Fable 5 真正有意思的地方，不是它能陪你聊很久，而是它可以在一个目标下连续推进很多步。

你先告诉它要达到什么结果，它自己搜集资料、执行操作、检查中间产物，再决定下一步做什么。只有遇到需要你授权、需要你判断，或者确实无法继续的问题时，它才回来找你。

这就是循环工作流的基本思路。

一、循环到底是什么

平时使用模型，你卡在每个步骤中间：

你发指令 -> 模型回答 -> 你判断 -> 再发下一条指令

循环工作流则是：

目标 + 背景 + 验收标准
             |
             v
       Agent 自己规划
             |
     执行 -> 检查 -> 修正
             ^       |
             +-------+
          直到满足停止条件

它不是让模型无限思考，而是把原来由人手动推动的中间步骤，交给 Agent 自动完成。

例如，“帮我研究 10 个产品”不是一个循环任务；“持续查找、交叉核对并整理资料，直到 10 个产品都有一手来源、价格日期和适用场景”才更接近循环任务。

二、循环任务最重要的是停止条件

如果没有停止条件，Agent 会遇到两个问题。

第一，它不知道什么叫完成。它可能已经交付了一份可用报告，却继续寻找更多资料。

第二，它不知道什么时候应该放弃。某个网页打不开、某个依赖安装失败，或者某个结论没有足够证据时，它可能反复尝试相似方案。

一个可用的停止条件，应该写成能够检查的句子：

完成条件：
1. 5 个核心问题都有答案；
2. 每个事实结论都有来源和日期；
3. 相互矛盾的资料已经单独标注；
4. 输出文件可以直接交给下一位编辑继续修改。

必须暂停：
1. 需要我登录、扫码或授权；
2. 需要删除文件或修改数据库；
3. 连续两次尝试没有产生新信息；
4. 预计修改范围超过原任务；
5. 出现无法验证的关键结论。

还可以设置时间或预算边界：

先运行 20 分钟。
如果仍未完成，不要继续猜测，汇总已经完成的工作、尝试过的方法和当前阻塞原因。

好的自动化不是永远不回来，而是知道什么时候回来最合适。

三、关于 /goal 和 /loop

网上有人把 /goal 和 /loop 介绍成启动自主循环的命令。例如，/goal 被描述为持续执行到目标完成，/loop 被描述为按照间隔重复执行。

但这类命令的名称、语法和支持范围会随 Claude Code 版本、入口和配置变化。不要只看别人截图就把它写进生产流程。打开当前环境的帮助：

/help

先确认当前版本是否支持这些命令、参数如何填写、如何停止运行，以及它们是否会继承当前目录的权限和上下文。

如果命令不存在，也不影响理解循环工作流。你完全可以用普通任务描述实现同样的逻辑：明确目标、步骤、停止条件、检查频率和人工关卡，再让 Agent 按计划执行。

四、杠铃策略：贵模型用在方向和验收

长任务通常会消耗更多上下文和推理资源。如果从头到尾都使用同一个高成本模型，很多机械工作并不划算。

我更喜欢一种“杠铃策略”：两头用强模型，中间用更便宜的模型。

开头：规划

让能力更强的模型把目标拆清楚，确定资料来源、任务顺序、输出格式和停止条件。

中间：执行

把格式转换、初步分类、重复整理、批量摘要和简单检查交给成本更低的模型。这里的前提是任务有清楚的规则，并且输出可以被后续步骤检查。

结尾：验收

再让强模型对着最初的标准检查结果，重点看事实错误、遗漏、逻辑矛盾和没有证据的结论。

规划阶段：定义问题、来源、标准和风险。
执行阶段：按固定规则批量处理。
验收阶段：检查结果是否满足原始标准。

这不是“强模型一定比便宜模型好”的结论，而是一种任务分工。真正的成本取决于模型价格、上下文长度、执行次数、工具调用和失败重试。不要在没有记录输入、输出和重试次数的情况下声称某种策略一定更省钱。

五、什么时候适合多个 subagent 并行

多个 subagent 适合分工明确、彼此独立的任务。例如研究一篇文章，可以让不同 Agent 分别负责官方资料、竞品信息、用户场景和事实核对，最后由主 Agent 汇总。

不适合并行的情况也很明显：多个 Agent 同时改一个文件、同时迁移同一个数据库、同时操作同一个线上环境。这样很容易互相覆盖，出了问题也难以判断是谁造成的。

可以使用下面的分工方式：

主任务：完成一份产品研究报告。

子任务 A：只整理官方资料，不写最终结论。
子任务 B：只整理竞品信息，标注日期和来源。
子任务 C：只归纳用户场景，不修改文件。
子任务 D：只检查引用、数字和逻辑矛盾。

所有子任务输出独立 Markdown。
最后由主 Agent 统一去重、合并和验收。

一句话原则是：可以并行思考，尽量不要并行修改同一份东西。

