这几天OpenClaw在圈子里刷屏了。它曾用过ClawdBot、MoltBot等名字，核心能力很直接：接入你的聊天渠道，让AI直接写代码、跑代码。
但我更在意的不是OpenClaw本身，而是它背后的底座——Pi（以及它所在的 pi-mono 工具包）。
Pi是由Mario Zechner开发的一个极简coding agent引擎。Armin Ronacher（Flask的创造者）最近专门写了一篇长文来讲他为什么“上瘾”了——Pi是他目前几乎唯一在用的coding agent。
Pi的默认工具只有四个：Read、Write、Edit、Bash。
听起来寒酸，但它把一件事做得极致：让模型在一个可控的闭环里读代码、写代码、改代码、跑起来验证；需要新能力时，不是先把工具列表堆到一百项，而是让AI代理用代码“长出”新能力。
这篇文章我想把三件事讲清楚：
Pi为什么刻意极简。pi-mono那7个包各自负责什么。以及OpenClaw这种“把Agent接到聊天里”的形态，为什么更依赖底层工程约束，而不是华丽的UI。
太长不看版
- Pi的价值不在“功能多”，而在“闭环完整”。 四个工具覆盖开发主路径：读→改→跑→再读
- 极简内核背后是扩展系统。 扩展能把状态写进会话，配合热重载，Agent能自己写扩展、自己迭代
- 会话是树形结构。 你可以分支去修一个坏掉的工具或尝试另一种方案，修好再带回主线
- 不内置MCP，不是偷懒，是哲学。 Pi的理念是：需要新能力？让Agent自己写一个
- OpenClaw之所以能“接到聊天里还可用”，靠的是工程化约束。 默认串行、命令白名单、可回放的会话日志
- 记忆系统越朴素越好维护。 Markdown记事实，JSONL记对话，再叠检索层就够了
先把Pi放回正确的分类里
很多人看到“Pi是一个coding agent”，会下意识把它当成IDE里的某条功能线——补全、重构、生成单测。
Pi不是这样。
Pi更像“引擎”而不是“应用”。 它把Agent的最小可行形态拆到几乎不能再拆：给模型一个工作目录、四个工具、一套会话记录方式、以及一套扩展机制。
Armin在文中特别提到Pi本身的工程质量：不闪烁、不吃内存、不会随机崩溃——它是由一个对软件品质极度在意的人写的。这个评价本身，就是一种很硬的背书。
你可以用Pi的核心组件搭建自己的agent产品。OpenClaw就是这么做的；Armin自己做了一个Telegram bot；Mario则做了一个叫 pi-mom 的Slack bot。换句话说，如果OpenClaw是汽车，Pi就是让它发动的引擎。
pi-mono 的7个包：每个解决一个清晰问题
如果只看名字，pi-mono 很像“又一个agent项目合集”。但拆开看，每个包的边界很干净。
下面这张图展示了它们之间的依赖关系——注意看层级：入口层、运行时、模型抽象、资源配置各自独立，组合方式留给你的产品形态。
各包职责一句话说清：
| 包名 |
一句话 |
pi-ai |
把 OpenAI / Anthropic / Gemini / 本地模型统一成同一种调用方式——LLM的驱动层 |
pi-agent-core |
核心运行时：会话管理、工具调用循环、扩展加载——引擎本体 |
pi-coding-agent |
把上两层封装成交互式CLI——你最可能碰到的入口 |
pi-mom |
Slack bot，把消息委托给coding agent处理 |
pi-tui |
终端UI组件库，灵活到能在里面跑Doom（真的） |
pi-web-ui |
Web端的交互组件 |
pi-pods |
vLLM / GPU pods的部署与管理CLI |
是的，pi-tui 灵活到Mario证明了可以在里面跑Doom[1]。虽然不实用，但如果你能跑Doom，你当然能做一个好用的调试仪表盘。
四个工具，为什么反而更强
写软件这件事，本质上是一个循环：
如果工具系统能稳定覆盖这个循环，剩下的“看起来很高级”的能力，其实很多只是工作流包装。
极简的好处有三个：
上下文更干净。 工具越多，系统提示词越长，模型越容易“误用工具”或把工具当成能力本身。Armin提到Pi拥有他所知最短的系统提示词——这不是巧合。
可审计性更强。 四个工具带来的副作用更可控。当出问题时，你能更清楚地知道Agent做了什么。
逼着你把工程约束前置。 命令白名单、目录隔离、会话持久化、失败回滚——这些才是“能不能长期用”的分水岭。
一个朴素的偏好：先把“跑得通”变成“跑得稳”，再去追求“能跑更多花活”。
真正的关键：扩展不是“加工具”，而是“长能力”
Pi不是“只有四个工具就结束了”。它把可塑性押注在扩展系统上，做对了三点：
1）扩展能把状态写进会话
你可以把“这次任务的配置”“外部系统的映射关系”“上次审查的结论”等，作为扩展状态跟着会话走。不需要每次都重新提示一遍。
2）扩展支持热重载
这意味着一个关键工作方式成立了：
“让Agent维护自己的能力”不再是口号，而是一条可重复的工程路径。
3）Pi自带文档和示例，供Agent参考
这个开源项目仓库里附带了扩展的文档和示例代码。这意味着当你让Agent写一个新扩展时，它不是从零猜测——它能参考现有的实现来“照着做”。
为什么不内置MCP？这不是偷懒
这是关于Pi最容易被误解的一点。Armin在文中说得很明确：这不是一个懒惰的遗漏，这来自于Pi的工作哲学。
Pi的核心理念是：如果你想让Agent做它还不能做的事，不要去下载一个扩展或技能——你让Agent自己写一个。
这并不意味着你不能下载别人的扩展（这完全支持）。但更推荐的做法是：你指着一个已有的扩展，跟Agent说——“照着那个做，但加上这些我想要的改动”。
Armin自己就是这么干的。他用Pi写了一个基于CDP的浏览器自动化skill，完全替代了他之前用的所有浏览器相关的CLI和MCP工具。不是因为那些替代品不好用，而是因为让Agent自己维护自己的功能，太自然了。
如果确实需要MCP，OpenClaw的做法是使用mcporter[2]——一个把MCP调用暴露为CLI接口的工具。够用就行，不需要内置到核心。
树形会话：把试错做成可控的分支
做复杂任务时最怕两件事：
- 想试一个大胆方案，但担心把当前进度弄乱
- 某个工具坏了，不得不在主对话里一边修一边解释，上下文被污染
Pi的会话结构是树形的，协作方式更像Git：
分支里发生的事情可以被总结，再带回主线。Armin提到一个典型场景：在分支里做代码审查（用 /review 扩展），拿到审查结论后，在主线上做修复。
这对coding agent特别关键——开发不是直线任务，更多时候是并行试探和回滚。
实用扩展案例：它们解决的是“工作流”
Armin分享了他日常使用的几个扩展。值得注意的是：这些扩展全部不是他自己手写的，而是他让Pi按照自己的要求写出来的。
| 扩展 |
解决什么问题 |
/answer |
Agent回复里的问题散落各处？提取出来，变成清爽的输入框 |
/todos |
在 .pi/todos 目录维护待办，会话可以认领任务，不会被对话滚动冲掉 |
/review |
展示diff、未提交改动、新增依赖——让“能跑”变成“敢让它跑” |
/files |
列出会话里引用过的文件，支持在Finder/VSCode中打开或对比 |
/control |
让一个Agent给另一个Agent发提示，做轻量的分工实验 |
社区也开始出现第三方扩展：subagent扩展[3]、interactive-shell[4]（让Pi在可观察的TUI覆盖层中自主运行交互式CLI）。
这些扩展的共性是：它们不是在“发明新工具”，而是在让协作更顺滑、让复盘更省力、让错误更早暴露。
OpenClaw这类产品，靠什么从“能跑”变成“能用”
把Agent接入聊天渠道，最大的挑战常常不在模型会不会写代码，而在系统会不会失控。
1）默认串行，显式并行
多智能体/多任务系统里，异步并发最先伤到的是可读性和可调试性：日志交错、状态竞态、问题难复现。
一个更工程化的心智模型：并行是一种需要证明安全的特权，不是默认权利。
有些实现会把每个会话绑定到一个Lane（通道），让命令天然串行排队。日志不交错、竞态被结构性消除、回放/重试都更自然。
2）记忆用文件系统，检索再叠一层
比起复杂的“专用记忆API”，更耐用的路径：
好处是可迁移、可审计、可手工修。如果你被“记忆系统”这四个字吓过，先接受这种土办法：让事实先落地成文件，再谈智能。
3）浏览器自动化：语义快照优于截图
截图对视觉模型自然，但对纯文本模型是负担：体积大、坐标定位难、成本高。
用可访问性树（ARIA）导出的语义快照，页面变成这样：
- button "Sign In" [ref=1]
- textbox "Email" [ref=2]
- textbox "Password" [ref=3]
模型直接引用 ref 做操作。成本低，也更像“读结构化数据”而不是“看图找点”。Armin自己就用Pi写了一个基于CDP的浏览器skill来替代所有截图方案。
4）安全策略：白名单优先，黑名单兜底
当Agent能跑 bash，安全不是可选项。更现实的做法是允许用户配置可执行命令白名单：
{
"agents": {
"main": {
"allowlist": [
{ "pattern": "/usr/bin/jq" },
{ "pattern": "/usr/bin/rg" },
{ "pattern": "/usr/bin/sed" }
]
}
}
}
把“允许执行什么命令”当成配置写出来，不同项目、不同环境可以不同，而不是用提示词去赌模型记得住。
一张表看懂两条路线
| 维度 |
“堆工具/堆技能”路线 |
“极简闭环 + 扩展”路线（Pi） |
| 上手体验 |
一开始更爽，功能列表很长 |
更克制，要先建立工作方式 |
| 长期维护 |
工具治理成本高，越用越复杂 |
先约束边界，再按需生长 |
| 可审计性 |
工具多 → 行为面更大 |
工具面小 → 更容易看清 |
| 定制能力 |
依赖生态质量与兼容性 |
直接用代码定制，贴合任务 |
| 风险控制 |
常靠提示词约束，容易漂 |
配置与工程约束为主 |
| 能力增长 |
下载安装，被动等生态 |
Agent自己写，主动长出来 |
这不是对错题。它更像你在做工程决策时的一个选择：你更愿意为“短期惊艳”付出多少“长期治理成本”。
我怎么判断一个coding agent “能不能长期用”
看模型指标有用，但我更在意三件“土”事，它们决定了你能不能把它放进真实工作流：
1. 出问题时能不能复盘。 有没有完整日志？能不能回放一次会话里做过的改动？能不能快速定位是哪条工具调用把事情带偏了？
2. 变更能不能被审查。 有没有差异视图？有没有“新增依赖提醒”？有没有一个机制让你在合并之前把风险看清楚？
3. 能力能不能被沉淀。 你这次踩过的坑，下一次能不能靠扩展/脚本/测试直接避开？还是又写一遍提示词？
Pi的极简给我的感觉是：它把这些“工程信号”放在了比“功能列表”更前面的位置。
如果你也想做“自己的OpenClaw”
代价与边界：极简不是银弹
Pi这条路线也有明显取舍：
- 它要求你接受“能力由代码长出来”。 对工程师友好，对纯业务使用者可能不够即插即用
- 扩展生态不是一开始就有的。 你会更依赖自己（或团队）维护扩展与工作流
- 文件化记忆会变大、会变乱。 需要配套的整理策略，否则“可审计”会变成“可怕的堆积”
- 它对工程素养有要求。 Armin说得很直接——他的扩展和skill都是让Agent写的，但你得知道要让Agent写什么
所以它更适合两类人：想把Agent当作长期生产工具的人，或者想自己做Agent产品的人。
一句话总结
当别人都在做加法的时候，Pi选择了做减法。而OpenClaw的爆火证明了：真正有力的系统，往往不是什么都有，而是底座足够稳、能力能自己长出来。
正如Armin在文末写的——把软件接到聊天里、让AI直接写代码跑代码，这种形态正在飞速增长。而Pi这种极简但可演化的底座，很可能就是未来的方向之一。如果你想了解更多此类深度技术剖析与实战心得，可以来云栈社区这样的开发者社区交流讨论。
参考
- Armin Ronacher：Pi: The Minimal Agent Within OpenClaw[5]（2026-01-31）
- Pi源码仓库：github.com/badlogic/pi-mono[6]
- Armin的扩展与skills：github.com/mitsuhiko/agent-stuff[7]
- OpenClaw官网：openclaw.ai[8]
引用链接
[1] 跑Doom: https://x.com/badlogicgames/status/2008702661093454039
[2] mcporter: https://github.com/steipete/mcporter
[3] subagent扩展: https://github.com/nicobailon/pi-subagents
[4] interactive-shell: https://www.npmjs.com/package/pi-interactive-shell
[5] Pi: The Minimal Agent Within OpenClaw: https://lucumr.pocoo.org/2026/1/31/pi/
[6] github.com/badlogic/pi-mono: https://github.com/badlogic/pi-mono/
[7] github.com/mitsuhiko/agent-stuff: https://github.com/mitsuhiko/agent-stuff
[8] openclaw.ai: https://openclaw.ai/
发表于 2026-2-11 16:00:56
|
查看: 229|
回复: 0
