← #805

Pi 的极简主义正是它的优势

文章摘要

这是 Earendil（Pi 背后的公司）发布的一篇立场文章，核心论点用一句话概括就是：在 AI 让代码变廉价之后，行业普遍的做法是往编码 harness 里堆更多东西——更大的提示词、更多编排、更多层次、更多复杂度——而 Pi 走了完全相反的路，并且有外部证据表明这条路不仅更干净，还更便宜、更高性能。

Pi 的具体形态是：开箱只有 4 个工具，系统提示词加上工具定义总共不到 1000 token。它的理念是大部分工作用基础能力就能完成，需要更多就自己造。文章用两个外部案例来论证。

案例一：Databricks 的「每任务成本」研究。

Databricks 发布了一份名为《在 Databricks 数百万行代码库上对编码智能体做基准测试》的研究。为了避免外部基准过饱和带来的偏差，他们基于自家工程师日常执行的真实任务自建了基准。结论用他们自己的话说是：「模型被调用时所处的 harness，会极大影响成本和质量」，以及「在很多情况下，像 Pi 这样简单的 harness 在我们的工作负载上表现最好」。文章指出，在搭配 Opus 4.8（xhigh）时，Pi 拿到了最高的整体通过率，同时成本显著低于 Claude Code 和 Codex。

这份研究之所以有说服力，是因为它把模型和 harness 分离开来测量。Databricks 报告说，当他们用相同的思考强度、把同一个模型跑在不同 harness 里时，「每任务成本差异显著（某些情况超过 2 倍），而质量保持不变」。Earendil 把这个特性称为 Pi 的「上下文纪律（context discipline）」，并引用了 Databricks 的具体测量：「Pi 每轮发送的上下文少了约 3 倍。它对上下文的管理更好，保持了更紧凑的工作集，并用更少的运行次数完成任务。」

文章顺势提出了一个更一般的观点：必须考虑端到端的工程经济学，而不只是每 token 的价格——这在模型层面同样成立。他们观察到，跑复杂工作流时用 Haiku 4.5 往往比用 Sonnet 4.6 更贵，尤其是涉及代码执行时，因为智能体需要更多轮次才能成功完成任务。现在这个规律在 harness 层面同样出现了：更强、更贵的模型配上高效的 harness，可能比反过来的组合更便宜。

案例二：Shopify 用 Pi 造出 pi-autoresearch。

Shopify 工程博客中，David Cortés 描述了他如何把 pi-autoresearch 直接作为一个 Pi 扩展造出来——方法就是让 Pi「给 Autoresearch 写个扩展」，Pi 读自己的扩展文档，然后从那里开始搭建新工作流。Autoresearch 是一个用编码智能体做优化的自主循环：你要求一个改动，它跑实验找出什么有效、什么造成了回归；只要目标是可度量的，它就能扔掉回归并持续自我改进。Shopify 报告的成果包括单元测试跑得「快了 300 倍」、React 组件挂载「快了 20%」、多个项目的构建时间下降，甚至连 pnpm 的性能也有改进。

文章强调的重点是：Pi 并不内置这些工具中的任何一个，它只是让你极其容易地造出它们。「与其假定厂商懂你的工作流、试图把天底下所有工具都塞进去，不如 Pi 这样假定你最懂，然后把可扩展性交给你去挥舞和打造。」

为什么是现在？

文章承认，大约一年前还可以论证原生 harness（模型围绕它构建）具有结构性优势，但这个论点已经变弱了。前沿模型现在普遍很擅长理解终端（或类终端）编码环境并在其中行动——Anthropic 最近把 Claude Code 的系统提示词砍掉了 80%，就是一个明确信号。于是问题从「harness 有多原生」转向「它如何处理上下文以避免冗余，并用干净的原语行动」。

最后一个论点关于本地模型：Earendil 认为本地模型发展很快且很有前景，而 Pi 的上下文纪律在这里尤其是资产——本地模型上下文窗口通常更小，prefill 可能很慢，因此保持稳定的提示词前缀至关重要。上下文纪律意味着「除非用户明确要求，否则我们不改变上下文」，从而避免长达一分钟的重新 prefill。

HN 评论精华

