Chatbot变Agent的渐进式陷阱

大多数 Agent 项目最初都不是以 Agent 的身份起步的。它们最初只是一个回答问题的 Chatbot，然后有人让它再去更新一条记录，再然后有人让它一小时后回来检查——到了第三个需求的时候，你已经在维护一个调度器、一个重试策略和一套没人梳理过的权限模型了。重写不会大声宣告自己，它是一点一点累积出来的。

之所以值得提前识别这个节点，是因为这两种架构并不是「同一种东西、不同的工作量」——它们是截然不同的形态。

票据里的动词

我所知的最快测试方法，就是读需求里的动词，其他的全部忽略。

「回答关于我们退货政策的问题」是一个 Chatbot。输出是一条消息，消息就是工作的终点。

「监控退货队列、识别重复薅羊毛的人、并创建工单」是一个 Agent。输出是对话之外某个地方的状态变更。

这一行几乎能预测下游所有的事情，因为 Agent 那些昂贵的组件存在的目的，就是为了在没有人工盯着的情况下，安全地执行状态变更。

聊天循环永远不需要的四层

Chatbot 是一个小型系统。解析输入、调用模型、渲染回复。一个请求进来，一个响应出去，整个流程可以在脑子里装下。

Agent 增加了四个聊天循环没有任何理由背负的组件。

工具调用，让它能访问 API、数据库、文件系统和浏览器，而不只是生成文本。持久化记忆，让它在会话之间积累，而不是窗口关闭就重置。规划，让一个目标分解为有真实依赖关系的、有序的子任务。还有反思，让它能评估自己的输出、发现失败的步骤、并换一条路走，而不是返回一个自信的错误答案。

去掉其中任何一条，你就得到一个加了步骤的 Chatbot。这就是为什么给聊天端点挂一个函数调用，在演示中看起来很好，但实际行为却不是那么回事——循环里缺少了「调用失败时该做什么」的那部分。如果你想把每一层和它对应的 Chatbot 版本对照着看，这两种架构的并排拆解值得一读。

成本模型的形状变了

Token 账单是每个人最先估算、但其实最不重要的那个数字。

Chatbot 的成本在会话量上大致是线性的。用户翻倍，花费翻倍，在餐巾纸上就能算出来。

Agent 的成本是每个目标消耗的步数，而每个目标的步数其实取决于重试频率。一个Planner 第一次就选错工具，不只是多花一次调用的钱——它把那个选择下面整条分支的调用都赔进去了。两个 Agent 拥有完全相同的 prompt、完全相同的模型，月度花费可能相差好几倍，原因纯粹就是它们第一次就做对的频率不同。

第二项成本永远不会出现在定价页上。一旦软件能自己修改数据库或发邮件，你就需要权限体系、审计日志，以及一种能回答「上周二它碰了什么」的方式。那些跳过这一步的团队早期跑得很快，然后就会卡住——因为没有人会签署同意给一个无法解释自己行为的系统生产环境访问权限。

路由才是真正的产品

那些在生产环境中运行良好的系统，几乎从来不是纯的。Chatbot 前端处理可预测的绝大多数——FAQ、订单查询、带引导的流程——成本低、延迟低。在它后面坐着一个 Agent，接手那些真正需要多个步骤和真实工具访问的请求。

两者之间的路由决策，才是工程上真正花功夫的地方，也是被关注最少的一环。路由得太积极，你就会用 Agent 的价格去回答一个数据库查询就能搞定的问题。路由得太保守，用户就会撞上 Chatbot 无法跨越的那堵墙——而这恰恰是让人彻底不再信任这个功能的体验。

值得注意的是，路由层也是日后改变主意成本最低的地方。在 Agent 内部做错了，意味着要返工 Planner。

不要从标签出发。先读动词，判断输出是一条消息还是一次状态变更，让这个判断来选择架构。

如果是状态变更，第一个设计问题不是选哪个框架，而是——你愿意让这东西自主做出哪些决策，对于那些你不愿意的决策，又会发生什么。尽早回答这个问题，重试、权限和审计日志就不再像是负担，因为它们是 Agent 得以运行的唯一原因。