Pi Agent 为什么不内置 MCP：工具发现与上下文成本的真实争议

Pi 为什么不内置 MCP：工具发现与上下文成本的真实争议

一个 Coding Agent 原来只有 read、write、edit、bash 四个通用工具。团队接入工单、数据库、监控、云平台和内部知识库后，工具很快增加到几十个。最直接的做法，是把每个 MCP Server 暴露的工具定义都交给模型：名字、描述、参数 Schema、返回结构一次性进入上下文。

连接成功了，模型却不一定更好用。它可能在相似工具之间选错，把大量输入预算花在与当前任务无关的 Schema 上；一次批量查询的中间结果又完整回到上下文，下一轮继续重复计费。另一种做法是只给模型 Bash，让它通过 CLI 完成所有操作。工具列表变短了，但帮助文档、参数发现、文本解析、认证、错误语义和权限审计并没有消失，只是换了位置。

这就是 Pi "不在核心内置 MCP"最值得讨论的地方。它不是"标准协议与反标准协议"的站队，而是一个 Harness 应该回答的四个工程问题：

text 复制代码

工具目录什么时候出现？
完整 Schema 什么时候进入模型上下文？
中间结果由模型处理，还是由受控执行环境处理？
发现、权限、凭证、缓存和审计最终由谁治理？

本文的核心结论是：MCP 统一了连接、发现和结构化调用，但不会自动替 Host 决定上下文与治理策略；Pi 选择小核心，也不会自动消除 CLI 的隐性成本。真正可靠的方案，是根据工具规模、复用范围和风险，把 CLI、Skill、Extension、MCP 或混合架构放到正确的责任层。

一、先把"协议"和"宿主策略"分开

MCP 的基础结构包含 Host、Client 和 Server。Server 暴露 Tools、Resources 或 Prompts；Client 维护与某个 Server 的连接；Host 负责把这些能力组织进用户实际使用的 Agent 或应用。

当前 2026-07-28 工具规范明确了几个关键动作：

text 复制代码

tools/list                         发现当前可用工具
tools/call                         调用指定工具
notifications/tools/list_changed   工具列表变化通知

这套协议回答的是：能力怎样被描述、发现和调用。它并没有要求 Host 必须在会话开始时把每个工具的完整定义全部塞进模型，也没有规定模型必须直接逐次调用。规范甚至明确允许实现采用适合自己的交互方式。

因此下面两句话不能画等号：

text 复制代码

Client 已通过 tools/list 取得工具目录
≠
模型上下文已经加载全部工具 Schema

工具目录可以只存在于 Host 的 Registry、索引或缓存中。模型先看到少量分类和检索入口，命中候选后再加载详情；也可以只面对一个稳定的 call_tool Broker，由 Host 在模型外路由。协议提供互操作基础，Host 决定什么进入上下文。

二、Pi 的 No MCP 是核心边界，不是能力禁令

Pi v0.82.1 的 README 已经写明：核心不内置 MCP，可以为常用能力构建带 README 的 CLI，也可以通过 Extension 增加 MCP 支持。到 2026-08-12 检查当前 main，这个产品立场仍然存在。当前文档同时把 MCP Server Integration 列入 Extension 可实现能力。

这意味着"Pi 没有 MCP"需要准确改写为：

text 复制代码

Pi 核心不为所有用户固定一种 MCP 生命周期、发现、权限和 UI 实现；
需要 MCP 的团队可以在 Extension 或 Package 层接入。

它没有否认 MCP 的互操作价值，也没有阻止开发者注册自定义工具。Pi 的设计偏好是把默认能力保持得很小：少量通用工具可以通过文件系统与 Shell 组合外部程序，领域能力按项目用 Skill、 Prompt、Extension 或 Package 加载。

这种选择的收益是可解释：核心无需承担每种传输、认证、Server 生命周期和工具 UI；不使用 MCP 的用户也不支付相应复杂度。代价同样真实：每个团队可能重复实现连接、命名、超时、重试、权限、结果裁剪和观察性；CLI 与自定义 Extension 之间也容易形成私有约定，跨客户端复用较弱。

所以 Pi 的选择不是免费午餐，而是把标准化成本从核心移到扩展作者和使用团队。

三、历史上的上下文批评，今天应该怎样更新

