Pi 1.0 正式版发布之后我第一时间就把手上的测试项目切了过去。这次大更新和以前小版本打补丁完全不是一个量级——新增的 MCP 服务支持、界面上可以直接盯着的 token 消耗数据、以及大家催了大半年的 codemode三个功能叠在一起直接把 Pi 从一个终端里的聊天机器人推到了能自己动手改代码的智能体这个位置。这篇文章我不打算写那种逐条列更新日志的评测只挑这三块往下挖MCP 到底怎么接才顺、token 消耗实测下来是什么水平、codemode 在各种工作流里应该怎么设怎么用。先说结论这三块功能都非常值得升级但使用体验差异很大。MCP 是质的飞跃token 统计是刚需codemode 则是双刃剑——用好了效率翻倍权限没配置好能给你整出大动静。下文全部来自我实际跑过的项目案例配置方法和踩坑记录都是可以直接照着复制的。1. Pi 1.0这次更新到底改了些什么1.1 新增MCP服务AI终于能伸手够到外部工具了MCP 的全称是 Model Context Protocol模型上下文协议。我用一个生活化的类比解释它这就是 AI 世界的USB-C 接口。在 USB-C 统一之前手机、电脑、耳机各自用不同的充电口出门得带好几根线MCP 出现之后AI 工具接外部数据源和工具的方式也被统一了只要实现了 MCP 标准大家用同一套协议互联。Pi 1.0 这次新增 MCP 服务支持意义在于它从一个只能说话的程序变成了能动手的程序。以前我要分析一份本地日志得自己把日志内容粘进对话里粘不进去的就只能干瞪眼现在我把文件系统 MCP 服务挂上去直接告诉 Pi 读取 /var/log 下最近一小时的应用日志帮我找出报错最频繁的三个模块它会自己调用工具读取文件、统计、返回结论。整个过程不需要我复制粘贴也不需要我先把文件内容截断成能塞进上下文的大小。这套能力再往后延伸还更值钱。接入 GitHub 的 MCP 服务之后Pi 可以直接读取指定仓库的 issue 列表、查看 PR 的变更文件接入 PostgreSQL 的 MCP 服务之后让它统计近七天订单金额按日分组这种需求它会自己拼 SQL、查库、把结果整理成表格。这些在 Pi 1.0 之前都做不到只能靠人肉搬运信息进对话费力且容易漏。1.2 除了MCP这次更新还带了什么更新日志里还有两个值得重点说的变化。第一个是 token 消耗可视化。现在每个会话的侧边栏都能实时看到本次会话消耗了多少输入 token、多少输出 token、其中多少命中了缓存对成本敏感的用户来说这功能比什么都实在。以前我用完一轮对话根本不知道一次让 AI 改个 bug的操作花了多少钱现在一目了然也方便针对性地优化。第二个变化是 codemode 被正式扶正了。其实之前的测试版里已经有类似能力但调用不稳定权限管理也混乱。1.0 版本把操作模式做了明确分层普通对话模式只管回答codemode 才允许 AI 读写代码文件、执行命令、运行测试。这个拆分很关键等于把建议权和操作权分开日常聊天和实际干活各走各的模式互不干扰。此外还有一些底层的性能优化比如会话恢复速度变快、长上下文的处理更稳定。不过这些属于体感层面的优化没有前面三个功能那种改变工作方式的冲击力。2. MCP服务接入实操从配置到调用2.1 先理解MCP的四个角色排查问题全靠它接 MCP 之前我建议先花两分钟弄明白它的架构。整个 MCP 体系里有四个角色Host宿主程序就是 Pi 1.0 本身。它负责维护 AI 模型和用户之间的会话决定什么时候调用工具。Client宿主内部内置的客户端负责和 MCP Server 建立一对一的连接、发送请求、接收结果。注意 Host 和 Client 是一对多的关系一个 Host 内部可以同时跑多个 Client。Server外部工具进程提供标准的工具、资源和提示词。比如文件系统 MCP Server就是专门用来执行文件读写操作的外部程序。Transport传输层负责数据在 Client 和 Server 之间流动。本地服务通常走 stdio标准输入输出远程服务走 HTTP 或 SSE。这个架构不是徒增复杂性。实际排查 MCP 问题的时候90% 的场景都可以定位到这四个角色中的某一个Pi 打不开是 Host 的问题工具列表里看不到某个 MCP 服务是 Client 连接没建立命令启动了但立刻退出是 Server 进程异常能连接但一直超时是 Transport 层出了问题。脑子里有这个模型看到报错信息就不会慌。2.2 找现成的MCP服务优先用官方维护的 reference serversMCP 生态现在已经比较丰富了我建议新手先从官方维护的 reference servers 入手这几个项目在 GitHub 上都是直接能用的质量也稳定filesystem文件系统读写支持指定允许访问的根目录最常用github拉取 issue、PR、文件内容需要配置 GitHub Tokenpostgres连接 PostgreSQL 数据库执行只读或写入查询sqlite本地 SQLite 数据库操作memory知识库持久化可以让 AI 跨会话记忆关键信息fetch抓取网页内容并转成 Markdown 文本这些服务大多通过npx一行命令启动例如文件系统服务只需要执行npx -y modelcontextprotocol/server-filesystem /path/to/allowed/dir。命令里的最后一个参数是允许访问的根目录这个参数很重要它决定了 MCP Server 能读哪些路径配得太宽等于把整个电脑都交给了 AI建议只给当前项目目录。另外社区里还有大量第三方 MCP 服务比如接浏览器自动化、接 Figma、接各种运维平台的。我个人的建议是先玩熟官方服务再按需探索社区的。社区服务质量参差不齐有些几周不维护就失效了别在生产环境里直接上。2.3 在Pi 1.0里配置MCP完整步骤和配置说明Pi 1.0 的 MCP 配置入口有两处一个是在交互界面里用/mcp add斜杠命令添加另一个是直接编辑配置文件。我更推荐用配置文件因为可重复、方便用 git 管理、换机器时可以直接复制。配置文件的位置在 Pi 的数据目录下不同系统路径略有差异。我这边以 macOS 上的测试环境为例配置完成后~/.pi/config.json里长这样{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /Users/me/work/my-project ] }, github: { command: npx, args: [ -y, modelcontextprotocol/server-github ], env: { GITHUB_TOKEN: ghp_你的token } } } }配置字段其实就四个command是启动命令args是传给命令的参数env是进程需要的环境变量cwd是可选的进程工作目录。这里我必须强调环境变量的坑。GitHub 这个 MCP 服务启动时必须要有GITHUB_TOKEN环境变量否则服务进程一启动就报错退出。很多人配完之后发现 Pi 里看不到任何 github 工具八成就是这里出了问题。建议配置完先手动执行一下args里的完整命令确认服务能正常跑起来再回到 Pi 里加载。配置文件保存之后重启 Pi 或者在新会话里执行/mcp list就能看到已经加载的 MCP 服务列表。看到connected状态就说明成功了。2.4 验证MCP服务是否生效用一句话快速确认配好 MCP 之后别急着写复杂任务先用最简单的话验证。我在新会话里通常会问一句你现在可以使用哪些工具请列出来。如果 MCP 服务连接正常Pi 会在回复里提到它检测到可用的 MCP 工具比如read_file、list_directory、write_file等文件系统工具。这时候再下达实际任务成功率会高很多。还有个小技巧给工具指令时明确告诉它要用哪个服务。比如同时挂了文件系统和 GitHub 服务你说读取一下仓库里的 README它可能会先试 GitHub 服务去获取文件内容如果你其实想让它读本地文件最好说用文件系统工具读取当前项目根目录下的 README.md。这样能减少 AI 在多个工具之间做错误的选择省时间也省 token。3. token消耗实测数据出乎意料3.1 三种典型场景的消耗实测我专门用同一个测试仓库跑了三类常见任务记录每一类的 token 消耗。测试用的模型是 Pi 1.0 默认的对话模型仓库代码量大约五千行涉及十几个文件。数据如下场景输入 token输出 token总消耗实测耗时纯问答解释一段函数逻辑812430约 1.2k6 秒带项目上下文修复一个跨文件 bug12,4602,180约 14.6k42 秒启用文件系统 MCP分析日志并出报告8,350 2,940工具返回1,520约 12.8k35 秒看这个表能很明显地感觉出差异纯问答消耗极小带着项目上下文之后消耗直接上一个数量级而启用 MCP 之后输入里多出来的一部分是工具调用返回给模型的内容。我解释一下为什么带项目上下文的输入 token 会飙到一万多。Pi 1.0 在带项目上下文模式下会自动扫描仓库结构、读取关键文件的内容注入到对话里这些被注入的文件内容全部计入输入 token。我这次让它修的 bug 涉及三个文件的交叉调用Pi 为了实现这个任务提前读入了大约十个相关文件光这一步就吃了接近一万个 token。另外要说明的是token 消耗波动非常大取决于模型版本、上下文长度、代码密度和工具返回结果的大小。上面数据只能作为同量级项目的参考基准别当成精确报价。3.2 token到底花在哪拆开看四个部分token 消耗不是铁板一块拆开来看主要是四个来源第一是系统提示词system prompt。这部分每个会话都会消耗Pi 1.0 的系统提示词不算长大约几百个 token但每次请求都会重复计算。这部分是固定开销。第二是对话历史。这是大头。AI 每回答一轮之前所有的问答都会作为上下文重复送入模型。你问得越多、回答越长历史包袱就越重。实测中聊了三十轮之后的会话单次请求的输入 token 能轻松超过五万费用和延迟都蹭蹭往上涨。第三是注入的项目上下文。这部分由 Pi 的自动上下文功能产生。开启后它会根据任务自动挑选仓库文件读入读进来的每一个文件都会按 token 计费。这也是我上一节实测里输入 token飙升的主因。第四是工具返回结果。接入 MCP 后AI 每次调用工具工具返回的数据都会回到对话上下文中。比如分析日志时文件系统服务把整个日志文件读完返回那个两三千 token 的日志内容就全算进输入了。如果工具返回的是几十 MB 的文件内容token 消耗会直接爆炸。理解这四部分之后优化方向就清晰了。3.3 把token费用打下来的几个办法我在实测过程中总结了几条真实有效的省钱经验第一控制注入上下文的范围。Pi 1.0 允许你指定 AI 读取哪些目录。默认情况它会自己判断但判断不一定准经常把无关的node_modules或dist目录也读进去。我在项目根目录放了一个.pi_ignore文件把构建产物、依赖目录和本地方档都排除掉实测输入 token 从一万二降到了七千多效果立竿见影。第二给 MCP 工具设置低消耗调用方式。不是所有工具调用都需要完整的数据。拿文件系统服务为例我会让 AI 先调用list_directory看目录结构再针对具体文件调用read_text_file并且告诉它如果文件超过 200 行只读取前 50 行。这样避免了一次性把大文件整个塞进上下文。第三及时清理对话历史。会话聊长了之后历史 token 远远超过有效信息。我的习惯是每隔一段时间执行一次/compact让 Pi 把之前的对话总结成一段简要摘要替代原始历史。一顿午饭下来几千 token 的长对话能被压到几百 token。代价是会丢失部分细节但通常不重要。第四拆任务而不是堆任务。一个会话里连续让它解决五个问题历史积累会很长拆成五个新会话分别执行每个会话都从干净的上下文开始总 token 消耗反而更低。这和人脑工作类似长时间不停切换任务上下文会有效率损失。第五如果服务商支持启用 prompt caching。部分 API 提供缓存功能重复的提示前缀命中缓存后按折扣价计费能省三分之一到一半的输入费用。Pi 1.0 的 token 界面上会显示命中缓存的量可以据此判断缓存是否生效。4. codemode怎么设置从聊天到干活4.1 codemode和普通对话模式到底差在哪Pi 1.0 把使用模式分成两类普通对话模式和 codemode。这个划分不是故弄玄虚而是对 AI 工具定位的一次认真规划。普通对话模式里AI 只基于已有信息作答。它可以解释代码、写代码片段、回答技术问题但不会主动去改你磁盘上的文件也不会执行命令。它更像一个随身技术顾问说多少做多少绝不越界。codemode 则完全不同。在这个模式下Pi 被授权为智能体agent可以执行一连串操作读取文件、创建文件、编辑代码、运行构建命令、执行测试、根据测试结果继续修。目标是让它独立完成一个从需求到实现的任务而不是给你指方向。我举一个非常直观的例子。普通模式下我说这个函数性能不对劲它会回我一段分析、建议改用某种缓存策略codemode 下我说同样的话它会直接打开对应的源文件、定位函数、加上缓存逻辑、跑一遍现有单元测试、把测试结果反馈给我。前者的产出是建议后者的产出是代码变更。这种差异也决定了权限模型必须更严格。codemode 能执行命令就意味着它能运行你机器上任何命令。如果提示词注入或者配置失误后果不堪设想。所以 Pi 1.0 在每个对话开始的时候都会明确标明当前模式并且在你首次进入 codemode 时要求确认授权范围。4.2 三种设置方式实测命令行、配置文件、对话内切换在 Pi 1.0 里设置 codemode 的方式有几种我全部实测过按使用频率排序方式一对话内斜杠命令切换最灵活进入对话后输入/codePi 会立刻切换到 codemode。当前会话的右上角会显示一个code角标。想切回普通模式输入/chat即可。这种方式适合偶尔用一次的场景。日常我大部分时间都在普通模式下聊天需要实际操作代码时才切到 codemode用完马上切回来避免它带着操作权限执行后续无关对话。方式二启动参数直接进入 codemode适合自动化脚本在终端里启动 Pi 时加一个参数就能新会话直接以 codemode 启动pi --code-mode这个方式适合挂在 CI 脚本或者 shell 别名里。我在自己的测试仓库里就配了一个别名pi-codepi --code-mode这样每次要让它干活的时候直接敲pi-code不用进交互再切换。方式三修改配置文件设为默认模式在~/.pi/config.json里加一行{ defaultMode: code, permissions: { allow: [Read, Edit, RunCommand], deny: [DeleteFile, NetworkConnect] } }配置完成后所有新会话默认走 codemode。我强烈建议不要直接设成默认除非你非常清楚自己在做什么。我最初试过设默认结果一个纯聊天场景它都试图去读写文件很别扭。按需切换才是更顺手的用法。4.3 codemode的适用场景什么时候该用什么时候别用我用了几个星期之后整理出了一份自己的判断清单适合开 codemode 的场景修复明确的 bug尤其跨文件的执行机械重构重命名、提取函数、调整目录结构补测试用例运行测试循环跑测试、看失败、改代码、再跑根据设计文档落地一个完整功能模块不建议开 codemode 的场景纯粹的知识问答、API 用法咨询聊天性质的代码 review刚接手一个还没读懂的代码仓库直接让它动手非常危险需要精确控制每一步的敏感操作场景我的经验是codemode 适合问题已经很清楚、执行路径相对固定的任务。如果是探索性问题先用普通模式聊明白再切到 codemode 执行。这个顺序能极大减少 AI 在错误方向上浪费 token 和操作时间。5. 常见问题排查与避坑实录5.1 登录与Token失效类问题升级到 Pi 1.0 之后我遇到的最典型报错是这种Sign-in could not be completed: token exchange failed: error sending request还有一种是运行到一半提示Your access token could not be refreshed because you have since logged out第一眼容易慌实际上大多是本地状态和新版本不兼容导致的。我的排查顺序如下检查系统时间。token 的签发和验签都依赖时间系统时间偏差超过几分钟JWT 就会验证失败表现为token exchange failed。先对时这是最容易被忽略的。确认网络连接正常。token 换发需要实时请求认证服务网络不稳定就会中断。检查一下路由器、公司出口网络是否正常。重新登录。执行pi logout然后再pi login走一遍完整的认证流程。清除本地认证缓存。执行pi auth clear或手动删除配置目录下的 credential 缓存文件重新认证。新版更新后旧缓存偶尔会有字段缺失导致 refresh token 解析失败。如果以上步骤走完还是报你的访问令牌无法刷新最干脆的做法是删除配置文件里的账号信息完全重新登录一次基本都能解决。5.2 MCP连接失败类问题MCP 相关的报错是这次更新后询问度最高的问题。常见的有这几种现象一配置了但看不到任何 MCP 工具原因大概率是配置文件格式不合法或者服务进程启动失败。先在终端手动执行一遍配置里的command和args如果报错说找不到npx或者命令不存在那需要先安装对应依赖。另外要确认 JSON 文件里没有多余逗号、引号是英文半角。现象二工具列表能看到但调用时报错这种通常是服务进程运行中崩溃了。常见诱因是环境变量缺失比如 GitHub 的GITHUB_TOKEN没传进去也可能是权限问题文件系统服务被拒绝访问某个目录。排查的时候打开 Pi 的日志搜 MCP 相关关键字能看到具体错误堆栈。现象三本地 MCP 都能用远程服务连不上远程 MCP 走 HTTP 协议连接不上先检查能不能访问对应的 URL。如果服务部署在内网还需要确认本地网络是否可达。用curl探一下返回码能省很多排查时间。5.3 实测中踩过的其他坑还有些细节官方文档没写但实操中一定会遇到。坑一配置了 MCP老会话里不生效。MCP 客户端列表是在会话启动时加载的中途加配置对已经打开的会话无效。必须新建会话或者重启 Pi。坑二codemode 里没看权限就放行。首次进入 codemodePi 会弹权限确认很多人随手点了 Allow All。有一次我让它跑测试它顺手执行了一个git reset --hard直接把我一上午的改动全丢了。从那以后我在权限设置里把RunCommand列成默认 deny只有明确需要执行的命令才临时允许。坑三工具返回内容太大token 直接爆表。让文件系统服务读取一个几 MB 的日志文件工具返回的内容会全部计入上下文一次调用吃掉几万 token。解决办法是最开始就给工具加约束比如只读取文件最后 100 行或者只统计包含 ERROR 的行数。坑四多个 MCP 服务同时挂着AI 容易选错工具。比如同时挂了文件系统和 GitHubAI 可能会通过 GitHub 接口读取本地文件路径报错之后才切换工具。显式指定工具名能省掉这个来回纠错的过程。最后再说两句实在的用了这段时间我最深的体会是Pi 1.0 把 MCP、token、codemode 这三件事做到一起本质上是在推动一个转变——AI 从只会给建议变成能自己动手。但能力变强不代表要无脑放权。我现在的工作流是默认普通模式聊天讨论方案确认方向后切换到 codemode 让它落地MCP 权限和命令权限都按最小化原则配置token 消耗定期复盘。这套组合用下来效率提升是很明显的但每次重大变更前我都会先在测试仓库跑一遍。工具趁手的前提是它始终在你的掌控范围之内。