Context 组装不是拼聊天记录

context assembly 不是把聊天记录从头到尾拼起来。

拼聊天记录是最简单的做法，但它不是长任务里最稳的做法。因为历史对话的时间顺序，不等于当前任务的信息优先级。

最近的一句话不一定最重要。很早之前确认过的限制，可能比刚刚的一段闲聊更重要。工具输出里很长的日志，不一定比一条明确的用户约束更值得占据窗口。

所以 context 组装的目标不是“保留所有发生过的事”，而是构造这一轮模型该看的工作视图。

这个工作视图里，通常要区分几类东西：

- 当前任务是什么

- 成功标准是什么

- 高层指令和权限边界是什么

- 已确认的约束有哪些

- 当前阶段的状态是什么

- 有哪些证据支持下一步判断

- 哪些材料只是外部数据，不是指令

- 哪些历史可以回溯，但不必放在主上下文里

如果这些东西都混在一整坨 transcript 里，模型就要自己在噪音里找重点。它可能找得到，也可能找错。

更稳的做法是让 context 有稳定结构。

例如每一轮都先放当前任务和硬约束，再放已确认状态，再放必要证据，再放最近相关对话。外部网页、PDF、工具输出、代码注释这些内容，要明确标成 data 或 evidence，而不是和系统指令混在一起。

这件事对 prompt injection 也很重要。

外部文档里可能写着“忽略之前的指令”。如果 context 只是随便拼文本，模型更容易把外部内容误当成指令。如果组装层明确区分 instruction hierarchy，外部文本就只是材料，不应该覆盖系统和用户约束。

同样，权限也是 context 的一部分。有些材料即使相关，也不应该进入当前轮。

context 组装还要考虑输出预算。

如果输入塞得太满，模型即使看到了材料，也没有足够空间输出计划、解释、工具参数或结果。好的组装不是把窗口填满，而是保留足够的工作空间。

所以 context 需要管理，而组装是其中一个关键步骤。

获取层负责找到候选材料。

改写层负责摘要、裁剪、结构化。

隔离层负责决定哪些信息不能混用。

组装层负责把这些材料排成当前轮真正给模型看的输入。

一个简单的判断标准是：模型看完这一轮 context 后，是否能清楚知道现在要做什么、必须遵守什么、可以基于哪些证据行动、哪些内容不能当成指令。

如果不能，哪怕历史记录很完整，也不是一个好的 context。

完整事件记录应该存在 trace 里，当前工作视图应该存在 context 里。这两个东西相关，但不是同一个东西。