上周我把终端里的默认编程代理从 0.x 切换到了 Pi 1.0起因很简单我同时开着三个 MCP Server 跑一个跨文件重构任务旧版本经常把工具调用的上下文搞乱更糟的是任务跑到一半电脑自动重启整个进度全部白费。Pi 1.0 正式发布主打原生 MCP 和 Pi Durable刚好都打在我这两个痛点上。这篇文章不是为了复读官方发布说明而是从我从旧版迁移过来、实际跑了几天之后的体验出发把三件事说透原生 MCP 支持到底改变了什么、Pi Durable 是怎么做到“断了还能续上”的以及接入 MCP 生态时哪些坑是真坑。如果你正在用终端编程代理或者在几个主流工具之间犹豫这篇应该能帮你少走几天弯路。1. Pi 1.0 这次发布先把三个老大难摆上台面1.1 终端编程代理这几年卡在了哪里终端编程代理是个很有意思的品类它不依赖 IDE直接在命令行里运行让 AI 自己读项目代码、跑测试、执行命令、改文件。相比 IDE 插件它更轻、更容易脚本化也天然适合放进 CI、容器、远程服务器这些没有图形界面的环境里。但这个品类从“能跑通 Demo”到“能真正接活”中间隔了三个老大难问题。第一是上下文太脆。终端会话一旦关闭、终端窗口被误关、或者电脑重启整个对话上下午就没了。下次启动要么重新描述一遍任务要么把之前的结论粘贴回来。对于超过一小时的复杂任务这种丢失几乎是致命的。第二是工具接入太碎。你想让 AI 操作浏览器得装一套浏览器自动化插件想查数据库又得配另一套连接器想读设计稿、操作逆向工具、调用项目管理接口每个都是单独适配。各家工具的自定义插件格式还不统一换一个代理就要重新配一遍。第三是长任务没有状态。跨 40 个文件的符号重命名、一次多阶段的数据迁移、跑一遍要半小时的回归测试加修复循环这类任务一旦中途被打断第二天你再问它“刚才进行到哪了”它往往一脸茫然。你说你没保存它也不知道该从哪里继续。这三个问题单看都不算致命但凑在一起终端编程代理就只能停留在“改改小文件”的水平。Pi 1.0 这次把 MCP 和 Durable 做进核心层本质上就是分别从“工具接入”和“任务状态”两个方向正面回应这些痛点。1.2 Pi 1.0 给出的两个正面回应先说原生 MCP。MCPModel Context Protocol模型上下文协议这两年已经成了 AI 工具接入的事实标准Playwright MCP、各类数据库 MCP、设计工具 MCP、逆向工具 MCP 都在往这个协议上靠。但“支持 MCP”和“原生支持 MCP”是两码事。Pi 1.0 是把 MCP 直接做进了代理主循环里项目里放一份pi.jsonc里面写好mcpServers启动时自动发现、按需加载、错误原样透传不需要再套一层自定义插件适配器。再说 Pi Durable。这是一套面向长任务的持久化机制它不只是把聊天记录存下来而是把整个任务的事件流、工具调用结果、已改文件的追踪、当前计划进度都落盘。会话过程中断后可以用pi resume找回代理会基于保存的状态继续干活而不是从头再来。我拿到的 1.0 正式版里这两个能力是默认开启并深度耦合的项目级配置也支持得很好。接下来我把原理和实操分开讲。2. 原生 MCP从“每个工具一套接口”到统一协议2.1 一句话讲清楚 MCP 是什么如果你没接触过 MCP可以把它理解成 AI 领域的“USB 接口”。USB 出现之前鼠标、键盘、U 盘各有各的接口你得为每个外设配不同的线。MCP 做的事就是统一它定义了 AI 应用host和外部工具/数据源server之间如何描述能力、如何发起调用、如何返回结果。一个 MCP Server 对外暴露三类能力tools可调用的函数比如“打开网页”“执行 SQL”、resources可读取的数据比如文件内容、表格、prompts可复用的提示词模板。数据传输走 JSON-RPC底层传输可以是标准输入输出stdio也可以是 HTTP/SSE。所以你在热词里看到的 Playwright MCP、Figma MCP、IDA MCP、PostgreSQL MCP本质都是同一个协议下的不同 Server。以前每接一个工具都是一套新集成现在只要按 MCP 协议写好配置理论上任何支持 MCP 的客户端都能复用。2.2 原生支持与外挂适配器的本质区别“支持 MCP”和“原生 MCP”的差别我建议看四个维度维度原生 MCP外挂适配器/插件转发工具发现启动时自动枚举 Server 的 tool list动态感知通常靠适配器硬编码工具名新增工具要发版错误透传工具内部报错原样返回给模型便于自我修正经常被包装成“调用失败”模型看不到真实原因传输层stdio、HTTP/SSE 原生支持配置即用中间多一层进程转发调试成本高配置一致性同一份mcpServers配置可在多个客户端间迁移各家插件配置格式不互通迁移要重写我在旧版本里尝试过给 Pi 接第三方 MCP 适配器最典型的问题是MCP Server 里明明定义了一个新工具适配器却没把它暴露给模型因为工具列表是写死的。原生支持后Pi 启动时会去询问每个 Server 的tools/list工具增删立刻生效这对工具生态快速演进的当下很重要。2.3 在 Pi 里配置并跑通第一个 MCP Server以 1.0 版本实测为例全局配置放在~/.pi/config.json项目级配置放在项目根目录的pi.jsonc。一个最基础的 stdio 传输的 MCP Server 配置长这样{ mcpServers: { playwright: { command: npx, args: [-y, playwright/mcplatest], env: { PLAYWRIGHT_BROWSER_PATH: /usr/bin/chromium } }, filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /workspace] } } }配置好之后用命令行管理pi mcp list pi mcp test playwright pi --mcp-server filesystem 把 /workspace/src/README.md 读给我并总结结构pi mcp test是个值得养成的习惯。它会向 Server 发一个初始化握手验证协议版本和工具列表是否正常。很多“工具没生效”的问题在这一步就能暴露出来。如果你的 MCP Server 走的是 HTTP 传输配置里要特别注意baseUrl这个字段而不是url{ mcpServers: { custom-http: { transport: http, baseUrl: http://127.0.0.1:3001/mcp, headers: { Authorization: Bearer token } } } }提示baseUrl必须包含完整的路径前缀比如/mcp。只写http://127.0.0.1:3001经常会导致 404。这个字段也是社区里搜索“pi configure base url”的高频问题后面第 5 节我会专门展开讲。2.4 一个真实任务让 Pi 开着浏览器干活配好 Playwright MCP 之后我做了个最简单的验证。给 Pi 下达指令用 playwright 打开一个本地页面读取页面上所有 h2 标题写入 /tmp/headings.md然后用 filesystem 确认文件内容。Pi 的处理过程大致是先发现playwrightServer 下有browser_navigate、page_get_content这类工具依次调用把页面内容写入文件时它又切换到filesystemServer 的写文件工具最后读取确认。两个不同 MCP Server 的工具在同一个任务里被统一调度切换几乎是无感的。这里我特意提一个热词场景MCP 工具流式输出内容到文件。当工具输出特别长比如 Playwright 抓回来的完整页面结构、数据库查询的几千行结果直接塞进对话上下文很容易把模型的注意力稀释掉。我在 Pi 里会引导它把长输出重定向到文件pi --mcp-server playwright 抓取页面 console 日志流式输出到 /tmp/console.log然后只汇报摘要这样既保留了完整过程记录又不会把上下文撑爆。原生 MCP 对这类场景的友好度是插件时代比不了的。3. Pi Durable状态不丢任务不白跑3.1 Durable 到底在持久化什么我一开始以为 Pi Durable 就是把聊天记录存下来用了一天才发现它远比这个复杂。它持久化的是“任务的状态”而不是“聊天的文字”。具体来说包括四类对话轮次和关键决策、工具调用的事件记录和结果摘要、工作区文件变更追踪哪些文件被哪个工具改过、改成什么样、以及代理内部的计划清单和待办进度。它类似一个事件日志每完成一次工具调用就形成一个可恢复的进度点而不是定时做全量快照。这个设计的好处是恢复粒度细。比如一个任务里改了 20 个文件你在第 18 个文件处中断恢复后代理知道自己推进到了哪里而不是把前 18 个文件再改一遍。更聪明的部分在于它会对编辑操作做幂等处理恢复时比对已应用变更的指纹避免重复替换导致的内容错乱。3.2 一次“干到一半崩溃”的恢复实测我专门做了一次压力测试让 Pi 对一个 C 项目做跨文件符号重命名涉及 40 个文件中间还穿插了几次编译和测试。任务跑到大约一半的时候我直接杀掉了终端进程模拟断电崩溃。重新打开终端执行pi durable sessions pi resume session-id恢复后的表现让我印象深刻。它没有从头开始而是先朗读了一段进度摘要“已完成 23/40 个文件的替换第 24 个文件尚未处理上一次测试在第 19 个文件处报错错误信息如下……”然后直接接着第 24 个文件继续。已完成的修改没有被重复应用失败断点也定位准确。这个体验和旧版本完全不同。以前遇到同样的情况我连“做到哪了”都要靠 git diff 猜更别说让代理记住失败原因。Durable 等于把“代理的短期记忆”升级成了“可持续的工程状态”。3.3 什么任务适合开 Durable什么任务别开不是所有任务都需要 Durable开之前先判断场景是否建议开启原因跨文件大规模重构强烈建议进度多、恢复成本高断点续跑收益最大多阶段数据迁移建议每个阶段都是独立事件中断后可精准续跑长时间测试修复循环建议失败信息被持久化不会丢上下文一次性小改动不建议事件日志也有写入开销涉及敏感数据的会话谨慎Durable 会把工具结果摘要落盘需评估边界多用户共享机器谨慎其他用户可能读取你的 durable 目录配置开关在项目级pi.jsonc里{ durable: { enabled: true, storageDir: ~/.pi/durable } }存储目录建议单独指定方便定期清理和备份。我个人的习惯是只有要跑超过 20 分钟的任务才显式开启短任务保持关闭减少无谓的文件写入。4. 和 Claude Code、Codex CLI 放一起比Pi 1.0 的价值在哪4.1 横向对比用终端编程代理的人基本都绕不开 Claude Code、Codex CLI、opencode 这几个名字。我把自己这几天的实测感受整理成一张表供你参考维度Pi 1.0Claude CodeCodex CLIopencodeMCP 配置兼容原生读取标准mcpServers配置支持配置走自家 CLI 或文件支持但部分传输类型受限支持插件体系略有额外封装任务持久化Pi Durable事件级恢复会话恢复为主任务级持久化较弱依赖外部记录进程中断后一般从头来基础会话恢复传输层stdio、HTTP/SSE 原生stdio 为主stdio 为主stdio 为主项目级配置pi.jsonc可继承全局配置有但和模型权限绑定较紧有配置项偏少有但社区插件格式分裂适合场景MCP 重度用户、长任务流水线深度代码理解和复杂对话与仓库/CI 工作流结合追求可定制 UI 和插件生态再说一遍这只是我的体感不代表绝对优劣。Claude Code 在复杂架构理解上依旧很强Codex CLI 和 GitHub 的联动是它独特的优势opencode 在交互界面上更现代。Pi 1.0 的差异化在于你用标准 MCP 配置就能把其他工具里攒下的 Server 生态直接搬过来再加上 Durable 对长任务的支撑这是它和其他工具拉开差距的地方。4.2 我切换主力工具的三点理由第一MCP 配置不用重写。我之前在别的工具里调的 Playwright MCP、文件系统 MCP、PostgreSQL MCP迁移到 Pi 1.0 就是把同一份mcpServers配置复制过来字段名、参数结构完全一致这个迁移成本几乎为零。第二Durable 正好匹配我的工作流。我日常有大量半小时以上的重构和迁移任务过去最怕中途被打断现在可以放心让任务挂着跑断了也能续上。这种安全感以前只有 CI 系统能给现在终端代理也给了。第三它在资源占用上很克制。不应答时基本不占内存没有 Electron 壳在服务器和容器里跑很干净。对于我这种常常 SSH 到远程机器上干活的人来说这个优点很实在。当然如果你主要做的是几十分钟内的深度对话式编程不一定需要换但如果你和我一样被长任务折腾过Pi 1.0 值得在你机器上跑两周试试。5. 接入 MCP 生态时最容易踩的坑附排查思路5.1 Server 拉起失败先查命令和 PATHMCP 接入最常见的失败不是协议问题而是进程根本没拉起来。现象是配置完pi mcp test直接报spawn npx ENOENT或者 Server 启动后秒退。根因通常是 PATH 不对。Pi 如果是从图形界面启动的继承到的环境变量和你在终端里看到的可能完全不一样npx、node的路径找不到。解决办法是在 Server 配置里显式指定 PATH{ mcpServers: { playwright: { command: /usr/local/bin/npx, args: [-y, playwright/mcplatest], env: { PATH: /usr/local/bin:/usr/bin:/bin } } } }另外npx -y第一次运行要下载包慢的话容易触发超时。排查时先手动在终端跑一遍 Server 启动命令确认退出码和报错信息再回来看配置。Windows 上还要注意用npx.cmd而不是npx。5.2 base URL 配错导致的连接失败就是热词里那个“pi configure base url”的高频问题。HTTP 传输的 MCP Server最常见的三个错误是字段名写错、路径没带全、本地地址的 IP 版本不对。字段名我再说一次是baseUrl不是url。很多从旧项目拷来的配置写的是urlPi 解析不到直接用默认的 stdio 去连结果自然是连接失败。路径问题也很常见。Server 实际监听/mcp你只写了http://127.0.0.1:3001请求全 404。排查时可以先用 curl 直接验证curl -X POST http://127.0.0.1:3001/mcp \ -H Content-Type: application/json \ -d {jsonrpc:2.0,id:1,method:initialize,params:{protocolVersion:2025-06-18,capabilities:{},clientInfo:{name:curl,version:0}}}有正常 JSON-RPC 返回说明 Server 没问题问题在 Pi 的配置没返回先去查 Server 本身的监听地址和端口。最后提醒一下localhost在部分机器上会解析到 IPv6 的::1而 Server 只监听了 IPv4这时换成127.0.0.1往往立刻见效。5.3 工具一多上下文就爆了这是 MCP 重度用户最容易忽略的隐性成本。每个 Server 启动后Pi 都要把它的工具定义读进上下文工具名、描述、参数 Schema一个复杂的 Server 动辄几千 token。挂 10 个 Server光工具介绍就能吃掉一大截上下文模型实际用来思考的窗口被严重压缩。我的处理原则是“少量按需”。全局配置只保留两三个核心 Server其余放进项目级pi.jsonc按项目加载。临时需要某个 Server 时用命令行参数单独挂载pi --mcp-server pg 列出 users 表结构如果某个 Server 工具特别多还可以尝试在配置里做工具过滤只暴露必要的几个大幅降低上下文占用。长输出继续沿用第 2 节说的“流式输出到文件”策略别让大段内容长期停留在对话窗口里。5.4 Durable 的存储占用与隐私边界Durable 便利的背后是磁盘代价。长任务的工具调用结果、文件变更摘要会持续追加写入事件日志跑一整天的大任务存储目录可能膨胀到几百兆。建议养成清理习惯pi durable prune --days 7隐私方面要拎清楚Durable 会把工具调用结果摘要落盘如果任务涉及敏感的生产数据、客户信息要么别开 Durable要么把storageDir指向一个加密盘。另外不建议把 Durable 存储目录提交进 git也不要在里面放任何凭据。5.5 权限控制与安全底线最后说安全。MCP Server 跑起来之后它的权限和当前用户是一样的能读你的文件、能执行命令、能访问网络。一个被投毒的 MCP Server完全可以借着“给 AI 提供能力”的名义干坏事。我的底线规则有三条第一只装来源清晰、更新频率正常的 Server优先用固定版本而不是latest避免供应链漂移第二配置里涉及 token 的地方尽量用环境变量引用不把明文写进pi.jsonc第三对要开放的目录和数据库权限做最小化设置给文件系统 Server 指定工作目录范围而不是放一个根目录权限。提示任何声称“免配置、全自动接入所有工具”的 MCP Server都值得多留个心眼。协议的便利性是把双刃剑权限该收紧还是要收紧。我在实际使用中还有个习惯是“先小后大”新接入一个 MCP Server先在临时目录里跑一个最小任务验证它只调用了预期的工具再放进正式项目。这套流程看起来费事但比事后排查供应链问题便宜得多。