Pi 与 opencode 对比——一个产品和一套工具箱，穿着同一身衣服

纸面上，这两个就是同一个工具出现了两次。Pi 和 opencode 都是 MIT 协议、都用 TypeScript 写、都以终端为主、都自带模型、都能一行命令装好。任何把它们并排放的功能对照表，最后都会得到两列几乎一样的勾，而这样的表格没有任何用处。

真正的区别不是某个功能。它写在各自的 README 里，各一句话。

opencode：

OpenCode 内置两个可以用 Tab 键切换的智能体——build（全权限）与 plan（只读，默认拒绝改文件，执行 bash 命令前先征求许可）。

Pi：

Pi 带着足够强的默认配置，但刻意不做子智能体和 plan 模式。你可以让 pi 自己把你要的东西造出来，或者装一个符合你工作流的第三方 pi 包。

这不是路线图上的两个先后项，而是对同一个问题给出的相反答案。两个项目其余的一切，都是从这里长出来的。

一个是产品，一个是工具箱

opencode 长得像产品。它能通过 Homebrew、Scoop、Chocolatey、pacman、AUR、mise、nix 安装，也能 curl 一行脚本装。有 beta 阶段的桌面应用，macOS、Windows、Linux 都有签名版本。README 被翻译成了二十二种语言。它内置智能体、有一个用 @general 调用的子智能体，还有一套写进文档的权限模型。

Pi 长得像工具箱。它是一个 monorepo，各部分本来就是给你分开引用的：

包	单独拿出来是什么
pi-coding-agent	交互式 CLI——多数人说「pi」时指的就是这个
pi-agent-core	智能体运行时：工具调用与状态管理
pi-ai	跨厂商的统一 LLM API
pi-tui	带差分渲染的终端 UI 库

这张表才是它真正的卖点。如果你正在做自己的智能体，想直接用别人写好的厂商抽象层和终端渲染器，pi 把它们当库交给你。opencode 没有这个，因为它压根不打算这么定位。

所以第一个问题不是「哪个更好」，而是：你是在采用一个智能体，还是在造一个？

权限这件事

这是最锋利的实际差异，也是在公司环境里最可能直接定胜负的那一条。

opencode 的 plan 智能体是只读的：默认拒绝修改文件，执行 shell 命令前先问。用 Tab 切过去。它第一次运行就在那儿，这也是很多人敢把 opencode 指向一个陌生仓库的原因。

Pi 完全没有权限系统，而且它自己直说：

Pi 不包含用于限制文件系统、进程、网络或凭证访问的内置权限系统。默认情况下，它以启动它的那个用户和进程的权限运行。

这是一个设计立场，不是疏漏——README 接着给出了三种容器化方案：一个微虚拟机扩展（把 pi 和厂商鉴权留在宿主机，把工具调用路由进 Linux 微虚拟机）、直接用 Docker 把整个进程装进去，以及一个受策略控制的沙箱。

两种答案都站得住，但都不免费：

• opencode 的进程内权限模型很方便，而且像所有进程内权限模型一样，执行约束的和被约束的是同一个程序。它抬高了「误操作」的成本。它不是一道安全边界。
• Pi 的立场是：你要边界，就用一道真的边界。这更诚实，而且在真被执行时严格更强。但实际情况是，相当多的人会直接在宿主机上跑它——那样智能体和你的 SSH 私钥之间就什么都没有。

如果你的环境要求工具本身能拒绝某些操作，opencode 今天做得到，pi 做不到。如果你的开发工作本来就在容器里，pi 的立场对你零成本，而 opencode 的那套也没给你带来什么。

扩展：写代码，还是写配置

Pi 内置的四个工具是 read、write、edit、bash。此外的一切都要你自己加，形式有四种：TypeScript 扩展、skill、提示词模板、主题。把它们打包成一个 Pi Package，通过 npm 或 git 发布。

关键细节在于：扩展是 TypeScript，不是配置。你不是在填别人替你设计好的 schema，而是在对着运行时写代码。这意味着更大的能力和更多的维护量——你先注意到这两个词里的哪一个，基本就说明了你该选哪个工具。

生态是真的存在，不是画饼——光 pi-skills 就有约 2,500 星，此外还有差异审阅、审阅循环、语音转写、Telegram 桥接、会话分享等一批独立发布的包。但要看清楚这些包是谁写的：绝大多数来自维护者自己的账号。这是一个中心很强、但还谈不上宽的年轻生态。

opencode 的扩展路径走的是配置（opencode.json）、插件机制和内置智能体定义。上限更低，下限也更低，但已经踩过你即将踩的路的人多得多。

模型：都不绑定，但不一样

两边都让你自带模型，而这也是原始数字真正拉开差距的一个维度。

