一文读懂什么是Loop，Claude Fable 5是Loop最严厉的父亲

最近Loop这个话题受到了很多关注。Claude Code之父Boris Cherny这两天在回顾cc一周年时提到，他现在的工作就是写Loop。

Boris这句话的背景是在过去一年半里，Anthropic内部的工程师经历了两次认知的转变。

第一次发生在大约一年半前。工程师开始意识到，他们不需要直接写源代码，只需要跟Agent说话，让Agent来写代码。

第二次正在发生。工程师不再直接跟Agent对话，而是跟Loop或例程交互，由Loop调度Agent，Agent再去写代码。

人从执行者，变成了系统设计者。

cc一周年回顾，可以看我的文章：

cc创始人对谈，Claude Code一周年回顾 ：内部经历两次认知跃迁，第三次正在路上

让模型反复尝试、每次都比上一次做得更好，是提升任务效果的常见做法。Claude Code里的/goal、Claude Managed Agent里的Outcomes，还有Codex的/goal，都是把这件事落地的具体工具，你可以直接拿来用在自己的任务上。

Loop到底是什么

谷歌云AI工程总监Addy Osmani给了一个清晰的描述：Loop Engineering，就是用你设计的系统替代你本人去提示Agent。

你不再是那个不断输入指令的人，你是那个设计循环结构的人。

Loop可以理解为一个递归目标：你定义一个目的，AI持续迭代直到完成。它大概由五个模块和一个记忆机制构成。

OpenAI的Codex和Anthropic的Claude Code，两款产品目前都已具备这五个模块。

模块一：自动化调度

自动化让Loop成为真正的循环，而不是你手动跑一次就结束的东西。

在Codex里，你在Automations标签页里创建任务，选好项目、Prompt、执行频率，以及是在本地检出环境还是后台工作树上运行。有发现的运行进入Triage收件箱，什么都没发现的自动归档。OpenAI内部用它做日常的事情：每天归类issue、汇总CI失败信息、写提交简报、找上周新引入的bug。自动化还可以调用Skill，用$skill-name替代粘贴一大堆指令，方便维护。

Claude Code的做法是通过调度和钩子。你可以用/loop按固定间隔运行Prompt或命令，可以设置cron任务，可以在Agent生命周期的特定节点触发shell命令，也可以把整套流程推到GitHub Actions上，关掉笔记本电脑它也会继续跑。

还有一个值得单独讲的指令：/goal。它不是按频率循环，而是一直跑到你写的条件为真才停。每一轮结束后，一个独立的小模型负责判断是否已完成，这意味着写代码的Agent不是给自己评分的那个。你写下"test/auth下所有测试通过且lint干净"，然后离开就行。Codex有同名功能，支持暂停和恢复。

模块二：工作树隔离

同时跑多个Agent的第一个问题，是文件冲突。

两个Agent写同一个文件，和两个工程师向同一行代码提交但彼此没沟通，是完全相同的麻烦。

git worktree解决了这个问题。它是一个在独立分支上的独立工作目录，和同一个仓库历史共享，一个Agent的改动物理上无法触碰另一个Agent的检出。

Codex内置了worktree支持，多个线程可以同时操作同一个仓库而不互相干扰。Claude Code通过git worktree、--worktree标志以及子Agent上的isolation: worktree配置实现同样的隔离，每个子Agent拿到一个新鲜的检出，结束后自动清理。

需要注意的是，worktree解决的是机械层面的冲突，你的Review带宽才是真正的上限。你能同时跑多少个Agent，取决于你有多少时间看它们的输出，而不是工具本身。

模块三：Skill

Skill解决的是一个基本问题：每次新对话，你不应该再重新解释一遍整个项目背景。

两款工具用的格式相同：一个包含SKILL.md文件的文件夹，里面放指令和元数据，外加可选的脚本、参考资料和资产文件。Codex用$或/skills调用Skill，或者在任务描述匹配时自动触发，这也是为什么Skill描述越准确越好，聪明的描述不如准确的描述管用。Claude Code的机制相同。

