喂什么、怎么喂、喂多少，是设计出来的
上一讲的课后作业里，你实测 token 了吧？你会发现，同样一句话，中文比英文费 token。有没有顺着再算另一笔账：咱们的 Agent 每跑一轮，究竟往模型里塞了多少 token？
这一讲就来算这笔账。先说结论：这笔账不算不知道，一算吓一跳。系统提示词、工具定义、聊天记录、检索结果，全都挤在同一个上下文窗口里抢预算——而这个预算，比我们想象的紧张得多。
学完这一讲回头看，skill 课的三层加载其实就是今天内容的特例。老学员会有一种”原来如此”的感觉。
问题一：窗口那么大，为什么不能随便塞？
现在主流模型的上下文窗口（context window）已经做到了 200K token，甚至 1M token。200K 是什么概念？大概能装下一本《活着》。既然装得下一本书，还有什么好省的？
第 1 讲咱们讲过上下文腐烂（context rot）：token 越多，模型对其中任何一条信息的回忆精度越低。今天把机制再往下挖一层——腐烂的根源是注意力预算（attention budget）。
Transformer 架构里，每个 token 都要”关注”其他所有 token。n 个 token，就是 n² 对关系：
1 万 token → 1 亿对关系
10 万 token → 100 亿对关系
100 万 token → 1 万亿对关系
token 涨 10 倍，注意力的摊薄涨 100 倍所以，窗口大，不等于窗口里的信息能用得上。Anthropic 的说法很准确：这是渐变曲线，不是悬崖——模型不会一到某个长度就突然崩溃，但检索精度和长程推理会一直打折。
举个栗子：家里房间大，不代表东西可以乱扔——房间越大，找东西越慢。窗口是房间面积，注意力是找东西的效率。
别忘了还有第二本账：钱。第 1 讲说过，每一次调用都要把全部上下文重新发一遍。塞 10 万 token 进上下文，每一轮调用都为这 10 万 token 付费——Agent 跑 20 轮，就是 20 倍的重复付费。
问题二：那到底应该喂什么？
Anthropic 的官方指南里有一句话，是上下文工程（context engineering）的总原则：
翻译过来：找到能让目标达成的、信号最强的、最小 token 集合。三个关键词挨个看：
- 最小——不是”够用就行”，而是”能少一个是一个”。每个 token 都在消耗注意力预算和真金白银。
- 高信号——对当前这一步任务有直接帮助的信息才进。无关信息不是”无害的冗余”，而是”有害的稀释”。
- 目标达成——判断标准是任务成功率，而不是”信息全不全”。
举个栗子。咱们的 sdd-site-agent 生成代码时，需要知道架构规范里的「目录结构约定」。它需要同时知道需求规范里三个月前某次评审的会议纪要吗？不需要。塞进去的结果不是”更保险”，而是”更分心”。
任何脱离任务的上下文堆积，都是耍流氓。
问题三：怎么喂？永远在线，还是按需加载？
知道”喂高信号的最小集合”只是第一步。真正动手时会碰到一个选择：一条信息，每轮都塞，还是用到再取？
这里有一个二分法，非常好用：
永远在线（常驻上下文）：
每一轮、每个任务都要用的东西
例如：Agent 的角色定义、输出格式约定、当前任务的直接指令
判断标准：删掉它，每一步都会错
按需加载（用时再取）：
只在特定任务、特定步骤才用的东西
例如：某张表的字段说明、某个规范的细则、历史决策记录
判断标准：大部分时间用不上，用的时候能取出来就行按需加载的官方叫法是 just-in-time 检索——上下文里只放轻量的”指针”（文件路径、索引、关键词），Agent 需要时再通过工具把内容取进来。Anthropic 的编码工具就是这么干的：项目约定文件常驻，但代码文件全部用搜索工具现用现取。
学过 skill 课的大伙应该反应过来了：这不就是三层加载嘛。元数据常驻、正文触发才载、资源按需才载——今天的二分法，就是那一讲的通用化。思想只有一个，场景处处是它。
落到 sdd-site-agent：三个规范怎么分层
道理讲完了，拿咱们的项目套一遍。sdd-site-agent 有三类规范：需求规范、原型规范、架构规范。它们全塞进系统提示词吗？用今天的框架走一遍：
需求规范 → 只有"写需求"这一步用 → 按需加载
原型规范 → 只有"画原型"这一步用 → 按需加载
架构规范 → 只有"出方案、写代码"用 → 按需加载
输出格式约定 → 每一步都要守 → 永远在线
当前任务描述 → 每一轮都要参考 → 永远在线三个规范全常驻，假设每个规范 2000 token，每轮就白白烧掉 6000 token 的预算和费用；按需加载后，每轮只取当前步骤需要的那一个规范，2000 token。省了三分之二，上下文还更干净。
这就是这一讲的完整答案：上下文是稀缺资源。喂什么（高信号最小集合）、怎么喂（永远在线还是按需加载）、喂多少（越少越好），全部是设计出来的，而不是默认塞进去的。
实操演练（约 25 分钟）
必做部分 + 一步加餐。做完必做部分，本讲的核心手感就到手了。
检验一下
①sdd-site-agent 分层设计表：三个规范 + 输出格式 + 当前任务，逐项标注”永远在线 / 按需加载”，并写一句理由。这份表就是第 4 讲记忆设计的输入。
这份作业是贯穿项目的关键部件，建议落成文档，后面几讲会反复在它上面做加法。
skills_loader.py把三层加载写成了代码——description 常驻系统提示词（目录层），SKILL.md 正文等模型点名才读（just-in-time），规范细节资源再按需。先自己动手做，再对照着看：你的分层和它不一样，不代表谁错了，重要的是能说清各自的理由。mini-agent 的完整代码，后续我会分享出来——但别等它，先把你的设计做出来。你如果想深挖一层，还是这篇：Anthropic · Effective context engineering for AI agents
第 1 讲引过它的注意力预算，这一讲的”最小高信号集合”和 just-in-time 检索也出自它。这篇是模块二的总纲，值得读第二遍。（沈剑注：这篇里最有共鸣的是”最小高信号集合”——做架构二十年，好的设计都是减法。）
但还有一个没解决的问题：任务跑长了，上下文迟早写满，到时候怎么办？是扔掉，还是压缩，还是搬出去？——第 4 讲，我们讲长任务的记忆。
知其然，知其所以然。思路比结论更重要。