AI Agent（智能体）是能围绕一个目标自己拆步骤、调用工具、看结果再决定下一步的 AI 系统。它和聊天机器人的差别不在模型多聪明，而在结构：有没有循环、有没有工具、有没有判断「什么时候该停」的那一层。

一、先分清两种东西

你去自动售货机买水，投币、按键、掉一瓶，交易结束。你说「再来一瓶」，它再走一遍同样的流程。它不知道你刚才买了什么，也不会因为你连买三瓶而建议你换一种。

实习生不一样。你给他一个目标，比如「把这周的销售数据整理成周报，发给张三」，他自己会想：数据在哪、按什么口径算、周报用什么格式、张三的邮箱是多少。中间发现缺了一天数据，他会回来问你。

这两种东西的差别，就是聊天机器人和智能体的差别。

聊天机器人回答的是「问题」，智能体完成的是「任务」。问题只需要一个答案，任务需要一串动作。这是最本质的一条分界。

二、多出来的那个圈

把两者的流程画出来，差别一眼就能看到。

聊天机器人是一条直线：你问，它答，结束。没有下一步，也没有回头路。

智能体是一个圈：给目标，拆步骤，调工具做事，看结果。结果不对，回到拆步骤那一步重来；结果对了，继续往下走，直到交付。

这个圈是它和聊天机器人最关键的结构差异。圈的存在还带来一个副作用：它会犯错，也会自己发现错了。这不是坏事。一次就把事情做对靠的是运气，能发现做错了再改，才是工程上可控的东西。

聊天机器人的流程是一条直线，问完即结束；智能体的流程带一个回环，执行结果不达标时会回到「拆步骤」重新计划，这个回环是两类系统的结构分界。

三、四个部件

圈要转起来，需要四个部件同时在场。

模型负责判断下一步做什么。它是脑子，但只负责「想」，不负责「做」。

工具负责真的去执行：查数据库、调接口、写文件、发邮件。没有工具，智能体只能想，不能动。这也是前面讲 MCP 的原因，工具从哪来、怎么接，是另一套问题。

工具的描述也直接影响结果。同一个接口，描述写成「查询订单」，它可能只会在字面相关时才调用；写成「按客户编号查询该客户的全部历史订单，返回订单号、金额、下单时间」，它就知道什么时候该用、要传什么参数。这一步的差别，往往比换一个更强的模型更明显。

上下文负责记住刚才发生了什么：调了什么工具、返回了什么、上一步的判断依据是什么。这一环断了，圈就转不下去，它会重复做同一件事，或者忘掉自己已经做过。

循环控制负责什么时候停、什么时候问人。这一条最容易被忽略，却决定了它能不能用在真实业务里。没有它，智能体会一直转下去，或者在明显不对劲的时候继续硬做。

智能体要真正跑起来，四个部件缺一不可：模型负责判断，工具负责执行，上下文负责记录，循环控制负责叫停。其中循环控制不属于模型，而是一层外部规则。

四个部件里，循环控制是唯一一个不属于模型的部分。它是一层外部的规则，也是企业敢不敢让它碰真实系统的关键。

四、它怎么知道自己做对了

圈要能自己转下去，前提是它能判断上一步的结果对不对——这一步靠三种信号。

工具返回的结果。调用成功还是失败、返回了几条数据、状态码是多少。这是最硬的信号，写代码就能拿到。

规则校验。生成的数据格式对不对、必填字段有没有缺、明细加起来等不等于总数。这类检查最好写成代码，别指望模型自己看。

模型自己的判断。「这个结果看起来不太对」。这是最软的一种，也是唯一没法保证的一种。它有时候能发现问题，有时候会把错的当成对的。

成熟的做法是：把前两种做厚，第三种只当补充。让代码判断「对不对」，让模型判断「下一步做什么」。两件事分开，系统才稳。

反过来，如果一个智能体完全靠模型自己判断对错，它会在错误上叠加错误：第一步查错了数据，第二步基于错数据计算，第三步把错结果发出去。而且每一步它都「觉得」自己是对的——这才是最危险的地方。

