[bug] thinking tokens 不计入 ACP 计量：extractText 跳过 thinking 块，无 usage 上报的会话压缩带盲区

[ranxianglei]

来源: #351 #351 分析 thinking 单字符退化问题时发现

现象 / 代码路径

src/messages.ts 的 extractText()（:111-120）只收集 type === "text" 块；assistant 的 thinking 块在入站投影中完全不可见。因此 kernel 侧全部计量（sentTokens、view-recount #289、nudge/compress 带仲裁）都基于纯 text，历史 thinking 体积为零。

影响分层

• 有可靠 usage 上报的 provider（如 DeepSeek）: realUsage floor（估算错误导致紧急压缩从不触发 #257/fix: run nudge/emergency decision on provider-reported prompt size (#257) #258，provider 报告的 prompt tokens 含全部 thinking）抬升 tokenCount，带仲裁基本准确 → 影响被掩盖。
• usage 上报缺失/不可靠的 relay 或 provider: 估算值系统性偏低（偏低量 = 每轮回传的 thinking 总量，reasoning 模型可占上下文相当比例）→ ACP 自认为上下文比实际小 → nudge/emergency 压缩触发偏晚 → 上游 overflow 风险。长 reasoning 会话正是 [bug] 长会话末尾 thinking 退化为连续重复的「【」(4655 个) 后 turn 被 abort,会话停死 #351 这类事故的高发场景。
• 附带效应：thinking-only turn 被 projectMessage 丢弃（空文本 400 防护），kernel 对这类消息零感知——与上面的计量缺口同源。

建议方向（未定，需 owner 拍板）

1. 入站投影把 thinking 长度并入 core message（带标记或独立字段），让 kernel 计量包含回传体积；或
2. 估算层单独加一个 thinking 增量（不污染 kernel 语义）。

方案 1 更彻底但触及 kernel 接口；方案 2 改动小但两处口径可能漂移。先记录，待排期。

复现

任何使用 reasoning 模型 + 不回传 usage 的 relay 的长会话：对比 /acp 面板 tokens 与 provider 实际 prompt size，差值 ≈ 累计 thinking 体积。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 审核完成：bug 属实（代码证据如下）。建议方案 2（估算层 thinking 增量，纯 host 侧），等你拍板后开工。

验证（代码路径逐条确认）

• src/messages.ts:111-120 extractText() 只收集 type === "text" 块；Pi 的 thinking part 形状是 { type: "thinking", thinking }（与 src/reasoning-drop.ts:44-47 的谓词一致）→ thinking 完全不进 core.text。✓
• src/messages.ts:83-86 确认附带效应：thinking-only assistant turn 返回 []（GLM 空文本 400 防护），kernel 对此类消息零感知。✓
• 计量链：estimateTokens（src/tokens.ts:37-47）= 每条 core message 的 defaultCountTokens(m.text) + 图片固定成本。kernel 自己不算 tokenCount——host 算好后经 processTurn({…, tokenCount }) 传入（src/index.ts:363；commands.ts:171、status-tool.ts:75 同）→ nudge/emergency 带仲裁、[Bug] Token 计数与压缩后状态不同步，导致低收益及零收益的连续压缩 #289 view-recount、growth scale、/acp 面板全部继承同一盲区。✓
• floor 掩盖机制：applyFloors（src/index.ts:312-315）= max(estimate, realUsage.tokens, armedFloor)——无 usage 上报的 relay 对 floor 贡献为 0，计量系统性偏低量 = 累计回传 thinking 体积。你的影响分层成立。✓

方案评估

方案 1（入站投影并入 thinking）有两个坑：

1. 把 thinking 拼进 core.text 会破坏出口重建：patchRefTag（src/messages.ts:376-381）拿 kernel body 与原文比对，不一致时 rebuildBodyFromCore 用 kernel body 重写可见文本 → thinking 会泄漏进 assistant 可见文本（模型复读 + 用户终端可见）。
2. 走独立字段则必须动 acp-kernel 的 CoreMessage（types.d.ts:3-10 目前只有 id/role/contentType/text/toolName/toolCallId），触发跨仓先发后发的 release 排序约束（AGENTS.md §5）——而 kernel 的带仲裁根本不需要这个字段（tokenCount 是 host 喂进去的）；且 kernel 内部记账（block compressedTokens）仍按 text 单独算，等于把你担心的"两处口径漂移"搬进了 kernel 内部。

