Agent 工程 on 鬼哥的空间

Loop Engineering：Agent 不是跑一次，而是活在循环里

Wed, 17 Jun 2026 00:00:00 +0000

最近一段时间，AI 开发讨论里有一个越来越热的词：Loop Engineering。

它把很多 AI 开发者过去两年跟 coding agent 协作沉淀下来的经验，逐渐聚集到一个共识上：你不应该再只是提示 coding agent，而应该设计会提示 agent 的循环。

鬼哥这篇引用 LangChain 团队的技术文章 The Art of Loop Engineering，来拆一下这个正在升温的工程话题。后面还有一篇来自 Google、同样围绕 Loop Engineering 的文章，更偏时间维度和落地实践，也值得期待。

过去两年，我们跟 coding agent 协作，大概是这个姿势：

1
2
3
4
5
6


我写 prompt
 -> agent 生成代码
 -> 我读结果
 -> 我补充上下文
 -> agent 再改
 -> 我再验

这当然有效。到今天为止，直接提示 agent 依然是最高性价比的日常操作。

但它有个天花板：你始终是循环里的调度器。任务从哪里来、下一步做什么、做完怎么验、失败怎么记、明天怎么接着跑，全都靠你脑子里那条线牵着。

Loop Engineering，本质上是把这条线从你的脑子里拿出来，做成外部系统：

1

发现任务 -> 分配执行 -> 隔离改动 -> 独立验证 -> 记录状态 -> 决定下一步

Prompt 还是存在，但它被放回了一个更大的机器里。你不再只是写一句话让 agent 干活，而是在设计 agent 干活的方式。

一个 Agent 最危险的幻觉，不是编错代码，而是跑完一遍就以为自己完成了任务。LangChain 这篇文章把 Agent 系统的核心能力拆成四层循环：agent loop、verification loop、event-driven loop、hill climbing loop。这个拆法很朴素，但对做过真实 Agent 工程的人来说，几乎每一层都踩过坑。

为什么我觉得这篇文章值得单独拎出来

那两篇的核心判断是：模型越强，工程师越不该把精力只花在 prompt 上，而应该设计模型工作的系统。

LangChain 这篇文章往前推了一步：它没有只说“要做系统”，而是把系统拆成了一个更可操作的结构：

层级	它解决的问题	典型失败模式
Agent loop	模型如何一步步调用工具完成任务	一次输出就收工，没计划、没状态
Verification loop	怎么知道这一步真的对了	自我感觉良好，错了也继续往下跑
Event-driven loop	Agent 怎么响应外部世界变化	只能同步问答，无法长期驻留
Hill climbing loop	系统怎么越跑越好	每次失败都是一次性事故，没有积累

这四层合起来，其实就是 Agent 从 demo 走向生产的路线图。

第一层：Agent loop，不是聊天，是“观察-行动-再观察”

最基础的一层是 agent loop。

很多人第一次做 Agent，会把它理解成“LLM + tools”：模型看一眼任务，决定调用哪个工具，拿到结果，再继续生成。这当然没错，但还不够。

真正的 agent loop 至少要包含四件事：

1

observe -> decide -> act -> update state -> observe again

也就是说，Agent 不是在“回答问题”，而是在一个不断变化的状态里行动。它每调用一次工具，世界就变了一点：文件被改了，网页打开了，数据库返回了新结果，用户可能又插了一句话。下一步动作必须基于新的状态，而不是基于最开始那段 prompt。

我自己用 Claude Code / Codex 做开发时，最明显的分水岭就是这里。弱 Agent 像一个“高级补全器”：你给它一个任务，它生成一坨代码，然后等你验尸。强一点的 Agent 会自己读文件、跑测试、看错误、再改，整个过程已经是一个小型闭环。

但只靠这一层还不够。因为 Agent loop 解决的是“会不会动”，不是“动得对不对”。

第二层：Verification loop，裁判必须独立

Agent 最容易犯的错，不是不会做，而是做错了还解释得很合理。

所以第二层是 verification loop：每一轮行动之后，系统要有一个明确的验证环节，判断结果是否满足标准。如果不满足，就把反馈送回 Agent，让它修正，而不是直接把错误带到下一步。

