夜雨聆风当下，AI Agent 框架如过江之鲫，浩浩荡荡。
从开年爆火的 OpenClaw 小龙虾，到后来的 Hermes 爱马仕，再到御三家的 Claude Code、Codex、Antigravity，以及开源社区里的 OpenCode、Pi，包括 DeepSeek 推荐的 Reasonix 等等等等。只要关注 AI 圈，这些 Agent 框架基本每天都会在你眼前晃来晃去。
我自己因为对透明度和可掌控性的要求，一直更加偏爱开源项目。所以对御三家的 Agent 框架，大多只是浅尝辄止，没有作为主力使用。
我用得最久的还是 OpenCode(以下简称 OC)。为了用得更舒服，我甚至专门 Vibe Coding 了一个飞书插件，让自己可以直接在飞书里调用电脑上的 OC。
然而最近，我已经把 OC 完全卸载，全面转向了 Pi。
这倒不是一时上头。OC 确实给过我非常惊艳的体验，我也真情实感地依赖过它。但用得越久，我越清楚自己真正需要的是什么：不是一个什么都替我安排好的 Agent，而是一个稳定、轻量，并且能让我自己掌控的底座。
其中原由，且听我慢慢道来。
初见 OpenCode：确实有种白月光的感觉
刚接触 OC 时，我的第一感觉就是：这个太牛逼了。
帅气的 Logo，多样的主题，再结合自带的 subagent 工作流，给我的感觉就是无敌。简单上手之后，我又安装了 Oh My OpenCode(以下简称 OMO)，然后整个体验直接起飞。
OMO 几乎接管了整套工作流。你只需要扔给它一句需求，它就会自己分析、拆解、执行，中间还会自动触发审计，尽量避免任务半路返回或者直接断联。
那是我第一次有了“AI 替代开发”的感觉。一句话的需求扔进去，它就可以一直跑，最后搭出一个完整可运行的程序。
这种体验只能说太美味了。
自动驾驶很省心，跑偏时也是真的可怕
初见的热情过去之后，一些问题也开始慢慢浮现。
OMO 虽然可以让我彻底解放双手，一行需求直接开跑，但它本身非常慢。
因为 OMO 的提示词和代理工作流很大，从分析需求、扩展需求，到真正开始写代码之前，可能已经把上下文窗口吃掉不少了。再加上提示词实在太多，它时不时还会出现幻觉或者跑偏。
更麻烦的是，它会一直自己跑，不需要停下来问你。
方向对的时候，这当然很爽。但一旦方向错了，就像在高速公路上拐错了匝道。等你反应过来，准备掉头时，它可能已经差出去十万八千里了。
理论上，你当然可以仔细审阅每一步输出。但用过 AI 开发的基本都知道，AI 每次都是一大段一大段地输出，你基本不可能每句话都认真检查。很多时候也就是浅浅带过，只要没有离谱到一眼就能看出来，就会让它继续往下跑。
最后，往往还是要等到实测时才发现问题。
所以 OMO 的自动化程度越高，我反而越不敢彻底放手。它帮我省下了盯过程的时间，但只要跑偏一次，前面省下来的时间很可能又全部赔回去。
真正劝退我的，是更新太快带来的失控
虽然 OC 有这些不足，但它已经可以帮我完成很多任务了。所以在很长一段时间里，它依然是我的主力工具。
至少那时，一切还在可控范围之内。
但是接下来的更新速度，就让我有点始料未及了。
从 1.XX 版本之后，也就是版本号开始进入两位数，OC 的更新变得极其频繁。有时候一周能更新两三次，而每次更新又可能带来各种版本迁移问题和 Bug。
这个是我比较难接受的。
我只能不停回滚到自己认为稳定的版本。但新版本里偏偏又有一些我想用的功能，导致我不得不花大量时间反复安装和测试，从新版本里找出一个相对稳定的版本。这让我着实有些痛苦。（后来还出现过版本号跳脱的问题，官方也一直没有修复到正轨。）
对一个每天都要用的工具来说，少几个功能其实没有那么可怕。真正难受的是你不知道下一次更新之后，原来的工作流还能不能正常运行。慢慢地，我花在版本选择和兼容性测试上的时间越来越多，已经开始超过我愿意承担的范围。
与此同时，OMO 的更新也越来越冗余。前面提到过，它本身的设计就十分庞大，跑一个任务通常要花很多时间。现在整个工作流又变得更重、更慢，最后确实越来越难以忍受。
到这里，我才开始认真考虑换工具。
我为什么最后选择了 Pi
痛苦总会推着你去寻找答案。
随着 OC 越来越难用，我也开始找其他开源方案。例如 Trellis 我也试过，但还是感觉差点意思。后来，我重新看到了 Pi。
一开始我其实不太喜欢它，因为我知道 Pi 是 OpenClaw 的底座，而我本人就不太喜欢 OpenClaw。（我一直觉得 OpenClaw 的设计有点问题。）
但真正了解之后，我才发现 Pi 和 OpenClaw 并不是一回事。Pi 的设计思路，反而非常符合我的理解。
Pi 最核心的设计，就是尽可能减少 Agent 框架本身的复杂度，把具体能力交给插件系统，让用户自己决定要装什么。
它原生只提供 Bash、grep、edit 等基础工具。不原生支持 MCP，也不原生提供 subagent flow。第一次看，这种设计甚至有点“简陋”。
但也正是这种简陋，让 Pi 的内核非常稳定，系统提示词也很少。需要什么能力，再通过插件和 skill 一点点加上去；不需要的东西，就不用一直背在身上。
快，真的会影响专注力
首先就是快。
在原生状态下，Pi 的打开速度和处理速度，是我用过的 Agent 里面最快的一类。
这种快带来的不只是省时间，而是更容易让人进入心流。之前用 OC 时，因为它很慢，我经常等着等着，注意力就跑到别的地方去了。切个网页，回个消息，再回来时，脑子已经不在刚才那个任务上了。
Pi 因为反馈快、交互快，你提出一个要求，很快就能得到结果，然后马上继续调整。整个过程不容易断，人也更容易专注在当下的任务里。
以前我可能会觉得，快几秒慢几秒只是性能区别。真正长期用下来才发现，它会直接影响你的思考节奏。
更小的上下文，也意味着更低的成本
其次是成本。
Databricks 最近做过一项实验，对比了不同 Agent 之间的任务成本。下面几张图分别展示了成本与性能、模型能力分层、Harness 对效率的影响，以及每个任务被重复送入模型的上下文总量。
从不同模型和 Agent 框架的组合来看，Pi 都能便宜 120% 到 320%。
性价比一直是我选择方案时很在意的问题。很多时候，不同方案的区别并不在于能不能完成，而在于为了完成同一件事，分别要付出多少成本。
如果一个框架需要反复携带庞大的系统提示词和上下文，那么每次调用都会更贵。上下文不断膨胀之后，执行过程也更容易受到影响。
Pi 这种轻量架构带来的成本效率，确实让整个工作流更加稳定。
我更看重的，还是掌控感
最后是掌控性，也是我最终留下来的主要原因。
Pi 的插件系统设计得很好，所以官方文档上甚至有这么一句话：“如果你觉得缺了什么，就让你的 AI 帮你实现。”
Pi 非常鼓励用户自己实现工作流插件，当然也有插件社区，可以直接下载别人做好的东西。
我现在很多时候就是这样：有什么想法，直接交给大模型，让它帮我写一个插件。官方在 Agent 可以读取的位置提供了非常详细的文档和示例，模型可以先了解 SDK，再照着现有例子实现具体功能。
这样一来，我不用等官方把功能塞进核心，也不用被某个庞大插件预设好的工作方式接管。我只需要添加自己真正需要的那一部分。
当然，这种自由也是有成本的。你得花时间配置，也得知道自己到底想要什么。但换来的掌控感是完全不同的：装了什么、为什么装、它会做什么，我自己心里大致有数。我更喜欢这种掌控感。
Pi 并不适合所有人
虽然前面说了这么多，但 Pi 也不是完美的。
相比其他 Agent 框架，Pi明显需要更多的配置和上手时间。你需要安装插件、补充 skill，再一点点把工作流调成自己喜欢的样子。没有经过调校的 Pi，未必能马上达到 Claude Code 或 Codex 的平均使用体验。
如果你只是想快速用上 Agent，希望开箱即用，那我可能不会推荐你上来就选 Pi。OC、Claude Code 或 Codex，大概率都会更省心。
但如果你和我一样，需要一个更加可控、更加轻量，也更加容易扩展的 Agent 框架，那么我还是很建议你试试 Pi。它可能会给你一些不一样的体验。
最后：少就是多
我离开 OC，并不是因为它不能完成任务。恰恰相反，它很强，也确实给过我一种接近“AI 替代开发”的感觉。
只是用得越久，我越不愿意为了这种强大的自动化，继续承担越来越高的复杂度、等待时间和维护成本。
Pi 选择了另一种思路。先给你一个足够小的核心，然后把决定权交还给用户。需要什么就加什么，不需要的东西就别塞进来。
现在每天都会冒出新的 Agent 框架、skill 和 MCP，让人目不暇接。我们也很容易下意识地觉得，功能越多，工具就越强。
但对一个需要长期使用的工作流来说，能少带一点东西，可能反而更重要。