Evidence and Evaluation：怎样证明一项 Agent 能力值得它的完整成本？

[tt-a1i]

这是 OpenPI 产品哲学总纲 #299 的证据专题。

前几个专题已经提出了多组竞争假设：工具全量常驻还是渐进加载、Explicit 还是 Adaptive、Provider-native deferred 能否保住前缀、动态能力怎样跨越 Compaction。它们不能继续只靠 Token 直觉或单次 Benchmark 输赢来决定。

本专题讨论：怎样证明一项 Agent 能力产生的价值，覆盖了它的静态成本、动态激活成本、错误轨迹、安全边界和长期维护成本？

先固定证据语言

建议所有实验与公开结论明确区分：

• Fact / Source Fact：固定源码、配置或 Provider 文档直接可见；
• Observation：本次运行实际记录了什么；
• Correlation：两个现象同时出现，但尚未证明因果；
• Verified Cause：通过对照或机制级 instrumentation 排除了主要替代解释；
• Inference：依据机制做出的可检验推断；
• Unknown：当前证据不能回答。

还要区分交付状态：

本地实验
≠ 仓库验证
≠ CI 通过
≠ 合并
≠ 发布
≠ 当前安装运行验收
≠ 可公开访问的 canonical evidence

完整价值模型

单独看采用率、Schema tokens 或 pass rate 都不够。一项能力的期望净价值更接近：

P(任务确实适用)
× P(模型正确发现并采用 | 适用)
× 采用后的质量/效率/风险收益
-
全体任务承担的静态工具与 Prompt 税
-
首次激活和重新投影成本
-
错误加载、错误调用与长轨迹放大
-
权限、资源、恢复和清理风险
-
实现、测试、文档和维护成本

低频能力仍可能有很高价值；高采用能力也可能只是被模型滥用。目标是净收益，不是最大化 Tool Call 数。

五层证据必须分开

1. 请求形状与静态表面

记录：

• system/developer/context bytes；
• active/immediate/deferred tools；
• Tool Schema bytes 与 fingerprint；
• gateway、Skill index 与其他固定注入；
• Provider request class、cache key fingerprint；
• ordinary first request 是否与 Bare Pi 语义相同。

这能证明固定税和请求差异，不能证明模型质量因果。

2. Provider usage 与 cache boundary

记录逐 turn：

• uncached input；
• cache read / cache write；
• output / reasoning；
• request bytes、TTFT、wall 和 cost；
• tool-surface、model、thinking、compaction 与 branch boundary。

Provider-reported usage 是证据；cache key、配置项和延迟不是 cache hit 证明。

3. 机制采用

分开记录：

• capability 是否 loaded；
• Tool Definition 是否 visible；
• 模型是否实际调用；
• 调用是否被 Runtime 授权；
• Child/Workflow 是否真的执行；
• 结果是否被父模型使用；
• 失败、取消和清理 receipt。

如果 openpi_load_tools=0，只能评价 gateway 的静态税和采样影响，不能声称验证了动态能力收益。

4. 任务结果

至少报告：

• 独立 verifier 的 task success；
• artifact/protocol/infrastructure/provider/verifier failure 分类；
• turns、tool calls、tokens、cost、wall；
• 非平局 pair 与不确定性；
• 是否存在极端长尾；
• 模型最终声明与实际 artifact 是否一致。

自评、工具执行成功、测试通过和任务解决不是同一个证据状态。

5. 生命周期与安全

覆盖：

• 用户明确授权、禁止和费用敏感场景；
• Parent/Child authority intersection；
• cancellation、timeout、cleanup；
• compaction、resume、fork、provider/model switch；
• 权限或资源收缩后的 fail-closed；
• replay 与 fresh execution 区分。

性能更好不能抵消越权或不可恢复状态。

6. 完整执行总账

不能只报告 Parent Session usage。至少合并：

• Parent 的全部模型请求；
• 所有 Child/Subagent/Workflow 模型请求；
• gateway、catalog/search 等辅助调用；
• 后台任务、compaction pass 和恢复调用；
• replay 与 fresh execution；
• 并发后的 wall-time 与总计算量分别报告。

如果 Child/provider usage 不可得，应标记为 lower bound / unknown，不能把成本转移到不可见 ledger 后宣称 Parent 更省。

7. 用户体验证据

Agent 能力的净收益还包括：

