今天群里有人甩了个标题Pi 为什么突然支持 MCP 了底下立马吵成两派。一派说 MCP 这次是真的赢了以后 AI 编程代理想接什么工具都行另一派说别高兴太早CLI 才是永远的神。我看了半天觉得两边其实都没说准——Pi 支持 MCP 这件事既不是什么平地惊雷也不意味着 MCP 取代了 CLI。它更像是一个信号编程代理从“只能调用内置工具”的阶段正式迈进了“外围生态决定上限”的阶段。这篇文章我想聊聊为什么说“突然”只是错觉以及为什么在这个时间点上MCP 和 CLI 其实是互相成就的关系。如果你把 Pi 理解成一个跑在终端或桌面上的 AI 编程代理类似 Codex CLI、Claude Code 那类产品那这次支持 MCP 的意义就很清楚了——它让 AI 不再只能靠内置的搜索、读文件、改文件这几板斧而是可以把外部世界的一整排工具箱直接递到模型手里。而且有意思的是MCP 接得越多我越发现它跟 CLI 根本不是一个维度的东西。这篇文章适合正在折腾 AI 编程代理、犹豫要不要上 MCP、以及被“MCP 和 CLI 到底啥关系”这类问题困扰的人。我会从协议本身讲起结合实测里的坑最后给出我自己的一套选型判断。1. “突然”只是错觉Pi 支持 MCP 的时机恰好是协议标准化的临界点先说结论Pi 不是突然开窍而是它等到了一个生态临界点。2024 年底 MCP 协议开源之后整个工具链生态经历了一轮野蛮生长。到今天你去看热搜词光是 MCP 相关的就有数据库、浏览器、设计稿、逆向工程、游戏引擎、行情软件——IDA MCP、x64dbg MCP 插件、Unreal Engine 5.8 MCP、同花顺 MCP甚至连 IDEA 插件里的通义灵码都有人在做连接 Oracle 数据库的 MCP。当一个协议的工具覆盖密度达到这个程度客户端这边再不接入就显得格格不入。Pi 选择在这个时间点跟进本质上不是技术冲动而是生态倒逼。1.1 没有 MCP 的日子AI 编程工具接外部能力到底有多痛在 MCP 出现之前你要让一个 AI 编程代理去操作外部系统基本只有三条路。第一条路是让 AI 直接生成一段临时脚本去调 API。比如你想让它查一下 PostgreSQL 里某个表的结构它得先猜数据库连接串、猜库名、猜表名然后用 psycopg2 或者直接拼 SQL 去连。一套操作下来能不能成完全看运气而且每一次新任务都要重新猜一遍。第二条路是给 AI 写一堆私有工具函数每个工具配一个 JSON Schema 描述。今天接 GitLab 写一个工具集明天接 Figma 再写一个工具集后天接数据库又得写一套。每接一个系统都要重新实现一遍“参数校验、调用执行、结果格式化”这三板斧。而且不同客户端之间的工具定义完全不互通——你给 A 产品写的适配层换到 B 产品直接作废。第三条路最原始也是我之前最常用的——把 CLI 的输出复制粘贴给 AI。终端里跑一条命令把 stdout 粘进对话上下文让模型看着输出继续干活。这条路能用但极其依赖人的操作而且一旦输出量大了比如几千行的日志上下文直接爆炸。MCP 解决的就是这三条路的共同痛点把“工具如何使用”这件事标准化。它定义了一套基于 JSON-RPC 2.0 的通信协议让任何 MCP 服务器都能用统一的方式暴露工具给 AI 客户端。你不需要知道对面是 PostgreSQL 还是 Figma只要对方实现了 MCP 协议AI 就能通过同一套机制调用它的能力。1.2 为什么“大家”都在同一时间点接入标准协议的时间窗口技术圈有个规律任何工具类协议都会经历一个“时间窗口”。最开始是几家大厂各搞各的私有协议互相不兼容等到有一个开放协议被足够多的头部玩家认可市场就会快速收敛到这个协议上后面的产品如果不跟进就会显得很另类。MCP 现在正处于这个收敛窗口期。Anthropic 开源协议之后OpenAI 的 Codex CLI 在迭代中加入了 MCP 支持各种桌面端、IDE 插件的 AI 助手也在陆陆续续跟进。Pi 作为面向开发者的 coding agent不可能无视这个趋势。但为什么现在才“突然”支持因为窗口期的意思是协议本身已经稳定到可以落地同时生态里的服务器数量已经多到值得客户端去支持。太早接入你会发现自己成了协议的白老鼠天天跟着上游改接口太晚接入又会被骂跟不上时代。Pi 选的这个点恰好是“能用的服务器足够多、协议破坏性变更足够少”的平衡点。这个时机判断给我一个很深的感受技术选型有时候拼的不是谁技术领先而是谁踩准了生态节奏。MCP 本身不是什么惊为天人的协议它就是把工具描述和调用标准化了而已。但当一个生态系统里所有的工具都开始按这个标准暴露自己时你再不接入你的 AI 就比别人的 AI 少了一只手。2. 接入之后Pi 的工作方式发生了什么实质变化很多人的疑问是Pi 支持 MCP 之前不也挺能打吗能读代码、能改文件、能跑命令接不接 MCP 到底差在哪差在“工具的粒度”和“AI 的自主性”。之前 Pi 能调用的工具是固定的那几样每样都是通用能力接上 MCP 之后工具的粒度可以小到一个具体的业务动作比如“查询这个订单的物流状态”“读取 Figma 上这个设计稿的标注”“拿到这个数据库里 users 表的索引列表”。AI 不再需要自己拆解任务、写一堆中间代码去模拟这些动作而是直接调用一个语义明确的工具一步到位。2.1 MCP 的核心Tool、Resource、Prompt 三类原语理解 MCP 接入后的变化先得搞清楚 MCP 协议提供了什么。它有三类核心原语Tools工具可被模型调用的函数式能力。模型根据工具的名字和描述决定要不要调用、传什么参数。Resources资源可被模型读取的数据类似文件内容、数据库查询结果、某个接口返回的 JSON。跟 Tools 的区别在于Resources 更多是“读上下文”而不是“执行动作”。Prompts提示预先写好的提示词模板用户或模型可以按模板快速组织任务相当于把一些高频操作流程固化下来。拿一个文件系统 MCP 服务器举例它的工具定义大概是这个画风社区常见实现差不多都这样{ name: read_file, description: 读取指定路径的文件内容适合阅读代码、配置、文档等文本文件, inputSchema: { type: object, properties: { path: { type: string, description: 文件的绝对路径 } }, required: [path] } }就这么一个 JSON 片段AI 客户端一看就知道哦有个叫read_file的工具作用是读文件需要一个 path 参数。然后它就把这个工具加入自己的可选能力池。实际调用时客户端通过标准化的消息把参数发给 MCP 服务器服务器执行完把结果返回。这跟以前最大的区别是什么是描述标准化。以前你给 AI 塞一个自定义工具它只能看到你的 JSON 描述不知道这个工具背后是怎么实现的现在一切 MCP 服务器的工具都按同一种 schema 语言描述AI 客户端的解析逻辑完全统一接入新工具的成本从“写一坨适配代码”降到“加一行配置”。2.2 从“人在回路”到“子代理并行”Pi Subagent MCP 的实际工作流MCP 接入对 Pi 这类 coding agent 的改变不只是多几个工具那么简单它直接改变了工作流的组织方式。我实测过的一个场景是这样的让 Pi 帮我排查一个项目里数据库慢查询的问题。以前的做法是我在终端里手动连上数据库跑EXPLAIN ANALYZE把结果贴给 Pi然后它分析我再继续手动查另一张表。一来一回一次排查得折腾十几轮。接上 PostgreSQL 的 MCP 服务器之后流程变成了我先给 Pi 一个总目标——“找出 orders 表上慢查询的原因并给出优化建议”。Pi 自己规划步骤先调用 MCP 工具拿到orders表的索引列表再调用另一个工具执行一条带EXPLAIN的查询然后把结果和代码仓库里的实体定义做比对。它甚至可以派一个 subagent 专门处理数据库侧的信息收集派另一个 subagent 去读项目里 ORM 的映射代码两个子代理并行工作最后汇总。这个过程中我几乎没有在终端里敲过一条 SQL。你说这是不是质变是。但它质变的前提是数据库侧有一套语义明确的 MCP 工具让 Pi 知道“该调哪个工具拿什么信息”而不是靠它自己瞎猜。MCP 在这里扮演的角色是把“数据库操作”这个领域的能力翻译成了 AI 能理解的结构化接口。3. MCP 没赢协议化之后的真实边界与踩坑清单我虽然很看好 MCP 的方向但要说“MCP 赢了”那绝对是为时过早。协议标准只是解决了互通问题它没有解决一个更根本的问题工具描述质量。工具描述写得烂MCP 服务器接得再多也是给 AI 添乱。3.1 工具定义质量的参差同一个概念五花八门的描述现在 MCP 服务器数量爆发但质量参差不齐得厉害。同一个功能不同的服务器可能给出完全不同的工具命名和描述。比如获取 Git 分支信息有的服务器叫list_branches描述写“列出所有本地分支”有的叫git_branch描述写“显示当前仓库的分支信息包括远程分支可用 -a 参数显示所有分支”。这个差异直接影响 AI 的“选工具”能力。MCP 这类系统中的工具调用本质是一个路由问题模型读一遍所有工具的名字和描述判断哪个最匹配当前任务。如果描述含糊、参数说明不完整模型就会选错工具或者为同一个目标反复尝试好几个工具浪费时间也消耗上下文。我见过最离谱的一个服务器把所有操作都塞进了一个叫execute的工具里靠第一个参数去区分是“查数据”“写文件”还是“跑命令”。这样一来模型确实只有一个工具可以选但它的 description 被拉得巨长而且每次调用都要把一大段参数说明重新过一遍——效率比不用 MCP 还差。3.2 异常与超时MCP 会话的黑盒体验另一个让我头疼的问题是排障体验。MCP 服务器以 stdio 模式跑在本地时本质是一个由客户端启动的子进程。这个子进程如果崩了、卡了、或者输出了一段非协议的日志AI 客户端往往只会给你一句冷冰冰的“工具调用失败”。有一次我让 Pi 调一个文件搜索的 MCP 工具它连续三次返回失败也不说具体原因。我最后手动在终端里单独启动那个服务器命令才发现是配置里的路径参数写错了服务器一启动就直接异常退出而客户端根本不会把这个 stderr 透传给我。这个问题的根源在于MCP 协议定义了客户端和服务器之间怎么说话但没定义服务器内部出了故障时该怎么把错误信息传递出来。有的服务器会把异常写成 JSON 错误返回给客户端有的直接往 stderr 里吐一段堆栈然后退出。行为不一致导致 AI 遇到 MCP 工具失败时几乎没有自主排查能力最后还是得靠人去翻日志。3.3 上下文成本与工具膨胀工具越多模型越容易“选错手”还有一个容易被忽略的问题工具是有上下文成本的。每给 AI 接入一个 MCP 服务器AI 客户端的上下文里就要多一份该服务器的工具列表。几十个工具的话还好几百个工具的话光是把这些工具的名字和描述过一遍就要吃掉不少 token。更要命的是工具越多模型的选择准确率反而可能下降。人也是这样一把螺丝刀和一个扳手摆在面前你很容易选对但要是桌上有两百件长得差不多的工具你就开始犹豫了。大模型在选择工具时也面临同样的困境——它需要从一堆描述里找到跟当前任务语义最匹配的那个工具数量越多route 错误的概率越大。所以那些一上来就接十几个 MCP 服务器的人很快会发现 AI 变得“手忙脚乱”明明有专门的数据库工具不用偏偏去调一个“代码搜索”工具把搜索结果拼起来猜数据库结构。这不是 AI 变笨了而是工具描述给它的信号太多太杂淹没了真正关键的那一两个。MCP 没赢的另一个含义就在这里——它解决了互通但没有解决“AI 怎么选工具”这个更上游的难题。4. CLI 也没输MCP 的内核其实是把 CLI 的“人可读输出”翻译成“机可读契约”聊到这里得回到标题的后半句了CLI 也没输。为什么这么说因为如果你拆开一个 MCP 服务器的实现来看会发现一个反直觉的事实——很多 MCP 服务器内部就是封装了一个 CLI 程序然后在外层套了一层 JSON-RPC 的壳。4.1 一个反直觉的事实很多 MCP server 内部就是封装 CLI 子进程本地 MCP 服务器最常见的传输方式是 stdio客户端通过标准输入输出和服务器进程通信。你在配置文件里看到的command: npx、args: [-y, modelcontextprotocol/server-postgres, ...]本质上就是让客户端去启动一个 Node.js 进程。这个进程内部干的事往往是再去调用 PostgreSQL 自带的psql命令行工具执行查询然后把psql输出的表格文本解析成结构化的 JSON 返回给 AI。GitLab 相关的 MCP 服务器就更典型了。很多实现直接封装glabCLI——这个命令行工具本身就是为人类使用设计的有色彩输出、有交互式提示。MCP 服务器要做的就是把这些面向人的输出风格剥掉提取出纯数据按协议打包。换句话说CLI 的“手”一直在MCP 只是在它外面套了一层“翻译官”。用代码理解大概是这样# MCP 服务器内部伪代码示意常见实现思路 import subprocess, json def handle_tool_call(name, arguments): if name git_list_branches: result subprocess.run([git, branch, --format%(refname:short)], capture_outputTrue, textTrue) branches [line.strip() for line in result.stdout.splitlines() if line.strip()] return json.dumps({branches: branches})看到没有核心还是那条git branch命令。MCP 服务器做的事情就是把“人敲命令 人读输出”这个过程自动化、结构化、塞给 AI。所以严格来说MCP 不是 CLI 的对手它是 CLI 的受益者。CLI 这么多年积累下来的工具生态不但没有被 MCP 抛弃反而成了 MCP 服务器最现成的“底层实现库”。4.2 直接使用 CLI 仍然不可替代的场景当然CLI 的可替代性也得分场景。至少有这么几类场景我到现在仍然选择直接敲命令不折腾 MCP。第一类是一次性临时操作。比如我想看看某个目录下最大的文件是哪个一条du -ah . | sort -rh | head -20就完了。为这个操作去配一个文件系统 MCP 服务器建索引、配置启动参数、测试工具调用半小时过去了。不值得。第二类是交互式 TUI 工具。git rebase -i、psql的\d命令、htop这种工具它们的设计前提就是人可以实时看到屏幕上的状态变化并且随时按快捷键做调整。MCP 要模拟这种交互式体验要么写一堆状态管理逻辑要么干脆做不到。有些东西天生就是给人在终端里玩的硬塞给 AI 反而别扭。第三类是输出质量需要人眼判断的场景。CLI 经常输出带颜色的表格、进度条、警告信息模型接收到这些格式化输出后反而要花额外的 token 去解析。比如docker logs的输出里有 ANSI 转义序列模型看到\x1b[32m这种东西第一反应往往是困惑。这种场景我宁愿自己在终端里看实时日志只把关键结论喂给 AI。4.3 一张表CLI 和 MCP 到底分别适合什么我整理了一个粗略的判断表格当你纠结“这个操作用 CLI 还是接 MCP”时可以参考对比维度CLIMCP交互主体人类AI 模型输出消费方人眼阅读模型解析适合任务一次性、探索性、交互式多步编排、上下文感知工具扩展成本低已有生态成熟高需要写服务端封装故障排查直接看 stderr 就能定位多一层协议层排障链路长长尾工具支持好几乎每个工具都有 CLI差长尾工具不一定有 MCP server上下文影响输出由人筛选后喂给 AI工具列表常驻上下文吃 token这个表格想表达的核心是CLI 和 MCP 不是替代关系而是互为表里。CLI 是“人通向工具的接口”MCP 是“模型通向工具的接口”。MCP 服务器内部大量复用了 CLI 的实现而 CLI 工具本身也在通过 MCP 获得新的消费场景。谁也没赢谁也没输大家只是换了个姿势合作。5. 实操视角给 Pi 用户的配置思路与排查链路讲了这么多宏观判断最后给点能直接落地的。我自己在给 Pi 这类编码代理配置 MCP 时有一套比较保守但稳定的思路这里按实操顺序拆开说。5.1 从“小而精”开始选型 MCP server第一条建议可能跟很多人的直觉相反别一上来就接一大堆服务器。我见过有人一次接了十几个 MCP server结果 AI 在工具选择上晕头转向什么活都干不好。起步阶段我建议只接三类高确定性工具文件系统类读写文件、目录遍历、搜索替换这类操作确定性强工具描述也成熟。代码搜索类语义搜索、符号跳转、跨文件引用分析让 AI 能快速摸清代码结构。数据库只读类查表结构、执行 SELECT、看慢查询日志但要注意权限控制尽量用只读账号。配置格式以社区常见的.mcp.json为例大概长这样{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /workspace/project ] }, postgres: { command: npx, args: [ -y, modelcontextprotocol/server-postgres, postgresql://readonly_user:passwordlocalhost:5432/mydb ] } } }注意几个细节command里的npx首次运行会去拉取 npm 包这一步通常很慢甚至可能超时。我建议先手动在终端跑一次这个命令确认包已经拉下来了、服务器能正常启动再让 AI 客户端去接管。另外数据库连接串里尽量用只读账号MCP 工具对 AI 来说是黑盒你没法保证它不会执行一次危险的写操作。5.2 “Codex 找不到 MCP 服务器”这类问题的完整排查链路很多人在配置 MCP 后遇到的第一问题就是“AI 客户端说找不到服务器”热搜词里也一直有“codex无法找到mcp”“安装codex cli很慢”这种词条。这里给一套我常用的排查链路照着走基本能定位。第一步确认配置文件的位置和命名。不同客户端的约定不一样有的读项目根目录的.mcp.json有的读用户目录下的全局配置还有的要在 GUI 设置里手动添加。配置文件放错位置客户端根本不会去读它这是最容易被忽略的原因。第二步把配置里的command和args拼在一起放到终端里手动执行一次。这一步能验证服务器本身能不能启动。很多人忽略了这个直接在客户端里调试结果要么是命令路径不对要么是依赖没装好要么是连接字符串写错全是这种低级但又极隐蔽的问题。第三步手动验证 JSON-RPC 握手是否成功。在终端里启动服务器进程后输入一条标准的 initialize 请求看它能不能返回带 protocolVersion 的响应。市面上大部分 MCP 服务器都支持这种直接输入 JSON 的方式# 连接到本地 MCP server 的标准输入发送初始化请求 {jsonrpc:2.0,id:1,method:initialize,params:{protocolVersion:2024-11-05,capabilities:{},clientInfo:{name:debug,version:0.1.0}}}如果这一步能拿到带serverInfo的响应说明服务器本身是完好的问题大概率出在 AI 客户端侧。如果这一步就卡住了那就是命令或参数的问题回到第二步继续查。第四步重启 AI 客户端。很多客户端是启动时才加载 MCP 配置的你改完配置之后不开新会话它根本不会重新读取。这个“改了配置不生效”的坑我踩过不下三次。最后一步查客户端日志。这一步相对费劲但很多时候客户端日志里会直接写着“MCP server exited with code 1”和具体的 stderr 输出。看到这句再去目标服务器目录下手动跑一次命令往往就真相大白了。5.3 什么时候直接退回 CLI我的判断清单最后分享一个我自己的实战判断清单。当你犹豫要不要为了某个工具接入 MCP 时按这三条问自己一遍答案基本就出来了。这个操作我多久用一次如果一周用不到一次直接 CLI。这个工具的输出是给人看的还是给机器解析的如果是颜色丰富的交互式界面直接 CLI。这个 MCP 服务器有人维护吗如果是一个个人开发者扔在仓库里三个月不更新的玩具项目直接 CLI。我现在的原则很简单凡是能一句话讲清楚目的的操作直接在终端里敲凡是需要模型在多步上下文里反复确认状态的操作才交给 MCP。这样两边都不累。别被“AI 什么都能干”的说法裹挟工具是拿来用的不是拿来堆的——这个道理无论协议怎么演进都不会变。
