Pi好比AI时代的Vim，让你在终端中拥有自由扩展且尽在掌控的编程利器。
核心内容：
1. Pi作为Coding Agent的设计理念与独特优势
2. 从性能、内存占用等维度对比主流Coding Agent
3. 剖析Pi的TUI实现与可扩展架构

这世界上只有三种代码编辑器：Vim、Emacs 和其他。这句话看似偏激，其实他讲的是设计哲学，Vim 后续有 NeoVim，有 Zed 等，这里的 Vim 指的是他作为文本编辑器的设计哲学。

到了 AI Agent 时代，程序员的 Coding 工具也从文本编辑器变成了各路 Coding Agent。Claude Code，Codex CLI，OpenCode 等等，以及今天的主角 Pi。

如果你是程序员，你常年在终端环境下工作，那我强烈建议你试试 Pi。这款 Coding Agent 和其他几家最大的区别，就是设计理念上的不同。Pi 就好比 AI Agent 时代的 Vim，一款你可以自由扩展，又让你感觉事事都在掌控之中的新时代编程工具！

在对比分析之前，我还是要强调，这些对比是基于你长期在终端环境中。因为例如 Claude，Codex 等产品，设计重心已经逐渐从一个 CLI 的 Coding Agent Tool 转移到更全面的桌面产品中，他们的产品设计重心早已不是仅停留在解决编程问题上。然而我们本次重心是 AI 时代程序员的趁手工具，以及选择 Pi 的理由。、

我将从以下维度带你了解 Pi 作为 AI 时代程序员的编程首选工具的理由：

• 底层实现，运行效率，内存占用
• TUI 实现
• System Prompt 与上下文注入机制
• Agent Loop 与工具调用实现
• 扩展机制

底层实现，运行效率，内存占用

Pi，Claude Code 和 OpenCode 底层都是使用 TypeScript 编写，Bun 编译而 Codex CLI 则是使用 Rust 编写和编译。初次启动后的内存占用情况如下：

• Codex CLI：~30 MB
• Pi：~110 MB
• Claude Code：~160 MB
• OpenCode：~500 MB

在启动速度和内存占用方面，Codex CLI 要远远优于其他 Coding Agent，Pi 优于仅需要加载少量 System Prompt 和必要的扩展仅次于 Codex。OpenCode 最重。

TUI 实现

Codex 是基于 ratatui/ratatui 框架，这是一套很成熟的 Rust 社区生态下的 TUI 开发方案。我们熟悉的 bottom，gitui，yazi 等终端工具都是基于 ratatui 开发。

Pi 则是采用自研的 TUI 框架，他并没有构筑复杂的 Virtual DOM 并在 Terminal 中渲染输出，而是采用字符串行数组渲染，用差分渲染和终端协议细节换取低闪烁。并且有极强的扩展能力，coding-agent 通过把 TUI 组合成 header、chat、pending messages、status、widgets、editor、footer。让用户可以重写这些组件模块从而自定义显示。

OpenCode 底层是 anomalyco/opentui，你可以用 React 的开发经验和 JSX 的语法开发终端程序。

Claude Code 的 TUI 是 TypeScript/Bun 上的 React 应用，使用内置的定制 Ink renderer，通过 Yoga 布局和 ANSI diff 直接控制终端。

简单说 Pi 的 TUI 实现胜在扩展性、易用性和性能给出了平衡方案。Codex 则是性能最佳方案，而 OpenCode 和 Claude Code 只能说方便自家前端团队高效开发，但在终端上都配了非常重的框架，牺牲性能的同时还没有规划好 TUI 的扩展区域，在终端工程与代码设计上都属于较差的水准。

System Prompt 与上下文注入机制

Coding Agent 的 System Prompt 不是简单的一段角色设定，而是整个工具如何理解项目、如何约束行为、如何暴露能力的总入口。一个 Coding Agent 把什么东西塞进 System Prompt、什么时候塞、能不能被用户修改，基本决定了这个 Agent 到底是一个黑盒产品，还是你可以自己定义的 Coding Agent 工具。

Claude Code 可以理解为一个完全黑盒的产品。它的 System Prompt 由大量内置 section 组成，会混合 CLAUDE.md、memory、MCP instructions、git 状态、环境信息、输出风格、语言偏好和各种动态 attachments。它甚至会把 prompt 切成静态段和动态段，配合 Anthropic prompt cache 做缓存优化。这套机制的问题是控制权主要在 Claude Code 和 Anthropic 手里。用户能写 CLAUDE.md，能配置 memory 和 MCP，但很难真正理解和重写整个上下文注入链条。

Codex CLI 的方案更偏底层工程，但同样是一个黑盒产品。它把 base instructions 放在 Responses API 的 instructions 字段里，把 developer instructions、AGENTS.md、环境信息、权限策略、skills、plugins 等拆成不同的上下文 fragment。首次 turn 全量注入，后续通过 reference context 做增量 diff。它比 Claude Code 唯一好的一点是它开源，你至少还能分析 System Prompt 长什么样，怎么拼装。但用户能影响的只有 AGENTS.md 和配置项，你同样拿到的是一个你支配不了的黑盒产品。

OpenCode 的 System Prompt 机制则是工程化到另一个方向。它按 provider 准备了 anthropic、gpt、gemini、codex 等不同 prompt 模板，同时允许 agent prompt 覆盖默认模板，还会额外注入 environment、instructions、skills、session history 和 compaction summary。V2 里甚至引入了 System Context source / reconcile 机制，把上下文做成可增量更新的 runtime。看上去很全面，但理解成本和运行时复杂度都不低。

Pi 的机制简单很多。它的 System Prompt 由以下几个部分组成：

• 基础提示词 - 说明 Agent 的职责，可用工具，工具手册
• 附加提示词 - 通过 APPEND_SYSTEM.md 附加
• 项目上下文 - 通过 AGENT.md 附加
• Skills 目录 - 通过解析所有 Skills 并把他们做成路径映射表

总的加载不到 1000 Token，并且你随时可以用自己的 SYSTEM.md 替换掉这整份提示词。而且你还可以随时导出系统提示词对比查看和调试。

扩展机制

Codex CLI 和 Claude Code 走的是产品扩展路线，围绕着目前 Coding Agent 的标准定义扩展：

• MCP 服务
• Skills
• Hooks
• Slash Command
• Subagents

而 Pi 则是另一个思路。Pi 的扩展是让你对 Pi 这个工具编写插件，通过这些插件间接支持 Codex、Claude Code 等传统 Agent 的基础能力，例如 MCP，Skills，Hooks 这些，同时还能拓展额外的能力。这就和 Vim 扩展类似，不仅仅是简单的文本编辑支持，还可以通过扩展和 UI 显示引入额外新的功能。

对于 Pi 而言，最强大的扩展莫过于 tools 的注册与调用。其他的扩展例如 prompt，command 以及前文提到的自定义 TUI，你可以通过这些方式将 Pi 改造成你心仪的模样，并严格控制他的 tool 调用从而精确地引导 LLM 进行本地代码编写和工具调用操作。

对于刚接触 Pi 的开发者，最不习惯的是他不内置 MCP 和 Subagents，这两项是需要你通过 Pi 的扩展自己编写实现，乍一看会觉得很不方便，但其实 MCP 底层无非是 tools 的注册与上报，而 Subagents 则是启动一个新的 Agent 进程并进行监听。这两项在你理解了 Pi 的扩展机制后，都能非常容易地实现。

小结

本周先写这些，下周继续~

登录查看剩余 70% 内容