MCP 工具面：一个懒加载代理能否降低 schema 税，而不让 OpenPI 拥有 MCP？

[tt-a1i]

一句话问题：一个 ~200 token 的懒加载 MCP 代理，能否降低 schema 税，而不让 OpenPI 拥有 MCP？

这不是 commit 计划。倾向 Discuss。本轮未安装、未运行该包。不提议新安装器，也不在 OpenPI 内自研 MCP 控制面。Pi 继续拥有 install / update / uninstall 与 MCP 配置。

为什么目录里这个机制看起来有趣

冻结身份（last-seen 2026-09-08）：

包	版本 / 日期	来源
pi-mcp-adapter	npm 2.32.1（2026-09-01）	https://www.npmjs.com/package/pi-mcp-adapter · https://github.com/nicobailon/pi-mcp-adapter

公开声明：用一个小代理代替把数百个 MCP tool schema 常驻进窗口；server 懒启动；可 import Cursor / Claude Code / Codex 的 MCP 配置。这是 渐进披露，直接打在 #300（Tool Surface Economics）上。

#169 已有 2026-09-08 源码摘录（审批 broker、owner cleanup）。本帖问产品所有权：OpenPI 是否只承认「代理缝」，还是继续完全不管 MCP。

和 OpenPI 已有能力的重叠

OpenPI 没有 MCP 层。#169 的结论是定义 Browser / Web / GitHub / Computer / Security 的外部 Provider Seam，不自研这些产品。懒加载代理是 seam 上的一种形状，不是把 MCP 收进 OpenPI。

六问（AGENTS.md）

1. 哪条 Pi seam？ MCP server / tool 生命周期属于 Pi + 用户安装的包。OpenPI 没有第二条 MCP registry。
2. 模型判断还是运行时不变量？ 「现在该不该调某个 MCP 工具」是模型判断。schema 税、懒启动、取消/清理、未分类工具 fail-closed 是运行时不变量。
3. 正交机制还是工作流？ 一个代理工具是正交的。若做成「OpenPI MCP 市场 / 安装器」就是工作流，且与 setup: 移除 OpenPI 对 pi-intercom 的主动安装与配置职责 #128 / 社区包风险收据：只读评估应由独立插件、Skill 还是 OpenPI 承担？ #475 冲突。
4. 更强模型会不会直接用 Pi 原语？ 更强模型仍受 schema/cache 税伤害（Tool Surface Economics：稳定全量前缀还是渐进式能力加载？ #300）。代理的价值不依赖「模型变笨」，这是少数可能随模型变强仍成立的理由——但必须用证据说话。
5. 成功 / 失败证据？ 成功：server 未启动时窗口里只有代理；调用后工具结果有界。失败：启动失败、重名、审批拒绝、取消后迟到结果，都必须是明确失败，不能把「没启动」显示成「没有这个工具所以任务完成」。
6. 权限如何停和清？ 代理及其展开工具必须做 child 分类（CHILD_EXCLUDED_TOOL_NAMES / CHILD_SAFE_PACKAGE_TOOL_NAMES）。高特权 MCP 默认进不了 child。停 = 取消 in-flight + 不留 stale UI。不在 /openpi-setup 之外再开 MCP 配置命令。

结论倾向

Discuss，不是 Adopt，更不是 in-house MCP。 若要试点，只验证「代理降低 schema 税」这一条，配置仍走 Pi。OS sandbox 见相邻讨论；本帖不讨论隔离。

关联：#169、#300、#312、#299、#314、#475（风险收据 ≠ 安装器）、权限试点 #497。研究记录：docs/research/PI_COMMUNITY_PLUGIN_SURVEY_2026-09-08.md。

[tt-a1i]

2026-09-09 源码实验（未安装、未运行）。结论仍是 Discuss，不 Adopt，不自研 MCP。OpenPI 可以学代理形状，但不能成为 MCP broker。

冻结：pi-mcp-adapter HEAD 8243eba；npm 2.32.1 gitHead 10a4536（peer 仍只声明 pi-ai ^0.84.1，与 HEAD 的 ^0.85.0 不要混用）。对照 stale irahardianto/pi-mcp-extension@8a01fc5（1.5.0，连上就把每个 tool 注册成顶层 Pi tool）。Pi 0.85.1 6160683 仍写 No MCP。OpenPI 对照本仓 a9b40f0，child 投影另读了 #169 用过的 ed9dbc1。

源码比 README「~200 token 一个代理」更大：默认至少 mcp + mcpScript；buildProxyDescription 空配置约 1209 字符且会写入 server 名；无 mcp-cache.json 时第一次会 bootstrap 全部 server；mcp__<server> namespace proxy 为 tool-groups 提前注册。审批 broker / owner cleanup / addedToolNames 仍是 #169 该消费的缝，不是收编理由。

Child：adapter 没有 child 分支；CHILD_* 只分类本包工具。ed9dbc1 的 inheritedChildToolAllowlist 按顶层工具名投影父 active 面，一个 mcp 仍可读写。未分类第三方进 child 是缝，不是「OpenPI 实现 MCP」。

Import：hostConfigDiscovery 默认 off；adopt/init 只往 Pi 自己的 mcp.json 写 imports，不改 Cursor/CC/Codex 文件、不拷贝 secret。init 非 dry-run 会立刻写全局 Pi 文件。OpenPI 不要做第二条 import UI。

六问摘要：生命周期在用户包 + Pi install；模型判断 vs 运行时不变量不要混；正交机制已经存在（用户安装 adapter）；schema 税不随模型变强消失，但收据还没有；失败必须是明确失败；权威/停止/清理不能靠 /openpi-setup。

完整记录（本地 draft，未 commit）：docs/research/EXPERIMENT_MCP_ADAPTER_2026-09-09.md。