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 EngineeringHarness EngineeringLoop 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 ActionsWorktrees工作树隔离隔离并行运行的多个 Agent避免文件冲突每个会话线程内置 Worktree 支持git worktree、--worktree参数、子智能体上的isolation: worktree配置Skills技能沉淀把项目知识写下来避免每轮从零猜测Agent Skills以SKILL.md存放用$name调用或按描述自动匹配同样采用SKILL.md格式的 Agent SkillsPlugins Connectors插件与连接器基于 MCP 把 Agent 接入你已有的工具生态Connectors(MCP) 用于分发的 PluginsMCP Servers PluginsSub-agents子智能体分工一个负责想点子另一个负责检查在.codex/agents/下以 TOML 定义 Subagents在.claude/agents/下定义 Task Subagents,以及 Agent TeamsState外部持久化状态记录已完成的和待完成的事项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 1Agent Loop模型反复调用工具直到任务完成让 Agent 具备执行真实动作的基本能力create_agent任意受支持的模型Loop 2Verification Loop用评分器(Grader)对输出打分不达标则带着反馈重试保证输出质量与一致性,而非跑完就算完RubricMiddleware,或在create_agent上挂after_agentHookLoop 3Event-Driven Loop由真实事件(新文档到达、定时触发、Webhook)驱动 Agent 运行让 Agent 成为持续在后台运行的系统组件,而非需要人工调用的工具LangSmith Deployment 的 Cron/Webhook 触发,或 Fleet 的 Channels/SchedulesLoop 4Hill-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 反复强调的这次范式转移的重点不是工作变简单了而是杠杆点移动了——验证的责任、理解代码库的义务、保持判断力而不滑向认知投降的自觉这些从未被自动化真正取代过。设计循环但要把自己设计成始终留在系统里的那个工程师而不只是那个按下开始按钮的人。