扫描一下本项目全部的issue和pr 看哪些值得哪些不值得

[ranxianglei]

扫描一下本项目全部的issue和pr 看哪些值得哪些不值得,哪些过期了 哪些还需要

[ranxianglei]

🤖 ework agent · vllm-qwen/qwen3.8-27b

[bot] 收到，开始扫描全部 issue 和 PR（含 open/closed），逐个评估"值得/不值得/过期/仍需"。稍后给出完整清单。

[ranxianglei]

🤖 ework agent · vllm-qwen/qwen3.8-27b

[bot] 扫描完成。全仓库共 167 个 issue/PR（含本 issue），其中 open 32 个（含本 issue）、closed 135 个。master 当前 = v0.0.46（2026-08-25）。我逐个核对了 open 项并对照当前 master 源码验证了"是否已修复"。结论如下：

一、过期 / 建议直接关闭（2 个）

#	结论	依据
#42	已修复，关闭	overlap 现在跳过而非整批中止：src/compress.ts:236 "Skipped range … overlaps an earlier range"（PR #55 已合并，标题即 "ISSUE-42"）
#108	与 #129 重复，关闭一个	同一天创建、同一主题（compress 参数解析统一）。#129 是更完整的 tracking（前因后果+全栈表），建议保留 #129、关 #108

另外发现一个重复簇：#140–#155 共 16 个同标题 issue（"Parameterize remaining tool-name references"），全部 2026-08-23 同一天创建——像是自动化循环重复建单。15 个已关，#140 是唯一幸存者。剩余工作（description/错误信息/协议提示里的工具名）真实存在（#138 的 withToolNames 只覆盖了 compression-rules.ts），建议保留 #140 作为唯一 tracker。

二、open PR（9 个）

建议合并（小 diff、真实修复，均已验证问题仍在 master 上）：

PR	内容	状态
#165	acp_status ranges 按对话轮分组（修 billion-context-pi#193 的"巨无霸 range"）	mergeable=clean，可直接合
#161	panel 去掉窗口相对百分比、以 sent-to-LLM tokens 领头（修用户误读 65%=645k 事件）	behind，rebase 后合
#123	drilldown 加 reverse/offset（closes #93）	behind，rebase 后合
#103	打断 identical-rejection 重试死循环（closes #101；事故：同一调用重试 3853 次/5h11m/约 800 GPU 分钟）	小 diff +120/-6，高价值
#102	responses codec 折叠省略 type 的 EasyInputMessage（修"整段对话绕过压缩"的真 bug）	+82/-3
#100	validateConfig 校验 nudge 数值字段（closes #46；已验证 src/config.ts:60 起确实没校验）	+137/-1
#91	nudge 摘要 token 数对齐 tokenizer（closes #45；已验证 src/nudge-text.ts:44 仍是 length/4）	+184/-10

需要 review 后再定：

PR	说明
#133	size-aware 紧急截断（billion-context-pi#12 事故驱动）。价值高（最新的大 tool-result 不再被 protectRecent 护住），但 10 文件 +534/-10，需要仔细过
#109	salvageParseRanges（5 层容错 ladder）。注意：#111 的 parseCompressArgs 已合入 master（src/parse-compress-input.ts），#109 是另一个更激进的解析器。按 #129 "单一共享解析器"的目标，需要二选一或合并设计，不能两个都留

三、open issue（22 个，除本 issue）

功能/设计类（仍需，不急）：

• feat(recommend): pluggable compression candidate planner (MICRO/EPISODE) — advisory, executor-parity #166 + feat(prompts): advisory compression prompt set (candidate-aware nudge/system/tool guidance) #167（一组）：candidate planner（MICRO/EPISODE）+ advisory 提示词集——针对"模型照单全压导致过度压缩"，依赖 fix(report): group acp_status uncompressed ranges by conversation turn #165 的 turn-grouped ranges。方向对，建议 fix(report): group acp_status uncompressed ranges by conversation turn #165 先合。
• enhancement: cross-session long-term memory — model-driven memory bank as compression byproduct (nudge-gated fork write, model-decided sedimentation) #92：跨会话长期记忆（dsh 提案）——大设计，长期议题，保留。
• Design: last-resort for non-tool content overflow — export-then-truncate vs full compression (global T2) #88：非工具内容溢出的 last-resort 设计（export-then-truncate vs 全局 T2）——设计决策未定，保留。
• Wire codecs: amazon-bedrock (Converse), cursor (gRPC AgentRunRequest), google #106：bedrock/cursor/google wire codec——backlog，难度高（无稳定 schema / gRPC 二进制），当前 fail-open 是设计行为，低优先级保留。

