Pi 为什么不内置 MCP工具发现与上下文成本的真实争议一个 Coding Agent 原来只有read、write、edit、bash四个通用工具。团队接入工单、数据库、监控、云平台和内部知识库后工具很快增加到几十个。最直接的做法是把每个 MCPServer 暴露的工具定义都交给模型名字、描述、参数 Schema、返回结构一次性进入上下文。连接成功了模型却不一定更好用。它可能在相似工具之间选错把大量输入预算花在与当前任务无关的 Schema 上一次批量查询的中间结果又完整回到上下文下一轮继续重复计费。另一种做法是只给模型 Bash让它通过 CLI 完成所有操作。工具列表变短了但帮助文档、参数发现、文本解析、认证、错误语义和权限审计并没有消失只是换了位置。这就是 Pi “不在核心内置 MCP”最值得讨论的地方。它不是“标准协议与反标准协议”的站队而是一个 Harness 应该回答的四个工程问题工具目录什么时候出现 完整 Schema 什么时候进入模型上下文 中间结果由模型处理还是由受控执行环境处理 发现、权限、凭证、缓存和审计最终由谁治理本文的核心结论是MCP 统一了连接、发现和结构化调用但不会自动替 Host 决定上下文与治理策略Pi 选择小核心也不会自动消除 CLI 的隐性成本。真正可靠的方案是根据工具规模、复用范围和风险把 CLI、Skill、Extension、MCP 或混合架构放到正确的责任层。一、先把“协议”和“宿主策略”分开MCP 的基础结构包含 Host、Client 和 Server。Server 暴露 Tools、Resources 或 PromptsClient维护与某个 Server 的连接Host 负责把这些能力组织进用户实际使用的 Agent 或应用。当前2026-07-28工具规范明确了几个关键动作tools/list 发现当前可用工具 tools/call 调用指定工具 notifications/tools/list_changed 工具列表变化通知这套协议回答的是能力怎样被描述、发现和调用。它并没有要求 Host 必须在会话开始时把每个工具的完整定义全部塞进模型也没有规定模型必须直接逐次调用。规范甚至明确允许实现采用适合自己的交互方式。因此下面两句话不能画等号Client 已通过 tools/list 取得工具目录 ≠ 模型上下文已经加载全部工具 Schema工具目录可以只存在于 Host 的 Registry、索引或缓存中。模型先看到少量分类和检索入口命中候选后再加载详情也可以只面对一个稳定的call_toolBroker由 Host 在模型外路由。协议提供互操作基础Host 决定什么进入上下文。二、Pi 的 No MCP 是核心边界不是能力禁令Piv0.82.1的 README 已经写明核心不内置 MCP可以为常用能力构建带 README 的 CLI也可以通过 Extension 增加 MCP 支持。到 2026-08-12 检查当前main这个产品立场仍然存在。当前文档同时把 MCP Server Integration 列入 Extension 可实现能力。这意味着“Pi 没有 MCP”需要准确改写为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获取能力却不立即把全部定义注入模型而是分成三层Catalog搜索名字、分类和一句话描述 Inspect只加载候选工具的完整 Schema Execute确认后调用需要的工具官方文档还建议在工具定义占上下文达到一定比例时切换渐进发现并考虑关键词、Embedding、小模型或混合检索。这里的阈值和检索器都属于 Host 策略不是 Server 自动替你完成。第二个是 Programmatic Tool Calling也称 Code Mode。模型不再逐次搬运每个中间结果而是生成一段调用工具的程序程序在 Sandbox 中运行通过 Host Broker 调用 MCP Server过滤、聚合或去重后只把必要结果返回模型。它能同时减少工具往返和中间结果占用却也引入新责任Sandbox 不能直接持有凭证或开放任意网络Broker 必须对每次实际调用继续做授权跨 Server 的数据流要防止被无意转发执行时间、内存和最终输出都要限制。因此更新后的判断应当是“所有 MCP 工具都必须常驻上下文”已经不是成立的协议结论 “接入 MCP 后自然得到渐进发现和 Code Mode”同样不成立。前者忽略了当前 Host 模式后者把实现责任误记到了协议名下。四、Token 只是显性成本真正要算的是五本账工具接入方案不能只比较 Schema Token。至少要同时核算五类成本。1. 发现成本模型怎样知道某个能力存在CLI 可能依赖命令名、README、--help与 SkillMCP 可以从tools/list取得结构化目录但大目录仍需要搜索、排序、命名规范和去重。同义工具、过时工具和权限不可用工具若都进入候选发现质量依然会下降。2. 上下文成本完整 Schema 是否常驻说明文档是否重复注入工具列表动态变化会不会打断 Provider 的 PromptCache当前 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 RuntimeExtension 可以注册自定义 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。标准化降低的是接口碎片不是所有产品与治理复杂度。六、不要四选一更实用的是分层组合实际系统常见的合理组合是Skill 说明何时需要某类能力与操作边界 ↓ Extension / Host Broker 负责目录、检索、授权、凭证、缓存和观察性 ↓ CLI 或 MCP Client 执行本地命令或连接标准化 Server ↓ 外部系统 Git、数据库、工单、监控、云平台、知识库本地 Git 操作可以继续用 CLI跨团队工单和数据库能力可以走 MCP高风险写操作统一经过Extension 的策略层Skill 只在任务相关时加载操作说明。这样既不要求所有能力迁入 MCP也不让每个 CLI 都以裸 Bash 的方式暴露给模型。对 Pi 而言一个可控的 MCP Adapter 可以分成五个模块Registry 保存 Server 身份、能力摘要和健康状态 Discovery 搜索工具只按需加载详情 Policy 根据用户、项目、Tool 和参数判断授权 Broker 持有凭证执行调用、超时、重试与取消 Result 分页、裁剪、结构校验和敏感信息过滤模型只面对任务需要的最小接口。Server 的凭证不进入生成代码Code Mode 的脚本也只能通过Broker 暴露的函数访问外部系统。工具列表变化先更新 Host 索引再决定是否以及如何更新模型可见定义避免为了“动态”反复破坏缓存。这套分层是作者建议不是 Pi 当前内置实现也不是 MCP 规范强制架构。七、用六维决策矩阵选接入方式维度CLI SkillPi ExtensionMCP混合路线能力发现文档与命令约定适合少量稳定工具可自建目录与 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 留在扩展层MCP2026-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.1https://github.com/earendil-works/pi/blob/v0.82.1/packages/coding-agent/README.mdPi Coding Agent README当前main检查于 2026-08-12https://github.com/earendil-works/pi/blob/main/packages/coding-agent/README.mdMCP Architecture版本2026-07-28https://modelcontextprotocol.io/docs/2026-07-28/learn/architectureMCP Tools Specification版本2026-07-28https://modelcontextprotocol.io/specification/2026-07-28/server/toolsMCP Client Best Practices版本2026-07-28https://modelcontextprotocol.io/docs/2026-07-28/develop/clients/client-best-practices