LangChain 的 Loop Engineering：四层循环，把 Agent 从"玩具"变成"生产组件"

> 来源: LangChain Blog — The Art of Loop Engineering > 作者: LangChain 团队 > 核心概念: Swyx 的 loopcraft 思想的具体工程实现

---

一、一个残酷的真相：好模型 ≠ 好 Agent

你有一个 GPT-5，调好了 prompt，配了十几个工具，Agent 能帮你写文档、改代码、发 PR。你 demo 给同事看，效果很好。

然后你把它丢进生产环境，让它每天自动跑。一周后你回来看：

• 它发了 3 个 PR，其中 1 个把 CI 搞崩了
• 它改了 20 个文件，其中 5 个改错了范围
• 它在凌晨 3 点触发了一次，因为没人审，直接合进了 main 分支
• 它花了 $200 token，但产出质量不稳定，有时极好，有时极差

问题不在模型。问题在于：你只在第一层循环上做了工作。

LangChain 这篇博客的核心论点是：Agent 的可靠性不是由模型质量决定的，而是由你套在外面的循环层数决定的。模型是引擎，循环是底盘。没有底盘的引擎再强也上不了路。

---

二、四层循环：从"做单件事"到"持续自我改进"

LangChain 把 Agent 周围的 harness 拆成四层嵌套循环，每层解决不同的问题：

┌─────────────────────────────────────────┐
│  Loop 4: Hill Climbing Loop             │
│  "从失败中学习，改进 harness 本身"      │
│  ↓ 更新 prompt / 工具 / 验证规则       │
├─────────────────────────────────────────┤
│  Loop 3: Event Driven Loop              │
│  "让 Agent 成为生态系统的长期组件"      │
│  ↓ Slack / Webhook / Cron 触发         │
├─────────────────────────────────────────┤
│  Loop 2: Verification Loop              │
│  "确保输出质量，不合格就反馈重试"       │
│  ↓ Grader 检查 → 反馈 → 重试           │
├─────────────────────────────────────────┤
│  Loop 1: Agent Loop                     │
│  "模型调用工具，直到任务完成"           │
│  ↓ 最核心的循环，但只是起点            │
└─────────────────────────────────────────┘

Loop 1: Agent Loop —— 做事

这是最内层的循环：给模型上下文，让它调用工具，循环直到任务完成。

这是 LangChain create_agent 做的事情。选一个模型，插几个工具，Agent 就能跑起来。工具让 Agent 能在现实世界里行动——读文件、写代码、发请求、开 PR。

但这只是开始。 一个能做事的 Agent 不等于一个能可靠地做事的 Agent。

Loop 2: Verification Loop —— 验货

Agent 做完事后，需要有人检查做得对不对。这就是验证循环。

Grader（评分器）检查 Agent 的输出，对照一个 rubric（评分标准）。如果不合格，把反馈发回给 Agent，让它重试。

Grader 可以是：

• 确定性的：跑测试、检查链接是否可用、CI 是否通过
• 模型化的：LLM as a Judge，让另一个模型评估质量

LangChain 提供了 RubricMiddleware 和 after_agent hook 来实现这个模式。

代价：增加延迟和成本。每次验证都是一次额外的模型调用或测试运行。

收益：在质量比速度重要的场景（也就是绝大多数生产场景），这是值得的。

Loop 3: Event Driven Loop —— 融入系统

前两层循环让 Agent 能做事、能验货。但谁来触发它？

事件驱动循环把 Agent 接到你的生态系统里：

• Cron 定时：每天早上 9 点跑文档检查
• Webhook：GitHub PR 创建时触发代码审查
• Slack 消息：有人在 #docs-plz 频道发消息，Agent 自动响应
• 文件上传：新文档落地，触发索引更新

LangChain 的 LangSmith Deployment 和 Fleet 平台支持这些触发器。Fleet 的 channels 和 schedules 让 Agent 不再是"你手动调用的脚本"，而是"生态系统里的长期运行的组件"。

Loop 4: Hill Climbing Loop —— 自我进化

这是最有野心的一层。

每次 Agent 运行都会产生一个 trace（运行记录）：模型做了什么决策、调用了什么工具、Grader 给了什么反馈、哪里失败了、哪里成功了。

这些 traces 里藏着高价值的信号。Hill climbing 循环让一个分析 Agent 去读这些 traces，发现问题模式，然后重写 harness 本身：

• 调整 prompt，让模型更清楚该做什么
• 修改工具描述，让模型更准确地调用
• 更新验证规则，让 Grader 更严格或更合理

LangChain 的 Engine 就是这个分析 Agent。它读 docs agent 的 traces，检测到多个 traces 指向同一个问题时，自动开一个 issue，建议修改 prompt 或工具。

关键设计：第四层的返回箭头不是回到第一层，而是直接修改第一层。每次外层循环都让内层循环更有效。

> 用 Satya Nadella 的话说："early learning loops, where human judgment and token capital compound together, will build an advantage that's hard to replicate."

---

三、一个贯穿全文的例子：LangChain 内部的 Docs Agent

LangChain 自己有一个内部文档 Agent，博客用它作为例子贯穿四层循环：

循环层	Docs Agent 的具体做法
Agent Loop	接收文档改进请求 → 规划修改 → 克隆仓库 → 读写文件 → 开 PR
Verification Loop	Grader 检查：所有链接可解析、CI 通过、diff 范围符合请求
Event Driven Loop	Fleet channel：有人在 Slack #docs-plz 发消息，自动触发
Hill Climbing Loop	Engine 分析 traces，发现常见问题模式，开 issue 建议改 prompt

