从 2020 年到 2024 年，编码 Agent 爆发了三款代表性项目：OpenAI 用 Rust 写的 Codex CLI、Anthropic 的 Claude Code。还有 earendil‑works 用纯 TypeScript 写的 Pi Agent。这三款都在终端跑一个能读代码、写文件、输入命令的 AI Agent，但它们在底层架构上的取舍截然不同。

使用者最常遇到的痛点

• 模型锁定Codex 只能绑定 OpenAI Responses API，Claude Code 只能用 Anthropic Messages API。按理说，
• 功能 受限消息类型、工具集合、压缩策略等都被编译期硬编码。想要自定义几乎只能 fork 项目。
• 运行时切换困难无法在同一次会话中动态更换模型或插入新任务，只能手动重启或手动输入指令。话说回来，
• 调试和审计不透明压缩后的上下文往往是黑盒。无法追溯到底改了哪些文件。

主要维度对比表

1️⃣ 消息类型不定义死，留给使用者

P​i 在 /packages/agent/src/types.ts 里只用了两行代码：

export type AgentMessage =
Message | CustomAgentMessages;其实，export interface CustomAgentMessages {}

declare module "@earendil-works/pi-agent-core" {
interface CustomAgentMessages {
deploymentLog: { role: "deploymentLog";content: LogData };
codeReview: { role: "codeReview";content: ReviewData };}
}

A​gentMessage 自动包含新增的消息类型，而主要库无需任何改动。这种设计让第三方能够在不 fork 主要代码的前提下自由添加业务专属的消息，如 “代码评审” 或 “部署日志”。说起来，唯一的代价是需要理解 declaration merging 的语义。但相对于 Fork Rust enum 的成本，这点学习曲线完全值得。

2️⃣ pi‑ai 用 Adapter 模式统一供应商

P​i 把所有支持的 API 抽象成一个统一的  接口：

export type StreamFn = (
model这方面。Model,context: Context,options?: SimpleStreamOptions,) => AssistantMessageEventStream | Promise;export type KnownApi =
| "openai-responses"
| "anthropic-messages"
| "bedrock-converse-stream"
| "google-generative-ai"
| "pi-messages";// ，更多