Loop Engineering：被高估的循环，被低估的拓扑

本文来自微信公众号： 五源资本 5Y Capital ，作者：五源信号站

上一期的五源信号站 5Hz，我们还在讨论 World Model 的三种未来。而今天，一个更“工程”、也更贴近一线开发者的概念，正在硅谷迅速升温：Loop Engineering，循环工程。

6月初，在短短一周里，三个身处不同 AI 巨头的人，不约而同地给出了同一个判断：“别再亲手给编程 agent 写提示词，去设计那套替你写提示词的循环系统。”

最先点火的是 Peter Steinberger，他是开源项目 OpenClaw 的作者，如今在 OpenAI 工作。他的一条帖子冲过了八百万次浏览，意思很直接：你不该再去 prompt 编程 agent，你该去设计那些 prompt agent 的循环。

几乎在同一时刻，Anthropic Claude Code 的负责人 Boris Cherny，说了同样的话。他已经不再亲手 prompt Claude，而是有一堆循环在后台 prompt 它、替他判断下一步该做什么，他的工作就是写这些循环。

6月7日，曾主导 Chrome 开发者体验、现任 Google Cloud AI 总监的 Addy Osmani，把这件事写成一篇文章，给了它一个名字：Loop Engineering，循环工程。

过去两年，AI 圈每隔一阵就冒出一个“XX工程”。先是 prompt engineering，相关课程到今天还在卖；接着是 context engineering，仍在引发讨论；再接着是 harness engineering，墨迹未干……loop engineering 踩着模型发布的节奏又来了。

不过前面那几个“工程”，讲的都是同一件事的不同版本：你坐在键盘前，如何把 agent 指挥得更好。loop engineering 把这个前提直接删掉了，你不再处于工作流里面，而是站在循环外面，去搭那个循环本身。

当然，“loop engineering”这个念头本身也不新。去年夏天，澳大利亚开发者 Geoffrey Huntley 就在博客里写过他的做法，起了个名字叫“Ralph Wiggum”，借的是《辛普森一家》里那个又笨、又乐观、又锲而不舍的小孩。把一个并不算聪明的 agent 摁在一个任务上，让它一遍遍地撞，直到撞通。当时这么干，效果一般，而今天效果好了很多。

这背后也是模型能力跨过了门槛，编程 agent 已经能无人值守地跑完一个不简单的任务。过去要把每种边角情况写进提示词，现在它大体能自己想明白；定时、调度这类命令，也进入了主流的 agent 运行环境。零件齐了，大家自然都转向把它们拼起来，去创造整个系统。

6月底，我们邀请了一批一线的研究者和创业者，一起聊了聊这件事，这是五源信号站 5Hz 的又一场闭门研讨。今天这篇文章我们将分成两半：前半篇，是我们对 loop engineering 的梳理：它是什么、为什么重要。

后半篇，则是那场闭门会上，比公开叙事更有意思的声音：当所有人都在谈论“循环”时，那些真正在一线把模型用到极限的人，私下里究竟在思考什么？

什么是 Loop Engineering

过去两年，编程 agent 的工作方式是这样的：写一段好提示词，给足上下文，敲一句，给答案，再敲下一句。agent 是工具，你全程握着它，一轮接一轮。

loop engineering 要换上的是一套小系统。它自己去找该干的任务，把任务派出去，检查结果，把“做完了什么、接下来做什么”记下，然后决定下一步。你让这套系统去催 agent，而不是你自己一轮一轮地催。

Addy Osmani把这些层次摞起来看，像一栋楼：最底下一层，是你给 agent 的指令（prompt）；上面一层，是你喂给它的背景资料（context）；再上面，是单个 agent 跑起来所需的整套运行环境（harness）。循环就架在这一切之上，它让下面这整套东西，能一遍遍自动跑起来。

一年前你想跑这样一个循环，得自己写一大堆脚本、天天维护，而且基本只有你自己用得了、很难挪给别人。如今，这些零件已经被直接做进了产品里。

一个 loop 拆开看，就是循环做五个动作：发现、派活、验证、持久化、调度（说法出自《Loop Design: A Field Playbook for Agentic Systems》）。

第一个动作是发现，说白了就是自己找活干。在聊天框里，活是你一条条敲给它的；在循环里，是它自己去代码库里转一圈，挑出该处理的东西：一批没通过的测试、一个没人管的 issue、一个突然变差的指标、最近某次提交留下的隐患。