早期或朴素的 MCP Host 常把所有已连接 Server 的工具定义一次性发送给模型。工具少时，这很合理；工具增长到数百个时，完整描述与 JSON Schema 会占用大量上下文，并干扰模型选择。每次直接工具调用又是一次"模型生成调用---Host 执行---完整结果返回模型"的往返，中间结果可能比最终结论大几个数量级。

这个批评曾经击中了真实实现，但不能被写成 MCP 永久限制。当前官方 Client Best Practices 已明确提出两个模式。

第一个是 Progressive Tool Discovery。Host 仍然通过 tools/list 获取能力，却不立即把全部定义注入模型，而是分成三层：

text 复制代码

Catalog：搜索名字、分类和一句话描述
Inspect：只加载候选工具的完整 Schema
Execute：确认后调用需要的工具

官方文档还建议在工具定义占上下文达到一定比例时切换渐进发现，并考虑关键词、Embedding、小模型或混合检索。这里的阈值和检索器都属于 Host 策略，不是 Server 自动替你完成。

第二个是 Programmatic Tool Calling，也称 Code Mode。模型不再逐次搬运每个中间结果，而是生成一段调用工具的程序；程序在 Sandbox 中运行，通过 Host Broker 调用 MCP Server，过滤、聚合或去重后，只把必要结果返回模型。

它能同时减少工具往返和中间结果占用，却也引入新责任：Sandbox 不能直接持有凭证或开放任意网络；Broker 必须对每次实际调用继续做授权；跨 Server 的数据流要防止被无意转发；执行时间、内存和最终输出都要限制。

因此更新后的判断应当是：

text 复制代码

"所有 MCP 工具都必须常驻上下文"已经不是成立的协议结论；
"接入 MCP 后自然得到渐进发现和 Code Mode"同样不成立。

前者忽略了当前 Host 模式，后者把实现责任误记到了协议名下。

四、Token 只是显性成本，真正要算的是五本账

工具接入方案不能只比较 Schema Token。至少要同时核算五类成本。

1. 发现成本

模型怎样知道某个能力存在？CLI 可能依赖命令名、README、--help 与 Skill；MCP 可以从 tools/list 取得结构化目录，但大目录仍需要搜索、排序、命名规范和去重。同义工具、过时工具和权限不可用工具若都进入候选，发现质量依然会下降。

2. 上下文成本

完整 Schema 是否常驻？说明文档是否重复注入？工具列表动态变化会不会打断 Provider 的 Prompt Cache？当前 MCP 客户端文档特别提醒：会话中增删工具定义可能导致缓存失效，有时损失比节省的 Schema 更多。动态加载需要和缓存边界一起设计。

3. 结果成本

数据库返回一万行、日志查询返回数万条、对象存储列举全部 Key，都不应该原样经过模型。CLI 可以用管道、jq 或脚本本地过滤；MCP 直调可以要求 Server 返回分页或聚合；Code Mode 可以在 Sandbox 处理。关键不是接口形式，而是"中间数据是否必须经过模型"。

4. 治理成本

谁保存 Token？谁决定可调用哪些 Server、Tool 和参数范围？谁处理用户确认、租户隔离和审计？ MCP 提供标准化接口和授权基础，不等于业务权限自动正确；CLI 继承本机凭证也不等于权限更简单。凭证位置、最小权限与逐调用策略都应落在模型之外。

5. 运维成本

Server 如何启动、升级、健康检查、超时、重连和回滚？CLI 版本怎样固定？Extension 与 Server 的协议漂移如何发现？跨团队复用越多，标准化收益越大；只有一个本地脚本时，为它建立完整远程 Server、OAuth 和 Registry 可能反而过重。

这五本账解释了为什么"更少 Token"不能单独决定技术路线。

五、CLI、Skill、Extension 和 MCP 各自解决什么

CLI：适合本地、稳定、可组合的执行能力

CLI 最大的优势是现成。Git、数据库客户端、云 CLI 和内部脚本已经有成熟的参数、退出码与日志， Pi 的 Bash 可以直接组合它们。敏感的大结果还能先在本地过滤，再把摘要交给模型。

