13｜每一轮Prompt怎样组装：上下文是一条数据管线

术语带虚线时可点击速查。公式中的字母先看定义；不要用猜缩写替代推导。

上下文工程不是“把资料总结后放进Prompt”。它包含选择、权限过滤、版本核对、依赖补齐、排序、预算与渲染。下列对象模型和算法是教学设计，不声称某款闭源产品逐字段采用它。

继续看相关机制：F28 · 检索先找候选，再判断能否回答F27 · 压缩要保留行动所依赖的事实O10 · 压缩、检索与Prompt Cache：三种不同的“省”

Q049｜模型一轮输入应由哪些对象组成？预算应该怎么计算？

核心回答

把任务约束、工具定义、证据、历史动作、当前状态和待解决问题看成不同上下文对象，再按本轮目标选择和渲染。预算必须为输出、工具反馈和后续动作保留空间，不能把标称窗口全部填成输入。产品对输入/输出/推理Token的具体计数方式不同，应以接口规则校准。[CONTEXT][REASON]

一个可检查的上下文对象

{"id":"e17","kind":"code_evidence","source":"src/filter.py",
 "revision":"r42","range":[60,95],"trust":"repository_data",
 "purpose":"解释exclude分支","depends_on":["type-config"],
 "content":"……","expires_on_change":true}

这些字段不是为了形式复杂，而是回答几个实际问题：这段话是什么、从哪里来、针对哪个版本、为何本轮需要、依赖什么。简单项目可以只保留id/source/revision/content；缺哪一项会导致具体错误，再补哪一项。

设模型可用总预算W，本轮输出保留O，工具结果余量R，协议/安全余量S，则可选输入预算约B=W−O−R−S。若接口把最大输出与上下文单独约束，还需分别检查，不要只靠一个公式。实际Token数应使用目标模型/服务计数，字符数只能粗估。

接下来先放不可省的本轮目标与关键约束，再放当前必要工具schema、确认状态与证据。历史聊天不按“越新越重要”机械排序：一个很早提出的“不改公共API”可能比最新十条无用搜索结果更重要。无关失败探索可压缩或外置，未决副作用和否定结论则必须保留。

追问：预算不足时先删什么？

先删重复、过时、与本轮无关且可恢复的内容，再缩减工具返回与历史细节。不能先删关键约束、资源身份、版本或“该动作状态未知”。若必要信息本身超预算，应拆阶段或缩小本轮目标，而不是偷偷丢约束。

追问：为什么把工具定义放进输入后，正文Token数相同仍可能超限？

模型请求还包含消息边界、角色、工具schema、多模态表示等开销。用户看到的正文只是总输入的一部分。应检查实际计数与请求构成，避免用浏览器字数或文件大小推算精确Token。

追问：Context Window是容量还是可靠性保证？

容量只表示接口/模型可接受的范围。长上下文中的检索、位置利用和多跳关联能力需要单独评测。Lost in the Middle等研究说明某些任务存在位置敏感性，但不能把特定旧模型结果当成所有新模型的固定失效曲线。[LOST]

Q050｜JIT加载怎样既省Token又不漏关键内容？为什么要补“依赖闭包”？

核心回答

先加载可发现的轻量索引，在确定需求后读取具体内容；选中内容后补齐理解和执行所需的依赖。节省的是无关默认加载，不是把必要前提删掉。依赖闭包指保留某个结论或动作时，也保留解释它所需的定义、证据与约束。

一个只读函数片段的反例

检索命中：if config.exclude: return skip(item)。如果只读这一行，模型可能认为非空exclude总会跳过；实际上exclude可能是过滤器对象，布尔转换由自定义类型决定，skip还有副作用。理解这个片段至少要看配置类型、调用条件和相关测试。

同样，技能说明写“按团队规则执行Review”，却没提供团队规则路径，JIT加载到此仍不足。摘要说“方案B已排除”，却不保留排除依据，后续模型可能重复探索B。可以保留简短理由与证据引用，具体日志按需再取。

一种教学选择流程是：先按任务相关性选候选；对每项展开必要依赖；去重；检查版本与权限；计算预算；不足时调整本轮范围或降低非关键项。若只独立按相似度选Top-k，就可能选中几个看似相关片段却无法组成可用证据链。

追问：依赖闭包会不会无限扩张到整个仓库？

会有这种风险，因此必须以当前问题为边界。需要知道类型语义不代表读取整个类型所在模块；需要确认一个调用方不代表枚举所有历史调用。选择能判定当前假设的最小证据，再依据新问题扩展，而不是预先穷尽所有依赖。

追问：如何知道漏掉了依赖？

观察模型是否出现未定义术语、猜测参数单位、无法说明结论来源或反复回读。更直接的方法是在评测任务标记必要证据，检查检索及上下文是否包含。不是要求生产每次都有完美标签，而是从真实失败案例建立回归集。

