title: " Fable 5 Loop实战 | /goal到/schedule" category: 人工智能 tags:

上一篇讲上下文管理。

这一篇讲 Fable 5 更高阶的用法：

Loop。

也就是让模型在你设定的条件下自己循环，不需要你每一轮都手动发下一句。

这件事强，也危险。

强在：

重复性工作可以外包。
长任务可以自己推进。
失败可以自己修。

危险在：

停止条件不清楚，它会空转。
权限边界不清楚，它会越界。
成本边界不清楚，它会烧钱。

所以 Loop 的核心不是“让 AI 一直干”。

而是：

定义触发条件、成功标准、停止规则和预算边界。

1. 四种循环形态

在 Claude Code 这类工具里，可以把循环分成四种。

类型 说明 适合场景
回合制 人看一轮，再发下一轮指令 探索、讨论、敏感决策
目标制 定义完成标准，模型迭代到达标 修测试、提分数、补文档
定时制 按时间间隔自动触发 查 PR、看工单、巡检
主动式 schedule + goal + workflows + auto 后台自动化任务

大多数人默认用的是回合制。

比如：

你先看看。
继续。
再改。
跑测试。
总结一下。

Fable 5 的能力上来以后，很多重复回合可以交给系统。

但前提是你能写清楚：

做到什么算完。
最多试几次。
什么时候必须停下来问人。

2. /goal：把“做完”写成可验证标准

/goal 的关键不是写步骤。

而是写停止条件。

差的写法：

/goal 优化首页性能

问题是“优化”没有终点。

模型可能很快说已经优化，也可能反复折腾。

好的写法：

/goal 把首页 Lighthouse 性能分数提到 90 以上，最多尝试 5 次。
每轮结束后报告当前分数、修改内容和剩余问题。

这条有三个好处：

有数字。
有上限。
有过程汇报。

再比如：

/goal 修复所有失败的集成测试，最多迭代 8 轮。
每轮结束后列出剩余失败测试数量和失败原因。

这比“把测试修好”稳得多。

因为模型知道：

测试数量归零才算结束。
最多 8 轮。
每轮要报告剩余失败。

3. 什么标准最适合 /goal

最适合 /goal 的，是确定性标准。

比如：

目标 好标准
修测试 失败测试数量为 0
性能优化 Lighthouse 分数大于 90
代码质量 lint 和 typecheck 通过
文档整理 指定目录所有文件都有摘要
接入 4SAPI 所有模型调用统一使用指定 Base URL
成本治理 调用日志包含 project、model、cost 字段

不适合直接写：

做到最好。
尽量优化。
让我满意。
提升体验。
变得更专业。

这些目标可以作为背景。

但不能作为停止条件。

Loop 最怕“满意为止”。

因为满意是主观的。

主观终点很容易空转。

4. /loop：本地定时触发

/loop 适合有规律触发的本地任务。

例如：

/loop 5m 检查我的 PR，滚动查看评审评论，
逐条回复或修改代码，修复失败的 CI。
除非需要重大架构决策，否则不暂停。

这类任务的特点是：

状态会变化。
需要反复检查。
每次检查动作类似。

常见场景：

每 5 分钟查一次 CI。
每 10 分钟查一次 PR 评论。
每 30 分钟整理一次新工单。
每小时检查一次爬虫异常。

但要注意：

/loop 跑在本地电脑上。
电脑关了，它就停。

需要长期稳定运行的任务，不应该只依赖本地 loop。

5. /schedule：云端例行任务

/schedule 适合持续运行的工作。

比如：

/schedule 每小时执行一次：
检查反馈频道的新 bug 报告。

更完整的例子：

/schedule 每小时执行一次：
检查 #project-feedback 频道的新 bug 报告。

/goal 本轮发现的所有报告都完成分类、处理和回复才算完成。
修复 bug 时，用并行工作流在三个独立分支里探索方案，
由一个 reviewer 代理做对抗性审查，选择最稳方案。

高风险动作必须暂停确认。

这条背后其实组合了多个能力：

定时触发。
目标约束。
并行探索。
独立审查。
人工确认。

这才是主动式 Agent 工作流的雏形。

6. 并行子代理：能拆就拆，但别乱拆

Fable 5 更擅长调度并行子代理。

但并行不是越多越好。

适合并行的任务有：

多个文件独立改造。
多个方案独立探索。
多个数据源并行调研。
多个 PR 风险维度审查。

不适合并行的任务有：

强依赖顺序的迁移。
需要统一上下文的设计决策。
权限敏感的生产操作。

推荐结构：

主代理：拆任务、定边界、收结果。
worker 代理：处理独立子任务。
reviewer 代理：全新上下文验证结果。
judge 代理：必要时对多个方案做选择。

注意：

执行者和验证者不要共用同一个上下文。

让主代理“再检查一遍自己的工作”，效果通常不如开一个全新上下文的 reviewer。

7. 自我验证要独立

长任务里可以加入周期性验证：

在构建过程中建立自检机制：
每隔 30 分钟，派出一个全新上下文的验证子代理，
对照规格说明检查已完成工作。

验证子代理只读，不修改。
它必须输出：已满足、未满足、证据位置、建议动作。

这个模式很适合：

代码迁移。
文档重构。
SEO/GEO 大工程。
企业 API 网关接入。
4SAPI 路由改造。

验证者只做验证。

不要让它顺手改。

否则验证又变成执行，边界就乱了。

8. Loop 产品化：先写四张卡

不要一上来就写 /loop 5m。

先把这个循环当成一个小产品，写清四张卡。

第一，触发卡

