Agent 上下文预算：先修剪、再压缩与大结果外置

根据机器转写整理，未经原音、画面或代码核对。讲者以某个 Agent Harness 的实现为例；以下是可讨论的设计思路，不代表所有框架具备相同机制或默认参数。

先判断压力来自哪里

长任务的上下文可能因历史消息逐渐增长，也可能因一次工具调用返回了特别大的结果。讲者提出在请求前或处理上下文超限时评估当前压力，先尝试修剪可处理的工具结果，再重新测量；只有仍需压缩时才考虑生成历史摘要。

修剪时保留头尾并标记中间省略，是讲者提出的一种选择，但它可能丢掉关键信息，不适用于必须完整保留的内容。预算估计还要考虑实际请求包含的系统信息、工具说明和历史；当请求组成发生变化时，旧的计量结果未必能直接复用。

压缩应保护工具调用关系

讲者强调，压缩历史时需要保持工具调用和对应结果的结构关系，避免保留一端却删除另一端，让后续请求缺少必要的上下文。未完成的工具调用应等到有合适的边界后再处理。压缩前后也应检查用户目标、重要约束和仍待完成的工作是否得到保留。

其案例还讨论用持久记录标识压缩过程及异常恢复，以及尽可能复用已有请求前缀以减少额外开销。这些是讲者描述的具体实现；缓存命中属于优化，不能作为正确恢复的前提。

单个大结果可以另作处理

当一个工具结果过大而全文又可能需要再次查看时，讲者提出把完整结果保存到上下文外，只向模型提供预览和定位信息，需要时再按受控方式读取。定位符的具体形态取决于存储后端，不应把路径或令牌本身当作授权。

这种做法与压缩多段历史解决的问题不同：外置需要检查访问范围、保存期限、失效与清理。讲者还提醒避免读取结果再次触发同样的外置流程，形成循环。保存失败时应有明确处理策略；不能仅因可选优化失败，就把已成功执行的工具伪装成执行失败。

复核问题

检查上下文预算是否覆盖真实请求；判断压力来自多段历史还是单个大结果；核对摘要、修剪和外置是否保留关键事实与工具关系；最后测试失败、恢复和权限边界。任何一种压缩方式都不能保证不丢失信息。