最近把Pi升级到1.0之后，我第一件事就是把MCP配置串起来跑了一遍。这次大更新其实等了好几个月，核心变化集中在三块：原生MCP服务支持、token消耗统计做了重构、新增了codemode这种偏自动化的编码模式。整篇文章我会按这三条主线来写，把我实测过的配置方法、token数据、踩坑记录都摊开说，给准备升级或者已经升级但还在摸索的人一个可以直接照着操作的路子。
1. Pi 1.0 更新概览：这次大改到底改了什么
先说结论：Pi 1.0不是一次小修小补，而是把产品定位从“带AI补全的编辑器”正式拉到了“AI Agent工作台”这个层面。我自己用了大概两周，最大的感受是，以前要折腾很多外部工具才能完成的自动化流程，现在可以在编辑器内部闭环了。
1.1 核心变化拆解
原生MCP服务支持：这是整个1.0里含金量最高的一项。以前想在IDE里对话操作外部数据源，得靠插件或者写脚本桥接，现在配置好MCP server后，AI能直接调用文件系统、数据库、GitHub、浏览器等外部工具，等于给AI装上了“手”和“眼睛”。
token消耗统计重构：旧版的token统计基本是黑盒，用完都不知道花在哪。1.0把token消耗拆到了会话、文件、工具调用三个维度，每次请求都记录了模型输入、输出和工具返回的tokens，方便做成本分析和优化。
新增codemode：这是很多人关心的点。简单理解，它把对话补全模式切换成“代码自动执行模式”，AI能自己改文件、跑命令、读报错并迭代修复，不需要你一条条搬运建议。后面我会详细讲怎么设置。
1.2 它适合谁
如果你平时用Pi做纯补全、写小脚本，这次更新对你有增量但不大；但如果你是拿Pi写项目级代码、经常要在多个文件之间来回改、或者想把AI接入公司内部工具链，那1.0的MCP和codemode基本就是为你准备的。特别是做全栈开发、数据和前后端联调的这一类场景，省下的不光是时间，还有来回切换上下文的精力。
我把这次更新的重点归纳成一句话：从“帮你写代码”变成“替你把活干完”。理解了这句话，后面的所有配置和优化就都顺了。
2. MCP服务接入实测：从零配置到手把手调通
MCP（Model Context Protocol）是一套开放协议，解决的是“模型怎么安全地调用外部工具和数据源”的问题。Pi 1.0新增的是MCP客户端能力，你可以把任意符合协议的MCP server挂进去，AI在对话中就能通过工具调用的方式操作它们。
2.1 MCP到底是什么，为什么现在才火
打个比方，以前的AI只有嘴，能说不能动；MCP就是给AI接上了手。文件系统MCP让AI能查看和修改本地文件，数据库MCP让AI能查表和执行SQL，GitHub MCP让AI能操作issue和PR。这个协议由Anthropic开源，现在各家IDE和大模型工具都在跟进，Pi 1.0接入后最大的价值是生态共享：社区里已有的MCP server，只要协议一致，直接拿来用，不用等官方适配。
2.2 在Pi中配置MCP的完整步骤
Pi 1.0里配置MCP有两种方式：图形界面添加和配置文件导入。我建议用配置文件，因为可以版本化管理，换机器也方便。
先找到配置文件位置：在Pi的配置目录下新建或修改mcp.json，结构类似下面这样：
{ "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/workspace"], "env": {} }, "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_PERSONAL_TOKEN": "ghp_xxxxxxxxxxxx" } }, "sqlite": { "command": "python", "args": ["-m", "mcp_server_sqlite", "--db-path", "./data.db"], "env": {} } } }注意，filesystem这一项最后一个参数是要暴露给AI的目录，务必要控制好权限范围，别把整个根目录都给出去，否则AI误删文件你哭都来不及。我自己的做法是在工作区下建一个~/projects专用目录，只暴露它。
配置完成后，在Pi的MCP管理面板里点击刷新，能看到每个服务的连接状态。这里判断是否成功很简单：如果显示connected，就说明握手成功。然后新建一个会话，输入一条指令让AI调用MCP，比如“用filesystem列出当前目录下的所有Markdown文件”，看AI是否真的执行了工具调用。
2.3 实测过程记录
我分别测了文件系统、SQLite、GitHub三个MCP服务。文件系统是最快见效的，AI能直接读取项目结构，替代了以前老要在对话里粘贴文件路径的做法。
数据库MCP我稍微折腾了一下。第一次启动时因为Python环境缺少依赖直接报错，后来用虚拟环境装好再启动就正常了。实测让AI执行“统计orders表中近30天订单总数”，它自动生成了SQL、执行并把结果返回到了对话里。这个流程如果放在以前，得先自己打开数据库客户端，写完SQL，再把结果复制给AI，现在全部自动完成。
GitHub MCP需要个人访问令牌，建议在GitHub设置里生成fine-grained token并只勾选需要的仓库权限。我踩过一个坑：用了老的repo全权限令牌也能连上，但某次AI在操作Issue时被拒绝，查了半天发现是权限粒度太粗导致GitHub侧校验不通过。换用细粒度令牌之后问题消失。
2.4 配置MCP时的三个常见坑
- npx首次运行很慢：MCP server首次通过npx拉取包要几十秒，Pi会显示连接超时。解决办法是先手动在终端执行一次同样的npx命令，预先把包缓存好，再回Pi里刷新。
- 环境变量拼写错误：GitHub、数据库这类服务经常要靠环境变量传凭证，大小写和Python下划线命名容易写错。我建议配置完先单独用命令行启动MCP server，确认它自己没问题，再挂给Pi。
- 工具返回内容过大：文件系统MCP读取大文件或整目录时，会把大量内容塞回对话里，token消耗直接飙升。遇到这种情况，我会在提示词里明确要求“只读取文件前100行”或“只列出文件名”。
3. token消耗实测：数据说话，钱花在哪一目了然
Token是模型计费的基本单位，这次Pi 1.0把token统计做得更细了，我趁机做了一组实测，用同一段重构任务在三种模式下跑，看消耗差异到底有多大。
3.1 一个token到底怎么算
简单理解，token是模型处理文本的最小单位。英文大概是四五个字符一个token，中文的表现因模型而异，但通常一个汉字约1到1.5个token。注意，对话里发给模型的“输入”和模型生成的“输出”都算token，而且输入里包含历史上下文，所以对话越长，每次请求的基础消耗就越高。
Pi 1.0的统计维度有三个：input_tokens（你发送的提示和历史）、output_tokens（模型回复的内容）、tool_tokens（MCP工具返回给模型的内容）。第三个维度是这次新加的，也是很多人忽略但实际占大头的地方。
3.2 实测场景与数据
我用一个“给支付模块重构错误处理逻辑”的任务做了对比，任务涉及3个文件、约800行代码。结果如下：
| 模式 | 输入tokens | 输出tokens | 工具tokens | 总tokens | 大约花费(按常见模型价估算) |
|---|---|---|---|---|---|
| 普通对话模式 | 18500 | 4200 | 0 | 22700 | 约0.015美元 |
| 对话+手动粘贴文件内容 | 52000 | 5800 | 0 | 57800 | 约0.04美元 |
| codemode（自动读文件+改文件） | 45000 | 7200 | 31000 | 83200 | 约0.06美元 |
| 启用MCP文件工具后的codemode | 38000 | 6800 | 45000 | 89800 | 约0.065美元 |
从数据能明显看出，工具tokens是隐藏的消耗大户。普通人只看input和output会觉得没花多少，但MCP每次读取文件、搜索内容，都会把返回结果计入tokens。另外，手动把整个文件粘贴到对话里是一种极度奢侈的用法，5000多行的文件一粘就是几万token，比codemode自动按需读取还要费钱。
3.3 怎么控制token消耗
我实测后总结了几条经验，按效果排序：
- 限制MCP的暴露范围：在文件系统MCP里只暴露当前工作目录，AI就没法去扫描无关目录，也就不会把无关内容读进来。
- 在提示词里规定读取方式：要求AI先查看文件列表，再按需读取关键文件，而不是一次性读全部。实测这样能省大概30%的tool tokens。
- 控制历史上下文长度：清理不需要的会话上下文，或者在想让AI专注新任务时开新会话，否则旧对话内容每次都会被计费。
- 用codemode的“按需读取”能力：它比手动粘贴文件省得多，因为AI只会读取它认为需要的文件片段，而不是整个文件。
我还发现Pi 1.0的统计面板里可以按文件维度看token，这个功能特别适合排查“哪个大文件在持续烧token”。有一次我明明没让AI看某个日志文件，但总消耗异常高，排查后才发现是旧会话历史里包含了它，清掉会话后消耗立刻降下来。
4. codemode设置详解：从开启到调参
Codemode是这次更新里争议最大的功能。喜欢的人觉得它像雇了一个24小时待命的初级工程师，不喜欢的人觉得它太“自作主张”。我自己的判断是：它是一把好刀，但你要给它划好边界。
4.1 codemode和普通模式的区别
普通对话模式下，AI给你的是一段建议代码，你复制、粘贴、改错，然后手动运行测试。codemode下，AI能自己修改文件、执行shell命令、运行测试并阅读输出，失败后还可以自己修改代码再试。
区别的核心不在“能不能生成代码”，而在“谁在负责执行循环”。普通模式是你在循环，AI只是输出；codemode是AI在循环，你负责审核结果。这个转变对多人协作项目风险尤其大，如果AI改到全局配置文件，你看都不看就合并，后果可想而知。
4.2 怎么开启codemode
Pi 1.0中开启codemode的方法很简单：在编辑器右上角的模式切换器里从“Chat”切到“Code”。但默认设置比较激进，我建议先调整几个关键参数再开工。
在Pi的设置-Codemode一栏里，有几个选项值得改：
- 自动执行命令：默认开启，AI跑测试、安装依赖都会直接执行。建议第一次使用先关掉，观察它到底要跑什么命令，确认没问题再开。
- 自动保存修改文件：默认开启。我强烈建议改成“每次保存前确认”，尤其在有版本管理的项目里，AI会频繁改动文件，手动确认能让你知道它每一步动了什么。
- 允许读取的文件范围：如果你配置了MCP，这里可以指定AI能访问的额外路径。建议和MCP暴露目录保持一致。
- 最大自动迭代次数：指AI在遇到失败后自己重试的最大轮数。默认5，我一般设3，防止它在同一个坑里反复打转烧token。
4.3 codemode的实测工作流
我实际跑过一个完整的任务：修复一个登录接口的鉴权失败问题。流程大致是这样：
- 我给出指令：“分析登录失败问题，修复它，并补充测试”。
- AI先读取了路由文件、鉴权中间件和测试文件（通过MCP）。
- AI定位到token有效期判断逻辑的时区问题，修改了对应文件。
- AI运行了相关测试，第一次失败，它阅读报错后修正了时间比较的格式，再跑，通过。
- AI向我汇报了修改的文件和测试结果。
整个过程大概耗时4分钟，消耗tokens 52000，其中工具tokens占了不少。效率是高，但过程中它在第2步读取了3个文件，如果我对文件系统MCP没有做目录限制，它可能会继续扫更多无关文件，浪费tokens和时间。
4.4 什么时候别用codemode
这是我最想强调的部分。codemode不等于全自动无人值守，至少在1.0版本里它不是。
- 生产环境热修复：别让codemode直接改生产分支的配置。AI对业务上下文的理解有限，改对是运气，改错是常态。
- 大规模重构：涉及几十个文件的重构，AI会因为上下文窗口限制而“顾头不顾尾”，容易在改A文件时破坏B文件的调用逻辑。这种任务应该拆小。
- 涉及权限和合规的脚本：比如操作生产数据库、申请云资源、修改敏感配置，我永远手动来。
5. 常见问题与排查实录：实测中遇到的坑都在这
5.1 MCP连接失败的快速定位
我遇到过三次MCP连接失败，现象都一样：Pi里显示disconnected或者timeout。排查思路如下，按顺序来：
| 现象 | 可能原因 | 排查步骤 |
|---|---|---|
| 首次连接超时 | npx正在拉取依赖包 | 先在终端手动执行npx -y @modelcontextprotocol/server-filesystem，看到“running”字样后再回Pi刷新 |
| 连接上了但工具调用报错 | 环境变量或权限不足 | 单独启动server，在终端里验证身份凭证是否正确 |
| 对话中看不到工具调用结果 | 模型不支持工具调用，或MCP返回格式异常 | 在Pi的日志面板查看原始工具返回；确认使用的模型支持function calling |
我在排查github MCP时反复遇到一种情况：启动成功、连接正常，但AI调用时提示“权限不足”。最后发现是token过期了。GitHub的fine-grained token有默认有效期，过期后连接不会立刻断，但实际请求会失败。看清这个区别，能少走很多弯路。
5.2 token统计对不上最常被忽略的原因
如果你发现Pi的token统计和模型商家的账单对不上，别急着怀疑偷跑。最大的可能是工具tokens被单独计费但你在模型侧看不到明细。MCP工具返回的内容，在Pi这里计入tool_tokens，但模型侧它属于输入token的一部分。所以对比时要把Pi的input_tokens + tool_tokens加起来，再和模型侧输入比较，才对得上。
我还测试过一种情况：某个会话把一个大JSON文件作为附件贴进对话，即使后续对话完全没用到这个内容，每次请求它都会被当成历史上下文重新发送。这种隐藏在“历史上下文”里的消耗，是token总账单虚高的主要来源。清理旧会话是最直接的解决办法。
5.3 codemode误改文件怎么处置
codemode最让人紧张的就是“它一保存，我的代码就变了”。我的应对方案是强制养成用Git分支的习惯：每次要启用codemode做任务，先开一个新的功能分支，让AI在这个分支上随便改；如果改坏了，git checkout一键回退，比在Pi里找历史版本快太多。
如果已经入了坑，比如AI在无确认模式下改了文件，也不要慌。Pi 1.0在codemode的日志面板里记录了每一步文件修改的差异（diff），你能看到具体改了哪几行。先对比diff，决定是保留部分修改还是整体回滚，再决定是否继续给AI下达新指令。务必先读懂diff再让AI继续，否则它会在一个错误的基线上越改越偏。
5.4 避坑技巧速查表
| 模块 | 建议 |
|---|---|
| MCP暴露目录 | 只暴露工作区子目录，别给全盘权限 |
| MCP凭证 | 用细粒度token，设置有效期提醒；过期后连接未必立即断 |
| codemode自动保存 | 初次使用时关掉，改成保存前确认 |
| codemode迭代轮数 | 默认5改为3，遇到死循环及时停 |
| token优化 | 限制工具读取范围；用codemode按需读取代替手动粘贴全文 |
| 项目安全 | 在分支上跑codemode，方便回滚 |
6. 一些通过实测沉淀下来的经验
这一节不列教程，就说几个我自己在实践里摸索出来的体会，按性价比排序。
第一个体会是：MCP的价值不在于“酷”，而在于把重复劳动去掉。以前每次让AI改代码，我得自己先把项目结构、报错信息、相关文件内容一点一点喂给它，那段时间花的tokens其实也不少。现在MCP让AI自己去读，虽然tool tokens增加了，但省下来的对话轮次换算成钱，反而更划算。关键在于控制读取范围，这个前面反复强调了。
第二个体会是关于codemode的定位。不要指望它一次跑通所有任务，而是把它当成一个“能自己动手的实习生”：交代要明确、边界要划清、结果要审核。我在使用中逐渐形成了一套固定的开工模板，每次都会附带三句话：任务背景、允许访问的目录与文件、禁止做的操作（比如不允许修改测试配置、不允许自动安装依赖）。这个模板看着简单，但在防止AI跑偏这件事上效果立竿见影。
最后，关于token消耗，我想说的是：不要只看单价，要看单位价值。同样的任务，普通模式手动粘贴可能花2万token，但消耗了10分钟人工；codemode加上MCP可能花6万token，但人只需要做最终审查。时间成本换算下来，前者未必更便宜。我在小项目上会切回普通模式省token，但在中等规模的重构任务上，直接上codemode，反而综合成本更低。这个取舍每个人情况不一样，建议你拿一个小任务做一次对照测试，心里就有数了。
