Harness 选型指南：Superpowers vs Deep Agents vs Claude Code 原生 vs Codex
TL;DR
没有"最好的 harness"，只有最适合你场景的。一张决策树：
你要解决什么问题？
│
├─ Agent 太散漫，跳步、偷懒、不测试
│ → Superpowers（纪律框架）
│
├─ 需要模型无关的 SDK，自建 agent 产品
│ → Deep Agents（可编程 harness SDK）
│
├─ 日常用 Claude Code，想优化它的表现
│ → Claude Code 原生机制（CLAUDE.md + hooks + skills + rules）
│
└─ 用 OpenAI 模型，需要 OS 级沙箱隔离
→ Codex SDK
一、四个方案一览
| 维度 | Superpowers | Deep Agents | Claude Code 原生 | Codex SDK |
|---|---|---|---|---|
| 本质 | Markdown 纪律框架 | Python/JS SDK | 内置配置体系 | 沙箱 Agent SDK |
| Stars | 138K | 19.6K | N/A（内置） | N/A（官方） |
| 运行时 | 无（宿主 agent 运行） | LangGraph | Claude Code 进程 | Codex runtime |
| 模型绑定 | 无 | 无（默认 Sonnet） | Claude only | OpenAI only |
| 安装 | /plugin install | pip install deepagents | 零安装（内置） | pip install codex-sdk |
| 核心机制 | 硬门控 + 反合理化 | 中间件管道 | hooks + rules + skills | OS 沙箱 + apply_patch |
| 学习曲线 | 低（读 Markdown） | 中（学 LangGraph 概念） | 低（配置文件） | 中（沙箱配置） |
| 协议 | MIT | MIT | 部分开源 | 部分开源 |
二、逐个拆解
Superpowers：解决"Agent 纪律"问题
最适合：你的 agent 技术能力够，但工作方式有问题——跳过测试、不做设计就写代码、不 review 就合并、debug 靠猜。
核心价值：
- 七阶段强制流水线（brainstorming → plan → worktree → subagent 执行 → TDD → review → 收尾）
- 铁律级硬门控（"先写了代码？删掉重来。没有例外。"）
- 反合理化设计——每个 skill 包含 agent 实际会说的借口和堵死它的对抗措施
- 两阶段 review（先 spec 合规，后代码质量）
不适合：
- 你需要自定义 agent 产品（Superpowers 不是 SDK）
- 你需要上下文压缩/token 管理（依赖宿主 agent）
- 你需要持久化文件系统后端（依赖宿主 agent）
代表案例：Chardet 7.0.0 —— 41x 性能提升，96.8% 准确率，2,161 文件测试覆盖
Deep Agents：解决"Agent 能力"问题
最适合：你在构建自己的 agent 产品/工具，需要模型无关的 planning + 文件系统 + subagent + 上下文压缩能力。
核心价值：
create_deep_agent()一行代码获得完整 agent 能力- 11 层可组合中间件管道
- 6 种可插拔后端（StateBackend → FilesystemBackend → 沙箱）
- 自动上下文压缩（85% 阈值触发，保留 10%）
- 模型无关——支持 Claude、GPT、Gemini、开源模型
不适合：
- 你只是想让现有 coding agent 更好（不需要 SDK）
- 你需要 OS 级沙箱（Deep Agents 只有工具级边界）
- 你需要纪律强制（Deep Agents 不管 agent 是否跳步）
代表数据：Terminal Bench 2.0 — Sonnet 4.5 跑到 42.65%，GPT-5.2-Codex 跑到 66.5%
Claude Code 原生：解决"日常效率"问题
最适合：你日常用 Claude Code，想让它在你的项目上表现更好，不想引入外部依赖。
核心价值：
- 零安装——全部内置
- CLAUDE.md 分层加载（home → 项目 → 子目录）
.claude/rules/*.md路径限定规则- Hooks 在 25+ 生命周期事件上注入确定性行为
- Skills 按需加载，支持动态上下文注入（
!`command`） settings.json权限控制（allow/deny/ask）
不适合：
- 你需要跨模型支持
- 你在构建 agent 产品（不是用 agent 做开发）
- 你需要多 agent 编排（Claude Code 的 subagent 是内置的，定制性有限）
代表数据：日均 ~135K GitHub 公共提交（约占全部的 4%）
Codex SDK：解决"安全隔离"问题
最适合：你用 OpenAI 模型，需要在不可信环境中运行 agent，OS 级沙箱是硬需求。
核心价值：
- OS 级沙箱——最强的安全隔离
- 与 Codex 模型深度集成（
apply_patch是训练时就内置的工具） - MCP server 模式
不适合：
- 你用 Claude 或其他模型
- 你不需要 OS 级隔离
- 你需要丰富的可观测性（LangSmith 远强于 Codex 的内置监控）
注意：Codex 模型和 apply_patch 工具是协同训练的——换成其他工具会导致性能下降。
三、可以组合使用
这四个方案不互斥。常见组合：
| 组合 | 场景 |
|---|---|
| Claude Code 原生 + Superpowers | 最常见。用 Claude Code 内置机制做基础配置，用 Superpowers 做工作流纪律。/plugin install 即可。 |
| Deep Agents + Superpowers Skills | 构建自己的 agent 产品时，把 Superpowers 的 SKILL.md 文件加载到 Deep Agents 的 skills 系统中。 |
| Claude Code 原生 + 自定义 Skills | 不需要 Superpowers 的完整流水线，只需要几个特定工作流。自己写 SKILL.md。 |
不推荐的组合：
- Codex SDK + Claude 模型（
apply_patch与 Claude 不兼容） - 同时装大量 Superpowers skills + 大量 MCP servers（上下文预算不够）
四、决策矩阵
回答这五个问题，选出你的方案：
| 问题 | Superpowers | Deep Agents | Claude Code 原生 | Codex SDK |
|---|---|---|---|---|
| 你在构建 agent 产品吗？ | 是 | |||
| 你需要 OS 级沙箱吗？ | 是 | |||
| 你需要跨模型支持吗？ | 是 | 是 | ||
| Agent 的主要问题是纪律？ | 是 | |||
| 你只想优化现有 Claude Code？ | 是 |
如果多个"是"：优先选最左边的"是"对应的方案，然后用组合覆盖其余需求。
五、从零开始的推荐路径
如果你是 Claude Code 用户（大多数人）
Week 1: Claude Code 原生
→ CLAUDE.md + 验证 hook + 2-3 条 rules
→ 跑真实任务，记录失败模式
Week 2-3: + Superpowers
→ /plugin install superpowers
→ 让 brainstorming + TDD + code review 强制执行
→ 观察工作质量变化
Month 2+: 按需定制
→ 写自定义 skills 解决项目特定问题
→ 如果标准 skills 不够，参考 Superpowers 的 writing-skills 方法论
如果你在构建 agent 产品
Week 1: Deep Agents SDK
→ create_deep_agent() + 默认配置
→ 选择合适的后端（StateBackend → FilesystemBackend）
Week 2-3: 定制中间件
→ 写自定义中间件处理领域逻辑
→ 配置 subagent 分工和模型分层
Month 2+: 集成生态
→ LangSmith 可观测性
→ ACP 编辑器集成
→ 沙箱后端（LangSmith / OpenShell）
如果你用 OpenAI 模型且安全是硬需求
Week 1: Codex SDK
→ 配置 OS 级沙箱
→ 使用 apply_patch 工具（不要换）
Week 2+: 补充纪律
→ 将 Superpowers 的 TDD 和 debugging 方法论
手动集成到 AGENTS.md 中（需要适配 Codex 的指令格式）
六、一句话总结
- Superpowers：让 agent 守规矩
- Deep Agents：让你能造 agent
- Claude Code 原生：让 Claude Code 更懂你的项目
- Codex SDK：让 agent 在安全沙箱里跑
选错了不会死——它们都可以随时切换或组合。选对了会省很多时间。
