BotOf TechAI / IoT / Full-Stack / 植物养护
返回首页Fable 5 的循环实操：从 /loop、/goal 到 grader 和 memory

Fable 5 的循环实操：从 /loop、/goal 到 grader 和 memory

·7 分钟阅读·
Claude CodeFable 5AgentWorkflowArchitecture

Fable 5 这类模型最值得关注的地方，不是单轮回答更漂亮，而是它在长任务里更愿意试错、读取反馈、调整策略，并把经验压缩成下一轮可用的状态。

所以使用 Fable 5 的重点不是“把 prompt 写长一点”，而是给它设计一个合适的循环。尤其是工程任务，最好不要让它自由发挥，而是让它在一个有目标、有评价、有记忆、有预算的系统里运行。

这篇更偏实操：如何用 /loop、/goal、grader sub-agent、memory 文件和 routines，搭一个能真正工作的闭环。

先判断：这个任务值不值得用 Fable 5

不要把 Fable 5 当默认档。它更适合混乱、长链路、需要多轮验证的任务。

任务是否适合原因
改按钮、改文案、补一个小测试不适合普通模型更便宜，验证简单
修复明确报错看情况单模块问题不需要；跨模块根因不清可以用
大型重构适合需要长上下文、规划和多轮验证
迁移框架或运行时适合需要理解旧架构、分阶段改、跑验证
性能实验 / 参数搜索适合需要不断试验、看日志、调整方案
数据库 schema 问答 / 长期分析适合需要跨 session memory 和事实沉淀
高风险生产操作不直接适合可以分析和开 draft，不能无审查执行

一句话：让 Fable 5 处理“需要保持目标并从反馈中调整”的任务，不要让它处理“一次就能写完”的任务。

一个可落地的目录结构

在仓库里先准备一组外部状态文件。不要把所有上下文都塞进一次对话。

.agent/
  VISION.md          # 成功是什么
  ARCHITECTURE.md    # 系统结构、关键模块、约束
  RULES.md           # 禁止事项、权限边界、风格约定
  EVAL.md            # 验收标准和评分规则
  LOOP_STATE.md      # 当前轮次、已尝试方案、下一步
  MEMORY.md          # 已验证事实、可复用规则、历史教训
  RUNBOOK.md         # 人类接管和回滚方式

这些文件看起来普通，但它们是 loop 的骨架。

文件作用写法重点
VISION.md定义方向不写愿景口号，写可判断结果
ARCHITECTURE.md给模型项目地图模块职责、边界、数据流、危险区域
RULES.md防止乱改禁止命令、敏感目录、分支规则、风格约束
EVAL.md给 grader 用具体、可检查、最好能跑命令
LOOP_STATE.md让本轮可恢复每次实验、结果、失败原因、下一步
MEMORY.md让未来不重踩坑只写已验证事实和泛化规则
RUNBOOK.md人类接管出错时停在哪里、找谁、怎么回滚

不要把 MEMORY.md 写成日记。它应该像一份被不断修订的工程知识库：事实、证据、适用范围、最后验证时间。

最小闭环：目标、执行、验证、记忆

Fable 5 的循环可以从一个很小的闭环开始：

关键是：每轮只做一个可解释的推进，不要一次让它改十个方向。Loop 的效率不来自大步乱跑，而来自每一步都能反馈。

/loop 和 /goal 分工不同

/loop 是重复触发；/goal 是完成条件。两者可以组合，但不要混淆。

能力解决的问题适合用法
/loop隔一段时间重复执行等 CI、轮询部署、定时扫描、观察日志
/goal不满足条件就继续修到测试绿、迁移到清单完成、实验达到阈值
scheduled task关闭终端后仍在本机定时运行每天早上生成摘要、定期检查文档漂移
Routine云端按 schedule / API / GitHub event 运行夜间 review、CI 失败分析、issue triage

一个常见组合是：

用 /loop 每 10 分钟检查 CI。
如果 CI 失败，启动 /goal：定位失败原因，提出最小修复，跑相关测试。
如果需要改生产配置、强推、删除文件，停止并交给人。

这不是“自动驾驶”，而是把等待、重复检查和低风险修复自动化。

Fable 5 的 loop prompt 模板

下面是一个适合长任务的模板。它的重点不是语气，而是边界和可恢复性。

使用 Fable 5 处理这个任务，但不要直接大范围改动。

目标：
- 完成 <具体目标>。
- 只有当 <验证命令 / 验收标准> 通过时才算完成。

上下文：
- 先读取 .agent/VISION.md、.agent/ARCHITECTURE.md、.agent/RULES.md、.agent/EVAL.md。
- 再读取 .agent/LOOP_STATE.md 和 .agent/MEMORY.md，确认之前试过什么。

执行规则：
- 每轮只提出一个主要假设或一个主要改动。
- 修改前写出为什么这一步最小、为什么可验证。
- 修改后运行指定验证命令。
- 不要触碰 .env、secrets、部署配置和主分支。
- 如果验证需要外部权限，停止并说明原因。