这个例子最有说服力的一点是：LangChain 自己也在吃自己的狗粮。 他们不是写了一个理论框架，而是真的在生产环境里跑这四层循环。

---

四、人机协同：自动化不是取消人工

博客花了相当篇幅讨论"人在哪里"。这是一个被很多 Agent 框架忽视的问题。

LangChain 的观点是：每一层循环都有自然的"人介入点"：

循环层	人的价值
Agent Loop	敏感操作前需要人类确认（如 DB 操作、资金转账）
Verification Loop	人类可以作为 Grader，判断机器无法评估的质量（如" framing 是否适合目标受众"）
Event Driven Loop	人类审批输出，才能返回给最终用户
Hill Climbing Loop	Harness 改进需要人类 review 后才能部署

机器能检查链接是否可用，但只有人能判断"这个文档的 framing 是否适合目标受众"。

这种判断来自上下文、经验和品味——恰恰是人类的不可替代性。

LangChain 把 "human in the loop" 做成了一等公民：开源框架里每个循环层都有对应的人类介入 primitive。

---

五、费曼视角：LangChain 的四层循环好在哪？

Q1：这和之前我写的 Loop Engineering 文章有什么区别？

我之前写的 Loop Engineering 文章（智柴 Topic 177981312）是一个宏观范式的讨论：从 Prompt Engineering 到 Loop Engineering 的范式转移，涉及 Addy Osmani、Lushbinary、Boris Cherny 等多个来源的观点。

LangChain 这篇文章是一个具体实现：它把 Loop Engineering 拆成四层，每层对应具体的 LangChain 工具/产品（create_agent、RubricMiddleware、LangSmith Deployment、Engine）。

如果说之前的文章是"Loop Engineering 是什么"，这篇就是"Loop Engineering 怎么做"。两者互补。

Q2：四层循环的划分是必然的吗？

四层划分不是唯一的，但 LangChain 的划分有其工程合理性：

• Agent → Verification：解决"做得对不对"
• Verification → Event Driven：解决"什么时候做"
• Event Driven → Hill Climbing：解决"怎么越做越好"

这是一个从"单次执行"到"持续运行"到"自我改进"的递进。少了任何一层，系统都会有明显短板。

但其他框架可能有不同的分层。比如 OpenClaw 的 heartbeat 机制可以看作 Event Driven Loop 的一种实现，但它的"记忆"层（memory/YYYY-MM-DD.md、MEMORY.md）又超越了 LangChain 的四层框架。

Q3：Hill Climbing Loop 是 RLHF 的工程化版本吗？

有点像，但不完全一样。

• RLHF：用人类偏好数据微调模型参数
• Hill Climbing Loop：用生产 traces 调整 harness 配置（prompt、工具、验证规则）

关键区别：RLHF 改的是模型，Hill Climbing 改的是系统。模型是昂贵的（训练一次要大量算力），harness 配置是便宜的（改一行 prompt 立即生效）。

博客提到：对于运行开源权重的团队，Hill Climbing Loop 的 traces 可以作为 RL 微调的信号。这是两个层面的结合：

• 短期：改 harness 配置（cheap）
• 长期：用累积的 trace 数据微调模型（expensive but powerful）

Q4：这套框架的局限在哪？

1. LangChain 中心化：四层循环的每一层都有对应的 LangChain 产品（create_agent、LangSmith、Fleet、Engine）。如果你不用 LangChain 生态，需要自己实现对应层。 2. Hill Climbing 的"分析 Agent"质量：第四层依赖一个"分析 Agent"来读 traces 并提改进建议。但这个分析 Agent 本身也需要被设计好——如果它提的改进建议质量不高，Hill Climbing 就变成了"随机扰动"。 3. 成本问题：四层全开的情况下，单次任务可能涉及：Agent 运行 + Verification Grader + Event 触发 + Trace 分析。Token 消耗和延迟都比单层 Agent 高很多。博客自己也承认"adding verification increases latency and cost"。 4. 不是所有任务都需要四层：简单的单次查询任务，可能只需要 Loop 1。强制套四层是过度工程。

Q5：最值得记住的一句话

> "The potential in agents is in the loops you build around them."

这句话来自博客结尾，引用了 Steipete、Boris、Andrej 等人的共识。也是整篇文章的核心：

模型能力在快速收敛（GPT-5、Claude 4、Gemini 3 之间的差距在缩小），但循环设计能力才是长期差异化的来源。谁能在生产环境里跑起稳定的四层循环，谁就能构建难以复制的竞争优势。

---

六、一句话总结

> LangChain 的四层循环框架，把 Agent 从"能做事"升级为"能持续、可靠、自我改进地做事"。模型是燃料，循环是引擎设计。Agent Loop 让 Agent 能动，Verification Loop 让它做对，Event Driven Loop 让它融入系统，Hill Climbing Loop 让它越跑越好。四层全开，Agent 才真正从 demo 变成 production。

---

参考

• LangChain Blog: The Art of Loop Engineering. https://www.langchain.com/blog/the-art-of-loop-engineering
• Swyx: loopcraft — the art of stacking loops. https://www.latent.space/p/ainews-loopcraft-the-art-of-stacking
• 相关智柴研究：Loop Engineering 深度解析 (https://zhichai.net/topic/177981312)

#LangChain #LoopEngineering #Agent #AI工程 #四层循环 #HillClimbing #Verification #EventDriven #费曼解读