Claude Code、OpenCode 要减肥了

在 Claude Code、Cursor、Windsurf 疯狂堆功能的时代，一个叫 pi 的终端编码 Agent 反其道而行之：不支持 MCP、不支持子代理、不支持计划模式、不需要权限弹窗。结果？它在 Terminal-Bench 2.0 上打败了几乎所有竞争对手

Ollama 再次升级，原生命令增加了对 Pi 的支持，一键启动并免配置使用 Kimi-K2.5 云端模型

然后好奇安装这个与 Claude Code、OpenCode 有完全不同设计哲学的 Agent 工具，也介绍给大家

核心哲学：Primitives, Not Features

pi 的核心理念可以用一句话概括：给你原语（primitives），而不是预烹饪好的功能（features）

其他编码 Agent 做加法

Claude Code、Cursor 等工具的迭代路径是不断添加内置功能：

• ✅ 内置子代理（Sub-agents）
• ✅ 内置计划模式（Plan Mode）
• ✅ 内置 MCP 支持
• ✅ 内置权限审批弹窗
• ✅ 内置后台 Bash
• ✅ 内置 TODO 管理

pi 选择做减法

pi 的做法完全相反——它把这些功能全部拿掉，但留下了一套足够强大的扩展机制：

1000 Token 的极简系统提示词

在整个编码 Agent 赛道中，pi 的系统提示词可能是最短的。

对比一下：

• Claude Code 的系统提示词：数万 Token[1]，包含详细的工具使用指南、安全规则、输出格式要求等
• OpenAI Codex 的系统提示词：相对精简但仍然很长
• opencode 的系统提示词：基本照抄了 Claude Code

而 pi 的系统提示词 + 工具定义加起来不到 1000 Token。

它的系统提示词核心内容就是：

You are an expert coding assistant. You help users with 
coding tasks by reading files, executing commands, editing 
code, and writing new files.

Available tools:
- read: Read file contents
- bash: Execute bash commands
- edit: Make surgical edits to files
- write: Create or overwrite files

为什么这能行得通？Mario 的解释是：当今的前沿模型已经被 RL 训练得足够好了，它们本身就理解编码 Agent 是什么、该怎么做。不需要 10000 Token 的长篇大论来教它们工作。

只有 4 个工具：read、write、edit、bash——这就是一个完整编码 Agent 所需要的全部。

为什么不要 MCP？

这可能是 pi 最具争议的设计决策

Mario 专门写了一篇博文[2]来解释为什么 pi 不支持 MCP。核心论点是：

MCP 的上下文开销太大

• Playwright MCP：21 个工具，13,700 Token
• Chrome DevTools MCP：26 个工具，18,000 Token

每次会话开始，还没干活就先占掉 7-9% 的上下文窗口

而且大部分工具在当前会话中根本用不到

pi 的替代方案：CLI 工具 + README

pi 用一种更简单的方式来替代 MCP：

1. 把功能包装成 CLI 工具
2. 每个工具附带一个 README.md
3. Agent 在需要时才读取 README（渐进式披露）
4. 通过 bash 调用 CLI 工具

这种方式的好处：

• 按需加载：只在需要时付出 Token 成本
• 可组合：可以用管道串联命令
• 易扩展：添加一个新脚本就行
• Token 高效：不用的工具不占上下文

Mario 维护了一个工具集合 github.com/badlogic/agent-tools[3]——每个都是简单的 CLI 工具，Agent 按需读取 README 后直接调用。

YOLO By Default：关于"安全性"的坦诚

pi 默认以 完全 YOLO 模式 运行——不限制文件系统访问、不检查 bash 命令、没有权限弹窗。

Mario 对此的态度非常坦诚：

"如果你的 Agent 能写代码、能运行代码，那基本上就 game over 了。其他编码 Agent 的安全措施大多是安全剧场（security theater）。"