真实缺陷（已逐一对照当前 master 源码验证仍存在）：

• fix(config): NudgeConfig docstring defaults drift from actuals; validateConfig accepts non-finite nudge scalars that silently kill growth nudges #163：NudgeConfig docstring 漂移（src/types.ts:129 写 Default 5000、实际 20000；:133 写 0.98、实际 0.95）+ validateConfig 接受非有限值——fix: validate nudge numeric config fields #100 只覆盖一半，docstring 部分没人做。仍需。
• decideNudge: effectiveThreshold (pending 时半阈值) 是死代码——只进 breakdown,没有任何门控使用 #86：effectiveThreshold 死代码——已验证 src/compress.ts:1086-1088 只进 breakdown（:1275），无门控使用。仍需（小修）。
• feat: nudge mid-band cadence + compress rejection escalation — port omp-side fixes #45/#48 into the kernel #73：mid-band nudge 无 cadence——已验证 src/compress.ts:1079 压力带仍 "Bypasses growth gate + cadence"，75–95% 区间每轮重发。仍需（事故驱动，omp 侧已修、kernel 未收编）。
• Duplicate search paths: core.search() ignores the search/ registry (BM25/fuzzy/hybrid/semantic) #44：core.search() 仍用私有 scoreRelevance（src/compress.ts:1342），完全绕过 search/ registry（BM25/fuzzy/hybrid/semantic）。仍需（架构级）。
• scoreRelevance (core.search) uses substring counting — over-matches short query terms #50：scoreRelevance 子串计数过匹配短词——同上，仍需（小修，可与 Duplicate search paths: core.search() ignores the search/ registry (BM25/fuzzy/hybrid/semantic) #44 一起）。

小清理（真实但琐碎，建议合成一个 chore PR 一次清掉）：

• Naming collision: two distinct concepts both called growthFloor in the nudge path #43：growthFloor 命名冲突（config 字段 vs src/compress.ts:1097 局部变量，仍是两个概念）
• report.ts: effectiveCompressedTokens carries two unused legacy params, forcing placeholder args at 7 call sites #47：effectiveCompressedTokens 两个未用参数（src/report.ts:23-27，7 处调用点传占位）
• deactivateBlock: redundant field spread (durationMs/createdAt are no-ops) #48：deactivateBlock 冗余字段 spread（src/decompress.ts:63-64 no-op）
• rebuildCompressionState: shallow copy shares the blocks array with caller state #49：rebuildCompressionState 浅拷贝共享 blocks 数组（src/rebuild.ts:37；issue 自己也说当前因 applyCompression clone 而不咬人，防御性）

等 PR 合并后关闭：#93（→#123）、#101（→#103）、#45（→#91）、#46（→#100）

四、建议执行顺序

