从提示员到系统架构师：Loop Engineering 的范式跃迁

引言：你不再是对话者了

2026 年上半年，AI 编码代理从命令行玩具变成了日常基础设施。Claude Code、OpenCode、Codex CLI、Cursor——这些工具不再只是"更聪明的自动补全"。它们开始自主地阅读代码库、提出修改方案、运行测试、迭代修复。

与此同时，一个微妙但彻底的转变发生了。那些从这些工具中获得最大产出的人，不再花更多时间写更好的提示词。他们花时间设计系统——系统自己决定下一步做什么。

Boris Cherny（Claude Code 的创造者）在 2026 年 5 月说了一句我觉得精准捕捉了拐点的话：“我不再给 Claude 写提示词了。我有一些 loop 在运行，而那些 loop 给 Claude 写提示词……我的工作是写 loop。”

这句话像一把刀切开了两个时代。在此之前，你的价值取决于你多擅长和模型对话。在那之后，你的价值取决于你多擅长设计不需要你参与对话的系统。

这篇文章记录的是我对这个转变的理解——它在 2026 年中期呈现的样子。如果你一年后重读，有些判断可能已经过时了。但结构性的东西，那些层次的划分、原语的识别、难的问题和容易犯的错——我猜它们会留得更久。

一个不成立的假设和一个正在发生的事实

我见过太多团队在 2025–2026 年的做法：雇一个人"专门调 prompt"，把这个人的产出绑定在每一次聊天窗口的对话质量上。这是一种很自然的想法——模型是你的对话对象，对话质量决定输出质量。

但这个假设在 2026 年中间某个时刻悄悄失效了。

失效的方式是这样的。想象两个工程师在使用同一个模型。工程师 A 打开聊天窗口，写了一条很长的 prompt，得到了一份不错的代码，然后关掉窗口。工程师 B 做了一个自动化工作流：一个 git hook 在 PR 创建时触发一个 agent，agent 阅读 diff、运行测试、检查代码风格、写 review 评论。如果评论被采纳，agent 还会修改代码并推送新的 commit。

工程师 A 可能写了更优雅的 prompt。但工程师 B 一周内 Review 的 PR 数量是 A 的几十倍——而且他在这期间还做了一堆别的事情。

这不是 prompt 质量的问题。这是抽象层次的问题。A 在第一个层次上和模型互动。B 设计了一个运行在更高抽象层次上的系统，这个系统自己知道什么时候需要和模型对话。

我最初看到这个差距时，觉得它只是一个效率优化——让机器做更多，人做更少。后来我发现这不仅仅是效率。它改变了你作为工程师的界面。你的工作不再是"写更好的指令"，而是"设计更好的迭代结构"。你从一个操作员变成了架构师。

这个转变我目前认为不可逆。不是因为工具会越来越好——而是因为一旦你体验过设计一个 loop 然后看着它自动完成过去需要你逐轮介入的工作，你就很难再回到聊天窗口里了。

什么是 Loop Engineering

一个直觉

Loop Engineering 的定义很简单：设计自主迭代循环的实践。这些循环决定什么时候调用模型、传递什么上下文、怎么评估输出、什么时候重试、什么时候停止。

但它真正反直觉的地方是这个：loop 把工程师从循环内部移到了循环外部。

在 prompt engineering 时代，你在循环里——你读模型的输出，你决定下一步说什么，你判断什么时候够了。你是控制回路的一部分。

在 loop engineering 时代，你设计循环本身。循环里的每一步可能仍然调用模型（可能很多次），但决定每一步做什么的逻辑是你写的代码、你定的规则、你连的工具——而不是你在聊天窗口里的实时判断。

一个具体例子

假设你要为一个代码库添加一组单元测试。

没有 loop 的做法：你打开聊天窗口，贴一个源文件，说"为这个文件写单元测试"。模型回复一段代码。你复制到项目里，运行测试，发现有失败的，把错误贴回去让模型修。重复三四轮，差不多了。

有 loop 的做法：你写一个脚本，大致是这样——

for 每个需要测试的源文件:
  1. agent 读取文件 + 项目中已有的测试风格
  2. agent 生成测试代码
  3. 运行测试
  4. 如果有失败:
     a. agent 阅读错误信息
     b. agent 修改测试代码
     c. 回到第 3 步
  5. 如果全部通过 -> commit
  6. 如果重试超过 N 次 -> 标记为需要人工审查