这里就有一个要人拿主意的地方：让它盯多大一摊事？只盯测试，它专注、好预测；把 issue、日志、指标、用户反馈都交给它盯，它能干得多，也更容易跑偏。稳妥的做法是先给它一小摊，等它在这摊上做得靠谱了，再把摊子铺大。连自己那几个没过的测试都收拾不利索的循环，就别指望它管 issue。

第二个动作是把活分出去。一旦同时开着不止一个 agent，它们就会为了文件打架：两个 agent 同时改一个文件，跟两个同事各改各的、事后才发现动了同一行代码，是一样的乱。办法是给每个任务单开一份互不相干的工作副本（技术上叫 git worktree），各干各的，谁也动不到谁的文件；只有到最后合并的那一刻，几份改动才碰头，就算有冲突，也都摆在明面上、能一条条核。先把它们隔开，“同时干活”才不至于变成“同时闯祸”。

第三个动作是验证，也是整件事的核心：东西做出来了，总得有人说一句“行”还是“不行”。而循环设计里最难的选择，就是让谁来说这句话。要是让写代码的那个 agent 自己给自己打分，循环就等于没有一个靠得住、又不偏心的裁判。经验里，agent 给自己打分，几乎永远往高了打。

所以此时就得另配另一个 agent 专门来挑刺：它拿的是另一套指令，有时干脆换一个模型，任务是默认第一个 agent 写的东西是坏的，专门去找它该被打回的理由。让一个独立的、爱挑刺的家伙来把关，比指望写代码的 agent 自我批评，要靠谱得多。

第四个动作是把进度记下来。一场对话里，“做到哪了”这些信息，都存在模型当时的记忆里，可这种记忆是临时的，对话一清空就没了。循环要一轮一轮长期地跑，靠不住这种临时记忆，得把结果实打实地写进文件、写进数据库，记下来存好。加上这一步，一次次原本各不相干的任务运行，才连成一件能累积的事：今天试过什么、哪些过了、哪些还没，明早那一轮才接得上。

第五个动作是调度，相当于给整件事装上心跳：让它到点自己启动、自己再跑一轮，而不用每回手动去点。

这五个动作，靠产品里一组现成的零件来实现，大致是六样：

一是定时自动跑、自己找活并挑出该处理项的“自动化”；

二是让并行的 agent 各用各的工作副本、互不打架的“工作树”；

三是把项目里的规矩和背景一次写下来、省得 agent 每回重猜的“技能”（Skills）；

四是把 agent 接上你日常工具的“连接器”（大多走 MCP 这个通用接口，能读你的任务系统、查数据库、往 Slack 发消息）；

五是把“写代码的”和“挑错的”分成两个人的“子 agent”；

六是那份活在单次对话之外、专门记着进度的“外部记忆”，一个 markdown 文件也行，一块 Linear 看板也行。

这六样，Claude Code 和 Codex 如今都配齐了，叫法各异，干的是一回事，不必纠结用谁，设计一个在哪边都跑得通的循环就行。

还有两个现成的命令值得重视：/loop 就是按固定节奏一遍遍重复；/goal 更进一步，它会一直干到你写下的条件真的达成为止，而且每跑完一轮，由另一个小模型来判定“到底完没完”，给它打分的，不是写代码的那个 agent。你只要写下一句“test/auth 目录下的测试全过、代码检查干净”，就能起身走人。

这些零件拼到一起，一条单线的对话就成了一个指挥台。Addy Osmani给自己搭的晨间循环大致是这样：每天一早，一个自动化在代码库上自动开跑；它调用一个分诊技能，把昨天没过的 CI、还开着的 issue、最近的提交都读一遍，把发现记进一个 markdown 文件；凡是值得动手的，它就单开一份隔离的工作副本，派一个子 agent 起草修复，再派第二个子 agent 拿着项目规矩和现有测试去审这份草稿；连接器替它把 PR 开好、把工单更新掉；它自己搞不定的，就丢进一个收件箱等他来处理。那个状态文件是整件事的主心骨，记着试过什么、过了什么、还剩什么，所以第二天早上那一轮，能从今天停下的地方接着往下走。

循环跑起来之后，没有一句提示词是他亲手敲的，全是这套循环替他写的。

Loop Engineering为什么重要？

一项技术真正重要的时刻，是它让某样原本稀缺的东西，突然变得近乎免费。

