TL;DR： loop engineering 最近很红，但它其实只是三个名字指同一件事：社群叫 loop，Anthropic 官方叫 harness。真正的结构是一套四级委派阶梯，从「你还在盯」的回合式，爬到「连题目都交出去」的主动式。它存在的理由是三个真问题，其中最关键的一个是模型判断不了自己输出的质量。Anthropic 自己的实测数据对照很清楚：单一 agent 20 分钟做出的是勉强能跑的半成品，拆开生成与评估的完整框架跑 6 小时，做出的才是真正堪用的成品。

「我不再 prompt Claude 了，我写的是会自己 prompt Claude 的循环。」写出 Claude Code 的 Boris Cherny 在 Sequoia AI Ascent 2026 的访谈里这句话，后来被剪成片段大量转发了近七十万次。可是往下细问，麻烦就来了：同一件事，社群叫它 loop，Anthropic 官方文件叫它 harness，Google 的 Addy Osmani 又正式取名叫 loop engineering。三个名字指同一个东西，难怪读起来像三种不同的新技术。这篇把名词对齐，再把这套东西的真正结构、它解决的问题、跟它跟我自己做的一套系统之间的关系，一次讲清楚。

loop engineering 到底是什么？

先把名词对齐。loop（Peter Steinberger、Addy Osmani、swyx 这条社群脉络在推）跟 harness（Anthropic 官方用语）是同一件事的两个名字。harness 指模型外面那整套装置：prompt、工具、记忆或交接文件、编排方式，模型负责想，harness 负责让它一直对准目标。

一句话讲完它在做什么：你不再一步步手动指挥 AI，而是写一个「会自己一直指挥 AI、朝目标反复跑到完成」的系统。这是一条光谱，两端是 Anthropic 在〈Building Effective Agents〉里分的两家：workflow（工作流），路径是你事先写死的，可预测、稳；agent（代理），路径是模型当场自己决定的，有弹性，但贵、慢、出错会滚雪球。从简单到复杂有五种积木：串接、分流、并行、指挥工人，最后才是生成评估。官方铁律是能简单就简单，只有真的需要才往上爬。

循环是什么：一个目标进入系统，Claude 一轮一轮做事，直到满足停止条件才输出完成

真正决定你委派了多少的，是「循环怎么跑」这个层次。Claude Code 官方文件〈Getting started with loops〉把它拆成一套委派阶梯，四级，差别在「你交出什么」：

回合式（turn-based）：你给一个提示，agent 自己搜集脉络、采取行动、验证成果，没做完就再跑一轮，判断做完或力气预算用完才回应。你还在旁边盯着每一步。

回合式循环：你给一个提示，Claude 搜集脉络、行动、验证，判断做完才回应

目标式（/goal）：你交出去的不再是每一步的指令，是「停止条件」。agent 在任务上工作，换一个独立的评估模型检查你设下的条件，没过就退回继续做，达标或到回合上限才结束。评审是另一个模型，不是 agent 自己说了算。

目标式循环：你交出停止条件，评审换一个独立模型检查，没过就退回继续做

时间式与主动式（/schedule）：你交出去的是「触发」，连 prompt 都不用每次给。系统在云端常驻，盯着某个事件来源，主 agent 跑到验证通过、开一个 PR，第二个 agent 审完通知你，你只需要决定要不要合并。最自主的「主动式」并在这一型里：它连题目都自己找，你唯一保留的动作是最后那个决定。

时间式与主动式循环：你交出触发，系统在云端跑到验证通过、开 PR，你只决定要不要合并

这套东西为什么现在才红：模型和框架两个齿轮在协同进化。METR 的时间跨度测试显示，Claude 3.7 Sonnet 完成一半任务的最长时长约 59 分钟，到 Opus 4.5 已经拉到约 4 小时 49 分（METR 官方数字，信赖区间 1 小时 49 分到 20 小时 25 分，样本仍偏少）。模型变强的同时，框架跟着简化：原本要靠反复重置上下文才撑得住的做法，新模型训练后常常自己就解掉，框架的复杂度随之下降。这条协同进化，是后面所有内容的背景。

它解决什么问题？

推动 loop engineering 出现的，是三个具体的真问题。Anthropic 工程团队在 2026 年 5 月的一场工作坊（Ash Prabaker 与 Andrew Wilson 主讲）把长时间运作的 agent 会遇到的麻烦分成三类：第一，脉络限制，窗口有限，会遗忘，会腐坏；第二，规划能力差，大模型天生不太会规划，常做到一半停下来，留一个半成品；第三、也是最关键的一类：模型无法可靠判断自己输出的质量，会误以为一个还没做完的功能已经做完了。

