6.10 六条代表性 Harness 路线¶

OpenSpec、Superpowers、GSD、OMC、ECC、Trellis 不适合放进同一张“谁最好”的榜单。它们补的是 Harness 的不同层。

如果你还没判断自己缺哪一层，先读 8-harness-frameworks-catalog.md。如果你已经决定组合工具，再读 11-harness-composition-patterns.md。

先看定位¶

flowchart TD
  H[Harness 缺口] --> A[OpenSpec<br/>规格层]
  H --> B[Superpowers<br/>工程纪律层]
  H --> C[GSD<br/>上下文与阶段执行层]
  H --> D[OMC<br/>多 Agent 编排层]
  H --> E[ECC<br/>能力增强层]
  H --> F[Trellis<br/>结构与项目记忆层]

这不是采用顺序，而是缺口定位图。实际采用时，先找当前最痛的层，再决定是否组合。

总览¶

路线	主要补哪层	一句话用途
OpenSpec	规格层	先把需求、设计、任务说清楚，再让 Agent 开工
Superpowers	工程纪律层	把 TDD、debug、review、worktree 等习惯变成默认动作
GSD	上下文与阶段执行层	把复杂任务拆进干净上下文，降低长会话腐烂
OMC	多 Agent 编排层	围绕 Claude Code 做 team-first 的多 Agent 协作
ECC	能力增强层	给 harness 补 skills、memory、安全、验证和学习能力
Trellis	结构与项目记忆层	用 specs / tasks / workspace 组织长期工作流

OpenSpec：规格先行¶

OpenSpec 更接近 spec framework，而不是执行引擎。它解决的是“还没说清楚就开工”的问题。

适合：

需求边界容易漂。
团队需要先 review 规格和设计。
Brownfield 项目里改动需要可追溯。
高风险功能需要 proposal、design、tasks 先落盘。

不适合：

你只是改一个小 typo。
你期待它自动完成多 Agent 编排。
你没有维护规格工件的意愿。

使用心法：

先对齐规格，再进入执行。
spec 是执行依据，不是事后补文档。

Superpowers：工程纪律默认化¶

Superpowers 更像一组 composable skills，把优秀工程师的工作习惯做成 Agent 的默认动作。

适合：

Agent 经常不计划就写。
Bug 修复没有复现和根因分析。
测试驱动、debug、review、worktree 隔离没有形成习惯。
你已经有主力 Agent，但缺工程纪律。

不适合：

需求本身还没定义清楚。
团队没有统一质量标准。
你希望它替代任务系统或项目记忆系统。

使用心法：

把“每次都要提醒”的流程做成 skill。
skill 管流程，不管事实来源。

GSD：上下文与阶段执行¶

GSD 关注 context rot：长会话越聊越乱，复杂任务越做越偏。它的价值在于把讨论、计划、执行、验证拆成阶段，并让每个阶段有清晰状态。

适合：

长任务容易上下文腐烂。
大仓库重构需要分波推进。
复杂任务需要阶段性验证和原子提交。
你希望每个阶段都能被接手和回看。

不适合：

任务很小，不需要阶段化。
项目没有基本验证命令。
你只是想补一个 spec 入口。

使用心法：

复杂任务不要靠一个长会话硬撑。
把阶段、状态、验证和提交切干净。

OMC：多 Agent 编排¶

OMC 更偏 Claude Code 场景下的 team-first orchestration。它关心的不是“怎么写一条好 prompt”，而是“怎么让多个 agent 像团队一样协作”。

适合：

Claude Code 是主力工具。
任务可以拆成 plan / exec / verify / fix。
你需要并行 worker、tmux、subagent 或多模型顾问。
你能清楚划分写入范围和合并责任。

不适合：

需求还很模糊。
文件边界高度重叠。
没有测试和 review 来回收多个 Agent 输出。
你需要跨工具长期任务资产骨架，而不是 Claude Code 编排。

使用心法：

并行之前先切边界。
没有验证能力，多 Agent 只会把混乱并行化。

ECC：能力增强与补全¶

ECC 更像一套 harness enhancement：补 skills、instincts、memory、安全审查、验证和持续学习。它不是最低成本起步方案，更适合已经有基础 harness 后做能力补全。

适合：

你已经有项目规则和任务流，但经验沉淀弱。
你希望强化 memory、security、validation、learning。
你需要跨 Claude Code、Codex、Cursor、OpenCode 等工具保持一些一致行为。
团队准备把 AI workflow 长期工程化。

不适合：

初学者还没跑通单 Agent 闭环。
项目没有稳定测试和 review 标准。
你只是想解决单次需求跑偏。

使用心法：

先有骨架，再做增强。
能力补全不是替代底层结构。

Trellis：结构、任务和项目记忆¶

Trellis 更像长期工作流骨架。它通过 specs、tasks、workspace，把项目规范、任务状态和跨会话记忆统一到 repo 里。

适合：

团队不只用一个 AI 工具。
任务经常跨多天、多会话、多 Agent。
项目规范、任务记录和工作记忆需要共享。
你希望把 AI 工作流沉淀成 repo 内结构，而不是个人聊天习惯。

不适合：

一次性脚本或 demo。
不愿维护任务文件和规格文件。
你追求的是单次执行爽感，而不是长期可恢复。

使用心法：

让项目围绕 specs / tasks / workspace 运转，
而不是围绕某一次聊天运转。

单层补位 vs 体系型方案¶

flowchart TD
  A[单层补位] --> A1[OpenSpec: 规格]
  A --> A2[Superpowers: 工程纪律]
  A --> A3[GSD: 上下文与阶段执行]
  B[体系型方案] --> B1[OMC: Claude Code 团队编排]
  B --> B2[ECC: 能力增强系统]
  B --> B3[Trellis: 长期工作流骨架]

这个划分不是绝对边界，而是帮助你决定引入成本。单层补位通常更适合作为第一步；体系型方案更适合在你已经知道自己要长期维护什么时引入。

最短选择规则¶

你现在最痛的是	优先看
需求总跑偏	OpenSpec
Agent 写法不守工程纪律	Superpowers
长任务上下文腐烂	GSD
多 Agent 并行没有组织	OMC
缺 memory / security / validation / learning	ECC
多工具、多任务、项目记忆混乱	Trellis

不要把这张表当采购清单。它的作用是帮你定位当前缺口。