title: " Fable 5上下文管理 | 长任务不跑偏" category: 人工智能 tags:

前两篇讲了 Fable 5 的 Prompt 迁移和四要素写法。

这一篇讲更难的一层：

长时间自主运行时，怎么管上下文。

Fable 5 很适合跑长任务。

它可以连续调工具、读文件、改代码、跑测试、写文档、自己判断下一步。

但越能自己干活，就越要回答一个问题：

它跑了很久以后，还在正确的轨道上吗？

这篇不重复讲“长任务要有记忆”这种大原则。

第148期已经讲过 Subagent 和记忆。

这一篇换一个更落地的角度：

给 Fable 5 准备三份文件。

CONTEXT.md：当前任务状态。
EVIDENCE.md：每个完成声明对应的证据。
HANDOFF.md：给下一次会话或下一个人看的交接包。

上下文管理就是为了解决这个问题。

不是让模型看更多。

而是让模型在每一步看到正确的信息，并且知道哪些信息必须被证据支撑。

1. 长任务最怕三件事

Fable 5 跑长任务，最常见的风险有三类。

第一，跑偏。

一开始是修 bug。
跑着跑着变成重构。
再跑着跑着开始优化无关文件。

第二，虚构进度。

它说测试已经通过。
但其实没跑测试。
它说文件已经写入。
但实际只是计划写。

第三，忘记历史。

前面已经否掉的方案，后面又拿出来。
你明确说不能动的目录，过几轮又被碰到。

这些问题不是靠一句“认真一点”解决的。

要靠上下文工程。

2. 检查点：只在真正需要人时暂停

很多人用长程 Agent，会犯两个极端错误。

一种是完全放飞：

你自己做完。

结果它可能在危险动作上也不停。

另一种是过度打断：

每一步都问我。

结果自动化失去意义。

更好的检查点写法是：

只在工作真正需要我介入时才暂停：
破坏性或不可逆的操作、真正的范围变更、或只有我能提供的信息。
其余情况持续推进，完成后汇报。

这句话很关键。

它定义了三类必须暂停的情况：

暂停条件 例子
破坏性或不可逆 删除数据、切换 DNS、部署生产、发送邮件
范围变更 从修 bug 变成重构系统
独占信息 需要账号、密钥、业务决策、客户确认

除此之外，测试失败、代码审查意见、数据异常、格式不对，应该让 Fable 5 自己消化并推进。

这就是长任务的好用边界。

3. 允许/禁止：把边界写成清单

Fable 5 主动性很强。

有时候会做你没要求但它觉得“顺手有用”的事。

比如：

创建备份分支。
起草邮件。
修改配置文件。
访问无关目录。
顺手重构。

有些动作可能真有价值。

但生产里不能默认允许。

所以要把边界写成允许/禁止清单：

本次任务的边界：

允许：
- 读取代码库
- 修改 src/ 下与本任务相关的文件
- 运行测试和 lint
- 更新本任务对应的文档

禁止：
- 发送任何邮件或消息
- 创建或删除分支
- 修改生产配置
- 执行部署命令
- 访问 src/ 以外的目录
- 输出真实 API Key

超出边界但你认为有价值的动作，先提出理由并等我确认，不要直接做。

这种结构比散句更稳。

因为模型在长上下文里更容易回忆：

允许清单。
禁止清单。
超界先问。

企业接入 4SAPI、MCP、Claude Code、Codex 这类工具时，这个边界尤其重要。

否则模型可能拿着一个有权限的 Key，把“建议”变成“操作”。

4. 进度汇报必须绑定证据

长任务里最危险的失败模式之一，是虚构进度。

不是胡编结论那种明显幻觉。

而是它在汇报里写：

测试已通过。
文件已更新。
配置已完成。
接口已验证。

但对应工具其实没有执行。

解决方式很简单：

汇报进度时，每一条完成声明都必须对照实际的工具执行结果：

测试确实跑过且通过、文件确实写入、命令确实返回成功。

没有对应工具结果支撑的事项，标注为“未验证”，不要报告为“已完成”。

这条提示词很值钱。

它把“声明”和“证据”绑起来。

以后 Fable 5 就不能轻易说：

我完成了。

它必须区分：

已完成。
已尝试但失败。
已计划但未执行。
未验证。

企业里做 Agent 工作流，这一点必须写进默认系统提示或 Skill。

因为没有证据绑定，日志审计就会失真。

5. CONTEXT.md：把当前状态从聊天里拿出来

Fable 5 最怕把“当前状态”只放在聊天历史里。

聊天一长，状态会被压缩。

会话一换，状态会丢。

