第 1.1.4 节：为 Agent 设置停止条件和失败兜底
设计停止条件与失败兜底时，关键是提前写清何时停止、怎样降级、由谁接手。完成本节后，你应该能够列出停止条件与失败兜底的触发条件、兜底动作、日志字段和人工升级条件。
失败场景与兜底
| 失败场景 | 表现 | 兜底方式 | 验收标准 |
|---|---|---|---|
| 误把 Chatbot（聊天机器人）当 Agent（智能体） | 项目架构过重，开发成本失控 | 重新判型，只保留对话和资料回答 | 需求说明里能解释为什么不需要工具和状态。 |
| 误把高风险动作自动化 | Agent 承诺退款、修改订单或发送通知 | 高风险动作转审批，只允许创建申请 | 系统中有人工确认记录。 |
| 没有资料依据 | 模型凭感觉回答售后政策 | 进入 RAG（检索增强生成）或拒答 | 回答必须带来源，缺资料时明确说明。 |
| 没有停止条件 | 反复追问、反复调用工具 | 设置最大轮次、最大工具调用次数和转人工规则 | 日志能看到停止原因。 |
| 没有审计日志 | 出错后无法复盘 | 记录 trace_id（追踪编号）、输入、工具、输出和错误 | 能按一次会话复现处理链路。 |
读图重点：重试只处理短暂故障；权限、合规和资料边界不能靠增加重试次数解决。
常见坑
把所有 AI（人工智能）应用都叫 Agent（智能体）
如果系统只是单轮生成文案，它不是 Agent。命名不准确会导致架构过度设计。
没有停止条件
Agent 必须知道什么时候结束。没有停止条件，就容易出现反复调用工具、重复追问或输出不稳定。
工具权限过大
不要一开始就让 Agent 具备删除数据、付款、发邮件等高风险能力。高风险动作必须加审批。
只写成功路径
真实商业项目里，知识库缺失、接口失败、用户输入不完整才是常态。失败处理要在初始架构里出现。
工程检查清单
- 需求是否真的需要 Agent，而不是普通 Chatbot 或 Workflow（工作流）？
- 是否定义了 Agent 的目标和停止条件？
- 是否列出了可用工具和不可用工具？
- 是否有工具调用日志？
- 是否有人工审批或转人工路径？
- 是否有 Mock（模拟）模式，方便无密钥学习和测试？
- 是否有失败兜底？