上下文窗口是有限且昂贵的资源。Context Builder 要在每次模型调用前做一次认真取舍：什么必须带上，什么先摘要，什么此刻根本不该出现。

把上下文元素结构化

候选内容可以统一表示为 {kind, content, tokens, priority, source, expires_at, access_scope}。这样系统才能比较任务状态、记忆、检索结果和工具输出，而不是把它们提前拼成一条无法治理的长字符串。

预算分配比末尾截断更可靠

组装时先为安全规则、用户目标和输出 schema 预留预算，再加入任务状态和高分证据。超出窗口时，应优先移除低优先级、可重新检索、已经被摘要覆盖或已经过期的内容，不能简单从文本末尾截断。

收集候选 -> 权限过滤 -> 相关性/时效评分 -> 去重 -> 预算装箱 -> 输出上下文清单

压缩要保留决策信息

对话摘要不只是缩短句子，而要保留用户已确认的约束、已经采取的动作、失败原因和下一步。工具返回可抽取关键字段，并保留原始结果的引用位置。对代码和表格等结构化内容，盲目自然语言摘要可能丢掉精确信息，应按类型选择压缩器。

必须记录“为什么选了它”

Context Builder 的输出应能被调试：每轮加入了哪些片段、来自哪里、用了多少 token、为什么被选中、哪些内容被丢弃。涉及隐私时，这一层还承担数据最小化和脱敏职责，避免不必要的信息被送往模型。

这章给我的启发

Context Builder 像一个资源调度器，让“模型为什么忘了、为什么被带偏”从玄学变成可观察的问题。上下文不再是拼接结果，而是一个经过策略选择的运行产物。

文章摘自：https://www.cnblogs.com/hazy-star/p/22684289