• 用户是否理解为什么能力被加载或额外模型调用被启动；
• 用户是否需要记忆 OpenPI 专有词汇；
• 首次结果延迟与中间进度是否可解释；
• stop/cancel 是否可靠；
• 错误自动委派是否可恢复；
• 权限、费用和恢复行为是否符合用户预期。

独立 verifier 和 Token 数据不能替代这些证据。

应该分开的实验赛道

A. Ordinary-task 负控赛道

任务不需要 OpenPI 高级能力。测量零常驻、gateway 固定税、无理由加载和普通 Pi 兼容性。

它可以证明“没有明显固定伤害”，不能证明 Subagent/Workflow 的价值。

B. Capability-demand 赛道

任务设计必须让某项能力产生可独立验证的价值，例如：

• 多个相互独立且都必须覆盖的调查面；
• 需要跨时间等待的长后台任务；
• 需要阶段隔离、恢复或重放的 Workflow；
• 结构化搜索相对 Bash 搜索存在可测收益。

同时保留直接使用 Pi primitive 的强基线，避免把“用了能力”误当成“能力有用”。

C. Provider/cache 确定性赛道

不能把 Explicit/Adaptive、是否多一次 loader call、工具序列化位置和 Compaction 同时改变后，再把结果归因于“渐进加载”。应采用三轴析因设计：

Discovery / Authority
- explicit before_agent_start
- adaptive loader
- forced known activation（不经过模型判断）

Serialization
- stable full top-level tools + allowed subset
- top-level mutation fallback
- Pi client-side native append
- Provider hosted tool search（若支持，单独一臂）

Lifecycle
- no compaction
- Pi compaction：load point retained
- Pi compaction：load point dropped
- Provider-native compaction

Pi client-side append 与 Provider hosted search 必须分开：前者由应用返回 completed search/load items 后继续采样，后者可能在同一 Provider response 内搜索并调用，roundtrip 和失败模型不同。

正式比较前先用 byte-identical replay 确认 cache read 非 0，并冻结 exact provider、API protocol、model snapshot、adapter flags、hosted/client mode、隔离域、region、TTL、cache key、请求速率与价格表。重复多次，不把单次路由 miss 当成 prefix 因果。

逐次分开记录：

effective context tokens
billed uncached / cache-read / cache-write tokens
serialized request bytes

先证明 request shape 和 cache 因果，再跑自然模型采样。

D. 长 Session 与恢复赛道

覆盖 late activation、repeated compaction、Session resume、Provider switch、权限收缩和资源终止。相关设计见 Tool lifecycle across context epochs #311。

Compaction 至少拆成：

1. compaction pass 自身的 input/cache/output、cost 与 latency；
2. compacted output 的 effective token size；
3. 下一次普通请求的 read/write/uncached input；
4. stateless replay request bytes 或 server-state reference bytes；
5. active tools 在新 epoch 中是 deferred 还是 immediate。

E. Discovery 与授权赛道

覆盖明确要求、隐含适用、完全不需要、明确禁止四种任务，比较 Explicit、Adaptive 与双路径。相关讨论见 Capability Discovery and Authority #312。

Benchmark 设计底线

• 固定 Provider、model snapshot、thinking、Pi/OpenPI revision、task、verifier、timeout 和候选边界；
• 使用 AB/BA 或其他可解释配对顺序，保留独立 samples；
• 先验证 instrumentation canary，再跑正式 cells；
• 0 tokens 必须区分真实零与 Provider 未提供 usage；
• capability adoption 为零时，不宣传 capability uplift；
• 两个 arm 首请求完全相同时，不把独立采样差异归因给隐藏机制；
• cache read 量高不自动等于成本低或质量好；
• 总量与逐 turn 同时报；
• 报告样本量、非平局数、长尾、失败分类和限制；
• 原始敏感证据可留在独立 content-addressed archive，但公开结论必须有可访问、可校验的 canonical record。

当前讨论暴露出的证据缺口

1. 现有普通 coding benchmark 中，高级能力自然采用很低，不能据此评价真实编排收益；
2. 已观察到 adaptive gateway 的固定小税和少数错误采用，但还没有稳定证明隐含适用任务上的正收益；
3. 已从源码确认 Pi/provider-native deferred 路径，但缺少 late-K 暖缓存的 wire-level 与逐 turn usage 闭环；
4. before_agent_start 直载、native deferred 与不支持 Provider 的 fallback 尚未在相同 transcript 下对照；
5. Compaction 后的重新物化、Session 恢复和权限收缩尚无完整 receipt；
6. Discussion 引用的证据必须确保在目标分支可访问，不能把 operator-local 报告当成已公开记录。

