Agent 的可靠性瓶颈，在“副作用”而不在“智能”

做 Agent Demo 很容易，做一个敢让它碰生产系统的 Agent 很难。最常见的故障模式不是模型推理错了，而是工具调用产生了不该发生的副作用：超时后自动重试，结果重复下单、重复发消息、重复建工单。模型可以重试，系统不能重复生效。

这引出一个被低估的工程原则：任何有副作用的工具都必须支持幂等。支付、发消息、写数据库、创建工单，这些操作需要幂等键，让“重试”在语义上等价于“只执行一次”。Agent 的可靠性不取决于模型多聪明，而取决于系统层能不能兜住模型的错误、重复和误解参数。

第二层是权限边界。模型可以读不可信内容，但不能拥有不可信权力。工具权限应该最小化，敏感操作需要人工确认，工具参数要做白名单和 Schema 校验，网络和文件访问要限制范围。提示注入很难靠 Prompt 彻底解决，安全边界必须放在架构里。把外部内容标记为“数据”而非“指令”有帮助，但真正的防线是系统层校验，不是提示词措辞。

第三层是可观测性。Agent 的一次任务可能串起检索、重排、多次模型调用、工具执行和后处理。没有 trace ID 把这些环节串起来，bad case 根本复现不了。至少需要记录完整的请求上下文（脱敏后）、模型参数、原始输出和解析结果、每段耗时和 token 消耗、工具调用的输入输出和结果状态。日志不是给审计看的，是给迭代用的。

还有一个容易被忽略的点：Agent 的失败态设计。流式输出到一半模型报错怎么办，工具调用成功但后续生成失败怎么回滚，用户取消后后台还在跑怎么止损。这些不是“模型能力”问题，是工作流设计问题。把失败态画清楚，比多调两版 Prompt 更能减少线上事故。

一句话的工程判断：Agent 不是“让模型自由行动”，是“让模型在幂等、最小权限、可观测、可回滚的边界内行动”。先建边界，再谈自主性。