Vibe coding已经让写代码不再是瓶颈，稀缺的东西从“写”挪向了“判断”，而loop engineering 把这个进程又往前推了一大步。

这套打法能被推到多远，一线已经给出了实例。Stripe 的工程师 Steve Kaliski，在 How I AI 播客上讲过他们一套叫 Minions 的流水线：每周合并一千三百多个 pull request，没有一行是人手敲的。但这不只是“用 agent 写代码”，如果是 vibe coding，一千三百个 PR 意味着得有人在对话框里一个个去提示、一个个去验收，根本做不到这个量。Minions 能跑到这个规模，是因为它是一条被设计好的、自己会转的流水线：在 Slack 里加个 emoji 就启动，确定性的关卡（规则能判的绝不交给模型）和 LLM 步骤自动咬合，一千多个 agent 同时跑而不打架。人设计了一次这条线，之后每一个 PR 都是自动触发、自动验收。人只在末端做一件事：审核。

循环带来的也不只是快，有时候是“能用”和“不能用”的差距。The Information 报道过 Anthropic 工程师在一次大会上的对照演示：同一个“做复古小游戏”的任务，极简提示词花了二十分钟、九美元，循环花了六小时、两百美元。但极简版做出来的游戏根本跑不起来，循环版则带上了换配色、能调试这些真正有用的功能。那场演示里还有个细节，负责生成的 agent 和负责验收的 agent，会为了“到底算不算做完”当场针锋相对。模型本身并没有变聪明，但上一轮那个被独立验过的结论，喂进了下一轮的输入，让这个循环一轮比一轮强。

这套逻辑也不只在代码领域管用。Airbnb 有一篇论文（Cen Zhao 等，arXiv:2510.06674）把类似的思路搬进了客服：客服对答案的取舍、采纳与否、哪条知识缺了，这些判断被直接喂回模型，重训周期从几个月压到几周；一次美国本土的试点里，检索召回提升了 11.7%，回答有用性提升 8.4%，客服采纳率提升 4.5%（均为相对提升）。场景不同，做的事情一样，把判断攒起来、不断喂回去。

不过，把生成自动化，并不代表完全替代人。留给人的活反而更难了，而且循环越顺手，一系列代价反而越难回避。Addy Osmani 在《Loop Engineering》里讲了好几个点，其中有几个问题在 vibe coding 中就有，循环也把它们放大了。

第一个是意图债（intent debt）。Agent 每轮都是冷启动，不知道项目里的规矩忌讳，无人值守时它就一路“自信地猜”下去；解法是把规矩写成 Skills，写一次、每轮自动读。

第二个是验证债（verification）。循环能无人值守地跑，也就能无人值守地错。哪怕另配了验收 agent，“做完了”终究只是一句声明，最后能不能上线还得人来判断。

第三个是理解债（comprehension debt）。循环吐代码越快，你没亲手写、也没真读懂的代码就堆得越高。这个问题 vibe coding 里也有，Osmani 认为“a smooth loop just makes it grow faster”，循环跑得越顺，这个缺口长得越快。

第四个最隐蔽，Osmani 叫它认知投降（cognitive surrender）。循环一顺，人就懒得较真，它递回来什么就收什么，判断权不知不觉就让出去了。所以Osmani说，要带着判断力去设计循环，它是解药；为了逃避思考去设计循环，它就是加速剂。

第五个是编排税（orchestration tax）。循环可以同时开很多条，但你的审查带宽是有限的，并行数量的上限，不是工具定的，是你的注意力定的。

第六个最实在：token 成本失控（token costs）。不同用法之间的花费，能差出一个数量级，不算着来很容易超支。

Peter Steinberger 现在也每天同时开着五六个 Codex 循环（早期模型慢时开过近十个），趁 A 在跑的时候去看 B 的结果，他承认这只是等模型再提速前的权宜之计。

但即便已经在这种强度下工作，有人问他看不看好“全自动黑工厂”，连进去的代码都不审，他一方面认为越来越可行，但另一方面，他仍然强调好软件是一步步试出来的，你最初想做的那个项目，几乎不会是最后做成的那个。瓶颈从来不是写代码本身，而是想清楚到底要什么，是品味。

他给工程师最重要的建议就是品味，是让产出“别闻起来像 AI”。循环把“写”这件事本身，变得更加不值钱，可“要写什么、写成什么样”，就变得更加重要了。

