编程 Agent 全面对比：从 Claude Code 到 Pi 的设计哲学 / Coding Agents Comparison: Design Philosophies from Claude Code to Pi
📅 创建时间：2026-07-29 🏷️ 标签：#CodingAgent #AgentArchitecture #ToolComparison #AgentDesign 📚 前置知识：[[01-function-calling]] [[04-agent-loop]] [[05-agent-workflow]]
📋 本章目标
- 理解主流编程 Agent 的架构设计差异与共同模式
- 掌握 TAOR、Plan-Search-Build、Cache-First 等核心循环范式
- 对比 6 个 Agent 的工具体系、模型策略、安全机制与扩展能力
- 建立"原语 vs 集成""全功能 vs 极简"的设计谱系认知
- 能根据团队规模、预算、技术栈与地区生态做出选型决策
- 理解每个 Agent 的设计取舍背后的工程哲学——没有银弹，只有权衡
- 为构建自己的 Agent 系统积累可复用的架构模式与反模式
第1部分：为什么要对比不同的 Agent 实现
1.1 一个需求，六种解法
2025-2026 年是编程 Agent 的爆发期。不到 18 个月的时间内，至少 6 个有影响力的编码 Agent 从不同起点出发，交出了截然不同的答卷。同一个需求——"让 LLM 帮你写代码"——在不同的工程哲学下，演化出了完全不同的实现路径。
┌─────────────────────────────────────────────────────────────┐
│ 同一个需求：让 LLM 帮你写代码 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Anthropic 的选择： │
│ "原语 > 集成。Bash + Grep + Edit 就够了。" │
│ │
│ OpenAI 的选择： │
│ "全自动。3 种模式覆盖从建议到全自动的光谱。" │
│ │
│ xAI 的选择： │
│ "多智能体协作。8 个 Agent 并行，竞技场决胜负。" │
│ │
│ Moonshot 的选择： │
│ "对标 Claude Code 架构，用中国生态和成本优势。" │
│ │
│ Reasonix 的选择： │
│ "深度绑定单一后端。最大化缓存命中率就是一切。" │
│ │
│ Pi 的选择： │
│ "4 个工具，1000 token 系统提示。其余全是扩展。" │
│ │
└─────────────────────────────────────────────────────────────┘1.2 对比的价值
理解这些差异化设计的意义不只在"选哪个工具"。更深层的价值在于：
- 每个 Agent 的设计选择都是一堂工程课：工具数量为什么是 4 个而不是 40 个？要不要子智能体？MCP 是必选项吗？
- 模型能力变化时，架构该跟着变吗？ Anthropic 明确说"harness 应该在模型进步时变薄"，而 Reasonix 深度耦合 DeepSeek 的 prefix-cache——两个方向都有道理。
- 生态位分化揭示未被满足的需求：Pi 的极端极简和 Grok Build 的极端并行，说明用户在两端都有强烈的偏好。
1.3 六个 Agent 的速览定位
| Agent | 公司/作者 | 首发 | 许可证 | 一句话定位 |
|---|---|---|---|---|
| Claude Code | Anthropic | 2025.02 | Proprietary | 原语至上，企业级编码 Agent |
| Codex CLI | OpenAI | 2025.04 | Apache 2.0 | 全自动编码，从建议到完全自主 |
| Grok Build | xAI | 2026.05 | Proprietary | 并行多智能体，价格屠夫 |
| KimiCode | Moonshot AI | 2025.10 | Apache 2.0 | 中国生态，对标 Claude Code |
| Reasonix | DeepSeek/社区 | 2025/2026 | MIT | 深度绑定 DeepSeek，极致缓存 |
| Pi | badlogic | 2025 | MIT | 极简主义，4 工具万能 |
第2部分：Claude Code (Anthropic) —— 原语至上主义
2.1 基本信息
- 首发：2025 年 2 月 research preview，2025 年 5 月 GA
- 最新版本 (2026.07)：v2.1.202
- 默认模型：Sonnet 5
- 语言：TypeScript
- 许可证：Proprietary
2.2 核心架构：TAOR 循环
Claude Code 的核心是一个 TypeScript 实现的 harness（外骨骼），围绕 TAOR 循环运行：
┌─────────────────────────────────────────────────────────────┐
│ Claude Code TAOR 循环 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ THINK │────→│ ACT │────→│ OBSERVE │ │
│ │ 思考 │ │ 执行 │ │ 观察 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ ↑ │ │
│ │ ↓ │
│ │ ┌──────────┐ │ │
│ └──────────│ DECIDE │←───────────┘ │
│ │ 决定 │ │
│ └──────────┘ │
│ │
│ 关键设计： │
│ • THINK：LLM 分析工具结果，推理下一步 │
│ • ACT：Harness 执行工具（Bash/Edit/Read/Write） │
│ • OBSERVE：收集工具输出，裁剪到上下文窗口 │
│ • DECIDE：判断 finish_reason（stop / tool_calls / 续写） │
│ │
└─────────────────────────────────────────────────────────────┘2.3 工具体系：~48 个工具，渐进披露
Claude Code 总共有约 48 个工具，但在任意时刻只能看到 14-20 个。不是所有工具都始终暴露——这被称为渐进披露 (Progressive Disclosure)。
┌─────────────────────────────────────────────────────────────┐
│ Claude Code 工具体系（渐进披露） │
├─────────────────────────────────────────────────────────────┤
│ │
│ 核心工具（始终可见）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Bash — 执行 shell 命令（通用工具） │ │
│ │ Read — 读取文件内容 │ │
│ │ Write — 覆写/创建文件 │ │
│ │ Edit — 精确字符串替换（核心差异化工具） │ │
│ │ Glob — 文件模式匹配 │ │
│ │ Grep — 正则内容搜索 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 状态工具（按需出现）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ TodoWrite — 任务列表管理 │ │
│ │ TaskStop — 停止后台任务 │ │
│ │ EnterPlanMode — 进入计划模式 │ │
│ │ ExitPlanMode — 退出计划模式 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 高级工具（按需出现）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Agent — 启动子 Agent │ │
│ │ Skill — 调用技能 │ │
│ │ EnterWorktree — Git 工作树隔离 │ │
│ │ WebSearch — 网络搜索 │ │
│ │ WebFetch — 获取网页内容 │ │
│ │ NotebookEdit — Jupyter Notebook 编辑 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 设计原理：工具多了 LLM 会决策瘫痪。 │
│ 只暴露当前上下文相关的工具 = 更高的决策质量。 │
│ │
└─────────────────────────────────────────────────────────────┘Edit 工具——精确字符串替换：这是 Claude Code 最具特色的原子工具。它不像传统 patch 工具依赖行号（容易因上下文变化而偏移），而是做精确的字符串匹配替换：
typescript
// Edit 工具的核心理念：old_string 必须精确匹配
// 如果匹配不上 => 编辑失败（不会产生破损的代码）
// replace_all: true 可替换所有出现
{
"file_path": "/absolute/path/to/file.ts",
"old_string": "const x = 1;",
"new_string": "const x = 2;",
"replace_all": false
}2.4 先进特性
Plan Mode（计划模式）
┌─────────────────────────────────────────────────────────────┐
│ Claude Code Plan Mode 工作流 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 用户触发 /plan │
│ │ │
│ ▼ │
│ EnterPlanMode ──→ LLM 被限制为只读 │
│ │ (Read/Glob/Grep 可用) │
│ │ (Write/Edit/Bash 被禁用) │
│ ▼ │
│ LLM 调研代码库 → 生成计划 │
│ │ │
│ ▼ │
│ 用户审批计划 → ExitPlanMode │
│ │ │
│ ▼ │
│ LLM 按计划执行（正常工具权限恢复） │
│ │
│ 核心价值：调研和执行分离。调研阶段零副作用。 │
│ │
└─────────────────────────────────────────────────────────────┘4 层压缩 (Compaction)
当对话上下文超出窗口时，Claude Code 分 4 层压缩而非简单截断：
┌─────────────────────────────────────────────────────────────┐
│ 4-Tier Compaction 策略 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Tier 1: 工具输出裁剪 │
│ ├── 大文件输出只保留首尾 + 行数统计 │
│ │ 原：500 行 grep 结果 → 压缩后：前 50 行 + "...450 行" │
│ │
│ Tier 2: 对话轮次摘要 │
│ ├── 旧轮次的工具调用和结果被压缩为摘要 │
│ │ 原：完整 tool_call + tool_result → 压缩后：一句概括 │
│ │
│ Tier 3: 中间思维压缩 │
│ ├── 模型内部的推理链（thinking）被摘要化 │
│ │
│ Tier 4: 重新开始（极端情况） │
│ └── 保留关键上下文摘要，其余全部丢弃 │
│ │
│ 设计原理：用户感知的是"无限对话"，而非突然截断。 │
│ │
└─────────────────────────────────────────────────────────────┘Worktree 隔离 + 子 Agent
- Worktree：Git worktree 级别的文件隔离。Agent 在独立分支上工作，不污染主工作区。
- 子 Agent：Agent 工具可启动独立子 Agent 执行并行任务，完成自动销毁。
2.5 扩展机制
┌─────────────────────────────────────────────────────────────┐
│ Claude Code 扩展机制全景 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Skills (SKILL.md)： │
│ ├── 为特定任务打包的指令集（部署、审查、测试） │
│ ├── 通过 Skill 工具调用 │
│ └── 支持目录级作用域（apps/web:deploy） │
│ │
│ Hooks (~30 生命周期事件)： │
│ ├── PreToolUse / PostToolUse — 工具前后拦截 │
│ ├── Notification — 通知事件 │
│ ├── Stop — Agent 停止时触发 │
│ ├── 可配置在 settings.json 中 │
│ └── 支持 shell 命令或 HTTP 回调 │
│ │
│ MCP (Model Context Protocol)： │
│ ├── 标准 MCP 客户端实现 │
│ └── 连接外部 MCP 服务器获取额外工具 │
│ │
│ Workflows (v2.1.154+)： │
│ ├── 多步骤 Agent 工作流编排 │
│ └── 声明式定义，自动执行 │
│ │
└─────────────────────────────────────────────────────────────┘2.6 设计哲学
Anthropic 的设计哲学用一句话概括：Primitives > Integrations（原语优于集成）。
Bash + Grep + Edit 这三个原子工具理论上可以组合出任何操作——不需要为 Git、Docker、npm 各自写专门的工具。Git 操作通过 Bash 执行 git 命令完成，代码搜索通过 Grep 正则完成，文件编辑通过 Edit 精确替换完成。
另一个关键信念：Harness 应该在模型进步时变薄。这意味着今天在 harness 层做的很多"补偿性工程"（精细的工具描述、复杂的状态机、手写的提示工程），随着模型推理能力增强，可以逐步移除。
2.7 优势与局限
| 优势 | 局限 |
|---|---|
| 渐进披露降低工具选择困难 | 闭源，无法自托管 |
| Edit 工具精确可靠 | 企业授权费用高 |
| 4 层压缩实现"无限对话" | 需要 Anthropic API 密钥 |
| 丰富的扩展机制 (Skills/Hooks/MCP) | TypeScript harness 较重 |
| Worktree 隔离安全性高 | 对非 Git 项目支持有限 |
第3部分：OpenAI Codex CLI —— 从全自动到合并终止
3.1 基本信息
- 首发：2025 年 4 月 16 日（开源，Apache 2.0）
- 终止：2026 年 4 月 27 日（合并入 GPT-5.5 + ChatGPT 超级应用）
- 语言：TypeScript/Node.js → Rust 重写（到 2026 年 4 月 95% 完成）
- 巅峰 WAU：500 万+
3.2 核心架构：App Server 统一层
Codex CLI 最独特的架构决策是 App Server——一个统一的后端服务层，为 CLI、VS Code、Web 和桌面端提供完全相同的 API：
┌─────────────────────────────────────────────────────────────┐
│ Codex CLI 架构：App Server 统一层 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ CLI │ │ VS Code │ │ Web │ │ Desktop │ │
│ │ TUI │ │ Extension│ │ App │ │ App │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │ │
│ └─────────────┴──────┬──────┴─────────────┘ │
│ │ │
│ ┌─────────▼──────────┐ │
│ │ App Server │ │
│ │ (Rust) │ │
│ │ │ │
│ │ • 会话管理 │ │
│ │ • 认证/授权 │ │
│ │ • 模型路由 │ │
│ │ • 沙箱编排 │ │
│ │ • ZDR 合规 │ │
│ └─────────┬──────────┘ │
│ │ │
│ ┌─────────▼──────────┐ │
│ │ LLM Backend │ │
│ │ (o3 → codex-1 │ │
│ │ → GPT-5.5) │ │
│ └────────────────────┘ │
│ │
│ 设计原理：一套后端，所有终端共享逻辑和状态。 │
│ │
└─────────────────────────────────────────────────────────────┘3.3 三模式体系
Codex CLI 定义了 3 个自动化级别——从最安全到最自主：
┌─────────────────────────────────────────────────────────────┐
│ Codex CLI 三模式体系 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Mode 1: Suggest（建议） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • LLM 只给出代码建议，不自动修改文件 │ │
│ │ • 用户手动接受/拒绝每个建议 │ │
│ │ • 最适合：学习、代码审查辅助 │ │
│ │ • 安全级别：最高 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Mode 2: Auto Edit（自动编辑） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • LLM 自动编辑文件，但每次编辑后可撤销 │ │
│ │ • 适合：日常开发，有安全网 │ │
│ │ • 安全级别：中等 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Mode 3: Full Auto（全自动） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • LLM 自主执行所有操作，无审批 │ │
│ │ • 适合：CI/CD、批量重构 │ │
│ │ • 安全级别：低（需配合沙箱使用） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 关键设计：模式 + 沙箱 + 审批是三个正交的维度。 │
│ Full Auto 模式如果配置了沙箱，依然安全。 │
│ │
└─────────────────────────────────────────────────────────────┘3.4 沙箱与安全模型
Codex CLI 的安全模型是三层正交：
┌─────────────────────────────────────────────────────────────┐
│ Codex CLI 安全模型：三层正交 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 层级 1：模式 (Mode) │
│ ├── Suggest / Auto Edit / Full Auto │
│ └── 决定"要不要自动执行" │
│ │
│ 层级 2：审批 (Approval) │
│ ├── 每次操作前是否弹确认 │
│ └── 决定"要不要问一下用户" │
│ │
│ 层级 3：沙箱 (Sandbox) │
│ ├── macOS：Apple Seatbelt 沙箱 │
│ ├── Linux：bubblewrap 容器 │
│ ├── Windows：Windows Sandbox │
│ └── 决定"即使执行了，能造成多大破坏" │
│ │
│ 三个维度独立配置，互不干扰。 │
│ │
└─────────────────────────────────────────────────────────────┘Apple Seatbelt 是 Codex CLI 在 macOS 上的杀手级特性——利用 macOS 系统级沙箱机制，通过声明式配置（.sb 文件）精确限制文件系统和网络访问，无需 root 权限，比 Docker 更轻量。
3.5 模型演进路径
Codex CLI 经历了 OpenAI 模型策略变化最快的时期：
┌─────────────────────────────────────────────────────────────┐
│ Codex CLI 模型演进时间线 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 2025.04 o3 ← 首发默认模型 │
│ │ │
│ ▼ │
│ 2025.06 codex-1 ← 首个"代码专用模型" │
│ │ 针对编码场景微调 │
│ ▼ │
│ 2025.10 GPT-5-Codex ← 代码能力合并到 GPT-5 分支 │
│ │ │
│ ▼ │
│ 2026.02 GPT-5.3-Codex ← 迭代升级 │
│ │ │
│ ▼ │
│ 2026.04 GPT-5.5 ← 代码与非代码模型统一 │
│ │ Codex CLI 源代码合并入 │
│ │ ChatGPT 超级应用 │
│ ▼ │
│ 2026.04.27 终止 Codex CLI 独立产品线结束 │
│ │
└─────────────────────────────────────────────────────────────┘3.6 ZDR 合规（零数据驻留请求）
Codex CLI 独特地支持 ZDR (Zero Data Retention) 模式——每个 API 请求标记为无需数据驻留，OpenAI 不会存储该请求的数据用于训练或改进模型。这对于企业合规至关重要，也是 Codex CLI 唯一能在受监管行业（金融、医疗）中使用的原因之一。
3.7 从 TypeScript 到 Rust 的重写
最初用 TypeScript/Node.js 实现，2025 年底启动 Rust 重写计划。到终止时约 95% 完成。重写的主要动机：
- 启动时间：Node.js JIT 预热开销 → Rust AOT 零延迟
- 内存效率：GC 导致的内存占用波动 → Rust 确定性内存管理
- 单二进制分发：Rust 编译为静态二进制，无需 Node.js 运行时
3.8 设计哲学
Codex CLI 体现了 OpenAI 一贯的"基础设施化"思路——不把 Agent 看作独立产品，而是看作 API 之上的薄客户端。App Server 统一架构让 Codex 能嵌入任何界面。但这也意味着当模型本身能力足够强时，专门的 CLI 客户端就不那么必要了——这恰好解释了为什么 Codex CLI 最终被合并进 ChatGPT 超级应用。
3.9 优势与局限
| 优势 | 局限 |
|---|---|
| 3 模式覆盖全自动化光谱 | 2026 年 4 月已终止 |
| 沙箱 + 审批 + 模式正交设计 | 不再独立维护 |
| App Server 多端统一 | 强依赖 OpenAI 生态 |
| ZDR 支持企业合规 | Rust 重写未完成 |
| 500 万+ WAU 验证了需求 | 与 ChatGPT 合并后独立特性消失 |
第4部分：Grok Build (xAI) —— 并行多智能体 + 价格屠夫
4.1 基本信息
- 首发：2026 年 5 月（Grok Build 0.1 API + CLI），2026 年 7 月（消费者 Grok Build Mode）
- 最新模型：Grok 4.5 (2026.07)
- 定价：$1/$2 per 1M tokens（输入/输出）——极其激进
- 许可证：Proprietary
4.2 核心架构：并行多智能体 + 三阶段流水线
Grok Build 的架构是最激进的——一次启动最多 8 个并行 Agent，每个独立探索不同方案，然后由裁判机制选出最佳结果：
┌─────────────────────────────────────────────────────────────┐
│ Grok Build 并行多智能体架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Stage 1: PLAN（规划） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Planner Agent 分析用户需求 │ │
│ │ → 拆解为多个子任务 │ │
│ │ → 生成每个子任务的 prompt │ │
│ └────────────────────────┬────────────────────────────┘ │
│ │ │
│ ▼ │
│ Stage 2: SEARCH（探索） ── 并行阶段 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────┐│ │
│ │ │ Agent 1 │ │ Agent 2 │ │ Agent 3 │ ... │ Agt 8││ │
│ │ │ Harper │ │ Benjamin │ │ Lucas │ │ ... ││ │
│ │ │ 创意 │ │ 深度推理 │ │ 代码数学 │ │ ││ │
│ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ └──┬───┘│ │
│ │ │ │ │ │ │ │
│ │ └────────────┴────────────┴──────────────┘ │ │
│ │ │ │ │
│ │ 各 Agent 独立生成方案 │ │
│ └─────────────────────────┬───────────────────────────┘ │
│ │ │
│ ▼ │
│ Stage 3: BUILD（构建） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ ┌──────────────────────────────────────────────┐ │ │
│ │ │ Arena Mode（竞技场） │ │ │
│ │ │ │ │ │
│ │ │ Agent 1 输出 ──┐ │ │ │
│ │ │ Agent 2 输出 ──┤ │ │ │
│ │ │ Agent 3 输出 ──┼──→ Judge LLM ──→ 最优方案 │ │ │
│ │ │ ... │ 逐项打分 │ │ │
│ │ │ Agent 8 输出 ──┘ │ │ │
│ │ └──────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ 选中方案 → 生成最终代码 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘4.3 命名子智能体角色
Grok Build 引入了具名的子智能体角色——每个角色有明确的专长：
| 角色名 | 专长 | 适用场景 |
|---|---|---|
| Harper | 创意生成 | UI/UX 设计、内容创作、头脑风暴 |
| Benjamin | 深度推理 | 架构设计、复杂逻辑、系统分析 |
| Lucas | 代码/数学 | 算法实现、性能优化、数学推导 |
4.4 Arena Mode（竞技场模式）
┌─────────────────────────────────────────────────────────────┐
│ Arena Mode 裁判机制 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 输入：N 个 Agent 对同一个任务的独立输出 │
│ │
│ 裁判 LLM 评估维度： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. 正确性 — 代码是否符合需求？ │ │
│ │ 2. 性能 — 实现的算法效率如何？ │ │
│ │ 3. 可读性 — 代码是否清晰可维护？ │ │
│ │ 4. 健壮性 — 边界情况处理如何？ │ │
│ │ 5. 风格 — 是否符合项目代码规范？ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 输出：最高分方案 + 各维度评分明细 │
│ │
│ 代价：N× 的 token 消耗（8 个并行 Agent 的开销） │
│ 收益：质量显著优于单 Agent 输出 │
│ │
└─────────────────────────────────────────────────────────────┘4.5 本地优先策略
Grok Build 声明了 local-first 策略——源代码不传输到 xAI 服务器：
- Agent 在本地运行，只发送 prompt 到 xAI API
- 文件操作在本地执行
- 代码审查和 Arena 裁判在本地完成
这种设计降低了企业采用的安全顾虑——代码不离开开发者的机器。
4.6 扩展兼容
Grok Build 兼容现有的 Agent 生态标准：
- ACP (Agent Communication Protocol)：Agent 间通信协议
- MCP (Model Context Protocol)：连接外部工具服务器
- AGENTS.md：项目级 Agent 配置（兼容 Claude Code 格式）
- Hooks + Plugins：生命周期钩子和插件系统（兼容 Claude Code 格式）
4.7 定价策略
Grok Build 0.1 的定价是市场上最激进的：
| 提供商 | 输入价格 (per 1M tokens) | 输出价格 (per 1M tokens) |
|---|---|---|
| Grok Build 0.1 | $1.00 | $2.00 |
| GPT-5.5 | $2.50 | $10.00 |
| Claude Sonnet 5 | $3.00 | $15.00 |
| DeepSeek-V3 | $0.27 | $1.10 |
对于需要并行 8 Agent 的工作负载，价格优势尤其明显——即使 8 倍并发，也仍然比单线程 Claude Code 便宜。
4.8 设计哲学
xAI 选择了一条"人多力量大"的路线。在他们的世界观里，单个 Agent 的推理质量有上限，而并行化是突破这个上限的最直接方法。8 个 Agent 从不同角度探索解空间，然后用裁判 LLM 选最优——本质上是用计算量换质量。
4.9 优势与局限
| 优势 | 局限 |
|---|---|
| Arena Mode 质量优于单 Agent | 并行 8 Agent 的 token 成本不低 |
| 激进定价（$1/$2 per 1M） | 产品较新，生态不如 Claude Code 成熟 |
| 兼容 Claude Code 生态 (AGENTS.md/Hooks) | 消费者模式才刚上线 (2026.07) |
| Local-first，代码不出本地 | 依赖 xAI 模型生态 |
| 3 具名角色清晰分工 | Grok 模型自身编码能力仍在追赶 |
第5部分：KimiCode / Kimi Code CLI (Moonshot AI) —— 中国生态的对标者
5.1 基本信息
- 首发：2025 年 10 月 27 日（Kimi CLI 开源），2026 年 1 月重命名为 KimiCode
- 语言：Python → TypeScript + Bun 重写（2026 年 4-5 月）
- 代码规模：166 个 TypeScript 文件，38K+ 行
- 许可证：Apache 2.0
- 默认模型：Kimi K2.7-Code (2026.06)
5.2 核心架构：对标 Claude Code 的 TS 实现
KimiCode 在架构层面明确对标 Claude Code，但在中国生态下做了显著的本土化：
┌─────────────────────────────────────────────────────────────┐
│ KimiCode 架构全景 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ TUI 层 (React Ink) │ │
│ │ • 交互式终端 UI │ │
│ │ • Ctrl-K 切换 Shell/Agent 模式 │ │
│ │ • 实时流式渲染 │ │
│ └────────────────────────┬─────────────────────────────┘ │
│ │ │
│ ┌────────────────────────▼─────────────────────────────┐ │
│ │ CLI 框架 (Commander.js) │ │
│ │ • 命令解析与路由 │ │
│ │ • 配置管理 │ │
│ │ • 模式切换调度 │ │
│ └────────────────────────┬─────────────────────────────┘ │
│ │ │
│ ┌────────────────────────▼─────────────────────────────┐ │
│ │ Agent 循环引擎 │ │
│ │ ┌──────────────────────────────────────────────┐ │ │
│ │ │ Shell Mode ←──→ Agent Mode (Ctrl-K) │ │ │
│ │ │ │ │ │
│ │ │ • RalphFlow: 自主规划引擎 │ │ │
│ │ │ • Print Mode: 只输出结果（可嵌入管道） │ │ │
│ │ │ • Wire Mode: JSON 事件流（可嵌入程序） │ │ │
│ │ └──────────────────────────────────────────────┘ │ │
│ └────────────────────────┬─────────────────────────────┘ │
│ │ │
│ ┌────────────────────────▼─────────────────────────────┐ │
│ │ MCP / ACP 支持 │ │
│ │ • MCP 客户端连接外部工具服务器 │ │
│ │ • ACP Agent 间通信 │ │
│ └────────────────────────┬─────────────────────────────┘ │
│ │ │
│ ┌────────────────────────▼─────────────────────────────┐ │
│ │ Kimi K2.7-Code (MoE 1T/32B active) │ │
│ │ • 384 experts, MLA attention │ │
│ │ • 256K context window │ │
│ │ • 强制 thinking mode │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘5.3 双模式 (Shell / Agent)
KimiCode 最独特的交互设计是 Ctrl-K 切换的双模式：
┌─────────────────────────────────────────────────────────────┐
│ KimiCode 双模式设计 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Shell Mode（终端模式）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 表现像普通终端 │ │
│ │ • 执行 shell 命令（不经过 Agent） │ │
│ │ • 适合：正常开发流程，偶尔需要 Agent 帮助 │ │
│ │ │ │
│ │ $ npm test │ │
│ │ $ git status │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Agent Mode（智能体模式）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 按 Ctrl-K 触发 │ │
│ │ • LLM 接管，开始读代码、改代码、执行命令 │ │
│ │ • 完成任务后返回 Shell Mode │ │
│ │ │ │
│ │ > 帮我把这个函数的复杂度从 O(n²) 降到 O(n log n) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 核心价值：不侵入正常开发流。Agent 是助手，不是"替代品"。 │
│ │
└─────────────────────────────────────────────────────────────┘5.4 RalphFlow：自主规划引擎
RalphFlow 是 KimiCode 的计划模式实现——与 Claude Code 的 Plan Mode 不同，RalphFlow 更强调自主性：
typescript
// RalphFlow 核心循环
interface RalphFlowStep {
goal: string; // 子目标
actions: string[]; // 计划执行的步骤
verification: string; // 检验标准
}
// 流程：分析需求 → 生成 RalphFlow steps → 逐步执行 → 每步验证
// 失败时自动回退重新规划，而非等待用户干预5.5 Print Mode 与 Wire Mode
┌─────────────────────────────────────────────────────────────┐
│ KimiCode 嵌入模式 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Print Mode： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ $ kimi print "找出所有未使用的 import" │ │
│ │ src/utils.ts:5 — import {lodash} from 'lodash' │ │
│ │ src/index.ts:12 — import {oldFn} from './deprecated'│ │
│ │ │ │
│ │ → 只输出结果，可管道到其他命令 │ │
│ │ → kimi print "..." | xargs ... │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Wire Mode： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ $ kimi wire "重构认证模块" │ │
│ │ {"event":"tool_call","tool":"Read","path":"auth.ts"}│ │
│ │ {"event":"thinking","content":"分析现有实现..."} │ │
│ │ {"event":"tool_call","tool":"Edit",...} │ │
│ │ {"event":"done","summary":"重构完成"} │ │
│ │ │ │
│ │ → JSON 事件流，可被其他程序消费 │ │
│ │ → 适合 CI/CD 集成、VS Code 扩展、Web 终端 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 设计原理：Agent 不仅是一个工具，也是一个可嵌入的组件。 │
│ │
└─────────────────────────────────────────────────────────────┘5.6 K2.7-Code 模型技术细节
Kimi K2.7-Code 使用了 MoE (Mixture of Experts) 架构：
┌─────────────────────────────────────────────────────────────┐
│ Kimi K2.7-Code MoE 架构概要 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 总参数量：1T (1 万亿) │
│ 激活参数：32B (每次推理仅激活 3.2%) │
│ 专家数量：384 个 │
│ 注意力机制：MLA (Multi-head Latent Attention) │
│ 上下文窗口：256K tokens │
│ 特殊能力：强制 thinking mode (始终开启推理链) │
│ │
│ 基准成绩： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ SWE-bench Verified: 63.4% (K2.5) │ │
│ │ MCP Mark Verified: 81.1% (K2.7-Code) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 关键设计：MLA 注意力在 256K 长上下文中保持了线性复杂度 │
│ 增长，使 KimiCode 能处理超大型代码库。 │
│ │
└─────────────────────────────────────────────────────────────┘5.7 AMD 合作：基础设施层优化
KimiCode 与 AMD 建立了深度合作，在 MI355X GPU 上针对 MoE 推理做了联合优化：
- p99 延迟降低 3.2 倍：通过定制 kernel 减少 MoE 路由开销
- 吞吐量提升 7.7%：通过批处理优化和内存布局调整
- UMBP (Unified Memory & Bandwidth Pool)：跨请求的上下文缓存复用，减少重复 KV-cache 计算
5.8 设计哲学
KimiCode 的设计哲学是 "对标但不照搬"。架构蓝本参考了 Claude Code（TypeScript 实现、MCP 支持、Plan Mode），但在关键交互上做了本土化创新：
- Shell/Agent 双模：尊重开发者已有的工作流，不强制切换
- Print/Wire 嵌入模式：让 Agent 成为管道中的一环，而非终端
- 中国生态优先：中文界面、国内 API 优先、本土合规
5.9 优势与局限
| 优势 | 局限 |
|---|---|
| 双模式设计不侵入工作流 | 模型能力仍在追赶国际一线 |
| Print/Wire 模式嵌入友好 | 生态规模不如 Claude Code |
| AMD 合作带来显著性能优势 | 中文优先，英文文档相对薄弱 |
| MoE 架构 + 256K 上下文 | 国际市场认知度有限 |
| Apache 2.0 开源 | 部分高级功能需 Kimi API 密钥 |
第6部分：Reasonix (DeepSeek 原生) —— 缓存至上主义
6.1 基本信息
- 首发：2025 年（TypeScript 0.x），2026 年 5 月（Go v1.0 重写）
- 语言：Go（单二进制）
- 许可证：MIT
- 配置：TOML
- 定位：DeepSeek 独家适配的编码 Agent
6.2 核心架构：Cache-First 循环
Reasonix 的整个设计围绕一个核心理念展开——最大化 DeepSeek 的 prefix-cache 命中率：
┌─────────────────────────────────────────────────────────────┐
│ Reasonix Cache-First 循环 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Append-Only 消息列表 │ │
│ │ │ │
│ │ [system] [user] [assistant] [tool_result] │ │
│ │ [assistant] [tool_result] [assistant] [tool_result] │ │
│ │ ←──── 永远追加，从不修改 ────→ │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ DeepSeek Prefix-Cache 引擎 │ │
│ │ │ │
│ │ 每次 API 请求： │ │
│ │ • 前面的消息序列未变 → CACHE HIT → 仅计算新 token │ │
│ │ • 命中率：设计目标 94%+，实际案例 99.82% │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 每个 turn 仅处理增量： │ │
│ │ • 新 assistant 消息（~50-500 tokens） │ │
│ │ • 新 tool_result（变量长度） │ │
│ │ • 其余全部命中缓存 → 零计算成本 │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘6.3 为什么是 Append-Only？
┌─────────────────────────────────────────────────────────────┐
│ 为什么 Append-Only 对缓存至关重要 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 前缀缓存的机制： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 消息序列: [M1] [M2] [M3] [M4] [M5] [M6] │ │
│ │ ↑──────────────────↑ │ │
│ │ │ │ │ │
│ │ 前缀部分 新增部分 │ │
│ │ (命中缓存) (需计算) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 如果插入或修改中间的消息： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 原序列: [M1] [M2] [M3] [M4] [M5] │ │
│ │ 修改 M2: [M1] [M2'] [M3] [M4] [M5] │ │
│ │ ↑ │ │
│ │ 只有 M1 命中缓存 │ │
│ │ M2' M3 M4 M5 全部需要重算 │ │
│ │ 缓存命中率: 1/5 = 20% │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Append-Only 保证前缀完全不变 → 每轮只有新增部分需计算 │
│ │
└─────────────────────────────────────────────────────────────┘6.4 三大支柱设计
┌─────────────────────────────────────────────────────────────┐
│ Reasonix 三大支柱 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Pillar 1: Cache-First Loop │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • Append-only message list │ │
│ │ • 设计目标：94%+ 缓存命中率 │ │
│ │ • 实际案例：99.82%（435M 输入 tokens） │ │
│ │ • 435M tokens → ~$12 总成本 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Pillar 2: Tool-Call Repair │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • flatten: 展平嵌套的工具调用 │ │
│ │ • scavenge: 从截断的 JSON 中恢复有效调用 │ │
│ │ • truncation-repair: 修复被上下文截断的工具调用 │ │
│ │ • storm-detection: 检测并中断无限调用循环 │ │
│ │ • 工具调用失败率 < 3% │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Pillar 3: Cost Control │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • flash-first: 优先使用 DeepSeek Flash（最便宜） │ │
│ │ • auto-escalate: 仅 Flash 失败时升级到 V3/R1 │ │
│ │ • token 预算管理: 每个 session 设置硬上限 │ │
│ │ • 实时成本追踪: 每次 API 调用后更新花费 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘6.5 真实案例：435M Tokens, $12
一个 Reasonix 用户报告的真实数据：
Session 统计:
总输入 tokens: 435,000,000
缓存命中 tokens: 434,217,000 (99.82%)
实际计算 tokens: 783,000 (0.18%)
总成本: ~$12.00
如果无缓存（全部 token 按输入价格计费）:
DeepSeek V3 输入价格 $0.27/1M tokens
→ 435M × $0.27 = ~$117.45
缓存带来的节省: ~90%6.6 平台支持
┌─────────────────────────────────────────────────────────────┐
│ Reasonix 多平台部署 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ CLI │ │ Desktop │ │ VS Code │ │ IM Bot │ │
│ │ (Go bin) │ │ (Tauri) │ │ Extension│ │ (飞书/钉) │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │ │
│ └─────────────┴──────┬──────┴─────────────┘ │
│ │ │
│ ┌─────────▼──────────┐ │
│ │ Reasonix Core │ │
│ │ (Go 单二进制) │ │
│ │ TOML 配置 │ │
│ └─────────┬──────────┘ │
│ │ │
│ ┌─────────▼──────────┐ │
│ │ DeepSeek API │ │
│ │ (唯一后端) │ │
│ └────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘6.7 设计哲学：故意深度耦合
Reasonix 做出了一个在软件工程中通常被视为"坏实践"的选择——故意深度耦合单一后端：
"Reasonix 不是模型无关的。它给 DeepSeek 量身定做。这不是局限，这是设计意图。" — Reasonix README
标准的多模型 Agent 框架为了兼容性牺牲了性能优化空间——统一的消息格式、通用工具定义、最低公分母的上下文管理。Reasonix 反其道而行：放弃兼容性，换取极致的 DeepSeek 优化。94%+ 的缓存命中率正来源于这种"不兼容"——只有深度理解 DeepSeek 的 prefix-cache 行为，才能设计出 Append-Only 的消息管理策略。
6.8 优势与局限
| 优势 | 局限 |
|---|---|
| 极致缓存命中率 (94%+)，成本低廉 | 仅支持 DeepSeek API |
| Go 单二进制，零依赖分发 | 无法切换到其他模型 |
| Tool-Call Repair 降低失败率 | 功能集不如全功能 Agent 丰富 |
| MIT 开源 | 社区相对较小 |
| 真实案例验证的极限成本 ($12/435M tokens) | DeepSeek API 在国内以外可用性有限 |
第7部分：Pi (badlogic) —— 极简主义的极限
7.1 基本信息
- 首发：2025 年，v0.63.1 (2026.03)
- 语言：TypeScript（monorepo）
- 许可证：MIT
- 作者：badlogic (Mario Zechner)
- 定位：只做一件事的工具——读、写、改代码
7.2 核心架构：4 层严格分离
Pi 采用 monorepo 4 层严格分离的架构——每层不能跨越访问下层：
┌─────────────────────────────────────────────────────────────┐
│ Pi Monorepo 4 层架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Layer 1: pi-tui │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 终端用户界面 │ │
│ │ • 只能调用 pi-coding-agent 的接口 │ │
│ │ • 不知道 AI/工具/模型的任何细节 │ │
│ └────────────────────────┬────────────────────────────┘ │
│ │ │
│ Layer 2: pi-coding-agent │
│ ┌────────────────────────▼────────────────────────────┐ │
│ │ • Agent 循环编排 │ │
│ │ • 工具调度 │ │
│ │ • 扩展加载与管理 │ │
│ │ • 只能调用 pi-agent-core 和 pi-ai │ │
│ └────────────────────────┬────────────────────────────┘ │
│ │ │
│ Layer 3: pi-ai Layer 4: pi-agent-core│
│ ┌────────────────────────▼──────────┐ ┌──────────────────┐│
│ │ • 15+ 模型提供商适配 │ │ • 核心抽象定义 ││
│ │ • 统一接口： │ │ • 类型系统 ││
│ │ complete(prompt, tools) │ │ • 工具接口 ││
│ │ • 流式/非流式 │ │ • 消息模型 ││
│ │ • 提供商： │ │ ││
│ │ Anthropic, OpenAI, Google, │ │ 所有上层依赖 ││
│ │ DeepSeek, Grok, Ollama, │ │ 都通过这层定义 ││
│ │ OpenRouter, ... │ │ 的类型交互 ││
│ └───────────────────────────────────┘ └──────────────────┘│
│ │
│ 关键约束：每层只知道自己和下一层的接口。无跨层调用。 │
│ │
└─────────────────────────────────────────────────────────────┘7.3 只有 4 个内置工具
Pi 的核心哲学体现在它的工具数量上——只有 4 个：
| 工具 | 功能 | 为什么足够 |
|---|---|---|
read | 读取文件内容 | 所有工具中最基础的操作 |
write | 覆写/创建文件 | 创建新文件，完全替换内容 |
edit | 精确字符串替换 | 修改文件的一部分（类似 Claude Code Edit） |
bash | 执行 shell 命令 | 万能工具——编译、测试、git、搜索等都是它 |
┌─────────────────────────────────────────────────────────────┐
│ Pi 的 4 工具哲学 │
├─────────────────────────────────────────────────────────────┤
│ │
│ "4 tools are enough for everything." │
│ │
│ read + write + edit → 所有文件操作 │
│ bash → 所有进程操作，包括： │
│ • git (版本控制) │
│ • npm/pip/cargo (包管理) │
│ • grep/find (搜索) │
│ • docker (容器) │
│ • curl (网络请求) │
│ • tests (测试运行) │
│ │
│ 反例（Pi 明确不做的事）： │
│ ✗ 不会有 git_commit 工具 │
│ ✗ 不会有 search_code 工具 │
│ ✗ 不会有 web_fetch 工具 │
│ ✗ 不会有 todo_list 工具 │
│ → 如果有需要，通过扩展实现，而非内置 │
│ │
└─────────────────────────────────────────────────────────────┘7.4 极简系统提示
Pi 的系统提示只有约 1000 个 token。相比之下，Claude Code 的系统提示超过 8000 token，Codex CLI 超过 6000 token。Pi 相信：
- LLM 已经足够聪明，不需要手把手的提示工程
- 系统提示越短，留给实际代码的空间越大
- 复杂的指令反而增加模型困惑
7.5 YOLO 模式：默认信任
┌─────────────────────────────────────────────────────────────┐
│ Pi 的 YOLO 模式 │
├─────────────────────────────────────────────────────────────┤
│ │
│ YOLO Mode = 无审批，全自动执行 │
│ │
│ 大多数 Agent 的默认行为： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 每次文件修改 → 弹确认 → 用户批准 → 执行 │ │
│ │ 有的甚至每次 bash 命令也弹确认 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Pi 的默认行为： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 直接执行，无需确认 │ │
│ │ 适合信任 Agent 的熟练开发者 │ │
│ │ 不适合初学者或不确定的场景 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Pi 的立场："如果你不信任 Agent，就不应该使用它。 │
│ 确认对话框创造的是安全幻觉，不是真安全。" │
│ │
└─────────────────────────────────────────────────────────────┘7.6 显式拒绝的特性
Pi 的 README 开篇就列出它不做什么：
- MCP：不内置。有社区扩展实现了它
- 子 Agent：不内置。有社区扩展实现了它
- Plan Mode：不内置。有社区扩展实现了它
- Todo 工具：不内置。有社区扩展实现了它
- RAG：不内置
- 多模态：不内置
所有不在"4 工具"范围内的功能，要么通过扩展实现，要么不存在。这个"不做清单"本身就是一种设计文档。
7.7 TypeScript 扩展系统
┌─────────────────────────────────────────────────────────────┐
│ Pi 扩展系统 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 扩展是一个 TypeScript 模块，可以： │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 注册新工具 │ │
│ │ • 修改系统提示 │ │
│ │ • 拦截工具调用（before/after hooks） │ │
│ │ • 添加新模型提供商 │ │
│ │ • 修改 Agent 循环行为 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 社区已实现的扩展（50+）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • pi-plan-mode — 计划模式 │ │
│ │ • pi-sub-agents — 子 Agent 支持 │ │
│ │ • pi-mcp-server — MCP 支持 │ │
│ │ • pi-parallel-research — 并行搜索多个源 │ │
│ │ • pi-diff-review — 逐差异审查变更 │ │
│ │ • pi-chrome-cdp — Chrome DevTools 集成 │ │
│ │ • pi-mcp — 让 Pi 作为 MCP 工具给其他 Agent 用│
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 核心 vs 扩展的哲学分歧： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Claude Code: 核心内置计划模式 → 所有用户都有 │ │
│ │ Pi: 计划模式是扩展 → 需要的用户自己装 │ │
│ │ │ │
│ │ 两者的分歧在于 "什么是必需品，什么是偏好品"。 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘7.8 非交互模式：作为其他 Agent 的工具
Pi 的一个独特特性是它可以作为另一个 Agent 的工具使用：
┌─────────────────────────────────────────────────────────────┐
│ Pi 作为 Agent 的工具 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 模式 1: JSON Event Stream │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ $ pi --json "修复 src/utils.ts 的类型错误" │ │
│ │ {"event":"start","timestamp":...} │ │
│ │ {"event":"tool_call","tool":"read","path":"..."} │ │
│ │ {"event":"tool_call","tool":"edit","old":"...",...}│ │
│ │ {"event":"done","summary":"修复了 3 个类型错误"} │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 模式 2: Headless RPC │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 程序化调用 Pi，获取结构化结果 │ │
│ │ 适合 CI/CD、自动化脚本 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 模式 3: SDK 嵌入 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ import { PiAgent } from 'pi-agent-core'; │ │
│ │ const agent = new PiAgent({ model: '...' }); │ │
│ │ const result = await agent.run(task); │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 模式 4: pi-mcp（让 Pi 成为 MCP 工具） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Claude Code 用户安装 pi-mcp 扩展 │ │
│ │ → Claude Code 的 Agent 工具可以调用 Pi │ │
│ │ → Pi 变成 Claude Code 的一个子 Agent │ │
│ │ → 充分利用 Pi 的极简高效 + Claude Code 的工程生态 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘7.9 15+ 模型提供商
Pi 支持 15+ 模型提供商：
- Anthropic (Claude 系列)
- OpenAI (GPT 系列)
- Google (Gemini 系列)
- DeepSeek (V3, R1)
- Grok (xAI)
- Ollama (本地模型)
- OpenRouter (聚合网关)
- 以及更多
每个提供商通过 pi-ai 层的统一接口适配：complete(prompt, tools)。
7.10 树形对话历史
Pi 采用树形结构而非线性列表存储对话历史：
┌─────────────────────────────────────────────────────────────┐
│ Pi 树形对话历史 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 线性历史（大多数 Agent）： │
│ [user] → [assistant] → [tool] → [result] → [assistant] │
│ 只有一条路径，回溯意味着丢弃 │
│ │
│ 树形历史（Pi）： │
│ [user: 修复 bug] │
│ / \ │
│ [方案A: 重写] [方案B: 最小修改] │
│ / \ / \ │
│ [测试通过] [失败] [测试通过] [新bug] │
│ │
│ 优势： │
│ • 可以回溯到任意节点尝试不同方案 │
│ • 保留所有探索路径，不会丢失尝试 │
│ • 支持 "what if" 式交互 │
│ │
└─────────────────────────────────────────────────────────────┘7.11 设计哲学
Pi 的设计哲学是所有 6 个 Agent 中最极端的：Primitives, Not Features（原语，不是功能）。但与 Claude Code 的"原语 > 集成"不同，Pi 把它推到了极致：
- 不只是"没有 MCP 集成"——而是"明确拒绝内置 MCP"
- 不只是"工具少"——而是"只有 4 个工具，且以此为荣"
- 不只是"系统提示短"——而是"1000 token 就够了"
这种极端立场在 Agent 工程社区引发了大量讨论。支持者认为它回归了 Unix 哲学的本质——做一件事并做好。批评者认为它把太多复杂度推给了用户和扩展作者。
7.12 优势与局限
| 优势 | 局限 |
|---|---|
| 极简设计，概念清晰 | 开箱即用功能少 |
| 50+ 社区扩展覆盖各种需求 | 扩展质量参差不齐 |
| 15+ 模型提供商支持 | 核心功能依赖社区扩展 |
| 非交互模式可作为其他 Agent 的工具 | 极简风格不适合需要引导的初学者 |
| 树形对话历史支持多路径探索 | YOLO 默认模式有安全风险 |
| MIT 开源，可自由定制 | 文档相对较少 |
第8部分：全面对比
8.1 技术维度对比
┌─────────────────────────────────────────────────────────────────────────────┐
│ 6 大编程 Agent 全面技术对比 │
├──────────────┬──────────┬──────────┬──────────┬──────────┬──────────┬──────────┤
│ 维度 │ClaudeCode│Codex CLI │Grok Build│ KimiCode │ Reasonix │ Pi │
├──────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 许可证 │Proprieta.│Apache 2.0│Proprieta.│Apache 2.0│ MIT │ MIT │
├──────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 语言 │TypeScript│TS → Rust│ 未知 │TypeScript│ Go │TypeScript│
├──────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 模型支持 │ 单一 │ 单一 │ 单一 │ 单一 │ 单一 │ 15+ │
│ (默认) │(Anthropic)│(OpenAI) │ (xAI) │(Moonshot)│(DeepSeek)│ 多提供商 │
├──────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 上下文窗口 │ 200K │ 256K │ 256K │ 256K │ 128K │ 取决于 │
│ │ │ │ │ │ │ 模型 │
├──────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 工具总数 │ ~48 │ ~30 │ ~25 │ ~35 │ ~12 │ 4 │
│ (活跃) │(14-20) │(可变) │(可变) │(可变) │(全部) │(全部) │
├──────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 计划模式 │内置 │内置 │内置 │内置 │无 │社区扩展 │
│ │(PlanMode)│(TL;DR) │(3-Stage) │(RalphFlow)│ │ │
├──────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ MCP 支持 │内置 │内置 │内置 │内置 │无 │社区扩展 │
├──────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 子 Agent │内置 │无 │内置 │无 │无 │社区扩展 │
│ │ │ │(最多8个) │ │ │ │
├──────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 沙箱 │Worktree │OS Sandbox│无 │无 │无 │无 │
│ │(Git) │(Seatbelt)│ │ │ │ │
├──────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 输入价格 │ $3.00 │ $2.50 │ $1.00 │ ~$1.00 │ $0.27 │ 取决于 │
│ (per 1M) │ │ │ │ │ │ 模型 │
├──────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 输出价格 │ $15.00 │ $10.00 │ $2.00 │ ~$2.00 │ $1.10 │ 取决于 │
│ (per 1M) │ │ │ │ │ │ 模型 │
├──────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 扩展方式 │Skills │自定义 │Plugins │MCP │TOML配置 │TS扩展 │
│ │Hooks MCP │工具 │Hooks │ACP │ │ │
├──────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 核心循环 │TAOR │标准 │Plan-Search│标准 │Cache- │标准 │
│ │ │Agent循环 │-Build │Agent循环 │First │Agent循环 │
├──────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 状态 │活跃 │已终止 │活跃 │活跃 │活跃 │活跃 │
│ (2026.07) │v2.1.202 │(2026.04) │v0.1 │v2.x │v1.0 │v0.63 │
└──────────────┴──────────┴──────────┴──────────┴──────────┴──────────┴──────────┘8.2 设计哲学维度对比
| 维度 | Claude Code | Codex CLI | Grok Build | KimiCode | Reasonix | Pi |
|---|---|---|---|---|---|---|
| 模型策略 | 单后端深度优化 | 单后端全自动 | 单后端并行 | 单后端本土化 | 单后端极致缓存 | 多后端通用 |
| 工具策略 | 渐进披露 (~20) | 中量 (~30) | 中量 (~25) | 中量 (~35) | 精简 (~12) | 极简 (4) |
| 自动化级别 | 中等 | 可配置 (3档) | 高 (并行) | 中等 | 中等 | 极高 (YOLO) |
| 首要设计目标 | 可靠性 | 全自动化 | 质量 (通过并行) | 本地化体验 | 成本效率 | 简洁性 |
| 安全哲学 | 隔离 + 审批 | 沙箱 + 审批 + 模式 | 本地优先 | 标准审批 | 标准审批 | 信任默认 |
第9部分：设计哲学谱系
9.1 从全功能到极简的光谱
6 个 Agent 可以在"全功能 vs 极简"的光谱上排列：
┌─────────────────────────────────────────────────────────────┐
│ 设计哲学光谱：全功能 ←─────────→ 极简主义 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Grok Codex ClaudeCode KimiCode Reasonix Pi│
│ Build CLI │
│ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ ▼ │
│ │
│ 多Agent 3种模式 渐进披露 对标但不 单一后端 4工具│
│ 并行 全自动 原语至上 照搬 极致缓存 1000 │
│ Arena 端到端 Hooks+ 双模式 Append- token│
│ Mode 沙箱 Skills Print/Wire Only YOLO│
│ │
│ 哲学： 哲学： 哲学： 哲学： 哲学： 哲学：│
│ 计算量换 自动化是 工具精细度 开发者体验 成本效率 做一件│
│ 质量 光谱 决定上限 优先 优先 事并做│
│ │好它 │
└─────────────────────────────────────────────────────────────┘9.2 工具数量的深层含义
工具数量不是越多越好——这是一个关键洞察：
┌─────────────────────────────────────────────────────────────┐
│ 工具数量的权衡 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 工具多 (~48 个)： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ ✅ 每个工具高度专业化，错误率低 │ │
│ │ ✅ 工具描述精确，LLM 决策更准确 │ │
│ │ ❌ 工具列表太长占用上下文 │ │
│ │ ❌ LLM 可能选错工具（决策瘫痪） │ │
│ │ ❌ 维护成本高 │ │
│ │ 代表：Claude Code（用渐进披露缓解） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 工具少 (4 个)： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ ✅ 上下文占用极小 │ │
│ │ ✅ 不会选错工具（因为没有选择） │ │
│ │ ✅ 维护成本极低 │ │
│ │ ❌ 每个工具非常宽泛，LLM 使用可能不精确 │ │
│ │ ❌ Bash 作为万能工具，安全边界模糊 │ │
│ │ 代表：Pi │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 中间地带 (~12-35 个)： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 在特殊化和简洁之间找平衡 │ │
│ │ 代表：Reasonix, KimiCode, Codex CLI, Grok Build │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘9.3 模型耦合度的光谱
┌─────────────────────────────────────────────────────────────┐
│ 模型耦合度光谱 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 深度耦合 ←─────────────────────────────→ 模型无关 │
│ │
│ Reasonix ClaudeCode Grok Codex KimiCode Pi │
│ (仅 (Anthropic (仅 (仅 (仅 (15+ │
│ DeepSeek) 优先,但 xAI) OpenAI) Moonshot) 提供商)│
│ 可通过 │
│ API切换) │
│ │
│ 深度耦合的优势： │
│ • 最大化特定模型特性（如 prefix-cache） │
│ • 性能最优 │
│ │
│ 模型无关的优势： │
│ • 用户自由选择模型 │
│ • 模型降价或升级时无缝切换 │
│ • 不受单一供应商风险影响 │
│ │
└─────────────────────────────────────────────────────────────┘9.4 共同模式：所有 Agent 都在解决同一个问题
尽管差异巨大，6 个 Agent 共享一些核心设计模式：
┌─────────────────────────────────────────────────────────────┐
│ 6 个 Agent 的共同设计模式 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. Agent 循环 (Agent Loop) │
│ 所有 Agent 都实现了 while(finish_reason != stop) 循环 │
│ LLM 调工具 → 执行 → 返回结果 → 再调 → ... → 最终回答 │
│ │
│ 2. 工具定义 (Tool Schema) │
│ 所有 Agent 都通过 JSON Schema 向 LLM 声明可用工具 │
│ name + description + parameters 三元组 │
│ │
│ 3. 上下文管理 (Context Management) │
│ 所有 Agent 都必须处理"messages 数组不断增长"的问题 │
│ 解法各异：压缩(ClaudeCode)、截断(Codex)、缓存(Reasonix) │
│ │
│ 4. 文件操作安全 (Safe File Operations) │
│ 所有 Agent 都有某种形式的文件修改安全机制 │
│ Edit 精确匹配 / 沙箱隔离 / 审批确认 │
│ │
│ 5. 错误恢复 (Error Recovery) │
│ 工具调用失败 → 错误信息返回 LLM → LLM 重试 │
│ Reasonix 的 Tool-Call Repair 是最激进的实现 │
│ │
└─────────────────────────────────────────────────────────────┘第10部分：选型建议
10.1 按场景选型
┌─────────────────────────────────────────────────────────────┐
│ 按场景选型决策树 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 你是企业团队？ ──Yes──→ Claude Code（最成熟的工程实践） │
│ │ 或 Codex（如还在维护） │
│ │ │
│ No │
│ │ │
│ ▼ │
│ 预算极度敏感？ ──Yes──→ Reasonix（DeepSeek，极致便宜） │
│ │ 或 Grok Build（$1/$2 per 1M） │
│ │ │
│ No │
│ │ │
│ ▼ │
│ 想要最大控制权？ ──Yes──→ Pi（4 工具 + 50+ 扩展） │
│ │ 从零搭建你的工作流 │
│ │ │
│ No │
│ │ │
│ ▼ │
│ 在国内开发？ ──Yes──→ KimiCode（中国生态、中文优先） │
│ │ MoE 架构 + AMD 优化的极速体验 │
│ │ │
│ No │
│ │ │
│ ▼ │
│ 追求最高代码质量？ ──Yes──→ Grok Build（Arena Mode 并行） │
│ 多 Agent 比单 Agent 质量更高 │
│ │
└─────────────────────────────────────────────────────────────┘10.2 按技术栈选型
| 你的技术栈 | 推荐 Agent | 原因 |
|---|---|---|
| Anthropic API 用户 | Claude Code | 原生集成，最优体验 |
| OpenAI API 用户 | Codex CLI (历史) 或 ChatGPT | 原生支持，但 Codex 已终止 |
| DeepSeek API 用户 | Reasonix | 专属优化，缓存命中率 94%+ |
| xAI / Grok 用户 | Grok Build | 原生集成，最低价格 |
| Moonshot / Kimi 用户 | KimiCode | 原生模型，256K 上下文 |
| 多模型切换需求 | Pi | 15+ 提供商，自由选择 |
10.3 如果你想构建自己的 Agent
从这 6 个 Agent 中提取的关键设计教训：
┌─────────────────────────────────────────────────────────────┐
│ 构建自己的 Agent：从 6 个实践中学习 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 从 Claude Code 学习： │
│ • 渐进披露——不要让 LLM 看到不需要的工具 │
│ • Edit 精确替换——比行号 patch 更可靠 │
│ • 压缩而非截断——用户体验差距巨大 │
│ │
│ 2. 从 Codex CLI 学习： │
│ • 模式 + 沙箱 + 审批 三个正交维度 │
│ • 不要把安全做成二选一 │
│ │
│ 3. 从 Grok Build 学习： │
│ • 并行多输出 + 裁判 = 质量跃升 │
│ • 但要算清楚 N× token 成本的账 │
│ │
│ 4. 从 KimiCode 学习： │
│ • Shell/Agent 双模——不强制改变工作流 │
│ • Print/Wire 模式——Agent 可嵌入管道 │
│ │
│ 5. 从 Reasonix 学习： │
│ • Append-Only = 缓存友好 │
│ • 深度了解你的模型特性，而非追求通用 │
│ │
│ 6. 从 Pi 学习： │
│ • "不做什么"和"做什么"同样重要 │
│ • 树形历史 > 线性历史（尤其是探索性任务） │
│ • 把 Agent 设计成可被其他 Agent 调用的组件 │
│ │
└─────────────────────────────────────────────────────────────┘10.4 Agent 工程的未来趋势
基于这 6 个 Agent 的演化路径，可以观察到的趋势：
- Harness 变薄：随着模型推理能力增强，Agent 层的很多补偿性工程（精细提示、复杂状态机）可以移除。Claude Code 明确声明了这一方向。
- Agent 作为组件：Pi 的 pi-mcp 和 KimiCode 的 Wire Mode 都在指向同一个方向——Agent 不是孤立的终端工具，而是可被程序调用的组件。
- 缓存即架构：Reasonix 证明了缓存策略不是性能优化，而是架构决策。Append-Only 消息管理为缓存而生。
- 并行化是质量杠杆：Grok Build 的 Arena Mode 用 N× token 换质量提升，这在未来将成为标准选项。
- 中国生态独立演进：KimiCode 和 Reasonix 不是为了"走向世界"而设计，而是深度服务本土开发者的需求——这种"非全球化"策略本身就是一种创新。
核心总结
总结1：没有银弹
┌─────────────────────────────────────────────────────────────┐
│ 6 个 Agent，6 种哲学，没有标准答案 │
│ │
│ 选择取决于： │
│ • 你的模型偏好（哪个 API 最便宜/最快/最好用） │
│ • 你的安全需求（审批每一步 vs 完全信任） │
│ • 你的定制需求（开箱即用 vs 从零组装） │
│ • 你的地区生态（国际 vs 中国） │
│ • 你的预算（$0.27 到 $15.00 per 1M tokens） │
└─────────────────────────────────────────────────────────────┘总结2：工具数量是设计决策，不是技术限制
工具多 → 专业化高，但上下文占用大。工具少 → 简洁，但每个工具责任宽泛。Claude Code 的渐进披露是最优雅的解决方案。
总结3：模型耦合度是战略选择
深度耦合（Reasonix）→ 极致性能。模型无关（Pi）→ 自由度和抗风险能力。两者都有道理，取决于你的优先级。
总结4：Agent 的未来是"变薄"和"组件化"
两个趋势并行：一方面 harness 层随模型进步而变薄；另一方面 Agent 从终端工具变成可嵌入其他系统的组件。Pi 的 pi-mcp 是这个趋势的最佳例证——最极简的 Agent 成为最通用的组件。
总结5：中国生态正在形成独立范式
KimiCode（Moonshot）和 Reasonix（DeepSeek）代表了不同于硅谷的 Agent 设计思路：深度服务本土市场、利用本土基础设施（AMD MI355X）、解决本土问题（合规、中文生态）。这不是"追赶"，而是"分叉"。
章节测试
测试1：架构理解
Claude Code 的 TAOR 循环中，哪个阶段负责判断 finish_reason 并决定下一步？
测试2：设计哲学
Codex CLI 的"模式 + 沙箱 + 审批"三个维度为什么被设计为"正交"而非"嵌套"？
测试3：并行策略
Grok Build 的 Arena Mode 用 8 个并行 Agent 竞争输出质量。这样做的主要代价是什么？
测试4：缓存设计
Reasonix 为什么采用 Append-Only 消息列表，而不是允许修改中间的消息？
测试5：极简主义
Pi 只有 4 个内置工具（read/write/edit/bash）。它如何实现 git 操作？
测试6：模型策略
在 6 个 Agent 中，哪个是唯一支持 15+ 模型提供商的？哪个是唯一故意只支持单一后端的？
测试7：选型决策
一个在国内开发、使用 DeepSeek API、预算非常有限的个人开发者，应该优先考虑哪两个 Agent？为什么？
参考答案
测试1答案
答案：DECIDE（决定）阶段。Harness 检查 API 响应的 finish_reason："stop" → 返回最终结果；"tool_calls" → 解析工具调用并执行；"length" 或其他 → 触发续写或错误处理。
测试2答案
答案：正交设计意味着三个维度可以独立组合——比如你可以同时使用"Full Auto 模式 + 沙箱开启 + 审批关闭"，也可以"Suggest 模式 + 沙箱关闭 + 审批开启"。如果是嵌套设计（比如"沙箱模式"是一个整体预设），用户就失去了灵活组合的能力。正交性 = 更大配置自由度。
测试3答案
答案：主要代价是 token 成本。8 个并行 Agent 意味着约 8× 的 token 消耗。如果输入的 prompt 很大（如分析整个代码库），8 个 Agent 各自处理完整上下文，总成本会非常可观。此外，裁判 LLM 本身也消耗额外的 token。
测试4答案
答案：因为 DeepSeek 的 prefix-cache 机制依赖前缀不变。Append-Only 保证每次新请求的前缀部分与上次请求完全一致 → 缓存全部命中 → 只计算新增 token。如果修改中间的消息，修改位置之后的所有 cache 都会失效，缓存命中率骤降。
测试5答案
答案：通过 bash 工具执行 git 命令。比如 git add, git commit, git diff 等。Pi 的哲学是 bash 是一个万能工具——所有可以通过命令行完成的操作都不需要专用工具。这就是"原语 > 集成"的极端体现。
测试6答案
答案：
- 唯一支持 15+ 模型提供商的：Pi（通过 pi-ai 层的统一接口）
- 唯一故意只支持单一后端的：Reasonix（故意深度耦合 DeepSeek，以获取极致缓存效率）
测试7答案
答案：优先考虑 Reasonix 和 KimiCode。
- Reasonix：原生支持 DeepSeek API，缓存命中率 94%+，435M tokens 仅需 ~$12，成本最低。
- KimiCode：中国生态优先，中文界面，国内 API 可用性好。MoE 架构 + AMD 合作带来性能优势。
如果预算不是主要考量，KimiCode 的中国生态和开发体验可能更适合。如果预算第一优先，Reasonix 的极致成本控制无出其右。
相关笔记
- [[01-function-calling]] - Function Calling 基础
- [[04-agent-loop]] - Agent 循环的多种实现方式
- [[05-agent-workflow]] - Agent 工作流设计
- [[09-mcp]] - MCP 协议详解
- [[10-sub-agents]] - 子 Agent 架构设计
下一步学习
- [ ] 阅读 28 - 领域 Agent 的确定性工具执行，理解高副作用领域为何需要“先收集、后编译、再确认执行”
- [ ] 阅读 18 - Agent 安全沙箱，深入理解 Codex CLI 的 Apple Seatbelt 等方案
- [ ] 阅读 06 - 多 Agent 协作架构，对比 Grok Build Arena Mode 与 Claude Code 子 Agent
- [ ] 动手实践：选择两个 Agent 完成同一个编码任务，记录差异
- [ ] 思考：如果你要构建自己的 Agent，你会站在光谱的哪个位置？为什么？
学习状态：🟡 开始学习