Agent Loop 与状态机：循环是旧的，决策策略改变了什么

把 Agent 的代码展开，常能看到一个熟悉的结构：读取状态、决定动作、执行、更新状态，再重复。后端工程师很容易说“这就是一个 while 循环”。这句话准确描述了控制骨架，却尚未解释决定动作的部分怎样工作。

判断是不是旧技术换名称，首先要确定比较的是哪一层。循环机制、业务策略和实际能力，不是同一个对象。

先把循环拆成四个职责

沿用本专题的虚构故障助手：调查订单服务 5xx，读取授权资料，给出建议，经确认后创建工单。其运行可以抽象为：

text

观察与任务状态 S
    → 策略 P 提出候选动作 A
    → 执行器检查 A 的权限、参数和前置条件
    → 工具返回观察 O
    → 状态更新器依据 O 更新 S
    → 检查完成、暂停和预算条件

这个骨架能够用状态机、事件循环或工作流引擎实现。状态落库、超时、重试、取消和恢复也都可以采用熟悉的工程方法。仅仅在循环中调用一个模型，不会使这些组件获得新的执行保证。

但“策略 P”可以很不同。固定规则根据错误码选择预写分支；模型则可能根据日志中的描述，提出一个开发者没有逐项枚举过的查询。两者都被程序调用，不能因此认定两者的决策能力相同。

考虑三个实现：

实现	下一步从哪里来	可复用的后端经验	仍需验证的部分
固定规则	开发者预先编码的条件	状态机、单元测试、规则版本	条件是否完整
已有分类模型加流程	模型选择有限路由	模型服务、路由、回退	分类泛化与校准
语言模型提出动作	根据任务、上下文和观察生成候选	接口校验、调度、状态管理	语义理解、工具选择、参数与停止判断

这也说明，“传统系统完全确定，Agent 完全不确定”是一种过度简化。后端早就会调用学习模型、处理随机结果和不可靠外部服务。这里更突出的变化是，开放语言输入可以影响多轮任务中的行动选择，错误还会改变后面能看到的证据。

例如模型把连接超时误当成认证失败，下一轮就只查权限文档。后续证据可能强化第一次误判。执行器即使每一步都正确执行，也无法由此保证调查方向正确。

ReAct 论文研究将语言模型的推理与外部行动交替组织，让环境观察参与后续决策。工程上可以据此设计“发现配置引用→读取配置→修正假设”的路径。

这样的机制与反馈控制有结构上的联系，但不能仅画一个反馈箭头就认为系统会收敛。需要有可靠观察、可接受的动作集合，以及判断是否取得进展的标准。模型重复改写同一句话，状态没有新增证据，就不代表完成了三轮有效调查。

同时，没有必要把模型的私有思维过程当成业务状态。任务记录保存可观察动作、工具结果、证据和当前假设即可。自然语言解释可以帮助阅读，但要和权威执行记录分开。

假设资料只说明“新版支持自动恢复”，没有说明这次部署是否启用。模型生成“系统会自动恢复，可以关闭告警”，格式与权限都合法，但结论缺少配置事实。

这不是增加循环次数就一定能解决的问题。需要将“当前部署是否启用”列为必要证据，让未满足的槽位阻止强结论。外层程序负责保留这个要求，模型可以决定怎样寻找证据。

于是分工变得清楚：业务不变量约束任何策略，模型负责在允许范围内尝试更灵活的路径。对关键未知的处理，仍需语义核验或人工判断，不能声称一张状态表已经证明答案真实。

若一个所谓自主 Agent 的步骤固定、分支固定，模型只在每一步润色文本，那么它在编排层就是含模型节点的工作流。称其为 Agent 未必妨碍使用，但不能据此宣称获得动态规划能力。

反过来，若模型确实能面对未预写的情况组合工具，也不能凭一次演示认定收益。应使用相同工具、任务与预算，比较固定基线和动态策略：哪些任务改善，哪些退步，多花多少调用，失败后能否定位。

**本篇判断：循环与状态转换高度复用后端技术；从开放语义生成行动的策略能力不能由“while 循环”解释完。**选型应围绕策略是否解决了真实的信息依赖，执行保证仍按普通软件系统逐项验证。