这些缺口不是否定现有方向，而是限定现在能说到哪里。

改变默认策略的门槛

将 Adaptive 升为默认

至少需要同时证明：

• 隐含但真实适用任务上的成功率或效率稳定提升；
• ordinary task 无理由加载率足够低；
• 固定入口税与额外轨迹在真实 Session 分布下可接受；
• 未授权执行为零，Runtime 拒绝有 receipt；
• native 与 fallback Provider 分开报告；
• 强弱模型分别有清晰边界。

将某项高级能力升为稳定核心

至少需要证明：

• 真实采用率高；
• 首次使用通常足够早；
• Schema 足够小且接口正交；
• 对 task outcome 有稳定净收益；
• 增加选择面不会显著提高误调用；
• 全量常驻优于 native deferred 的主要收益不仅是省掉一次 gateway。

删除或弱化某项能力

低采用率本身不够。还需要证明适用任务中直接 Pi primitive 或更强模型能稳定替代，并且没有丢失关键生命周期、权限或恢复能力。

证据如何进入产品

Discussion
  → 明确假设、竞争方案、决策门槛
Experiment / Benchmark
  → 产生固定身份和原始 receipt
Decision / Design record
  → 记录稳定结论、适用范围、未知和替代方案
Issue
  → 只承载已经明确的实现或下一实验
PR
  → 交付，不重写历史证据

历史结论被新证据替代时，应标记 superseded 并链接替代记录，不静默重写。

与现有工作的关系

• #20：工具面历史、三臂诊断与普通任务证据；
• #84：Schema、选择面、缓存稳定和 bounded design；
• #156：逐 turn cache observability；
• #191：缓存、上下文、Memory、Compaction、Replay 的证据边界；
• #194：模型可见注入面、顺序、权限与 receipt；
• Tool Surface Economics #300：完整工具成本与加载策略。

非目标

• 不为跑分加入 Benchmark-only 提示或隐藏 Workflow；
• 不把 Provider 偶发波动解释成产品机制；
• 不用单次胜负替代配对证据；
• 不追求一个脱离任务分布的“通用 Agent 分数”；
• 不以实现复杂度作为必须保留某项能力的理由；
• 不因为模型更强就预设 Harness 一定更有用或一定更没用。

希望讨论最终形成一份可复用的判断合同：

什么证据足以新增、默认开启、保持 opt-in、进入稳定核心、重设计或删除一项 OpenPI 能力？

[tt-a1i]

2026-08-30：来自群聊的待验证线索

下面这些内容值得保留和追查，但目前证据身份不完整，因此只记录为 Claim / Anecdote / Unknown，不作为竞品结论。

1. “重工具面”的实际代价

群聊中提到一个基于 Pi 的扩展包，其工具描述和初始上下文很重，并出现了两个具体说法：

• 首轮 Token 开销“超过纯 Pi 五倍”；
• 实测任务中，模型很少真正使用已暴露的高级能力。

这里的产品名在聊天记录中存在 OMO / OMP 混用，需要先确认比较对象。数字也需要找回对应 OpenPI Issue、冻结 revision、模型、任务、usage 和原始 receipt。

这个线索真正值得验证的不是“某产品太重”，而是：

全量暴露的高级能力数量
→ 首轮静态成本
→ 实际 capability adoption
→ task outcome 增益

如果前三项可测而最后一项没有增益，才构成“工具面没有覆盖成本”的证据。

2. Maka 与 OpenPI 的比较说法

群聊中还出现了“Maka 在一次对比中不如 OpenPI”的经验判断，同时提到其项目背景。当前没有随聊天提供可公开复核的：

• 精确项目与版本；
• Provider / model / thinking；
• task 与 verifier；
• OpenPI、Pi 和对方产品的配置对齐；
• 逐 turn usage、工具采用和失败分类；
• 原始结果与 canonical report。

因此它只能作为一个待重跑的比较线索，不能写成产品优劣结论。项目背景本身也应由项目官方来源单独核验。

3. OpenCode 尚未形成比较证据

聊天中有人询问是否测过 OpenCode，回答是没有做该项对比。这个“没有测”也应保留，因为它限定了当前结论的外推范围：不能把对 OMO/OMP 或 Maka 的体验扩展成对所有 Agent Harness 的判断。

