Loop Engineering：当你不再亲自提示 Agent，而是设计一套系统去提示它
引言：一句断言引发的范式讨论
2026 年 6 月，Peter Steinberger 发了一句被广泛转引的话：“你不该再亲自给编码 Agent 写提示词了。你应该设计一套能给 Agent 写提示词的循环系统。” Anthropic Claude Code 负责人 Boris Cherny 几乎同时给出了呼应性的表述：“我已经不再直接提示 Claude 了。我让循环系统去跑，它们负责提示 Claude、判断下一步该做什么。我的工作是写循环。”
Google 工程师 Addy Osmani 随后在《Loop Engineering》一文中把这个现象命名并系统化，他给出的定义相当克制而精确：Loop Engineering 就是把"你自己去提示 Agent"这件事替换掉——你转而设计一套系统，让这套系统去替你提示 Agent。这不是又一次"发明一个新词包装旧概念"的营销行为(虽然 Osmani 本人也坦承自己对此保持一定怀疑，并特别提醒要警惕 token 成本失控的风险)，而是反映了一个正在发生的、可观察的产品能力迁移：过去你想要一个"循环"，得自己手写一堆 Bash 脚本并终生维护；现在 Codex App 和 Claude Code 已经把循环所需的核心原语直接内置进产品本身。
几乎同一时期，LangChain 也发表了《The Art of Loop Engineering》，从架构角度提出了一个更具普适性的分析框架——四层 Loop 堆叠模型，用来解释"同样是模型在循环里调用工具，为什么有的 Agent 系统能持续产生价值，有的却停留在演示阶段"。本文将结合这两条独立但高度呼应的论述,系统梳理 Loop Engineering 的概念边界、核心组成要素、架构模型,以及这套范式转移背后不会消失的风险。
一、概念界定：三层分工，逐级抬升的抽象粒度
要理解 Loop Engineering 的位置，需要先把它放进一个更完整的坐标系里，与此前已经成型的 Prompt Engineering、Harness Engineering 做对比。Osmani 把 Harness Engineering 定义为"搭建单个 Agent 运行所在的环境"，而Loop Engineering 是架在 Harness 之上的一层——它是那个带定时器运行的 Harness,会自己派生小助手,还会自我反哺。
| 维度 | Prompt Engineering | Harness Engineering | Loop Engineering |
|---|---|---|---|
| 关注对象 | 单次对话中一句提示词该怎么写 | 单个 Agent 运行所在的环境(工具、上下文、执行逻辑) | 一整套自动发现工作、派单、检查、记录、决策的系统 |
| 触发方式 | 人工每轮手动输入 | 人工启动单次运行，运行时环境由 Harness 支撑 | 系统按计划/事件自动触发,人不再逐轮介入 |
| 时间尺度 | 单轮对话 | 单次任务的一次运行 | 持续运行、跨会话、无限接续的运行周期 |
| 抽象粒度 | 最细粒度：文字表达 | 中粒度：单个运行时的软硬件配置 | 最粗粒度：多个 Harness 实例的调度与协同系统 |
| 人的角色 | 逐轮对话者 | 环境设计者 | 系统设计者，退出逐轮循环 |
三者是层级递进而非替代关系——写好 Prompt 的能力在 Loop 内部依然重要(循环最终还是要生成提示喂给模型)，搭好 Harness 也是 Loop 能够稳定运行的前提；Loop Engineering 只是把工作重心从"这一轮该说什么"抬升到了"这套系统该如何自己决定说什么、什么时候说"。
二、为什么现在成为核心议题
LangChain 对这一转变给出了一个精炼的技术判断：Agent 的核心算法本身极其简单——给 LLM 一段上下文，让它在循环里反复调用工具直到任务完成，这就是最基础的那个循环。但这个基础循环本身几乎不能解释为什么不同团队搭出来的 Agent 系统在生产环境中的可靠性天差地别——真正决定价值上限的，是在这个最基础循环之上,又叠加了哪些循环。这与 swyx 提出的"loopcraft"(堆叠循环的艺术)是同一个观察角度。
而 Osmani 的观察补上了另外半块拼图——这件事之所以能在 2025-2026 年这个时间点集中爆发，一个关键原因是循环所需的原语正在从"你自己写的一堆脆弱脚本"变成"产品内置能力"。一年前，如果你想要一个自动运行的循环，你得自己写 Bash 脚本、自己维护定时任务、自己处理并发冲突，这套东西完全属于你自己,极其脆弱。而现在，Steinberger 列出的循环所需能力几乎精确地映射到了 Codex App 里,又几乎同样精确地映射到了 Claude Code 里——一旦你发现两个不同厂商的产品长出了同一套"形状"，你就不再需要争论"到底该用哪个工具"，而是可以直接设计一套不依赖具体工具的循环。
三、核心组成要素：五个部件加一处记忆
Osmani 给出了一个便于记忆的框架——一个循环需要五个部件，再加一个用来记事的地方：
| 部件 | 在循环中的职责 | Codex App 中的实现 | Claude Code 中的实现 |
|---|---|---|---|
| Automations（自动化触发） | 按计划自动发现工作、做分诊 | Automations 标签页：选项目、写提示、定周期、定环境；结果进入 Triage 收件箱；/goal用于"跑到完成为止" | 定时任务与 Cron、/loop、/goal、Hooks、GitHub Actions |
| Worktrees（工作树隔离） | 隔离并行运行的多个 Agent，避免文件冲突 | 每个会话线程内置 Worktree 支持 | git worktree、--worktree参数、子智能体上的isolation: worktree配置 |
| Skills（技能沉淀） | 把项目知识写下来，避免每轮从零猜测 | Agent Skills，以SKILL.md存放，用$name调用或按描述自动匹配 | 同样采用SKILL.md格式的 Agent Skills |
| Plugins & Connectors（插件与连接器） | 基于 MCP 把 Agent 接入你已有的工具生态 | Connectors(MCP)+ 用于分发的 Plugins | MCP Servers + Plugins |
| Sub-agents（子智能体分工） | 一个负责想点子，另一个负责检查 | 在.codex/agents/下以 TOML 定义 Subagents | 在.claude/agents/下定义 Task Subagents,以及 Agent Teams |
| State（外部持久化状态） | 记录已完成的和待完成的事项 | Markdown 或经由 Connector 连接的 Linear 看板 | AGENTS.md、进度文件（Markdown），或通过 MCP 连接的 Linear |
值得单独展开的是为什么状态必须落在磁盘或看板上,而不能只留在对话上下文里：模型在每次运行之间会彻底遗忘一切,如果"已经做了什么、接下来该做什么"这类信息只存在于某一次对话的上下文窗口里,那么循环的下一次触发就等于从零开始。让状态活在文件系统或外部看板里，是所有长时程运行 Agent 共同依赖的同一个技巧——模型会遗忘，仓库不会。
一个组合起来的循环大致长这样：一个自动化任务每天早上在仓库里运行一次，它调用一个"分诊技能"读取昨天的 CI 失败记录、未关闭的 Issue、最近的提交，把发现写入一个 Markdown 文件或 Linear 看板；对于每一个值得处理的发现，系统打开一个隔离的 Worktree，派一个子智能体起草修复方案，再派另一个子智能体依据项目技能文档和现有测试对这份草稿做审查；连接器负责让循环自己开 PR、更新工单;循环处理不了的部分,进入人工的 Triage 收件箱;状态文件是整套系统的脊梁——它记住了尝试过什么、通过了什么、还剩下什么,让明天早上的运行能从今天停下的地方接着走。你只设计了这套系统一次，之后再也没有亲自提示过其中任何一步——这正是 Steinberger 那句断言的具体落地形态。
其中两个部件值得额外强调实现细节：
/goal与/loop的区别：/loop是按固定节奏反复运行；/goal则是持续运行直到一个你写下的条件真正成立为止——每一轮结束后,一个独立的小模型会检查任务是否真的完成了,而不是让写代码的那个模型给自己打分。你可以给它一句类似"test/auth目录下所有测试通过且 lint 无报错"这样的条件,然后就可以离开。Codex 里同名的/goal原语做的是同一件事,支持暂停、恢复、清空。- Skill 与 Plugin 的关系：Skill 是撰写格式,Plugin 是分发方式。当你想跨仓库共享一个 Skill,或把几个 Skill 打包在一起时,你会把它们打包成一个 Plugin——这一点在 Codex 和 Claude Code 中是一致的。
四、LangChain 的四层 Loop 堆叠模型
如果说 Osmani 的五要素框架回答的是"一个循环需要哪些零件"，LangChain 的四层堆叠模型回答的则是"这些循环彼此之间是怎样一层包一层地组织起来的"。LangChain 用其内部的文档撰写 Agent 作为贯穿全文的示例，逐层拆解：
| 层级 | 核心动作 | 解决的问题 | 代表机制/工具 |
|---|---|---|---|
| Loop 1：Agent Loop | 模型反复调用工具直到任务完成 | 让 Agent 具备执行真实动作的基本能力 | create_agent，任意受支持的模型 |
| Loop 2：Verification Loop | 用评分器(Grader)对输出打分，不达标则带着反馈重试 | 保证输出质量与一致性,而非"跑完就算完" | RubricMiddleware,或在create_agent上挂after_agentHook |
| Loop 3：Event-Driven Loop | 由真实事件(新文档到达、定时触发、Webhook)驱动 Agent 运行 | 让 Agent 成为持续在后台运行的系统组件,而非需要人工调用的工具 | LangSmith Deployment 的 Cron/Webhook 触发,或 Fleet 的 Channels/Schedules |
| Loop 4：Hill-Climbing Loop | 分析 Agent 运行轨迹(Trace),用发现反哺、重写上层 Harness 配置 | 自动化"改进"本身,而不只是自动化"执行" | LangSmith Engine(轨迹分析 Agent) |
第一层是最基础的循环——一个文档改进请求进来，模型规划并起草改动，调用工具克隆仓库、读写文件、开 PR。第二层给这个循环加上一个评分器：检查所有链接是否可解析、CI 是否通过、diff 是否只覆盖了被要求的范围，不达标就带着具体反馈打回重试——评分器既可以是确定性规则，也可以是 LLM-as-judge 这类"用模型评判模型"的机制,代价是每次运行的延迟和成本都会上升，但在质量优先于速度的多数生产场景中，这个代价是值得付出的[ref:6]。第三层把 Agent 接入真实事件流——在 LangChain 的例子里，团队在内部 Slack 的#docs-plz频道里发一条消息就能触发文档 Agent 运行，Agent 不再是被人工调用的工具，而是持续运行在更大系统内部的一个组件。
第四层是四层里"最容易被忽视、却可能最重要"的一层：每一次 Agent 运行都会产生一份轨迹记录（模型做了什么、调用了哪些工具、评分器给出了什么反馈）,这些轨迹里蕴含着关于"哪里在起作用、哪里没起作用"的高价值信号。Hill-Climbing Loop 用一个专门的分析 Agent 去处理这些轨迹，并用分析结果重写 Harness 的配置——可能是调整 Prompt 或工具，也可能是调整评分器本身。
这里有一个容易被误解的细节需要特别澄清：这四层循环之间不是简单的"外层循环转一圈之后绕回顶部重新开始"，而是外层循环的反馈箭头会直接伸进内层循环内部,对其进行更新。用 LangChain 原文的表述——“这个反馈箭头不只是绕回顶部,它会直接伸进去,更新 Agent Loop 本身”，每一轮外层循环的运转，都让它所包裹的内层循环变得更有效[ref:6]。这与传统"重试循环"的本质区别在于：传统重试只是让系统再跑一次同样的逻辑，而 Hill-Climbing Loop 改变的是逻辑本身。
LangChain 还提出了一个值得关注的延伸方向：目前 Hill-Climbing Loop 主要用于调整 Prompt 和工具配置——这是最容易改动的部分，但绝不是唯一选项。对于使用开源权重模型的团队，这一层完全可以进一步反哺强化学习微调，把轨迹或评测结果本身作为训练信号去改进模型；同样的思路也可以用来改进记忆机制和检索到的技能库——循环是一种模式，具体优化什么，取决于你自己的选择。
五、人在回路中的位置：自动化不等于移除人类
一个常见的误解是,循环工程意味着把人类完全排除在决策之外。LangChain 明确反驳了这一点：自动化不意味着把人类从循环中移除,而是把人类监督点精确安放在四层循环各自恰当的位置上。一个自动化的评分器可以检查链接是否可解析,但要判断"这段文案对目标读者的语气对不对",还是需要人。这种依赖上下文、经验和判断力的判断,正是人工评审真正有价值的地方。
具体的落点可以逐层安放：
- 在Agent Loop层，对敏感操作(金融交易、数据库写操作等)要求人工确认后才能真正执行工具调用;
- 在Verification Loop层，针对敏感工作流,让人类本身充当评分器,而不是完全交给自动化规则或 LLM 评判;
- 在Event-Driven Loop层,在结果真正返回给终端用户之前,保留一道人工审批环节;
- 在Hill-Climbing Loop层，对 Harness 的改动(Prompt、工具、评分器的调整)在真正上线前,经过人工评审。
这也解释了 Loop Engineering 与"单纯的定时任务/Cron Job"之间的本质区别——一个 Cron Job 只是让同一段逻辑按固定频率重复执行，而一套真正的 Loop 包含了状态记忆、验证反馈、子智能体分工、以及可以插入人工监督点的分层结构,这些结构性要素才是让循环具备"自我纠错、自我改进"能力的关键,而不只是"自动重复"本身。
六、工程实践视角与风险
6.1 Token 成本：自主性越强，消耗越难预测
Osmani 特别提醒,要警惕 Loop 带来的 Token 成本问题——一旦系统开始自己决定"要不要多跑一轮"“要不要多派一个子智能体去验证”，使用模式在"Token 富裕"和"Token 贫乏"两种场景下会呈现出截然不同的面貌。子智能体的引入尤其值得警惕——每多引入一个负责验证的子智能体，就意味着多一次独立的模型调用和工具调用开销，这笔支出只应该花在"第二意见确实值得付费"的地方，而不是默认给每个环节都配一个验证者。同理，Verification Loop 引入的评分反馈机制，本质上是用延迟和成本去换取质量的确定性,这个权衡在质量优先的生产场景中通常值得,但绝非没有代价。
6.2 三个随循环变强反而加剧的问题
Osmani 指出一个反直觉的现象：循环设计得越好，以下三个问题反而不会消失，甚至会变得更尖锐——
- 验证责任依然落在人身上：一个无人值守运行的循环，同时也是一个无人值守犯错的循环。把制作者和验证者拆成两个子智能体的全部意义,正是为了让循环所说的"完成了"这句话真正有意义——但即便如此，"完成"仍然只是一种声明，而不是证明。
- 理解债务(Comprehension Debt)会随自动化提速而加剧：循环交付你没有亲自写过的代码的速度越快，"实际存在的代码"与"你真正理解的代码"之间的落差就扩张得越快。除非你真的去读循环产出的东西，否则这个落差不会自己消失。
- “认知投降”(Cognitive Surrender)的风险：当循环自己运转起来之后，人会很自然地产生一种诱惑——不再对产出保持自己的判断力，全盘接受循环给出的结果。设计一套循环，如果带着判断力去做，是理解债务问题的解药；如果只是为了逃避思考,同样的动作反而会成为放大器——同一个动作，截然相反的结果，区别只在于设计者本人的意图。
6.3 落脚点：留在系统里的工程师
Osmani 给出的收尾判断值得完整引用其精神：如果他不亲自审查代码,或者完全依赖自动化循环去修复问题,他的产品质量一定会下降,他很可能陷入一种越陷越深的下降螺旋[ref:1]。这也是为什么他强调,搭建循环并不会让工作变得更轻松——Cherny 那句话的重点不是"工作变简单了",而是"杠杆点移动了"。这恰恰是 Loop Engineering 比 Prompt Engineering 更难、而不是更容易的原因所在。
两个人可以搭建出完全相同的循环，却得到截然相反的结果：一个人用它在自己深刻理解的工作上跑得更快;另一个人用它彻底逃避理解这份工作。循环本身分辨不出这两者的差异——只有设计者自己知道。这正是本文想传达的核心立场：Loop Engineering 的价值,不在于让工程师从系统里消失,而在于把工程师的角色从"逐轮对话的操作者",提升为"设计反馈闭环、并始终亲自坐镇校验的架构师"。
结论
Loop Engineering 之所以值得认真对待，并不是因为它发明了什么全新的技术原语——Automations、Worktrees、Skills、Sub-agents、MCP 连接器，这些能力大多早已存在。真正发生变化的，是这些原语第一次被系统性地组织进同一套闭环,并且从"你自己写的一堆脆弱脚本"变成了主流产品的内置能力,让"设计一套系统去提示 Agent"这件事,第一次具备了不依赖单一工具、可以跨产品迁移的可复制性。
LangChain 的四层堆叠模型则提供了一套更具普适性的分析语言，帮助我们理解不同复杂度的 Agent 系统之间到底差在哪一层——是缺少验证反馈、还是没有接入真实事件流、还是压根没有一个机制去把运行轨迹里的信号反哺回配置本身。这两条独立提出、却高度呼应的论述共同指向同一个结论：在模型能力短期趋于稳定的窗口期，决定 Agent 系统价值上限的变量，正在从"这一轮提示词写得好不好"迁移到"围绕这个循环的系统设计得好不好"。
但正如 Osmani 反复强调的，这次范式转移的重点不是"工作变简单了"，而是"杠杆点移动了"——验证的责任、理解代码库的义务、保持判断力而不滑向认知投降的自觉，这些从未被自动化真正取代过。设计循环，但要把自己设计成始终留在系统里的那个工程师，而不只是那个按下"开始"按钮的人。