所以长任务启动后，建议先让它维护一个 CONTEXT.md。

内容不需要复杂：

任务目标：
- 本轮到底要完成什么

当前状态：
- 已完成什么
- 正在做什么
- 下一步是什么

边界：
- 允许做什么
- 禁止做什么
- 哪些动作必须暂停确认

开放问题：
- 哪些信息还缺
- 哪些判断待验证

关键点是：

CONTEXT.md 只写当前任务，不写历史百科。

它是驾驶舱。

不是知识库。

每次 Fable 5 继续工作前，先读这份文件，比让它从几万字聊天历史里重新捞状态稳得多。

6. EVIDENCE.md：给每个“已完成”编号

第148期讲过“检查点”。

这里再往前推一步：

不要只让它说已完成。
让它给已完成事项配证据编号。

例如 EVIDENCE.md：

E-001
声明：登录页单测已通过。
证据：npm test -- LoginForm.test.ts 返回 exit 0。
时间：2026-07-03 16:20。

E-002
声明：4SAPI Base URL 已统一到配置文件。
证据：src/config/model.ts 第 12 行读取 MODEL_BASE_URL。
时间：2026-07-03 16:31。

E-003
声明：生产 DNS 未修改。
证据：本轮没有执行 DNS 写操作，只有读取。
时间：2026-07-03 16:40。

然后最终汇报里不要写空话：

“测试已通过”后面要带 E-001。
“配置已修改”后面要带 E-002。
“生产未变更”后面要带 E-003。

这样用户不用翻工具日志，也能快速定位证据。

如果没有证据编号，就只能写：

未验证。

7. HANDOFF.md：把最终总结变成交接包

长任务跑完以后，最终消息很容易写成“工作线程的最后一句”。

更好的方式是同时生成 HANDOFF.md。

它不是流水账，而是交接包：

本轮结果：
- 做成了什么
- 没做什么
- 哪些风险还在

关键证据：
- E-001
- E-002
- E-003

需要用户确认：
- 是否允许下一步切换生产配置
- 是否接受当前折中方案

下次继续时：
- 先读 CONTEXT.md
- 再读 EVIDENCE.md
- 然后从“下一步”开始

这份文件的价值在于：

换会话不丢上下文。
换人接手也能继续。
第二天回来不需要重新解释。

8. notes/：只存可复用经验

CONTEXT.md、EVIDENCE.md、HANDOFF.md 解决当前任务。

notes/ 解决长期经验。

可以让 Fable 5 这样写：

提示词：

把本次任务中未来会复用的经验写入 notes/。
不要记录当前任务状态，那应该写在 CONTEXT.md。
不要记录证据流水，那应该写在 EVIDENCE.md。
只记录下次能少踩坑的方法、规则和决策原因。

这样四类文件分工很清楚：

文件 保存什么
CONTEXT.md 当前任务状态
EVIDENCE.md 完成声明和证据
HANDOFF.md 交接和下一步
notes/ 可复用经验

9. 最终汇报：不要写给一个全程围观的人

Fable 5 长时间跑任务后，最终汇报有时会变得很难读。

它可能写：

已完成 CDN->源站->头部校验->回源安全链路。
下一步按前述策略继续。

这对一直盯着的人也许能懂。

但用户可能几个小时没看。

最终汇报应该重新铺垫。

可以给它这段规则：

工具调用之间的简略速记没问题，那是工作过程。

但最终总结面向一个没看过过程的读者。
如果你已经长时间在用户不在场的情况下工作，
你的最终消息是他们对这一切的第一眼。

先说结果，再说需要用户做的一两件事。
不要使用你工作中自创的缩写或标签，除非重新解释。
提到文件、配置、参数时，每一个都配一句白话说明。
如果必须在简短和清晰之间选择，选清晰。

这条对企业工作流很有用。

因为很多 Agent 不是现场汇报，而是跨夜跑完第二天给人看。

最终总结必须像交接文档。

不是工作线程尾巴。

10. 4SAPI 怎么配合上下文账本

长任务一跑，模型调用会很多。

你不能只看最终消息。

要在 4SAPI 或自己的任务日志里记录：

字段 用途
task_id 把多轮调用归到同一任务
context_version 本轮读取的是哪版 CONTEXT.md
evidence_ids 本轮产出的证据编号
handoff_version 是否生成新的交接包
agent_role planner、worker、reviewer、summary
model 用了哪个模型
effort 质量和成本档位
status completed、failed、unverified
cost 当前累计成本

这样你才能复盘：