早期的解法不够。单一模型、单一会话，一直跑 build、check、fix 循环，靠压缩历史来修自己，这种做法的致命伤正是第三类问题：它自己盖章通过，最后陷入无限修补一个烂地基。Anthropic 那句常被引用的原则讲的就是这个：可预测地失败，胜过不可预测地成功。

新解法怎么对症下药：脉络问题用结构化的文件交接，不靠模型记忆；规划问题让一个 planner agent 先把模糊需求拆成规格加多个 sprint；最关键的第三类问题，解法是把生成和评估拆成两个独立 agent，各自独立的上下文、独立的 system prompt，借鉴的正是 GAN 的对抗式生成。Ash 在那场工作坊讲得直白：批评一幅画远比自己画一幅容易，所以与其要求生成者自我批评，不如训练一个严苛的独立评审。

真正让这套做法落地的，是开工前的一道手续：生成和评估两个 agent 在动工前先协商清楚「这一段做完了要满足哪些条件」，Anthropic 实测案例里光是其中一个关卡（level-editor sprint）就谈出 27 项可测条件，每一项都有明确门槛，只要有一项没过，这个阶段就算失败，生成方拿到具体反馈重做。

📊 一手实测数据

  • 单一 agent 做同一个题目（打造一套复古游戏制作工具）：20 分钟、成本 9 美元，做出一个勉强能跑的雏型
  • 拆开规划、生成、评估三个角色的完整框架：6 小时、成本 200 美元，做出的 RetroForge 是真正堪用、能玩的应用
  • 多花的近六倍时间，几乎全用在「谈清楚怎样算做完」跟「严格检查有没有做到」，这正是产出能不能用的关键

Anthropic 自己还留了一句提醒：模型变强、框架跟着简化，是协同进化，但这不代表框架这一层会消失。他们的说法是「有意思的 harness 组合不会随模型变强而变少，它只是换了位置」，旧的被模型吃掉，新的能力又开出新的组合空间。这句话该怎么用，得看你自己的任务落在哪个阶段：模型还接不住的地方，框架还是得补上去。

这跟我自己的翻译系统有什么关系？

Anthropic 在〈Building Effective Agents〉里举生成评估这个积木的例子，用的正是文学翻译：翻译有很多细节，第一轮模型不一定抓得到，但一个独立的评估模型可以给出有用的批评，一轮一轮修。这刚好是我今年早些时候开始做的一套会议翻译质量工程系统，我叫它 TQEF：多路语音识别接不同引擎、进模型翻译、后处理、出逐段译文，这是生成端；一个评分器拿五个维度的 rubric 给每段译文打分，术语、流畅度、语境、格式、致命错误，不过关就重来，这是评估端；五个来源汇流、排程常驻累积语料，是把整套东西撑住的背景设施。

我没有读过这套官方框架才开始做，是自己一轮一轮撞出同样的结构。我比官方示范多想了一步：不只调评分器的 prompt，还该有一个阶段（我叫它 Stage B）去验评分器本身准不准，拿另一套指标交叉比对它的判断、拿真人专家的评分校准它、看同一批重跑稳不稳。这个阶段我还没真正跑完，先卡在其他优先顺序后面，是诚实留着的一个坑。这件事回应的正是前面那条原则：循环可以帮你把生成和评估拆开，但「怎样算一句翻译过关」这件事，永远得是你自己先讲清楚，连「这把尺准不准」都得自己验，没人能替你做。

从这条路走过一轮，我归纳出几条日常工作原则：每个手工零件都写一句「为什么存在」，模型升级时先做减法再做加法；力气要投在评审跟 criteria 上，换模型也不会丢，别投在叠更多循环，那些会被模型吃掉；一个结果不合格，别只修那一个，把它编码进系统让之后每一轮都受益；控 token 也要选对层次，/goal 的评审用便宜模型就够，停止条件写清楚，确定性的步骤交给脚本，不用每次重新想一遍。

loop engineering 让你把「怎么跑」交出去：怎么搜集脉络、怎么行动、怎么验证，都可以自动化。它永远不能自动化的，是谁来定义「跑对了」这件事本身。那个标准，还是得有人先讲清楚。

这篇先把框架本身讲清楚。我自己这几个月怎么一轮一轮撞出同样的结构、踩过哪些坑，留到下一篇细谈。

参考资料

Anthropic／Claude Code 官方一手

其他一手来源

  • Boris Cherny（Claude Code 负责人），Sequoia AI Ascent 2026 访谈：本文开场那句话的原始出处。这段话后来被大量剪辑转发，本文引用回访谈本身，不采二手转述版本
  • Addy Osmani，Loop Engineering：正式为这个概念命名的原始文章