这跟我在本地折腾模型、写自动化脚本的体感完全一致：没有 verifier 的 Agent，越勤奋越危险。 它会非常积极地把错误扩散到更多文件、更深的状态里。

一个实用的 verification loop 可以长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


agent proposes change
 |
 v
run deterministic checks
 |
 v
LLM judge reviews ambiguous quality
 |
 v
pass -> continue
fail -> send structured feedback back to agent

这里有两个关键点。

第一，能用确定性检查的地方，别让 LLM 当裁判。测试、类型检查、lint、SQL 校验、schema validation，这些都应该是硬规则。

第二，必须用 LLM 判断的地方，也尽量让它成为独立裁判。不要让生成答案的同一个上下文顺手给自己打分。模型自评经常带着自己的思路滤镜，看不到真正的问题。

第三层：Event-driven loop，让 Agent 从“工具”变成“服务”

前两层解决的是一次任务内部的闭环。第三层 event-driven loop，解决的是更生产级的问题：Agent 怎么在真实世界里长期运行？

现实系统不是你问一句它答一句。真实系统里会发生各种事件：

用户发来新消息
GitHub 出现新 issue
CI 失败
数据库里多了一条异常记录
定时任务触发
人类审批通过或驳回

一个 event-driven Agent 不应该只是被动等待 prompt，而应该能被事件唤醒，读取上下文，恢复状态，执行下一步，然后再次挂起。

这也是 LangGraph 这类框架一直强调 state、durability、interrupt/resume 的原因。没有这些能力，Agent 只能做“同步聊天机器人”；有了这些能力，Agent 才能接近“后台工作人员”。

我觉得这一层对 AI 开发者特别重要，因为很多 Agent 项目死在这里：demo 里看起来很聪明，接到生产事件之后就不知道自己是谁、之前做过什么、现在该从哪一步继续。

一个更像生产系统的 Agent，应该长这样：

1
2
3
4
5
6


event arrives
 -> load thread / task state
 -> decide next action
 -> call tools or ask human
 -> persist state and trace
 -> wait for next event

第四层：Hill climbing loop，真正的复利在系统之外

最外层，也是最容易被忽略的一层，是 hill climbing loop。

前三层让 Agent 能跑、能验、能响应事件。第四层要回答的问题是：这个系统跑了一百次之后，有没有变得更好？

如果每次失败都只是“这次模型没发挥好”，那你永远在原地打补丁。Hill climbing loop 要做的是把失败变成可积累的工程资产：

traces：记录 Agent 每一步为什么这么做
evals：把失败案例沉淀成可重复评测
feedback：把人类纠错变成结构化信号
prompt / policy changes：把经验固化到系统行为里
regression checks：防止修好一个场景又弄坏另一个场景

这也是为什么我越来越觉得 LangSmith、OpenTelemetry、eval harness 这些东西不是“上线后再补”的配套工具，而是 Agent 工程的主干。

没有 trace，你不知道它为什么失败；没有 eval，你不知道改动是否真的变好；没有反馈闭环，你只是每天给同一个坑换名字。

Human oversight 不是“最后点一下确认”

LangChain 文章里还有一个横跨四层的点：human oversight。

很多系统把 human-in-the-loop 做成一个很浅的审批按钮：Agent 生成结果，人类点 approve 或 reject。这个当然有用，但太窄了。

更好的 human oversight 应该分布在不同层级：

位置	人类做什么	价值
Agent loop	在关键工具调用前确认	防止不可逆操作
Verification loop	对模糊质量给判断	弥补自动评测盲区
Event-driven loop	在异常分支里接管	避免系统卡死或误操作
Hill climbing loop	标注失败、调整 rubric	让系统长期进化

换句话说，人类不是 Agent 的“老板”，而是整个循环系统里的高价值传感器和调参者。

对 AI 开发者的实操建议

如果你正在做 Agent，不要一上来就问“该用哪个模型”。

先把你的系统画成四层循环，然后逐层检查：

