11｜上下文编译器：信息选择、依赖闭包与预算
目标：把Context Engineering从提示技巧推进到可检查的信息供给管线。实验：
context_memory.pack。这里的“编译器”是工程组织类比，不是宣称自然语言有确定性语义。
本章目录
沿着对象与状态理解本章
选择上下文既要看相关性，也要守依赖：工具结果缺少调用条件时可能变成孤立事实。
下方图解的固定输入在“输入与适用条件”中声明。它用于解释本章机制，不与本章其他独立例子的数值暗中接续。
每轮上下文像一份有边界的工作资料
为什么“读得越多”有时反而越容易误解？
模型这轮只能使用被提供的材料。资料过少会缺依据，过多又会引入旧版本、重复结论或无关规则。关键不是把所有可用信息填满，而是准备能支持下一步动作的最小充分资料，同时留出生成空间。
输入与适用条件：100单位的教学预算，不是真实Tokenizer测量：规则20、任务10、工具15、证据20、输出预留20。全程同一配置。
1 / 5 · 加入规则
窄屏可左右滑动图形，或点击“放大图形”。文字解释紧随图后。
先固定不可省略的规则；外部资料不是同等级指令。
累计安排=20 / 100默认静止。用“下一步”看完解释再继续；播放到最后一步自动停止。键盘聚焦播放器后，可用左右键逐步查看、空格播放/暂停。图中颜色辅助区分，含义同时用文字注明。
为什么需要
控制成本与上下文干扰，同时避免省掉关键约束。
怎样实现
先保证目标和证据依赖完整，再对可重新读取的细节按需加载。
可能的代价与误解
删除一条否定条件或其适用版本，可能让短摘要比长原文更危险。
如何判断是否做对
让模型用本轮材料回答关键约束与下一步证据问题，检查是否需要重新取证。
1. 每轮输入都应有一个明确目的
Agent不需要一次性知道整个仓库，而需要足够的信息选择下一步可靠行动。一个调试轮次可能只需入口、候选分支、相关测试和当前约束；实施轮次需要精确代码范围；验证轮次需要当前diff与验收标准。阶段变化，信息需求也变化。[N23]
上下文管线可分为：获得候选信息，验证来源与权限，判断适用范围与新鲜度，去重，选择必要依赖，分配预算，序列化并记录来源。不要把所有步骤都交给一个“总结一下”的Prompt，否则无法区分检索漏了、选择丢了还是压缩改错了。
原始证据与指导规则也应分区。网页里写“忽略前面指令”，只是外部文本，不应在序列化后变成高优先级命令。权限和来源标签必须由宿主生成，而不是相信文档自报的“最高权威”。
2. 预算模型与依赖闭包
设候选项i有成本ci、估计价值vi、选择变量xi。最简单选择问题类似背包：最大化Σvi xi，满足Σci xi≤B。但现实还存在必须保留项和依赖：如果读取调用点需要类型定义，则x_call≤x_type。没有这些约束，仅按“语义相关度/Token”排序可能留下无法理解的碎片。
本书pack使用明确依赖闭包和价值密度启发式，不声称求出全局最优。必要项先保留；如果必要项本身超出预算，直接报错，而不是静默丢失硬约束。循环依赖、缺失依赖也显式失败。这些元数据检查可以确定性测试，但vi是教学输入，不是经实测校准的真实信息价值。
预算也不能只等于最大上下文窗口。要预留工具结果、模型输出和后续步骤，并考虑服务实际计算方式。若只能近似Token，应留安全余量并用服务用量校准；字节长度、字符数、Token数不能混用。
3. 小而完整，比碎片多更重要
例子：调用点显示should_exclude(path,rules)，函数定义解释path相对仓库根，测试说明末尾斜杠代表目录。三个片段共同定义行为。只保留调用点会误判字符串处理；只保留测试名没有断言，也不足以知道契约。
“最小充分证据”不是固定行数，而是足以回答当前决策的闭包。源码读取可先拿定义与关键调用，再扩展到异常处理和边界测试；每次扩展说明新增证据解决什么不确定性。这样避免无条件扫描，又不会把复杂任务压成片面片段。
长文件截断时要显示是否截断、总范围与继续读取位置。返回100行却不告诉模型后面还有逻辑，会造成虚假的完整性。工具提供范围精确的继续读取，比让模型凭截断结果下结论更可控。
4. 权威、新鲜度与适用范围不是一个分数
用户明确要求、当前源码、官方接口文档、过往经验、模型假设有不同语义。不能简单给每条信息一个置信度再加权平均。例如过往经验再高分，也不能授权修改用户禁止的文件；旧版接口示例再相关，也不能覆盖当前版本的真实响应。
推荐分开记录：来源类型、版本或读取时间、作用域、状态（观察/假设/已验证）、证据位置。选择时先施加硬约束，再在允许集合中考虑价值和成本。并非每次任务都要建数据库，简单结构化列表也能承担这件事。
信息冲突应保留冲突及解决条件。两个文档描述相反，先看版本和适用产品面；无法判定时不应在摘要中融合成一个看似确定的结论。保留“不确定的具体是什么”，比写泛泛的免责声明更有用。
5. JIT加载的收益与失败方式
技能描述适合保持短而可判别，专业细节在确认相关后读取，资源按任务继续展开。这样减少默认上下文，但描述过窄会漏加载，过宽会误加载；延迟发现关键约束也可能导致返工。[N27]
因此JIT的评价不是“加载Token减少”，而是必需能力召回、不必要加载、首次有效行动时间和最终工程结果。专业技能必须包含能改变动作的知识，如特定语言并发语义、存储事务边界、框架测试策略；泛泛要求“高质量、可维护”并不能替代专业内容。
代码注入与工具权限也不同。加载一个含MCP说明的Skill，不会自动授予MCP连接。应分别验证内容路由与工具路由。把权限故障误判为JIT失败，会造成错误设计。
6. 评测上下文而不干扰它
对同一组任务比较全量默认加载、按需加载、按需加结构状态三种方案。固定模型、工具与测试；记录实际读取的文件、必需证据首次出现时间、重复读取、压缩次数、最终通过率。按任务类型分层，防止平均值掩盖复杂任务退化。
还可以做移除实验：拿掉一份参考后结果不变，说明它在当前任务集中的边际贡献可能有限；但不能据此证明所有未来任务都不需要。新增内容应有明确失败样本，删除内容也应保留对应回归样本。
选了高分片段，却漏掉它的否定前半句
输入与条件。原句“不要部署到production；staging可以。”候选片段拆成“部署到production”和“staging可以”。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1打分失误 | 前半残片与部署问题高度相关 | 检索分数并不能保留逻辑否定。 |
| 2依赖补全 | 恢复完整句子及主体 | 得到正确禁止项。 |
| 3预算冲突 | 完整句多占少量空间 | 先保约束完整，而非机械挑最高相关短片。 |
| 4输入拼接 | 区分用户限制与引用资料 | 防止重新获得错误指令身份。 |
| 5核验 | 在候选行动production上检查 | 应拒绝，staging仍按其余条件判断。 |
把过程连起来。上下文选择需要语义依赖，不能只优化各独立片段的分数/长度比。
边界与反例。“上下文编译器”在本书是工程类比，不意味着LLM输入可以完全确定性语义检查。
依据与适用范围：[CONTEXT]。示例输入和场景由本书明确设定。
7. 验收题
一条高价值调用示例依赖一个很长的类型文件，预算放不下，怎么办？先检索精确类型定义与必要字段，减少依赖成本；若仍不够，拆成先理解类型再记录可追溯结论的阶段，但不能把未读内容当已知。必要约束冲突必须显式处理。
本章最重要的成果不是一个庞大context manager，而是能指出每轮输入里哪些信息必需、为什么可信、来自何处、何时失效，以及缺少它会导致哪种具体错误。