六、把循环任务拆成四个阶段

阶段一：观察

读取项目、文件、资料和现状，不做修改。输出事实清单和未知问题。

阶段二：计划

列出任务顺序、每一步的输入和输出、需要的权限，以及失败时的处理方式。

阶段三：执行

按照计划做最小修改。每完成一个独立步骤，就记录修改内容和验证结果。

阶段四：验收

运行测试、查看日志、对照验收标准，整理通过项、失败项和剩余风险。

通用提示词可以这样写：

请按“观察、计划、执行、验收”四个阶段工作。
观察和计划阶段不要修改文件。
执行阶段每完成一个独立步骤，说明修改了什么以及如何验证。
遇到删除数据、修改账号权限、使用密钥、产生费用或发布到公网时暂停。
验收阶段输出通过项、失败项、证据和剩余风险。
不要把未验证内容写成已完成。

七、循环工作流的安全边界

不要因为模型能执行命令，就把所有权限都打开。建议把权限分为三层：

涉及密钥、数据库、域名、付款、删除和公网发布时，都应该回到人工确认。日志和错误信息也要脱敏，不要把 Cookie、私钥、数据库连接串完整粘贴进对话。

一个内容研究循环的完整例子

假设你想每周跟踪一个行业，但不想每天自己打开几十个网页。不要直接让 Agent“帮我监控行业动态”，而要把循环设计成固定流程：

每周一上午执行一次行业信息整理。

信息范围：只看列出的官方博客、产品文档、监管网站和公司公告。
处理步骤：
1. 读取上次执行记录，避免重复报告同一条信息；
2. 收集本周新增内容；
3. 为每条信息记录来源、发布日期和原文链接；
4. 判断它属于产品更新、价格变化、政策变化还是市场事件；
5. 只把可能影响当前项目的内容列入重点；
6. 将无法确认的推断放到“待核实”部分。

停止条件：所有来源检查完成，或达到 30 分钟执行上限。
暂停条件：需要登录、遇到访问限制、发现来源互相矛盾。
输出：weekly-brief-YYYY-MM-DD.md。

这套循环可以持续运行，但它仍然需要人检查来源、判断影响和决定是否行动。自动收集信息不等于自动完成决策。

给循环加一份执行日志

长任务如果没有日志，出了问题很难判断是没有执行、执行失败，还是执行了但结果被覆盖。建议每次循环都记录：

# Run 2026-07-29

- 开始时间：
- 结束时间：
- 读取来源：
- 完成步骤：
- 失败步骤：
- 重试次数：
- 新增文件：
- 需要人工确认：
- 下次执行前要修正：

日志不需要记录所有思考过程，只记录足以复盘的事实。尤其是执行时间、失败步骤、重试次数和输入来源，它们可以帮助你判断某个任务是否真的适合自动化。

用一个小预算测试，而不是直接长期运行

第一次搭循环时，先做一次短周期试运行。观察三个指标：

如果 10 次运行里有 8 次需要人工重做，问题通常不在模型价格，而在任务标准不清楚、来源不稳定或输出没有检查。先修流程，再讨论换模型。

成本记录可以简单到一张表：

日期 任务 输入规模 执行次数 重试次数 人工返工时间 结果
2026-07-29 周报整理 18 份记录 1 0 20 分钟 可用

不要只记录模型标价。失败重试、工具调用、上下文重复加载和人工复核时间，都会影响真实成本。

循环失败时怎样恢复

一个可恢复的循环应该满足三点：保留上一版结果、保留执行日志、下一次能从明确位置继续。

例如内容监控任务在第 4 个来源处失败，不要让它从头重复 1 到 3。可以在日志里记录已经完成的来源，在下次运行时从第 4 个开始，并再次验证前面结果是否仍然有效。

如果循环修改代码，则应该使用版本控制：

执行前：记录当前提交或版本。
每个阶段：只完成一类独立修改。
验证失败：保留日志，不覆盖上一版可用结果。
回滚：恢复到上一个通过验收的版本，再分析失败原因。

数据库、线上文件和域名配置不能只靠 Git 回滚。它们需要单独的备份和恢复方案。

什么时候不应该使用循环

以下任务通常不适合直接长期循环：

循环的价值是减少重复劳动，不是为了让系统看起来更自动化。能被一条清楚的手工流程稳定完成的事情，不一定需要改造成全天候 Agent。

结论

循环工作流的核心不是某一个斜杠命令，而是把目标、步骤、验收和停止条件写清楚。命令只是入口，任务设计才是决定结果的部分。

杠铃策略可以帮助你把强模型用在规划和验收，把规则明确的体力活交给更便宜的模型；subagent 可以并行处理独立问题，但不应该同时修改同一份线上资产。

只要保留人工关卡、权限边界和失败后的回滚路径，Fable 5 才会真正从“能回答问题”变成“能持续推进任务”。

参考资料