你运行这个脚本。它处理了 20 个文件。其中有 17 个一次性通过，3 个经过一两次迭代后通过，1 个标记为人工审查。你花 5 分钟看了那个审查标记的文件，手动调了一行断言。

在这整个过程里，你和模型的对话次数是零。模型被你的 loop 调用了上百次——但你一次都没有打开聊天窗口。

这个定义的两个边界

第一，不是所有任务都适合 loop。一次性的、定义清晰的、不需要迭代的任务——比如"把这个 JSON 转成 YAML"——写 loop 的成本高于收益。Loop 的价值在任务量大、有迭代模式、失败模式可预测的场景里最明显。

第二，Loop 不替代 prompt engineering。你设计 loop 时仍然需要写 prompt——但这些 prompt 现在不是写给最终用户看的人机对话 prompt，而是写给 loop 内部的子代理 的系统指令。它们更结构化，更少自由发挥，更多约束条件。这个区别很重要：你并没有停止写 prompt，你写的 prompt 的消费者变了。

四层抽象阶梯：从对话到自我改进

如果给 2022–2026 年的 AI 工程画一条抽象层次上升的路径，它大致经过四个阶段。每一层包裹但不替换前一层。

第一层：Prompt Engineering（2022–2024）

核心关注点：怎么说话模型才会照做。

你优化的是措辞、角色设定、示例格式、few-shot 排列顺序。你的输出质量取决于你多了解模型的"脾气"——GPT-4 喜欢什么结构，Claude 对什么措辞敏感。这是一门手艺活，而且不透明。同一个 prompt 在两个版本之间可能突然不好用了。

第二层：Context Engineering（2025 年前后）

核心关注点：模型看到了什么。

你不再只关心你说什么，你还关心模型看到的历史、文档、代码库结构。RAG 检索、系统提示组装、对话历史压缩——这些成为核心技能。你的 prompt 不再孤立存在，它被嵌入到一个更大的信息上下文中。

这一层的出现是因为模型开始支持更长的上下文窗口，但很快人们发现"能放进去"不等于"能注意到"。你需要的不是把更多文本塞进窗口——你需要把正确的文本放在模型会读到的地方。

第三层：Harness Engineering（2026 年初）

核心关注点：模型能做什么、不能做什么、怎么约束它。

Harness 是模型和外部世界之间的运行时中间层。它管理工具注册、任务状态、资源预算、可观测性。它决定模型能调用哪些工具、每次调用的超时是多少、连续失败几次应该熔断。

这一层的核心洞察是：模型的可靠性不是模型的问题，是 harness 的问题。给同一个模型配上不同的 harness，产出质量可以差一个数量级。

第四层：Loop Engineering（2026 年中至今）

核心关注点：怎么让系统自己决定下一步。

Loop 是 harness 之上的编排层。它不关心单次调用的质量——它关心的是：系统怎么知道什么时候该做什么？怎么知道自己做完了？做不完的时候怎么办？怎么从一次运行中学到的经验改进下一次运行？

这是最抽象的一层，也是杠杆最高的一层。一个设计良好的 loop 可以把一次手动的三轮迭代压缩成一个自动步骤。但设计它的难度也最高——因为你不再有实时反馈。你设计的时候不知道具体会遇到什么情况。你的 loop 需要在运行时自己判断。

四层的关系

拿我前面那个单元测试的例子来说：

• 每一轮调用的 prompt 内容是 Prompt Engineering。
• 让 agent 读取项目中已有的测试风格文件是 Context Engineering。
• 限制每次调用的 token 预算、超时、重试次数是 Harness Engineering。
• 决定"对每个文件做同样的事，但失败时循环回来"是整个 Loop。

你不需要精通所有四层来使用 loop——但你设计 loop 越深入，四层都会碰到。这是个全栈活计。

六个原语：Loop 的建筑模块

在研究了多个开源实现和商业产品之后，我发现大多数 loop 可以分解为六种原语。它们不是理论分类——我在实际代码里看到了同样的结构反复出现。

1. 心跳（Heartbeat）——谁启动 loop

Loop 不能凭空运行。它需要一个触发条件。

最简单的是时间触发——cron 表达式，每隔一段时间启动一次。GitHub Actions 的 schedule 事件就是这个模式。更复杂的是事件驱动——webhook 收到外部信号时启动，或者文件系统变化时启动。