方案 2（估算层 thinking 增量）— 推荐。 它与现有 image-token 模式 1:1 对称：collectImageTokens(entries) → Map<entryId, tokens>（src/tokens.ts:26-35），在 estimateTokens 内消费并经 sentViewTokenCount/adjustedTokenCount 穿透（tokens.ts:58-93），调用点 index.ts:298-299、commands.ts:160-162+186、status-tool.ts:66-67。同样做 collectThinkingTokens(entries)（对 thinking 原文跑真实 defaultCountTokens，不用固定费率），同一路径穿透。不动 kernel、无跨仓发布、所有读计量的面（nudge 仲裁 / view-recount / /acp / acp_status）天然同一口径。测试有现成模板：tests/image-tokens.test.ts。

实现时发现的一个细节（方案 2 专属）：assistant tool-call turn 投影成拆分 core ${id}#${callId}（src/messages.ts:71-81），朴素 map.get(m.id) 会漏掉 tool-call turn（thinking 往往最大的一类），而给每个拆分 core 各记一次又会 N 倍重复计数。处理：在 estimateTokens 内按 base id 去重，每条原始消息的 thinking 只在存活的 core 中计一次（消息被 prune 掉则其 thinking 一并消失，与实际发送行为一致）。

已知残余偏差（全部在安全方向——偏早 nudge，不会 overflow）：

1. Protected-message exemption inflates the incompressible context floor: per-compression reasoning is never reclaimable (~83.5% of measured residual) #336 dropCompressReasoning（index.ts:411-416）在请求时剥掉 closed-turn compress 消息中 >2048 字符的 thinking，计量仍会计入 → 轻微高估，量级受 compress 调用频率约束。两特性对齐可作后续项，不进 day-one scope。
2. 不回传 thinking 的 provider 会高估。安全方向。
3. thinking-only turn 保持不投影（400 防护不能动）→ 其 thinking 不计。残余小；主要成本在伴随 text/tool-call 的 thinking，已覆盖。
4. 小瑕疵：block 的 compressedTokens（kernel 内部按 text 算）与含 thinking 的 host 计量在 thinking-heavy range 上会有显示级出入，仅影响面板 "X→Y" 数字。

查重结论：非重复。相关但不同构：#336/#338/#339（请求时 drop closed-turn compress thinking——正交，那个缩小 prompt、这个计量它）、#351（源事故，退化缺陷本体）、#325（压缩后 uncovered 消息钉死导致的低估——不同机制，已由 #289 view-recount 处理）。

拍板方案 2 的话我直接开工：src/tokens.ts 加 collectThinkingTokens + 三处调用点穿透 + 镜像 image-tokens 的测试。

---

中文摘要：确认了 thinking 块在入站投影中被整体跳过、无 usage 上报会话计量系统性偏低的 bug（逐条代码证据见上）；建议采用方案 2——估算层按现有 image-token 模式加 thinking 增量，纯 host 侧改动、不动 acp-kernel、无跨仓发布依赖，且偏差全在安全方向；等你拍板后实现。

[ranxianglei]

从内核改

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 收到，按方案 1（内核改）执行。设计取你给的两个变体里的独立字段（不拼进 text——拼接会破坏出口重建路径，见上轮分析）。

执行顺序受跨仓依赖约束（AGENTS.md §5：acp-kernel 必须先发布）：

1. acp-kernel：CoreMessage 加独立字段（thinkingTokens?: number，host 用 kernel 导出的同一个 defaultCountTokens 预计），并入 kernel 内部所有按消息计数的地方（block compressedTokens、status report 等）。先开 feature PR（不动 version）。PR 合并是 human-only，需要你合并。
2. 合并后走 release（CI auto-publish），我验证 npm 上的新版本号。
3. billion-context-pi：pin 新 acp-kernel 版本；入站投影把每条 assistant 消息的 thinking 体积挂到该消息的第一个 core 上（tool-call 拆分 core ${id}#${callId} 若每个都挂会 N 倍重复计数）；host 侧计量（estimateTokens / [Bug] Token 计数与压缩后状态不同步，导致低收益及零收益的连续压缩 #289 view-recount / /acp / acp_status）改读同一字段 → 所有面同一口径。本地用 overlay 预验证，发布后推分支开 PR（引用本 issue）。

开始动手，进展会持续回帖。

中文摘要：按 owner 拍板从内核改——acp-kernel 的 CoreMessage 加独立 thinkingTokens 字段并计入内核计量，先发内核 PR（需人工合并+release），再发 billion-context-pi 适配 PR；现在开工。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

按拍板，内核侧已完成实现：acp-kernel PR ranxianglei/acp-kernel#242 （issue: ranxianglei/acp-kernel#241 ，已带来源标记）。

改动（分支 2026-09-10_coremessage-thinking-tokens，8 文件，diff 全部与本事项相关）：