Skill的另一层价值是固化意图。Agent每次启动都是空白的，它会用自己的推断填补你没说清楚的地方。Skill是把意图写在外部：项目约定、构建步骤、某个曾经踩过的坑，写一次，每次运行都能读到。没有Skill的Loop，每轮都从零推导你的项目；有了Skill，它是在复利增长的。

Skill是撰写格式，Plugin是分发格式。要跨仓库共享或打包多个Skill，就封装成Plugin。

模块四：插件与连接器

只能看到文件系统的Loop，能做的事很有限。

Connectors建立在MCP协议之上，让Agent能读取issue tracker、查询数据库、访问staging API、往Slack发消息。Codex和Claude Code都支持MCP，为一个写的Connector通常在另一个里也能直接用。Plugin把Connectors和Skills打包在一起，队友一次安装，不用自己从头重建。

这是Agent说"这是修复方案"和Loop自动开PR、关联Linear票、CI绿了自动通知频道之间的差距。Connectors让Loop真正在你的实际工作环境里行动，而不只是告诉你它理论上能做什么。

模块五：子Agent

Loop里最有用的结构设计，是把写代码的和检查代码的分开。

写代码的模型给自己的代码打分，会打得太好看。用不同指令、有时还用不同模型的第二个Agent，会抓到第一个说服自己接受了的问题。

Codex按需生成子Agent，同时运行后汇总结果。你在.codex/agents/里用TOML文件定义自己的Agent，每个有名字、描述、指令，以及可选的模型和推理力度，让安全审查Agent用强模型跑高强度推理，让探索Agent用快速的只读模式跑。Claude Code在.claude/agents/里同样设置子Agent，组成Agent团队传递工作。两款工具里常见的分工是：一个探索，一个实现，一个对照规格验证。

子Agent会消耗更多token，因为每个都有自己的模型调用和工具使用。把token花在真正值得第二次确认的地方。

/goal在底层做的，本质上也是这个拆分：Loop是否完成，由一个新鲜的模型来判断，不是那个做了工作的。

加一个记忆机制

Loop的第六个组件，通常听起来太朴素：一个markdown文件，或一块Linear看板，任何存在于单次对话之外、记录已做什么和下一步做什么的东西。

但这是所有长期运行的Agent依赖的机制。模型在每次运行之间会忘掉一切，所以记忆必须在磁盘上，不能只在上下文里。Agent会忘，仓库不会。

一个完整Loop长什么样

把这些组件拼在一起，单个线程就变成了一个小型控制系统。

每天早晨，一个自动化任务在仓库上跑。它的Prompt调用一个Triage Skill，读取昨天的CI失败记录、未关闭的issue、最近的提交，把发现写进一个markdown文件或Linear看板。对于每个值得处理的发现，开一个独立的工作树，派一个子Agent去起草修复方案，再派第二个子Agent对照项目Skill和现有测试来审查这份草案。

Connectors让Loop自动开PR、更新票据。Loop处理不了的，进我的Triage收件箱。状态文件是整个系统的骨架，记录什么被尝试过、什么通过了、什么还悬着，明天早上的运行从今天停的地方继续。

你设计了一次，之后没有手动提示任何一步。

Loop做不了的三件事

Loop改变了工作，但它不会把你从工作里删掉。Loop越好，三个问题反而会越尖锐，而不是消失。

验证还是你的责任。无人看守跑的Loop，也是无人看守地犯错。分离验证子Agent和执行子Agent的全部意义，是让Loop说"完成了"这个词有点分量，但即便如此，"完成"是个声明，不是证明。要发出的代码，是你确认它能用的代码。

你对代码库的理解会腐烂。Loop发出代码的速度越快，实际存在的代码和你真正理解的代码之间的差距就越大。这是理解债。流畅的Loop只会让它长得更快，除非你读它产出的东西。

