为什么 Agent 容易失控
当模型被允许调用工具、浏览网页或执行命令时，失败模式会从「答错」变成「做错事」：无限循环、重复调用、错误参数、或把敏感操作当成常规步骤。护栏的目标不是限制模型，而是让系统在可预测边界内工作。
状态机比「自由对话」更可靠
把任务拆成可枚举的状态：收集信息 → 制定计划 → 执行 → 验证 → 结束。每一步都定义允许的输入/输出与失败分支。自由对话可以作为 UI，但底层执行应落在状态机里，否则很难调试。
预算：轮次、时间与金钱
为每个任务设置最大轮次、最大耗时与最大外部调用成本。预算一旦触发，必须进入「安全降级」：停止、请求人工、或返回最小可用结果。没有预算的 Agent，本质上是在赌运气。
工具白名单与最小权限
只允许调用明确列出的工具；参数要做 schema 校验；敏感工具需要二次确认或人工审批。对「写操作」要格外谨慎：删除、付款、发邮件、对外发布，都应默认拒绝，除非显式授权。
人在回路：什么时候必须介入
当出现以下情况时，系统应自动转人工：连续失败、置信度低、涉及敏感操作、或用户明确要求。把转人工设计成产品能力，而不是客服补救。
可观测与可回放
记录每次工具调用的输入输出（注意脱敏）、模型版本与提示版本。出现问题时，你能回放并定位是「哪一步」错了，而不是只看最终答案。
常见事故复盘模板
很多团队知道要做复盘，但模板过于抽象，最后只写成一句“模型判断错误”。建议固定四段：事件概述、影响范围、直接原因、系统性原因。直接原因通常是某一步规则漏掉，系统性原因通常是“没有测试样本”“上线阈值定义不清”“权限审批缺少日志”等。把系统性原因写清楚，才能避免相同问题换个入口再次发生。
交付前检查清单（可直接落地）
在你把 Agent 功能推到生产前，至少确认以下事项：
- 是否配置了单任务最大轮次、最大执行时间、最大调用成本。
- 是否对高风险工具做了二次确认或人工审批。
- 是否有失败后的统一返回格式（例如错误码、可读解释、建议下一步）。
- 是否有观察面板能看到任务成功率、平均轮次、超时率、人工接管率。
如果这四项中有两项以上缺失，建议先在灰度环境运行，不要直接全量开放。
小结
Agent 不是更聪明的聊天机器人，而是「带风险的自动化」。把终止条件、权限与预算写进系统，再谈智能，才能从 demo 走向生产。