他引用了 Simon Willison 关于双 LLM 模式[4]的讨论——即使是这个方案，其作者也承认"这个解决方案相当糟糕"。

核心问题是：如果一个 LLM 既能读取私密数据、又能执行代码、还能访问网络，你就是在玩"打地鼠"游戏——堵住一个攻击向量，还有无数个在等着。

既然大家用 Claude Code 时也都在 --dangerously-skip-permissions 模式下工作，那为什么不把 YOLO 直接作为默认选项呢？

如果你真的介意，pi 的建议是：在容器里运行它。

15+ 提供商，数百个模型

pi 的另一个亮点是其多模型支持：

• Anthropic、OpenAI、Google
• Azure、AWS Bedrock
• Mistral、Groq、Cerebras、xAI
• Hugging Face、Kimi For Coding、MiniMax
• OpenRouter、Ollama
• ……还在持续增加

更酷的是，你可以在会话中途切换模型：

• /model 或 Ctrl+L 打开模型选择器
• Ctrl+P 在收藏模型间循环

pi 背后的统一 LLM API（pi-ai）抹平了四种主要 API 的差异：

1. OpenAI Completions API
2. OpenAI Responses API
3. Anthropic Messages API
4. Google Generative AI API

Mario 还特别吐槽了各提供商在 API 实现上的各种"奇妙差异"：

• Cerebras、xAI、Mistral 不支持 store 字段
• Mistral 用 max_tokens 而不是 max_completion_tokens
• 不同提供商在不同字段返回推理链内容
• Google 至今不支持工具调用流式传输……

树形结构的会话历史

tree view

tree view

pi 的会话管理也很独特——它使用树形结构而不是线性的聊天历史

• 用 /tree 命令可以可视化所有分支
• 可以导航到任意历史节点继续对话
• 所有分支存储在单个文件中
• 支持书签标记
• /export 导出为 HTML
• /share 上传到 GitHub Gist，生成可分享链接

你可以在同一个会话中探索多条路径，而不会丢失之前的上下文

扩展系统：用 TypeScript 构建一切

doom extension

doom extension

pi 的扩展系统可能是它最强大的特性

Extension 是 TypeScript 模块，可以访问：

• 工具（Tools）
• 命令（Commands）
• 键盘快捷键
• 事件系统
• 完整的 TUI

你能用 Extension 做什么？

• 自定义子代理[5]
• 计划模式[6]
• 权限门控[7]
• 路径保护[8]
• SSH 远程执行[9]
• 沙箱化[10]
• 甚至……在终端里跑 Doom[11]！🎮

仓库里有 50+ 扩展示例，从实用到疯狂应有尽有。

扩展还可以通过 pi packages 打包分发：

$ pi install npm:@foo/pi-tools
$ pi install git:github.com/badlogic/pi-doom

支持版本锁定（@1.2.3）、批量更新（pi update）、无安装测试（pi -e git:...）

四种运行模式

pi 提供了四种灵活的运行模式：

1. 交互模式：完整的 TUI 体验
2. Print/JSON 模式：pi -p "query" 用于脚本集成，--mode json 输出事件流
3. RPC 模式：通过 stdin/stdout 的 JSON 协议，用于非 Node.js 集成
4. SDK 模式：将 pi 嵌入到你的应用中

clawdbot[12] 是一个使用 SDK 模式的实际案例——一个基于 pi 构建的 Slack 机器人

Benchmark 结果：极简也能赢

terminal bench results

terminal bench results

说了这么多哲学，有没有实际数据来证明？有的。

Mario 在 Terminal-Bench 2.0[13] 上用 Claude Opus 4.5 跑了完整测试（每个任务 5 次），与 Codex、Cursor、Windsurf 等工具正面对决。

leaderboard results

leaderboard results

值得注意的另一个发现：Terminal-Bench 团队自己的最小化 Agent Terminus 2 也在排行榜上表现不俗。Terminus 2 甚至更极端——它只给模型一个 tmux 会话，没有任何花哨的工具，模型通过发送文本命令到 tmux 并自己解析终端输出来工作。