它的短板是机器可读契约不统一。帮助文本未必稳定，JSON 输出并非总有，交互式认证、环境变量和工作目录都会影响行为。只有"命令能运行"还不够，团队仍要规定版本、结构化输出、错误码、超时、幂等和凭证范围。

Skill：适合按需加载操作知识

Skill 适合告诉模型"什么时候用哪个 CLI、先检查什么、怎样解释失败"。它可以把领域流程按需加载，而不是让所有说明常驻系统提示词。

但 Skill 是指导层，不是强制执行层。它不能单独提供权限隔离、可靠参数校验、超时或审计。若动作具有副作用，真正的 Gate 仍应在 Extension、Broker、CLI 或外部系统中。

Extension：适合把环境策略落进 Pi Runtime

Extension 可以注册自定义 Tool、监听调用事件、提供 UI，并把企业内部的授权、日志、结果裁剪或连接生命周期接入 Pi。它也是在 Pi 中实现 MCP Client/Adapter 的自然位置。

代价是实现与维护责任归团队所有。Extension 执行代码，必须处理版本兼容、异常隔离、资源释放和供应链风险。本文提出的 Adapter 只是架构设计，没有运行第三方实现，证据状态保持 NOT_RUN_PI_MCP_ADAPTER。

MCP：适合跨客户端、跨语言和远程复用

当一个能力要同时服务多个 Agent、IDE 或业务应用，需要结构化发现、统一 Schema、远程连接、授权或独立发布生命周期时，MCP 的标准化价值会迅速上升。Server 可以独立演进，Host 不必为每个外部系统重新发明连接协议。

但 MCP 不替业务做选择。工具命名糟糕、Schema 过大、返回结果失控、权限过宽或 Server 不稳定，仍会伤害 Agent。标准化降低的是接口碎片，不是所有产品与治理复杂度。

六、不要四选一：更实用的是分层组合

实际系统常见的合理组合是：

text 复制代码

Skill
  说明何时需要某类能力与操作边界
     ↓
Extension / Host Broker
  负责目录、检索、授权、凭证、缓存和观察性
     ↓
CLI 或 MCP Client
  执行本地命令，或连接标准化 Server
     ↓
外部系统
  Git、数据库、工单、监控、云平台、知识库

本地 Git 操作可以继续用 CLI；跨团队工单和数据库能力可以走 MCP；高风险写操作统一经过 Extension 的策略层；Skill 只在任务相关时加载操作说明。这样既不要求所有能力迁入 MCP，也不让每个 CLI 都以裸 Bash 的方式暴露给模型。

对 Pi 而言，一个可控的 MCP Adapter 可以分成五个模块：

text 复制代码

Registry    保存 Server 身份、能力摘要和健康状态
Discovery   搜索工具，只按需加载详情
Policy      根据用户、项目、Tool 和参数判断授权
Broker      持有凭证，执行调用、超时、重试与取消
Result      分页、裁剪、结构校验和敏感信息过滤

模型只面对任务需要的最小接口。Server 的凭证不进入生成代码；Code Mode 的脚本也只能通过 Broker 暴露的函数访问外部系统。工具列表变化先更新 Host 索引，再决定是否以及如何更新模型可见定义，避免为了"动态"反复破坏缓存。

这套分层是作者建议，不是 Pi 当前内置实现，也不是 MCP 规范强制架构。

七、用六维决策矩阵选接入方式

维度	CLI + Skill	Pi Extension	MCP	混合路线
能力发现	文档与命令约定，适合少量稳定工具	可自建目录与 UI	标准 `tools/list`，大目录仍需检索	MCP 供目录，Extension 做按需发现
上下文	Skill 按需加载，但帮助文本需治理	可控制注入与裁剪	取决于 Host，不必全量注入	统一在 Host 控制 Schema 预算
执行与结果	管道和脚本灵活，输出契约不一	可强制校验、超时和结果过滤	结构化调用，Server 质量决定结果	本地 CLI 与远程 MCP 共用 Broker
权限与凭证	常继承本机环境，易过宽	可接项目策略和确认 UI	支持标准授权，但业务权限仍自建	凭证统一由 Host/Broker 持有
跨端复用	较弱，依赖 OS 与安装环境	主要复用在 Pi 生态	强，适合多 Host、远程和多语言	高频共享能力用 MCP，本地能力留 CLI
运维复杂度	低起点，规模增大后约定膨胀	团队维护 Runtime 适配	Server、连接、认证与版本均需运营	按能力价值分层承担复杂度