Agent loop：它是否真的会观察状态、调用工具、更新状态、继续行动？
Verification loop：每一步有没有可执行的验收标准？能不能自动跑？
Event-driven loop：它能不能从外部事件恢复上下文，而不是每次从零开始？
Hill climbing loop：失败案例有没有沉淀成 trace、eval、规则或测试？

如果这四层里有一层是空的，你的 Agent 很可能还停留在 demo 阶段。

更直接一点：别再只调 prompt 了，把 prompt 放回循环里看。 Prompt 是 Agent 的一部分，但不是 Agent 系统本身。真正决定可靠性的，是状态、验证、事件、观测和反馈如何组成闭环。

Takeaway：下次设计 Agent，先画循环

我会把 LangChain 这篇文章的核心压缩成一句话：

Agent 工程不是让模型更聪明，而是让系统在每一次行动之后都能变得更确定。

下一次你要做一个 Agent，不妨先别打开代码编辑器。先画四个圈：

这个 Agent 怎么行动？
它怎么验证自己没有跑偏？
它怎么响应真实世界的事件？
它怎么从失败里长期爬坡？

四个圈画清楚，再选模型、写 prompt、接工具。顺序反了，你大概率会得到一个很会说话、但不能放心托付的 demo。

参考资料

别再只会提示词了：下一代程序员要会设计 Agent 循环

Wed, 17 Jun 2026 00:00:00 +0000

你以为 AI 编程的下一步是“写出更好的 prompt”？可能错了。

Addy Osmani 最近在 X 上写了一篇长文：Loop Engineering。他的判断很直接：你不应该再只是提示 coding agent，而应该设计会提示 agent 的循环。

这句话听起来像一句漂亮口号，但背后其实是 AI 编程工作流的重心迁移：从“人坐在驾驶位，一轮一轮指挥模型”，变成“人设计一个小系统，让它发现任务、分配任务、验证结果、记录状态，然后继续下一轮”。

Prompt engineering 还没死，但它不再是杠杆最大的位置

过去两年，我们跟 coding agent 协作，大概是这个姿势：

1
2
3
4
5
6


我写 prompt
 -> agent 生成代码
 -> 我读结果
 -> 我补充上下文
 -> agent 再改
 -> 我再验

这当然有效。到今天为止，直接提示 agent 依然是最高性价比的日常操作。

Addy 说的 loop engineering，本质上是把这条线从你的脑子里拿出来，做成外部系统：

1

发现任务 -> 分配执行 -> 隔离改动 -> 独立验证 -> 记录状态 -> 决定下一步

Prompt 还是存在，但它被放回了一个更大的机器里。你不再只是写一句话让 agent 干活，而是在设计 agent 干活的方式。

一个 Agent loop 至少需要五个零件

Addy 把这个循环拆成五个核心零件，再加一个外部记忆层。

零件	作用	没有它会怎样
Automations	定时发现任务、触发运行	每次都要人手动想起要检查什么
Worktrees	让多个 agent 并行但互不踩文件	并发一开，代码库变事故现场
Skills	固化项目知识和工作约定	每次会话都从零猜你的项目习惯
Plugins / Connectors	接入真实工具和数据源	agent 只能在文件系统里自言自语
Sub-agents	拆分执行者和验证者	写代码的人顺手给自己打满分
Memory	记录已做、待做、失败和下一步	模型每轮都忘，循环无法延续

这几个词看起来像产品功能列表，但组合起来才是重点。

单独看，automation 只是定时任务；worktree 只是 Git 技巧；skill 只是文档；connector 只是 MCP；sub-agent 只是多开一个模型。

但放在一起，它们变成了一种新的工作单元：不是一个 agent，而是一条可以重复运行的工程流水线。

Automations 是心跳：它让循环真的会“再来一次”

循环和一次性任务最大的区别，不是复杂度，而是有没有心跳。

没有 automation，你只是今天心血来潮跑了一次 agent。
有 automation，它明天还会来，后天还会来，出事时会把结果丢进你的 inbox。

Addy 举的例子很具体：

每天做 issue triage
总结 CI 失败
写 commit briefing
找出最近引入的 bug
定时运行某个 skill，而不是粘贴一大坨 prompt

这里的关键不是“自动化很酷”，而是任务发现被系统化了。

