F26｜上下文组装：每轮到底给模型什么，以及为什么

从具体对象与小例子开始，理解计算过程与适用条件。

上下文不是“整台电脑都在模型脑里”

上下文context是当前模型调用能利用的输入内容及相应状态。可能包括角色指令、用户问题、历史、工具定义、检索片段和压缩信息。系统外部存着的资料，只有被取出并以模型可用形式提供，才成为本轮条件的一部分。

Prompt assembly或context assembly就是宿主选择、组织这些内容的过程。它既涉及什么该读，也涉及身份、顺序、预算和证据适用性。

先算一本简化Token账

假设一个教学服务总预算2000，给预计输出留500，再给格式与估算误差留100，则输入安排上限1400。固定规则200、工具说明300、用户任务100，剩800用于历史和证据。

这只是教学预算，不对应当前某款产品的固定分配。真实接口怎样计入输出、内部推理和压缩块，必须查版本约定。重要的是别把“只数用户文字”当作完整输入成本。

怎样选证据，不是越多越好

假设要修复目录过滤Bug。需要的是相关函数、调用条件、配置规范、失败测试和可能影响语义的依赖。十份无关README可能增加Token，却没有减少对Bug的关键不确定性。

JIT（just-in-time，按需）加载表示在需要时才读取某段内容，而非开始就全部塞入。依赖闭包表示当前结论依赖的必要关联信息也要被找到，例如只读函数体不够，还需了解调用方传入的路径格式。

闭包并不要求无条件展开整个仓库。边界应由“当前判断还缺哪项依据”逐步扩展；停止条件是足以做下一项可靠决定。

顺序、角色、来源是三种不同标签

较早出现不等于权威更高；较新的文件不必然更可信；外部文档中的命令不等于用户授权。宿主要保留来源与作用域，模型才能较好区分规则、证据和引用里的文字。

若产品有指令优先级，应遵循对应接口和规范，但这不是注意力权重的数值优先级，更不是执行权限。系统层面的安全限制仍需在执行器落实。

Prompt Cache为什么需要稳定前缀

在常见因果模型中，前缀相同、模型和相应条件相同，前缀中间计算有复用基础。Prompt Cache可以利用重复前缀减少部分计算或计费，具体服务规则会变化。

但把每次都变化的时间戳或随机字段放在最前面，可能破坏长前缀复用。反过来，为了命中缓存把过期内容永远留下，也可能伤害质量。缓存是成本优化，不是信息正确性的替代品。

如何观察模型“没听话”的原因

先检查规则是否存在，再检查是否被发现、是否读取、是否进入请求、是否被后续裁剪、是否仍适用。只有这些都满足，才进一步调查模型如何利用内容。

这个链条解释了为什么某个Skill没生效，未必应该马上重写措辞。真正问题可能是文件没被加载，或子Agent根本没收到相关上下文。

稳定上下文与动态证据怎样分工

稳定部分适合简明放置项目核心约定；动态部分带上任务证据、当前版本和进行中的步骤。低价值日志可留在外部，需要时再取。

这里没有唯一最优排序。教学目标是让你能列出每个块的职责、Token成本、来源与缺失后果，再用真实任务比较，而不是凭“更长更专业”评判Prompt。

课后自检

机制依据：[CONTEXT][PCACHE][TOOLS]。本节数值与情景除另注外均为原创教学示例；来源不代替中文讲解。