这条帖子拿到 548 分、294 条评论，是本期讨论最激烈的一条。真实走向是：Pi 的用户群极其活跃且忠诚，但反对意见同样具体尖锐，而且争论焦点很快从「极简是否更好」漂移到了两个更实际的问题——沙箱安全，以及 XDG 目录规范。

「Pi 是 Emacs / Neovim」这个类比主导了整场讨论

malisper：「试过所有编码 harness 之后，我觉得用 Pi 就跟用 Emacs 一模一样。任何你想造的东西，你都可以让 agent 帮你造，而且有大量现成代码可以参考配置。与此同时，一半代码是有 bug 的，UI 元素会互相重叠，你还会时不时崩溃。如果你愿意投入精力翻过学习曲线、扛过这些问题，它可以是个很棒的工具。」
azuanrb 提出了更流行的版本：「Codex、Claude Code 是 VS Code、JetBrains，Pi 是 Neovim。」MattPerry 论证得更细：Emacs 的特点是塞满了你不知道自己装了的隐藏功能（10 个游戏、邮件客户端、浏览器、RSS 阅读器、摩尔斯电码解码器），而 Pi 什么隐藏功能都不打包；而且 Pi 已经有了 oh-my-pi 这样的「发行版」，对应 LazyVim/AstroVim。
dasil003 给出了本帖最克制的中间立场：他当年选 vim 而非 emacs，正是因为 vim 靠默认配置就是好编辑器；Emacs 的强项是定制，「Pi 相对于开箱即用的 harness 就是这种感觉」。他的结论是：LLM 进步太快，现阶段花时间优化 harness 不是好的时间投资——他刻意保持 harness 中立，「我的目标不是当早期采用者，而是坐享所有这些实验的成果」。

「别折腾工具，去干活」派

CharlieDigital：「结果变成在造 Pi 扩展而不是造实际产品。……你需要多少浏览器扩展？广告拦截器。别的基本不需要，因为浏览器已经把重要的活干了。」impulser_ 的反驳是「未来本质上就是为智能体造扩展，智能体会成为新的浏览器，扩展会成为新的应用」，同时补了一句关键的：「用 Pi 你不需要任何扩展，不装扩展也能走很远。」
hakunin 贡献了本帖最实用的一条经验，直接反驳「你就让 Pi 给你写个扩展」这种轻描淡写：「拿到一个扩展很容易，拿到一个真正好用、确实有帮助的扩展很难。」他的建议是：先在原味配置上开始干活，随着需要慢慢做小幅增强，做好精修的准备，最重要的是做好回滚的准备——他自己回滚了一堆。他还点破了「batteries included」的问题所在：「很多『内置电池』来自投机性的、半成品的想法，出自那些在他们旅程某个阶段对某件事很兴奋的人。实践中这些想法可能带不来预期效果，而它们的创造者可能早就转身走了。」他举了个具体例子：很多自动记忆系统并不好用——他自己写了个小扩展，在记东西前先问他一句，结果他接受的建议不到 5%，其余大多是会污染上下文的一次性废话。
hakunin 关于子智能体（subagent）的观察也很值得记：他从 OpenCode 带子智能体切到 Pi 后完全不用子智能体，「没注意到上下文消耗有明显变化，任务反而完成得更快」。他的猜测是交接边界才是问题：主模型把孤立任务交给子智能体后，后者会「放飞自我，生成一份面面俱到的报告，试图满足所有可能性」；没有交接时主模型做得精确保守得多，只检查特定的窄问题，并且更早停下。他反问对方：「你确定你看到的是产出／耗时的真实改善，还是看到子智能体做了一大堆事，然后假定主模型也会以更高成本做同样的事？」
theshrike79 给出了相反的成功做法：根级 CLAUDE.md 里基本只写「相关时使用更低层级的智能体」，然后日常用 Opus，它会基于自己的推理把简单活自动卸载给 Sonnet 甚至 Haiku——「Opus 为 Sonnet 写出精确的实现计划然后等它完成，之后检查成果并自己修问题」。

沙箱与安全：本帖第一个真正的痛点

