← 返回首页

极简 Coding Agent 的哲学:从 Pi 学到的设计智慧

AI Agent Coding

Mario Zechner(libGDX 作者)写了一篇关于他自己造的极简 coding agent Pi 的长文。这个项目的哲学和技术选择非常有启发性,值得每个做 AI agent 的人认真学习。

原文:What I learned building an opinionated and minimal coding agent

为什么要自己造?

Mario 用了三年 LLM 辅助编码,从 ChatGPT → Copilot → Cursor → Claude Code,最终觉得 Claude Code 变得太臃肿——80% 的功能他用不上,system prompt 和工具定义每次更新都变,破坏工作流。他想要的很简单:完全掌控上下文、完全可观测、极简

架构:四个包解决一切

七个反直觉的设计决策

1. System Prompt < 1000 tokens

对比 Claude Code 上万 token 的 system prompt,Pi 只用了极简指令。结论:前沿模型已被 RL 训练得足够理解 coding agent,不需要冗长的 prompt。在 Terminal-Bench 2.0 上的跑分证明了这一点。

2. 只有 4 个工具

read, write, edit, bash —— 就这四个。模型天生会用它们。Pi 的 system prompt + tool definitions 加起来不到 1000 tokens。对比 Claude Code 的几十个工具定义……

3. 默认 YOLO 模式

没有权限确认,没有安全检查。Mario 的理由很直白:当 agent 能写代码 + 跑代码 + 联网,所有安全措施本质上都是"安全剧场"。大家实际用的时候都在 YOLO 模式,不如直接承认。

4. 不要内置 TODO

内置 TODO 列表只会增加模型的认知负担和出错机会。直接用 TODO.md 文件更好——可见、可控、跨会话持久。

5. 不要 MCP

MCP server 动辄消耗 13-18K token 的上下文(Playwright MCP 21 个工具 13.7K,Chrome DevTools MCP 26 个工具 18K)。替代方案:写 CLI 工具 + README,agent 按需读取,token 成本只在需要时支付。

6. 不要后台 bash

tmux 代替。完全可观测,还能人机共享终端协作调试。

7. 不要 sub-agent

Sub-agent 是黑箱中的黑箱——你看不到它做了什么,上下文传递质量也差。更重要的是:

使用 sub-agent 收集上下文是错误的思路。如果你需要收集上下文,先在独立 session 里做,生成一个 artifact,再在新 session 里用它。

关于上下文工程

Mario 最精辟的观察:

Twitter 上到处都是 context engineering 的帖子和博客,但没有一个现有 harness 真正让你做 context engineering。

他还指出一个被低估的问题:模型被训练成只读文件的一部分而非全文,所以它们会错过重要上下文。这意味着我们太信任 agent 了——看看 Pi 的 issue tracker,很多 AI 生成的 PR 因为缺乏完整理解而被关闭。

Benchmark 结果

在 Terminal-Bench 2.0 上,Pi + Claude Opus 4.5 的成绩排名前列,和那些工具复杂得多的 agent(Codex、Cursor、Windsurf)不相上下。这个结果很有说服力——极简不等于弱

值得注意的是 Terminus 2(Terminal-Bench 团队自己的极简 agent,只给模型一个 tmux session)也表现不错。它没有任何花哨工具,只有原始终端交互。

我的思考

这篇文章最大的启发不是具体的技术选择,而是一种思维方式:先问"真的需要吗?"

很多 agent 框架在做加法——更多工具、更多 prompt、更多功能。但 Pi 证明了减法同样有效,甚至更有效。因为:

这也呼应了我之前写的 简单的力量——在 AI agent 时代,简单依然是最强大的设计原则。