五源信号站Best Insight：被高估的“循环”，被低估的“拓扑”

以上是硅谷对 loop engineering 的公开讨论。而在 6 月底我们那场闭门研讨上，房间里的气氛和外面不太一样，没有人急着给 loop engineering 唱赞歌，大家更想聊的，是它还没解决、甚至还没想清楚的那些事。以下insight节选自闭门研讨会中的嘉宾观点：

Highlights

• 在长程能力上的一句尖锐判断：“循环（loop）被高估了，拓扑（topology）被低估了”。真实有价值的任务，是螺旋式自我迭代 × 深度耦合拓扑结构的结合体。

  
  

• 长程 ≠ 难：很多 loop 型任务跑得久但并不难；而人类真实工作是并行、异步、可被打断的，很难被镜像成单个 Agent 的任务。长跑，更多是厂商的展示姿态：发模型时爱晒几十小时的长跑曲线，但真实用户大多数情况只做九、十分钟的交互。跑得久的 auto research，和与人协作解一个 coding 任务，并不是一回事。

  
  

• 多 Agent 的本质，是给上下文“换血”：靠行为变异时的动态替换、context refresh、QA / reviewer 角色维持系统不发散，像一个被工程化的 “strange loop”。

  
  

• 反馈是循环的命门：信号密度 > 通讯密度。把 Agent 间通讯搬到 latent 空间，是大家正在认真琢磨的方向，但瓶颈始终是信号有多密、有多准，而非通讯有多频繁。

  
  

• Scaling 的下一站，从“训模型”转向“造环境”：自己造题太窄，长期一定要从真实、大用户量的产品里逆向出环境与 verifier。

  
  

• Self-Improvement 仍是一场尚未被证明的信仰：没有理论保证模型一定会自我改进；好的 reward 通常必须外生，模型内部信号（如 KL）只能 sharpen 分布、并不抬升能力上限。

  
  

• 落地仍然差得很远：像咨询级 PPT（一张幻灯片价值数万元）这类高复杂度、非简单 loop 的任务，当前模型还无法做有效拆解；结论是不必 FOMO，更该亲自上手、与真实用户交流。

  
  

讨论嘉宾 | 5Y社群

整理 | 刘一鸣

Insight 01

被高估的“循环”，被低估的“拓扑”

1.在严肃讨论之前，先把任务分个类。一类是 loop 型任务，反馈密集、目标单一，你用一个简单的 agent loop，体感上就能解掉约 80% 的问题；只要 harness 做得好，让它一直跑下去，理论上是有可能持续提升的。另一类，是真正大型、系统化的任务，由多个具备深度耦合拓扑结构的子任务构成，需要一步步深入推进。模型在这类任务里很容易 lost，往往解到第三层、第四层就开始发散。怎么让模型保持收敛、不发散，做好状态评估与目标管理，是后一类任务真正的难点。

2.由此引出本场最尖锐的一个判断：在现有的 long-horizon 能力与 benchmark 上，loop 是被过度重视的，而拓扑（topology）是被低估的。未来真实的任务，大概率是两者的 combine，我们在处理一个任务时，既会螺旋式地迭代某一部分的表现（这正是 recursive self-improvement，也是当下所有人都在 focus 的方向），也会同时推进整体的结构。能真正取代一个人正常工作流的那个“长程”状态，是“螺旋迭代 × 拓扑推进”的合体，而不是单纯把循环拉长。

3.为什么拓扑被低估？因为它很难标，而且很难标得既能防住 reward hacking、又足够 solid。相比之下，loop 型任务反馈密集、信号单一、容易标注，于是热度自然集中到了 RSI 一侧。

Insight 02

长程是表象，难度才是本质

4.METR 的长程任务榜显示，50% 成功率任务的运行时长已经达到 17 个小时（几周前还是 14 小时），扩展速度极快。但“长程”是一个相对、且容易误导的概念：长程 ≠ 难。loop 型任务可以跑得很久，却并不难；而一些更复杂的 playground 或 toB 任务，可能只跑了两个小时，却解决了大量层级式的 subtask，难度反而更高。现场有嘉宾给出的一个衡量框架是：长程任务的难度，取决于耦合图的复杂度，与中间信号的稀疏程度这两件事。