很多工程工作其实死在第一步：不是没人会修，而是没人持续看。CI 偶尔红一次、issue 堆一点、依赖慢慢旧一点、代码质量每天滑一点。人类对这种缓慢腐蚀很迟钝，循环不会。

Worktrees 是并行的刹车系统

只要你让多个 agent 同时改同一个 repo，最先坏掉的通常不是模型能力，而是文件冲突。

两个 agent 同时改同一个文件，本质上和两个工程师同时改同一段代码一样：不是不能做，而是你必须有隔离边界。

Git worktree 的价值就在这里。每个 agent 在自己的 checkout、自己的 branch 里工作，改动不会直接踩到另一个 agent 的现场。

这让并行从“看起来很爽”变成“至少机械上可控”。

但别高兴太早。worktree 解决的是文件层面的碰撞，不解决人的 review 带宽。

你可以同时开 5 个 agent，但如果你只能认真 review 1 个 PR，那么系统吞吐量的瓶颈仍然是你。并行不是免费午餐，它只是把瓶颈从执行转移到判断。

Skills 是意图的缓存

我越来越觉得，skill 最被低估的地方不是“复用提示词”，而是它把项目里的隐性规则变成了显性资产。

每个成熟项目都有一堆口头约定：

这个目录不能乱动
这个测试必须先跑
这个 API 不能破坏兼容性
这类 UI 不能做成营销页
我们上次踩过这个坑，所以现在不这么写

如果这些东西只存在于人的脑子里，agent 每次进来都会重新猜一遍。猜对了叫聪明，猜错了叫事故。

Skill 的意义是把这些判断写在外部，让 agent 每次运行都能读到。

这也是 loop engineering 里很关键的一点：循环要长期跑，就不能每次都重新理解世界。 它需要一套可积累、可维护、可版本化的项目知识。

Connectors 让循环碰到真实世界

一个只能看本地文件的 agent，能做的事很有限。

真正有用的 loop 往往要碰到真实系统：

GitHub issue 和 PR
Linear / Jira ticket
Slack / 飞书通知
CI 日志
数据库查询
线上监控
staging API

这就是 connector 的位置。MCP 这类协议的价值，不只是“让 agent 多几个工具”，而是让 loop 能把状态从真实工作流里拿进来，再把结果写回去。

差别很大：

普通 agent	Loop + connectors
“我建议你这样改”	直接开 PR
“这个 issue 可能相关”	自动链接 ticket
“CI 好像失败了”	读取日志、定位原因、发修复分支
“你可以通知团队”	CI 绿了以后发 Slack

前者是助手，后者更像一个后台工作人员。

Sub-agents：不要让写代码的人当唯一裁判

在无人值守循环里，最危险的一句话是：“看起来完成了。”

模型很擅长把自己刚刚做的事解释得很合理。它写了代码，它也知道自己想表达什么，所以它很容易忽略读者、测试、边界条件和真实需求。

所以 loop 里最值得花 token 的地方，往往是 maker / checker 分离：

1
2
3


Explorer 负责读上下文
Implementer 负责改代码
Verifier 负责按 spec 和测试挑刺

Verifier 不一定总是另一个大模型。能用确定性检查的地方，应该优先用测试、lint、type check、schema validation。

但只要涉及模糊质量，比如架构是否过度、文案是否误导、交互是否符合用户习惯，一个独立的 sub-agent 就很值钱。

循环越自动化，验证越不能省。 因为你不在现场时，错误也会自动化。

Memory 是循环的脊柱

Addy 在文里提到一个看起来很朴素、但非常重要的东西：外部记忆。

它可以是一个 Markdown 文件，也可以是 Linear board，甚至是一个很普通的状态表。关键是它必须活在单次对话之外。

原因很简单：模型会忘，repo 不会；聊天会结束，文件还在。

一个长期运行的 loop 至少要记住：

昨天发现了什么
哪些任务已经尝试过
哪些方案失败了
哪些检查通过了
哪些问题需要人类决策
下一轮应该从哪里继续

没有这个状态文件，所谓 loop 只是每天重复失忆。
有了它，agent 才能在多次运行之间接力。

