# hey vs pi / codex / opencode / Claude Code — 对比分析
> 基于 `DESIGN.md`（实现态：M1-M13 全部完成 + thinking 按协议原生语义重构 + CLI 标准化）。维度：内核、扩展、工具与权限、上下文、会话、代理、多模型、UI、分发与维护。
## 1. 定位概览
| 语言 | Rust | Node.js (TS) | Rust | TypeScript | Node.js |
| 内核形态 | 单 crate，10 文件 | 单包模块化 | 几十个 crate 的 workspace | client/server 双进程 | 闭源黑盒 |
| UI | v1 纯 CLI 流式；TUI 留位 | 成熟 TUI | 成熟 TUI | 成熟 TUI | 成熟 TUI |
| 扩展 | 配置工具 + MCP + Skills（零代码） | JS 扩展 + Skills | Rust trait + MCP + Skills | TS 插件 + MCP | MCP + hooks + subagents + Skills |
| 服务商绑定 | 任何 OpenAI 兼容端点 | 自定义 provider | OpenAI 系 + Ollama + 网关 | 多 provider（最强） | Claude（官方） |
| 定位 | 轻量嵌入式/个人 agent 内核 | 多功能个人 agent + SDK 平台 | OpenAI 官方生产级 | 开源多模 agent | 商业产品 |
## 2. 分维度对比
### 2.1 内核与架构
| **hey** | ✅ 最简：循环 + 3 个 trait。可整体被第三方库化嵌入（模块 API，不 exit）；改一行配置即可适配新模型 |
| **codex** | ❌ 最重：几十 crate + bazel，为生产级规模化设计，学习与构建成本高 |
| **opencode** | ⚠️ client/server 分离能力强（远程 agent），但架构复杂度高 |
| **claude code** | ⚠️ 无从读源码；功能完整但不可裁剪 |
| **pi** | ⚠️ 功能全面但模块耦合较多，Node 生态依赖面大 |
### 2.2 扩展机制（用户重点）
| **hey** | 配置 JSON 工具 + MCP stdio + SKILL.md | ✅ 全部数据驱动：零编译、零依赖、可分享（拷目录即装）；❌ 表达力上限=命令模板，复杂逻辑（解析/状态/回调）需回写 Rust |
| **pi** | JS 扩展（hooks/slash 命令等） | ✅ 表达力强，生态大；❌ 需要会写 JS、有版本兼容问题 |
| **codex** | Rust trait + MCP + skills | ✅ 能力最强；❌ 扩展=改 Rust 重编译，门槛最高 |
| **opencode** | TS 插件 + MCP | ✅ 生态大；❌ 插件与内核版本绑定脆弱 |
| **claude code** | MCP + hooks + subagents + Skills | ✅ hooks/subagents 组合能力强；❌ 配置语法多且密，学习成本高 |
**结论**：hey 的扩展模型≈claude code 的 MCP+Skills 子集（去 hooks），够覆盖"加工具、加知识、接外部能力"三类需求；缺 hooks 这类**事件钩子**——这是与 CC 最大的功能缺口，可后续以配置化 hooks 补（低优先级）。
### 2.3 工具与权限安全
| **hey** | bash / read / write / edit / grep（5 个） | allow 列表（默认全权限，未匹配 blocked）；**无沙箱** |
| **claude code** | 更全（含 git、web、思维工具） | 分层权限 + 可编程 hooks + 审批流；最强 |
| **codex** | 全 + sandbox（seccomp/landlock） | 沙箱隔离，最安全 |
| **opencode** | 全（含 LSP、git） | permission 配置 |
| **pi** | 中（bash/fs 等） | 命令确认模式 |
**结论**：hey v1 权限"够家用"（个人本机信任模型），但**无沙箱 + 权限规则较粗**是明确短板；家庭使用可接受，接 CI/多租户不可。v2 可选补：allow 规则支持参数级通配细化。
### 2.4 上下文管理
| **hey** | 预算裁剪 + 复用同一 provider 发摘要请求压缩（两级） |
| **claude code** | auto-compact 自动总结 + 显式 /compact |
| **codex** | 自动 compaction + 手动 |
| **opencode** | compaction + 上下文编辑 |
| **pi** | 手动清理/压缩（弱） |
**结论**：hey 与主流持平；复用 provider 做摘要比 CC 的专用总结模型更省成本，实现也更简单。
### 2.5 会话
| **hey** | JSONL 追加 + `--resume` / `--last`（无索引无 DB） |
| **claude code** | `--resume`/`--continue`，会话管理 UI |
| **codex** | resume + thread 管理 |
| **opencode** | session 列表 + 恢复 |
| **pi** | session 持久化 |
**结论**：功能持平；hey 的 JSONL 最简，且天然与 `--output json` 共用格式（一个格式两用）。
### 2.6 代理支持（用户重点）
| **hey** | reqwest 原生 http/https/socks5，`--proxy`/配置/env 三来源 + NO_PROXY，user:pass 认证 |
| **codex** | 独立 network-proxy crate，同样三协议 |
| **claude code** | http/https（socks 支持受限/需手动） |
| **pi / opencode** | 走 Node 运行时代理，可配但非一等公民 |
**结论**：hey 处于第一梯队，且 proxy 模块纯数据层可单测，是设计中最早成熟的一块。
### 2.7 多模型支持
| **hey** | OpenAI 兼容协议全覆盖（OpenAI/DeepSeek/Kimi/通义/Ollama/vLLM/CC 兼容端点） |
| **opencode** | 最全（原生 Anthropic/Google/OpenAI + 网关） |
| **hey** | 三个协议适配器（OpenAI 兼容 / Anthropic / Google Gemini），配置声明协议 |
| **codex** | OpenAI 原生 + Ollama + 网关 |
| **claude code** | 绑定 Claude（走网关可间接接他厂，非官方） |
| **pi** | 自定义 provider（配置级） |
**结论**：hey 的"兼容协议+三项配置"覆盖现实需求 95%（国内主流模型几乎全部 OpenAI 兼容）；代价是拿不到协议特性（如 Claude 原生 thinking/缓存控制、Ollama 原生 API），需要时再加原生 Provider 实现即可（trait 已留位）。
### 2.8 UI 与交互
| **hey** | REPL（rustyline 历史/行编辑）：`/model` 切模型、`/effort` 切推理强度、`/thinking` toggle 显示、`/usage` `/compact` `/reload` `/skill:<name>` `/sessions`；流式 + 推理灰字；`--output json` 数据流（thinking 事件不受 UI 开关影响） |
| **其余四个** | 全部成熟 TUI |
**结论**：hey 无 TUI 仍是与"可用商品"的直观差距，但 REPL 命令面已对齐主流（`/effort`、`/thinking` 与 Claude Code /pi 同款）；`Output` trait 已隔离 UI，接 ratatui 做只读展示版即可追平 80%。
## 3. hey 的优劣总结
### 优势（相对参考项目）
1. **最简内核**：单 crate 无框架感；别人要理解整体才能改，hey 改 `agent.rs` 主循环（配 `agent/` 四子模块：提示构建 / 上下文裁剪 / 工具流水线 / compress）即可
2. **单一二进制分发**：`cargo build --release` 一个文件，无 Node 运行时/依赖树，跨平台拷贝即用（CC/opencode/pi 都要 Node 环境）
3. **扩展零门槛**：配置/MCP/Skills 全部是文件级协议，分享=拷目录；不引入语言级插件的版本地狱
4. **代理一等公民**：三协议原生，国内网络场景刚需
5. **可库化嵌入**：模块 API（`agent::run_agent` / `tools::Registry` / `ui::Output` / `config::Config`）可直接被 CI、编辑器插件、自己的工具链调用（错误经 `RunStats` 传播，不 exit）——pi 有 SDK 但需 JS 环境，Rust 侧没有等价物
6. **上下文压缩自包含**：不依赖第二模型/专用服务
### 劣势（相对参考项目）
1. **无 TUI**（v1）：交互体验差距最直观
2. **权限偏弱**：无沙箱、allow 规则粗（vs CC 可编程权限、codex seccomp）
3. **无事件钩子**：CC 的 hooks（PreToolUse 等）、opencode 的插件事件，hey 只能靠 MCP 间接实现
4. **协议特性受限**：OpenAI 兼容协议拿不到原生 reasoning/缓存等特性
5. **生态空白**：无现成插件市场；MCP 是唯一生态接入点（好在 MCP 已成事实标准，弥补大半）
## 4. 定位结论与建议
**hey 的定位不是"第 5 个 CC/opencode"，而是"可裁剪的个人 agent 内核"**：对标的其实是"想要一个自己的、能看懂全部代码、能嵌入任何脚本的 coding agent"的场景 —— 这一档目前没有 Rust 轻量选项（codex 太重，pi/opencode 绑 Node）。
### 建议的取舍（维持 v3 不动摇）
| 保持 | 单 crate、3 trait、同步回调、单配置文件 —— 这些是"精简"的立身之本 |
| M4 后补 | ~~TUI（ratatui 只读展示版）~~ 已定不做（M4 实际做了信任/文档/错误恢复）；TUI 维持明确不做 |
| v2 候选 | 配置化 hooks（PreToolUse/PostToolUse 命令级）—— 补 CC 缺口且保持数据驱动 |
| 不做 | 沙箱（个人场景价值/成本比低）、语言级插件（违背定位） |
## 5. 一句话
内核比 pi/opencode/CC 干净得多，代理与扩展成本优于多数参考；代价是 v1 无 TUI、权限弱一档 —— 这两点不影响"能干活"，只影响"好不好看、敢不敢放开跑"。