1. CoreMessage 增加可选字段 thinkingTokens?: number —— metering-only：永不渲染、永不截断、永不索引；host 契约为每条原始消息恰好挂在一个 core 上（拆分出的 tool-call cores 不得重复挂载，否则总量被乘倍——契约写进了字段文档）；
2. tokenize.ts 新增 countMessageTokens(message, countTokens) 作为唯一计量口径（text + 合法正有限 thinking，非法值按 0），并从 index.ts 导出；
3. 全部逐消息计数点切换到该口径：applyCompression 的 compressedTokens、computeContextBreakdown、recommend 的 protected/compressible range tokens（chars 保持纯文本长度——截断闸门数的是可截断载荷）、report 的 collectVisible、render-refs 的 ref tag tokens 属性（模型看到的单消息体积与 block/range/breakdown 账目从此一致）。

验证：typecheck ✓ / 637 tests ✓（含新增 tests/thinking-tokens.test.ts 6 项）/ build ✓。无破坏性变更：字段可选，不挂载的 host 行为与现状完全一致。

后续步骤（严格按 AGENTS.md §5 顺序）：

1. 请 review 并合并 acp-kernel#242（系统规则禁止我合并 PR，请自行合并：https://github.com/ranxianglei/acp-kernel/pull/242）；
2. 合并后 CI 自动发布，我会 npm view acp-kernel version 确认上线；
3. 确认后做 billion-context-pi 侧：pin 新 acp-kernel 精确版本、projectMessage 把每轮 assistant 的 thinking 串接后以 defaultCountTokens 计入并挂到该轮首个 core、estimateTokens 经 sentViewTokenCount/adjustedTokenCount 穿透到 nudge 带/view-recount//acp 面板、仿照 tests/image-tokens.test.ts 补测试，然后提引用本 issue 的 PR。

说明：此实现同时避开了两个坑——不把 thinking 拼进 core.text（那会破坏 patchRefTag/rebuildBodyFromCore 出站重建），也不采用方案 2 的两处口径（kernel 是唯一口径，adapter 只负责投影与传递）。

中文摘要：内核已加 thinkingTokens 字段与统一计量口径（修复无 usage 上报会话中 thinking 体积漏计导致压缩带偏晚的盲区），PR 已提交待人工合并发布，随后继续 adapter 接线。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 内核侧已提交，适配侧已完成本地验证——现在卡在人工合并这一步。

1️⃣ acp-kernel PR #242（内核改动） — ranxianglei/acp-kernel#242

• CoreMessage 新增 thinkingTokens?: number；新增 countMessageTokens() 统一计量口径（text + thinking）
• block 记账、context breakdown、recommend ranges、report、ref-tag tokens 属性全部切换到该口径
• 契约：host 侧每条原始消息的 thinking 只挂到第一个 core 上（拆分 tool-call cores 不重复，否则总量翻倍）
• CI 全绿：pr-validation / test (22) / test (24) / build-artifact ✅，mergeable_state = clean
• 配套 issue：[feature] CoreMessage 增加 thinkingTokens：reasoning 模型回传体积计入 ACP 计量 acp-kernel#241
• ⚠️ 需要 @ranxianglei 合并（PR 合并仅限人工）。合并后 CI 会自动发布。

2️⃣ billion-context-pi 适配分支（已推送，未开 PR） — 2026-09-10_thinking-tokens-metering @ a73a155

• projectMessage：assistant 回合的 thinking 体积（defaultCountTokens）挂到首个发出的 core（text / 单 toolCall / 多 toolCall 三种形态全覆盖）；thinking-only turn 的空文本 400 防护保持不变
• estimateTokens + /acp 面板 session fallback + unpruned 总量：计入 thinkingTokens（index.ts / status-tool.ts 走同一入口，自动覆盖）
• 新增 tests/thinking-tokens.test.ts 6 个测试：单测（三种 core 形态的单点挂载、covered 跳过）+ 集成（sent-view [turn] 计数含 thinking；thinking 把会话推过 nudge 带才触发 nudge，对照会话保持安静）
• 验证方式：acp-kernel master 新构建 dist 本地 overlay 到 node_modules，typecheck ✅ / 654 pass · 0 fail / build ✅
• 按 §5 顺序约束，pin 升级（+lockfile）等 npm 上确认新版本后单独提交，然后开 PR（Fixes #353）

下一步（等 #242 合并后我继续）：npm view acp-kernel version 确认发布 → 升 pin + lockfile → 复跑三项检查 → 开适配 PR。

---

中文摘要：内核 PR #242 已就绪且 CI 全绿，等你人工合并并发布；适配侧代码已全部完成并本地验证通过（654 测试全绿），待内核发布后我会升 pin 并开 PR 收尾。

[ranxianglei]

检查 billion-context 是否有这个问题

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 核查结论：billion-context 没有 #353 这个问题，无需改动。

已 clone 该仓库（master @6282f35, v0.1.99, pin acp-kernel 0.0.61）逐层验证：

1. 投影层不丢 thinking——它把 thinking 升格为一等 core

