原作者：Sydney Runkle
原文发布日期：2026 年 6 月 16 日
译文说明：本文为中文翻译，原文链接见文末。
Agent 之所以有用，是因为它们能通过在真实世界中采取行动来帮助我们自动化工作。但要让 Agent 稳定地完成有价值的工作，光有一个好模型还不够：你还需要一个经过精心设计、适配具体任务集合的 harness。
Agent 的核心算法很简单：给 LLM 上下文，让它在循环中调用工具，直到任务完成。这是最基础的循环。但支撑 Agent 的循环远不止这一种。Swyx 最近写了一篇很好的文章，讨论 “loopcraft: the art of stacking loops”，也就是通过堆叠和扩展循环来构建更有效的 Agent。
下面是我们对这套循环栈的理解，以及如何用 LangChain primitives 为每一层加上相应的工程能力。
Loop 1：The Agent
.png)
从本质上说，Agent 就是一个模型不断调用工具，直到任务完成。
这正是 LangChain 的 create_agent 提供的能力。你可以选择任意模型，接入工具，然后得到一个可以运行的 Agent loop。工具（Tools）让 Agent 拥有在真实世界中采取行动的能力。
以我们的内部文档 Agent 为例，后文也会继续用它作为贯穿全文的例子。在第一层循环中，它接收一个文档改进请求，模型会规划并起草修改，然后调用工具去克隆仓库、读取文件、编写文档、打开 Pull Request 等。
Level 2：Verification loop
.png)
Agent loop 可以把事情做完，但它并不总能在第一次尝试时就产出正确且一致的结果。当一致性很重要时，把它包在一个 Verification loop 里通常很有价值：Verification loop 会检查输出，如果结果不达标，就把反馈重新交给模型。
Verification loop 会增加一个 grader。这个 grader 会根据一套标准检查 Agent 的输出；如果检查失败，就把结果和反馈返回给模型。grader 可以是确定性的，也可以是 Agentic 的。例如，“LLM as a judge” 就是一个典型例子。
RubricMiddleware 可以处理这种模式，你也可以在 create_agent 上通过 after_agent hook 自己接起来。
回到文档写作 Agent 的例子，grader 会在每次尝试后运行测试，检查所有链接是否可访问、所有 CI 检查是否通过，以及 diff 是否只覆盖用户实际请求的范围。对于这类错误，不需要 human review也能被自动发现。
