Agent Loop: 从 ReAct 模式到可观测运行时

Agent Loop: 从 ReAct 模式到可观测运行时 Agent loop 很容易被写成一句伪代码： 这段代码看着很顺。它也确实能表达 ReAct 的核心直觉：模型一边推理，一边行动，再根据外部 observation 修正下一步。 但真正要上线时，这段伪代码会让人紧张。AgentLoop 从来不是 while true 调模型。它更像一个小型操作系统：状态由谁保存，工具调用如何治理，什么时候停止，失败如何恢复，预算如何消耗，人工确认在哪里插入，trace 如何复盘。 本文讨论一个更窄的运行时抽象： AgentLoop 是围绕随机模型决策构建的确定性运行时。 它把模型从全能控制器降级为 policy component，把状态、上下文、工具、预算、检查点和观测交给运行时管理。 目标不是让 Agent 更“自主”，而是让多步行动变得可观测、可恢复、可评测。 先把边界说清楚 文中的 Agent Loop 指运行时抽象，不是某个已经完整商品化的产品声明。讨论重点放在架构边界、状态转移、工具治理、会话恢复和评测边界上。 在博客 Agent、文档助手、工具型 Assistant 等场景里，这个抽象可以逐步落地：先保存会话和 trace，再引入受控工具，最后扩展到文件、权限、限流和人工确认。复杂度应该随着真实任务需求增加，而不是一开始就堆叠多 Agent 或重型编排。 1. From Pattern to Runtime ReAct 的贡献是把语言推理和环境行动放进同一条轨迹中。模型不再只是生成答案，而是可以先思考、再行动、再根据 observation 更新计划。这个范式适合工具使用、网页操作、检索问答和交互式任务。 ReAct 解决的是行为模式问题，但 AgentLoop 还要解决运行时问题： 当前任务状态是否独立于 prompt 保存？ 每一步模型输入由谁构建？ 工具参数如何验证？ 副作用 action 如何审批和去重？ 工具失败后如何重试、降级或终止？ 模型重复无效 action 时如何检测 no progress？ crash 后能否从上一个安全状态恢复？ 因此，...