分层加载与交接包

把全流程手册常驻上下文是浪费注意力；按五层按需加载，阶段之间用结构化交接包传递状态，而不是一段自然语言摘要。

把全流程手册常驻在上下文里，不是更安全，而是更浪费——常驻的每一条规则都在和当前任务抢注意力，而且规则集一旦没有版本化维护机制，必然过时。正确做法是分层加载：按读取时机和任务范围逐层注入，阶段之间用结构化交接包传递状态。

常驻的每一条规则都在抢注意力

OpenAI 用 Codex 在 5 个月里建成一个内部产品：3–7 名工程师、约 1500 个 PR、约十分之一的传统工期、几乎零行手写代码。但最初他们把所有规则塞进一个巨大的单体 AGENTS.md，结果很快就失败了：它挤占任务上下文、让一切显得同等重要、迅速腐烂，还难以验证规则到底有没有被遵守。openai-harness

这四条失败是通用的，不是 AGENTS.md 特有的问题。"让一切显得同等重要"尤其致命——当"禁止 YOLO 式探测数据"和"函数命名风格"以同样的权重摆在模型面前，模型没有理由优先前者。

五层的加载时机与释放

两条纪律让这张表真正生效：为强制阶段资料维护 Required Read 清单；阶段结束后释放无后续依赖的上下文。没有释放这一步，分层加载只是在做加法——加载了五层，一层都没丢。

交接包要带什么

阶段之间传递状态，必须走结构化的 Handoff Artifact，至少包含：目标范围、已验证事实、未决假设、当前 checkpoint、待确认副作用、审批状态、停止条件、结果交还对象。

还有两个字段容易被省掉，但省掉就会付出代价：一是**"已放弃的路径"独立字段**——它直接防止下游重蹈覆辙；二是保留具体 ID 和数值，禁止概括泛化——"已处理那批订单"这种句子在下一步毫无用处。

判断标准可以这么说：只传一段自然语言摘要，是把上下文丢失伪装成组织分工。 下游依赖必须公开自己的 Contract，不能依赖上游的对话历史——否则上游改一次措辞，下游就断一次。

稳定前缀与动态后缀

Prompt 结构按稳定性拆成两段。稳定前缀：平台规则 → 组织策略 → 项目规则 → Agent 契约 → 工具定义 → 输出契约。动态后缀：当前目标 → 阶段上下文 → 选中产物 → 工作状态 → 最新用户输入。

顺序不是审美问题。动态内容必须放在稳定指令之后，否则每次调用的前缀都在变，缓存全部失效——你会为同一批规则反复付全价。系统规则、项目规则、Agent 定义和工具 Schema 的顺序也要保持稳定，并且不要为了凑缓存命中去复制无关内容。

这条顺序的经济性，有一个代价可查的事故做背书。某客服 Agent 每天处理 10 万次对话，工程师为了让它"知道"当前时间，在系统提示词里加了一行 Current time: {{now}}。第二天监控全线告警：首 token 延迟从 0.5 秒涨到 3–5 秒，月度推理账单几乎翻倍。代码逻辑没改，模型也没换——缓存只认 token 字节序列，前缀里第一个不同的 token 之后全部要重算，而系统提示词在最前面，等于每次请求都从头算一遍 ai-agent-book。

同一个机制还管着两个更少被人注意的设计决定。运行时条件不许进全局缓存段：缓存边界之前的内容能跨用户、跨会话复用，所以每多一个二值条件就把缓存键变体翻一倍，3 个条件（macOS/Linux、普通/调试、中/英文）就是 8 种键，动态元素一律放到边界之后——提示词的排列顺序首先由缓存经济性决定，其次才是语义。少样本示例集要按任务类型固定：示例位置靠前，按请求动态检索"最相关"的示例等于每次改写前缀；两三个覆盖边界情况的示例，通常好过十个大同小异的，后者还额外稀释模型对规则本身的注意力 ai-agent-book。派生子 Agent 时再来一条：提示词、工具定义、模型配置、消息前缀、思考配置都要与父 Agent 逐字节对齐，否则这层缓存一分都省不下。

渐进披露是同一件事的另一面：规则文件当地图用，指向按需读取的结构化文档，而不是把文档内容铺开在上下文里。

三个案例：地图、目录、三件套

OpenAI 把 AGENTS.md 压到约 100 行，只当目录用，指向结构化的 docs 按需读取——"给 Codex 一张地图，而不是一千页手册"。配套还有后台 Codex 任务定期扫描代码库偏差、开重构 PR，以及一个专门清理过时文档的 doc-gardening agent。openai-harness

Stripe 的 Kai 平台撞的是规模的墙：system prompt 里堆上超过 150 个 skills 的描述后，即使前沿模型的质量也开始退化。解法是两段式加载——先让 LLM 从目录里选出需要的 skill，再由 skill 的 allowedTools 决定加载哪些工具，基础 skills 仍固定注入。附带一个反直觉发现：在当前规模下，纯 LLM 选择优于 RAG 预筛。langchain-stripe

长时程任务则靠文件系统的持久记忆。Codex 一次不间断跑了 25 小时、13M token、产出 3 万行代码，靠的是 durable project memory 三件套：plan.md（里程碑加每个里程碑的验收命令，加 stop-and-fix 规则）、implement.md（执行 runbook）、documentation.md（状态与决策的实时审计日志，让你离开几小时回来仍能看懂发生了什么）。openai-long-horizon

代价与检查

代价是设施：分层加载器、Required Read 清单、契约版本管理，以及定期清理过期文档的机制。小项目、单文件任务不值得上这套——它会先把你自己的维护成本拖垮。

检查方法：数一数你当前常驻上下文的规则里，有多少条与当前任务无关；再看阶段交接时，下游拿到的能不能回答"上一步放弃了什么"。前者超三成就该分层，后者答不上来就没有真正交接。