1. 当年那波“不跟风”到底在犟什么1.1 彼时的 Pi自成体系的“全家桶”路线说句实话Pi 团队当初在公开场合表态“不会做 MCP”我第一反应是这很合理。因为那时候的 Pi 整个产品思路就是把自己做成一个 AI 原生的编程 IDE从代码编辑、终端、版本管理到 Agent 任务编排全部在自家容器里闭环。Pi 的 Agent 模式靠的是内置的一套工具链——文件读写、Shell 执行、代码检索、问题追踪——这些能力全部由官方维护API 稳定行为可预期。站在产品团队的视角这种“全家桶”路线是有诱惑力的用户打开 Pi 就能干活不需要折腾外部依赖Agent 调用的每个工具都经过白名单校验安全模型可控上下文窗口里塞什么、怎么摘要有一套统一策略不会因为第三方工具突然吐一段超长 JSON 把整个对话搞崩。当时市面上的 MCP 协议才刚刚露出苗头生态里大多是玩具级别的 Server稳定性差文档稀烂接入一个外部工具往往要花半天调参数最后跑起来的效果还不如内置命令来得利索。而且还有一层更实际的原因如果全面拥抱 MCP等于把“工具生态”这个最核心的护城河拱手让给了第三方。任何一个 MCP Server 都可以替代 Pi 内置的文件操作、终端执行甚至代码分析能力用户对 Pi 的依赖就从“非它不可”变成了“不过是个 Host 而已”。这种被架空的风险任何一个商业产品都会认真掂量。1.2 拒绝 MCP 的合理性并不完全是傲慢抛开商业博弈单纯从工程角度看当年拒绝 MCP 也有充分的技术理由。MCP 协议在设计上有一个明显的短板工具返回的内容没有强约束的 SchemaServer 可以返回任意格式的文本、图片或结构化数据。对于 Agent 来说这意味着每次调用完工具模型都要重新“理解”一段可能长达数千 token 的输出再决定下一步动作如果 Server 写得不规范甚至会把二进制内容、日志噪音一起塞进上下文直接拉低推理质量。Pi 当初的内置工具每一个都有严格定义的返回结构。文件读取返回的是分片段截取的内容Shell 执行返回的是退出码、stdout、stderr 的分段切片代码检索返回的是带行号、带仓库路径的匹配片段。这种“有界输出”设计能让 Agent 在执行长期任务时保持上下文整洁不会因为一次工具调用就陷入信息过载。相比之下当时的 MCP Server 五花八门有的直接返回整份文件内容有的把日志和结果混在一起模型经常被带偏。另一个顾虑是安全问题。MCP 的授权模型很粗放Server 启动时拿到的是用户进程的完整权限一个写得不严谨的文件系统 Server可能允许 Agent 读取整个磁盘的敏感文件。Pi 内置工具至少有细粒度的权限提示比如执行高危命令前会弹确认而 MCP 工具的调用往往直接透传用户根本来不及反应。对一个主打生产力场景的编码 IDE 来说这种不确定性是很难接受的。1.3 那根“导火索”是怎么被点燃的那后来为什么改口了我观察到的转折点有两个。第一个是生态的爆发式增长。从 Anthropic 把协议开源之后各家工具跟进的速度远超预期——浏览器自动化、数据库连接、设计稿导入、CI/CD 触发、安全扫描、逆向调试几乎每个垂直领域都长出了可用的 MCP Server。用户的需求不再只是“读写文件、跑命令”而是“让 Agent 帮我把 Figma 的设计稿转成代码”“让 Agent 直接查生产数据库的慢查询日志”“让 Agent 在 GitHub 上提 issue、改 PR”。这些需求靠 IDE 内置工具是永远覆盖不完的而且每接一个垂直场景就要重新造轮子成本完全不可控。第二个转折点是 Pi 自己的架构演进。Pi 在后续版本里把 Agent 模块做成了更通用的“任务规划器”开始支持 Subagent 子任务拆分Agent 的执行流程从“单工具顺序调用”变成了“多 Agent 并行协作”。在这种架构下内置工具其实是 Agent 的“默认手”而外部世界需要一套标准协议来扩张 Agent 的感知半径。MCP 恰好提供了这套标准——HostPi、Client会话内部、Server外部工具三层结构天然适配 Agent 的任务委派模型。所以与其说是“真香打脸”不如说是生态成熟度到了临界点当外部工具的丰富度和稳定性能够反哺 Agent 能力时再坚持封闭路线就是对用户体验的辜负。Pi 的转变本质上是从“我是全能工具”切换到“我是智能中枢”的定位调整。2. MCP 到底是啥为什么能让 Pi 打脸2.1 一句话理解 MCP 的架构如果只用一句话解释 MCPModel Context Protocol模型上下文协议我会说它是 AI 助手的 USB-C 接口。一台笔记本如果只有固定几个焊死的接口能接的外设就非常有限有了 USB-C 标准几乎所有设备都能统一接入。MCP 做的是同一件事——让 AI 助手Host通过同一套协议连接任何外部工具和数据源Server。在 Pi 这个场景里角色分工是这样的Host也就是 Pi 本体桌面端或者 Web 端负责维护 Agent/Subagent 的会话生命周期管理 MCP 连接的配置。ClientHost 内部为每个会话创建的客户端实例负责与远端 Server 建立连接、发起请求。Server独立运行的进程或服务暴露一组工具Tools、资源Resources和提示词模板Prompts比如一个文件系统 Server 暴露 read_file、write_file、list_directory 等工具。Pi 启动时会根据配置文件把声明的 Server 全部拉起然后通过 Client 与 Server 之间交互获取工具列表并把工具的描述注入上下文。当 Agent 决定调用某个工具时Client 会按照协议把参数传给 Server执行结果返回后再交还给 Agent 继续推理。整个过程对用户是透明的——你只会看到 Pi 的对话界面里多出了几个可以调用的“外部工具”但这些工具的代码不在 Pi 的仓库里而是来自一个独立的进程。2.2 三个要搞懂的核心概念Tools、Resources、PromptsMCP 协议定义了三种主要的原语理解它们比背协议文档重要得多。Tools工具是 Agent 主动调用的动作单元比如“查询天气”“创建文件”“执行 SQL”。每个 Tool 有名字、描述、输入输出 Schema。Agent 拿到这些 Schema 后会在推理过程中决定是否调用、传什么参数。这是 MCP 里最常用的原语Pi 接 MCP 之后主要折腾的就是这一层。Resources资源是只读的数据源比如一个配置文件、一整个目录的文档、一张数据库的表结构。资源可以被 Agent 主动读取也可以在对话中作为上下文被引用。举例来说你可以把项目的 README 和接口文档注册成 Resources这样 Agent 在回答问题前可以先拉取这些资源来“预习”。Pi 的 Web 端导入 Skill 的功能本质上也是在给 Agent 注入预制的知识资源不过 Skill 更多是提示词级的MCP 的 Resources 是数据级的。Prompts提示词模板是预置的指令模板目的不是让 Agent 自己调用而是让用户可以一键调用某个场景的工作流。比如你装了一个“代码评审” MCP Server它里面内置了一个 prompt 模板你选中一段代码后点一下“评审”模板会自动填充成完整的评审请求发给 Agent。这个原语在 IDE 场景里特别有用能把高频操作变成一键动作减少重复写提示词的时间。2.3 传输层stdio 和 streamable HTTP 怎么选MCP 的传输层有两种模式实战中经常会遇到所以这里单独拎出来说。stdio 模式Server 以子进程的方式被 Host 拉起Host 通过标准输入/输出和 Server 通信。这是本地开发时最常用的模式配置简单启动快不需要额外跑一个服务。缺点是一个 Server 进程只能服务一个 Host如果多个 Pi 实例或 Pi 和 Codex 同时要连同一个 Server就得各拉一个进程。streamable HTTP 模式Server 作为一个常驻 HTTP 服务运行Host 通过网络请求连接。适合远程部署的 Server、多用户共享的情况。Pi 的桌面版和 Web 版都支持这个模式如果你有一个跑在公司内网里的数据库 MCP Server可以让多个开发者同时通过 HTTP 连上去。选择的基本原则是本机用、单用户、配置简单——选 stdio跨设备、多用户、需要常驻服务——选 streamable HTTP。实操中很多人喜欢把文件系统、浏览器这类 Server 用 stdio 挂着把数据库、文档库这种偏“服务型”的用 HTTP 暴露。一个特殊的地方是如果某个 MCP Server 需要同时给多个 AI 工具用比如 Pi 和 Codex 都可能用到公司的数据库那 streamable HTTP 是唯一不会踩进程冲突坑的选择。3. Pi 接入 MCP 的实操记录3.1 这一步先说清楚配置文件到底怎么写Pi 接入 MCP 的方式和其他主流工具基本一致都是靠一个 JSON 配置文件声明要启动的 Server。常见的配置文件名是.mcp.json或者放在全局配置目录下的mcp.json项目级的配置通常在项目根目录全局配置则放在用户目录下的 Pi 配置文件夹里。一个典型的配置长这样{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /Users/me/projects/demo ] }, fetch: { command: npx, args: [ -y, modelcontextprotocol/server-fetch ] } } }这里mcpServers是固定顶层字段下面每个 key 是一个 Server 的名字。command是启动命令args是参数。如果你用的是 streamable HTTP 模式的 Server则不需要 command改成type: http加url字段{ mcpServers: { internal-db: { type: http, url: http://localhost:8080/mcp, headers: { Authorization: Bearer your-token } } } }有个细节要特别注意每个 Server 声明是一次性定义、多个会话共享的。Pi 会为每个 Server 维护一个 Client 实例你在不同对话里看到的同一个工具实际调用的是同一个 Server 进程stdio 模式下就是同一个子进程。如果 Server 是有状态的比如文件系统 Server 记住了当前工作目录那不同会话之间可能会互相影响。配置写完以后在 Pi 里大概率需要重启会话或者点击刷新按钮让配置生效。如果刷新后工具列表没出现优先检查命令能不能在终端里单独跑通——这是排查的第一步后面会有专题。3.2 亲手连一个 filesystem server验证“真香”纸上谈兵没用我直接把第一个 MCP Server 配起来给你们看。项目路径是/Users/me/projects/demo我加了一个文件系统 Server然后在对话里让 Pi Agent“帮我看看 demo 项目里有哪些文件并统计每个目录的占用空间”。第一次调用时Pi 会先列出工具列表Agent 看到read_file、write_file、list_directory、get_file_info这些工具后会先调用list_directory扫描项目根目录然后逐个递归查看子目录最后汇总成一份 markdown 表格给我。整个过程几乎无感工具调用发生在后台对话里只显示最终结果。这里有一个我认为很关键的体验变化内置文件工具和 MCP 文件系统 Server 相比功能几乎一样但 MCP 版本多了几个“意外收获”——它支持跨目录访问。只要配置时给了多个路径参数Agent 就能同时读取几个不同项目的文件而不需要额外切换工作目录。对于我这种经常需要在多个仓库之间对比代码的人来说这个能力非常实用。另外一个值得试的是 fetch server。接入之后Agent 可以直接请求一个 URL 并读取网页内容。我让 Pi“抓取某个开源项目的 README 并总结它的核心架构”它先调用 fetch 获取页面再把内容消化成结构化摘要。这个场景以前只能靠内置工具里可能没有的“打开链接”功能或者手动把文本贴进去现在等于给 Agent 装了一个“浏览器手”。3.3 Pi Agent 与 Subagent 的协作模式MCP 怎么配合Pi 的 Agent 模式支持把任务拆分成多个 Subagent 并行处理这个机制遇到 MCP 之后有个很有意思的化学反应不同 Subagent 可以带着不同的 MCP 工具去执行各自的任务。举个例子我接入了三个 Server文件系统、数据库、网页搜索。然后我给 Pi 一个任务“对比本地项目的文档描述和线上数据库的实际表结构把差异整理成报告。” 主 Agent 会把任务分成三个子任务一个 Subagent 用文件系统 Server 读取本地文档一个 Subagent 用数据库 Server 查表结构还有一个 Subagent 用网络搜索 Server 找相关技术资料。每个 Subagent 自己管理自己的 MCP 工具会话最终把结果汇总给主 Agent。在这个协作模型里有几个实操细节值得记录Subagent 之间不会共享上下文所以你在设计任务时要让每个 Subagent 的输入输出尽量结构化。比如明确告诉它“读取完成后输出一个 JSON 数组字段包含表名、字段名、类型”。MCP 工具在 Subagent 里是可见的但并不是所有工具都适合并行。如果两个 Subagent 同时调用同一个有状态 Server比如数据库 Server 正在执行写操作可能会互相干扰。对这种 Server尽量让 Subagent 串行执行或者在配置层面拆成多个 Server 实例按角色隔离。Pi 的 Token 消耗会明显增加因为每个 Subagent 都要加载一次工具描述。如果你的 MCP Server 工具很多十几个每个 Subagent 都得把全部工具列表载入上下文一次。这时候可以考虑给不同的 Subagent 配置不同的 Server 权限只暴露它任务需要的工具。3.4 MCP 工具的输出怎么“流式”落盘别把上下文撑爆程序员天生爱较真把 MCP 工具的输出直接塞回对话里其实是“下策”。很多工具返回的数据量大得惊人数据库查询结果是几千行表格文件系统扫描是成千上万个文件名网页抓取是一整篇 HTML。如果这些原始输出全部进上下文Agent 的推理质量会被拖垮。我的做法是“输出落盘、上下文只留摘要”。具体来说在 MCP Server 端或者通过 Pi 的 Agent 编排层加一个后置步骤工具返回值先写到临时文件Agent 只读取文件的前 N 行作为摘要。这个思路有点像 CherryStudio 里常见的流式输出方案——MCP 工具把内容分段写入日志文件界面只展示进度和摘要完整内容后面需要时再分段读取。如果你自己写 MCP Server可以在 Server 端就实现这个逻辑把大结果写入磁盘返回给 Client 的只有文件路径和行数统计。这样 Pi 的上下文负担极小Agent 也能通过分段读取来按需消费内容。我在本地测试过一个日志分析 Server它扫描十万行日志后返回一个“分析完成结果在 /tmp/xxx/result.json共 2000 行”这样的摘要Agent 再通过 read_file 一点点读关键部分效果非常好。4. 顺着“真香”路线这几个场景值得抄作业4.1 浏览器/网页自动化接一个浏览器 MCP 干点重活浏览器 MCP 是 Pi 接入 MCP 后最容易出效果的场景之一。我配过一个 Playwright 系的浏览器 Server直接让 Agent 打开网页、点击按钮、填写表单、截取页面状态。实际跑下来稳定性比我预期的好多了。比如我让它“打开某个后台管理系统用测试账号登录找到今天的订单列表截图并总结前十条订单金额”。Agent 的动作序列大致是调用 browser_navigate 打开登录页browser_fill 填用户名密码browser_click 点击登录等待页面跳转再调用 browser_evaluate 执行一段 JS 获取表格数据最后 browser_snapshot 截图。整个过程有十余次工具调用Agent 在 Pi 里以可视化步骤的方式逐步执行我能看到每一步的输入输出也能随时中断修正。这里面有个很重要的经验浏览器自动化场景不要等到最后才截图要经常截图。因为 Agent 很容易在某个环节被验证码、弹窗、异步加载绊住如果每一步都有视觉信息Agent 能自己判断是否偏离预期并调整。我用的是 Dify 里也常见的浏览器 MCP 思路——把浏览器作为 Agent 的“眼睛”和“手”每一步都汇报当前页面状态大幅减少“盲目点击”的失败率。4.2 数据库直连给模型一双会查表的手数据库 MCP 的接入其实比很多人想象中简单。通常是运行一个数据库 MCP Server把连接串写在配置文件里Server 启动时建立连接池然后暴露query、list_tables、describe_table这些工具。我在 Pi 里接入了一个 MySQL 的 MCP Server测试任务是“查一下用户表里最近 7 天注册人数按日分布并对比前一周的同期数据。” Agent 先调用 list_tables 确认表名再调用 describe_table 拿到字段名最后构造 SQL 查询执行。整个过程不需要我写一行 SQLAgent 自己就能根据表结构推断字段含义。但这个场景有几个必须提前避开的坑数据库 MCP Server 默认情况下没有只读保护。你给 Agent 的权限是它查的但它如果被引导调用 update、delete 这类写工具后果很严重。强烈建议在生产数据库上只暴露只读账户的 MCP Server或者在 Server 层把写操作直接禁用。另外一个教训是时区问题。数据库里存的可能是 UTC 时间Agent 直接用本地时区计算会得出错误结果。我在让 Agent 查“最近 7 天”这类时间窗口时会在提示词里显式说明“数据库时间为 UTC请先转换再过滤”否则数经常对不上。这种问题不能指望 Agent 自己发现你得提前在工具描述里写好约束。4.3 设计稿同步Figma、蓝湖这类工具崩溃过但也救过人设计稿转代码这个场景MCP 的价值体现在“Agent 能看到设计稿的结构而不只是图片”。如果用 Codex 或者 Pi 接入 Figma MCPAgent 可以直接读取设计稿里的节点树、样式属性、文本内容、导出资源然后生成结构和风格都贴合设计稿的前端代码。实际体验下来这个流程比截图给 Agent 看要强得多。截图只能给视觉参考Agent 对颜色值的还原基本靠猜MCP 则直接把 hex 颜色、字号、间距这些参数喂给模型生成的结果贴近度高很多。我试过用同样的设计稿分别用截图方式和 MCP 方式生成页面MCP 方式产出的代码几乎不用调样式截图方式则需要手动修大量细节。不过也踩过坑Figma MCP 的授权流程偶尔不稳定Token 过期后不会自动刷新需要手动去 Pi 的配置里重新设置环境变量。蓝湖的 MCP 偶发超时大页面节点树导出时容易卡住。我的建议是不要把整个设计稿一次性丢给 Agent而是按页面、按区块去读取节点降低单次数据量成功率会高很多。4.4 逆向工程场景IDA、x32dbg 的 MCP 插件是真的好用顺着热搜词里“ida mcp”“x32dbg 的 MCP 插件”往下聊聊。安全研究这个圈子最近也在快速拥抱 MCPIDA Pro 已经有成熟的 MCP 插件可以暴露反汇编、函数列表、交叉引用、伪代码获取等工具让 AI Agent 辅助分析二进制文件。我在 Pi 里连过一个 IDA MCP Server通过 streamable HTTP 在本地起服务测试任务很简单“分析这个函数的调用关系找出谁调用了它并生成伪代码级别的说明。” Agent 调用 list_functions 找到目标函数再调用 get_xrefs_to 拿到引用列表最后 get_pseudocode 提取伪代码整理成分析报告。相比手动在 IDA 里一个个点交叉引用这个效率提升不是一星半点。这类工具的使用特性是结果高度结构化非常适合 Agent 处理。不过要注意 IDA MCP Server 和 IDA 本身是绑定的——Server 进程必须要有一个打开且正在分析目标的 IDA 实例在背后支撑IDA 关掉的话 MCP 工具会全部失效。这类 Server 通常只能承担单进程任务如果你同时开了多个分析项目建议一个项目一个 Server 实例避免互相抢 IDA 会话。5. 从“代码 IDE”到“所有软件都想接 MCP”5.1 不只是 IDE 的事工业软件和业务系统的 MCP 化苗头最近看到的热搜词里有一个很有意思的现象——MCP 已经不只出现在 AI 编程工具里了。Altium Designer 这种电路设计软件开始琢磨 AI 接口怎么走 MCPTIA西门子的工业自动化工程组态软件出现了 MCP 交付包连 RuoYi-Vue-Pro 这种业务脚手架都开始合入 MCP 功能。这说明 MCP 正在从“开发者工具圈的协议”变成“行业软件的通用 AI 接入层”。这些工业软件的共同特点是专业能力极强但数据封闭自动化接口要么没有要么非常难用。以前想给这类软件配一个 AI 助手得单独写定制插件跟软件的内部 API 深度耦合。有了 MCP 之后软件厂商只需要暴露一层标准化的 MCP Server把核心操作打开工程、读取器件库、执行布线检查、操作组态变量封装成 Tools任何支持 MCP 的 AI 助手都能直接接管这些能力。以 Altium Designer 为例AI Agent 可以通过 MCP 读取原理图里的元器件清单、检查某个网络的连接关系、甚至辅助生成器件选型建议。设计师的工作流从“打开软件—手动翻看原理图—记笔记—切到 AI 对话—描述问题”变成了“直接在 Pi 里发指令—Agent 自己打开工程—读取关键数据—返回分析结果”。这中间的效率差距是数量级的。5.2 别只顾着接协议之外的“隐性成本”要算清楚MCP 接入本身不难难的是接入以后的运维成本。我列几个容易忽略的隐性成本给正准备全面铺开的朋友提个醒。工具数量的管理与上下文预算的博弈。每接一个 MCP ServerPi 都会在会话初始化时加载它的全部工具描述。一个 Server 如果有 8 个工具描述文本可能就要消耗几千 token。如果接了十几个 Server光是工具列表就把上下文占满了模型根本没空间思考你的实际问题。我的经验是把不常用的 Server 平时关掉按需启用或者在同一配置文件里按项目拆分每个项目只挂自己需要的两三个 Server。依赖进程的生命周期。stdio 模式的 Server 跟随 Pi 会话启动理论上会话结束会跟着退出。但实测中偶尔会出现 Server 进程残留的问题尤其是 npx 拉起的 node 进程长时间累积会导致端口占用、资源泄漏。建议定期用ps aux | grep mcp检查一下或者写个简单的清理脚本把残留的 mcp server 进程统一杀掉。协议的版本兼容性。MCP 协议还在快速演进旧版的 SDK 写的 Server 可能在新的 Pi 版本上跑不起来或者 Pi 升级后某些 Server 的连接方式变了。我遇到过 Pi 一次更新后原本用 stdio 跑得好好的 Server 全部连不上查了半天发现是配置里少了一个type: stdio的显式声明。这类问题无解只能养成习惯升级 Pi 之后先跑一遍工具冒烟测试确认所有 MCP Server 都正常连接再继续干活。安全边界问题。MCP 是一把双刃剑它给 Agent 扩展能力的窗口也是恶意指令的入口。不要随意信任来历不明的 MCP Server尤其是那些需要输入密钥、需要读取全盘文件、需要执行任意命令的 Server。给 Server 的权限永远遵循最小化原则宁可多配一个只读实例也不要图省事给一个全集权限。6. 常见问题与排查实录6.1 “找不到 MCP”这个问题九成是三个原因如果你在 Pi 或者 Codex 里遇到“无法找到 MCP”“工具列表为空”之类的问题不要慌九成的概率是下面三个原因之一。第一个原因是配置文件没有生效。检查一下文件路径对不对全局配置和项目配置的关系是否弄混了。Pi 的项目级配置一般在项目根目录下的.mcp.json但如果你是在全局配置里写的而当前项目覆盖了全局配置那项目里的配置里没有声明这个 Server自然就找不到。解决方法是把 Server 声明合并到当前生效的配置里。第二个原因是命令本身跑不通。npx -y modelcontextprotocol/server-filesystem这类的命令在终端里没跑通最常见的原因是网络问题——npx 需要从 npm 仓库拉取包公司网络代理环境下经常拉不下来。排查方法很简单把command和args复制到终端里手动执行看能否正常启动。如果启动时报错优先解决依赖安装或者代理问题。第三个原因是 Server 启动后崩了。有些 Server 启动时会做环境检查比如需要当前目录存在、需要环境变量里有 Token检查失败就静默退出。Pi 界面上往往只显示“连接失败”不会显示具体错误。这时候去终端手动跑一遍命令把启动报错信息看清楚基本就能定位。6.2 MCP 进程悄悄挂了之后你该怎么自救stdio 模式的 MCP Server 挂掉之后Pi 的会话会继续但所有工具调用都会超时或者返回空。这是最恼火的情况因为界面不会主动提示你有工具不可用。我的处理方式分三步第一步先检查进程是不是还活着在终端里执行ps aux | grep -i mcp如果找不到对应的 node 进程基本确定 Server 挂了。第二步尝试在 Pi 里手动重接连线——很多工具在配置界面有一个刷新或者重连按钮点一下会重新拉起 Server。实在没有就重启一下 Pi 的会话。第三步如果重启会话依然失败把配置文件里的 Server 单独拿出来在终端跑一遍看是否报错。这一步通常能发现 Server 代码本身的 bug比如版本不兼容、依赖更新导致参数变了。有一个经验可以分享尽量让 Server 的启动方式简单化。依赖本机复杂环境的 Server比如要求某个 Python 虚拟环境先激活更容易挂因为 Pi 拉起子进程时的环境变量和你终端里的不一定一致。遇到这种 Server我会写一个包装脚本把环境激活和启动逻辑封装成一行命令配置里直接调用脚本能少踩很多坑。6.3 权限与安全一次误操作把数据库表清空的反思最后谈一个严肃话题。MCP 工具一旦给了 Agent调用就只是一个“推理决定”的事——模型认为需要它就会调用用户往往来不及拦截。我在测试一个数据库 MCP Server 时因为配置的是管理员账户Agent 在执行一个看似无害的“清理测试数据”任务时直接把一张表的所有行删了。删除发生在会话里等我反应过来数据已经没了。好在是测试库没有造成真实损失但这个教训让我彻底改变了对 MCP 的权限管理策略。现在我的规则很简单所有数据源类的 MCP Server一律使用只读账户权限只给 SELECT 和 SHOW。文件系统 Server 只暴露指定的工作目录绝不暴露整个用户目录。浏览器 Server 只给测试环境的 URL不给生产环境。任何写操作类的工具在 Server 端加一个确认回调不确认就不执行。定期审查 MCP Server 的日志看看 Agent 实际调用了哪些工具有没有越权意图。我把这个思路也用在给团队分享的配置模板里——所有 Server 的权限先按最小集配置缺什么再开什么而不是图方便一次开全。MCP 带来的便利是真实的但它的风险边界也必须是清晰的。工具越强大使用者的纪律就越重要。说实话我从 Pi 刚开始说“不做 MCP”时觉得合理到现在自己接入了一堆 Server 离不开了中间的转变也就半年多的时间。最后分享一个我自己的判断MCP 不会取代 AI 工具的内置能力但它正在成为所有 AI 工具连接外部世界的事实标准。以后选 AI 工具支持 MCP 可能比支持某个具体功能更重要——因为 MCP 意味着这个工具可以持续长出新能力而封闭的工具链只会慢慢被生态边缘化。你如果还没试过给 Pi 接一个 MCP Server我建议从文件系统那个开始配好之后让 Agent 帮你整理一次项目目录你会立刻理解“多了一双手”是什么感觉。