Pi 开源编程 Agent：为什么它不内置 MCP、子 Agent 和计划模式
编辑标准与来源政策: 编辑标准, 团队. 内容均链至原始来源，见 方法论.
Last checked: 2026-07-27.
别的编程 Agent 在加功能，Pi 选择做减法
Pi Agent Harness 是一个 MIT 许可证的开源项目，官方仓库是 earendil-works/pi。它把自己定位成 agent harness：可以把 harness 理解为连接大模型、工具和终端界面的运行骨架，而不是一套替团队做完所有决定的平台。
Pi 最有意思的地方，是明确不把 MCP、子 Agent、权限弹窗、计划模式、待办列表和后台 bash 塞进核心。这里的 MCP 指 Model Context Protocol（模型上下文协议）。这些能力不是被宣布为“没用”，而是留给扩展、文件、tmux 或沙箱按需组合。代价也很直接：Pi 默认继承启动它的用户权限，安全隔离要由使用者自己负责。
| Pi 留在核心里的东西 | 主要作用 |
|---|---|
pi-ai |
统一连接 OpenAI、Anthropic、Google 等模型 provider |
pi-agent-core |
Agent 运行循环和核心状态 |
pi-coding-agent |
面向代码任务的命令行入口 |
pi-tui |
终端交互界面 |
图：Pi Agent Harness 官方页面，访问于 2026-07-27。项目身份、核心理念和安装入口以官网及仓库 README 为准。
“不内置”到底意味着什么
许多编程 Agent 会默认带上一整套工作流：先生成计划，再启动多个子 Agent，遇到命令时弹权限确认，还要维护待办和后台进程。Pi 的选择相反。核心尽量小，团队可以用自己的文件约定写计划，用 tmux 管后台任务，用扩展接协议，用 Docker 或其他沙箱做隔离。
这种方式对已经有工程规范的团队很友好。你不必为了接入一个新工具，连权限模型、任务编排和界面习惯一起换掉。但它不适合把“开源”理解成“默认安全”。Pi 进程在默认情况下拥有调用者已有的权限；如果当前用户能读密钥、改主仓库、调用内网，Pi 以及它加载的扩展也可能触及这些资源。
官方列出的隔离选择包括 Gondolin 扩展、普通 Docker 和 OpenShell。它们代表几种可采用的办法，不是 Pi 启动后自动获得的保护层。核心仓库使用 MIT 许可证，团队安装社区扩展时仍要单独检查扩展的代码和许可证。
上线前先做一份扩展清单
Pi 的组合式设计意味着，真正需要审计的对象不只是核心仓库，还包括团队装上的每一个扩展、hook、外部命令和模型 provider。最实用的做法是一页扩展清单：记录来源仓库、锁定版本、许可证、安装脚本、读取目录、可写目录、网络目的地和维护负责人。任何一项为空，都先不要进入长期使用环境。
权限也应该从抽象的“允许执行命令”拆成具体能力。读取源代码、写 fixture、修改主分支、访问 SSH agent、读取云凭据和连接内网不是同一种权限。团队可以先给一次性仓库和只读依赖缓存，再逐项开放；如果扩展升级后权限范围扩大，必须重新审查，而不是沿用旧批准。
这种清单还能解决归因问题。一次成功到底来自 Pi 核心、某个社区扩展、底层模型还是 shell 工具，只有记录组合版本才能复现。否则团队看到的不是一套可维护系统，而是一次碰巧工作的终端会话。
如何开始，而不是先搭一座平台
安装入口是 @earendil-works/pi-coding-agent：
npm install -g @earendil-works/pi-coding-agent
pi
若要从源码核验，可以在隔离环境里运行 npm install --ignore-scripts、npm run build、npm run check 和 ./test.sh。发布文章或写入内部安装文档前，再去 npm 核验精确版本，不要把某次查看到的版本永久写死。
内部 CLI 团队：3 文件、2 个钩子、1 个容器
一个合适的试点不需要连接生产仓库。准备一个一次性 fixture 仓库，只放 3 个测试文件；用 2 个能记录输入输出的钩子观察扩展顺序和失败传播；所有模型建议的命令只在 1 个没有宿主凭据的容器里执行。
团队要看的不是“Pi 能不能写出一段漂亮代码”，而是三个更基础的问题：扩展会不会写出 fixture 目录，钩子是否留下足够日志，失败后能否完整回滚。如果容器能看到宿主密钥、扩展要求运行未审查的生命周期脚本，或者结果来自社区 fork 却被算到 Pi 核心头上，测试就应该停。
这个案例也说明了 Pi 的适用人群。它更像给 CLI 团队的一盒标准零件：自由度高、替换成本低，但组装质量取决于团队自己。如果团队想要开箱即用的审批流和集中治理，Pi 的极简反而会增加前期工作。
Pi 带来的新思路
Pi 不是在证明“功能越少越好”，而是在重新划分核心与外围：模型调用和 Agent 循环留在核心，组织方式、安全隔离和后台任务交给更适合它们的工具。对于厌倦大型 Agent 框架的开发者，这是一条值得测试的开源路线；对于没有容器、日志和扩展审查能力的团队，则应先补齐运行边界，再谈采用。