为什么 Pi 选择极简设计

Pi 的设计很反直觉。在很多 coding agent 都在不断增加 MCP、子代理、后台任务、权限系统、复杂工具注册和各种自动化能力时，Pi 反而选择了一个非常小的核心：给模型 bash、文件读写、少量必要工具，再让它自己在项目里工作。

这个选择背后的判断是：模型本身已经知道什么是 coding agent。它知道如何使用 bash，知道如何搜索文件，知道如何运行测试，知道如何用 GitHub CLI 看 issue，也知道如何用 tmux 或 nohup 启动后台进程。既然模型已经能理解这些通用工具，就没有必要把所有能力都包装成专门的 agent 功能。

比如后台 bash。很多工具会内置后台任务能力，但 Mario 更倾向让模型直接使用 tmux。原因是 tmux 是一个成熟、透明、可交互的工具。Agent 可以启动会话，人也可以进去查看和操作。相比内置一个特殊的后台 bash，tmux 更通用，也更符合 Unix 工具哲学。

再比如 MCP。Mario 并不是认为 MCP 协议完全没有价值，而是认为很多 MCP server 的实现质量不稳定，而且会把大量 tool definitions 塞进上下文。一个 GitHub MCP server 可能先消耗几万 token 来描述工具，但模型其实已经会用 GitHub CLI。既然 gh 命令能解决问题，为什么要为了同一件事额外消耗上下文？

所以 Pi 的极简不是功能缺失，而是一种设计取舍：优先保留模型已经擅长使用的通用接口，避免把 harness 做成越来越重的中间层。工具越多，上下文越重，行为越不透明；核心越小，模型和人越容易理解整个系统怎么运转。

Pi 的另一个关键设计是可扩展，而不是预置一切。它不试图定义所有人的工作流，而是允许用户用 prompt template、extension、甚至让 Pi 自己修改 Pi 来适配工作习惯。别人需要 MCP，可以让 Pi 加 MCP 扩展；需要 diff review，可以写一个 review 扩展；需要把上一条回答放进编辑器批注，也可以写一个 comment 扩展。

这让 Pi 更像一个可生长的工具箱，而不是一个封闭产品。很多功能如果只服务于某个人的习惯，就不一定要进入核心。让 Agent 自己写一个几十行的小扩展，反而更快、更灵活，也更不容易把主系统复杂化。

这种设计也体现了 Mario 对 Agent 的基本态度：不要把复杂性藏起来。越是关键的流程，越应该让人看得见。Pi 的极简核心让人知道模型在调用什么工具、读了什么文件、改了什么代码。相比一个功能繁多但行为黑箱的 harness，这种透明性更符合人类主导的工作流。

如果用一句话概括，Pi 选择极简设计，是因为它相信：模型已经足够会用现有工具，真正稀缺的不是更多内置功能，而是更少的隐藏复杂度、更清晰的控制权，以及更容易被用户改造的系统。

相关：AI Coding Agent 的两派：全自动黑箱 vs 人类主导、Agents、Mario 的日常 AI 编程工作流