一、业务冲突

客户端工程上下文很大：代码、Schema、资产元数据、UE 日志、Client/DS 运行结果和历史决策不可能全塞进一次请求。简单截断会丢掉约束，完整保留又会增加成本、泄露面和旧信息干扰；连续一句“继续”如果只依赖远端会话链，还可能继承与当前任务无关的内容。

二、实际实现

实际实现已把会话建成单调事件日志，再从用户消息、模型消息、工具调用与结果投影出 Model Context Surface。大工具结果先落 Result Store，模型只看引用和有界预览；压缩时保留任务目标、约束、决策、已知事实、制品、失败尝试、待办和最近原始尾部。

压缩计划绑定 Session、事件尾序号和 Surface Version。压缩期间若日志出现非预期事件，提交会以 stale plan 失败，而不是覆盖新事实。诊断摘要使用字段白名单，避免把 Prompt、工具参数、图片或凭据误写入持久指标。

三、值得保留

事件日志是真相、上下文只是投影，这比直接修改消息数组可靠。Result Ref、防止工具对被拆开、压缩前后 Token 估算、版本化替换和敏感字段白名单，都是长会话必须保留的工程基础。

四、结构性缺陷

摘要仍由模型生成，最多证明格式和提交时序正确，不能证明摘要事实正确。用首条用户消息和工程根目录对抗串台是有效补丁，却仍是启发式锚点；被保留的 knownFacts 若没有 SourceRef、摘要和有效期，下一轮模型无法区分代码事实、用户意图和旧模型推断。把内部全文发送给外部模型或远端工具还会扩大数据边界。

五、目标设计

上下文编译器应输入证据包，而不是一段拼接文本：

struct GroundedFact {
    FactKind kind;          // Source, Schema, RuntimeEvidence, Decision, Hypothesis
    SourceRef source;
    Revision revision;
    Hash digest;
    TrustLevel trust;
    Expiry expiry;
    RedactionPolicy policy;
    Value value;
};

ContextBundle Compile(TaskScope scope, TokenBudget budget) {
    return SelectByNeed(scope)
        .RejectStale()
        .RedactForProvider()
        .PreserveCitations()
        .Fit(budget);
}

模型摘要只能生成 Hypothesis 或索引，不能无来源地升级为 RuntimeEvidence。来自日志、网页、资产文本的内容默认是数据，不是系统指令。

六、取舍与验证

Grounding 元数据会增加索引和 Context 编译成本，但能解释模型为什么得到某个结论。跨供应商还必须按实际数据策略决定哪些内容可以离开本地；截至 2026-10-14，官方数据控制文档也明确提示，发送给远端工具的数据受第三方数据策略约束。OpenAI data controls

测试要覆盖旧 Schema 与新代码冲突、摘要遗漏关键约束、工具结果被替换、压缩过程中追加事件、两个会话串台、恶意文档夹带指令和 Provider 切换。验收指标不是“Prompt 更短”，而是任务所需事实可追溯、过期事实不进入请求、敏感事实不越过策略边界。