Onavo：「Pi 最大的问题是没有配合自动批准的正经沙箱。大多数方案是第三方且半成品。你只能在『纯自动批准（无沙箱）』和『Claude/Codex 式沙箱但手动批准』之间二选一。」
josh_p 的辩护是「这是设计使然，Pi 假定你是高级用户」，这句话引来了本帖最有力的反击。imtringued：「这是反过来的。如果你是高级用户，你想要的是对授予智能体的所有工具有完全控制权，而不是让智能体用 bash 绕过它们。恰恰是那些不想定制任何东西的人才不在乎智能体在沙箱里乱跑。想想为什么需要沙箱：因为你的权限设得太松了。如果智能体只被允许读文件和跑 cargo test，你压根不需要沙箱——智能体本身就是沙箱。」BoiledCabbage 更直白：「高级用户不想要沙箱和安全？你对高级用户的理解也太离谱了。」
imtringued 顺势否定了文章的标题命题：「pi.dev 不是一个极简编码智能体。它已经烘焙进了大量预设。比如它内置了一个你无法禁用的 bash 工具。这不是极简，这是全套厨房水槽。……我完全不同意这个标题。它对我来说已经太臃肿了。它还不够极简。」（la_fayette 指出可以用 --tools 标志禁用 bash 工具。）
实践派给出了各自的解法：pavo-etc 和 myaccountonhn 都是「给 Pi 单独开一个 Unix 用户账号，靠权限隔离」；thehours 用 Anthropic 的 sandbox-runtime（srt pi）拿到文件系统和网络隔离；frogperson 和 mark_l_watson 分别推荐 nono.sh 和 pi-sandbox；spudlyo 走的是最激进的路线——把开发工作站当牲畜养，一键把一台纯净的 Ubuntu 装成他的开发环境，「如果 YOLO 模式哪天毁了我的工作站（目前还没），我直接把它从轨道上炸掉再起一台」。
sejje 提供了一个具体的翻车案例：「我读完这个帖子决定试试 Pi，第一个请求它就跑出了启动目录，去改了一个兄弟目录里另一个 git 项目的代码。opencode 从来没这么干过。」

XDG 目录规范：本帖第二个、也是更情绪化的痛点

paldepind2 是全帖最有分量的反对票：「这个帖子里全是对 Pi 的赞美，那我提个不同意见。考虑到这些炒作，我对 Pi 有点失望。……一个号称极简的程序，启动却慢得离谱；标准的 C-p 和 C-n 键位不起作用；它不遵循 XDG Base Directory Specification，直接污染我的 $HOME 目录。」他认为还有空间给另一个 harness：开源、用快速编译型语言（Rust/Go）写、用简单的（非 JS）脚本语言可编程、少一些固执己见。
the_mitsuhiko（Pi 团队成员）亲自下场回应，态度非常明确：「XDG 规范的问题在于它现在强迫你在不同平台上有不同路径。这只增加复杂度，而且到头来除非所有软件都遵守，你的 HOME 照样是脏的。（免责声明：我在 Pi 工作，但我在所有场合都不喜欢 XDG。）」——这条回复被大量反驳。oblio：「平台标准本来就要求不同位置，比如 Windows 的 %APPDATA%。一个做智能体 harness 的人居然懒得花 5 分钟研究一下这个，还持有如此僵化且缺乏了解的观点，我觉得挺震惊的。」deadbunny 补刀：「我在 Pi 仓库提过这个 bug，立刻被标成 wont do。」
deadbunny 也给出了 XDG 阵营最有说服力的理由——备份：「程序正确遵循规范，我就能直接 rsync ~/.config/foo 或者扔进仓库，不用操心。不遵循的话，我现在得为每个程序写 rsync 过滤器／自定义 .gitignore 来避免备份 state 和 cache。再乘上几十个不愿意写 12 行代码来判断正确路径的懒开发者。」
intothemild 提供了最平衡的视角，他既是重度用户也是批评者：「我真的非常喜欢 Pi。但我同意你的看法，它最大的弱点是很长一段时间里它的标语是『harness 有很多，这一个是我的』（指 Mario 的）。……哪怕新东家把标语从 MINE 改成了 YOURS，它依然非常是 Mario 的。我喜欢有主见的东西，真的。但我也认为标准之所以存在是有原因的。」尽管如此，Pi 仍是他的日常主力，他围绕它建了一整套通过共享总线互通的插件生态。

