LLM Agent 的状态机设计：从一次性失败中学到的 5 件事

去年我们为某 SaaS 客户做的客服 Agent 在生产第一周失败了。问题是 Agent 进入了「无限工具调用循环」：每次 LLM 输出都决定再调一次工具，永远不返回。

复盘之后，我们沉淀出 5 个原则：

1. 显式状态机优先于隐式提示

不要让 LLM 自己「决定下一步」。把状态枚举出来：需求收集 / 检索知识 / 调用工具 / 给出答案 / 转人工。每个状态有明确入口、出口、超时。

2. 工具调用次数硬上限

每个会话给出最多 N 次工具调用预算（我们默认 8）。超过即强制进入「转人工」状态，不允许 LLM 继续决定。

3. 关键决策点强制确认

任何会修改外部状态的操作（下单、退款、发邮件），必须给用户一个明确确认按钮。哪怕 LLM 已经「决定」要做。

4. 失败模式必须可观测

每次工具调用结果、LLM 输出、状态转移，全部写日志（结构化 JSON，不是文本）。失败时 5 分钟内能定位是工具问题、LLM 问题，还是 prompt 问题。

5. 灰度发布，永远

新版 Agent 先放 5% 流量，观察 24 小时无异常再扩 30%，再 100%。客户看不到 100% 切换的能力，是产品风险。

这 5 条做完后，第二次发布跑了 6 个月没出过事。