feat(context): 增加旧工具结果的读时 Micro Compact

[wynxing]

变更摘要

在 context 模块中增加读时 Micro Compact 能力，用于缩小发送给模型的上下文体积，同时不修改 runtime 持久化的原始会话消息。

本次改动将 micro compact 挂到 context.Builder 的消息输出链路中，执行顺序变为 trim -> micro compact -> BuildResult.Messages。对于较早的高体积工具结果，会将 role=tool 消息的内容替换为 [Old tool result content cleared]，同时保留工具调用结构和最近工作面上下文。

主要改动

• 在 context.Builder 中接入读时 micro compact
• 保持现有 trim 逻辑不变，在其后增加微压缩投影
• 保留最近的可压缩工具块内容，以及最后一条明确用户指令所在受保护尾部
• 仅清理较早工具块中的 tool 消息内容，不改写 assistant 的 ToolCalls
• 保留 ToolCallID、Role、IsError 等结构字段，避免破坏后续上下文语义
• 跳过以下场景：
  • 非可压缩工具
  • IsError=true 的工具结果
  • 孤立 tool 消息
  • 空内容消息
  • 已经被清空的消息

默认纳入 Micro Compact 的工具

• bash
• webfetch
• filesystem_read_file
• filesystem_grep
• filesystem_glob
• filesystem_edit
• filesystem_write_file

行为说明

• 本次实现是“读时投影”，不是持久化压缩
• runtime 中保存的 session history 不会被修改
• 不涉及 runtime / provider / tools / tui / config 接口变更
• 本次不引入 token 计数、阈值触发、warning 状态或配置项

测试覆盖

新增并补充了以下测试场景：

• Builder.Build() 默认链路会执行 micro compact
• 较早的可压缩工具结果会被替换为占位符
• 最近的可压缩工具块会被保留
• 受保护尾部中的消息不会被 micro compact
• 非可压缩工具结果不会被误清理
• 工具错误结果不会被清理
• 混合 tool call 场景下只清理可压缩结果，并保持结构不变

验证结果

已执行：

• go test ./internal/context/...
• go test ./...

[codecov]

Codecov Report

❌ Patch coverage is 86.04651% with 18 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/context/microcompact.go	91.89%	3 Missing and 3 partials ⚠️
internal/tools/filesystem/edit.go	0.00%	2 Missing ⚠️
internal/tools/filesystem/glob.go	0.00%	2 Missing ⚠️
internal/tools/filesystem/grep.go	0.00%	2 Missing ⚠️
internal/tools/filesystem/read_file.go	0.00%	2 Missing ⚠️
internal/tools/filesystem/write_file.go	0.00%	2 Missing ⚠️
internal/tools/webfetch/tool.go	0.00%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[Cai-Tang-www]

架构与行为上我有一个建议需要在本 PR 里修正：

1. microCompactRetainedToolSpans 的计数时机可能导致“保留预算被空块占用”

• 位置：internal/context/microcompact.go
• 当前逻辑：只要 span 里存在可压缩 tool call ID，就会先 retainedCompactableSpans++，即使该 span 内所有 tool message 都是 IsError=true / 空内容 / 已清空，最终并没有真正“保留有效内容”。
• 风险：最近窗口会被这些“不可清理/无有效内容”的 span 吃掉，导致更早但仍有价值的工具结果被过早清理，和“保留最近工作面上下文”的目标不一致。

建议修复：

• 先判断该 span 是否存在至少一条“可清理候选”或“有效保留候选”（例如 role=tool、匹配 compactable ID、非错误、非空、未清空）再消耗 retained 预算。
• 补一条回归测试：最近两个 compactable span 均为 error/empty 时，不应挤占保留预算并误清理更近的有效工具结果。

其余模块边界（读时投影、不改 runtime 持久化）是合理的，测试覆盖也比较完整。

[Cai-Tang-www]

1)可压缩工具列表硬编码在 context 层

microCompactableTools 是静态 map，后续新增/改名工具时容易漂移。
架构上更稳的是复用统一定义（例如 tools 层常量或配置入口），避免“context 知道太多工具细节”。
缺少开关/阈值，行为是全局强制开启

2)现在 Builder.Build() 每次都执行 micro compact，无法按会话/环境灰度。

如果线上出现误清理，很难快速回退。建议至少留一个配置开关（默认开也行）。

[wynxing]

架构与行为上我有一个建议需要在本 PR 里修正：

1. microCompactRetainedToolSpans 的计数时机可能导致“保留预算被空块占用”

• 位置：internal/context/microcompact.go
• 当前逻辑：只要 span 里存在可压缩 tool call ID，就会先 retainedCompactableSpans++，即使该 span 内所有 tool message 都是 IsError=true / 空内容 / 已清空，最终并没有真正“保留有效内容”。
• 风险：最近窗口会被这些“不可清理/无有效内容”的 span 吃掉，导致更早但仍有价值的工具结果被过早清理，和“保留最近工作面上下文”的目标不一致。

建议修复：

• 先判断该 span 是否存在至少一条“可清理候选”或“有效保留候选”（例如 role=tool、匹配 compactable ID、非错误、非空、未清空）再消耗 retained 预算。
• 补一条回归测试：最近两个 compactable span 均为 error/empty 时，不应挤占保留预算并误清理更近的有效工具结果。

其余模块边界（读时投影、不改 runtime 持久化）是合理的，测试覆盖也比较完整。

已修正 retained 预算被 error/empty span 占用的问题
已补对应回归测试
已重新跑过
go test ./internal/context -run TestMicroCompactMessages -count=1
go test ./...

[pionxe]

当前 micro compact 对“可压缩工具”的判断依赖静态白名单（按工具名匹配）。
这意味着：新增工具时，若只完成了工具实现和注册，但遗漏了 micro compact 白名单同步，该工具历史结果将默认“不参与清理”。

该行为对“高输出工具”风险较高，因为其旧 tool result 会长期保留在 provider 请求上下文中。
#165

[Cai-Tang-www]

在工具中加入显式声明compact:true即可，直接改动就行