这也是我觉得很多 AI 自动化项目跑不久的原因：大家拼命优化 prompt，却没有给系统一个可靠的记忆脊柱。

一个真实 loop 可以长什么样

把这些零件拼起来，一个早晨自动运行的 coding loop 大概长这样：

1
2
3
4
5
6
7
8
9


每天 9:00 automation 启动
 -> 调用 triage skill
 -> 读取昨天 CI、issues、recent commits
 -> 把发现写入 state.md 或 Linear
 -> 对值得处理的问题创建 worktree
 -> sub-agent A 起草修复
 -> sub-agent B 按项目 skill 和测试验证
 -> connector 创建 PR / 更新 ticket / 通知频道
 -> 未处理事项回到 triage inbox

你实际设计的是一条小型生产线。

最有意思的是，人类的工作没有消失，而是换了位置。你不再逐步提示每个 agent，而是在设计：

哪些任务值得自动发现
哪些检查必须硬性通过
哪些情况要中断给人
哪些状态要写下来
哪些权限不能交出去

这不是“少干活”那么简单。它更像从写脚本的人，变成设计操作系统的人。

Loop Engineering 的风险：你会更快地失控

Addy 的文章里有个很重要的提醒：这东西还早，而且 token 成本、质量下降、slop 都是真问题。

我会把风险拆成三类。

第一，验证风险。
没有可靠 verifier 的 loop，只是在自动制造自信的错误。

第二，理解债务。
loop 帮你产出越快，如果你不读、不理解、不复盘，你和代码库之间的距离就会越拉越大。

第三，认知投降。
最舒服的姿势是“让它跑吧”。但如果你只是为了逃避判断而设计 loop，它会把你的懒惰放大成系统性风险。

这就是 loop engineering 比 prompt engineering 更难的地方：prompt 错了，通常只坏一次；loop 错了，会重复坏。

Takeaway：先设计循环，再让 agent 跑

我觉得 Addy 这篇长文最值得带走的，不是某个工具功能，而是一种工作顺序：

先定义循环要解决什么问题。
再决定它如何发现任务。
给每个执行单元分配隔离环境。
把项目知识写成 skill。
用 connector 接入真实工具。
用 verifier 或 sub-agent 检查结果。
把状态写到对话之外。
最后才是：让 agent 开始跑。

换句话说，不要一上来就问“我该怎么 prompt 它”。先问：这个循环的输入、状态、验证、退出条件和人工接管点在哪里？

Loop engineering 不是把工程师拿掉。恰恰相反，它要求工程师更像工程师：少一点临场催促，多一点系统设计；少一点“帮我改一下”，多一点“这条生产线为什么可信”。

Build the loop. Stay the engineer.

参考资料

别再调教模型了：聪明人都在设计循环

Wed, 10 Jun 2026 00:00:00 +0000

Anthropic 的工程师 Boris Cherny 有一句话被反复引用：「我的工作就是写循环（My job is to write loops）。」

这句话第一次听像段子，听第二遍你会发现它在描述一个范式转移。过去我们用大模型，本能是去「调教」它——改 prompt、加 few-shot、写一长串「你必须……你不能……」的规则。但当模型本身已经足够强，真正决定产出质量的，往往不再是你怎么指挥它，而是你给它套了一个什么样的循环。

Anthropic 的 Lance Martin 最近分享了他用新一代 Claude 模型（内部代号 Fable 5，Mythos 级别）做实验的两个心得。两个都不是 prompt 技巧，而是关于怎么设计循环。下面我把它整理成中文，并加上我自己的一些体感。

为什么是「循环」，而不是「prompt」

先说清楚这个范式差在哪。

传统用法是一次性的：你写一个尽可能完美的 prompt，模型吐一个答案，好不好全看这一发。这本质上是在赌模型的「直觉」。

循环用法是迭代式的：你不再追求一发命中，而是给模型套一个「跑 → 拿反馈 → 自我纠正 → 再跑」的环，让它在一个评判标准（goal 或 rubric）上不断爬坡，直到达标才停。

	一次性 prompt	设计循环
