Appearance
Tool 如何撑爆 Context：Definition Cost 与 Result Management
前置：Context 如何选：Selection Signals、Progressive Disclosure 与 JIT
Tool 会从两个方向挤占 Context：调用前要携带能力定义，调用后又会产生 Observation。两者应该先在各自边界收敛，而不是一上来就依赖通用 Compaction；只有跨 Turn 的 working set 仍持续增长时，才进入下一篇的 Context Compaction。
Tool Definition Context Cost
工具 description/schema 本身占 context。catalog 扩展到百/千级后应通过 namespace、tool search、deferred loading 暴露小候选集。
Catalog 规模大时，工具定义本身会成为主要 token 消耗。
🔍 源码对照：Tool Definition 本身就是模型 Context
完整源码与通用分析见 06-03 Tool Metadata / Dynamic Discovery。这里不重复代码；这里关注 context cost：模型看到的是投影后的 Tool Definition；catalog 越大，name / description / schema 本身越会消耗 Context Budget。
源码说明
仓库把“大输出处理”“conversation outline”“prompt assembly”拆成不同入口，本身就是一个有用信号：执行结果的完整载荷、给模型看的摘要/引用、长期保存的 artifact 不必是同一种表示。阅读时应追数据什么时候仍是 raw payload，什么时候被转成 model-visible context，而不是只找某个固定 token 阈值。
工程边界
文件拆分只能证明这个 reconstruction 采用了分层处理，不能证明它的 spill threshold 或 outline 语义适用于其他 Harness。阈值必须由模型窗口、任务和成本目标决定。
Shadow Harness 对照
- ToolResult 保留完整事实；ContextItem 只保存模型当前需要的 projection。
- 大输出进入 ArtifactStore，并在 Context 中使用稳定 handle + 摘要，而不是无条件截断后丢失原文。
验证
构造 5 MB shell 输出：比较 raw-inline、tail-only、artifact+summary 三种策略的 token、任务成功率和后续可追溯性。
Tool Result Management
原始结果先做 projection/filter/pagination，再必要时 summary，并保存 artifact reference。能用确定性代码压缩的数据不要先交给 LLM。
🔍 源码对照：Tool Result 先归一化，再决定如何进入下一轮
完整源码与通用分析见 06-04 Tool Search / Execution Pipeline。这里不重复代码；这里关注 result projection：raw Tool Result 应先 normalize / filter，再决定哪些部分进入下一轮 Model Context；Context 层不直接吞协议原始结果。
Tool Definition 和 Result 要在不同边界减负
Tool Definition 和 Tool Result 都会吃 Context，但治理方式不同。
text
Tool Definition 太多
→ discovery / dynamic exposure / deferred loading
Tool Result 太大
→ projection / pagination / artifact / compaction例如 500 个 Tool schema 不应该靠“把 description 摘短一点”解决，真正应该减少本轮暴露数量；而一次 SQL Tool 返回 10 万行，也不能靠隐藏 Tool schema 解决，应把原始结果放 Artifact，只向模型注入聚合后的必要字段和引用。
先分清是哪一种 Context 成本，才能选对优化手段。
结果压缩必须保留可追溯性
确定性过滤优先于语义摘要，因为它更容易验证。推荐顺序是：
text
raw result
→ validate/normalize
→ field projection / filter / pagination
→ persist large artifact if needed
→ compact observation
→ optional semantic summary如果做 semantic summary，应保留 source/artifact reference 和原始结果版本，避免摘要遗漏后彻底无法回看。跨 Turn 的 working set 仍然过大时，再交给下一篇定义的 Compaction policy 处理。
关联源码
自测
- 一个 grep Tool 返回 5 万行结果。为什么“截前 200 行塞回 Context”通常不是可靠的 result management？
- Tool definition 很长与 Tool result 很大是两种不同 token 成本。分别可以用什么机制控制？