企业官网建设流程全解析

很多人第一次看 Agent，注意力会放在工具上。它能读文件、能跑命令、能查资料、

能改代码、能发请求。这些能力确实重要。但工具不是 Agent 的核心。

真正让一个 AI 系统从“回答问题”变成“执行任务”的，是循环。

Goal -> Plan -> Act -> Observe -> Verify -> Update State -> Repeat

没有这个循环，模型只是一次调用。有了这个循环，模型才开始像一个执行系统。

它会根据目标判断下一步。根据工具结果修正判断。根据验证结果决定继续还是停止。

根据状态更新接住下一轮。这就是 Agent Loop。

一、Agent Loop 解决什么

普通 LLM 调用解决的是一次响应：输入进来、输出出去、过程结束。

Agent Loop 解决的是多步任务。

它面对的问题不是：

这句话怎么回答？

而是：

为了完成这个目标，下一步应该做什么？ 做完以后看到什么？ 结果是否足够？ 如果不够，下一步怎么调整？

这类任务天然不是一次调用能解决的。

比如：

修一个线上 bug 整理一份竞品报告 迁移一个接口 审查一个 PR 生成一组公众号草稿 每天检查文档是否过期

这些任务都有共同特征：

目标明确 路径不完全明确 执行中会产生新信息 需要工具 需要验证 可能需要多轮调整

这就是 Agent Loop 的适用区间。

二、最小内核

一个 Agent Loop 至少有六个环节。

第一，Goal。

系统必须知道目标是什么。

不是一句模糊愿望，而是能指导行动的目标。

修复 failing test 把 PR review comments 处理完 生成可发布的公众号草稿 把知识库中过期链接更新掉

第二，Plan。

模型根据目标、上下文和可用工具，决定下一步动作。

这里的计划不一定很长，很多时候只是下一步。

先读失败日志 先找相关文件 先跑测试复现 先查最新接口文档

第三，Act。

Agent 调用工具。

工具可以是文件系统、Shell、浏览器、数据库、API、MCP server，也可以是内部业务接口。

第四，Observe。

工具返回结果后，结果进入上下文。这是循环和普通函数调用最大的差异。

工具不是只产生副作用。工具输出会改变下一轮推理。

第五，Verify。

Agent判断当前状态是否接近目标，验证可以是确定性的。

test passed schema valid build success API returned 200 draft saved

也可以是推理型的。

回答是否覆盖用户需求 摘要是否忠实原文 报告是否有足够证据 风险是否被说明

第六，Update State。

循环不能只靠模型上下文记忆，它需要把进度、决策、失败、待办和验证结果写入状态。

否则任务一长，Agent 就会忘。或者重复、或者把旧结论当成新事实。

三、循环的难点不在循环

写一个循环很简单。

while not done: ask model call tool append result

这不是难点。

难点是四件事。

第一，退出条件。

Agent 什么时候算完成？

如果完成条件只靠模型说“我完成了”，风险很高。更好的做法是把完成条件外显。

所有测试通过 所有 review comments 已回复 草稿箱返回 media_id 检查清单全部勾选 人工审批通过

第二，状态边界。

哪些信息进入上下文？哪些落盘？哪些只保留摘要？哪些必须丢弃？

第三，验证强度。

低风险任务可以用模型自检。中风险任务需要测试、schema、引用或二次审核。

高风险任务需要人类审批。

第四，预算控制。

循环如果没有预算，就会无限尝试。

最多多少轮？ 最多多少 token？ 最多多少工具调用？ 失败几次后升级人工？

这些才是 Agent Loop 的工程部分。

四、三种 Loop

不同系统里的 loop 长得不一样，但大体可以分成三类。

1. ReAct Loop

这是很多 Agent 的基础形态，模型推理，选择工具，观察结果，继续推理。

它适合路径不确定、需要边查边做的任务。

比如排查 bug、查资料、探索代码库。

风险是：

容易走偏 容易过度探索 容易把工具输出直接当真 容易没有明确停止条件

所以 ReAct Loop 必须配验证和预算。

2. Workflow Loop

Workflow Loop 的路径更确定。

比如：

读取输入 抽取字段 调用工具 校验 schema 生成结果 写入数据库

模型可以参与某些步骤，但整体流程由代码控制。

它适合稳定业务流程，优点是可控，缺点是灵活性较低。

3. Event-driven Loop

Event-driven Loop 不是用户一直坐在聊天框前触发。

它由事件触发。

PR opened issue assigned build failed 每天 9 点 文档变更 客户工单进入队列

这类 loop 更接近自动化系统。它的难点不只是执行，还包括触发器、权限、审计、失败恢复和人类升级。这会进入下一篇的主题：

Loop Engineering。

五、SDK在管理什么

OpenAI Agents SDK 里的 Runner，本质上就是把多轮模型调用、工具调用、handoff、guardrails 和 session 管起来。

Claude Agent SDK / Claude Code 一类系统，也是在让模型评估当前状态，决定是否调用工具，把工具结果回填，再继续评估。

你当然可以自己写 loop。但只要进入生产环境，SDK 或框架至少要帮你管理这些事：

turns tool calls tool result injection guardrails handoffs sessions interruptions resume state trace cost limits

如果你不用 SDK，也要自己设计这些能力。不是因为框架高级。

而是因为 loop 天然需要运行时。

六、什么时候不要用 Agent Loop

不是所有任务都需要 Agent Loop。如果任务输入清楚、路径确定、输出格式固定，用普通函数或 workflow 更好。

比如：

字段抽取 格式转换 分类打标 固定模板生成 确定性 API 编排

Agent Loop 的价值来自不确定路径。

如果没有不确定性，就不要为了“Agent 化”引入循环。

循环会带来成本。

也会带来失败模式。

重复执行 过度调用工具 目标漂移 状态污染 错误累积 权限扩大

能不用 loop，就不用；能用 workflow，就先用 workflow。

只有当任务需要根据中间结果动态决策时，再引入 Agent Loop。

七、实战 Checklist

设计一个 Agent Loop 前，先问这十个问题。

1. 目标是否可验证？ 2. 成功标准是否外显？ 3. 下一步动作是否需要模型动态决定？ 4. 可用工具是否足够清晰？ 5. 工具输出是否可追踪？ 6. 每轮是否有验证？ 7. 状态写在哪里？ 8. 最多允许多少轮？ 9. 失败几次后停止或升级人工？ 10. trace 能否解释每一轮为什么继续？

如果这些问题没有答案，Agent Loop 只是一个会花钱的 while 循环。

八、最后

Agent Loop 是所有自治系统的最小内核，但它不是魔法。

它只是把模型放进一个执行循环里。真正决定可靠性的，是循环周围的工程设计：

目标 状态 工具 验证 退出条件 预算 审计 人类监督

这也是为什么前面几篇要先讲 Prompt、Context 和 Harness。

Loop 不是替代它们。

Loop 是把它们串起来。

下一篇，我们进一步往外看：

Loop Engineering。

不是写一个循环。

而是设计一个能围绕目标持续运行的自动化系统。

参考资料：

• OpenAI Agents SDK: Running agents / Runner
• OpenAI Agents SDK: Agents, tools, guardrails, handoffs, sessions
• Anthropic: Building Effective AI Agents
• Claude Code / Claude Agent SDK agent loop documentation
• Anthropic: Effective Harnesses for Long-Running Agents

参考文献：

第十二篇：Agent Loop，所有自治系统的最小内核