一句话结论

#18 的渐进式工具面改进解决了 setup / episode 生命周期和一部分常驻 schema 膨胀，但它保留的 7 个 OpenPI “紧凑入口”对 DeepSeek V4 Flash 仍然太重。当前实测中，OpenPI 没有提供一次可观察到的增量能力调用，却显著增加首请求、总上下文、工具调用和完成时间。

这说明下一阶段不应继续微调 7 个入口的描述，而应把 OpenPI 从“常驻若干入口工具”改成“Pi 核心工具 + 一个极小能力网关 + 会话内稳定的能力组 + 有界工具结果”。Maka 的 headless profile 证明了极小默认执行面的价值；Codex CLI 则提供了更完整的长期参照：每步工具计划、Direct / Deferred / Hidden 暴露、能力驱动的工具检索、Code Mode、输出预算和自动压缩共同组成闭环。

这是一份效果复盘和下一阶段设计提案。它会修正 #18 中“第一阶段不引入能力网关”的决策，但保留 #18 已经完成的生命周期门控成果。

1. #18 做了什么，哪些部分有效

#18 将原来约 31 个 OpenPI 模型可见工具收缩为：

• Pi 核心工具：read、bash、edit、write
• 7 个常驻 OpenPI 入口：fd、rg、subagent_spawn、workflow、bg_start、tasks_add、create_goal
• 其余生命周期工具只在对应 episode / resource 有效时暴露

它带来了真实改进：

1. setup 写工具不再常驻普通回合；
2. episode follow-up 的状态机更正确；
3. workflow、background、subagent、goal 等生命周期工具不再无条件出现；
4. 工具 desired state 由一处协调，减少竞态和错误隐藏。

因此，这部分不应该回滚。问题在于：我们把 7 个入口工具当成了“足够便宜的 compact core”，而 DeepSeek 实测否定了这个假设。

2. 改进后的 DeepSeek 结果为什么仍然不好

测试环境：Pi 0.84.1、seal/deepseek-v4-flash-0731-baidu、thinking off、OpenPI 9e7451c21d0d7afcc7d79080cd393e375e062a48。两轮各 4 个任务 × 2 次重复，采用 AB / BA 反转顺序，共 16 个 cell / arm。

配对结果中 Bare-only 通过 9 个，OpenPI-only 通过 2 个；精确双侧 McNemar p = 0.0654。样本仍小，不能把差异写成已经统计定论，但方向和成本效应都足够强，不能继续把它当作随机波动忽略。

路由 canary 的首请求 input tokens：

更关键的是：这些 OpenPI cell 实际只调用了 Pi 自带的 read、bash、edit、write；没有调用 OpenPI 的 subagent、workflow、background、goal 或 task 能力。也就是说，当前任务分布上出现了“成本全部兑现，能力收益为零”。

根因判断

1. 7 个入口对 DeepSeek 仍不小。 工具名、说明、参数 schema 会进入第一请求；“入口”在产品语义上紧凑，不代表在模型 payload 上便宜。
2. 入口和任务意图不匹配。 普通编码任务不需要代理、工作流、后台任务、goal 和 task；常驻只增加选择空间和干扰。
3. 错误轨迹被放大。 OpenPI arm 出现更多 bash 搜索、更多 turn 和更长上下文。一旦模型走偏，当前没有足够强的工具结果预算 / 归档机制限制动态上下文增长。
4. 动态切换只覆盖生命周期，没有覆盖能力发现。 渐进式暴露 OpenPI 工具，降低普通回合的上下文开销 #18 解决的是“能力内部什么时候有效”，没有解决“这个能力类别是否应该进入本轮模型视野”。
5. 基准仍有隔离缺陷。 个别 cell 搜索了候选目录之外的 /tmp、/private/var/folders，并看到了同批 calibration / sibling candidate 目录。这是 benchmark 问题，不是 OpenPI 产品 bug。它削弱通过率效应的正式解释，因此下一轮必须先隔离；但 OpenPI 的轨迹膨胀、额外工具调用和上下文成本仍是实测事实。

3. Maka 是怎么实现的

Maka 没有让完整产品能力直接进入 headless coding benchmark。它在 hosted-execution-tool-profile.ts 中定义版本化的 headless-coding-v1 profile：

• DeepSeek 首请求实际可见 6 个工具：ArchiveRead、Bash、Glob、Grep、Read、apply_patch
• system prompt 只有 4 行
• memory extraction、background、PTY 等在该 profile 中关闭
• 产品中的 persona、memory、goals、tasks、agents 等能力不进入这条基准路径
• 工具结果超过约 2,048 估算 token 时会归档，模型拿到可检索引用，原始事实仍保留在事件日志
• 完整产品另有 load_tools 渐进加载入口，但 headless benchmark 不带这个入口