这进一步印证了一个观点：极简方案可以做得和复杂方案一样好。

上下文工程：真正把控制权交给用户

pi 提出了一个很有趣的概念：真正的上下文工程（Context Engineering）。

Twitter 上到处是关于上下文工程的帖子和博客，但 Mario 认为现有的工具实际上都不让你做真正的上下文工程。pi 的设计让你能控制进入上下文窗口的每一部分：

• AGENTS.md：项目指令文件，从 ~/.pi/agent/ 到当前目录层层加载
• SYSTEM.md：替换或追加默认系统提示词
• 压缩（Compaction）：自动总结旧消息，且完全可自定义——通过 Extension 实现基于主题的压缩、代码感知的总结，或使用不同的总结模型
• Skills：按需加载的能力包，包含指令和工具，渐进式披露而不会撑爆上下文
• 提示词模板：以 Markdown 文件形式的可复用提示词，输入 /name 即可展开
• 动态上下文：Extension 可以在每轮对话前注入消息、过滤历史、实现 RAG 或构建长期记忆

运行时的交互控制

pi 还有一个很贴心的运行时交互设计：

• Enter：发送转向消息——在当前工具调用完成后立即送达，打断剩余工具执行
• Alt+Enter：发送后续消息——等 Agent 完全完成当前任务后再送达

这意味着你可以在 Agent 工作时实时调整方向，而不需要等它跑完整个流程。

为什么自己造轮子？

可能有人会问：为什么不用 Vercel AI SDK 之类的现成方案？

Mario 引用了 Armin Ronacher（Flask 的创造者）的一篇博文[14]来回答：

直接在提供商 SDK 之上构建给了我完全的控制权，让我可以按照自己想要的方式设计 API，并且保持更小的表面积。

pi-ai（pi 的统一 LLM API）已经在7 个不同的生产项目中使用，并且表现极好。它还支持：

• 完整的请求中止（abort）支持，包括工具调用
• 部分结果返回
• 浏览器环境运行（感谢 Anthropic 和 xAI 的 CORS 支持）
• 类型安全的模型定义

安装和上手

上手非常简单：

$ npm install -g @mariozechner/pi-coding-agent

然后在项目目录下运行 pi 即可开始交互。

参考资料

[1]

数万 Token: https://cchistory.mariozechner.at

[2]

一篇博文: https://mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp/

[3]

github.com/badlogic/agent-tools: https://github.com/badlogic/agent-tools

[4]

双 LLM 模式: https://simonwillison.net/2023/Apr/25/dual-llm-pattern/

[5]

子代理: https://github.com/badlogic/pi-mono/tree/main/packages/coding-agent/examples/extensions/subagent/

[6]

计划模式: https://github.com/badlogic/pi-mono/tree/main/packages/coding-agent/examples/extensions/plan-mode/

[7]

权限门控: https://github.com/badlogic/pi-mono/tree/main/packages/coding-agent/examples/extensions/permission-gate.ts

[8]

路径保护: https://github.com/badlogic/pi-mono/tree/main/packages/coding-agent/examples/extensions/protected-paths.ts

[9]

SSH 远程执行: https://github.com/badlogic/pi-mono/tree/main/packages/coding-agent/examples/extensions/ssh.ts

[10]

沙箱化: https://github.com/badlogic/pi-mono/tree/main/packages/coding-agent/examples/extensions/sandbox/

[11]

在终端里跑 Doom: https://github.com/badlogic/pi-mono/tree/main/packages/coding-agent/examples/extensions/doom-overlay/

[12]

clawdbot: https://github.com/clawdbot/clawdbot

[13]

Terminal-Bench 2.0: https://github.com/laude-institute/terminal-bench

[14]

一篇博文: https://lucumr.pocoo.org/2025/11/21/agents-are-hard/