从Claude Code到Pi：逃离隐性成本与模型绑定，拥抱开放Agent工作流

1. 先说说我是怎么一点一点被 Claude Code 的隐性成本劝退的

我自己写代码大概有十来年，真正重度使用 AI 编码 Agent 是从 Claude Code 出现之后开始的。最开始那段时间，几乎所有接触过的开发者都会被它的表现震住：一个长 Prompt 下去，它能自己拆任务、改多个文件、跑测试、再把 commit 都写好。这种"它好像真的在替我干活"的错觉，往往能持续一整个小项目的周期。可一旦项目从单模块涨到多模块，从几千行代码涨到几万行甚至更多，问题就会一个接一个地浮出水面。

1.1 三个让我开始动摇的硬伤

第一个硬伤是账单。Claude Code 不是按项目定价的，它按 token 消耗计费，而交互式 Agent 的 token 消耗量远比聊天场景夸张。它每做一步都会把工具调用结果、文件内容片段、上下文摘要重新算进模型窗口。我做过一个中等规模的代码迁移，大概跑了一个半小时，账单数字直接让我往后每次用之前都要犹豫一下。那种感觉不是"贵一点"，而是"它明明在帮我省时间，我却要盯着成本心疼半天"。

第二个硬伤是上下文墙。Claude Code 的上下文窗口虽然不小，但当我把一个大仓库交给它时，它会先做检索和摘要，再把相关文件内容塞进上下文。项目里一旦有大量历史代码、MCP 工具输出、甚至一些无关紧要的旧目录，它就会把宝贵的上下文浪费在无关信息上。最典型的症状是，同一个会话走到后半段，它开始"失去记忆"，要么重新问你已经确认过的方案，要么改到一半忘了最开始定的命名约束。你明明跟它说过"不要动 utils 目录下的历史兼容层"，二十分钟后它仍然会去改动。

第三个硬伤更隐蔽，也是我最终转向另一个 Agent 框架的最大原因：Claude Code 的设计重心是"Anthropic 模型的前端"。它的技能、权限、上下文策略，很大程度都是围绕固定模型调校的。你想换一个更便宜或者更合适的模型？没有那么容易。你想把整个 Agent 工作流脚本化，塞进 CI 里自动执行？它的交互式输出风格会让这件事变得很别扭。越用到后期，越有一种"我租了一套精装修房，但想换家具都很费劲"的感觉。

1.2 压垮我的最后一个场景：复杂重写中途的"流式断档"

真正让我决定动手找替代方案的，是一次后端模块重写。当时项目已经跑到中期，Claude Code 已经连续工作了一个多小时，突然终端里开始反复出现类似 "response stream was malformed" 的报错，输出流中断，它怎么重试都恢复不了。你想继续让它干活，就得从那个断了的地方重新描述上下文，之前它做的决定、中间状态、以及已经改到一半的文件，都得靠我自己回忆并重新喂给它。

那次之后我算了一笔账：我在聊天框里花在"还原上下文"上的时间，已经远远超过了代码修改本身。如果工具只是入口，而模型的输出管理、上下文维护、失败恢复都要我自己负责，那为什么不选一个更开放、更可控的入口？

把这三个问题叠加起来，就会理解为什么越来越多人开始找替代品。不是 Claude 这个模型不好，而是 Claude Code 这层壳开始显得贵、僵硬、不好定制。这时候，一个叫 Pi 的开源 Agent 项目进入了我的视线。

2. Pi 真正的入场逻辑：模型无关的 Agent 工作流，而不是又一个 CLI

很多人第一次看到 Pi 会误以为它只是另一个命令行版 AI 助手。这个理解大方向没错，但差了一个关键层级。Claude Code 解决的是"怎么让一个具体模型更好地写代码"，而 Pi 解决的是"怎么让你的好模型更好地当 Agent"。前者是模型驱动，后者是工作流驱动。

2.1 模型无关是它最大的卖点

Pi 在实际使用中最大的特点是不绑定模型。你可以用自己的 API key 接 Claude 系列模型，可以接各类开源模型，也可以接 DeepSeek 这类性价比很高的服务型模型。对长期用 AI 写代码的人来说，这个自由度意味着两件事。

第一是成本可干预。当某家模型涨价，或者某段时间用量抖动时，我可以不换工具，只换底层模型。这个能力在实际工作中非常实用：探索性任务我用便宜模型，到了需要精细修改的时候再切回更聪明的模型，整套 CLI 工具和技能体系不用跟着变化。

第二是风险隔离。绑定单一模型供应商就像把所有鸡蛋放在同一个篮子里：某天接口波动，某天服务策略调整，某天团队内部只能用某种私有化部署的模型，你都会很难受。Pi 这种模型无关的架构，至少保证换模型时，你的 Agent 习惯、工具配置、项目约定不会被丢掉。

2.2 技能和工具是"平权"的

Claude Code 里也有 skills 的概念，但它整体围绕官方运行时展开。Pi 更接近一种 "harness" 架构，官方提供一整套调度逻辑，技能和工具则以相对松散的插件方式插入。简单说，Claude Code 里的 skill 更像"给特定模型准备的说明书"，而 Pi 里的技能更像"一套可以跨模型复用的行为协议"。