5.一个对照的观察是：长跑，更多是厂商愿意展示的姿态。发模型的时候，大家都爱放“在某个代码库（codebase）上连续跑了三十几个小时、提升了多少”这样的 case，看着那条一路向上的曲线，大家都很开心。但大多数真实用户，几乎不会放一个模型去跑十几、二十个小时的任务；即便不谈成本，主流的交互方式仍然是和 Codex、Claude Code 做一次交互，跑个九、十分钟，拿到一个足够好的修改结果。跑得很久的带 loop 的 auto research，和真的与人协作去解决一个 coding 任务，并不是同一回事。

6.真正的gap，在于人类工作与单 Agent 任务之间的结构差异。人的日常工作是并行的、多线程的、会被打断的、异步的，上午被老板插进来一件急事，下午做 research，晚上又被叫去改 PPT。一个看似做了三五个月的 project，“looks like”很长程，却很难被完整地镜像成一个 Agent 的 well-defined task。反过来，真正适合长程、且能随模型与算力 scaling 越做越好的，是那种极其 pure 的环境，比如 coding，交互对象是 bash 与命令行，用的是 Agent 最擅长的自然语言和代码，且有非常清晰的奖励。

7.toB 场景把难度推到极致：信号极端微弱，拓扑又极端复杂。老板做智能化转型，往往只给你一两句话，或一份非常不清晰、中间还会有无数次修改的复杂文档，且那些真实场景他根本无法为你复现。能不能“刷”得动一个领域，很大程度取决于它的 in-distribution 程度，code 的信号最好收集，所以最先被攻克，接着是 finance、office；而那些不常见的任务，需要的是另一种能力：在复杂文档里自己读懂说明、自己构建一个 world model、自己定义 verifier 与目标。现场提到的一个新 agentic benchmark 里，就明显分成两类 task：十几分的“送分题”（office / finance / cyber，大厂已逐一覆盖），与占比约 80%、谁都没见过的 task。这背后还有一个更根本的追问：AGI 到底要取代什么样的人类工作？是“造核弹”那种需要极高 level 全局视野的大型系统工程（稀缺，但经济价值极高），还是大多数人“今天和明天差不多”的日常 loop 型工作（正逐渐被覆盖，但单位价值有限、容易卡在 ROI）？由此也分出一条清晰的产品分野：一端是追求极致 long-running 上限、解决最难系统型任务的模型；另一端是高性价比、适配各种人类 loop 型工作的模型。

Insight 03

多 Agent 的本质，是给上下文“换血”

8.单 Agent 有一个隐蔽的退化曲线：用户第一次给的 prompt 往往超长、超精准、超高质量；但后续交互里说的话，是“继续”“你看一下”“汇报一下”，输入质量持续下降，输出质量也随之劣化（garbage in, garbage out，对 context 同样成立）。多 Agent 之所以能改善这一点，是因为 Agent 给 Agent 的 prompt 可以稳定保持高质量（不受人类“打 2000 字要 5–10 分钟”的注意力瓶颈限制），从而让整个系统进入一种“高质量共振”，而不是单 Agent 那条单调下滑的曲线。

9.但 Agent 是马尔可夫的：一开始设定的错误会累积，而让 Agent 自己 review 自己，只会带着这些累积的错误把自己的成果放大。讨论中给出的解法是三件套：其一，当观测到某个 Agent 行为产生变异时，由系统层重建一个新 Agent，并继承此前沉淀的 context / goal / experience；其二，持续做 context refresh，让所有上下文尽量保持“新鲜与健康”；其三，引入 QA 与 reviewer 两个角色，具备 QA 自检能力后，系统表现可提升约 22 个点，而 QA + reviewer 这两个角色，能让系统的延续性再多撑 2–4 个小时。这些实验在 GLM 5.1 / 5.2 上跑，一个 team 一天大约消耗 2–3B token。这套系统三到四天长跑的产出，也是拿去迭代模型本身：模型训练的 feedback 信号最明确，research 与 training 被认为是眼下长跑系统最合适的场景。大型系统任务在 loop 内的求解，本质都是 context scaling，并行地切、串行地切、在分段内做压缩，只要这件事做得足够干净，上限就一定会更高。

10.更底层的设计哲学，是一个被工程化的 “strange loop”。讨论中借用了侯世达《Gödel, Escher, Bach》里“自指”的思想：让整个系统自我镜像，每个 Agent 都能看到自己的 collaborator 是谁、状态健不健康、靠不靠谱、什么难度的任务可以交给它，从而在系统中实现自适应的任务分配。当然，自指与自适应也有代价：有人用 16GB 内存的 Mac mini 长跑，因系统自创建的 Agent 过多而直接卡死，资源管理由此成为多 Agent 系统绕不开的一环。