这是一种很强的“产品面与默认执行面分离”设计。

已合并的 PR #2947 恢复并固定了这套 headless 工具面。Maka 的完整四臂同模型报告中：

• Codex 70 / 89（78.65%）
• Maka 65 / 89（73.03%）
• Codex–Maka 差异 p = 0.359，没有统计显著性
• Maka 只使用 Codex 约 61% 的 input tokens，并且 cost / pass 更低

最新但仍是 Draft、单次重复的 PR #3004 报告 Codex 73 / 89、Maka 69 / 89、Pi 66 / 89。它支持“Maka 轻量 profile 有竞争力”的方向，但 3 个任务的 Maka–Pi 差距不能视为 settled ranking。

Maka 方案的局限

1. 它是专用 benchmark profile，不等于完整产品默认体验；
2. 默认关闭大量产品能力，会提高分数，但不能直接证明用户需要的 OpenPI 编排能力也能这样关闭；
3. load_tools 会增加一次发现往返，弱模型可能根本不触发；
4. 2K 归档可能隐藏关键错误细节，需要稳定、低成本的恢复读取路径；
5. 目前报告缺少针对“工具面 / prompt / prune”的逐项消融，不能把分数差归因到单一机制。

4. Codex CLI 是怎么实现的，为什么得分高

官方说明中，Codex CLI 的基本循环是在本地仓库检查文件、修改代码和运行命令，并允许控制模型、推理强度与权限；核心 CLI 和 app-server 均在 openai/codex 开源。参见 Codex CLI 官方文档 与 开源组件说明。

最新源码中可观察到几项与 OpenPI 直接相关的设计：

4.1 每一步重建模型可见 Tool Plan

spec_plan.rs 每一步从 core、MCP、extension 和 dynamic tools 重建 registry；runtime 是否注册与 schema 是否给模型可见是两件事。

ToolExposure 明确定义：

• Direct
• Deferred
• DeferredModelOnly
• DirectModelOnly
• CodeModeOnly
• Hidden

最终只有 is_direct() 的工具进入当前模型请求。

4.2 原生支持 Deferred Tool Search，但由能力开关驱动

如果模型支持 search tool 且确实存在 deferred tools，Codex 才加入一个 tool_search。多代理工具在这种模型上也可以全部延迟，不占初始工具列表。

这不是按 provider / model 名硬编码，而是按 supports_search_tool、namespace capability、feature 和当前 step 状态决定。对没有原生 deferred placement 的 DeepSeek 路径，OpenPI 不能照抄协议能力，需要提供自己的极小 fallback gateway。

4.3 Code Mode 可以把多个工具压到一个执行入口

在 Code Mode Only 下，模型只直接看到统一执行器和 wait；嵌套工具不再各自占据 model-visible surface。它比“固定 enum 选择一个组”更可扩展，但对模型的代码生成和工具运行时要求也更高，不适合作为 OpenPI 第一阶段的唯一方案。

4.4 工具输出和对话都有预算

Codex 对 exec / MCP 等模型可见输出应用 token / byte 截断策略，并在达到上下文阈值时运行自动 compact。仓库根部 AGENTS.md 还明确要求：避免频繁改变上下文导致 cache miss、所有上下文项必须有硬上限、单项不得超过 10K token。

4.5 执行节奏更偏向短步验证

Maka 的同模型四臂遥测中：

Codex 更频繁地走小步，留出更多机会读取、执行、验证和修正。它在两次 89-task run 中都名义领先 Maka，基础设施失败为零，预算耗尽也较低。

为什么 Codex 高分：当前能说到什么程度

最合理的系统级解释是：

稳定且能力适配的工具面，配合有界上下文和更频繁的小步验证，降低了错误轨迹的尾部放大。

但这仍是源码机制 + 运行遥测形成的强推断，不是逐项消融后的因果结论。Maka 报告明确是 harness 整体比较；Codex 使用 openai-responses，Maka 使用 openai-chat，两者保留各自 native instructions、工具行为、上下文管理和执行循环。不能简单说“Codex 因为工具少，所以高分”。

5. 建议的 OpenPI 下一阶段设计

Phase 0：先修 benchmark 隔离

• 每个 cell 只允许访问自己的 candidate workspace
• calibration、reference、其他 arm / repeat 目录不可见
• hidden verifier 继续 run 后注入
• 记录 candidate root 之外的读写并直接标记 harness invalid
• 同时保留首请求 payload、工具列表与源码 hash

