把 AI Agent 做成系统：状态、工具与失败恢复

1st Sep 2026 AI Agent 工具调用状态机工程实践

Agent 最容易被说复杂，也最容易被做得过于简单。接一个大模型，再挂几个函数，并不自动等于“智能体”。真正拉开差距的是模型之外的部分：状态有没有落盘、动作是否可验证、失败后能否从断点继续、权限边界是否真的生效。

与其争论定义，不如看一个任务能否稳定跑完。

从普通脚本的边界说起

固定流程适合条件清楚的任务：读取输入、转换格式、写出结果。它的优点恰恰是没有自主性，行为容易预测。

问题出现在输入和环境都不稳定时。例如“检查一台服务器并修复站点”至少包含信息收集、故障判断、方案选择、执行、验证和回滚准备。每一步的结果都会改变下一步，预先写死全部分支很快就会失控。

Agent 适合的是这种下一步取决于刚刚发生了什么的任务。最小闭环并不神秘：

读取目标与当前状态
  → 选择一个允许的动作
  → 执行动作并保存原始结果
  → 判断状态是否变化
  → 达成目标则结束，否则进入下一轮

这里最关键的词不是“推理”，而是“状态变化”。如果一次工具调用没有产生可观察结果，系统就没有可靠依据决定下一步。

一个实用的任务状态至少应包含目标、当前阶段、已知事实、动作记录、产物、风险和结束条件。不要把所有历史对话都塞给模型，期待它自行找出重点。随着轮次增长，噪声会稀释真正有用的事实。

更稳妥的做法是同时保存三种信息：

三者用途不同，不能互相替代。

模型只能通过工具影响外部世界。工具返回一大段无结构文本，模型就只能猜；工具明确返回状态码、目标对象和变化摘要，判断会可靠很多。

一个删除接口不应只返回 success，还应给出目标、实际是否删除以及能否恢复。工具设计至少要满足：

提示词是行为引导，不是安全边界。

计划描述“准备做什么”，轨迹记录“实际做了什么”。很多实现把两者混在一段自然语言里，任务一长就会出现已完成步骤再次执行、失败步骤被误判成功的问题。

更合适的状态是 pending、in_progress、completed 和 blocked，并且同时只能有一个当前执行步骤。

“命令没有报错”也不等于步骤完成。修改配置后至少应重新加载服务并请求真实页面；上传文件后应检查内容；创建数据库记录后应读回验证。完成状态需要证据，而不是模型的主观判断。

真实环境中的失败通常不是永久故障：网络超时、锁冲突、令牌过期、服务冷启动都可能在下一次尝试恢复。但无脑重试会把临时问题放大成事故。

一个可控的重试策略应包含：

对于不可逆操作，优先设计补偿动作。例如部署前保留旧版本，切换失败后恢复旧版本；改配置前生成备份并验证备份可读。没有恢复路径的“全自动”只是把风险藏了起来。

Agent 不应该天然拥有整个系统的权限。合理的权限模型通常分三层：

文件工具应限制根目录，数据库工具应限制表和语句类型，网络工具应限制目标域名。即使模型被错误内容诱导，工具层仍应拒绝越权请求。

只看最终成功率会掩盖很多问题。至少还应记录：

评测数据应包含超时、空结果、部分成功、重复提交和权限不足等脏场景。只在理想输入上演示，测到的是脚本演示效果，不是系统可靠性。

我更倾向从半自动系统开始：先把工具、状态和验证做好，让模型只负责有限范围内的判断。运行轨迹稳定后，再逐步减少人工确认点。

顺序可以是：单任务闭环、结构化日志、失败恢复、权限分层，最后才是长期记忆和多 Agent 协作。前四项没有打牢，增加更多模型只会让故障更难复现。

Agent 的工程本质，是让一个不完全确定的决策组件运行在确定的约束里。模型负责提出下一步，状态机负责保持连续性，工具负责守住权限和数据边界，验证器负责回答“到底完成没有”。

当这些部分彼此独立、可以观察、可以恢复时，Agent 才从一次对话变成一个能长期维护的系统。