Pi 最新版本 v0.82.1 在 README 里直接写明：核心不内置 MCP（Model Context Protocol，让 AI Agent 标准化连接外部工具和数据源的协议）。这件事发生在 MCP 被大量 Agent 框架默认采用两年后，值得我们停下来看：这不是"标准 vs 反标准"的站队，而是把工程责任从产品核心挪到了使用团队。

这是什么

MCP 的本分是让工具能被"发现、描述、调用"——AI 应用（行业叫 Host）通过 MCP Client 拿到一份工具清单，再决定怎么用。问题出在第二步：当一个 Coding Agent（能写代码并执行命令的 AI 助手）接了工单系统、数据库、监控、云平台和内部知识库后，工具从最初的 4 个变成几十个。每个工具的名字、说明、参数 Schema（结构化参数定义）和返回结构一起进入 AI 的上下文——连接是成功了，模型却不一定更好用：它在相似工具之间选错，把大量算力花在无关的 Schema 上；一次批量查询的中间结果完整回到上下文，下一轮继续重复计费。

Pi 的选择是核心保持小：少量通用工具（read、write、edit、bash），领域能力通过 CLI（命令行工具）、Skill、Extension 或 Package 按项目加载。需要 MCP 的团队可以在扩展层接入，核心不为所有用户固定一种工具生命周期、权限和 UI（界面呈现方式）。代价同样真实：每个团队可能重复实现连接、命名、超时、权限、结果裁剪和审计。

行业怎么看

支持者认为这是更诚实的工程立场。MCP 官方 Client Best Practices 已经给出两条新路径——Progressive Tool Discovery（渐进式发现：先给模型看工具目录的索引，命中候选后再加载完整 Schema）和 Programmatic Tool Calling（程序式调用：让模型生成一段代码在隔离环境里跑工具调用，只把必要结果拿回来）。这两条都说明"接入 MCP 后自然得到好体验"是个误会：协议解决互操作，Host 决定什么进上下文，治理责任从来不在协议里。

反对声音同样成立：把标准化成本从核心挪到每个团队，意味着大量中小企业和独立开发者会重复造轮子——认证、发现、缓存、审计每一项都要自己写。CLI 和私有 Extension 之间容易形成不可复用的约定，长期看是生态碎片化的隐患。Pi 的"小核心"哲学对成熟团队是减负，对资源有限的团队可能是负担。

对普通人的影响

对企业 IT：当公司想用 AI Agent 接内部系统，关键不在"接了几个 MCP"，而在"谁负责治理"。工具超过 20 个时，建议让 IT 团队介入做渐进发现和权限边界设计，而不是让业务部门直接接。

对个人职场：如果你在用 AI 写代码、做数据查询，遇到"AI 选错工具"或"回答越来越慢"，多半不是 AI 变笨了，而是上下文里堆了太多无关工具定义——这是工程问题，不是模型问题。

对消费市场：MCP 类标准的成熟意味着未来两年会出现更多"AI + 企业内部系统"的轻量产品；但用户侧感知到的差异，主要来自应用方怎么设计上下文管理，而不是协议本身。