【译】Pi：OpenClaw 内部的极简 Agent
原文：Pi: The Minimal Agent Within OpenClaw 作者：Armin Ronacher 发布日期：2026 年 1 月 31 日
如果你这周没有与世隔绝，大概率已经注意到：我朋友 Peter 的一个项目在互联网上爆火了。它有过很多名字，最近的名字是 OpenClaw，但如果你是在新闻里看到它，也许会见到 ClawdBot 或 MoltBot 这样的叫法——取决于你是什么时候读到它的。它本质上是一个接到任意通信渠道上的 Agent，而它做的事情非常直接：跑代码。
但你可能不太熟悉的是，OpenClaw 引擎盖下面，藏着一个很小的 coding agent，叫 Pi。而到了现在，Pi 基本已经成了我几乎唯一在用的 coding agent。过去几周里，我越来越像它的免费宣传员。前阵子我刚做过一次相关分享，结果突然意识到：我居然还没在博客里认真写过 Pi。所以这篇文章，我想补上一些背景——为什么我会对它这么上头，以及它和 OpenClaw 到底是什么关系。
Pi 出自 Mario Zechner 之手。和 Peter 那种“带一点疯狂气息的科幻感”不同，Mario 的风格非常务实。尽管两人的气质不同，但 OpenClaw 和 Pi 背后的核心想法其实是一致的：LLM 非常擅长写代码和跑代码，所以你就该顺着这个方向去用它。 某种程度上这也不算巧合——毕竟去年是 Peter 把我和 Mario 一起带进了这个思路，以及 Agent 这个坑。
注：这里提到的 Peter 指的是 OpenClaw 作者 Peter Steinberger。
Pi 是什么？
Pi 是一个 coding agent。而现在市面上的 coding agent 已经非常多了。说实话，到了今天，你几乎随便挑一个现成产品，都能体验到所谓的 Agentic 编程到底是什么感觉。
我之前在博客里评价过 AMP，而且我之所以会对 AMP 有这么强的共鸣，其中一个重要原因就是：它给人的感觉，不是“有人做了个漂亮 UI 再往里塞点 AI”，而是真的是一群已经对 Agentic 编程上瘾、并且亲自试过很多不同路径、知道什么有效什么无效的人做出来的产品。
Pi 对我有意思，主要有两个原因：
- 第一，它的内核极小。它可能是我见过系统提示词最短的 Agent，而且只内置四个工具：Read、Write、Edit、Bash。
- 第二，它用一个扩展系统弥补了这种极简内核的不足，而这个扩展系统还允许扩展把状态持久化进会话里，这一点非常强。
此外还有一个额外加分项：Pi 本身写得就像一款优秀的软件。它不会闪烁，不怎么吃内存，不会莫名其妙坏掉，稳定得很，而且你能明显感觉到，作者对“什么东西应该进软件、什么不应该进”这件事很有分寸。
Pi 同时也是一组小型组件，你可以在它上面搭自己的 Agent。OpenClaw 就是这么做出来的；我自己的 Telegram 小机器人也是这么做的；Mario 还在这套东西之上做了 mom。如果你也想做一个能接到某个外部系统上的 Agent，那么只要把 Pi 指向它自己，再加上 mom，它大概率就能给你现搓一个出来。
Pi 里没有什么
想理解 Pi 里有什么，先理解它没有什么反而更重要——以及为什么没有、更重要的是为什么它今后大概率也不会有。
最明显的缺失当然是对 MCP 的支持。Pi 里没有 MCP。虽然理论上你可以给它做一个扩展来支持，但你也完全可以像 OpenClaw 那样，通过 mcporter 来接 MCP。mcporter 会把 MCP 调用暴露成 CLI 接口或者 TypeScript 绑定，然后你的 Agent 也许就能拿来用。也许不能，谁知道呢 :)
但这并不是偷懒造成的缺失，而是 Pi 的设计哲学使然。Pi 的整个思路就是：如果 Agent 现在还不会某件事，你不是去下载一个扩展、一个 skill，或者某种现成插件；你是让 Agent 自己把这件事学会。它推崇的是“写代码、跑代码”这条路。
这倒不是说你不能下载扩展。Pi 对此完全支持。只是它并不特别鼓励你直接拿别人现成的东西就用；相反，你也可以把 Agent 指向一个已有扩展，对它说：照着那边那个做一个，但按我的喜好改这些地方。
为会造 Agent 的 Agent 而造的 Agent
如果你认真看 Pi，以及更上层的 OpenClaw 在做什么，会发现它们展示的是一种“像泥巴一样可塑”的软件形态。而这对底层架构其实提出了很多要求，也在很多地方反过来约束了系统核心设计。
比如，Pi 底层的 AI SDK 被设计成：一个会话里真的可以混杂来自多个不同模型提供方的消息。它承认一个现实——会话在不同模型提供方之间并没有那么强的可移植性——所以它不会过度依赖那些无法迁移的 provider-specific 特性。
第二点是，除了模型消息之外，它还会在会话文件里维护自定义消息。这些消息既可以让扩展拿来存状态，也可以让系统自己保存某些信息——其中一些完全不会发给 AI，另一些则只会发送其中一部分。
正因为有这套机制，扩展状态也可以持久化到磁盘里，所以 Pi 内建了热重载能力：Agent 可以写代码、重载、测试，然后不断循环，直到你的扩展真的能工作为止。它还自带文档和示例，而且这些文档和示例本身也能被 Agent 用来扩展自己。
更妙的是：Pi 的会话是树状的。你可以在一个会话里分支、跳转。这会带来很多很有意思的工作流，比如你可以开一个 side quest（支线任务）去修一个坏掉的 Agent 工具，而不污染主会话的上下文。等工具修好以后，我再把会话 rewind 回更早的位置，Pi 会顺手把另一条分支上发生过什么总结给我。
这件事很重要。因为如果你看看 MCP 的工作方式，在大多数模型提供方那里，MCP 的工具和任何给 LLM 的工具一样，都必须在会话开始时加载进系统上下文或者工具描述区。这会导致一个问题：你很难，甚至几乎不可能，在不中断完整缓存、也不让 AI 对“为什么同一个工具前后行为不一样”感到困惑的前提下，真正彻底地重载工具能力。
上下文之外的工具
Pi 的扩展可以注册工具，让 LLM 直接调用。我偶尔会觉得这很有用。
举个例子，虽然我一直批评 Beads 的实现方式，但我确实认为：给 Agent 一个待办事项列表，是很有价值的能力。我自己就在本地用一个 Agent 专用 issue tracker，也是我让 Agent 自己做出来的。因为我希望 Agent 也能管理 to-dos，所以在这个场景里，我最终给了它一个工具，而不是一个 CLI。对这个问题的规模来说，这样做比较合适。到目前为止，这也是我唯一一个真正额外塞进上下文里的工具。
但除此之外，我给 Agent 加的大多数东西，要么是 skills，要么是一些 TUI 扩展，用来让“和 Agent 一起工作”这件事对我来说更顺手、更舒服。
除了 slash commands，Pi 的扩展还能直接在终端里渲染自定义 TUI 组件：spinner、progress bar、交互式文件选择器、数据表格、预览面板。这个 TUI 灵活到什么程度？Mario 已经证明过，它甚至可以 在里面跑 Doom。当然，这没什么实用价值，但如果你能在里面跑 Doom，那你显然也能做一个真正有用的 dashboard 或调试界面。
我想拿自己的一些扩展举例，给你一个直观印象：这套东西到底能玩到什么程度。虽然你完全可以原样使用它们，但整个思路其实还是——把 Agent 指向某个现成例子，然后按你的想法尽情 remix。
/answer
我不用 plan mode。我更鼓励 Agent 主动提问，来回多轮交流，把事情说透。但我不喜欢那种“只要给了问题工具，Agent 就开始走结构化问答对话框”的交互方式。我更喜欢 Agent 用自然语言和我说话，中间穿插解释、图示，而不是弹出一个机械化问卷。
问题在于：如果让它直接在正文里提问，场面会变得很乱。所以 /answer 这个扩展会读取 Agent 上一次回复，把里面所有问题提取出来，再格式化成一个更干净的输入框。
/todos
虽然我会批评 Beads 的实现方式，但“给 Agent 一个 to-do list”这件事本身是真的有用。/todos 命令会把 .pi/todos 里的所有 markdown 文件列出来。Agent 和我都可以改它们，而会话还可以 claim 某个任务，把它标记成进行中。
/review
随着越来越多代码开始由 Agent 来写，在把一堆未完成工作直接丢给人类之前，先让另一个 Agent 做一轮 review，其实才是更合理的流程。因为 Pi 的会话是树状的，所以我可以先分出一个新的 review 上下文，拿到 review 结果，再把修复带回主会话。
这个 UI 是照着 Codex 的风格做的，所以它能很方便地审查 commit、diff、未提交改动，甚至远程 PR。提示词也会特别关注我在意的点，因此它能把我真正想被提醒的东西点出来——比如我会要求它特别标出新引入的依赖。
/control
这是一个我还在实验、但并没有日常使用的扩展。它允许一个 Pi agent 给另一个 Pi agent 发送 prompt。它本质上是一个不带复杂 orchestration 的简易 multi-agent 系统，主要适合拿来做实验。
/files
它会列出这个会话里所有被修改过或被引用过的文件。你可以直接在 Finder 里定位它们、在 VS Code 里 diff、快速预览，或者在 prompt 里继续引用它们。shift+ctrl+r 会快速预览最近一次提到的文件——如果 Agent 刚好生成了一个 PDF，这就特别顺手。
当然，别的人也做了扩展：比如 Nico 的 subagent 扩展，以及 interactive-shell，后者允许 Pi 在一个可观察的 TUI 覆层里，自主运行交互式 CLI。
用软件继续制造软件
上面这些，其实都只是“你可以拿 Agent 做什么”的一些例子。真正关键的是：这里大部分东西都不是我亲手写的，而是 Agent 按我的要求做出来的。
我告诉 Pi 去做一个扩展，它就做了。没有 MCP，没有社区 skills，什么都没有。别误会，我自己其实用了很多 skills。但这些 skills 都是我的 clanker 手工打造的，不是从哪下载来的。
比如，我已经把所有浏览器自动化相关的 CLI 或 MCP 都换掉了，改成一个直接使用 CDP 的 skill。并不是因为别的方案不好用，或者设计得差，而只是因为：这样做更自然，也更简单。 Agent 自己维护自己的能力。
我的 Agent 现在已经有相当多 skills，而且有个很重要的原则：没用了我就删。
比如，我曾给它做过一个 skill，让它去读取别的工程师分享出来的 Pi 会话，这对 code review 很有帮助。又比如，我还有一个 skill，专门帮 Agent 生成我想要的 commit message、遵循我想要的 commit 习惯、以及更新 changelog。它们最早是 slash commands，但我最近正在把它们迁移成 skills，看看这种形式是不是一样顺手。
我还给它加过一个 skill，希望它优先用 uv 而不是 pip。除此之外，我甚至还做了一个自定义扩展，专门拦截对 pip 和 python 的调用，然后把它们重定向到 uv。
而像 Pi 这样一个极简 Agent 最让我着迷的地方之一，就是它会逼着你真正活进“让软件继续制造软件”这个理念里。
如果把这件事推到极致，就是：你把 UI 和输出层统统拿掉，只把它接进聊天里。OpenClaw 做的就是这件事。而考虑到它近来的爆炸式增长，我越来越觉得，这大概率会以某种形式成为我们的未来。