4. Benchmark 宣称与机制采用可能脱节

群聊观察到，外部项目经常宣称支持 Workflow、Subagent 和多种工具，但排行榜或跑分任务未必真正触发这些高级能力。后续竞品比较必须分开报告：

• 宣称支持；
• 工具定义可见；
• 模型实际加载；
• Runtime 实际执行；
• 结果被父模型采用；
• 对最终 verifier 的增益。

没有 mechanism adoption，就不能把跑分输赢归因于 Workflow、Subagent 或动态工具面。

5. “模型越强，旧 Harness 越可能成为负担”仍是双向假设

模型快速迭代会改变工具选择、规划和直接完成任务的能力。每次模型升级都可能让旧 Prompt、重 Schema 或固定 Workflow 成为负担；也可能让模型更会使用小而正交的能力。

所以升级后不应机械携带全部旧能力，也不应机械删除。应在固定新模型 snapshot 后重新测：

• 无 Harness 强基线；
• 只暴露小型正交 primitive；
• 完整高级能力面；
• native deferred / catalog 发现路径。

这些线索怎样转成可引用证据

1. 先确认 OMO/OMP、Maka、OpenCode 的准确项目身份；
2. 找回所谓“五倍”及低采用率的原始 Issue/运行记录；
3. 固定双方 revision、模型、任务和 verifier；
4. 同时报首轮静态税、逐 turn usage、capability adoption、task result 和长尾；
5. 公开可访问的报告形成前，只能引用为待验证线索；
6. 若新证据推翻旧体验，保留旧记录并标记 superseded，不静默改写。

这组线索归入本 Evidence 专题，不另开“竞品输赢帖”，避免让未经复核的体验变成营销结论。

[tt-a1i]

竞品线索的公开证据补充与限定

前一条评论把 OMO/OMP、“五倍”和低采用率全部标成 Unknown 是安全的，但现已找到部分公开冻结记录，可以把一部分升级为 bounded observation：

• #45 的冻结 OMP 17.2.12 / DeepSeek 诊断记录：Pi-native 首请求约 1.7k tokens，OMP 约 16.1k，约 9.4×。这只证明该版本、模型和配置下的首请求静态输入差异，不代表所有 Session 总成本，也不能外推到名称相近的 OMO。
• 同一批 OMP trace 中，完整 task/hub/多代理编排没有明显采用，但专用 eval 被调用 16 次。因此只能说“部分高级编排机制未触发”，不能笼统写成“高级能力基本没用”。
• #46 的冻结普通 Terminal 切片中，GLM‑5.3 两者同为 7/9；OMP provider tokens 为 OpenPI 的约 6.56×。Luna arm 的 usage 不可得，不能据此声称 Token 优势。该记录不能推出 OMP 普遍差于 OpenPI。
• #20 的三题 DeepSeek 诊断中，OpenPI 与 Maka 都为 2/3，OpenPI comparable main tokens 还比 Maka 高约 6.4%。因此群聊中“Maka 不如 OpenPI”仍只能保留为未绑定运行的 Anecdote，不能晋升成排名。
• 当前这组 OpenPI 内部比较没有运行 OpenCode arm，因此本讨论不能对 OpenCode 作产品或效率结论；这不等于外部从未测过 OpenCode。

这些记录替代了“完全没有公开证据”的判断，但没有消除版本、任务、Provider、采用率和因果边界。任何对外结论仍应引用精确 Issue/record，而不是复述群聊数字。

[tt-a1i]

2026-09-09：一份还没跑的插件试验配方（fd/rg vs LSP vs fff）

这不是一次运行，也不是新的评测产品。#313 正文已经有证据语言、价值模型和赛道 A–E；仓库已经有 docs/benchmarks/PI_OPENPI_BENCHMARK_PROTOCOL.md 与结果模板。缺的是 2026-09-09 插件对照能执行的最小细胞，而不是第二套 eval OS。

本地研究笔记（未进 Git）：docs/research/EXPERIMENT_EVIDENCE_EVAL_2026-09-09.md。能力归属不变：LSP → #163，fuzzy/semantic → #503。AST 仍走 #510，DAP 仍走 #168。

基线（#503 已写死，这里只复述）

证伪「还要第三种搜索」或「值得付 LSP 税」时，对照臂必须是 同一模型 + 已加载 OpenPI search 的 fd/rg。禁止用「没加载搜索、只靠弱模型乱猜」当 Arm A。

一次战役，三个问题，不要合成「代码智能总分」