opencode 宣称支持 75+ 家厂商，目录经由 AI SDK 取自 Models.dev，另外还留了一个任意 OpenAI 兼容端点的口子。Pi 自己维护一份「按厂商列出的、支持工具调用的模型」清单，目录会自动刷新，覆盖主流托管厂商，外加 Bedrock、Vertex、Azure、Groq、Cerebras、Mistral、DeepSeek 以及 Cloudflare 的两条产品线。

厂商更少、但逐个核过是否支持工具调用，未必就是更差的交易——一个在目录里、却没法稳定调用工具的厂商，对智能体来说本来就不是可用选项。但如果你需要 Ollama、LM Studio、llama.cpp，或者长尾里的某个网关，opencode 列了，pi 没有。

两边都支持用订阅登录而不是 API key：Claude Pro/Max、ChatGPT Plus/Pro、GitHub Copilot。但在把团队工作流建在这上面之前，有一条提醒值得知道。 opencode 自己的文档明确标了出来：

有一些插件可以让你在 OpenCode 里使用 Claude Pro/Max 模型。Anthropic 明确禁止这么做。

Pi 则把 Claude Pro/Max 直接列在支持的订阅登录里，没有同类说明。这是两个项目对同一片灰色地带的呈现方式不同，而不是底层厂商条款本身有什么不同——如果你是在替公司做决定而不是替自己，这种事该直接去问厂商，而不是从 README 里推断。

数字说明什么，不说明什么

以下为 2026-09-08 通过 GitHub API 核对：

	Pi	opencode
仓库	earendil-works/pi	anomalyco/opencode
Star	102,775	205,702
Fork	12,821	26,834
未关闭 issue	156	5,718
首次提交	2025-08-09	2025-04-30
协议	MIT	MIT

其中有两行经常被读错。

未关闭 issue 的差距不是质量信号。 Pi 默认会自动关闭新贡献者提交的 issue 和 PR，维护者每天再去复查那些被关掉的。这个策略在机制上就会产出一个很小的数字。opencode 的 5,718 则是那个体量下一个开放三角分类队列的正常样子。这两列不能相互比较；能看出的只有：两个项目的「接收外部输入」哲学是相反的——而这恰恰又是本文一直在讲的同一个故事。

Star 数衡量的是注意力，不是契合度。 opencode 早开工四个月，分发面也宽得多。数字能诚实告诉你的是：两个都很大，也都在活跃开发——写这篇时 opencode 当天有推送，pi 是前一天——你赌的都不是某个周末项目。

有一件事无论你选哪个都值得单独点出来：pi 把 npm 依赖变更当作需要评审的代码变更来对待。直接依赖锁定到确切版本、设置两天的最小发布年龄以躲开当天爆发的供应链事故、随包发布 shrinkwrap、自己的安装说明里就带 --ignore-scripts、CI 里有定时 npm audit。对一个你马上要授予 shell 权限的工具来说，这不是小事，而且比这个品类里多数智能体做得都多。

怎么选

选 opencode，如果你想装上就开始干活；如果你想要一个不用自己搭的只读模式；如果你需要长尾里的某个厂商；如果桌面应用或非英文界面对你的团队有意义；或者你更愿意走一条已经有几千人走过的路。

选 pi，如果你是在这个智能体之上开发而不只是使用它；如果你想把运行时、厂商层或 TUI 当库用；如果你的工作流本来就在容器里、缺失的权限系统对你零成本；或者你团队遇到工具不称手时的本能是写五十行 TypeScript，而不是提一个 feature request。

两个都不选，如果「工具」和「模型厂商」允许是同一个决定。这两个项目存在的意义就是把这两个决定拆开，而这种拆分要付出配置时间和提示词质量的代价。如果你本来就在付某个订阅、也不需要可迁移性，Claude Code 或 Codex CLI 会更省事、调校也更好。这一页的对比是真实的，但只有在「厂商独立」是硬需求而不是偏好时才值得做。

这篇是怎么写出来的

本文关于行为、协议、打包方式与厂商支持的每一条陈述，都取自项目自己的仓库与文档，而不是取自对它们的二手总结。Star、fork 与 issue 数来自 2026-09-08 的 GitHub API，之后会漂移。

有一处订正值得记下来：不少第三方文章提到 pi 时给的是约 46,000 星、npm 包名 @mariozechner/pi-coding-agent。两者都已过时——当前是 102,775 星，发布的包是 @earendil-works/pi-coding-agent。如果你读到的某篇对比把这两项写错了，那它是从别的对比里拼出来的，不是从源头。

两个工具作者都还没有经过长期实际试用。本文凡是给判断而非陈述事实的地方，依据的是有文档支撑的设计决策，并且已经标明。

本页两张插图都是生成的，不是照片也不是截图。架构图由上文那些事实的结构化规范编译而来，因此它不会多出正文没有的主张；开篇那张只是一个比喻，本身不承载任何主张。