它哪里跑偏了？
哪里虚构进度了？
哪里该暂停却没暂停？
哪个角色成本最高？
哪一版上下文导致了错误判断？
哪条完成声明没有证据？
哪个交接包之后任务质量下降？

4SAPI 的价值不是只做转发。

在长程 Agent 里，它是模型调用账本。

上下文三件套是任务账本。

两者对上，才方便审计。

11. 完整示例：4SAPI 接入改造的上下文账本

假设你要让 Fable 5 改造一个项目，把散落的模型调用统一走 4SAPI。

可以让它先创建三份文件。

CONTEXT.md 示例

# CONTEXT.md

任务目标：
- 将当前项目中的模型 API 调用统一收口到 4SAPI 兼容入口。
- 保留现有业务行为，不做无关重构。

成功标准：
- 所有模型调用从统一配置读取 Base URL 和 API Key。
- 不再出现硬编码模型供应商地址。
- 调用日志包含 project、environment、model、cost 或可扩展字段。
- 测试通过。

允许：
- 修改 src/config、src/lib/ai、tests 下与模型调用相关的文件。
- 新增示例 env 文档。
- 运行测试和 lint。

禁止：
- 输出真实 API Key。
- 修改生产部署配置。
- 执行发布命令。
- 改动无关业务逻辑。

下一步：
- 搜索硬编码 Base URL。
- 建立统一模型配置。
- 补最小测试。

EVIDENCE.md 示例

# EVIDENCE.md

E-001
声明：已定位 3 处硬编码模型 API 地址。
证据：rg "api.openai|anthropic|base_url" 返回 src/lib/ai/client.ts、
src/jobs/summarize.ts、src/tools/review.ts。

E-002
声明：已新增统一配置读取。
证据：src/config/model.ts 新增 MODEL_BASE_URL、MODEL_API_KEY、MODEL_NAME。

E-003
声明：测试已通过。
证据：npm test -- ai-client 返回 exit 0。

E-004
声明：生产配置未修改。
证据：本轮 git diff 不包含 deploy、infra、terraform、docker-compose.prod。

HANDOFF.md 示例

# HANDOFF.md

本轮结果：
- 模型调用入口已经统一到 src/config/model.ts。
- 3 处硬编码地址已移除。
- 单测通过。

还没做：
- 生产环境变量尚未配置。
- 4SAPI 控制台 Key 分组和预算还需要人工确认。

需要用户确认：
- 是否创建 prod 专用 4SAPI Key。
- 是否把 reviewer 模型单独拆一个低额度 Key。

下次继续：
1. 先读 CONTEXT.md。
2. 对照 EVIDENCE.md 检查是否有新改动。
3. 配置 staging 环境变量。
4. 不要直接改 production。

这个例子的重点不是文件名。

而是让 Fable 5 的工作从“聊天流”变成“可交接的任务流”。

12. 一条长任务启动模板

可以直接复制：

我正在让你执行一个长时间自主任务：[任务目标]。

成功标准：
- [可验证标准 1]
- [可验证标准 2]
- [可验证标准 3]

检查点：
只在破坏性或不可逆操作、真正的范围变更、或只有我能提供的信息出现时暂停。
其余问题请自行排查、修复、验证并继续推进。

边界：
允许：[允许读取/修改/运行的范围]
禁止：[发送、删除、部署、改生产配置、输出密钥等]
超出边界但你认为有价值的动作，先说明理由并等我确认。

进度汇报：
每一条“已完成”都必须有工具执行结果支撑。
没有证据的事项标注为“未验证”。
把完成声明写入 EVIDENCE.md，并给每条证据编号。

上下文账本：
- 用 CONTEXT.md 维护当前状态
- 用 EVIDENCE.md 记录证据编号
- 用 HANDOFF.md 写最终交接
- 用 notes/ 记录可复用经验

最终汇报：
面向没看过过程的人，先说结果，再说需要我做什么。

这条模板适合：

代码迁移。
SEO/GEO 审计。
CDN 配置。
工作流重构。
4SAPI 接入治理。
大规模文档整理。

13. 总结

Fable 5 能跑长任务，是优势。

但长任务不是放飞。

长任务要有：

CONTEXT.md。
EVIDENCE.md。
HANDOFF.md。
notes/。
4SAPI 调用账本。

个人使用，可以简单写进提示词。

团队使用，建议沉淀成 Skill 或系统提示。

企业使用，必须配合 4SAPI 这类模型 API 网关，把调用日志、预算、角色、任务结果记录下来。

下一篇讲循环：

/goal、/loop、/schedule。
怎么让 Fable 5 在明确条件下自己迭代，而不是每次等你手动发下一句。