AI 编程框架全景比较 - 使用场景、优势与选型指南

AI 编程框架全景比较 —— 使用场景、优势与选型指南

一、核心认知：不是竞品，是分层叠加

这八个工具（Claude Code、Codex、OpenCode、OpenClaw、Hermes、SpecKit、Superpowers、Paperclip）不是横向竞品，而是从下到上的分层叠加增强关系。它们在产品形态上就不属于同一类——有的是独立 CLI 软件，有的是运行时框架，有的是工具包，有的是插件，有的是管理平台。

1.1 工具总览

1.2 关键区分：三条赛道

在比较之前，先把工具归入正确的赛道：

赛道一：编码执行工具（谁写代码） ├── Claude Code — Anthropic 嫡系，专有 ├── OpenAI Codex — OpenAI 嫡系，开源 └── OpenCode — 社区驱动，模型中立（75+ 提供商） 赛道二：个人 Agent 运行时（谁攒经验、跑后台） ├── Hermes — 偏编码场景的记忆+技能，三层记忆体系 └── OpenClaw — 偏全能管家，50+ 消息通道，高系统权限 赛道三：规范与治理（谁定标准、管团队） ├── SpecKit — 需求规格，单一事实源 ├── Superpowers — 执行纪律，流程护栏 └── Paperclip — 多 Agent 调度，预算+权限+审计

同一赛道内才有竞争关系，跨赛道是比较职责差异。

二、四层标准分层架构

Agent 工具链和后端架构一样——分层解耦、按需叠加、能力互补。不是层数越多越高级，刚好匹配项目的约束强度，才是最优解。

2.1 演进逻辑

最早：只用原生编码工具 → 解决"能不能写代码" ↓ 后来：加了运行时层 → 解决"长期项目反复同步上下文成本太高" ↓ 再后来：加了规范纪律层 → 解决"AI 写的代码质量不可控、多人协作容易失焦" ↓ 最后：加了编排治理层 → 解决"项目和 Agent 数量上来后的规模化管理问题"

2.2 四层职责

2.3 两条关键回路

• 经验沉淀回路：下层执行结果 → 沉淀回运行时层（记忆/技能）。没有这条回路，每次执行都是从零开始。
• 校验回退回路：校验失败 → 回退到执行环节重新修复。没有这条回路，规范和纪律形同虚设。

三、赛道一：编码执行工具深度对比

三个工具同属执行层，存在直接竞争关系。选哪个主要取决于你的模型生态偏好和开源需求。

3.1 功能对比

3.2 选型建议

3.3 什么时候只用执行层工具就够了？

判断标准（三点全满足）：

• 任务生命周期短，未来不会反复迭代
• 单人执行，不需要多人对齐标准
• 没有强质量、强审计要求

典型场景：临时调试、单次 Bug 修复、小功能开发、快速原型验证

警示：改个单行 Bug 也要开全套框架，工具启动和上下文准备的时间已经超过修复本身——本末倒置。架构的克制，很多时候比加功能更考验水平。

四、赛道二：个人 Agent 运行时深度对比

Hermes 和 OpenClaw 同属运行时层，但定位和权限差异巨大。

4.1 功能对比

4.2 选型建议

4.3 什么时候加运行时层？

判断标准（满足任意两条）：

• 同一项目长期维护，反复回头修改
• 每次新开会话都要重复解释项目背景、编码习惯
• 需要沉淀可复用经验、技能
• 需要后台定时自动任务
• 需要多端（手机/其他设备）触达 Agent

4.4 运行时层常见陷阱

五、赛道三：规范与治理层深度对比

5.1 SpecKit vs Superpowers（规范层内部）

5.2 什么时候加规范层？

加 SpecKit 的判断标准：

• 多人协作，需要统一需求标准
• 有合规审计、需求追溯需求
• 需求边界复杂、容易漂移

加 Superpowers 的判断标准：

