6.11 Harness 组合策略¶
Harness 组合的原则不是“多装几个框架更强”，而是每一层只补一个明确缺口。
三步判断¶
flowchart LR
A[先判断缺哪一层] --> B[再判断补多重]
B --> C[最后决定是否组合]每次只回答一个问题：
- 需求是不是说清楚了？
- Agent 是否按工程纪律执行？
- 上下文是否能跨阶段保持干净？
- 多 Agent 是否真的需要并行？
- 验证、记忆、安全是否足够？
- 任务状态是否能长期恢复？
推荐组合¶
| 组合 | 适合解决 | 注意点 |
|---|---|---|
| OpenSpec + Superpowers | 先防需求跑偏，再防实现乱写 | spec 管“做什么”，skill 管“怎么做” |
| OpenSpec + GSD | 先固定规格，再分阶段执行复杂任务 | 避免 proposal、plan、phase 文档重复 |
| OMC + Superpowers | 多 Agent 编排加工程纪律 | 必须明确写入范围和 reviewer 角色 |
| Trellis + OpenSpec | 长期任务骨架加规格驱动 | 要定义哪个目录是规格事实来源 |
| Trellis + Superpowers | 任务状态落盘加流程默认化 | skill 输出要回写 task/journal |
| Trellis + ECC | 长期项目记忆加能力增强 | 适合进阶团队，不适合初始引入 |
不推荐的组合方式¶
| 反模式 | 后果 |
|---|---|
| 两套 spec 系统同时当事实来源 | 需求冲突，verify 不知道对齐谁 |
| 多个任务目录系统并存 | handoff 分散，恢复成本上升 |
| skills、hooks、commands 都管同一流程 | 规则打架，Agent 不知道听谁 |
| 没有测试就上多 Agent | 并行输出无法回收 |
| 一开始就叠三层以上框架 | 控制面比业务还复杂 |
主骨架优先¶
如果一个项目已经进入长期维护，先选主骨架：
OpenSpec 主骨架：
适合规格驱动强、变更必须先审的团队。
Trellis 主骨架：
适合多工具、多任务、跨会话项目记忆强的团队。
OMC 主骨架：
适合 Claude Code 重度使用、明确需要团队式多 Agent 编排的工作流。
主骨架确定后，其他工具只能补层，不能抢事实来源。
轻量起步路线¶
个人或小团队不要一开始追求完整体系。更稳的路线：
flowchart TD
A[AGENTS.md / CLAUDE.md] --> B[任务目录或 OpenSpec]
B --> C[1 个 bug-fix 或 review skill]
C --> D[只读 MCP]
D --> E[阶段化执行或 worktree]
E --> F[长期记忆与复盘机制]这条路线的关键是：先让单 Agent 可控，再让多 Agent 并行；先让任务可恢复，再让系统自动化。
组合前检查清单¶
- [ ] 当前痛点已经明确，不是因为“别人用了所以我也用”。
- [ ] 每个框架负责的层不同。
- [ ] 规格、任务、记忆各自只有一个事实来源。
- [ ] 验证命令能跑，且失败后有处理流程。
- [ ] 高风险写入有人工确认点。
- [ ] 新增框架不会让普通任务更难完成。
一句话原则¶
轻量框架可以双层组合。
重型框架先单独跑稳。
没有主次关系的叠加，就是技术债。