AI coding agent 最大的问题通常不是不会写代码，而是太快开始写代码：需求没有澄清，约束没有固化，任务没有拆分，验证没有闭环，最后只能靠更长的对话把项目拉回正轨。

我重新阅读了 Superpowers、OpenSpec、Spec Kit、gstack 和 oh-my-claudecode 的当前源码。结论先说：

它们都在补 Agent Harness，但补的是不同层：Superpowers 约束方法，OpenSpec/Spec Kit 固化规格，gstack 编排产品团队流程，OMC 管理多 Agent 运行时。

01 先建立二维坐标系

AI Coding Workflow Landscape

用两个维度看这些项目：

规格约束弱 ---------------------------------------- 强
执行编排轻 ---------------------------------------- 重
项目核心层主要 artifact运行时重量
Superpowers方法论与 skillsdesign、plan、TDD 过程轻
OpenSpec变更规格proposal、design、tasks、spec中
Spec Kit项目规格工作区constitution、spec、plan、tasks中
gstack产品工程工作流角色化命令、浏览器验证、发布检查中重
OMC多 Agent runtimetask、worker、event、team state重

这张表避免了一个常见误判：star 多、命令多，不代表项目处在同一层。

02 Superpowers：把“先想清楚”变成强制技能流

Superpowers workflow

截至当前主线，Superpowers 的核心仍然是 skills 和 hooks，而不是一个独立的 agent server。它通过宿主的技能机制，把需求澄清、设计、计划、TDD、debug、review 和提交组织成一套可调用流程。

它最重要的机制不是某一条提示词，而是入口优先级：面对任务，Agent 先检查是否存在适用 skill，再进入设计和执行。这样可以把“经验”从模型记忆迁移到版本化文件。

它的强项是低侵入、易审阅和容易迁移；弱点是最终执行仍依赖宿主 Agent 的遵循程度，复杂并行任务、状态恢复和跨机器 durable execution 并不是它的重点。适合个人或小团队建立工程纪律，不适合直接承担大型多 Agent 调度。

03 OpenSpec：把变更组织成 artifact graph

OpenSpec 的关键不是写一份长需求，而是让变更形成可追踪的 artifact：

change proposal
  -> design
  -> specs / scenarios
  -> tasks
  -> implementation
  -> verification

CLI 和 command generation 负责适配不同宿主，把同一工作流生成成 Claude Code、Codex 或其他 Agent 可以消费的命令。其价值在于规格不是聊天记录，而是仓库中的可审阅对象。

OpenSpec 更像“变更控制层”，它不替你实现完整的多 Agent runtime。优点是轻量、适合增量改动；限制是团队仍需定义验收、评审和执行权限，否则 artifact 可能变成另一套没人维护的文档。

04 Spec Kit：把规格驱动开发变成项目骨架

Spec Kit 由 GitHub 维护，当前 CLI 和模板体系已经形成较完整的项目内规格工作区。典型阶段是：

constitution -> specify -> clarify -> plan -> tasks -> implement

constitution 固化项目层原则，spec 描述用户可观察行为，plan 描述技术方案，tasks 则成为 Agent 的执行清单。模板与 agent integration 负责把这些阶段暴露给不同宿主。

它比 OpenSpec 更重的地方，是把团队治理前置到项目骨架；比 OMC 更轻的地方，是不负责长期 worker 调度。适合多人协作、需要把架构原则和验收条件留在仓库的项目。

05 gstack：把 Agent 当成一支虚拟产品团队

gstack 的抽象不是单个编码 Agent，而是一组角色化工作流：CEO/产品判断、设计、实现、QA、浏览器验证、review 和 release。它的 browser runtime 是一个重要分水岭，因为它不仅生成代码，还能进入真实页面完成检查。

产品判断 -> 设计约束 -> 实现 -> 浏览器 QA -> review -> release

它的优势是覆盖用户价值链，而不只是代码生成；代价是工具链更重，浏览器、环境、权限、测试数据和页面状态都会进入运行时。gstack 适合希望把产品开发流程显式化的团队，单纯修一个函数则可能过度设计。

06 oh-my-claudecode：从命令增强到 Team Runtime

OMC 的重点是 teams-first orchestration。源码中可以看到 agents、skills、commands、allocation policy、event-driven runtime 和 self-improve 等层次。它试图解决的不是“怎么写一段代码”，而是“多个角色如何围绕一个目标并行推进并收敛”。

一个典型路径是：

目标澄清 -> 分解 -> worker 分配 -> 并行执行
  -> 集成 -> QA / review -> 失败重试 -> 完成审计

相比最朴素的 Ralph 循环，OMC 把状态从 done 文件和轮询脚本提升到事件、worker 生命周期和共享任务状态。它能承载更长任务，但也引入了调度、竞争写入、取消、预算和结果合并等新问题。

07 它们共同补上了 Agent 的哪几块

Architecture Comparison

可以把 coding harness 拆成五层：

  1. 意图层：需求澄清、用户故事、成功标准。
  2. 规格层：约束、设计、任务、变更记录。
  3. 执行层：工具、worker、浏览器、沙箱。
  4. 验证层：测试、review、截图、lint、completion audit。
  5. 状态层：上下文、事件、记忆、失败重试和恢复。

Superpowers 主要覆盖 1、2、4；OpenSpec 和 Spec Kit 主要覆盖 2；gstack 覆盖 1、3、4；OMC 覆盖 3、4、5。没有哪个项目自动覆盖全部层。

08 三种工作流范式

Workflow Patterns

方法论技能流

适合相对短的任务。通过 skills 约束顺序，依靠宿主 session 保存状态。

规格驱动流

适合中长期变更。先生成 artifact，再让 Agent 按任务实现，最后用规格做验收。

团队编排流

适合可分解、可并行和需要多角色验证的任务。必须引入事件、worker 状态、共享上下文和失败恢复。

三者可以叠加：用 Spec Kit 产生规格，用 Superpowers 约束 TDD，用 OMC 执行并行任务，用 gstack 做浏览器验收。真正的难点是避免重复状态源。

09 选型建议

场景优先选择
个人 coding，想减少“直接开写”Superpowers
需求变更需要可审阅和可追踪OpenSpec
团队需要项目级原则和规格骨架Spec Kit
要覆盖产品、设计、浏览器 QA 和发布gstack
长任务、多 worker、并行分工OMC

选择时不要只看命令数量，应先问五个问题：规格是否要入库，执行是否需要并行，验证是否有独立角色，任务是否需要跨天恢复，权限是否要由宿主统一治理。

10 最后的判断

这些项目共同说明，AI coding 的瓶颈正在从“模型能不能生成代码”转向“系统能不能把目标变成可验证的进度”。方法论、规格、编排和记忆都在把隐含规则外部化。

最实用的组合通常不是一次安装全部工具，而是先确定一个状态源：短任务用 skill，长期变更用 spec，多 Agent 再引入 runtime。否则每个项目都维护自己的 plan、tasks 和 status，Agent 只会在不同格式之间来回搬运。

参考资料