Display/`acp_status` context-usage estimator excludes reasoning tokens (undercounts real usage)

[ranxianglei]

来源: #368 (#368) 分析 "compress-call reasoning inflates the incompressible floor" 时发现

问题

estimateContextComposition 只统计 text + tool 两部分，不统计 reasoning 部分，导致 /acp context / acp_status 显示的上下文占用百分比系统性低估真实 usage（真实 usage 包含 reasoning）。

证据

• lib/messages/inject/utils.ts:586 estimateContextComposition：只累加 text（:624-638）+ tool（:639+）部分，没有 reasoning 分支。
• 真实 usage 计算 lib/token-utils.ts:19,44：input + cacheRead + cacheWrite + output + reasoning —— 包含 reasoning。
• 因此显示值 < 真实值，且最大的残留项（reasoning）恰好在显示中不可见。

影响

• 用户看到的上下文占用百分比偏低，无法感知 reasoning 地板（PR feat: strip reasoning from protected-exempt historical messages (gated) #370 修复的正是这个地板）的存在。
• 与真实 token 计费 / 上下文上限判断不一致。

建议修复

在 estimateContextComposition 中为 part.type === "reasoning" 增加分支，累加 part.text.length（或对应 token 估算），与 lib/token-utils.ts 的 usage 口径对齐。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 Triage 完成 —— bug 属实，已逐行在源码核实（基于 master v1.14.27）。先给结论，再给证据。

查重结论

非重复。本 issue 是 #368 分析中拆出的「次生发现 A」（#368 floor 5 明确承诺 "I'll file them as separate issues with source markers"，floor 24 确认已拆出 #371/#372/#373），带来源标记，与 #368 主体（reasoning 地板回收，PR #370）是独立问题，保持打开。

核实结果（代码证据）

1. estimateContextComposition 确实没有 reasoning 分支 —— lib/messages/inject/utils.ts:623-665 的 per-part 循环只有 part.type === "text"（:624）和 part.type === "tool"（:639）两个分支；total = systemTokens + toolTokens + summaryTokens + messageTokens（:703），reasoning 完全不在内。
2. 真实 usage 口径包含 reasoning —— lib/token-utils.ts:44：return input + cacheRead + cacheWrite + output + reasoning。这是 nudge 决策路径（currentTokens）用的口径。✓ 与 issue 描述一致。
3. issue 漏了第二处同型代码路径 —— acp_status 的 overview 并不调用 estimateContextComposition（lib/compress/status.ts:9 只是 import 了但从未调用，是个死 import）。它走自己的 collectVisibleMessages（lib/compress/status.ts:158-168），per-part 循环同样是 text+tool 两分支、无 reasoning；overview 的 total = systemTokens + totalTool + totalText + summaryTokens（:212）。只修 estimateContextComposition 修不好 issue 标题点名的 acp_status 显示——两处都得修。
4. 一处更正：/acp context 命令（lib/commands/context.ts:119）的 TOTAL 是 apiInput + apiOutput + apiReasoning + apiCacheRead + apiCacheWrite，来自 API 上报的 token 数据，已包含 reasoning（折进 "Assistant" 残差项）。所以真正受影响的显示是 nudge breakdown（lib/messages/inject/inject.ts:604）和 acp_status overview（lib/compress/status.ts:219-222），不是 /acp context。

层次判断

• 根因：基于消息内容估算的 estimator 缺 reasoning part 分支（两处同型代码）。
• 症状：显示百分比系统性低于真实 usage，且最大残留项（reasoning）在显示中不可见。
• 决策路径（何时 nudge）不受影响——它用 API token 口径；受影响的只有展示。

修复方案（比 issue 建议稍大，理由见上）

1. estimateContextComposition：新增 reasoningTokens 类别（part.type === "reasoning" 分支，沿用现有 len/4 启发式），计入 total；nudge breakdown 行加 | N reasoning (Q%) 类别。
2. collectVisibleMessages + renderOverview（status.ts）：同样新增 reasoning 聚合，CONTEXT BREAKDOWN 行加 reasoning 类别；per-message drilldown 的 token 数也计入 reasoning（保持口径一致）。
3. lib/prompts/system.ts:76-82：系统提示里的 breakdown 示例行 + 类别说明补上 reasoning。
4. 测试：inject-utils-pure.test.ts / acp-status.test.ts 补 reasoning 计数断言（total 口径、保护消息的 reasoning 计入 protectedTokens、overview 类别显示）。

与 PR #370 的交互（已查 pipeline 顺序）

#370 的 strip pass 插在 hideConsumedCompressCalls 之后、assignMessageRefs 之前（lib/hooks.ts:258-259 之间），早于 injectCompressNudges（:262）。所以 #370 合并后，nudge 路径的 estimator 跑在 strip 之后的数组上，自然与真实发送内容一致；acp_status 读的是 DB 原始消息（fetchSessionMessages），仍会显示请求时已被 strip 的 reasoning——那是 #370 侧的已知交互，我会在 PR 描述里注明，不在本 PR 处理。

开工：分支 + devlog + 实现 + 测试 + 双 agent 评审 → PR。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 进度更新 —— 代码改动已完成（分支 2026-09-08_reasoning-in-context-estimate，devlog REQ 已建），typecheck 通过。改动：

