最近 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"

https://docs.openclaw.ai/

[3] "A frontier without an ecosystem is not stable"

https://x.com/satyanadella/status/2066182223213293753

(如果这篇文章对您有所帮助，请帮忙 关注 并 转发，谢谢！)