我自己在迁移过程中写了几个非常轻量的技能：一个是把 Todo 文件转换成下一步行动指令，一个是把测试失败日志自动摘要成可提交的 issue，还有一个是统一格式化 commit message。这些东西在 Claude Code 里也能写，但在 Pi 里迁移到任何模型上都不需要重写，体验完全不同。你一旦开始把技能沉淀成和模型无关的东西，后续选模型的空间就会大很多。

2.3 输出协议更稳定，适合脚本化

我日常工作有很大一部分不是交互式聊天，而是让 Agent 在 CI 或者本地脚本里跑固定任务。Claude Code 的优势在于交互式体验，但它的输出有时候是欢迎词，有时候是 markdown，有时候又混着结构化 JSON，抓取起来很费劲。

Pi 的 CLI 在这方面省心很多。它的输出协议相对固定，我可以让日志流直接进入命令管道，也可以设定它只输出机器可读的 JSON，再交给后处理脚本。对做自动化流程的人来说，这才是真正的杀手级特征：它意味着你不只是在跟一个 Agent 交互式聊天，而是真正把 Agent 变成流水线上的一环。

3. 迁移到 Pi 时，我实际做了什么以及踩过的坑

工具切换从来不是下载一个新程序那么简单。我从 Claude Code 正式切到 Pi，前后大概花了两个晚上，主要做了三件事：参数对照、项目约定迁移、模型切换。

3.1 两者完全不在同一层，先做参数对照

先列一个简化的对比表，方便还在观望的人快速建立认知：

表格里有一行很容易被忽略：项目记忆机制。Claude Code 靠读取项目里的说明文件来理解背景，Pi 也有类似机制，但它们的读取优先级和匹配规则不同。你直接把 Claude Code 的说明文件复制过去，不一定会得到同样效果，必须手动检查。

3.2 项目记忆文件的迁移要点

我当时仓库里有一份很长的说明文件，里面写了模块划分、编码规范、禁止改动的文件列表。放到 Pi 里后，我发现默认情况下它并不过度依赖这份文件，反而更偏爱写在项目根目录附近的简短说明。我后来试了两种方案：一是把内容精简后集中放，二是按目录拆分成多个局部规则。

结论是，对于大仓库，分散放比集中放效果好。你一份三百行的说明文件，不如在每个关键模块目录下放一个简短的说明，让 Agent 进入对应目录时按需加载。这是我在迁移中第一个真正有效的调整。另一个经验是，说明文件里命令式语句越短越好，凡是需要模型"理解后执行"的业务细节，都要转成明确的动作清单。

3.3 用 Pi 接 DeepSeek：我的实测记录

提到 Pi 必谈它接其他模型的灵活性。我用 DeepSeek 跑了一个周末，主要验证三件事：代码补全质量、多文件修改一致性、长会话稳定性。

补全质量上，DeepSeek 完全能满足我日常七成左右的编码任务，尤其是常规 CRUD 和脚本编写；到了多文件重构这类需要强一致性理解的场景，模型本身的能力差距就会体现出来，这是模型水平问题，不怪 Pi。长会话稳定性方面，DeepSeek 在 Pi 里的表现比我想象中更稳，可能因为 Pi 的上下文管理会主动裁剪历史消息，避免模型被冗长轮次干扰。

配置过程也比想象中简单。填一个接口地址、一个 API key、一个模型名，然后把默认模型切到新服务上就可以了。整个过程不用重启终端，也不用改任何技能代码。我后来还做了一个小实验：把 Pi 当作一个代码审查员接入本地 CI，push 之后自动让它只读评审差异，以 JSON 输出问题和建议。这套流程在 Claude Code 里做的话，我需要额外处理它的交互输出，但在 Pi 里，一条命令加一个输出格式参数就完成了。

3.4 自动化场景带来的真实收益

我连续跑了小半个月的自动审查流程之后，最大的感受是：它把"人工扫 diff"这一步彻底替代了。以往每次提交代码，我都得在聊天窗口里贴一段 diff，问"有没有问题"，然后再根据回复逐条处理。现在这个动作被固化成了流水线的一部分，不需要我开窗口，不需要我组织语言，只要 CI 跑完，我就能拿到一份结构化的问题清单。

另一个让我很惊喜的场景是多个仓库的统一维护。我以前有七八个仓库都配置过类似的说明文件，在 Claude Code 里要逐个检查配置是否生效。在 Pi 里，我把仓库初始化脚本和技能配置收进了统一的配置文件，改动一次，批量同步。对维护大量项目的人来说，这套能力比单次对话质量的提升更有价值。

4. 替换时最容易翻车的几个细节，全是我真实踩过的

工具迁移最坑人的永远不是主功能，而是边角细节。下面这几个问题，我都在实际替换过程中遇到过。

4.1 工具权限一不小心就给了个大的