你优化的对象	prompt 本身	环境与反馈信号
模型的角色	一次输出	反复试错、自我修正
决定质量的关键	你的措辞	评判标准设计得好不好
适合的任务	简单、确定性强	长程、可验证、能爬坡

Claude Code 里的 /goal 和 Claude Managed Agents（CMA）里的 Outcomes，就是把这套通用配方变成了你能直接用的原语。它们的本质都是：给环境注入一个反馈信号，让模型自己跟这个信号死磕。

第一招：自我纠正循环

新模型一个被反复验证的特性是——它特别擅长在循环里自我纠正。一个设计良好的 goal 或 rubric，相当于给 Claude 运行的环境加了一个反馈源：它跑一轮、通过 goal/rubric 收集反馈、修正自己，然后继续，直到标准被满足。

这里有一个最容易被忽略、却最关键的点：谁来当裁判。

直觉上你可能觉得，让模型自己检查自己的输出不就行了？但 Anthropic 的实验反复发现，模型在「自我批判」上是有系统性缺陷的——它很难客观地挑自己输出的毛病（Prithvi Rajasekaran 在 Anthropic 工程博客里专门写过这个现象）。

解法是：用一个独立的 verifier 子 agent 来打分，而不是让主 agent 自我批判。 因为打分是在一个独立的上下文窗口里完成的，不受主 agent 思路的污染，效果明显更好。CMA 的 Outcomes 就是帮你自动 spawn 一个 grader 子 agent 来做这件事。

下面这张表把两种实现方式拆得很清楚——无论是 Claude Code 的 /goal 还是 CMA 的 Outcomes，骨架都是一样的五件套：目标、裁判、循环、边界、退出条件。

注意「裁判（The judge）」这一行：/goal 用一个独立的 grader 模型（Haiku），CMA 用一个独立的 grader 子 agent——两者都刻意把评判放到了主流程之外。 这不是实现细节，这是这套方法能 work 的核心原因。

Parameter Golf：一个能跑 8 小时的玩具实验

Lance 用了一个开源的 ML 工程挑战 Parameter Golf 来测试：在 8 张 H100 上、10 分钟内，训练出一个能塞进 16MB 的最强模型。

这个挑战很像 Karpathy 的 autoresearch 项目——它考验的不是模型会不会写代码，而是一个 agent 能不能像研究员一样工作：改训练代码（一个 train_gpt.py 文件）、启动训练、轮询日志、读分数、然后决定下一个实验做什么。这是一个典型的长程、可验证、能爬坡的任务，正好是循环的主场。

他给了一个有 9 条可检查标准的 rubric（比如「跑一个 baseline」「跑 20 个实验」），让 Parameter Golf 最多跑 8 小时，由 Outcomes 的 grader 确认所有标准都满足后才允许 Claude 停手。结果：

Fable 5 把训练 pipeline 优化了约 6 倍于 Opus 4.7。 但比这个数字更有意思的是两个模型的实验风格差异：

Fable 5 敢下「结构性」的大注（比如改架构：TRAIN_SEQ_LEN=2048 带来 −0.0179、overlapped sliding-window eval 带来 −0.0207），而且有韧性——它甚至顶着一次量化回退继续推，最后拿到了最大的一次提升。
Opus 4.7 第一个实验拿了个小赢，然后几乎所有后续实验都在复制同一个模板：调一个标量、测一下、有正收益就留下。稳，但天花板低。

看图里那条蓝线（Fable 5）是怎么一个台阶一个台阶往下砸的，红线（Opus 4.7）则基本是平的——这就是「敢赌结构性改动」和「只敢调标量」的区别。循环给了模型试错的空间，而更强的模型会用这个空间去下更大的注。

第二招：记忆——跨会话的外层循环

如果说自我纠正是单次会话内的内层循环，那记忆就是跨会话的外层循环：Claude 在一次会话里把经验写进记忆，这些记忆能在未来的会话里被取回。

Lance 用 Continual Learning Bench 1.0 里的一个任务来测：给 agent 一个 SQL 数据库，让它回答一连串问题。每个问题是一个独立的 agent 会话，会话之间靠记忆来传递经验。他用 CMA 的记忆功能给每个 agent 挂载一个可跨会话共享的文件系统。