不作为也是一种风险。当Loop自己跑起来，很容易停止有自己的判断，拿到什么就接受什么。这是认知放弃。设计Loop，在有判断力的情况下做，是解药；为了逃避思考而做，是加速剂。同样的动作，相反的结果。

另一个值得关注的进展：Claude Fable 5的自校正实验

Anthropic内部工程师Lance Martin做了一组实验，专门测试Loop模式在最新模型上的效果。

他用的任务叫Parameter Golf，这是一个开源ML工程挑战，目标是在8张H100上用不到10分钟训练出能放进16MB产物的最佳模型。任务流程是：Agent编辑一个训练代码文件，启动训练，轮询日志，读取分数，决定下一个实验怎么做。

他用Claude Managed Agents（CMA）对比了Fable 5和Opus 4.7。CMA提供Agent运行环境和托管沙盒，适合长期运行的任务。

有一个关键细节：谁来评分很重要。研究发现，模型给自己的输出打分效果差，用独立的验证子Agent比自我评价效果更好，因为打分在独立的上下文窗口里完成。CMA的Outcomes功能会自动生成一个评分子Agent。

实验里，他给每次测试提供了包含九条可检验标准的评分文件，比如运行基准测试、跑20次实验等，最多运行8小时，Outcomes评分器确认所有标准都满足后才允许停止。

结果：Fable 5对训练流程的改进幅度大约是Opus 4.7的6倍。Fable 5倾向于下更大的结构性赌注，比如架构改动，也表现出更强的韧性，比如撑过一次量化回退，最终实现最大的收益。Opus 4.7的第一次实验产生了一个小提升，之后几乎全是同一个模式：调一个标量，测量，正向就保留。

内存能力上，他对比了Fable 5、Opus 4.7和Sonnet 4.6在一个SQL数据库顺序问答任务上的表现，使用CMA的记忆功能，每个Agent会话都能访问跨会话共享的挂载文件系统。

有效使用记忆的完整路径是：失败并记录，调查原因，核实诊断结论，提炼为通用规则，下次直接查规则而不是重新推导。

Sonnet 4.6停在第一步：存的是失败记录和猜测，很少查阅之前的笔记，需要特定任务的记忆指令才能改善表现。

Opus 4.7停在第三步：建了带不确定性标注的模式参考，但核实覆盖率低，7%到33%之间，中位数约17%。

Fable 5倾向于走完整个路径：最强的运行里，核实覆盖率达到73%（30题中22题），并把经验提炼成帮助未来任务的通用规则。

两款主流工具的对比

Claude Code和Codex在五个核心模块上的设计高度一致，只是名字和入口有所不同。

写在最后

Boris Cherny的那句话，最后落地的意思不是工作变简单了，而是杠杆支点移动了。

以前杠杆在Prompt，写好Prompt就能从Agent那里得到好结果。现在杠杆在Loop的设计，你设计的系统质量决定了产出的质量。

同样的Loop，两个人用会产生完全不同的结果。一个人用它更快地推进自己深度理解的工作，另一个人用它来回避真正理解工作。Loop不知道这个区别，你知道。

这也是为什么Loop设计比Prompt工程更难，不是更容易，Loop需要你有很深的工程技术背景，还要烧的起tokens，设计一个能生成高质量代码的Loop，需要疯狂的设置和监督，以确保它以正确的方式完成。

但现在有个严重的问题，Claude Fable 5 已经被A厂设计成一个可以随意操纵你研究的模型了，Fable 5如果认为你的研究/工程有“害”就会秘密降低其智商不告诉你或者直接不执行，最无语的是Fable 5可能还会故意误导或提供错误信息，这已经引起行业公愤了，就算loop设计的再好，有时候你可能做的一切都只是徒劳。

参考：

https://x.com/RLanceMartin/status/2064397389189071163

https://x.com/addyosmani/status/2064127981161959567

--end--

最后记得⭐️我，每天都在更新：如果觉得文章还不错的话可以点赞转发推荐评论

/...@作者：你说的完全正确（YAR师）