可以用四个场景快速判断：

三个以内、本地稳定、已有成熟 CLI：先用 CLI + Skill，补结构化输出和失败合同。
需要 Pi 内部 UI、审批、状态或结果裁剪：增加 Extension，不必因此改造成 MCP。
同一能力要跨多个 Agent/IDE 复用或远程托管：优先评估 MCP，并设计渐进发现。
工具多、结果大、调用链长：无论底层是 CLI 还是 MCP，都需要 Host 级目录、Broker 和受控执行；必要时再引入 Code Mode。

八、从最小实现逐级升级，而不是一次造完平台

第一阶段，先测量真实问题。记录工具定义占上下文比例、工具选择错误、平均结果大小、调用轮数、 Prompt Cache 命中和 P95 延迟。没有这些基线，不要仅凭文档示意数字宣称节省了多少。

第二阶段，治理已有 CLI。固定版本，优先 JSON 输出，统一超时与错误码，把危险写操作放到窄接口，由 Skill 说明使用条件。这一步常能解决小规模团队的大部分问题。

第三阶段，在 Pi Extension 中建立最小 Broker。先做 Tool Allowlist、参数校验、凭证隔离、结果上限和审计，再增加目录检索。只有需要的工具定义进入模型。

第四阶段，把真正需要跨客户端复用的能力封装为 MCP Server。保留本地低成本 CLI，不做为统一而统一的迁移。用 tools/list 建目录，并对 list_changed、缓存和不可用 Server 制定明确策略。

第五阶段，只有批量中间结果已经成为主要成本时，再评估 Code Mode。运行模型生成代码的 Sandbox 必须无直接凭证、无任意网络，并由 Host Broker 对每个外部调用继续授权。脚本成功不代表所有副作用可以跳过审计。

每一级都应设置退出条件：如果工具选择、上下文、延迟和运维没有明显改善，就保留较简单方案。

九、最终应该验收什么

一套工具接入架构是否合格，可以不用争论协议偏好，直接检查下面六项：

验收对象	必须回答的问题	最低证据
目录	模型怎样找到能力，过时和无权工具怎样排除	真实目录、检索结果与失败样本
Schema	哪些定义何时进入上下文，是否影响缓存	上下文与 Cache 指标
执行	超时、重试、取消、幂等和部分成功怎样处理	真实调用 Trace 与故障注入
结果	大结果在哪里过滤，敏感字段怎样阻断	字节/Token 上限与泄漏测试
权限	凭证在哪里，谁批准什么范围	身份、Scope、授权与审计记录
运维	Server/CLI 版本漂移和故障怎样恢复	版本锁、健康检查和回滚演练

本文能够确认的是：Pi 固定版本与当前 README 都把 MCP 留在扩展层；MCP 2026-07-28 工具规范支持结构化发现与调用；当前官方客户端文档已经提出渐进发现和 Programmatic Tool Calling，明确把 Schema 注入与中间结果处理视为 Host 需要优化的问题。

本文不能确认的是：某个 Pi MCP Extension 已经在目标环境稳定运行，某套工具目录一定节省多少 Token，或 Code Mode 在真实业务权限下已经安全。它们仍是 NOT_RUN_PI_MCP_ADAPTER 和 UNKNOWN_REAL_COST，必须用目标工具集、真实身份和故障场景验证。

Pi 不内置 MCP，不等于 MCP 没有价值；MCP 变得更成熟，也不意味着每个工具都应该改造成 Server。把争论从协议名称移回目录、上下文、结果、权限、复用和运维，团队才能选到真正便宜、清楚且可控的接入方式。

参考资料

Pi Coding Agent README，固定 v0.82.1：github.com/earendil-wo...
Pi Coding Agent README，当前 main，检查于 2026-08-12：github.com/earendil-wo...
MCP Architecture，版本 2026-07-28：modelcontextprotocol.io/docs/2026-0...
MCP Tools Specification，版本 2026-07-28：modelcontextprotocol.io/specificati...
MCP Client Best Practices，版本 2026-07-28：modelcontextprotocol.io/docs/2026-0...