一份"不做清单"，一份"做了清单"

pi 是现在最火的轻量 coding agent 之一：GitHub 12 万星（earendil-works/pi，2026-11-08 的数字），npm 上那个包一周被拉六百多万次——它是 OpenClaw 的底层 agent，这个数里下游占大头。今年 4 月它加入 Earendil，也就是 Flask 作者 Armin Ronacher 创办的公益公司，作者 Mario Zechner 一并成了股东（公告）。

它最出名的不是功能，而是一份明确写出来的"不做清单"：不内置 MCP，不做子 Agent，不弹权限确认，没有 plan mode、内置待办和后台 bash。模型只有 read、bash、edit、write 四个工具，系统提示加四个工具的定义合起来不到 1000 token（作者自述）。

言（Master-Norna/yan）是我一个人做的轻量 Agent。拿那份清单一对照，我发现一件好玩的事：pi 说不的，言几乎都做了——MCP 浏览器、子 Agent、权限确认，外加一个独立的审查模型。

这不是谁更好的问题。两边都叫"轻量"，押的却是两个相反的赌注。这篇把它们摊开来比一比。

两种轻量：套件和成品

同一平台同一格式比，数字都是 2026-11-08 从各自 Releases 量的：pi 1.5.0 的 Windows 包 59 MB，言 1.2.7 的 Windows 包 43 MB。

区别在包里装了什么。言把一份 Node.js 22 运行时一起打了进去——包解开 113 MB，其中 node.exe 就占 89 MB——下载解压双击就跑，不用先装环境。pi 的轻是另一种：核心精简，留给你改。工具、上下文管理、技能、主题、UI 都是可替换组件，用 TypeScript 扩展往上加，社区已经有 awesome-pi-agent 这样的清单可以参考。

言的轻是"替你装好，拆包即用"。模型配置有界面，不用翻配置文件；选好服务商会自动填 URL，粘贴 key 就能用。

一句话：pi 是套件，言是成品。愿意自己拧螺丝的开发者会更喜欢 pi；只想把 Agent 用起来的人，用言能少走很多弯路。

押注：模型够强，还是结构补位

pi 押的是模型够强。它的前提是：前沿模型已经被大量 RL 训练成了会写代码的 Agent，本来就会用 rg、find、gh，不需要冗长的系统提示，多加专用工具只会烧上下文。对 Claude、GPT 这一档的模型，这个判断基本成立。

言押的是结构补位。我平时主要跑本地的开源模型，它不是前沿模型。所以言把任务状态放在对话之外：一张持久化的任务依赖图（DAG）加一本任务账本，记录约束、状态、证据和验证结果。对话可以随时结束、重开，任务一直活着。

工具上言其实也很省：模型只有两个出口，一个终端，一个 MCP（主要是浏览器）。终端覆盖九成任务；浏览器补终端够不着的地方，比如当场看到自己做出来的页面，或者登录账号去读要登录才能看的内容。

上下文压缩：阈值触发，还是语义边界

这是我一个朋友最先吐槽的地方："pi 把上下文强行压到 20k 以内，跑 32k 的本地模型就不行。"查了文档之后，这个说法不准确，但他的体感是对的。

pi 的规则有两条，默认值写在 ~/.pi/agent/settings.json，也能按项目覆盖：

• 什么时候压：上下文超过"窗口 − reserveTokens"时自动触发，reserveTokens 默认 16384。
• 压完留多少：从最新消息往回，原样保留约 keepRecentTokens（默认 20000），更早的交给模型总结成一份摘要。

所以 20k 不是上限，而是"原样留下最近多少"。问题在于，这两个默认值都是绝对 token 数，是按大窗口模型调的。放到 32k 窗口上算一下：

• 触发点：32768 − 16384 = 16384，上下文刚到一半就要压。
• 压完要原样保留 20000，比触发点多 3616。
• 摘要还要再占一段，长度取决于模型的输出上限，窗口越紧越挤。

结果是压完仍然越过触发线：下一次请求一进来就再压一次，而这一次几乎拿不出消息来总结——腾不出空间，只是多花一次摘要的钱。

