前阵子我们组做了一个 AI Agent Demo。
需求不复杂：让它读取客户反馈，自己查知识库，再把问题分成产品、售后和使用咨询三类。现场跑得挺顺，几秒钟就给出结果，分类也像模像样。
有人当场问：“这个下周能不能上线？”
我没马上接话。
不是故意泼冷水。做过 Agent 的人应该都有这种感受：Demo 跑通的那一刻很兴奋，可一想到真实用户、真实权限和那些时不时抽风的接口，脑子里马上会冒出一堆问题。
知识库没查到怎么办？接口超时以后，它会重试还是继续编？用户一句话没说清楚，它是追问还是自己猜？更要命的是，如果它不只生成建议，还能真的改订单、发邮件，做错以后谁来收拾？
到这一步，事情就不再是“调个提示词”那么简单了。
Agent 不只是会回答，它还会动手
普通的大模型应用，大多停在回答问题这一步。
你问，它答。答案不合适，最多重新生成一次。
Agent 不一样。它会根据目标决定下一步做什么，可能查询数据库，也可能搜索资料、调用接口，甚至修改业务系统里的状态。
比如，让 Agent 查某个产品销量下降的原因。
它先看整体销量，发现华东下降明显；再拆渠道，发现问题集中在一个经销渠道；接着查询库存和活动记录，最后给出原因判断。这一串动作，才是 Agent 真正有用的地方。
也正因为它会动手，风险跟着放大了。
模型回答错一句，用户可能只是觉得不好用。Agent 调错一次接口，结果可能是邮件发错人、订单被重复创建，或者本来没有权限看的数据被查了出来。
所以我现在判断一个东西是不是生产级 Agent，不看它会不会讲漂亮话，先看它犯错时会发生什么。
Demo 为什么总比生产环境听话
演示时，我们通常会选一条比较顺的路径。
输入写得清楚，测试数据提前准备好，接口也刚刚检查过。就算中间出了小问题，演示的人知道怎么换一种问法，把流程带回来。
真实用户可没这个耐心。
他们会说：“昨天那个客户的问题，你顺手处理一下。”
哪个客户？什么问题？“处理”是整理材料、生成回复，还是直接修改工单状态？
人和同事沟通时，可以靠共同背景补上这些信息。Agent 如果也靠猜，迟早会猜到不该猜的地方。
接口同样不会一直配合。最典型的一种情况是，查询请求超时，工具却给模型返回了一个空结果。模型看到“空”，顺着逻辑写出：“目前没有待处理工单。”
句子很通顺，结论也像真的。可系统不是没有工单，只是这一次没查出来。
这种错误比胡言乱语更难发现，因为它看起来太正常了。
我后来把“想”和“做”拆开了
刚开始做 Agent 时，我也想让模型包办整个流程：理解需求、规划步骤、调用工具、判断结果，然后直接执行。
后来发现，这种方式在 Demo 里很省事，到了生产环境却不好管。
现在我更愿意让模型负责“想”，让程序负责“做”。
模型可以判断下一步需要查订单，但真正查询之前，程序要检查用户是谁、能看哪些订单、参数是否完整。模型可以建议退款，但退款金额、审批条件和最终提交，不能由它一句话决定。
说得直白一点，模型负责出主意，系统负责守规矩。
工具也不能做得太宽。与其扔给 Agent 一个“自由查询数据库”的入口，不如直接给它几个清楚的业务动作：
- 查询当前客户的订单；
- 获取指定时间内的退款记录；
- 创建一份待审核回复；
- 提交退款申请。
动作越明确，出错后越容易知道问题卡在哪里。
还有一个很小但很关键的细节：工具必须告诉 Agent，这次是“查到了空数据”，还是“根本没查成功”。
人能分清这两句话，系统也必须分清。
任务做到一半，不能假装什么都没发生
Agent 处理的任务一长，状态问题就出来了。
假设它已经创建了退款申请，正准备更新工单时网络断了。恢复以后，如果它从头再走一遍，就可能重复退款；如果它只看聊天记录，又未必知道前面哪些动作已经真正落到了业务系统。
所以聊天上下文和任务状态必须分开。
聊天上下文告诉模型，我们刚才聊了什么。任务状态则要明确记录：查过哪些数据，执行到哪一步，哪个动作已经成功，当前是不是在等人工确认。
每个写入动作还要有唯一标识。哪怕因为网络问题重复提交，系统也只能执行一次。
这个部分不太适合拿来做发布会演示，却直接决定 Agent 上线后会不会给团队添乱。
记忆也不是越多越聪明
不少 Agent 产品喜欢强调长期记忆，仿佛记得越多就越懂用户。
我倒觉得，记忆首先要解决的不是“存多少”，而是“什么该存”。
用户说“这次给我一个简版”，大概率只是临时要求。要是 Agent 把它记成长期偏好，以后每次都交一份简版，用户反而会觉得莫名其妙。
我会把记忆分得简单一点：
当前对话里有效的信息，放在会话中；任务执行进度，放在任务状态里；真正稳定的偏好和事实，要经过确认以后再长期保存。
旧信息还得允许修改和删除。不然 Agent 记住的不是用户，而是一堆已经过期的用户版本。
企业第一次做 Agent，别急着做万能助手
“做一个什么都能处理的企业助手”，听起来很有吸引力。
但边界越大，权限越难管，出了问题也越难查。
我更建议从一个小任务开始。比如工单分类、知识检索、会议纪要、销售线索整理，或者生成一份待审核的客户回复。
这些任务有几个共同点：出现频率高，过程相对清楚，结果也容易由人检查。即使 Agent 判断错了，也不会立刻造成不可逆的损失。
付款、退款、删除数据、修改权限这类动作，可以晚一点再开放。先让 Agent 查询，再让它提建议，最后才考虑执行。
别嫌这个节奏慢。权限一次开得太大，后面补安全措施，往往比从头设计还麻烦。
上线前，我会故意给它找麻烦
测 Agent 不能只拿标准问题喂它。
我会故意少给一个参数，故意放两条互相冲突的规则，或者让某个工具超时。还会模拟任务做到一半被打断，看它恢复以后会不会重复执行。
除了答案对不对，我还会看几件事：
它有没有选错工具？参数是不是乱填的？查不到资料时会不会硬答？遇到越权请求会不会停？出了问题，日志能不能还原它当时的判断？
其中我最在意的，是它能不能承认“现在无法确认”。
一个 Agent 偶尔完成复杂任务，并不稀奇。难的是它在证据不足时不自作聪明。
从 Demo 到生产，真正要补什么
回头看，Agent 从 Demo 到生产，大致要补上四样东西：
先把任务边界说清楚，再把工具接口做扎实；给长任务加上可恢复的状态；最后补齐权限、审计和人工确认。
提示词当然还要调，模型也可以继续换。
但这些都不是最难的部分。
Demo 证明的是 Agent 在理想情况下可以完成任务。生产系统要证明的，是接口不听话、用户没说清楚、数据又不完整时，它仍然知道什么时候继续，什么时候停下来找人。
我们最后需要的，也不是一个看起来什么都会的聊天机器人。
而是一个做事有边界、出错能追踪、不确定时敢停下来的执行系统。
这才是 AI Agent 真正开始进入生产的标志。