五、跑长任务为什么会跑偏

还有一个所有智能体都会遇到的问题：任务越长，越容易忘掉最初的目标。

原因是上下文。跑到第十五步的时候，你最开始说的那句「注意不要动历史数据」，在对话历史里已经被推到很后面了。模型不是故意忽略，是这句话在它眼里的权重下降了。

缓解的办法有三个：把关键约束写进系统提示，让它每次都重新出现；每几步回头核对一次原始目标；把长任务拆成几个短任务。

这也是为什么，能跑三步的智能体到处都是，能稳定跑三十步的很少。差别不在模型，在上下文管理。

六、什么时候它比人快，什么时候它比人蠢

适合交给它的活，通常有三个特征：步骤多但每一步都不难、中间要查好几个系统、做完有明确的验收标准。

比如月底对账。人要打开银行流水、导出系统订单、逐笔核对、把差异挑出来做成表，一整天。换成智能体：它自己去取两份数据、按规则比对、把对不上的列成清单，人只需要看那份清单。这类活人做起来烦，机器做起来稳。

不适合的活也有三个特征：目标本身说不清、错了代价很大、需要跨权限操作。

「帮我优化一下客户体验」，这种活给它，它只会给你一堆看起来合理但没法执行的动作。目标说不清的时候，智能体不会变聪明，只会更快地跑偏。

代价大的活也一样。它可以生成一份合同草稿，但不该自己盖章发出去。

还有一种情况容易被忽略：数据本身是错的。智能体会把错数据算得又快又准。人看到一张明显不合理的表，会停下来问一句「这个数对吗」，它不一定。数据质量差的场景，先修数据，别急着上智能体。

七、三个误解

误解一：智能体就是更聪明的模型。不是。同一个模型，套上循环和工具就是智能体，不套就是个问答框。进步来自结构，不来自参数。

误解二：智能体可以完全无人值守。取决于你敢把边界画在哪。成熟的做法是分级：查数据这类只读动作可以放开，写入和删除必须人工确认。全自动不是目标，可控才是。

误解三：有了智能体，就不需要工作流了。恰恰相反。步骤固定、每次都一样的活，用工作流更稳、更便宜、更好排查。智能体的价值在「每次路径都不完全一样」的地方。把固定流程硬塞给它，是用不确定换不确定。

八、几个常被问到的问题

智能体和 RPA 有什么区别？

RPA 是照着录好的步骤点鼠标：第 3 步点这个按钮，第 4 步填那个框。它很稳，但脆，界面一改就得重录。智能体是按目标自己找路，界面变了它能换个走法，代价是每次路径不完全一样。前者适合高度重复、界面稳定的场景，后者适合判断多、系统多、路径不固定的场景。

它会自己乱做事吗？

会不会乱，取决于你给了什么工具、什么权限。给它一个只能读的数据库账号，它再乱也删不掉东西。风险不在「智能」本身，在授权范围。

企业里最先能落地的是哪类场景？

通常是读多写少的：查数据、做汇总、生成初稿、跨系统核对。这些错了可以重来，代价低，适合先跑通，再往写操作扩。

搭一个需要写代码吗？

看平台。有的要自己写循环和工具调用，有的已经把循环、工具、权限封好了，配置就能用。判断标准很简单：你需要为「怎么循环」写代码吗？需要，就是偏底层；不需要，就是偏产品。

怎么判断一个智能体做得好不好？

看三个指标：任务完成率，多少任务不用人插手就做完了；平均步数，做完一件事要转几圈，越少越省钱；人工接手率，多少任务需要人中途纠正。只看第一个会骗人，因为有一种完成叫「勉强算完成」。

它和 MCP、Skills 是什么关系？

MCP 管它够不够得着外部系统，Skills 管它知不知道该怎么干，智能体是那个「由谁决定下一步」的角色。三个东西叠在一起才完整，缺一个都跑不出稳定的结果。