6个代表性AI编程Harness框架拆解：OpenSpec、Superpowers、GSD、OMC、ECC、Trellis怎么选？
原文链接6个代表性AI编程Harness框架拆解：OpenSpec、Superpowers、GSD、OMC、ECC、Trellis怎么选？
原文链接：https://mp.weixin.qq.com/s/tT97gfbc_3lJkVuaUtmRpg 来源：单向箔 | 2026-04-05
摘要
单向箔对 6 个代表性 Harness 框架的系统拆解。核心判断：这 6 个不是同一种东西，而是 Harness 不同层级的能力模块。按从单层补位到体系化搭建的路径排列：OpenSpec → Superpowers → GSD → OMC → ECC → Trellis。文章不仅横向对比了每个框架的定位、适用场景、边界，还给出了落地建议和一线实战校正。
为什么需要 Harness？
AI 会写 ≠ AI 能稳定交付。Vibe Coding 进入真实工程后的 6 个致命问题：
- 需求只存在于聊天里，输出天然不稳定
- 上下文腐烂，长对话中模型逐渐变形
- 没有长期记忆，跨 session 像断片
- 没有并行与隔离机制，多代理放大混乱
- 没有质量守卫，"看起来像写对了"
- 基本无法团队协作，大家在用各自的方式"抽卡"
Harness 的价值不是"让 AI 更会聊天"，而是让 AI 在复杂工程里变得更可控、更可验证、更可规模化。
6 个框架逐层拆解
框架总表
| 框架 | 定位层级 | 核心关注点 | 适合谁 |
|---|---|---|---|
| OpenSpec | 规范层 | 先把需求、设计、任务写清楚 | 需要先对齐再开工的个人/团队 |
| Superpowers | 方法论与技能层 | TDD、调试、review、worktree 变成默认动作 | 重视质量纪律的开发者 |
| GSD | 上下文工程+阶段化执行层 | 解决 context rot，复杂任务拆成原子计划 | 长任务、复杂仓库、重构场景 |
| OMC | 多代理编排层 | 围绕 Claude Code 做 team-first orchestration | Claude Code 重度用户、并行开发 |
| ECC | 增强层 | skills、instincts、memory、安全、验证全补 | 想把 AI workflow 长期工程化的人 |
| Trellis | 结构层 | specs/tasks/workspace 组织跨平台工作流和项目记忆 | 多工具团队、长期协作项目 |
1. OpenSpec — 先把"要做什么"写清楚
定位：规范层，spec framework，不是执行引擎。
核心主张：Agree before you build（先对齐，再动手）。
典型工件：proposal → specs → design → tasks
最适合解决：
- 需求经常漂、AI 老跑偏
- 团队对边界理解不一致
- 改动缺少结构化依据
边界： 不主打多代理编排、不主打上下文压缩、不主打复杂执行流水线。解决的是最基础也最常被忽视的一层。
2. Superpowers — 把工程方法论做成自动触发的技能
定位：技能与行为约束层。
关键词：composable skills（组合技能）。
工作流覆盖：brainstorming → plan → worktree → subagent TDD → debug → review
核心思想： 优秀工程师的工作方法，能不能被做成 agent 的默认动作？
最适合解决：
- AI 写代码太随意、没有 TDD 纪律
- 调试靠碰运气、review 不成体系
- plan 不够细、worktree 隔离意识薄弱
强项： 工程纪律导向很强，把工程习惯做成 agent 的默认行为。
3. Get Shit Done (GSD) — 把复杂任务拆进干净上下文里
定位：上下文工程与阶段化执行层。
核心卖点：Solves context rot（解决上下文腐烂）。
典型流程：new-project → discuss-phase → plan-phase → execute-phase → verify-work
核心逻辑： 不是"看起来完整"，是为了防止复杂任务在长对话中失真。
三强项：
- 上下文工程意识非常强（默认大模型在长会话里会退化）
- 执行流程完整（讨论→研究→计划→执行→验证形成闭环）
- 工程痕迹清楚（原子提交、阶段文档、验证结果可回溯）
vs OpenSpec： OpenSpec 是"先把规格讲清楚"，GSD 是"把复杂任务拆进干净上下文里执行"。
4. Oh My ClaudeCode (OMC) — 把 Claude Code 从单助手变成团队系统
定位：多代理编排层。
核心卖点：Team-first orchestration for Claude Code。
团队工作流：team-plan → team-prd → team-exec → team-verify → team-fix
最适合解决：
- 想提高并行吞吐
- 希望 Claude Code 承担执行编排角色
- 需要 plan/exec/verify/fix 持续循环
边界： 重点不是通用 spec 资产体系，不是跨平台统一结构层，不是项目记忆系统。就是 Claude Code 场景下的团队协同编排。
5. Everything Claude Code (ECC) — Harness 的"性能增强系统"
定位：增强与能力补全层。
自我定义：The performance optimization system for AI agent harnesses。
能力矩阵：skills + instincts + memory 优化 + 持续学习 + 安全扫描 + research 优先开发
最适合解决：
- 工程经验没法沉淀
- 每次 session 都像从零开始
- 缺少 hooks、rules、安全、验证闭环
- 想在多个 AI 工具间保持一致性
代价： 全面 → 重。信息密度高，初学者容易有"东西太多"的感觉，建议进阶阶段再学。
6. Trellis — 工作流骨架
定位：结构层、任务层和项目记忆层。
关键词：自动注入 Spec、任务驱动工作流、并行 Agent 执行、项目记忆、团队共享标准、多平台复用。
核心目录：.trellis/spec/、.trellis/tasks/、.trellis/workspace/
核心关注： 如何让项目围绕结构化 specs/tasks/workspace 运行，而不是围绕某一次聊天运行。
最适合解决：
- 团队不是只用一个 AI 工具
- 工作流在不同平台间碎片化
- 任务上下文和项目记忆难以沉淀
特点： 不是"单次执行爽感很强"的工具，更像长期结构化沉淀框架。
一句话概括分工
- OpenSpec → 先把"要做什么"说清楚
- Superpowers → 让 agent 默认按工程纪律工作
- GSD → 把复杂任务拆进干净上下文中执行
- OMC → 把 Claude Code 组织成团队式执行系统
- ECC → 给 Harness 补技能、记忆、安全、验证和学习能力
- Trellis → 把 specs、tasks、workspace 变成统一工作流骨架
两级分类：
- OpenSpec / Superpowers / GSD — 偏单层补位（规范、技能、上下文）
- OMC / ECC / Trellis — 偏体系型方案（编排、增强、结构）
落地建议：不是"6 选 1"
三步判断法
- 先判断自己最缺哪一层
- 再判断这一层要用多重的方案来补
- 最后决定哪些层适合组合搭配
更稳的采用路径
第一步：补最痛的一层
| 痛点 | 推荐 |
|---|---|
| 需求总跑偏 | OpenSpec |
| 工程纪律太松 | Superpowers |
| 长任务容易崩 | GSD |
| Claude Code 需多代理并行 | OMC |
| 缺 memory/security/verification | ECC |
| 多工具协作、项目记忆混乱 | Trellis |
第二步：轻量框架可双层组合，重型框架别叠甲
推荐组合：
- OpenSpec + Superpowers：先解决"别跑偏"，再解决"别乱写"
- OpenSpec + GSD：固定规格 + 解决 context rot
- OMC + Superpowers：编排 + 工程纪律
警告： 2 个以上框架一起上容易出现规范重复、任务资产重叠、状态记录分散、事实来源不一致。
一线实战校正
1. 横评成本极高，结论天然是"短保"的
Harness 的比较很难靠一次 Demo 完成。谁能在真实工程里稳定跑更久、出问题后更容易接班和纠偏，谁才真正赢。
2. 多代理 ≠ 真正 hands-off，最怕控制面膨胀
Agent 越多，设计文档越多、进度记录越多、协调信息越多——但真正落到代码上的产出反而没那么多。关键看控制面和执行面的比例是否健康。
3. 上下文压缩与交接能力，比单次写码能力更关键
长任务不是在比谁更会写，而是在比谁更不容易失忆。STATE.md、ROADMAP.md、task 文档本质上是为长期运行提供记忆与交接能力。
4. 超级任务最好拆成 task-centered workflow
把多个耦合的大计划一次性塞给 agent → 优先级混乱、子任务污染上下文、验证边界模糊。正确做法：先写 spec → 拆成 task → 按 phase 推进 → 每段留验证和交接工件。
5. 决策层和执行层最好隔离
高阶模型负责架构判断、偏差识别、方向决策；执行型工具负责跨文件修改、批量实现；压缩/总结型模型负责清洗历史、生成交接材料。不要让最贵的大脑泡在代码细节里。
作者结论
Harness 不是"选一个最强工具"的问题，是分层搭建、按缺口补位的问题。框架在精不在多，选自己真正需要的，比无脑叠甲重要得多。
三类人：
- 无脑叠甲 — 多层叠加反而限制 AI 能力
- 找一个最屌的全能框架 — 过重，学习成本过高，没学会就过时
- 觉得 Harness 没用 — 那你敢在公司级项目里真正放 AI Coding 跑大型需求吗？
Harness 是 AI 编程从"能玩"走向"能进生产"的必要过程。它是一种思想，不是固定模板。核心不是"先把所有东西装满"，而是在使用中发现缺口，再把缺口补起来。