演示环境里，AI Agent 读邮件、提取需求、写进表格，常常一气呵成。换到真实邮箱，一封带附件的邮件就可能让它卡住：附件解析失败，它没有停，而是换个方式重试，又把同一封邮件重新分类了两次。流程看着还在跑，结果已经悄悄分叉。
这类问题很少出现在宣传视频里。视频展示的是“目标—行动—完成”，真实系统里更多是“目标—行动—失败—判断要不要重试”。重试本身不是坏事，坏的是没有边界的重试。一个会调用工具的 AI Agent，如果不知道哪些动作可以重复、哪些动作只能发生一次，越“勤奋”越容易制造脏数据。
先分清“能做什么”和“可以做到什么程度”
工具调用让 Agent 从聊天框走进业务流，也把权限问题摆到桌面上。读取日历和修改日历是两种权限；查询订单和发起退款也是两种权限。很多演示只验证前者，上线后却默认后者。比较稳妥的做法，是把动作按影响范围切开：只读、可逆写、不可逆写。不可逆的那一类，宁可多一次人工确认，也不要让模型自己“看着办”。
- 只读动作：查询、摘要、分类，失败可以重来。
- 可逆写动作：草稿、待确认记录，允许回滚。
- 不可逆写动作：发送、删除、覆盖，先确认再执行。
另一个常被低估的是记忆。AI Agent 有记忆，听起来像更懂你；放到多人协作里，也可能是把甲的信息带进乙的会话。记忆该存什么、存多久、谁能清空，最好在设计时就写清楚，而不是等用户来问“它怎么知道的”。
失败要能被看见
我倾向于把可观测性放在“更聪明”之前。一次任务跑了哪些步骤、调用了哪个工具、参数是什么、返回了什么、为什么决定重试，这些记录比最终答案更有诊断价值。没有这些，排障只能靠猜；有了这些，至少能判断是模型选错工具，还是工具本身不稳定，抑或是提示词把边界写含糊了。
人工兜底也不等于失败。相反，它是把不确定性收口的一种方式。当置信度低、动作不可逆、或者连续重试超过设定次数时，把上下文交给一个人，比让 Agent 继续试更划算。关键在于交接要完整：前面做了什么、卡在哪、建议下一步是什么，而不是只弹一句“任务失败”。
别急着让它“全自动”
AI Agent 的价值不只在替代人手，也在把流程里含糊的地方逼出来。哪些步骤必须留痕，哪些动作需要审批，异常时谁来接手，这些问题原本就存在，只是过去被人顺手补掉了。现在要让 Agent 参与，就得把隐含规则写成显式规则。
所以，评估一个 Agent 时，除了看它完成任务的速度，也可以看它失败时的样子：会不会停，会不会说清楚为什么停，会不会把现场保留下来。能把这些做稳，再谈更复杂的自主性，可能更实际。