考察点
这道题出自字节跳动一面真题（"Skill 渐进式加载省下的 context 量级大概多少？"），也常变形成"200k 窗口你怎么规划"。面试官想看两点：你有没有对上下文做过定量规划（每块各占多少），以及知不知道工具定义本身就是 token 大户、怎么压。追问往预算超了谁先砍、输出预留多少上走。
参考答案
先做一笔账
以一个 200k 窗口、带 40 个工具的任务型 Agent 为例，一个可起步的分配：
| 块 | 预算 | 说明 |
|---|---|---|
| 系统指令 | 5k（2.5%） | 角色、规则、输出协议 |
| 工具/Skill 定义 | 10-30k（5-15%） | 全量加载时是隐形的吞金兽 |
| 检索知识 | 20k（10%） | RAG top-k 片段 |
| 记忆 | 5k（2.5%） | 画像 + 召回条目 |
| 对话历史 | 120k（60%） | 弹性区，被其他块挤占 |
| 输出预留 | 20k（10%） | 模型本轮回答的空间 |
原则：对话历史是弹性区，其他块超支都从这里扣；历史被压到阈值以下就触发压缩（见上下文压缩题）。
大头在哪：工具 schema
很多人以为历史是大头，其实工具定义经常被低估。一个设计认真的工具 schema——名称、描述、参数 JSON Schema、枚举值、示例——平均 300-800 token，复杂工具上千。40 个工具全量加载就是 2 万到 3 万 token，而且每轮推理都重复计费，占窗口 15% 不说，还把工具间的可区分度稀释了（模型在 40 个相似 schema 里选错工具的概率明显上升）。
渐进式加载：字节那题的答案
Skill 的渐进式加载分三层：
- 元信息层：只加载名称和一句话描述，每个 Skill 约 30-50 token，40 个 Skill 一共 1500-2000 token。
- 指令层：模型选中某个 Skill 后才加载它的完整指令文档，几百到几千 token，一次只加载当前要用的那一两个。
- 资源层：Skill 附带的脚本、参考文件、模板，执行时按需读，不进主上下文。
对比全量加载：假设 40 个 Skill 每个完整内容平均 2000 token，全量是 80k；渐进式常驻只有元信息层的 1500-2000，加上当前激活的 1-2 个完整指令。常驻开销从 80k 压到 2k，省下约 97%，即使算上激活开销，总量也通常省 90% 以上。这就是字节那道题想要的量级答案。
预算的动态治理
静态分配只是起点，还要三件配套：每轮统计各块实际用量，和预算对比，超支告警；拥挤时的降级优先级——先砍检索 top-k，再压记忆条数，再触发历史压缩，系统指令和输出预留是底线不动；工具按场景动态挂载，写代码的会话不挂绘图工具，从入口就减 schema 数量。
可能的追问
- 输出预留留多少合适？——看任务：问答类 2-4k 够，长文生成、代码改写类至少 8-16k；输出被 max_tokens 截断是隐蔽的故障源，预留不够时宁可压缩历史。
- 窗口快满时谁先砍？——检索片段和记忆条目先减半，它们有损但可召回补充；历史压缩是第二步；系统指令和工具定义砍了模型会直接行为异常，最后动。
- 渐进式加载有什么代价？——多一次"选中再加载"的往返，首轮延迟略升；元信息描述写不好模型会漏选 Skill，描述质量成了新的关键路径。