Claude Code 里允许按工具白名单设定权限，默认比较谨慎。而 Pi 作为开源框架，如果你在配置里直接允许所有工具执行，Agent 是真的会大胆尝试的。我遇到过它直接改动了一个我没打算改的文件，原因就是我在权限配置里写得太宽。

经验是：先把权限默认设为询问，优先做最小授权。尤其是扩展工具和文件删除类操作，宁可多弹两次确认，也别一开始就全放开。你可以在项目初期用宽松模式跑通流程，确认哪些操作不会误伤，再把具体目录和命令加入白名单。

4.2 MCP 服务不是"导入即用"

我在 Claude Code 里配了一堆 MCP 服务，迁移到 Pi 后，以为配置文件复制过来就行。实际跑的时候才意识到，不同运行时对 MCP 工具的初始化协议差异很大，同一个服务在 Claude Code 里正常，换到 Pi 里就可能出现连接异常或工具找不到。

解决办法没有捷径：逐个服务建立连接测试，记录好每个服务用的什么协议、对应哪个工具名。别指望通配符一把梭。如果你之前也把一堆工具全部塞进 MCP，迁移的时候正好是清理的好时机，只保留真正用得上的一部分，既减少故障面，也给上下文腾出空间。

4.3 长任务恢复时，上下文很容易"秀逗"

Claude Code 的长会话如果断掉，可以用会话恢复继续，整体体验相对成熟。Pi 早期版本在长任务恢复方面没那么顺滑，恢复后可能漏掉关键决策，或者把已经确认过的问题重新拿出来问一遍。

我的建议是，对于超过一个小时的复杂任务，主动拆成多个小阶段，每个阶段结束生成一份简短的"阶段结论"文档，让下一个阶段从结论开始。这样即便工具本身的恢复能力不强，你的工作流结构也能兜住。配合前文提到的 TASK.md 习惯，我基本不再担心对话中断丢状态。

4.4 心态预期：开源不等于免费维护

最后这个坑是心态。很多人一看到"开源"就以为可以完全免费、无成本使用，实际用下来发现，虽然 Pi 本身是免费的，但你仍然要承担配置、学习、排错的时间成本。它迭代节奏快，API 也可能频繁变化，文档偶尔跟不上新版本。这时候唯一靠谱的方法是看源码和提 issue，而不是等一个一步到位的大而全教程。

我自己的对策是，把环境配置、初始化脚本这类内容沉淀成自己的配置文件，每次版本升级之后跑一遍，能省下不少精力。开源项目的好处在于，遇到问题你能扒开看内部实现，但这也意味着维护责任回归到了自己身上。

5. 都换到 Pi 了，我为什么还保留了 Claude Code 的"半个位置"

说了这么多 Pi 的好话，并不代表我会把所有场景一刀切。工具选择本来就不该是二极管思维。

5.1 高难度重构时，我依然偶尔切回

某些高难度的、需要深度理解业务背景的重构任务，Claude Code 在"聪明模型 + 官方调校"的组合下，依然表现得更稳。尤其当模型对代码语义的把握到了关键时刻，那种"一次就能顺下来"的体验，是目前我用开源模型时做不到的。

所以我现在策略是：日常任务和自动化流水线都放在 Pi 上，遇到特别棘手、需要高成本推理的任务，临时切回 Claude Code 做兜底。本质上是用工具组合，而不是用信仰选工具。

5.2 团队如果已经建立了原有协作约定，先别急着折腾

如果你不是个人开发者，而是带团队一起用，我反而建议谨慎迁移。团队协作里最贵的不是工具，是大家的肌肉记忆。如果原来的配置、约定、权限规则已经在团队里跑顺了，强行切换至少要付出两周的适应成本，而收益短期未必能补上。

我观察到真正顺利切换的团队，往往都有一个负责基建的成员在组织迁移，而不是每个人各自为战。个人开发者和对工具掌控欲强的人更容易吃到 Pi 的红利，人一多、流程一重，迁移成本就会迅速放大。

5.3 最适合切到 Pi 的，其实就是这几种人

在我个人看来，以下这类人最值得现在尝试 Pi：

• 个人开发者，尤其是同时用多个模型的人，希望不换工具就能调整成本。
• 需要做 Agent 自动化、CI 集成、批量任务处理的工程师。
• 对模型供应商有戒心，希望保留随时切换自主权的人。
• 喜欢折腾开源工具、能接受高频迭代节奏的技术爱好者。

如果这些情况你占了两条以上，那我的建议是找一个周末，从一个不重要的项目开始迁移，而不是一上来就把所有主项目搬过去。先跑通一个最小闭环，把技能、配置、权限规则固化下来，再扩大到日常项目，整个体验会顺畅很多。

最后再说说我的一个操作习惯：无论在哪个 Agent 工具里，我都会在项目根目录留一份任务清单文件，每完成一个阶段就把决策、文件改动和下一步计划写进去。这个习惯在 Claude Code 里帮我兜底，在 Pi 里则让我更安心。工具换哪个模型、换哪个客户端其实都不重要，真正让你稳定的，是你自己设计好的工作流结构。