Claude Code 内置了 /loop 和 /goal 命令，它们本质上是一个带有交互式心跳的循环：你告诉它一个目标，它在内部决定什么时候该启动下一步。OpenCode 不做这个——它把心跳决策留给你，用 opencode run 作为 worker，你自己用 cron 或 CI 触发器来调度。

心跳是容易被低估的原语。很多人可能会写了一个很好的 loop，但忘了想"这个 loop 是天天跑还是只跑一次"——然后它就只跑了一次，再也没动过。

2. 工作分离（Worktree）——并行隔离

真正的项目从来不是一个 loop 处理一件事。你会有多个 loop 同时在跑——一个修 bug，一个加功能，一个做代码审查。

每个 loop 需要自己的隔离环境。用 git branch 或者独立目录来隔离，这样不同 loop 的修改不会打架。这在实施上很琐碎，但在设计上很关键——没有隔离的 loop 不是并行，是竞态条件。

3. 技能（Skill）——知识固化

Loop 跑一次的时候，它是热的——上下文里全是当前任务的信息。但 loop 跑完，下一轮启动时，它是冷的。它不记得上一轮学到了什么。

Skill 是解决这个问题的原语。它是项目特定知识的固化文件——编码规范、架构决策记录、常见陷阱列表。Skill 文件在每次 loop 启动时被注入到上下文中，让 loop 从冷启动跳到"有备而来"的状态。

好的 skill 不是静态文档。它是从 loop 的运行经验中提炼出来的——一个 loop 发现一个常见错误模式，这个模式被写进 skill，下一次 loop 就不会再犯。

4. 子代理（Sub-agent）——分工与制衡

一个 loop 内部可以只有一个代理反复调用自己，但实践中更好的模式是分工。

我做代码审查的 loop 里有三个角色：一个代理写代码（maker），第二个分出五个影分身从五个正交的角度审查代码(reviewer)，最后一个代理做对抗性验证（adversarial verifier）。Maker 可以很激进——它尝试各种方案，不介意犯错。Reviewer 很保守——它从五个不同的方向逐行审查 maker 的输出，找逻辑漏洞、边界条件、风格偏离。如果 checker 发现了问题，maker 重做。

Maker 和 checker 可以是同一个模型，但角色分离的 prompt 不一样，这就有用了。关键是检查者不能和制造者是同一个对话上下文——否则模型会对自己太温柔。

Adversarial Verifier 只能看到 Maker 的输出，并先入为主地认为有重大缺陷隐藏其中，他的任务就是揪出隐藏的缺陷来。

更复杂的 loop 可以有更多的子代理角色：规划者、执行者、评审者、记录者。子代理越多，协调成本越高，但分工带来更专业的输出。

5. 连接器（Connector）——与现实世界交互

Loop 不能只在模型内部的思维空间里运行。它需要调用工具：读文件、写文件、查数据库、调 API、发消息。

连接器原语处理的是工具如何暴露给 loop 内的代理。MCP（Model Context Protocol）是 2026 年最主流的标准化方案——它定义了一个统一的接口，loop 可以通过这个接口发现和调用外部工具。虽然我颇为嫌弃 MCP 对上下文污染太多，平常很少用到。

连接器的设计决策影响深远：你允许 loop 访问 shell 吗？允许它写任意文件吗？允许它调用生产环境的 API 吗？每个连接都是权限的边界。

6. 脊骨（Spine）——跨运行持久化

这是最被忽视的原语，也可能是最重要的。

模型在每次调用之间遗忘一切。Loop 在每次运行之间也遗忘一切——除非你有地方存状态。Spine 就是这个"地方"。它可以是一个进度文件（progress.md）、一个数据库表、一个看板工具（Linear、Jira）——只要 loop 在下一次启动时可以回答"上次我做到哪了"。

没有 spine 的 loop 不是一个循环——它是一个每次都从第一步开始的重复。

我感觉在 loop 设计里，这个原语的缺席会导致了最隐蔽的失败模式：loop 在跑，也在产出，但产出质量不随时间增长，因为每次启动都把之前的经验丢掉了。

三个最硬的问题

Loop Engineering 目前有三个问题我还没有看到优雅的通用解法。似乎每个项目都得用自己的方式硬扛。

上下文管理

随着 loop 运行轮次增加，模型看到的内容越来越多。但"更多"不等于"更好"——注意力随长度衰减，无关细节淹没关键信号。

通用的应对策略有三类，各有利弊：

