上个月有人给我看他们内部的一个小工具：AI Agent 接手客服工单初筛，读完内容打标签，再按标签把工单分到对应的处理组。前二十分钟一切正常，二十来分钟后，它把一条带着明显情绪的投诉归进了“使用咨询”，还自动回了一段客套话。用户没等到人，第二天又发了一遍，措辞比第一次重。
这件事让我重新想一个问题：我们讨论 AI Agent 时，注意力大多放在“它能做多少事”，却很少放在“它什么时候该停”。前者是能力问题，后者是责任问题。而落地时卡住的，往往是后者。
能跑通和能上线，中间隔着几件事
演示环境和真实业务流程之间，差的不只是准确率。我观察下来，至少有三个问题需要提前回答。
- 这个动作可不可逆。发一条消息、改一条状态、提交一个申请，后果不一样。可逆的动作可以放宽，不可逆的动作要设置确认点。
- 结果能不能被验证。Agent 说“已完成”，系统能不能独立确认它真的完成了，而不是只相信它的措辞。
- 出错之后能不能追溯。哪一步读了什么、调用了什么、依据什么做了判断，日志里要留得下来。
这三条听起来像工程规范，其实决定的是信任边界。没有它们，Agent 做得越多，团队越不敢放手；有了它们，才谈得上把权限一点点交出去。
把大动作拆开
我见过一种做法：不让它直接执行写操作，而是生成一份待确认的草案，由人点一下再提交。听着笨，但很有效。它把“判断”和“执行”分开了——判断可以交给模型，执行留在有权限的那一侧。
再往下走，是把任务切成粒度合适的步骤。一次只做一件能被单独检查的事，一口气跑完整个流程，反而不容易定位问题。步骤之间加一个校验，比如字段是否为空、时间是否合理、收件人是否存在。这些校验不需要聪明，只需要确定。
常被忽略的一点是只读和写入要分开授权。查询类操作可以放开，改动类操作收敛。很多事故不是因为模型判断错，而是因为它判断错的时候，手里正好有写入权限。
“我不确定”这句话，模型说得太少
人在不确定时会问、会拖、会找人确认。模型倾向于给一个像样的回答，因为流畅本身就是它被训练出来的样子。于是模糊的输入被处理成清晰的结论，风险就藏在这中间。
所以在设计这套东西时，我会特意留一条降级路径：置信度低、输入矛盾、涉及例外规则时，转人工或者直接提问，而不是硬着头皮往下走。这条路径要写在提示里，也要写在流程里——光写在提示里不够，因为提示会被绕过。
评估方式也得换一换
现在很多团队评估这类系统，看的是任务完成率。这个指标在实验室里有意义，在生产环境里不够。生产环境真正关心的是：它做错的时候，有没有被拦住；拦住了之后，能不能快速恢复。
也就是说，失败的可恢复性，往往决定了一套系统能不能用。一个完成率八成的 Agent，如果错的那两成都能被校验拦下、被人接手，它是可以上线的；而完成率很高、错误却悄无声息流出去的系统，出了事反而不好收拾。
回到开头那个工单工具。后来他们加进去的东西不是新模型，而是一个提交前的确认按钮，外加一条规则：涉及投诉、退订、账号异常的关键词，一律转人工。任务量下降了一些，但重复投诉没有了。
这大概是我对 AI Agent 的一点理解：它不需要无所不能，它需要知道自己到哪儿为止。剩下的部分，交回给人。