• anthropicToCore（acp-kernel src/wire/anthropic.ts:117-124）: thinking block → contentType "reasoning"、text = 完整 thinking 文本
• openaiToCore（src/wire/openai.ts:90-116）: reasoning_content 字段或内联 dialect tag（think/thinking 标签，经 splitDemotedThinking）同样拆出为全文本 reasoning core
• Responses API: reasoning items 明确"路由进压缩管线"（src/wire/responses.ts:68-71），可计量可压缩

2. 计量层全额计入
effectiveTokenCount（src/server.ts:1863-1867）优先取上游真实 input_tokens（有 usage 上报时精确且含 thinking）；无上报时回退 estimateCoreMessagesUpper（src/preflight.ts:156-160）——对所有 core 求和 m.text 长度，无 contentType 过滤，reasoning core 天然在列。计量输入正是转换后的 msgs（server.ts:1914→1923）。

3. 与 pi 的本质差异（为什么 pi 有盲区而它没有）
pi 的会话日志原生记录 thinking 块，但 extractText 投影只收 text 块 → 日志里有、投影里没有 → 计量与真实回传体积脱节（#353 病灶）。proxy 的架构是"线上有什么就转发什么"：客户端 history 里的 thinking 字节 → 全文本 core → 被计量也被转发，两边永远一致。若客户端自己不回传 reasoning（某些 relay 客户端会剥离），上游 prompt 里本来也没有 → 不存在"计量值小于实际上游 prompt"的偏差。

4. 一个刻意的缩减，非盲区
dropCompressReasoning（src/reasoning-drop.ts，该仓 issue #651，即 pi #336/#339 的同源修复）移除已关闭轮次 compress 调用所附的 reasoning——这是主动减负（确实不再发送），计量与实际转发保持一致，不属于 #353 这类少算问题。

对内核 PR #242 的影响：thinkingTokens 是增量可选字段，专为"投影无法承载 thinking 文本"的 host（如 pi）设计；billion-context 继续用 0.0.61 不受影响。审计结论为阴性，按规范不在该仓库开 issue。

---

中文摘要：核查了 billion-context 的投影与计量路径——其 thinking 经 kernel wire 转换器升格为全文本 reasoning core 并全额计入 tokenCount，且"所见即所发"不存在计量偏差，确认无 #353 同类问题，无需改动。

[ranxianglei]

你确认下 billion-context 的 launch 模式启动 pi 也没有影响吗

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 确认：launch 模式（bili pi）同样不受 #353 影响。 证据链如下：

1. launch 模式下压缩权威始终在 proxy，不在 pi 侧

• bili 自带的 pi 扩展是纯薄客户端（src/agent/pi.ts 头部注释："The bundled artifact imports NOTHING from the host at runtime"）：它只注册转发到 proxy 的 ACP 工具（forwardTool → POST /__bili/plugin/tool）和拉取 proxy 状态的 /acp 命令（fetchStatus），自身不做任何计量或压缩决策。
• plugin.ts:30-41 的协议注释写得很明确："the proxy stays the single compression authority (state, history folding, philosophy prompt, nudges)"。x-bili-plugin 头触发的 pluginMode 只抑制线级工具注入（server.ts:1885/2140/2330 三处均为 injectTools = ... && !pluginMode），计量管线 effectiveTokenCount → processTurn → nudge 原样运行。

2. 计量口径覆盖 thinking（沿用上一条审计结论）
launch 模式不改变投影路径：pi 发出的请求体经 anthropicToCore/openaiToCore/responsesToCore 转成 core，thinking/reasoning_content 升格为全文本 reasoning core，estimateCoreMessagesUpper 无过滤全额计入。结构性不变式：wire 上有什么 = 被计量什么 = 被转发什么——pi 若回传 thinking 则被计且被发；pi 若不回传（某些客户端会剥离）则上游本来也没有。任何情况下都不存在"计量值 < 实际上游 prompt"的偏差，#353 的盲区在架构上不可能出现。

3. 一个边界情况说明（诚实起见）
如果同一个 pi 里同时装了 billion-context-pi（双栈），那么 pi 侧的内核仍基于会话日志做自己的决策——那个实例带着 #353 盲区，直到内核 PR #242 + 适配 PR 落地为止。这是 billion-context-pi 自身的属性（修复已在途），与 launch 模式无关；只用 bili 自带扩展的纯净 launch 模式没有此问题。

---

中文摘要：确认了 launch 模式的压缩权威在 proxy 侧（自带 pi 扩展只是薄转发层，pluginMode 仅抑制工具注入不关计量），thinking 经 wire 转换器全文计入且"所见即所发"，故 bili 启动 pi 同样没有 #353 问题；唯一例外是双装 billion-context-pi 时 pi 侧实例仍带盲区，待在途修复落地。