Agent Loop：智能体如何完成一次自主任务
Agent Loop 为什么是智能体的核心？从开放环境中的反馈需求出发，分析决策循环、状态机、失败恢复与终止条件。
把模型接入工具之后，最容易写出的 Agent 是一个 while 循环：模型选择工具，程序执行工具，再把结果交还模型。它可以在演示中工作，却经常在生产环境中陷入重复调用、错误重试、提前宣布完成或无限消耗预算。
问题不在于循环代码太简单，而在于我们把一个控制系统问题误写成了一个聊天问题。
What：Agent Loop 是什么
Agent Loop 是智能体与环境持续交互的执行协议。每一轮至少包含四个阶段：观察当前状态、决定下一步、执行行动、根据结果更新状态。
Observe → Decide → Act → Evaluate
↑ ↓
└──────── Continue ───────┘
这个结构与机器人控制、强化学习中的 Agent-Environment Loop 有共同来源，但语言模型 Agent 有自己的特点：状态主要以文本和结构化事件存在，行动通常是工具调用，策略由大模型临时生成，而不是一个稳定的显式函数。
ReAct 将 Reasoning 与 Acting 交错起来，说明了反馈循环的核心意义：模型不必在一开始凭空构造完整答案，而可以通过行动获取信息，再根据新证据修正推理。
Why：为什么不能先规划完再一次执行
对于封闭任务，一次规划可能足够。但开放环境具有三个性质。
第一，环境是部分可观察的。排查故障前，我们不知道问题在哪个服务；阅读一个日志后，才知道下一步该检查配置还是数据库。
第二，行动会改变环境。修改文件、创建资源、发送请求都会产生新状态，后续决策必须基于改变后的事实。
第三，行动结果具有不确定性。网络可能超时，工具可能返回部分成功，用户可能同时修改同一份数据。原计划无法覆盖所有分支。
因此，Agent 的计划更接近滚动规划：高层目标保持稳定，局部路径在每次观察后重新计算。循环不是为了让模型多“想”几次，而是为了让认知与现实保持同步。
一轮执行不只是模型调用
生产级 Loop 在模型前后都有确定性边界。
进入模型前，Runtime 需要从事件日志中投影当前状态，装配系统规则、任务目标、最近结果和可用工具。这里必须区分事实与推测：工具返回值是观察，模型对返回值的解释只是推测。
模型输出后，系统不能直接照做。它要验证工具是否存在、参数是否符合 Schema、当前身份是否有权限、调用是否超过预算，以及该操作是否需要人工确认。
工具执行后，结果应先写入不可变事件，再进入下一轮上下文。这样即使进程崩溃，也能从已确认的事实恢复，而不是依赖模型记住发生了什么。
可以把一次 Run 建模为状态机：
Created → Running → WaitingForTool → Running
↘ WaitingForHuman ↗
Running → Succeeded | Failed | Cancelled | BudgetExceeded
状态机比一个无限 while 更重要，因为它让暂停、恢复、取消和审计有了确定语义。
失败为什么不能统一重试
“失败就重试三次”是常见做法，却混淆了不同类型的失败。
传输超时可能适合退避重试；参数校验失败意味着模型需要修正调用；权限拒绝需要用户授权；业务冲突需要重新读取状态；测试失败则提供了新的诊断证据。对所有错误采用同一种策略，会把确定性错误变成昂贵的循环。
副作用操作还需要幂等语义。发送邮件时连接超时，并不能证明邮件没有发送。如果 Agent 直接重试，可能造成重复通知。工具层应使用幂等键、操作回执或事后查询，让 Runtime 能区分“执行失败”和“结果未知”。
Reflexion 等研究尝试让 Agent 把失败总结成语言反馈，在后续尝试中利用。这能改善部分任务，但反思本身仍由模型生成，可能把错误归因写入记忆。反思不能替代外部验证。
终止条件是 Loop 最难的部分
模型很容易继续产生下一步，也很容易根据主观判断宣布完成。真正的终止应该来自显式条件。
成功终止需要验收证据，例如测试通过、目标状态可查询、产物存在且格式正确。阻塞终止表示需要缺失的信息或权限。失败终止表示已知无法在约束内完成。预算终止则保护时间、Token、工具调用次数和金钱。
“停止”不是失败处理的附属功能，而是安全能力。一个不知道何时停止的 Agent，本质上是一个无法证明会收敛的自动化系统。
Loop 的代价与失败模式
循环会放大误差。一次决策偏差可能在后续被当作事实，逐步形成错误轨迹；错误工具结果进入上下文后，还可能污染规划。长链路的整体成功率也会随步骤增加而下降：即使每一步都相当可靠，几十步组合后仍可能脆弱。
另一个问题是可复现性。模型、外部数据和工具状态都可能变化，完全重放并不容易。工程上需要保存模型版本、输入上下文、工具参数、响应、时间和环境标识，才能接近可诊断。
Loop 还带来延迟和成本。能用数据库事务或确定性脚本完成的操作，不应该为了“智能”而拆成十轮推理。模型只应介入无法通过明确规则解决的决策点。
研究真正缺少什么
当前很多 Agent Benchmark 关注最终是否成功，却较少解释过程为什么成功。我们需要能评价计划质量、工具选择、恢复能力、成本效率和风险暴露的过程指标。
长期任务还需要更好的层级控制。单一模型同时负责战略规划与每个微小动作，容易在局部细节中丢失全局目标。未来的 Runtime 可能需要把目标、阶段计划与原子行动放在不同时间尺度上管理。
另一个方向是形式化验证与概率策略的结合。数据库事务、类型系统和策略引擎可以证明部分不变量，但无法证明模型一定选择正确目标。未来系统可能把开放决策交给模型，把资金上限、资源范围和状态转换交给可验证规则，并用运行时监控检查轨迹是否偏离允许集合。
我的判断
实践中还应为循环建立进度信号：新的证据是否增加、待办是否减少、验收是否更接近。如果连续多轮没有状态增量，即使每次工具调用都成功，也应判定为停滞并触发重新规划或人工介入。
Agent Loop 的价值不在于重复调用模型，而在于建立一条“提出假设—作用于环境—获得证据—修正判断”的因果链。模型负责处理开放性，Runtime 负责提供确定性。
成熟的 Loop 应当让每一步都可解释为：为什么现在做这件事，执行前需要什么权限，执行后产生了什么事实，以及什么证据允许任务继续或结束。做到这一点，Agent 才从会调用工具的 Demo 变成可运行的系统。