最近 LangChain 发表了一篇题为《The Art of Loop Engineering》的博客文章指出：“模型推理-工具调用”只是 Agent 工作模式最基本的循环，通过构建和叠加四种不同层次的循环，可以让 Agent 变得更高效甚至自我进化。
下面来拆解这四层循环架构是如何提升 Agent 的能力。
01 第一层：Agent 循环
第一层是 Agent 循环（Agent Loop），它是 Agent 行动的基础。从这个层面理解，Agent 的本质就是：一个大语言模型（LLM）在循环中不断调用工具，直到任务完成。
图注：源自 LangChain 博客，Agent 循环
这就是 LangChain 中 create_agent 函数提供的基础能力。你选择一个模型，接入一组工具，就得到了一个可以运转的 Agent 循环。
在这个循环中，工具赋予了 Agent 在现实世界中采取行动的能力，而模型则负责规划和决策。
以 LangChain 的“文档 Agent”为例。当它收到一个“改进某篇文档”的请求时，模型会进行规划，然后使用工具去克隆代码仓库、读取文件、修改内容、最后提交 PR（Pull Request）。
这一层循环解决了“能不能做”的问题。它让大模型从一个被动的“回答者”，变成了一个主动的“执行者”。然而，仅仅停留在这一层是不够的。因为模型是概率性的，它的每次执行都可能是不一样的，甚至可能是错误的。这就引出了第二层循环。
02 第二层：验证循环
第一层的 Agent 循环能把工作做完，但它并不能保证每次都能把工作做对。在真实业务场景中，我们往往对一致性和正确性有着极高的要求，这时就需要引入第二层验证循环（Verification Loop），它是执行质量的保障。
验证循环的核心逻辑是：在 Agent 输出最终结果之前，增加一个“评分器”（Grader）。这个评分器会根据预设的评估标准检查 Agent 的输出。如果输出不达标，它不会直接报错，而是将评估结果连同反馈意见一起“打回”给模型，让模型重新修改，直到通过验证。
图注：源自 LangChain 博客，验证循环
这个评分器可以是确定性的，如检查代码是否能编译通过；也可以是基于 Agent 的，如使用另一个 LLM 作为裁判，即常说的 LLM-as-a-Judge。
在 LangChain 的生态中，你可以通过 RubricMiddleware 或者在 create_agent上添加 after_agent 钩子来实现这种模式。
回到我们前面提到的“文档 Agent”的例子。为了保证文档质量，在 Agent 提交 PR 之前，验证循环会运行一系列测试：检查所有添加的链接是否都能正常访问，检查所有的 CI（持续集成）流程是否通过。只有所有检查都验证通过，修改才会被真正提交。
引入验证循环是一个典型的“以时间换质量”的策略。它确实会增加每次运行的延迟和成本，但对于大多数生产用例来说，这种策略经过权衡有时是值得的。它就像是给 Agent 配备了一个严厉的 QA（质量保证）工程师，极大地提升了系统的可靠性，让你敢于将 Agent 部署到真实业务流中。
03 第三层：事件驱动循环
前两层循环解决的是“如何把一件任务做好”的问题，但它是被动触发的，需要人手动去唤醒 Agent。一个更高效的 Agent，它应该能主动感知周围的环境，并在合适的时候主动介入。这就需要第三层事件驱动循环（Event-driven Loop）。
这一层的核心是主动执行与生态集成，它将 Agent 连接到更广泛的业务生态系统中。当某个特定的事件发生时，比如系统里上传了一份新文档、到达了预设的定时任务时间或者接收到了一个外部的 Webhook，Agent 就会被自动触发运行。
图注：源自 LangChain 博客，事件驱动循环
叠加这个循环后，Agent 不再是一个你需要手动调用的独立工具，而是变成了一个持续运行的自主系统。
你可以设置一个 Cron 定时任务，让 Agent 每天早上 8 点自动分析昨天的销售数据并生成简报；或者像 openclaw 这样的 Agent 设置“心跳（Heartbeats）”，让 openclaw 变成一个永远在线、主动出击的助手。
在 LangChain 团队内部，他们的“文档 Agent”就是通过一个事件驱动循环运行的。只要有人在内部 Slack 的 #docs-plz 频道里发送了一条消息，系统就会通过 Webhook 自动触发 Agent 去处理这个文档请求。
加入事件驱动循环后，Agent 真正融入了企业的自动化工作流，帮助业务运转。
04 第四层：爬山循环
前三层循环是为了“自动化工作”，而第四层循环则是为了“自动化改进”，称为爬山循环（Hill Climbing Loop）。
在机器学习和优化算法中，“爬山算法”是一种寻找局部最优解的方法。在 Agent 中，爬山循环意味着系统能够从过去的经验中学习，不断优化 Agent 系统自身的表现。
每次 Agent 运行，都会产生一个“轨迹”（Trace）：记录了模型思考的过程、调用了哪些工具、评分器给出了什么反馈等等。这些轨迹数据包含了关于“什么有效、什么无效”的高价值信号。
爬山循环的运作方式是：运行一个专门的“分析 Agent”，让它去审查这些运行轨迹，从中发现规律和问题，并利用这些发现来重写或优化整个系统的配置。 这种优化可以包括：修改提示词、修改工具描述或者调整评分器的标准。
图注：源自 LangChain 博客，爬山循环
在 LangSmith 中，可以使用名为 Engine 的“轨迹分析 Agent” 来实现这第四层循环。
继续以“文档 Agent”为例。LangChain 团队会定期让 Engine 去分析“文档 Agent”的运行轨迹。如果 Engine 发现有多个轨迹都显示“文档 Agent ”在某个特定的工具调用上反复出错，那就可以提交一个问题报告，建议修改那个容易引起误解的提示词或者修复那个有缺陷的工具。
第四层循环设计精妙在于：它的反馈是给向的系统内部，去更新内部的 Agent 循环本身。 这样外层循环的每一次执行，都在让内层循环变得更加高效和聪明。
后续这种自我进化的潜力远不止于修改 Prompt。对于那些有能力运行开源权重模型的团队来说，爬山循环甚至可以与强化学习（RL）微调结合，将轨迹和评估结果作为训练信号，用于提升底层模型的能力。同样，Agent 的外部记忆和检索技能也可以通过这种方式不断迭代。
至此可以总结循环工程的定义：Loop Engineering 是一种 AI Agent 系统设计方法论。它的核心思想是：Agent 的能力边界不由单个模型决定，而由围绕模型所构建的循环层次决定。 具体而言，它将 Agent 系统分解为四个可独立设计、可相互叠加的循环层——执行循环、验证循环、事件驱动循环与爬山循环——每一层都在扩展 Agent 的能力边界：从"能做事"到"做对事"，从"被动响应"到"主动运行"，最终到"持续进化"。
05 LangChain 视角下 OpenClaw 的循环工程
OpenClaw 是一个可以接入 WhatsApp、Telegram 等通讯软件在本地运行的 Agent，虽然与 LangChain 生态相互独立，但它的核心架构设计也印证了 LangChain 提出的这四层循环理念，它的实现与 LangChain 四层循环有对应关系。
第一层对应：Gateway 与 Agent Loop。OpenClaw 的 Gateway 接收来自各种通讯软件的消息，触发 Agent Loop。在这个循环中，Agent 结合历史对话上下文，调用内置的 Shell、文件系统、浏览器控制等工具，完成从搜索资料到执行命令的各种任务。
在 OpenClaw 的 src/agents/embedded-agent-runner/run/ 目录下，实现了 Agent 的核心运行逻辑。
第二层对应：基于 sessions_spawn 的多智能体协作。OpenClaw 真正实现验证循环的核心机制是 sessions_spawn 工具。主 Agent 完成初稿后，可以通过调用 sessions_spawn 来启动一个独立的子 Agent 会话，专门扮演"评分器（Grader）"的角色，对主 Agent 的输出进行审查和评估，并将反馈结果返回给主 Agent 进行修改。
sessions_spawn 的参数类型定义在 src/agents/acp-spawn.ts 中，其 SpawnAcpParams 类型明确包含了 model（子 Agent 使用的模型）和 thinking（思考深度）两个关键参数。部分代码如下：
export type SpawnAcpParams = { task: string; label?: string; agentId?: string; resumeSessionId?: string; model?: string; thinking?: string; runTimeoutSeconds?: number; cwd?: string; mode?: SpawnAcpMode; thread?: boolean; sandbox?: SpawnAcpSandboxMode; streamTo?: SpawnAcpStreamTarget; attachments?: AcpTurnAttachment[]; };
第三层对应：Heartbeat（心跳）与 Cron 机制。这是 OpenClaw 最具特色的功能之一。它的 Heartbeat 机制允许 Agent 每隔一段时间（如 30 分钟）自动唤醒，读取 HEARTBEAT.md 文件中的指令，主动检查邮件、日程或后台任务状态，并在需要时主动向用户发送通知。
在 src/cron/service/jobs.ts 中，OpenClaw 实现了强大的定时任务调度逻辑，包括 CronJob 的创建、验证和执行。结合 Gateway，这些 Cron 任务能像用户消息一样发布到同一个消息总线，触发 Agent 执行后台工作流。部分代码如下：
/** Creates a normalized cron job row from public add input and computes its initial schedule. */ export function createJob(state: CronServiceState, input: CronJobCreate): CronJob { const now = state.deps.nowMs(); const id = crypto.randomUUID(); const schedule = input.schedule.kind === "every" ? { input.schedule, anchorMs: resolveEveryAnchorMs({ schedule: input.schedule, fallbackAnchorMs: now, }), } : input.schedule.kind === "cron" ? (() => { const explicitStaggerMs = normalizeCronStaggerMs(input.schedule.staggerMs); if (explicitStaggerMs !== undefined) { return { input.schedule, staggerMs: explicitStaggerMs }; } const defaultStaggerMs = resolveDefaultCronStaggerMs(input.schedule.expr); return defaultStaggerMs !== undefined ? { input.schedule, staggerMs: defaultStaggerMs } : input.schedule; })() : input.schedule; …… }
第四层对应：基于纯文本配置与轨迹记录的持续迭代。OpenClaw 的记忆和配置如 AGENTS.md、SOUL.md、TOOLS.md 都是纯文本的 Markdown 文件。此外，它在 src/trajectory/runtime.ts 中实现了完整的运行轨迹（Trajectory）记录机制。
src/trajectory/runtime.ts 会将 Agent 的每次运行事件（包括工具定义、截断状态等）详细记录到日志文件中。
虽然它目前没有内置像 LangSmith 那样自动化的分析 Agent，但这种详细的轨迹记录机制和纯文本的架构，让开发者（或更高阶的监控脚本）可以非常容易地审查 Agent 的行为轨迹，并通过 Git 版本控制来不断迭代和优化 Agent 的 Prompt 与工具定义，从而实现系统的逐步进化。部分代码如下：
const buildEventLine = (type: string, data?: Record<string, unknown>): string | undefined => { const nextSeq = seq + 1; const sourceSeq = writer.nextSourceSeq?.() ?? nextSeq; const event: TrajectoryEvent = { traceSchema: "openclaw-trajectory", schemaVersion: 1, traceId, source: "runtime", type, ts: new Date().toISOString(), seq: nextSeq, sourceSeq, sessionId: params.sessionId, sessionKey: params.sessionKey, runId: params.runId, workspaceDir: params.workspaceDir, provider: params.provider, …… };
06 构建循环后人机如何协作？
在探讨了高度自动化的循环之后，需要澄清的是：自动化并不意味着将人类完全排除在外。相反，优秀的循环工程设计，是为了让人类在最需要的地方发挥不可替代的价值。
在 Agent 的不同循环层级中，人机协作的模式是动态变化的：
- 在 Agent 循环中：充当“授权者”与“向导”。 当 Agent 遇到模棱两可的指令，或者需要执行高风险操作（如删除数据库、进行财务转账）时，必须暂停循环，请求人类介入。此时，人类的判断是不可或缺的安全阀。
- 在验证循环中：充当“最终裁判”。 自动化的评分器（Grader）可以检查代码是否报错、链接是否有效，但只有人类才能敏锐地察觉到一篇文章的语气是否契合目标受众，或者一个设计方案是否符合品牌调性。对于涉及审美、价值观或复杂业务逻辑的输出，人类是最好的 Grader。
- 在事件驱动循环中：充当“规则制定者”。 Agent 虽然可以自动运行，但“何时运行”、“触发条件是什么”仍然需要人类根据业务流程来定义。人类负责构建生态系统，Agent 负责在其中流转。
- 在爬山循环中：充当“进化审批者”。 系统虽然能通过分析轨迹提出优化建议（如修改 Prompt），但这些系统级的变更在部署前，通常需要人类工程师的复核，以确保进化方向不偏离最初的业务目标。
在设计 Agent 系统时，我们需要清晰地界定人机协作边界：
- 什么情况下不需要人参与？ 对于确定性强、容错率高、且评估标准客观的任务（如数据清洗、格式转换、日常巡检），应尽可能交由 Agent 独立完成。此时，系统的重点在于提高效率和降低成本。
- 什么情况下必须有人参与？ 涉及高风险决策、道德伦理判断、创意性评估，以及缺乏明确评估标准的开放性任务时，必须保持“人在回路（HITL）”。
- 如何平滑过渡？ 理想的 Agent 系统应该具备“置信度评估”能力。当 Agent 对当前任务的把握度高时，自动执行；当置信度低于某个阈值或者遇到未知的边界情况时，系统应能优雅地“降级”，主动向人类求助。随着爬山循环的不断迭代，Agent 处理复杂情况的能力提升，人类介入的频率可以逐渐降低，实现从“人类主导”到“人类监督”的平滑过渡。
07 结语
正如微软 CEO 纳德拉所言，在 AI 时代企业竞争的焦点正在发生转移。那些能够尽早构建起"学习循环"的公司，将人类的判断力与大模型的"Token 资本"深度融合并让它们共同复利增长，才能建立自己的护城河。
这里的"学习循环"，正如爬山循环。它让 Agent 系统不再是一个静态的工具，而是一个随着使用不断成长的有机体。每一次运行产生轨迹，每一条轨迹沉淀信号，每一个信号驱动进化，每一次进化让下一次运行更好。这个飞轮一旦转动，便会形成难以复制和追赶的能力壁垒。
构建更高效的 Agent，答案隐藏在精心设计的循环叠加之中。从现在开始重新审视你的 Agent 架构，思考如何为其注入验证的严谨、事件驱动的活力，以及自我进化的智慧。
参考链接
[1] "LangChain Blog. "The Art of Loop Engineering"."
https://www.langchain.com/blog/the-art-of-loop-engineering
[2] "OpenClaw"
[3] "A frontier without an ecosystem is not stable"
https://x.com/satyanadella/status/2066182223213293753
(如果这篇文章对您有所帮助，请帮忙 关注 并 转发，谢谢！)