其他值得记录的具体经验

pavo-etc 分享了本帖最有想象力的用法：在服务器上以 headless 模式跑 Pi 并用 XMPP 客户端包起来，于是任何能上 XMPP 的地方都能跟它对话，智能体之间也能互相通信。他在 NixOS 上以各自独立的用户账号并行跑多个具名 Pi 实例，「它们可以在临时 shell 里装任何东西，我永远不用担心它们的环境」；智能体共享一个 wiki（其实就是一个用 [[wikilink]] 风格链接的 md 文件 git 仓库）并把 GitHub issue 当 todo list。他强调 NixOS 是这一切的关键——智能体能看到整个服务器配置、做改动、在真正部署前跑编译期检查，搞砸了也总能回滚。他的 Pi 本身「非常原味」，只有自写的 XMPP 包装和 pi-subagents。
timwis 点名了一个被低估的功能：「/tree 功能对上下文管理来说太强了。其他 harness 居然还没抄过去，挺意外的。它让你倒回到任何之前的消息并从那里 fork 出对话，把你的『支线任务』（比如你去深挖 agent 说的某件事）从上下文里移除。有些 harness 有 rewind，但这个能让你把之前的对话历史保留在一个独立线程里，甚至在它们之间跳来跳去。」
Szpadel 给出了 Pi 上下文管理的技术细节：「压缩不压整个上下文，而是原样保留最后约 20k token，我认为这对模型搞清楚自己当下在干什么帮助很大。」它还有软／硬压缩阈值，尽量在回合边界压缩，组合起来大约多出 35% 可用上下文。他还吐槽了 Codex 的对照问题：跑 shell 命令时输出拉取有 30 秒硬上限，跑编译就是白烧 token——「有些任务智能体要跑一个多小时的测试套件，Codex 每小时烧掉大约 20 美元，就为了每 30 秒推理一次『嗯，还在跑』」。
alfiedotwtf 报告了一个具体的失败模式：自动压缩在他这里每次都失败——在一个接近自动压缩阈值的多工具调用回合里，它要么一路跑到上下文溢出 OOM，要么自己打断自己去压缩但丢掉上下文。他从 GitHub issue 里推断原因是 Pi 不让扩展作者（和内置压缩器）在每次工具调用之间挂钩，唯一能检查的时机是请求结束、即将等待下一个 prompt 时——那时已经太晚了。
carlsborg 提出了对文章论据的一个直接质疑：「他们为 Claude 5 系模型砍掉了 Claude Code 大约 80% 的系统提示词，所以这个 harness 每任务成本基准可能已经过时了。」
grewil2 问了一个所有人都关心的钱的问题：Pi 用户都是在付 API 费用，还是能结合订阅？danslo 说两家都能用订阅但 Anthropic 那边违反 TOS；colinmarc 说他一直用 Anthropic 订阅跑 Pi、以为迟早会被按 API 计费但一直没有——然后在几小时后追加了一条：「……好笑的是，发完这条评论几小时后，它就不能用了。」
rcarmo 在多处提出了一个与主流认知相反的论断：「我在 pi/piclaw 里同时用两个模型家族，我可以保证它们在那个环境里比在原生环境里工作得更好。模型不是被训练来适配 harness 的，是 harness 提供了模型会跟随的线索。」
帖子里还冒出了一大批「更小的替代品」：tosh 的 smol（约 20 行 Go、只用标准库、无 MCP／无 AGENTS.md／无系统提示词），并引发了本帖最好笑的一段——imtringued fork 了 smol，然后连发四条编辑自我拆解：「读完我的 fork 我意识到它其实就是把所有东西喂给 bash，完全没意义」→「我搞不清这到底是我见过的最好的编码智能体讽刺作品而我刚把它毁了，还是有人真的认真考虑发布这玩意儿这件事本身很恐怖」。他随后引申出一个真问题：「不如别装了，把编码 harness 的本质暴露出来吧——难以理解的 bash 执行器，有失控的潜力。」

</content>