他观察到，有效使用记忆是有梯度的，从低到高是这么一条进阶链：

失败（fail）：做错了，把它记下来
调查（investigate）：在继续之前，搞清楚为什么错
验证（verify）：把诊断变成一个被核实过的事实
提炼（distill）：把验证结果升华成一条通用规则
查阅（consult）：下次直接读这条规则，而不是重新推导一遍

三个模型卡在了不同的台阶上，差距非常直观：

模型	卡在哪一步	表现
Sonnet 4.6	第 1 步（失败）	记忆只是一堆失败笔记和没验证的猜测（「也许是 prc 不是 prc_usd？」），几乎不回头查阅。得分 0.330，跟无记忆的 baseline 几乎没差
Opus 4.7	第 3 步（验证）	会建带不确定标记的 schema 参考（「可能是以分为单位？待验证」），但验证覆盖率低，只有 7–33%（中位数约 17%）。得分 0.700
Fable 5	走完全程	最强的几次运行里验证覆盖率高达 73%（30 题里验证了 22 题），并能把学到的东西提炼成通用规则，反哺未来任务。得分 0.839

看右边那张收敛曲线特别有感觉：带记忆的实线和无记忆的虚线，差距随着问题数累积越拉越大。 记忆不是「记下来」就完事了，关键在于你的 agent 能不能走完「失败 → 调查 → 验证 → 提炼 → 查阅」这条链。Sonnet 4.6 停在记笔记，Fable 5 在建知识库——这就是 0.330 和 0.839 的差距。

一个实操提醒：如果你的模型只走到第 1 步（像 Sonnet 4.6 那样），你需要给它针对具体任务的记忆指令来往上推。记忆这东西，模型越弱越需要你手把手教它怎么用。

我的体感：这其实是在重新分配「智能」

整理完这两个实验，我自己最大的感受是：Agent 工程正在从「怎么问」转向「怎么搭环境」。

过去一年我自己用 Claude Code 的体验也印证了这点。早期我花大量时间打磨 prompt，恨不得把每一步都写死。但模型一强，这套做法的边际收益就崩了——你写的规则越细，反而越限制它。真正让产出质变的，是另外两件事：

给它一个可验证的目标，然后闭嘴让它自己跑。/goal 这类原语的价值就在这——你定义「什么叫做完了」，剩下的交给循环。
让它管理自己的上下文，包括往记忆里写、从记忆里读。你不需要每次都把背景重新喂一遍。

Lance 那句话我很认同：与其直接 prompt 和 steer 模型，不如设计循环，让模型自己根据环境反馈做自我纠正（比如 /goal 或 Outcomes），并管理自己的上下文（比如记忆）。

换个角度说，你作为工程师的「智能」，正在从「写在 prompt 里」迁移到「写在循环结构里」。前者是一次性的指令，后者是可复利的系统。

Takeaway：下次构建 Agent，先问自己四个问题

如果你也想用循环的思路构建 agent，把下面四个问题贴在显示器上：

目标可验证吗？ 能不能写出一个 rubric / goal，让一个独立的裁判明确判断「做完了没有」？如果不能，先把任务拆到能验证为止。
裁判独立吗？ 千万别让主 agent 自我批判。用一个独立的 grader 模型或子 agent，在干净的上下文里打分。
循环有边界吗？ max_iterations、时间上限、退出条件——别让它无限跑。
记忆走完链路了吗？ 检查你的 agent 是停在「记笔记」，还是真的在「失败 → 调查 → 验证 → 提炼 → 查阅」。停在第一步的记忆约等于没有。

想上手的话，可以直接问最新版的 Claude Code——它能用内置的 /claude-api skill 告诉你 Fable 5 的 prompting 最佳实践、/goal、Claude Managed Agents 这些 API 特性怎么用。

说到底，写 prompt 是在赌一次直觉，设计循环是在搭一套能自我改进的系统。 模型越强，后者的回报越高。

参考资料

原推文：Lance Martin (@RLanceMartin) — Designing loops with Fable 5
Parameter Golf：开源 ML 工程挑战（16MB 模型，10 分钟，8×H100）
Continual Learning Bench 1.0：跨会话记忆基准