• 压缩：把历史记录总结成更短的形式。丢失细节，但保留主线。
• 剪枝：直接丢弃不相关的历史。需要启发式判断什么是不相关的——启发式本身可能出错。
• 外部化：不让模型自己记忆，而是把状态写到一个外部文件里，模型只在需要时读取。最干净的做法，但要额外设计读写机制。

我目前想到的做法是混合使用：每一轮结束时自动做一次压缩（把本轮的关键决策和输出写进 spine），然后在下一轮开始时只加载压缩后的摘要，不加载完整历史。

终止检测

这个问题比看起来难十倍。

一个 loop 需要知道什么时候停下来。听起来很简单——任务完成了就停。但"完成"在复杂任务中是一个很难自动判断的属性。

常见的终止条件有六种：

1. 模型输出了一个明确的终止信号——比如"任务完成"标记。
2. 外部验证通过——测试全绿、lint 无报错、编译通过。
3. 达到最大迭代次数——硬上限，防止无限循环。
4. 超时——时间预算耗尽。
5. 遇到不可恢复的错误——比如依赖服务挂了。
6. 振荡检测——代理反复调用同一个工具、传同样的参数、得到同样的结果。

第六种我花了一段时间才意识到它的存在是必要的。Agent 在遇到困难时会"卡住"——它反复尝试同一个已经证明无效的方案，每次都期待不同的结果。没有振荡检测的 loop 会在这种状态下消耗大量预算。

我对终止的当前判断是：终止不是事后考虑，它是半个设计。一个 loop 的终止条件和它的业务逻辑一样重要。如果你写 loop 的时候先写"做什么"再补"什么时候停"，你得到的一定是一个在边缘情况下会无限跑的 loop。

验证信号

Loop 需要知道自己做的事情对不对。验证信号就是这个"对不对"的输入。

最好的验证信号是确定性的：测试通过、类型检查通过、编译成功。这些信号是 gold standard——它们客观、可重复、不会说谎。

但当任务没有确定性验证可用时（比如写文档、做设计决策），可以退而求其次用模型作为评审者（LLM-as-Judge）。这是一个有用的技术，但它有一个结构性问题：写代码的模型评价自己写的代码太温柔了。不是说它会作弊——而是它会在看到自己熟悉的模式时放松标准。

解决方法我在 maker–checker 前面提到了：制造者和检查者必须是不同的代理实例——最好是不同的上下文、不同的 prompt 体系、甚至不同的模型。这不是不信任——这是架构约束。

两个陷阱：效率的暗面

Loop 越强大，越容易滑入两个陷阱。我说"陷阱"是因为它们不是技术问题——它们是你自己的认知在习惯 loop 之后产生的盲区。

陷阱一：检查仍然是你的工作

Loop 让产出变得更快、更自主。但"完成"是代理的主张，不是证明。一个 loop 说"所有测试通过"——你真的看过测试覆盖了正确的东西吗？一个 loop 说"重构完成"——你真的确认过架构约束没有被绕过吗？

这不是说你不该信任 loop。我信任我的 loop 去做它们被设计来做的事情。但当 loop 的输出要进入生产环境时，审查仍然是你的工作。和人类同事写的代码一样——你信任他们，但你还是做 code review。Loop 生成的代码也是同样的逻辑。

区别在于：因为 loop 产出太流畅了，你很容易跳过审查这一环。流畅性本身是一个认知陷阱。

陷阱二：不要停止深度思考

这是更隐蔽的一个。

Loop 越快地产出你没有亲手写的代码，你的项目能力和你的实际理解之间的差距就越大。你看着一个 loop 重构了整个模块——但你真的能解释重构后的每一行在做什么吗？如果不能，你是模块的拥有者还是旁观者？

我在自己身上看到过这个现象 —— 开始依赖 ClaudeCode/Codex 后，我对代码库的细节掌握明显变薄弱了。不是因为我变懒了 —— 而是因为 AI 代理处理得太好，我没有"被迫理解"的机会了。

这不是反对使用 loop。一个人熟练的工程师用 loop 可以产出比手动高十倍的效率。但那是因为在 loop 出现之前，他已经理解了。他设计 loop 时知道 loop 在做什么，知道边界在哪里，知道什么情况下 loop 的假设会失效。

这个陷阱真正的风险是时间差：如果你在还没有深入理解一个领域的时候就开始用 loop 替你工作，你永远不会有那个"被迫理解"的阶段。loop 把学习的窗户关掉了。

我目前的应对是：对于我熟悉的领域，loop 全速前进。对于我不熟悉的领域，我先手动做几次，理解之后再写 loop。