1. 关 Errors: content: range (m15930..m16063) overlaps (m16062..m16168). Overlapping ranges cannot be compressed in the same batch. #42、统一 compress 参数解析（salvage + diagnostics）— 4 个实现收敛到内核 #108（留 compress 参数解析统一：前因后果与全栈收敛（tracking） #129）
2. 合 fix(report): group acp_status uncompressed ranges by conversation turn #165（clean）→ rebase 合 fix(panel): drop window-relative percentages, lead with sent-to-LLM tokens #161、feat(report): drilldown reverse + offset options — let users reach the newest messages #123 → 合 compress: break identical-rejection retry death-loops #103、responses: fold EasyInputMessage items that omit type #102、fix: validate nudge numeric config fields #100、fix: align nudge summary token counts with tokenizer #91 → 对应关 enhancement: acp_status drilldown cannot reach the newest messages — sort:time is ascending-only, slice(0,limit) has no offset/reverse #93/compress gate: 近阈值拒绝死循环 (4914/5000 chars 被拒 101 次) + 无终止语义 #101/nudge text shows summary tokens estimated via length/4, inconsistent with the CJK-aware tokenizer #45/validateConfig() does not sanity-check the newer nudge numeric fields #46
3. review fix: size-aware emergency truncation (billion-context-pi#12) #133（事故驱动，值得）；feat: salvageParseRanges — lenient compress-arg parser (5-layer ladder) #109 与 feat: add parseCompressArgs — lenient compress-arg parsing with diagnostics #111 做合并设计决策
4. 一个 chore PR 清 Naming collision: two distinct concepts both called growthFloor in the nudge path #43/report.ts: effectiveCompressedTokens carries two unused legacy params, forcing placeholder args at 7 call sites #47/deactivateBlock: redundant field spread (durationMs/createdAt are no-ops) #48/rebuildCompressionState: shallow copy shares the blocks array with caller state #49
5. fix(config): NudgeConfig docstring defaults drift from actuals; validateConfig accepts non-finite nudge scalars that silently kill growth nudges #163 剩余一半（docstring）随手修
6. 功能线：feat(recommend): pluggable compression candidate planner (MICRO/EPISODE) — advisory, executor-parity #166/feat(prompts): advisory compression prompt set (candidate-aware nudge/system/tool guidance) #167 → Design: last-resort for non-tool content overflow — export-then-truncate vs full compression (global T2) #88 → enhancement: cross-session long-term memory — model-driven memory bank as compression byproduct (nudge-gated fork write, model-decided sedimentation) #92 → Wire codecs: amazon-bedrock (Converse), cursor (gRPC AgentRunRequest), google #106（按此优先级排）

总评：open 列表里没有一个"不值得存在"的功能项；真正的噪音是 #140–#155 重复簇（15 个已关）和 #108/#129 双 tracking。9 个 open PR 里 7 个可直接推进，2 个需 review。需要我执行第 1、4 步（关 issue、提 chore PR）的话说一声——PR 合并按规矩由你来点。

[ranxianglei]

#165 按照对话分组 详细解释发生机理

[ranxianglei]

🤖 ework agent · vllm-qwen/qwen3.8-27b

[bot] #165 的"按对话轮分组"机理详解（对照当前 master 源码 + PR diff）：

1. 问题是怎么发生的（master 现状）

acp_status({scope:"uncompressed"}) 默认走 renderUncompressedRanges（src/report.ts:204）。它把可见消息合并成 range 的规则只有一条：

if (last && num === last.startNum + last.count) {
    // 合并进上一个 range
}

即：只要 ref 编号连续就合并。而 ref 是密集分配的（m00001、m00002、m00003…），长会话里几乎永远连续。结果：整个可见窗口塌缩成一个巨无霸 range，例如：

m00001–m00150  (150 msgs, 120K (800/msg)) bash

这一行对"我该先压什么"毫无信息量——150 条消息横跨几十个对话轮，模型没法从中挑出一个自包含的压缩单元。于是模型退回 view:"messages" 逐条看（firehose，更费 token）。这就是 billion-context-pi#193 的现象。

2. 修复的分组机理（#165）

核心改动就一个判断。合并循环里加了一个对话轮边界条件：

const contiguous = !!last && num === last.startNum + last.count;
const turnBoundary = !!last && m.isUser && last.count >= 3;
if (contiguous && !turnBoundary) {
    // 合并
} else {
    // 开新 range
}

（isUser 来自新增的 VisibleMessageInfo.isUser，在 collectVisible 里取 message.role === "user"。）

拆分规则拆开看：

• 触发点 = 用户消息。agent 循环里每个对话轮的结构是：user(请求) → assistant(text/tool-call) → tool-result → assistant(text) → …。用户消息是天然的轮次起点——遇到它，说明上一轮的工作序列结束了。
• 阈值 = 当前组 ≥ 3 条。这是关键细节，防止碎片化：
  • 若组内已有 ≥3 条（一个完整轮次的工作量：用户请求 + 至少两条助手侧消息），后面的用户消息 = 新一轮开始 → 拆。
  • 若组内 <3 条（比如只有 user + 1 条 assistant text 的短尾巴），后面的用户消息不拆，继续合并——否则每个短交互都会碎成独立 range，视图又退化成 firehose。
• ref 断档仍然拆（原 contiguous 条件保留），两个条件取或。
• 用户消息本身归入新组（拆分发生在 push 之前），所以除第一个 range 外，每个 range 都以一条用户消息开头——range 的起点就是"这一轮用户要什么"，自包含。

为什么是 ≥3 而不是 ≥1/≥2：这不是 #165 发明的，而是照抄 buildCompressibleRanges 的既有条件（src/recommend.ts:216）：

if (cur && ((info.isUser && cur.count >= 3) || hasGap)) {

nudge 注入的 "Compressible Ranges"（上下文 breakdown 里列的那些 range）一直就是用这个条件分组的。#165 做的事本质是让 acp_status 的 ranges 视图和 nudge 建议的压缩单元对齐——修复前两者粒度不一致：nudge 说"压 m00040–m00055 这一轮"，acp_status 却只显示一个巨无霸 range，模型无法把两者对上。修复后同一个条件、同一套边界，视图直接就是可执行的压缩候选列表。

3. 具体例子（PR 新增测试的场景）

8 条消息，3 个轮次：

m00001 user "start turn one"
m00002 tool-result bash (4 tokens)
m00003 assistant "done one"
m00004 user "start turn two"
m00005 tool-result bash (4 tokens)
m00006 assistant "done two"
m00007 user "start turn three"
m00008 assistant (20 tokens)

• master：m00001–m00008 (8 msgs) 一个 range。
• fix(report): group acp_status uncompressed ranges by conversation turn #165：走到 m00004（user，前组 count=3 ≥3）→ 拆；走到 m00007（user，前组 count=3）→ 拆。得到：

  Sorted by size
  
    m00007–m00008  (2 msgs, 23K (12/msg)) text
    m00001–m00003  (3 msgs, 9K (3/msg)) bash
    m00004–m00006  (3 msgs, 9K (3/msg)) bash
  

4. 配套改动（服务于同一个目标）

• 默认按 size 降序（tie 用 startNum 升序），sort:"time" 保持时间序，并加 Sorted by size|time 头显式声明排序——视图直接回答"先压哪个"。
• limit 选项生效（原来硬编码 30）。

5. 边界情况与局限

• 连续两条用户消息（user→user→assistant…）：第二条 user 只在第一组 ≥3 时才拆；实际 agent 循环里 user 消息之间必有 assistant 响应，基本不会触发。
• 启发式基于 role 而非真实 turn ID：没有用 runId 之类的硬边界，"轮"的定义就是"上一条用户消息以来、已积累 ≥3 条消息的连续段"。够用且零成本，但极端对话形状下边界可能偏移一条消息。
• 短尾巴（<3 条）会并入下一轮的 range 尾部——这是有意取舍：宁可边界略偏，不可碎片化。

状态：mergeable=clean，2 文件 +83/-10，4 个新测试（拆轮/size 排序+tie-break/time 序/limit），全套 544 pass。是 #166/#167（advisory 提示词集引用 "turn-grouped range targets"）的前置依赖。

[ranxianglei]

user 切分是不是也有问题?因为有的可能非常小

另外注入提示的推荐列表是怎么做的 是否对齐

[ranxianglei]

🤖 ework agent · vllm-qwen/qwen3.8-27b

[bot] 两个问题都对照源码查过了，分开答：

Q1：user 切分会不会切出很小的 range？

会的风险存在，但方向和你担心的相反——不是"切出极小 range"，而是"小轮次被吞掉"：

机理：range 只在"当前组 ≥3 条时遇到 user 消息"才终止。所以：

• 小轮次（user + 1 条 assistant = 2 条）遇到下一条 user 时 count=2 <3 → 不拆 → 小轮次被并入下一轮的组。
• 推论：窗口中段的 range 最小是 3 条消息，不会出现 1-2 条的碎片。极小 range 只可能出现在两处：窗口最后一个 range（当前进行中的轮次，可能才 1-2 条）和 ref 断档切出的组。

代价是边界漂移：比如 [u1, a1, u2, a2, a3] 一个 range 里含了轮次 1 的尾巴 + 轮次 2 的全部，边界偏了一个轮次。对压缩无害——range 仍然连续、自包含，小轮次的内容完整落在 range 内，压了不丢东西。这是有意取舍：宁肯边界偏，不可碎片化（若每个 user 消息都拆，短交互会碎成 1-2 条的 range，视图退回 firehose）。

"太小不值得压"的问题在另一层解决（见 Q2）：nudge 推荐列表会做 mergeRangesToThreshold，把相邻轮次 range 顺序合并到 ≥ minCompressRange（默认 5000 chars），所以注入提示里的推荐列表不会推荐低于阈值的 range。例外：尾部不足阈值的 batch 仍会输出（src/recommend.ts:339-341），列表末尾最多一个小项。

注意：acp_status 的 ranges 视图（#165 后）只做轮次切分、不做 minCompressRange 合并——所以它显示的 range 比 nudge 推荐列表更多更小。这是设计差异：acp_status 是原始视图，nudge 是可执行推荐。

Q2：注入提示的推荐列表怎么做的？是否对齐？

管线（每轮执行，recommendNode → nudgeNode，src/compress.ts:534-573）：

1. computeProtectedRefs（src/recommend.ts）：保护带 = 最近 5 条消息（preserveRecentMessages=5，src/config.ts:31）∪ 最近 5000 tokens（preserveRecentTokens=5000，src/config.ts:32，从尾部向前扩）；decompress 型 tool result 排除在保护带外（isNeverPreserveRecent——大段内联恢复应可立即再压）。
2. buildCompressibleRanges（src/recommend.ts:147）：
   • 排除：synthetic/pruned、BLOCKED、保护工具消息（skill/task 等，含按 callId 配对的 tool result）、保护带内的 ref；
   • 分组：连续 ref 合并，ref 断档拆 + user 边界拆（count≥3） → compressible（时间序）；保护工具消息单独成组 → protected。
3. mergeRangesToThreshold（src/recommend.ts:322）：相邻轮次 range 顺序合并到 ≥ minCompressRange（5000 chars，src/config.ts:26）→ recommendedRanges。用与 apply 侧 applyCompression 门控相同的 chars 口径（raw text length）——这是修过一个 bug 的：token×4 估算 + CJK tokenizer（约 1:1）时 nudge 推荐的 range 会被 apply 侧拒收（src/recommend.ts:314-321 注释）。
4. decideNudge 取 recommendedRanges + protected（src/compress.ts:1266-1267）。
5. formatRanges（src/nudge-text.ts:51-121）：两列表合并、按 startNum 排序（oldest first）、相邻/重叠项合并（gap≤1 ref），渲染成：

   Compressible ranges (3, oldest first):
     m00040–m00055  16 msgs  12.3K [tool 75% | text 25%]
     m00056–m00060  5 msgs  6.1K [4.0K compressible | 2.1K protected: skill]
     m00061–m00062  2 msgs  3.0K [PROTECTED: skill — not compressible]
   

   外加 ⚠️ NOT recommended unless you are certain.（dangerous 标记，保留字段，内核目前没有任何地方设置它）和 "Compress all ranges in one call (pass multiple content entries…)"。

与 acp_status ranges 视图（#165 后）的对齐状态：

维度	对齐？	说明
切分粒度	✅	同一个 ≥3 user 边界 + ref gap 条件——这正是 #165 修的
成员	❌	acp_status 显示全部可见消息（只排除 block 覆盖）；nudge 额外排除保护工具 + 保护带 + synthetic/BLOCKED
大小	❌	nudge 合并到 ≥5000 chars；acp_status 是原始轮次 range
排序	❌	nudge 固定 oldest-first；acp_status 默认 size 降序
保护带感知	❌ 最大缺口	acp_status 完全没有 preserveRecent 概念（renderOverview/renderUncompressedRanges 均无）——模型按 acp_status 提议压最近 5 条，apply 侧会拒收（protected）。nudge 列表里它们根本不出现，acp_status 里却显示为普通可压 range

结论：#165 只对齐了"切分粒度"这一维；成员/大小/排序/保护带感知四不对齐中，前三个是设计差异（原始视图 vs 可执行推荐，可接受），保护带感知是真正的缺口——模型从 acp_status 看到的可压范围比实际可压的宽，会撞 apply 侧拒收。建议立一个 follow-up issue：acp_status ranges 视图标记保护带（如 [recent-zone] 后缀）+ 可选显示 minCompressRange 提示。要我开这个 issue 的话说一声。