• 需要守住 TDD、评审、自测等质量底线
• 不想上重型规范，但质量不能全靠模型自觉
• 小团队协作，需要统一的执行纪律

分级策略（关键）：

临时任务/单行修复 → 只用执行层工具 + 变更说明 ↓ 复杂度上升 中小型功能迭代 → Superpowers 守质量 + minimal/light Spec ↓ 影响面变大 核心模块/公共接口 → light Spec + Superpowers ↓ 交付要求提高 大型交付/强合规 → full Spec + Superpowers + 审计留痕

5.3 什么时候加治理层（Paperclip）？

三个信号，满足两个以上再考虑：

反例警示：有团队两个人两个项目搭 Paperclip，每周花时间清日志、调权限、看任务状态，写业务的时间反而被挤掉。后来下掉平台改成 Claude Code + Hermes + Superpowers，交付节奏反而快了。

5.4 Paperclip vs LangGraph

很多团队两者一起用：底层用 LangGraph 保证灵活度，上层用 Paperclip 统一治理。

六、五类标准组合方案

分层是理论，落地到具体项目，社区和行业已经踩坑踩出了五类标准组合。

组合一：轻量执行 —— 单执行工具

Claude Code / Codex / OpenCode（任选其一）

组合二：基础效率 —— 执行工具 + Hermes

Claude Code（或 Codex / OpenCode）+ Hermes

组合三：全能管家 —— 执行工具 + OpenClaw

Claude Code（或 Codex / OpenCode）+ OpenClaw + Claw Orchestrator

组合四：规范交付 —— 执行工具 + SpecKit + Superpowers

Claude Code（或 Codex / OpenCode）+ SpecKit + Superpowers

为什么 SpecKit 和 Superpowers 要一起上？

• 只上 SpecKit：规格写得再好，Agent 执行时偷工减料、跳测试，交付质量还是不稳
• 只上 Superpowers：纪律有了，但多人协作没统一需求标准，各理解各的
• 企业级交付要的是确定性，不是"可能做好"。需求锁和执行锁一道都不能少

组合五：平台治理 —— Paperclip + 下层任意链路

Paperclip + 下层按需组合 ├── 轻量项目：Hermes + Claude Code ├── 规范项目：SpecKit + Superpowers + Claude Code └── 全能项目：OpenClaw + Claw Orchestrator

七、工具能力全景矩阵

7.1 核心能力覆盖

7.2 核心定位一句话

八、场景化选型决策

8.1 决策树

1. 先选执行层（三选一或混用） ├── Anthropic 生态深度用户 → Claude Code ├── OpenAI 生态深度用户 → OpenAI Codex └── 需要模型自由 + 开源 → OpenCode 2. 再看要不要加运行时层 ├── 单人长期项目、编码为主 → + Hermes ├── 需要全能管家、多端触达 → + OpenClaw（⚠️注意安全） └── 临时/一次性任务 → 不加运行时层 3. 再看要不要加规范层 ├── 需求容易跑偏 → + SpecKit（分级使用） ├── 质量老出问题 → + Superpowers ├── 两者都缺 → + SpecKit + Superpowers └── 单人简单项目 → 不加规范层 4. 最后看要不要加治理层 ├── 项目>5 且角色>3 且有治理需求 → + Paperclip └── 规模未到 → 不加，省下运维成本

8.2 按团队规模推荐

8.3 按项目类型推荐

8.4 成本四维度评估

选型时不能只看工具成本，要把四类成本都纳入考量：

常见误区：很多人只盯着 Token 成本和部署成本，最后省了工具钱，花了更多人肉对齐和返工时间。

九、选型三大原则

原则一：先分层级，不跨维度比强弱

不同层级分工不同，没有"谁更强"的说法，只有职责差异。

• ❌ 错误：拿 Claude Code 和 Paperclip 比谁厉害，拿 OpenClaw 和 SpecKit 比谁好用
• ✅ 正确：先划清层级（执行层 → 运行时层 → 规范层 → 治理层），再看场景需要哪一层