手动把两个数按窗口调小，或者用 compaction.modelOverrides 给这个模型单设一份，就能修好。但默认配置下，小窗口模型确实跑不顺。

言的做法是把压缩做成一个工具，由模型自己决定什么时候调，通常是一个模块做完的时候。这样有两个好处：切在语义边界上，不会把做到一半的子任务拦腰截断；压缩时机可控，前缀稳定，缓存命中率高。

代价是依赖模型判断。所以言也保留了阈值自动压缩做兜底：平时基本触发不到，模型漏判的时候能接住。语义触发为主、阈值兜底，这是从结构上解决问题，而不是去调一个数。

安全：权限弹窗是"安全表演"吗

pi 作者 Mario Zechner 的立场很鲜明：Agent 只要能读数据、执行代码、联网，权限弹窗就挡不住什么，只是"安全表演"（security theater）。要么接受 YOLO，要么把 Agent 放进容器。pi 默认就是 YOLO：不确认，不预检命令，文件系统和网络全开。

这话我同意一半。对只在本地改代码的 Agent，它很有道理：用户点了一百次"允许"之后，就不会再看了。

但言接了浏览器，情况就变了：它会登录账号、读网页，而网页内容可能夹带 prompt 注入。

有意思的是，这条路 Mario 自己点过名。他提到 Simon Willison 的 dual LLM 模式——让一个看不到原文的模型来做判断，正是为了挡住注入——说 Willison 自己都承认这个解法"挺糟"，还带来极高的实现复杂度。我承认它复杂。差别在于我的用户不会自己去开容器。

所以言没有在"弹窗"和"全放开"之间二选一，而是做了三层：三档权限、一层沙箱，外加一个独立的审查模型。审查模型只看即将执行的动作和你在这个对话里说过的话，不看网页原文，注入的指令传不到它那里。规则拿不准的一步交它照你的原话再判；需要人参与时，也有逐步确认模式和 diff 视图。

这里的分歧来自定位。pi 的用户是开发者，开发者会自己开容器；言要给不熟悉这些的人用，安全不能指望用户自己兜。

子 Agent 与长程任务

pi 不内置子 Agent。Mario 的理由不是"功能少"，是看不见：一个子 Agent 是黑箱里的黑箱，它拿什么上下文、看了哪些文件、错在哪，你都无从查起；上下文交接也由上层模型随手决定。他自己只留了一个例外——代码审查，用 bash 把 pi 再起一个，只看它的输出。

言把子 Agent 当核心能力，而且要把它做成可见的：每个子 Agent 在干什么、读到哪儿，界面上都看得见。它服务的是言最看重的场景：长程任务。我要的是把注意力外包出去，人走开了，任务还在推进。

长程任务靠三样东西撑着：

• 任务图：状态活在对话之外，对话结束了，任务还在。
• 回合末拦截：任务没达标时，模型想收工会被拦下，可以自己唤醒继续推进。
• 可见的子 Agent：分工、交叉验证，像一个小团队，每个在干什么都看得见。

在这类任务里，pi 那套"上下文归你管"的思路很难直接套用：任务比任何一段对话都长，状态必须活在对话之外。

该用哪个

	pi	言
轻在哪儿	核心精简，扩展往上加	运行时打包好，拆包即用
押注	模型够强	结构补位
上下文	阈值触发，两个绝对值可调	语义边界为主，阈值兜底
安全	默认 YOLO，容器自理	三档权限 + 沙箱 + 审查模型
子 Agent	不内置，要就自己起	内置，且可见
适合谁	前沿模型 + 愿意改造工具的开发者	本地或小模型，或需要浏览器与无人值守

同样是轻量，pi 把选择权交给用户，言把选择做好了再交给用户。两种都成立，就看你是哪种人。

言以 Apache-2.0 开源在 GitHub。

参考

• pi 的压缩文档：Compaction Reference
• Mario Zechner：What I learned building an opinionated and minimal coding agent（不做清单、YOLO、dual LLM 的评语都出自这里）
• Earendil：Announcing Pi & Lefos
• Armin Ronacher：Building Pi With Pi
• 压缩功能的设计讨论：pi issue #92