两条实现路径：工具选择与工程哲学

2026 年中，想实践 Loop Engineering 的人面对两个主流选择：Claude Code 和 OpenCode。它们都做 loop——但背后的哲学差异很大。

这个对比的背后是一个更深的选择：你想要一辆造好的车，还是一个发动机让你自己造车？

Claude Code 适合那些想快速体验 loop engineering、不想在基础设施上花时间的团队。它的 loop 原语是内置的，心跳开箱即用，子代理分工通过 /loop 和 /goal 就能实现。你付出的代价是：一旦内置的 loop 模式不满足你的需求，修改起来很困难。

OpenCode 适合那些需要完全控制 loop 行为的团队。你就是 loop 的设计者——心跳自己写，spine 自己选，子代理的调度自己实现。代价是：你要把六个原语全部手动组装一遍。上手慢，但上限高。

我目前倾向 OpenCode 路线。不是因为它更好——而是因为 loop engineering 还在快速演化，我不想把我的 loop 架构绑定在一个厂商的特定实现上。等模式稳定了，再考虑更高的抽象层。

边界条件

本文讨论的 loop 模式在以下情况下可能不适用或需要大幅调整：

• 单次任务：如果你只需要让模型做一件事一次，loop 是过度设计。写一个 prompt 就够了。
• 高精度要求：目前 loop 的验证机制在需要人类级判断的任务（法律文件审核、医疗建议）上不够可靠。确定性验证覆盖不到的地方，loop 的可靠性取决于你愿意接受多少错误率。
• 极低延迟要求：Loop 涉及多轮模型调用，每次调用几百毫秒到几秒。对实时交互有要求的场景，loop 不是一个合适的选择。
• 团队规模太小：一个人的团队写 loop 可能得不偿失 —— 维护 loop 本身有成本。当团队有三个以上工程师复用同一个 loop 时，这个成本开始物有所值。当然我准备在自己的小项目上实验下 loop，就顾不得这个了。
• 语言或文化障碍：Loop Engineering 的当前最佳实践和工具文档以英文为主。非母语团队的采纳曲线会更陡。
• 组织尚未准备好：如果团队的工程文化不支持自动化、不信任自主系统、或者管理方式要求每步都有人签字，loop 的收益会被组织摩擦吃掉。

开放问题

1. Loop 的可观测性：当一个 loop 跑了 48 小时，调用了上千次模型，做了几百次文件修改——你怎么知道它做得对不对？目前的可观测性工具（trace、log、metric）是为确定性系统设计的，不是为自主决策系统设计的。这个缺口怎么补？

2. 验证泛化：确定性验证（测试、lint）覆盖不了的任务中，LLM-as-Judge 的可靠性到底有多高？我还没有看到严格的、跨场景的基准测试。

3. 跨 loop 状态共享：多个 loop 同时在同一个项目上运行时，它们怎么共享上下文而不会冲突？目前的做法是各自写各自的任务上下文，但"总览全局"的能力在 loop 之间是缺失的。

4. Skill 的自改进周期：当 loop 从运行中学习到新经验时，它怎么自动更新自己的 skill 文件？这个元循环（改进 loop 的 loop）的实现目前还没有好的通用模式。这个感觉跟 Hermes Agent 有点像。

5. 收敛性保证：多代理 loop（规划→执行→评审→记录）在复杂长周期任务中，是否存在收敛性？有没有一种情况是执行者和评审者反复来回修改同一段代码永远无法达成一致？理论上是的，实际中我见过。什么条件下它一定会收敛？

[[Q]] 一年后重读这篇文章时，我会仍然认同"Loop Engineering 是一次范式跃迁"这个框架，还是会觉得它只是 Harness Engineering 的一个子集？

参考文献

1. Addy Osmani, “Loop Engineering”, 2026 年 6 月。六个原语的首次系统化定义。
2. Boris Cherny（Claude Code 创作者），关于"我不再写 prompt，我写 loop"的访谈，2026 年 5 月。
3. Sydney Runkle（LangChain），“The Art of Loop Engineering”，2026 年 6 月。四层循环栈模型的来源。
4. Richmond Alake（Oracle），“Agent Loop Decoded”，2026 年 6 月。Agent = Model + Harness 公式和三级成熟度模型。
5. Peter Steinberger（OpenClaw），关于"技能已转移到 loop 设计"的帖文，2026 年 6 月。