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，而不是复述群聊数字。