1. lib/messages/inject/utils.ts — ContextComposition 新增 reasoningTokens 字段；per-part 循环新增 part.type === "reasoning" 分支（len/4 启发式，与 text 一致）；total 计入 reasoning。reasoning 计入 msgTotal（因此保护消息的 reasoning 进 protectedTokens、大消息列表可见），但不进 messageTokens（保持 text/code 分类干净）。
2. lib/messages/inject/inject.ts:604 — nudge breakdown 行新增 | N reasoning (Q%) 类别。
3. lib/compress/status.ts — VisibleMessageInfo 新增 reasoning 字段（与 tokens=text+tool 分开，避免 overview 双重计数）；collectVisibleMessages 统计 reasoning（纯 reasoning 消息现在也会进入可见列表）；renderOverview 的 total + CONTEXT BREAKDOWN 行新增 reasoning 类别；per-message drilldown 的排序/合计/行内 token 数均含 reasoning。
4. lib/prompts/system.ts — 系统提示的 breakdown 示例行 + 类别说明补上 reasoning。

正在补测试（inject-utils-pure.test.ts + acp-status.test.ts 的 reasoning 计数断言），跑全量测试 + 双 agent 评审后开 PR。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 Done — PR: #374

实现(分支 2026-09-08_reasoning-in-context-estimate,base 9b7adfd v1.14.27)

按 triage 回复的方案落地,两条展示路径都补了 reasoning 类别:

lib/messages/inject/utils.ts — ContextComposition 新增 reasoningTokens;per-part 循环新增 part.type === "reasoning" 分支(Math.round(len/4),与 text 同口径),计入 msgTotal 和 reasoningTokens(不计入 messageTokens,保持 text/code 分类干净);total 公式加入 reasoning。连带效果:受保护消息的 reasoning 流入 protectedTokens,纯 reasoning 消息进入 largestRanges(完整 footprint)。

lib/messages/inject/inject.ts:604 — nudge breakdown 行新增 | N reasoning (Q%)。

lib/compress/status.ts(acp_status 实际走的路径——estimateContextComposition 那个 import 是死代码,只修 issue 建议的那处修不到 acp_status):VisibleMessageInfo 新增 reasoning 字段(与 tokens 分开,避免 overview 重复计数);收录门槛放宽为 tokens > 0 || reasoning > 0(纯 reasoning 消息现在可见);overview total + CONTEXT BREAKDOWN 行新增 reasoning 类别;drilldown 排序/合计/每行 token 用完整 footprint(tokens + reasoning)。

lib/prompts/system.ts:76 — 示例行 + 类别列表加入 reasoning(示例百分比顺手修成加和 100%,原值加和 121%)。

测试

• +9 新测试:tests/inject-utils-pure.test.ts(+4)、tests/protection-aware-stats.test.ts(+1,protected 消息的 reasoning 计入 protectedTokens)、tests/acp-status.test.ts(+3)、tests/inject.test.ts(+1,渲染后 nudge 行含 2.0K reasoning (Q%))。
• 顺手修了 2 个既有空测试(tests/acp-status.test.ts 的 partial mock 缺 info.sessionID/info.time.created,被 filterMessages 丢弃后在 0 条可见消息上通过)——双审都指出,已补全 mock + 真实 listing 断言。
• 1086/1086 通过(master 基线 1077,+9);typecheck / build 干净。
• 测试审核 agent 在 base 9b7adfd 上实证:9 个新测试全部在修复前代码上 fail(无恒真测试)。

双审(§5.3 + §5.6)

代码 + 测试两个独立 agent 均 APPROVE;可操作发现全部落实(渲染行测试、空测试、精确断言、示例百分比)。

已记录的非目标 / 交互(PR 描述里都有)

• 与 PR feat: strip reasoning from protected-exempt historical messages (gated) #370 的交互:feat: strip reasoning from protected-exempt historical messages (gated) #370 的 strip 路径在 injectCompressNudges 之前运行,合并后 nudge 路径的估算自然与发送内容一致;acp_status 读原始 DB 消息,仍会显示被 strip 掉的 reasoning——属 feat: strip reasoning from protected-exempt historical messages (gated) #370 侧问题,此处只记录。
• composition-vs-range 口径差(新发现,minor):buildCompressibleRanges 的 range token 仍不含 reasoning(有意:流水线 min-size 检查 countMessageCharacters 也不含,加进去会触发 chore: bump version to 1.6.0 #37 的假 "Range too small")。后果:nudge 的 "Effective compressible: ~X" 和 overview total 现在含 reasoning,而 per-range 行不含。候选 follow-up issue。
• dcp-message-id 每消息 token 标注(countMessageCharacters)仍不含 reasoning——既有行为,候选 follow-up。
• countAllMessageTokens fallback 不动(首轮无 reasoning)。

纯展示修复:无持久化状态、内部 tag、配置或决策路径变更。

合并由人工操作——PR 已就绪(CI 跑 pr-validation + test + build),请人工 merge:#374

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 CI 全绿 — PR #374 (#374) 全部 6 项检查通过:

• pr-validation ✅
• test (22) ✅ / test (24) ✅
• build ✅ / build-artifact ✅
• e2e ✅(Docker E2E 场景,含 nudge→compress 流程)

PR 已就绪,等待人工 merge(系统规则:Agent 不能合并 PR)。