原则二：约束定轻重，不脱离场景谈优劣

工具链没有绝对的好坏，只有和项目约束匹配不匹配。

• 合规要求越高、协作人数越多、项目生命周期越长 → 工具链越"重"
• 单人项目、快速验证、一次性需求 → 尽量往"轻"了走

网上总有人争 Hermes 好还是 SpecKit 好，本质都是站在自己的场景自说自话。做个人副业的觉得 SpecKit 太重冗余，做金融交付的觉得 Hermes 太野没保障——两边都没错，错的是脱离场景谈好坏。

原则三：按需叠加，不一上来就堆全套

正确的做法永远从最简方案开始：

原生执行工具 → 不够用加运行时层 → 质量出问题补纪律技能 → 协作乱了加规范层 → 项目多到管不过来再上编排平台

太多团队选型一上来就追求一步到位，规范、编排、治理全套堆满。结果项目没那么复杂，大半功能用不上，维护成本高得离谱，折腾半年又全拆掉。缺什么补什么，不是先把东西备齐等着落灰。

十、选型里最容易踩的坑

坑 1：跨层级比较

“Superpowers 和 Hermes 哪个写代码厉害？”——Superpowers 根本不写代码，Hermes 也不写。把不同层级的工具放在同一张桌子上比强弱，结论从根上就错。

坑 2：小需求上重流程

改个单行 Bug 也要走 SpecKit 全量流程，规格、计划、任务拆分一套下来，修复时间比 Bug 本身长十倍。工具的流程成本必须小于它省下的返工成本。

坑 3：团队没到规模就上治理平台

两个人两个项目搭 Paperclip，每周维护平台的时间比写业务还多。治理收益 > 平台成本，这是唯一判断标准。

坑 4：忽略记忆治理

Hermes 或 OpenClaw 的记忆不是越满越好。什么信息都往里塞，过期信息和新信息混在一起，Agent 可能把废弃逻辑又拿出来用。有界记忆，用容量换稳定性。建议每月清理。

坑 5：安全配置忽视

OpenClaw 默认绑定0.0.0.0无认证，全球已有 135,000+ 暴露实例，约 15,000 可被远程利用。ClawHub 中发现 800+ 恶意技能。高权限工具必须搭配高安全意识。

坑 6：只看单个工具成本，不看组合成本

省钱选了便宜模型 + 跳过了规范层，结果需求扯皮、Bug 返工、联调对齐的成本远超省下的 Token 钱。成本要从全链条看，不能只看一个环节。

十一、总结

AI 编程框架选型不是挑最强工具，而是看当前场景缺哪层能力。约束弱就轻装上阵，约束强才逐层加治理。

从下到上的完整工具链：

┌─────────────────┐ │ Paperclip │ ← 治理层：多项目多Agent统一管控 └───────┬─────────┘ │ ┌──────────────────┼──────────────────┐ ↓ ↓ ↓ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ SpecKit │ │ Superpowers │ │ 其他规范 │ ← 规范层 │ (需求规格) │ │ (执行纪律) │ │ 工具 │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ └──────────────────┼──────────────────┘ ↓ ┌──────────────────┼──────────────────┐ ↓ ↓ ↓ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Hermes │ │ OpenClaw │ │ 其他运行时 │ ← 运行时层 │ (编码助理) │ │ (全能管家) │ │ 框架 │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ └──────────────────┼──────────────────┘ ↓ ┌──────────────────┼──────────────────┐ ↓ ↓ ↓ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Claude Code │ │ OpenAI Codex│ │ OpenCode │ ← 执行层 │ (Anthropic) │ │ (OpenAI) │ │ (75+模型) │ └─────────────┘ └─────────────┘ └─────────────┘

缺哪一层补哪一层，不是选一个就排除其他。