11.顺着这个方向，让“编排”本身变得可学、可搜，是另一个重要趋势。ChatDev 式地 1:1 模仿人类软件公司（CEO / CTO / 写代码的 / 审代码的 / 测试员，pipeline 式运行），在今天看来已显过时，它高度依赖人类经验，并不适配 Agent 的工作模式。取而代之的是：用线性搜索或 MCTS 在有限空间里搜更优的多智能体架构（如 AFlow 等工作）；训练一个动态调度的“编排者”模型（动几层、训几层），学会根据当前任务状态决定“下一步交给谁”；以及像 Kimi 的 agent swarm 那样，学会“何时该拉起多个 subagent 去做更宽的 exploration、何时不需要”。相比之下，在现场讨论看来，Claude Code 彼时的并行 subagent 搜索，更多还停留在“并行化”，尚未触及复杂的任务派发。

Insight 04

反馈是循环的命门：信号密度 > 通讯密度

12.为什么循环类任务现在做得好？因为它的反馈密集且单一。而系统型任务之所以难，是因为它的反馈本质上要给一个 process reward / process call，这种过程信号极难给。一个朴素却精准的类比：管一个 Agent，和管一个员工没什么不同，你让他干三天活、一点反馈都不给，他大概率搞出来的东西跟你想要的不一样。所以无论 feedback 来自环境、来自其他 Agent、还是来自 review，本质都是同一件事：模型需要更密集的反馈。

13.多 Agent 协作里，约 40% 的信息花在通讯上，很容易陷入“收到、收到、收到”的回声式低效率。一个被反复思考的方向是：Agent 之间为什么一定要用人类的离散 token 来沟通？能不能像把 thinking 放到 latent 下做推理那样，让 Agent 在 latent 空间通讯（共享 KV cache、甚至共享部分激活层）？一个现场讨论的共识是：通讯密度本身并不解决上限问题。把片段切得更碎，能让单个 Agent 对信息更鲁棒，但整个系统的错误信息仍在累积；真正清空错误，最终仍取决于你在什么时间点，给了一个足够好的 feedback、做了一次系统级的 update。

Insight 05

Scaling 的下一站：从“训模型”到“造环境”

14.Scaling 的重心，正从预训练、后训练，转向scaling environment 与 scaling verifier。一个核心痛点是：自己造题太窄，就那么几个人，能造多少题？最后只能覆盖少数 benchmark 分和极少数人的体验，落在一个很窄的区间，且不泛化。因此长期看一定要“逆向”：从真实、大用户量的产品里逆向出环境，尤其是去模拟“一个用户用了很久之后”的真实电脑环境，而不是凭空造出来的、过于简单的玩具环境。也正因如此，能沉淀海量真实任务、可被大规模逆向的体系，被认为可能性非常好。

15.这也解释了模型公司为何在产品化上明显加速：Codex 的 record and replay（录屏、记录 workflow）、Claude Tag 这类非常产品化的想法，开始进入模型公司的视野；至于“一家公司到底想覆盖什么”这个问题，在现场讨论看来，Anthropic 的 first-principle 很直接，哪个领域最能挣钱，就先用 intelligence 去 hack 哪个。与此同时，据现场讨论提及，Anthropic 也在探索 Loop / Dreaming / Outcomes 一类做审计与打分、用以增强 memory 与经验、强化自我改进 harness 的能力。

Insight 06

Self-Improvement：一场尚未被证明的信仰

16.自 2022 年的 APE 等早期工作以来，至今没有一个理论证明：我们今天的模型一定会 self-improvement。给它一些 failure 经验，它未必会朝正确方向走。今天大量所谓的自我改进，其实是把经验沉淀下来、不断试、不断穷举。差距在于：足够聪明的模型（如 Anthropic 的模型）可能错一次就知道第二次怎么做；而当下的多数模型，可能需要 5 到 10 次才知道下一条轨迹该怎么走，在一个 local region 的任务上，它的 failure 概率会非常高。于是，“如何评价一个模型的 self-improvement 能力”本身，仍是一个开放问题。

