llm-intelligence/reports/openclaw/OPENCLAW_CAPABILITY_BACKLOG.md

OpenClaw Capability Backlog

本文件用于持续沉淀 OpenClaw 在 llm-intelligence 项目推进和自我优化过程中暴露出的能力缺口。

记录原则：

• 只写真实 review 暴露的问题
• 每个问题都要说明影响
• 每个建议都要可执行、可验证

---

当前未修复问题速查表（截至 2026-05-15 21:31）

#	问题	优先级	首次暴露	修复状态	影响次数
1	验证器 rg 依赖误报	P0	05-07 22:50	✅ 已修复（05-10 14:30 确认 grep 替换完成）	10 次
2	验证器退出码设计	P0	05-07 22:50	⚠️ 部分（rg 误报消除，但三级状态仍未实现）	10 次
3	session 历史工具/业务错误区分	P1	05-07 22:50	❌ 未修复	11 次
4	cron 无主动状态报告机制	P1	05-07 22:50	❌ 未修复	11 次
5	subagent spawn 未传递 workspace	P1	05-07 22:50	❌ 未修复	11 次
6	验收脚本无法检测构建	P1	05-08 09:05	❌ 未修复	10 次
7	环境变量/API Key 缺失未自动检测	P1	05-08 09:05	⚠️ 部分（已写入 review 标准步骤，但未固化到 prompt）	11 次
8	文件修改后未触发 commit 提示	P2→P1	05-08 09:05	❌ 未修复	12 次
9	cron review 无 delta 时空转	P1	05-08 09:12	❌ 未修复	12 次
10	验证模式伪进展（artifact_present 局限）	P1	05-08 14:30	❌ 未修复	9 次
11	项目提交停滞（commit stagnation）	P0	05-08 21:30	❌ 未修复（虽有新 commit，但工作区长期非干净问题仍在）	14 次
12	review 报告未触发修复动作	P2→P1	05-08 21:30	❌ 未修复	9 次
13	BACKLOG 文件膨胀导致 review 成本递增	P1	05-09 09:30	⚠️ 部分（已实施分层归档，但主文件仍在增长）	7 次
14	untracked 核心代码未入版本控制	P0	05-10 21:30	❌ 未修复（本轮仍有大量 untracked 文件）	10 次
15	CI 配置存在但未验证运行	P1	05-10 21:30	✅ 已修复（05-14 16:23 已补齐 .github/workflows/ci.yml 且 verify_phase5.sh PASS）	8 次
16	Phase 6+ 范围未定义	P1	05-10 21:30	❌ 未修复	5 次
17	collection_stats vs collector_stats 表名不一致	P2	05-11 09:30	✅ 已澄清为误报（05-11 14:30 确认 verify_phase2.sh 与 schema 一致）	1 次
18	无 .gitignore 文件	P1	05-11 14:30	❌ 未修复	3 次
19	review 误报传播	P1	05-11 14:30	❌ 未修复	7 次
20	untracked 文件统计遗漏	P1	05-11 14:30	❌ 未修复	5 次
21	验收脚本瞬时回归缺少稳定性标记	P1	05-12 22:46	❌ 未修复（仍缺 transient / repeated / reproducible 标记）	5 次
22	无 delta 场景缺少老化风险优先策略	P2	05-12 22:46	❌ 未修复	3 次
23	日报归档路径门禁失配	P0	05-13 00:15	✅ 已复核（05-14 16:23 再验证未复现，verify_phase3.sh PASS）	1 次
24	综合验收错误聚合误导根因判断	P1	05-13 00:15	❌ 未修复	3 次
25	snapshot truth 与 current truth 漂移未被显式提示	P1	05-14 09:31	❌ 未修复	5 次
26	Phase 6 稳定性门禁失败缺少样本窗口摘要	P1	05-14 15:10	❌ 未修复	4 次
27	Phase 6 稳定性门禁未区分前置条件缺失 vs 真实采集失败	P1	05-14 21:30	❌ 未修复	3 次
28	脚本型 Go 仓库缺少可测试入口发现能力	P1	05-15 15:11	❌ 未修复	2 次
29	长命令部分回传时缺少保守结论模板	P1	05-15 21:31	❌ 未修复	1 次