记忆规则：
- 把每轮尝试、结果、证据写入 .agent/LOOP_STATE.md。
- 只有经过验证的事实才写入 .agent/MEMORY.md。
- 把未证实猜测留在 LOOP_STATE，不要写成长期规则。

停止条件：
- 通过 <验证命令 / rubric> 后停止。
- 连续 3 轮没有新证据时停止。
- 超过 <预算或轮数> 时停止并交接。

这类模板比“请修好这个项目”可靠很多，因为它把 Agent 的工作方式变成了可审计流程。

Grader 要独立上下文

Lance Martin 的实验里，一个很重要的点是：让独立 grader 来判定目标是否满足，通常比让同一个模型自评更稳。原因不是神秘，而是上下文污染。

实现者已经在上下文里形成了自己的路线。它越努力，越可能为自己的结果找理由。独立 grader 拿到的是 diff、日志、rubric 和验收命令，比较容易保持冷静。

自评独立 grader
快，便宜多一次模型和工具调用
容易把局部成功当整体完成更接近客观验收
适合低风险小任务适合长任务、迁移、实验、生产候选
经常需要人再看一遍可以作为人审前的第一道门

建议把 grader 的输入限制在这些东西：

  • 任务目标；
  • EVAL.md；
  • diff；
  • 测试输出；
  • LOOP_STATE.md 的本轮记录；
  • 是否违反 RULES.md。

不要把实现者的完整推理过程都塞给 grader。否则 grader 很容易被实现者的叙述说服。

Memory 不是越多越好

Fable 5 的另一个强项是利用跨 session memory。但 memory 的写法决定了它是资产还是噪声。

一个实用的 memory 进阶流程是：

不要把每次失败都直接写成长期记忆。先调查，再验证，再提炼。否则 memory 会变成一堆未经证实的猜测，未来每一轮都会被污染。

Memory 内容是否应该长期保存
“某字段可能是 cents”不应该，放 LOOP_STATE.md
“已用 SQL 验证，price_cents 单位是 cent，样本见查询样例和 invoice 对账结果”应该
“测试偶尔失败”不应该，太含糊
“test/auth/session.test.ts 在 Node 22 下因 fake timer 顺序失败，复现命令是 ...”应该
“这个模块很乱”不应该
“订单状态流只能从 paid -> fulfilled，不能 paid -> cancelled，依据是 ...”应该

Memory 的质量，决定 loop 是越来越聪明，还是越来越固执。

Fable 5 更适合结构性实验

材料里的一个实验很有代表性：在参数受限的 ML 训练挑战里，Fable 5 更愿意尝试结构性改动，而不是只调常数。这给工程任务一个启发：Fable 5 最值得用在需要提出新路线的环节。

改动类型普通模型常见倾向Fable 5 更值得尝试的地方
Scalar tweak改阈值、改超参、改 timeout低成本模型足够
Local patch改一个函数、补判断Sonnet / Opus 往往够用
Structural change改训练流程、重组模块、换架构路径更适合 Fable 5
Long-horizon debugging多个日志、多个假设、反复实验更适合 Fable 5
Cross-session learning每轮沉淀规则，下轮复用更适合 Fable 5 + memory

所以实操上可以这样分配：

  1. 用便宜模型扫问题、收集上下文、生成候选假设。
  2. 用 Fable 5 选择结构性路线，做第一轮深入实验。
  3. 用独立 grader 验收。
  4. 用普通模型做机械补齐和文档整理。
  5. 高风险结果交给人审。

这比“所有事情都用最贵模型”更像生产系统。

一个工程修复 loop 示例

假设 CI 里有一组 auth 测试失败，但根因不明确。

目标：
让 auth 相关测试全部通过，并解释根因。

循环：
1. 读取失败日志和最近相关提交。
2. 提出一个根因假设。
3. 只做能验证该假设的最小改动或最小实验。
4. 运行 auth 测试。
5. 记录结果。
6. grader 检查：测试是否通过、解释是否有证据、是否引入范围外改动。
7. 失败则下一轮，不重复已证伪假设。

停止：
- auth 测试通过；
- 没有证据支持继续；
- 连续 3 轮没有新信息；
- 需要访问 secret 或生产系统。

配套状态表可以写在 LOOP_STATE.md：

RoundHypothesisActionEvidenceResultNext
1session cookie 过期逻辑变了只跑 session 测试并加日志日志显示 token 未刷新证实一半查 refresh 流程
2refresh mock 不兼容 Node 22改 mock 时序并跑单测单测通过，集成仍失败局部通过查集成配置
3测试环境缺少 clock reset加 afterEach reset全部 auth 测试通过通过交给 grader

这种状态表会显著降低“同一个错误反复试”的概率。

一个 Fable 5 实验 loop 示例

如果任务是优化一个训练 pipeline，不要给它一句“帮我把指标做高”。更好的写法是把实验节奏固定下来：

阶段要求
Baseline先跑原始 baseline，记录命令、时间、指标
Hypothesis每轮只能提出一个主要改动
Experiment保存配置、代码 diff、日志路径
Score用同一个脚本计算指标，不允许手工估计
Grader检查是否跑满约定实验数、是否真的提升
Memory只保存被验证的规律，比如某类结构改动有效