回答：

什么情况下启动？
多久检查一次？
触发源是 PR、工单、频道消息，还是监控指标？
没有新变化时是否直接退出？

示例：

触发源：GitHub PR 评论。
频率：10 分钟一次。
无新评论且 CI 未变化时直接退出，不调用强模型。

第二，目标卡

回答：

做到什么算完成？
用什么命令、分数、字段或人工确认来判断？
最多迭代几轮？

示例：

目标：所有 review 评论已回复，CI 为绿色。
上限：最多 6 轮。
验收：git diff、测试结果和评论回复都有证据。

第三，预算卡

回答：

本轮最多调用几次模型？
哪些阶段允许用 Fable 5？
哪些阶段只能用低成本模型？
超预算时停止、降级还是转人工？

示例：

Planner 可用 Fable 5 high 1 次。
Worker 默认用性价比模型。
Reviewer 只有在有代码变更时调用。
单轮预算超过阈值转人工。

第四，证据卡

回答：

每轮结束要留下什么证据？
哪些声明必须带命令输出、截图、文件 diff 或日志链接？

示例：

每轮产出 loop-run.md：
- 本轮触发原因
- 实际动作
- 测试结果
- 剩余阻塞
- 下一轮是否需要继续

四张卡写清楚以后，Loop 才像一个可维护的系统。

否则它只是一个会定时消耗 token 的后台任务。

9. 4SAPI 在 Loop 里的用法：记录每一轮，而不是只记总账

Loop 不是一次调用。

它是连续调用。

所以 4SAPI 的日志字段要更细：

字段 示例
loop_id pr-review-hourly
trigger_hash 本轮触发内容的摘要，避免重复处理
goal_id fix-ci-until-green
iteration 第几轮
agent_role planner、worker、reviewer
model Fable 5、Opus、Sonnet
route_reason 为什么这一步用了这个模型
cost 本轮成本
evidence_file 本轮证据文件
status continue、success、failed、manual
stop_reason 达标、无变化、超预算、人工确认

这样你才能知道：

这个 loop 为什么启动？
有没有重复处理同一条评论？
Fable 5 是不是只用在关键判断上？
哪一轮开始空转？
最终停止是达标，还是因为预算。

没有这些日志，Loop 就会变成后台黑盒。

10. 三个可复制配方

配方一：Prompt 迁移流水线

/goal 把 prompts/ 目录下的旧提示词迁移到 Fable 5 风格。
成功标准：
- 删除过度流程化指令
- 移除展示隐藏推理的要求
- 每个 Prompt 都补齐背景、请求、输出格式、约束
- 生成迁移前后对照表
最多迭代 4 轮。

配方二：GEO 监控循环

/schedule 每天 9 点执行：
检查 AIHOT 最近 24 小时来自 AI 爬虫、搜索引擎和海外访问的异常。

/goal 本轮必须输出：
- 新增高价值来源
- 异常轮询来源
- 镜像或采集风险
- 需要人工处理的前 3 项

只读日志，不修改生产配置。

配方三：4SAPI 路由巡检

/loop 1h 检查 4SAPI 调用日志。

目标：
- 找出异常高成本任务
- 找出 fallback 频率异常的模型
- 找出没有 project 或 environment 标记的调用
- 输出一页成本治理建议

不修改路由规则，只生成建议。

11. 什么时候不要上 Loop

Loop 很诱人，但不是所有任务都该循环。

下面几类不要急着上：

场景 原因
成功标准写不出来 模型不知道什么时候停
每一步都需要业务判断 自动化会变成反复打断
权限边界没拆清 容易误触发生产操作
数据变化很慢 高频轮询浪费成本
工具返回不稳定 loop 会把偶发错误放大
没有回放日志 出事后不知道哪轮开始跑偏

有一个简单判断：

如果你不能写出“触发、目标、预算、证据”四张卡，
就先不要上 /loop 或 /schedule。

可以先用回合制。

让 Fable 5 跑几次，观察它在哪里需要你。

等边界清楚了，再把高频部分提炼成 Loop。

12. 从手动到自动的三级成熟度

团队不要一上来就追求全自动。

更稳的是三步走。

L1：手动增强

人发起任务。

Fable 5 执行一个明确步骤。

适合：

写 Prompt。
改一个文件。
生成一份审计清单。

目标是验证模型能力。

L2：目标循环

人定义 /goal。

Fable 5 自己迭代到达标。

适合：

修测试。
补文档。
迁移一批 Prompt。
把 Lighthouse 分数提高到指定阈值。

目标是减少“继续、再试、再修”的人工回合。

L3：定时后台

系统用 /loop 或 /schedule 触发。

Fable 5 按目标卡和预算卡执行。

适合：

PR 评论处理。
日志巡检。
成本异常日报。
4SAPI 路由健康检查。

目标是把重复性运营变成后台任务。

这三级不要跳。

很多团队失败，不是因为模型不行，而是从 L1 直接跳到 L3。

13. 总结

Loop 的本质不是“AI 自己一直跑”。

而是：

触发条件。
成功标准。
停止规则。
验证机制。
预算边界。

Fable 5 让 Loop 更可用。

但越可用，越要治理。

个人项目可以先用 /goal 和 /loop 试起来。

团队项目建议把模型调用统一进 4SAPI，记录 loop、goal、iteration、role、cost 和 stop_reason。

下一篇收尾，讲 Fable 5 避坑和成本治理：

提前停止。
上下文预算焦虑。
安全拒绝。
reasoning_extraction。
模型回退。
以及 4SAPI 路由怎么兜底。