Phase 1：默认改成 Pi core + 一个能力网关

默认模型可见：

• Pi 自带 read、bash、edit、write
• 一个新的 openpi_capabilities

网关背后使用声明式 Capability Registry，而不是散落的 setActiveTools()：

建议网关支持 list / load，参数保持很小；模型加载后，由 registry reconcile 出权威 active-tool snapshot。能力组一旦加载，默认在当前 session 内保持稳定，避免频繁增删工具导致 cache churn；组内生命周期工具仍使用 #18 已实现的状态门控。

Phase 2：增加工具结果预算与归档

• bash、search、subagent、workflow 等输出统一应用有界策略
• 默认保留 head + tail、总字节数、原始 token 估算和归档 id
• 增加一个只读、可延迟暴露的 archive read 路径
• 事件日志保留完整原始结果，模型上下文只保留压缩表示

Phase 3：按模型能力选择暴露机制

• 支持 native deferred tools / namespace / tool search 的模型：使用 provider 能力
• 不支持的模型（当前 DeepSeek 路径）：使用 openpi_capabilities fallback
• 判断依据必须是 capability flags，不是硬编码 provider 或 model 名

Phase 4：拆成两条基准赛道

1. 默认非回归赛道：普通 coding tasks，OpenPI 不需要被使用；目标是接近 Bare Pi。
2. 编排价值赛道：任务明确受益于 subagent / workflow / background / goal；目标是自然采用并产生净收益。

只有这样才能同时回答：OpenPI 不用时是否便宜，以及需要时是否有价值。

6. 新方案会带来哪些新问题

1. 发现往返成本：首次需要 OpenPI 能力时会多一轮 gateway 调用。
2. 发现失败：弱模型可能从不调用 gateway，导致高级能力“存在但不可达”。
3. 缓存稳定性：能力组动态加入会改变 tool surface；如果频繁 unload，cache 会进一步碎片化。
4. 注册表漂移：新增工具若未分类，可能永远无法暴露；需要 fail-closed drift guard。
5. 第三方扩展边界：OpenPI registry 只能权威管理 package-owned tools，不能假定拥有全部 Pi tools。
6. 归档过度：截断可能隐藏失败根因；archive read 必须稳定且低成本。
7. provider 分叉：native deferred 和 fallback gateway 的行为可能不一致，需要同一套契约测试。
8. 过度基准优化：极小 headless profile 可能提高编码分数，却降低普通用户对 OpenPI 能力的发现；因此必须保留编排价值赛道。

7. 建议实验与验收门槛

先做 4-arm 小消融：

1. Bare Pi（4 core tools）
2. OpenPI loaded，但首请求仍只有 4 core tools
3. 4 core + openpi_capabilities
4. 当前 4 core + 7 OpenPI entry tools

阶段一：2 tasks × 2 repeats × AB / BA，只验证方向和 route health。

阶段二：隔离修复后，至少 4 tasks × 3 repeats，并报告 paired outcomes 和 bootstrap / McNemar，不只看总分。

默认非回归赛道建议门槛：

• OpenPI 首请求 input tokens ≤ Bare Pi 的 1.25×
• total tokens、turns、tool calls、wall time 各 ≤ 1.25×
• 通过率对 Bare Pi 非劣；不允许稳定出现 Bare-only 大幅领先
• 普通任务不得无理由加载 OpenPI capability group
• candidate root 之外访问 = harness invalid，不进入产品结论

编排价值赛道建议门槛：

• gateway 需要时的自然发现 / 加载成功率 ≥ 95%
• capability group 加载后工具在下一内部 turn 可用
• follow-up / episode / resource 生命周期不回归
• 与“只用 Pi core”相比，至少一个预注册主要结果（成功率、时间或人工步骤）有明确净收益

8. 决策请求

建议接受以下方向：

• 保留 渐进式暴露 OpenPI 工具，降低普通回合的上下文开销 #18 的 desired-state 与生命周期门控实现
• 推翻 渐进式暴露 OpenPI 工具，降低普通回合的上下文开销 #18 中“先保留 7 个 compact entry、不引入 gateway”的默认决策
• 先实现 benchmark isolation + 4-arm 首请求消融
• 若 4 core + gateway 达到 1.25× 门槛，再实现 Capability Registry、结果归档和两条正式赛道

这条路线比继续压缩 7 个工具的文案更可验证，也更接近 Maka 的低负载基线和 Codex 的长期架构。