问题	#313 赛道	臂
Q1. 已加载 fd/rg 之后，fuzzy 还有没有净收益	B	A vs C_fff（@ff-labs/pi-fff 0.10.6 默认安装，负例，不作为 Adopt 候选）
Q2. lsp_diagnostics 在类型/重载上是否优于纯文本	B	A vs B_lsp（OpenPI 自有、mutation-off、按调用 spawn/shutdown；不装 Lens）
Q3. 只多实验工具 schema 时，普通题有没有固定伤害	A 负控	N = explicit 且 search 未加载，不装社区包

A = 官方 find/grep + 已加载 OpenPI search（fd/rg + 只读 git）。这是产品「用户已经要搜索」的状态。

不要三臂混报一个 winner。不要把 C_fff 的 T_typo 赢面写成 Adopt。colgrep / AST / DAP / Lens 整包不进第一战役。

题型必须拆开

• T_known 拼写正确的符号：A 一次 fd/rg 应够；第三工具不得用更多 turn 换同样正确率。
• T_typo 拼错/残缺路径：正确文件率 和 误报文件率一起报。
• T_intent 关键词不明：成功键是最终读到的正确实现，不是第一次结果「像」。
• T_absent 仓库里没有：必须 miss；弱匹配截断不得当命中；空索引 ≠ 空仓库。
• T_reexport / T_diag / T_alias（只服务 Q2）：重载/re-export、真实类型错误、文本同名语义不同。B_lsp 必须降低误改，且相对 Pi 原生 edit 零额外 format/autofix/test 写盘。

冻结与失败类（沿用已有协议，不新造枚举）

冻结：单一 OpenPI revision、单一 Pi build、当前默认模型（弱模型只许第二 campaign）、三个真实仓（TS / Python / Go 或 Rust）、隐藏程序化 verifier、suggestions 与 post-edit 关闭。

失败类沿用协议与 2026-08-26 记录：passed / task_failed / budget_exhausted / infra_failed，外加 protocol、provider、verifier、capability-policy。自评、工具成功、测试绿 ≠ 任务解决。0 tokens 区分真实零与 usage 缺失；嵌套 usage 不可得标 unknown，禁止写成 0 再宣称更省。

采用表与结果表必须分开：search 是否 loaded、fd/rg 次数、lsp_diagnostics 次数、fffind/ffgrep 次数、父模型是否读了结果、最终 artifact。adoption = 0 时不准宣传 capability uplift。

成功（必须同时成立）

当前默认模型上：Q2 的正确文件:行上升且误改不升；Q1 若声称有收益，T_typo/T_intent 上升且误报不升。普通 turn 在加载前 OpenPI 工具面仍是 []。缺失服务器 / 取消 / 超时是可操作错误，不伪装成「无匹配」或「0 diagnostics = clean」。session_shutdown 无残留 language-server / fff。child 无未分类工具，无 lsp_fix/lsp_rename，不能扫 $HOME。

只在弱模型上有增益、正确率持平但 schema+索引税明显、迟到结果跨 epoch、或把 C_fff 写成 Adopt——整臂不得升默认。

非目标

不新开评测 CLI / docs/evals/ / 插件排行榜。需要 runner 时只给已有 benchmark-pi-openpi 加臂配置。不为跑分加「请先调用 lsp_diagnostics」的系统句；adoption 为 0 是有效结果。不把 2026-08-26 Luna 的包级 +5 pass 抄到 #163 / #503（那次 explicit 细胞 openpi_load_tools=0）。

本条是 Claim / 试验设计。在有人按上面跑完并写出 docs/benchmarks/runs/ 记录之前，#503 继续 Discuss，#163 可以门后试点但不得升默认加载。

[tt-a1i]

2026-09-09：Q1/Q2 Arm A 的题身份（Luna 五题填不上这些空格）

结论先行。 Luna 2026-08-26 五题是 #313 赛道 A 的历史包级税，不是本战役 Q1/Q2 的 Arm A。不要抄 15/15、不要同题重跑当定位基线、不要把 Bare Pi / 未加载 search 叫成 Arm A。四道 polyglot 字节只许进 Q3，且必须新 campaign、新 archive。lsp_diagnostics 在本对照的两棵树上都不是活工具；把 a9b40f0 或 0d17f45 上的空调用写成「LSP 无增益」是假标签。

