最近几个月，我的信息流里“MCP 已死”这句话几乎每隔几天就要被翻出来吵一轮。就在争论最热的时候，Pi 1.0 发布了，头号卖点竟然是“原生支持 MCP”，活像故意往这个话题上浇油。我先说结论：我把 Pi 1.0 在本地完整跑了一遍，体验下来我的看法是——MCP 离死亡差得远，它正在变成那层没人在意、但人人都依赖的基础设施，就像 HTTP。这篇文章不打算争论谁对谁错，只记录我实际跑 Pi 1.0 的过程，以及为什么我认为“协议已死”这个论调被严重高估了。如果你正在做 Agent 开发、工具接入，或者纠结要不要在项目里引入 MCP，这篇应该能给你一些参考。
1. “MCP已死”的争论到底在吵什么
1.1 MCP解决的核心问题：把“接工具”这件事标准化
先给不熟悉的读者补个背景。MCP（Model Context Protocol，模型上下文协议）解决的其实是一个非常具体的问题：大模型应用怎么和外部工具、数据源打交道。在它出现之前，你要让 Agent 查数据库、读文件、调接口，基本是每种工具写一套适配代码，模型要感知每一种工具的调用习惯。MCP 做的事情，是把“应用调工具”这个动作标准化了。
打个比方：以前每个手机品牌都有自己的充电口，你出门得带好几根线。MCP 相当于 USB-C 接口——协议规定好接口长什么样，Agent 应用只要学会一套调用方式，就能连接任意实现了 MCP 的工具服务器。工具端只需要暴露出一份能力清单（tools/list），Agent 通过一次标准调用（tools/call）执行操作，结果以结构化内容返回。这套协议跑在 JSON-RPC 2.0 之上，传输层可以走本地 stdio，也可以走 HTTP。
这个定位决定了它必然会被吐槽“太简单”。但请注意，简单不是缺陷——总线层的职责就是简单，真正的复杂度应该在总线之上构建。
1.2 三个唱衰理由，哪些成立哪些不成立
我总结了一下社区里唱衰 MCP 的主流说法，大致有三类：
| 唱衰理由 | 我的观察 | 是否成立 |
|---|---|---|
| 协议层太薄，只管“应用调工具”，规划、记忆、多智能体协作一概不碰，不配叫协议 | 薄是真的，但不代表没用。HTTP 也薄，Web 照样长在上面 | 部分成立，但观点有偏 |
| 各家模型平台都在内置工具箱，开发者直接调官方接口就够了，MCP 是多余的一层 | 平台内卷恰好说明工具调用已经普及，而 MCP 的价值恰恰在于不绑定平台 | 不成立 |
| 生产环境跑起来毛刺太多：鉴权、长连接、协议版本、返回体过大，体验不如自己写 HTTP 接口 | 这是生态还没成熟的表现，不是协议本身的死刑判决 | 现阶段事实，但可改善 |
第一个理由最值得展开。MCP 确实管不了 Agent 的规划、记忆、反思，它只负责“模型想用某个工具时，怎么连过去”。但你去问任何做过 Agent 的人，都会告诉你：工具接入才是最容易拖垮项目的地方，而不是模型推理。模型一直在升级，框架一直在翻新，工具的接入方式如果也能稳定不变，反而是件大好事。MCP 要做的不是终结所有协议，而是让工具接入这一层先稳定下来。
第二个理由更有意思。“平台内置工具箱”意味着你只要换一个模型厂商，原来写好的工具适配全部作废。MCP 的价值就是把这层适配从模型端剥离出来——模型只需要会一种调用方式，工具端只需要实现一次协议，中间谁都能插进来。平台越封闭，MCP 这种开放层的价值反而越高。
第三个理由我承认，当前 MCP 生态确实有大量工程化问题。但也正因为这样，才需要 Pi 这类运行时去把它补成一个能上生产的东西。接下来聊聊我为什么关注 Pi 1.0。
2. Pi 1.0把MCP做成“一等公民”的设计逻辑
2.1 Pi到底是什么，为什么在这个节点发布
先说清楚，这个 Pi 不是那个硬件开发板，它是一个面向 Agent 编排的轻量级运行时，也是一个社区开源项目。目标很明确：让开发者用一份配置文件，把模型、工具、上下文组合成一个可调试的 Agent。1.0 之前它也有工具机制，但走的是自定义接口；1.0 版本直接内置了 MCP 客户端，可以消费任意 MCP Server。
为什么选在这个节点发布？我个人的判断是：整个行业正在从“做 Demo”转向“上生产”，大家发现工具接入的标准化已经成了硬需求。Pi 1.0 选择把 MCP 作为头号卖点，其实是在押注一个方向——工具接入必须标准化，而标准化需要一个与之配套的运行时来承载。它不打算替代 MCP，而是打算让 MCP 真正好用起来。
2.2 “原生支持”不是加个SDK：配置、注册、调用、观测的全链路内置
很多框架说支持 MCP，实际只是加了一个插件，或者包了一层官方 SDK，把连接能力塞给你。Pi 的做法完全不同，它把 MCP 当成运行时的一等公民：
- 配置层：
mcp.servers是配置文件里的顶层字段，不是藏在某个插件配置里； - 注册层：启动时自动执行
tools/list，把远程工具注册进 Agent 的工具表，不需要手写注册代码； - 调用层：模型生成函数调用意图后，Pi 直接按 MCP 协议与工具服务器通信，并把结果处理后包装回上下文；
- 可观测层：每次 MCP 调用都会产出结构化 trace 日志，方便定位问题。
这个区别有多大？我实际体验下来，最直观的感受是：之前用某个框架集 MCP，工具清单要自己拉、生命周期要自己管、错误要自己兜，MCP 只是一个被动调用的 API。在 Pi 里面，MCP Server 像本地模块一样自然，启动即注册，调用即可见。对于工具多、切换频繁的项目，这种体验差异非常大。
2.3 协议薄不是缺点：Pi在MCP之上补的三层治理
MCP 本身不管“结果太大”“参数错误”“工具慢”这些治理问题，Pi 1.0 在客户端侧补了三件事：
第一是结果预算。给每个工具的返回大小设一个阈值，超过自动截断、摘要，避免一次工具调用把上下文窗口塞满。第二是参数校验。调用前用 JSON Schema 严格校验模型生成的参数，不合格就让模型重新生成，而不是把错误直接甩给工具。第三是超时与自动重试。每个 Server 可以配独立的超时时间，慢工具不会拖垮整个 Agent 循环，失败后还能按策略自动重连。
我最欣赏的是这个设计思路：协议保持薄，治理放到运行时。MCP 不需要变成无所不包的庞然大物，它只要当好那个稳定的“接口”，剩下的工程问题由 Pi 这类工具在上层解决。这才是生态该有的分工。
3. 实操：一条MCP工具链从配置到调用的完整走读
3.1 安装与初始化
我这边环境比较干净，Python 3.11，本地跑着一个 OpenAI 兼容接口的推理网关，没有依赖任何云端厂商密钥。安装很简单：
pip install pi-runtime pi init demo-agent两个命令就完成了。有一点要注意：我之前装过 0.9 的测试版，升级到 1.0 之前最好先把旧版本卸载干净，否则命令行里会同时存在两个可执行文件，路径混在一起非常容易出问题。卸载重装之后用pi --version确认一下，我这次看到的是 v1.0.3。
初始化的目录结构大概是：
demo-agent/ ├── pi.yaml ├── agents/ │ └── default.yaml └── traces/pi.yaml是全局配置，agents/下放每个 Agent 的独立配置，traces/是运行日志目录。这个划分挺直观，一个项目多个 Agent 时不用挤在同一个文件里。
3.2 用一份配置文件同时拉起HTTP和stdio两类MCP Server
我准备了两个 MCP Server：一个是本地自建的文件系统工具，走 HTTP；一个是代码搜索工具，走 stdio。配置如下：
# pi.yaml name: demo-agent model: provider: openai-compatible # 本地网关，不用导出任何厂商密钥 base_url: http://127.0.0.1:8000/v1 model: local-model-32b mcp: servers: fs-tool: transport: streamable-http url: http://127.0.0.1:8931/mcp code-search: transport: stdio command: npx args: ["-y", "my-codesearch-mcp"] env: CSEARCH_INDEX: "./.index"这里我刻意做了混合配置：本地工具走 stdio 最省事，因为不牵扯网络和鉴权；需要共享给团队的远程服务走 HTTP，方便多端访问。Pi 1.0 可以同时管理这两种传输方式，这也是我觉得它像一个正经运行时的地方——真实项目里很少只用一种传输。
启动命令：
pi start --config pi.yaml --trace启动日志里能看到它依次做了三件事：连接模型网关、初始化 MCP 客户端、对每个 Server 执行tools/list完成注册。我那个文件服务器返回了 5 个工具，代码搜索服务器返回了 7 个，说明注册链路通了。
3.3 看一次工具调用怎么在协议层走通
我给 Agent 发了个很朴素的任务：“看看 /tmp/demo 下有哪些文件，统计 C 代码行数。” 然后打开 trace 日志，看到了一段非常清晰的结构化记录：
{ "seq": 7, "kind": "mcp_call", "server": "fs-tool", "tool": "list_directory", "input": {"path": "/tmp/demo"}, "latency_ms": 34, "return_items": 5 }接着是第二次调用：
{ "seq": 9, "kind": "mcp_call", "server": "code-search", "tool": "count_lines", "input": {"path": "/tmp/demo/test.c"}, "latency_ms": 287, "return_items": 1 }这两段日志背后发生的完整链路是：模型先生成函数调用意图，Pi 拿到意图后先做参数校验，校验通过后按 MCP 协议向对应 Server 发出tools/call请求，Server 执行完把结果返回，Pi 再做结果预算处理，最后把处理后的文本塞回上下文给模型读。整个过程模型只关心“调用什么工具、传入什么参数”，完全不关心工具是什么语言写的、部署在哪里。这就是 MCP 存在的意义。
3.4 让Agent自己编排工具调用
更有意思的是，任务本身包含两个步骤：先列目录，拿到文件名之后才能去统计行数。Agent 没有被我硬编码流程，它是自己决定“先调 list_directory，拿到 test.c，再调 count_lines”，然后自然地把两次结果汇总成一句话回答我。
在模型原生工具调用机制里，这种多步编排已经能做到；但加上 MCP 之后，这种能力变成了一种通用能力——只要工具实现了 MCP，任何支持 MCP 的模型都能自动对接，不需要为每个模型重新适配工具集。这对于一个经常换模型的项目来说，省下来的工作量是实打实的。
4. 接入MCP最容易翻车的四个环节与排查方法
4.1 tools/list正常，tools/call却一直超时
我遇到的第一个坑就很典型：状态检查时工具列表能正常拉回来，但真正发起调用就超时，整个 Agent 卡死在那里。一开始我以为是自己配置问题，后来发现根因在 Server 端——那个文件服务器把耗时的目录扫描逻辑放在同步请求处理器里，HTTP 模式下一遇到大目录就一直占着连接不返回。
这种问题光靠猜很难定位。我最后用了 Pi 自带的手工探测命令：
pi mcp probe fs-tool list_directory --input '{"path": "/tmp/demo"}'它绕开模型，直接发一次 MCP 调用，返回时间、状态码一目了然。在这里测出 1.5 秒没返回，才确认是 Server 的同步阻塞问题。最终修复是给 Server 加上异步处理，同时把 Pi 里那个 Server 的timeout配置从默认的 10 秒调到 30 秒。经验就是：工具列表能拉回来只代表注册成功，不代表调用链路健康。凡是不通了，先手工 probe 一次，把模型层和工具层切开。
4.2 模型生成的参数和工具Schema对不上
第二个坑在模型侧。有一次 Agent 调用一个搜索工具，工具返回invalid params，原因是模型生成的参数缺了必填字段。我看了下那个工具的 Schema，里面有个嵌套对象加上oneOf约束，模型没吃透，生成的参数结构完全不对。
我做了两件事：第一，在 Pi 里开启strict_schema_check，调用前先校验参数，不合格就让模型重新生成，而不是把错误直接发给工具；第二，把所有工具的参数描述写得更明确，比如在描述里加一句“path 必须是绝对路径，否则返回空”。改完之后，调用成功率立刻上来。这里有个通用规律：工具 Schema 里描述写得不清楚，模型出错率就高；描述里样例给得越具体，模型生成的参数越规范。协议本身能做的只是传递 Schema，解释清楚的责任在于 Server 开发者。
4.3 工具返回值太大，把模型上下文撑爆
这个坑最隐蔽。我做了一次全目录搜索，工具一次性返回了几十万字符的文件内容列表，模型上下文瞬间被塞满，后续回答开始前言不搭后语。MCP 协议没有规定返回值上限，Server 也没做分页，所有压力都堆到了客户端上。
Pi 里面有个结果预算机制，会给每次工具返回设置大小上限，超出的部分自动截断并附上摘要。但我还是建议在 Server 侧做分页——理想做法是给列表类工具都加上limit和offset参数，默认只返回前 100 条。我把那个文件服务器加上了limit默认值之后，整个交互明显稳定。这是协议层不背锅但实实在在要解决的问题：工具再强，返回值也得为上下文窗口着想。
4.4 协议版本和SDK版本错配
还有一个特别常见的兼容性坑：Server 端的依赖里用的是某个版本协议，Pi 客户端实现只认另一个版本，握手阶段就报UNSUPPORTED_PROTOCOL_VERSION，工具列表根本拉不回来。
Pi 1.0 声称兼容当前主流协议版本，但现实是各家 Server 的 SDK 版本差距很大。我的处理方法是：先运行pi mcp status看握手状态和协议版本号，确认是哪边的版本太老，然后把 Server 端的 SDK 锁定到指定版本。这里提醒一句：尽量不要从零散的工具包里直接升级 SDK，版本不平齐很容易出现“昨天还好好的，今天初始化失败”的诡异问题。
4.5 我的通用排查链路：先切层，再切消息
绕了这几个坑之后，我总结了一套自己的排查顺序，写在这里供参考：
- 先看 Agent 日志，判断到底断在哪一层：是拿不到工具列表、调用失败、还是结果处理失败；
- 运行
pi mcp status看每个 Server 的注册是否成功、协议版本是否对齐； - 用
pi mcp probe <server> <tool>直接发一次调用，绕开模型，单独验证工具层； - 再看 Server 端自己的 stderr 日志，确认请求有没有真正到达；
- 逐层去掉变量：先去掉鉴权头，从 HTTP 切到 stdio，再切回原配置，缩小范围；
- 问题收敛到某一层之后，把最终可用的配置固化下来，留档。
这套方法的核心是：不要拿模型当背锅侠，也不要拿协议当黑盒。每次只隔离一个变量，问题一定会现形。Agent 系统里最有价值的往往不是某个神奇模型，而是这套能让你快速定位问题的排查能力。
5. 我的结论与项目选型建议
5.1 协议会沉淀，平台会迭代
回到标题那个问题：MCP 死了吗？我的答案是：离死远得很。我说个判断——MCP 大概率不是 Agent 领域的最终答案，但它会是下一层基础设施。就像 HTTP 不是 Web 的全部，但没有 HTTP，后面的 HTML、CDN、浏览器引擎都没法谈。MCP 之上会长出编排层、记忆层、多智能体协作协议，但它们都需要一个稳定的“工具接入通道”。谁来做这个通道？目前看就是 MCP，不是某家平台的私有工具协议。
这也是为什么 Pi 敢在这个节点押注 MCP。它选的是“基础设施 + 运行时治理”的路线——协议负责标准，运行时负责把协议变成能上生产的东西。两者分工清晰，比那些试图再造一个超大协议的项目要务实得多。
5.2 什么项目适合马上接入MCP，什么可以再等等
我根据自己的实践做了一个简单对照表：
| 适合尽快上 MCP | 可以再等等的 |
|---|---|
| 工具数量多、语言异构，需要一个统一接入层 | 只有一两个固定内部接口，直接用 SDK 更轻量 |
| 需要让第三方工具即插即用，比如给 Agent 生态做扩展 | 没有精力处理鉴权、长连接等运维问题 |
| 模型端经常切换，不想被某个平台的私有工具格式绑住 | 平台自带工具调用已经够用，且不打算迁移 |
| 要搭企业内部工具市场，让各团队按 MCP 标准发布工具 | 项目规模小、后续大概率不会扩展工具种类 |
如果你正处在两者交界，我建议先找一两个非核心工具试水，跑通之后再决定要不要全面转。MCP 的边界控制做得好的话，切回去的成本也不高。
5.3 我现在的Agent分层实践
最后分享一个我自己项目里的分层方式。我现在基本按四层来做：模型层只管推理，工具层用 MCP Server 只管能力，编排层交给 Pi 这类运行时管上下文和调用循环，治理层负责结果预算、参数校验、可观测。MCP 只占据工具层的主干，其他三层都不依赖具体工具实现。
这样做的好处是：换模型、换工具、换编排框架，都只动单层，不会伤筋动骨。我自己的体会是——当我彻底把 MCP 当成那个“USB-C 接口”来用，不再指望它解决所有问题时，它反而比任何时候都稳。工具接入的标准化是刚需，而刚需不会死，只会变得越来越透明，透明到大家根本不再讨论它。