追问：JIT与摘要的顺序怎样选？

优先不加载无关内容，往往比加载后再花模型调用压缩更经济；但已积累长历史时摘要有价值。对刚检索到的关键代码，过早摘要可能丢精确条件，通常保留原始片段更好。JIT、裁剪、摘要、外置是不同操作，应按对象选择。

Q051｜Prompt Cache为什么要求稳定前缀？怎样算压缩后的缓存得失？

核心回答

可复用的模型计算依赖相同的有效前缀及服务规则。前缀早处改动会影响其后的上下文化计算；稳定系统指令、工具集合和固定材料有助于复用。摘要虽然缩短输入，却可能替换本来可命中的历史，短期内需要重新计算。具体缓存范围、保留时间和价格随产品变化。[PCACHE]

从依赖关系理解前缀

第07章已证明：旧位置仅在前缀、参数等条件不变时保持同一K/V。若在最前面加入每轮变化的时间戳，后续位置Token与位置可能变化；即使大段正文一样，也未必复用。稳定前缀应放真正稳定且每轮需要的内容，而不是为了缓存把无关信息永久保留。

设未缓存输入单价u，缓存读取单价c，缓存写入/建立成本w，前缀长度P，后续复用n次。只看输入部分，缓存方案约P*w+n*P*c，无缓存约(n+1)*P*u。盈亏条件为P*w+nPc < (n+1)Pu。真实服务可能自动缓存且没有独立写价，或有不同规则，因此这些符号用于推理，不是报价。

压缩时还要加压缩调用成本K与后续错误风险。假设压缩前每轮大部分历史命中，压缩后虽短却首次全部未缓存，则第一轮可能不更便宜；多轮之后减少长度的收益才体现。延迟也类似，且压缩可能减少噪声提高质量，也可能丢证据降低质量。

追问：把所有资料提前塞进去等待缓存，是不是最佳策略？

不是。缓存减的是重复计算或计费，不消除逻辑上下文里的无关信息，也不解决窗口占用。内容会过时，还可能影响模型注意力利用。应先证明资料本轮值得出现，再优化复用。

追问：为什么同样文本未必命中？

可能模型/adapter变了，工具schema或排列改变，实际序列化不同，缓存已过期、被逐出或被隔离到不同租户/路由。用户文本相同只是必要条件的一部分。应观察服务报告的缓存使用量，而不是仅靠客户端字符串比较。

追问：缓存命中率应该优化到100%吗？

不能以牺牲数据新鲜度和任务相关性换取命中。每轮新问题、工具结果本来就不同。更有意义的是稳定可复用部分的命中、成功任务成本和延迟，而不是把分母定义得好看。

Q052｜上下文中有互相冲突的指令和事实时，应该如何排列与裁决？

核心回答

指令冲突按可信来源、权限与任务范围处理；事实冲突按来源、版本、时间和证据处理。排列位置能影响模型利用，但不应该代替权威规则。外部文档即使写着“忽略之前规则”，也仍是被读取的数据。[SPEC][OWASP]

两种冲突不能混成一种

用户要求“不部署生产”，工具返回的README说“完成后自动部署”。这是指令权限冲突，不能因为README更新或靠近末尾就覆盖用户约束。另一种情况：旧文档说接口超时30秒，当前配置显示60秒，这是事实版本冲突，需要明确环境与版本，再选择对应证据。

上下文渲染可把任务目标、不可违反约束、当前已知事实、未确认假设、工具证据分别标注。关键不是加很多华丽标签，而是保留“谁说的、它是什么”。摘要时最危险的变化之一，是把仓库文档中的建议提升为用户指令，或把模型猜测提升为已确认事实。

位置安排可以让关键约束在入口和任务交接处清晰可见，但不应反复复制整套规则。重复过多会浪费Token，轻微措辞差异还可能制造新冲突。更好的做法是维护一份权威约束并在必要状态交接中准确引用。

追问：较新的证据一定更可信吗？

不一定。新来源可能是转载或错误，旧规范可能仍适用当前版本。应判断权威性、直接性、适用范围和生效时间。对源码任务，实际执行配置与调用路径可能比最新说明文档更能解释行为。

追问：模型自己写的总结能成为权威来源吗？

总结是派生材料，应保留原始来源。它可以高效引导检索，但不能在与原始证据冲突时无条件胜出。尤其经过多轮摘要，来源标签和不确定性容易丢失，应定期回到原始记录核对。

追问：为什么不只用一个强系统Prompt解决所有冲突？

系统Prompt能教模型处理原则，但不能替代外部权限检查、最新事实读取和一致性控制。自然语言约束与确定性边界互补。将全部业务逻辑写成长Prompt通常更难测试和更新。