极简到什么程度

Pi 的内核只有四个工具：

  • Read — 读取文件
  • Write — 写入文件
  • Edit — 编辑文件
  • Bash — 执行命令

没了。系统提示词短到让人怀疑"就这？"，但 Armin Ronacher（Flask 作者）认为这恰恰是正确的设计起点。

扩展系统才是真正的杀手锏

极简内核的代价由扩展系统来补。Pi 的扩展机制有几个值得关注的特性：

  • 扩展可以向会话中持久化状态，不只是一次性调用
  • 支持热重载，Agent 可以自己写扩展、测试、循环迭代
  • 自带文档和示例，供 Agent 自行学习并扩展自身能力

换句话说，Pi 不是让你去下载插件，而是让 Agent 自己写插件。

刻意不做的事：不支持 MCP

这个决策很有意思。Pi 明确不内置 MCP 支持。如果 OpenClaw 需要用到 MCP，会通过 mcporter 这样的 CLI 工具桥接，而不是把 MCP 做进 Agent 内核。

背后的理念是：如果 Agent 还不能做某件事，正确的方式不是下载一个技能包，而是让 Agent 自己写代码来扩展自己。这是"代码写代码"的核心逻辑。

为「Agent 构建 Agent」设计的架构

Pi 的架构有几个关键设计值得独立开发者注意：

跨模型的会话兼容性：Pi 的 AI SDK 允许一个会话包含来自不同模型提供商的消息，不过度绑定任何特定提供商。这在多模型混用越来越普遍的今天非常实用。

会话中的自定义消息：除了模型消息，Pi 维护自定义消息层，用于扩展状态存储、系统维护等不需要发送给 AI（或只部分发送）的信息。

会话是树结构：这个设计很聪明。Pi 的会话支持分支和导航——你可以开一个"支线任务"去修复某个工具，修复后回退到主会话，Pi 会自动总结支线上发生的事情。

这直接解决了一个常见痛点：工具定义通常在会话开始时加载到上下文中，运行中重载很容易破坏缓存或让 AI 对历史调用产生困惑。树结构的会话天然规避了这个问题。

实际的扩展示例

几个内置扩展展示了这套体系的灵活性：

  • /answer — 提取 Agent 回复中的问题，格式化为输入框，避免内联回答的混乱
  • /todos — 基于本地 .pi/todos 目录的 Markdown 待办管理，Agent 和人都可以操作
  • /review — 代码审查，分支到新上下文审查，再将修复带回主会话
  • /control — 让一个 Pi Agent 向另一个发送 prompt，实现简单的多 Agent 协作
  • /files — 列出会话中涉及的所有文件，支持 Finder 打开、VS Code diff、Quick Look 预览

社区还贡献了 subagent 和 interactive-shell 等扩展。关键细节：这些扩展大部分不是手写的，而是让 Agent 按规格自动生成的。

"软件构建软件"的工作方式

Pi 的作者分享了自己的实际使用方式：没有 MCP，没有社区技能，所有技能都是他的 Agent 手工定制的。他会主动丢弃不需要的技能，只保留当前真正用得上的。

几个例子：

  • 用 CDP 技能完全替代了浏览器自动化的 CLI/MCP 方案
  • 自定义 commit message 格式和 changelog 更新行为
  • 拦截 pip/python 调用自动重定向到 uv

这种工作方式的本质是：你在使用的软件，能构建更多软件。对于一人公司的开发者来说，这意味着你的工具链可以随着你的需求持续进化，而不是被固定的插件市场限制住。

Pi 的设计给了一个很好的启示：Agent 的能力上限不取决于它出厂时有多少工具，而取决于它能不能在运行中扩展自己。如果你正在搭建自己的 AI 工作流，不妨思考一下——与其追求"大而全"的工具集，不如给 Agent 一个能自我进化的最小内核。