这不是一次运行，也不改 2026-09-09 配方评论里的臂表。配方仍在上面那条（fd/rg vs LSP vs fff）。缺的是 可冻结的题身份 + file:line verifier，避免以后付费细胞去 join Luna 那 60 格。

SHA（本轮 git rev-parse）

树	commit	package
本地 checkout（09-09 实现基线）	a9b40f0044ee59c360a6077c1c0bdbdbd30da10b	OpenPI 0.4.0
origin/main	0d17f4577fe31315fe6c95370d251bdb4e2413cf	0.8.1
Luna 被测包	2a69d3f32994da4123f1312b7fa84ef3d6119be1	更早；不得与上两行混表
polyglot 题源（仅 Q3 字节）	7e0611e77b54e2dea774cdc0aa00cf9f7ed6144f	Aider/Exercism

git grep：lsp_diagnostics / lsp_goto 在 a9b40f0 与 0d17f45 都是空集。search 组两边都是 fd/rg + 只读 git。#163 仍是 OPEN 试点票，不是这两棵树上的 registerTool。

本地研究笔记（未进 Git，勿当成 origin/main blob）

• docs/research/EXPERIMENT_LUNA_REUSE_2026-09-09.md — 五题为何是错形状；三种「复用」都不成立。若该路径在 main 404，以本地 checkout a9b40f0 工作区为准。
• docs/research/EXPERIMENT_ARM_A_TASK_SHAPE_2026-09-09.md — Q1/Q2 题身份合同、隐藏 oracle 形状、本树六个 q1.a9b40f0.ts.* 种子、Q2 形状种子、以及「无 lsp_diagnostics 则 B_lsp 不可计模型分」。

（这两份此刻是 operator-local research。链接指向 upstream main 只为路径稳定；以 SHA + 本地文件为证，不要把 404 读成「记录不存在」。）

事实（不是分数）

• Q1 = locate。成功键是读到隐藏 oracle 的文件:行（工具 read / rg 命中），外加误报与 T_absent 必须 miss。Hidden unit-test pass@1 是错主键。
• Q1/Q2 Arm A = 官方 find/grep + 已加载 OpenPI search。不是协议里的 Bare Pi 臂 A，也不是 Luna explicit（当时 capability calls = 0）。
• Q2 = diagnose，与 Q1 分表。治疗是 OpenPI 自有 lsp_diagnostics。该名字不在 a9b40f0 / 0d17f45。在这两颗 SHA 上启动 B_lsp → infra_failed / campaign 不可跑，不是 task_failed。
• Q3 = 可选 schema 税。只复用四道练习字节：go-book-store / python-bottle-song / javascript-connect / rust-nucleotide-codons。丢掉或另表 adaptive-policy-discovery。禁止抄 Luna 10/15、15/15。
• 本树是 TypeScript（约 238 个 .ts），没有生产用 .py/.go/.rs。够填 Q1 的 allowlist / 意图 /「本 SHA 没有 lsp_diagnostics」负控；不够单独当 code-intelligence: 研究按需加载的 Pi-native LSP 能力，而不是常驻第二套 IDE Runtime #163 的三语言仓。

本树种子（身份，不是已跑细胞）

Q1 例：q1.a9b40f0.ts.T_known.child_safe_allowlist（权威 CHILD_SAFE_PACKAGE_TOOL_NAMES @ extensions/shared/child-session.ts:25–31；干扰是 PLAN_MODE_CHILD_TOOLS / READ_ONLY_AGENT_TOOLS）；q1.a9b40f0.ts.T_absent.lsp_diagnostics（oracle 为空；编造文件即失败）。Q2 形状例：改 sanitizeTerminalText 不要只改 sanitizeText 包装。正式细胞的候选快照必须剥掉 docs/research/，否则本评论和笔记就是泄漏的 gold。

建议 / 未知

引用 Luna，不要续写 Luna。正式数字另开 docs/benchmarks/runs/YYYY-MM-DD-search-lsp-fff.md。需要 runner 时只扩展已有 benchmark-pi-openpi 臂配置。不新开 Issue / Discussion / docs/evals/。不 pi install 社区包凑题。

未知：未打开 Luna archive；未核本机 pi list；未钉 Python/Rust 公开仓；未在任一 SHA 上实现 lsp_diagnostics。本条是 Claim / 题身份。在按上面跑完并写出 Benchmark 记录之前，#503 继续 Discuss；#163 可以门后试点，但不得在无工具的 SHA 上升默认或报 B_lsp 模型分。