最近几个月我的信息流里“MCP 已死”这句话几乎每隔几天就要被翻出来吵一轮。就在争论最热的时候Pi 1.0 发布了头号卖点竟然是“原生支持 MCP”活像故意往这个话题上浇油。我先说结论我把 Pi 1.0 在本地完整跑了一遍体验下来我的看法是——MCP 离死亡差得远它正在变成那层没人在意、但人人都依赖的基础设施就像 HTTP。这篇文章不打算争论谁对谁错只记录我实际跑 Pi 1.0 的过程以及为什么我认为“协议已死”这个论调被严重高估了。如果你正在做 Agent 开发、工具接入或者纠结要不要在项目里引入 MCP这篇应该能给你一些参考。1. “MCP已死”的争论到底在吵什么1.1 MCP解决的核心问题把“接工具”这件事标准化先给不熟悉的读者补个背景。MCPModel Context Protocol模型上下文协议解决的其实是一个非常具体的问题大模型应用怎么和外部工具、数据源打交道。在它出现之前你要让 Agent 查数据库、读文件、调接口基本是每种工具写一套适配代码模型要感知每一种工具的调用习惯。MCP 做的事情是把“应用调工具”这个动作标准化了。打个比方以前每个手机品牌都有自己的充电口你出门得带好几根线。MCP 相当于 USB-C 接口——协议规定好接口长什么样Agent 应用只要学会一套调用方式就能连接任意实现了 MCP 的工具服务器。工具端只需要暴露出一份能力清单tools/listAgent 通过一次标准调用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 接口”来用不再指望它解决所有问题时它反而比任何时候都稳。工具接入的标准化是刚需而刚需不会死只会变得越来越透明透明到大家根本不再讨论它。