17.Self-improvement 的必要条件，是一个好的 reward，而它通常无法从模型内部获得。用模型内部状态（如 KL 散度）构造的奖励，大多只是 sharpen 分布（让分布更尖锐，从而在某些下游任务上表现更好），并不抬升能力上限。真正有效的 reward 需要外生构造：合适的环境、合适的 evaluation，乃至合适的 human-in-the-loop。现场的讨论，也的确分出了两种倾向：一边更信 human-in-the-loop 的人类 reward，一边押注 multi-agent / LLM-as-judge。但一个更实操的判据：任务若客观、对错分明，人就不必进来；若“用户喜欢与否”才是标准，就必须有人在 loop 里，因为人的 taste 与审美目前没法被很好地建模，人本就不是完全理性的。

18.一个清醒的类比：self-improvement 今天的位置，可能就像去年我们看 memory，当时以为 memory 不过是 storage、是 engineering，后来才发现它远不止于此。memory 同样被低估：在一个跨越 10 年、让模型不断 interest-shifting 的评测里，多数模型并不知道该用哪些新信息去覆盖哪些旧信息，表现相当差。而对产品而言，能让用户真切感到“它越来越懂我”的那种自我改进，收益往往来自 memory 的 evolving，本质是更好的context engineering。别忘了，数据提升也有天花板，那个天花板，是标注员 / 人类审核员审美的天花板，它并非无限。

Insight 07

落地的两端，与中间被浪费的“垃圾时间”

19. 垂类深度，仍是一道巨大的 gap。以咨询级 PPT 为例：Gamma 等工具已经做得不错，但咨询师那种一张幻灯片价值数万人民币的标准，当前大模型完全做不出来，这类任务复杂度极高（并不是简单的 loop），模型还无法做有效拆解、完成单页高信息密度的绘制工作。结论也很务实：不必 FOMO，更该去观察、亲自上手、与不同的真实用户交流，你会发现现在的模型还差得很远。

20.任务的价值，过去常被切成两端：一端是对时延要求极高、必须即时响应的交互；另一端是“放着跑、不关注时延”的长任务。而夹在中间的地带，比如“花 8 分钟帮用户干了一个 5 分钟的活”，曾被视为纯粹的“垃圾时间”，用户走也不是、等也不是。一个被低估的应用层机会，是预测任务耗时，并利用这段等待，把信息主动推送回给人（那个“发完任务刷一集短剧刚好回来”的段子，正是这种需求的朴素版本）。但“预测耗时”本质上类似“预测 reward / token 数”，很难做准、必有长尾，大概率只能过拟合到具体垂直场景。

如果这场讨论最后要留下一个注脚，也许就是：管一个 Agent，本质上和带一个员工没什么不同，你让他干三天活却一点反馈都不给，他交出来的东西多半就不是你想要的。我们离让 Agent 真正接管一个人的完整工作流，还差几个数量级的环境与数据、几个数量级更密更准的反馈信号，以及一个对“自我改进”到底成不成立的、尚未到来的回答。但至少，现在可供探索的道路已经很多了。

参考与延伸阅读：

本文第一部分的梳理，主要参考以下来源；第二部分的全部 Insight，均出自那场闭门讨论。

- Addy Osmani，《Loop Engineering》，2026 年 6 月 7 日，“循环工程”一词的命名与定义之作，六个零件与六类代价的源头。

- The Information，《Why Agent Loops Are Hot》，2026 年 6 月，agent loop 的来龙去脉，及 Anthropic 复古游戏 app“极简提示词 vs 循环”的对照实验。

- Cen Zhao 等，《Agent-in-the-Loop: A Data Flywheel for Continuous Improvement in LLM-based Customer Support》，Airbnb，arXiv:2510.06674，把人类反馈嵌入实时运营、将重训周期由“月”压到“周”的arXiv 论文。

- 《Loop Engineering: The Anthropic Playbook…》《The Self-Improving Agentic Loop…》《Loop Design: A Field Playbook for Agentic Systems》，2026 年围绕 loop engineering 的独立整理稿：将一次循环拆为发现、派活、验证、持久化、调度五个动作，并映射到 Anthropic 公开的 agent patterns（orchestrator–workers、evaluator–optimizer）；Stripe Minions 每周一千三百个 PR 的案例亦记述于此。

- Peter Steinberger（OpenClaw创建者，现就职于 OpenAI）在 AI Engineer Europe 的对谈，以及 Anatoli Kopadze 关于循环的长文，一线工作流与方法论的第一手视角。