---

Review 日志

2026-05-15 21:31（第 25 次 review，night-review）

前置说明：距上一次 review（05-15 15:11）约 6 小时 18 分钟。本轮没有拿到足够新证据去推翻 afternoon 的主判断：Phase 1~5 当前仍 PASS，但 Phase 6 不能在证据不足的情况下直接改写成 PASS。与此同时，工作区持续堆积 tracked/untracked 变更而最新 commit 未前进，说明版本化收口继续老化。

本次新增发现

• Phase 1~5 当前继续 PASS：verify_pre_phase6.sh 本轮再次完整通过。
• night 时点无证据证明主 blocker 已消失：verify_phase6.sh 本轮只回传到前半段 PASS，未拿到完整结束输出，因此不能把历史活跃 blocker 直接宣告解除。
• 工作区非干净风险继续老化：tracked 修改和 untracked 新文件仍然很多，但最近提交未前进。
• 仓库已明确给出推荐验证入口：Makefile、README.md、scripts/verify_phase*.sh 都提供了更可信入口，说明 agent 默认策略需要更主动地发现这些入口。

问题 28（P1，再次确认）：脚本型 Go 仓库缺少可测试入口发现能力

• 21:31 状态：本轮继续确认本仓库的可信入口是 verify_pre_phase6 / verify_phase6 / run_daily.sh 等项目脚本，而不是通用语言惯性命令。
• 问题影响：
  • reviewer 或 agent 若先跑错误入口，会得到假阴性或低价值结果
  • review 成本上升，因为需要再次回到仓库声明的真实入口
  • 同类脚本型仓库会重复暴露相同问题
• 优化建议：
  1. review/verification 默认先搜 Makefile、verify 脚本、README 中的“常用命令/门禁入口”
  2. 若仓库显式声明入口，优先使用声明入口而不是语言通用命令
  3. 将“入口不适配”与“测试失败”分开标注
• 优先级：P1
• 建议验证方法：后续在脚本型 Go 仓库中，先读取 Makefile/README，再检查 agent 是否直接选择仓库声明入口，而不是默认 go test ./...

问题 29（P1）：长命令部分回传时缺少保守结论模板

• 21:31 状态：本轮 verify_phase6.sh 已回传多条 PASS，但未在当前对话拿到完整结束输出；如果没有明确模板，review 很容易在“部分好消息”下过度乐观，或反过来因为等待完整输出而卡死。
• 问题影响：
  • 容易把“部分通过”错误表述为“全部通过”
  • 也可能因为追求完整输出导致 cron review 超时
  • 对低频 review 任务尤其危险，因为一轮结论可能被后续长期复用
• 优化建议：
  1. 当长命令只返回部分输出时，模板强制要求写明 partial runtime evidence 与 old blocker not disproven
  2. 为 review 类 cron 任务增加“最小证据阈值”：超过阈值就允许先落保守结论，不必无限等待
  3. 在 backlog / review 模板中增加“完整结束输出是否已获得”字段
• 优先级：P1
• 建议验证方法：在长命令故意延迟或只部分回传的场景下，检查 agent 是否能稳定写出“部分通过、旧 blocker 未证伪”的保守结论，而不是误报 PASS 或无期限阻塞

2026-05-15 15:11（第 24 次 review，afternoon-review）

前置说明：距上一次 review（05-15 09:30）约 5 小时 41 分钟。本轮没有出现新的主 blocker，但稳定性窗口比 morning 更差：最新 7 条 collector_stats 中仅 4 条成功、3 条失败，成功率约 57.14%。3 条失败全部是 严格真实模式缺 API Key，说明 Phase 6 仍在被前置条件缺失污染，而且问题在老化。

本次新增发现