适合 Fable 5 的 prompt：

这是一个实验优化任务，不要只调常数。

先跑 baseline。每轮提出一个结构性假设，例如数据流、模型结构、训练流程或压缩策略。
每个实验都必须记录：改动原因、命令、指标、失败日志、是否保留。
如果某轮失败，但暴露了新信息，不要立刻回退；先判断是否值得继续沿该结构方向探索。
grader 只有在 baseline、至少 N 个实验、最终指标和 artifact 约束都满足时，才允许结束。

重点是“结构性假设”。Fable 5 这类模型的价值，往往不在更快做完机械改动，而在能否从反馈里调整路线。

一个 memory loop 示例

对于数据库问答、数据分析、业务规则梳理这类任务，memory 的收益很明显。

每个问题独立 session。
每轮先读取 MEMORY.md。
如果答错或不确定：
  1. 记录失败问题；
  2. 查询数据库验证；
  3. 把验证后的事实写成规则；
  4. 下轮回答前先查规则。

MEMORY.md 可以用这种格式：

## Verified facts

### pricing
- Fact: `orders.price_cents` stores cents, not dollars.
- Evidence: query `select price_cents from orders limit 5` returned integer cent values matching invoice totals.
- Last verified: 2026-06-11
- Use when: answering revenue, AOV, refund amount, invoice total questions.

## Invalidated assumptions

- Do not assume `users.region` is billing region. It is signup region. Billing region is in `billing_profiles.country`.

这种 memory 比“我之前好像看到过某字段”可靠得多。

权限和预算要写进 loop

能跑起来不代表能放心运行。任何无人值守的 loop 都要有权限和预算边界。

边界推荐写法
文件边界禁止改 .env、secrets/、部署配置、数据库迁移脚本，除非人确认
Git 边界只能开 draft PR，不能 push main，不能 force push
命令边界允许 test、lint、build、git diff；拒绝破坏性命令
Token 边界每轮预算、最大轮数、超预算写状态并退出
时间边界单轮最长运行时间，超过就交接
人类边界高风险、缺凭证、生产操作、需求冲突时必须停止

不要把 --dangerously-skip-permissions 当自动化方案。那不是 loop engineering，是把刹车拆掉。

从本地 loop 升级到云端 routine

建议按三步推进：

阶段目标进入下一阶段的条件
本地 /loop找到可重复流程prompt 稳定、验证清楚、失败能解释
本地 scheduled task让流程跨重启运行权限收紧、状态文件稳定、日志可读
Cloud Routine让流程脱离你的机器触发器清楚、connector 最小化、只开 draft 输出

不要一开始就把一个含糊任务丢进云端。先在本地把 loop 跑窄、跑稳，再升级触发层。

Routine 的 prompt 要像 runbook，不要像聊天：

每天 07:00 运行。

读取过去 24 小时失败的 CI 和新 opened PR。
只分析，不直接修改 main。
如果能定位低风险修复，创建 claude/ 前缀 draft branch 和 draft PR。
如果涉及安全、数据库迁移、生产配置，停止并写入人工处理清单。
最后把摘要发到指定位置：失败项、证据、已开的 draft PR、需要人判断的事项。

Routine 不是生产系统的全部。它只是触发和执行层。长期运行还需要队列、状态机、审计、补偿和人类控制面。

最后给一份检查清单

上线任何 Fable 5 loop 前，我会逐项检查：

检查项合格标准
目标一句话能判断完成与否
验证有命令、rubric 或独立 grader
状态LOOP_STATE.md 能恢复上下文
记忆MEMORY.md 只存已验证事实
权限写入范围、命令范围、connector 范围都最小化
成本有 token / 时间 / 轮数上限
分支只允许隔离 worktree 或 draft branch
人类接管触发条件明确
审计能看到它读了什么、改了什么、为什么继续
降级Fable 5 不适合时能切回便宜模型或停止

我的判断

Fable 5 的正确位置，不是“更聪明的聊天对象”，而是“长任务循环里的结构性推理引擎”。

它应该在这样的环境里工作：

  • 有清晰目标；
  • 有外部记忆；
  • 有独立 grader；
  • 有验证命令；
  • 有权限边界；
  • 有预算上限；
  • 有人类接管点。

如果缺这些东西，强模型只会让错误跑得更远、成本烧得更快。把 loop 设计好之后，Fable 5 才能把它擅长的自纠错、长上下文和跨 session 学习发挥出来。

真正的实操原则很简单：先闭环，再放权；先验证，再自动化；先让系统能停下来，再让它跑起来。

参考材料

  • Addy Osmani：关于 Loop Engineering、automations、worktrees、skills、connectors、subagents 与 memory 的长文，2026-06-09。
  • Codez：关于 Claude Code /loop、cron、Auto Mode、scheduled tasks、Routines 与触发器的长文，2026-06-05。
  • Rahul：关于 loop 成本、open / closed loop、fleet loop 与闭环框架的长文，2026-06-09。
  • Lance Martin：关于 Fable 5、自纠错 loop、grader sub-agent、Parameter Golf 和跨 session memory 的长文，2026-06-10。
← 返回所有文章