• Phase 1~5 当前继续 PASS：verify_pre_phase6.sh 仍全绿，说明主链路与前置门禁未回退。
• Phase 6 唯一 live blocker 仍是稳定性门禁：verify_phase6.sh 继续表现为 pass=15 fail=1。
• 稳定性窗口较 morning 进一步恶化：从 5/7 成功下降到 4/7 成功，不能再沿用上午窗口数字。
• 失败样本仍全部指向前置条件缺失：最近 3 条失败都为 严格真实模式下必须提供 API Key。
• 通用 go test ./scripts/... 在本仓库给出假阴性：命令返回 matched no packages / no packages to test，但仓库声明的 verify_phase*.sh 却能提供有效验证结果。

问题 25（P1，再次确认）：snapshot truth 与 current truth 漂移未被显式提示

• 15:11 状态：同日两次 review 的主 blocker 没变，但严重度已变化；如果 afternoon 不 live 复验，仍会沿用 morning 的 5/7 窗口，低估风险老化。
• 问题影响：
  • 同日数小时内窗口数字会变化，旧结论若不失效会直接误导风险判断
  • backlog 和 follow-up 可能继续引用过时窗口，影响优先级排序
• 优化建议：
  1. review 模板在涉及样本窗口时强制写“sample timestamp / sample size / sample freshness”
  2. 若当前窗口与上一轮数值不同，必须显式写出 window changed 或 old sample expired
  3. 对同日多次 review 的窗口漂移单独累计，而不是只记泛化的误报传播
• 优先级：P1
• 建议验证方法：后续若同日两次 review 的窗口成功率变化，检查新报告是否显式指出窗口已变化，而不是继续复用上一轮数字

问题 27（P1，再次确认）：Phase 6 稳定性门禁未区分前置条件缺失 vs 真实采集失败

• 15:11 状态：最新 7 条样本中 3 条失败全部来自 openrouter，且错误一致为 严格真实模式下必须提供 API Key。
• 问题影响：
  • 稳定性统计继续把环境/调度问题混进 collector 运行失败
  • review 读者可能误把 57.14% 成功率解读为采集器代码不稳定
  • 修复资源会被错误投向代码层，而不是运行环境/统计口径
• 优化建议：
  1. 在 verify_phase6.sh 或其依赖查询中增加失败分类，至少区分 precondition-missing、collector-runtime-failure、external-provider-failure
  2. 对缺 API Key / 缺 DB 权限这类前置条件失败单独统计并显式展示
  3. 输出中附最近 N 条失败样本摘要，避免只给一个成功率数字
• 优先级：P1
• 建议验证方法：制造一条缺 API Key 失败和一条真实采集失败，确认 Phase 6 输出能分别标记类别，并在 review 中直接映射到不同修复路径

问题 28（P1）：脚本型 Go 仓库缺少可测试入口发现能力

• 15:11 状态：本轮尝试常见 Go 测试入口 go test ./scripts/...，结果为 matched no packages / no packages to test；但仓库真实可执行门禁位于 Makefile 和 scripts/verify_phase*.sh。
• 问题影响：
  • agent 若按通用语言惯性选命令，会得到假阴性，误判仓库“不可测试”或“测试失败”
  • review 成本上升，因为需要人工再纠正到项目自定义验证入口
  • 跨项目迁移时，这类误用会持续产生噪声
• 优化建议：
  1. 在 OpenClaw review/verification 流程中优先发现并使用 Makefile、package.json scripts、仓库显式 verify 脚本，而不是默认语言通用命令
  2. 若检测到 go test ./... 或其子路径返回 no packages to test，应把它标记为“入口不适配”而非“测试失败”
  3. 在 review 模板中增加一条“验证入口发现结果”，明确当前仓库推荐的最小可信命令
• 优先级：P1
• 建议验证方法：在至少一个脚本型 Go 仓库中复现 no packages to test，确认 agent 最终能回退到项目声明的 verify 脚本，并把错误类型归为入口不适配