2025 年下半年以来,围绕 Claude Code 等 coding agent 的"工作流框架"井喷式涌现——它们不改模型,而是在 agent 之上叠一层技能(skills)、命令(commands)、子代理(subagents)、钩子(hooks)和规格(specs),试图把"随手 vibe coding"约束成可复现的工程流程。

本文挑了 12 个有代表性的项目做横向评测。方法:把仓库全部 clone 到本地做源码级审查,配合 GitHub API 核验成熟度指标,并对每个项目派独立 agent 做对抗式交叉验证。评测维度包括:分类定位、成熟度与治理风险、硬技术程度(是空泛口号还是真材实料)、扩展点注册机制,以及对各家 coding agent 的支持面。

关于 star 数:下文 star/fork 数据经 GitHub REST + GraphQL 双接口核验一致,且用 react/linux/vscode 作控制组验证了接口准确(返回真实值)。但需警惕:几个仓库的 star 增速在物理上不合理——superpowers 建仓仅 9 个月却有 25.5 万 star(高于诞生十余年的 React),ECC 半年 23 万 star + 3.5 万 fork,mattpocock/skills 5 个月 17 万——几乎肯定含刷星或运营放大成分。因此 star 只能当"热度信号",不代表质量或成熟度,评测仍以版本节奏、治理结构、许可证、工程规范等更硬的指标为准。

参评项目:spec-kit、OpenSpec、BMAD-METHOD、superpowers、agent-skills、compound-engineering、gstack、gsd-core、trellis、oh-my-openagent、everything-claude-code(ECC)、mattpocock-skills。

速查(TL;DR)

一句话选型:新项目规格驱动 → spec-kit(官方最稳);存量代码改造 → OpenSpec(delta 规格更轻);团队敏捷全流程 → BMAD-METHOD;纪律/评审派 → superpowers / agent-skills / compound-engineering;抗上下文腐烂、跨会话记忆 → gsd-core / trellis 的设计思路。想让工作流被最多框架/工具支持,优先押 Codex CLI / OpenCode / Claude Code / Cursor 这四个通用底座。

三句话看透:① 硬技术上没有空泛口号——11 家源码级评分全部 ≥4/5;② 真正的差异在三个取舍:重工程真软件 vs 纯 Markdown 剧本、钦定技术栈 vs 技术无关、机器门禁强制 vs 靠 AI 自觉;③ 它们注册扩展点的方式分 4 种范式:原生插件 / CLI 生成器 / symlink / 编程式。

项目定位硬技术许可 / 主要风险一等适配 agent 数注册范式
spec-kit官方规格驱动(SDD)4.0MIT / 方法论重、宪法模板留空需自填33CLI 生成器
OpenSpecdelta 规格,棕地友好4.0MIT / 单人主导、PR 积压27CLI 生成器
BMAD-METHOD敏捷角色全流程4.0MIT+商标 / 学习曲线陡44插件+生成器
superpowersTDD 硬门禁纪律4.0MIT / 自身无 CI、PR 积压7原生插件
agent-skillsSDLC 六阶段(Addy Osmani)4.5MIT / 巴士因子高、偏 Web 栈4原生插件
compound-eng复利工程,对抗评审4.5MIT / token 消耗高、需认同哲学10原生插件
gstack虚拟工程团队(Garry Tan)5.0MIT / 营销制度化、无 release、单人9symlink
gsd-core上下文工程抗 rot4.5MIT / 源于 rug-pull 项目的社区 fork18原生插件
trellisspec+task+记忆持久化4.7AGPL-3.0 / 早期 v0.6、单人15CLI 生成器
oh-my-openagent多模型编排 harness5.0SUL 非开源禁商用 / 绑 OpenCode、单人3编程式
ECC超大工具箱/素材库4.0MIT / “889"实为 278、AgentShield 不可验证9原生插件
mattpocock/skills工程流程 skill(Matt Pocock)3.5MIT / 一人主导、star 增速反常2原生插件

规模与热度(GitHub 数据,2026-07-15)

star/fork 经 REST + GraphQL 双接口核验一致。“热度可信度"一栏依据"建仓时长 vs star 量级"判断增速是否合理:

项目StarsForks建仓热度可信度
superpowers255,03622,8012025-10❗ 反常(9 个月 > React,极可能刷星)
everything-claude-code229,88535,1892026-01❗ 反常(半年 23 万 + 3.5 万 fork)
mattpocock/skills171,42514,7272026-02❗ 反常(5 个月 17 万)
gstack121,98118,2362026-03❗ 反常(4 个月 12 万)
spec-kit121,43910,8032025-08✅ 可信(GitHub 官方大热)
agent-skills78,4248,4232026-02⚠️ 偏高(作者影响力大,或含放大)
oh-my-openagent65,8435,3712025-12⚠️ 偏高
OpenSpec60,9654,2282025-08⚠️ 偏高
BMAD-METHOD50,6165,8242025-04✅ 相对可信(社区成熟)
compound-engineering23,1941,8662025-10✅ 可信
trellis12,6357042026-01✅ 可信
gsd-core6,6304262026-05✅ 可信(fork 自 get-shit-done)

判读:star 榜与工程质量几乎无关——热度最高的 superpowers/ECC/gstack 反而是增速最反常的;而工程硬度天花板 gsd-core 的 star 最低。别把 star 当选型依据。

先分类:三个不同物种

把 12 个放在一起容易误比,因为它们解决的问题层次不同:

家族解决的核心问题成员
① 规格驱动(Spec-Driven)写代码前先把"要造什么"固化成可复核的规格spec-kit、OpenSpec
② 方法论 / 角色化工作流把软件工程流程(计划→评审→交付)固化成 AI 可执行的纪律BMAD-METHOD、superpowers、agent-skills、compound-engineering、gstack、mattpocock-skills
③ Agent Harness / 上下文与编排增强对抗上下文腐烂、跨会话记忆、多模型编排gsd-core、trellis、oh-my-openagent、ECC

边界有重叠——superpowers 既是方法论也是 skills 框架,gstack/trellis 既是工作流也是 harness,BMAD 也带浓重的规格驱动色彩。上表按"最主要卖点"归类。

逐项目画像

每个项目一段,融合定位、成熟度/治理、硬技术分与优劣。

规格驱动

spec-kit(GitHub 官方,MIT)——规格驱动开发(SDD)的官方旗舰,把 Constitution → Specify → Plan → Tasks → Implement 落成"宪法 + 模板 + 合规门"的可执行流水线,通过独立 CLI specify 适配 33 个 agent。成熟度:官方团队 + 社区维护,巴士因子健康,发版极密(接口仍在漂移)。硬技术 4.0:门禁引擎(合规门、只读一致性审查、覆盖率指标)是真机制,但宪法模板全是空占位符——用户不认真填,它的"硬"就落空;自身仓库工程质量一流(测试 > 源码、多 OS CI、Actions 按 SHA 钉版本)。最稳的官方选择,适合追求一致性的中大型项目。

OpenSpec(Fission AI,MIT)——最轻量的规格驱动。核心创新是 delta 规格:变更只描述"变了什么”(ADDED/MODIFIED/REMOVED),归档时自动并入主规格,天然适配存量代码和并行变更。纯 npm + Markdown,不依赖 Python。硬技术 4.0:delta 格式有 Zod schema + 编译器级冲突检测(跨 section 冲突、重名、RENAMED 碰撞全报 ERROR),但刻意技术无关、未编码 TDD/评审。风险:单核作者、PR 积压,跨仓库协作(Stores)仍是 Beta。存量项目里 spec-kit 的更轻替代。

方法论 / 角色化工作流

BMAD-METHOD(BMad Code,MIT+商标)——最"重"也最完整的方法论,把 PM/架构/开发/QA 做成角色 agent,规划-实现两阶段分离,Analyst→PM→Architect→SM→Dev→QA 跑完整 SDLC,还有游戏/创意等扩展包出圈到非软件领域。成熟度:社区、文档、发版都成熟(v6 主线),支持 44 个平台居首。硬技术 4.0:workflow 用受控 XML DSL,dev-story 强制 red-green-refactor + DoD 门禁 + HALT 条件,校验器还带确定性正则和元工具自测。劣:学习曲线陡、V4→V6 反复重构、小项目过度工程。适合团队级、复杂、需追溯的项目。

superpowers(Jesse Vincent / obra,MIT)——理念最"硬核"的纪律框架。用 SessionStart hook 注入 + 硬性关卡强制工程纪律:TDD 的 “Iron Law”(没有失败测试就不许写实现,“写在测试前的代码必须删除”),外加 git worktree 隔离、子 agent 双阶段评审。大量精力花在**“防止 AI 给自己找借口绕过规则”**(反规避对照表)。硬技术 4.0:最佳实践编码颗粒度到命令级,但真正的机器门禁少、自身仓库甚至没有 CI,靠 hook 注入 + AI 自觉。作者是开源老兵(K-9 Mail)。劣:极年轻却已 v6、PR 积压、流程对小改动偏重。

agent-skills(Addy Osmani,MIT)——把资深工程师"不在 diff 里"的价值(写规格、测试、评审、控 scope)编码成 SDLC 六阶段(DEFINE→PLAN→BUILD→VERIFY→REVIEW→SHIP),约 24 个 skill + 8 个 slash 命令 + 4 个角色人格,每个技能内置"agent 偷懒借口对照表”,理念源自 Google 工程文化(Hyrum’s Law、Beyoncé Rule 等)。硬技术 4.5:有量化阈值(LCP≤2.5s、JS<200KB gzip 等)、钦定 TS/React/Web 栈、并有可运行的三层校验(结构/触发路由/行为)。劣:巴士因子高(作者一人贡献占绝对多数)、偏 Web/前端栈、仍 v0.6 早期。与 superpowers 理念高度相似,但 SDLC 覆盖更系统、作者影响力更大。

compound-engineering(Every Inc,MIT)——理念最独特的"复利工程":每次工作让下次更容易,80% 精力在规划与评审。/ce-compound 把每次教训回写成结构化知识库(强 enum schema:18 值 problem_type 等),/ce-code-review 做多 agent 对抗式评审,甚至有跨模型对抗脚本(把同一份 brief 交给不同厂商 CLI 独立评审)。硬技术 4.5:规则被编译成 enum/schema/脚本/CI 门禁,可机器校验;运营专业(语义化自动发版)。劣:token 消耗高、见效慢、价值依赖你认同其哲学。方法论派的标杆。

gstack(Garry Tan / YC CEO,MIT)——把 Claude Code 包装成"你雇了一个工程团队",23+ 角色技能覆盖研发全生命周期(CEO→设计→工程三重评审、安全审计、真实浏览器 QA、跨模型复核)。硬技术 5.0(反直觉):有真实的 LLM-judge eval 体系、多 runner CI 矩阵、grep 级安全审计、静态 tripwire 测试——工程内核相当硬。但:本质是一个人的配置固化(无正式 release、单人主导),且把创始人营销(“810× 生产力”、YC 叙事)制度化写进 PR 治理规则(禁止社区 PR 软化宣传)。当灵感库/范本可以,但它是"高热度个人方法论"而非中立生产级框架。

mattpocock/skills(Matt Pocock / Total TypeScript,MIT)——“给真正做工程的人用"的 skill 集(README 直言 “real engineering, not vibe coding”),40 个 skill(22 个成熟),显式把自己摆在 GSD/BMAD/spec-kit 的对立面:小、可组合、model-agnostic、不夺走你的控制权。核心是工程流程(grilling 对齐需求、用 CONTEXT.md 共享领域语言、TDD、to-spec→to-tickets→implement→code-review),刻意技术无关——尽管作者是 TS 顶流,promoted skill 基本不绑 TypeScript。硬技术 3.5:方法论编码到教科书级(TDD 的"seam 接缝"规则、内联 Fowler 12 条 code smell),但自身仓库无测试、无 lint,CI 只发版不校验,不变量全靠 CLAUDE.md+ADR 约束 agent;无 commands/hooks/MCP。劣:一人主导、star 增速反常。理念克制、内容硬核的个人工程哲学 skill 集,适合认同"控制权在你"取向的开发者。

Agent Harness / 上下文与编排增强

gsd-core(open-gsd 社区,MIT)——直击 “context rot”:用 fresh-context 子 agent 并行执行 + 落盘状态(STATE.md/CONTEXT.md)对抗长会话上下文腐烂,五阶段循环 Discuss→Plan→Execute→Verify→Ship,“先验证再宣布完成"是 fail-closed 硬门禁。硬技术 4.5,自身工程硬度是这批天花板:变异测试棘轮、15 条 AST 级反假测试 lint、12 类强制对抗性 QA 矩阵、66 个 ADR。⚠️ 最大隐忧是治理背景:它是原项目 gsd-build/get-shit-done 因作者失联 + $GSD 代币被指 rug-pull 后的社区 fork(非官方交接)。技术很好,但历史包袱与品牌信任是硬伤。

trellis(Mindfold AI,AGPL-3.0)——用 .trellis/ 目录做 spec/task/journal 三层持久化解决"AI 失忆”,Plan→Implement→Verify→Finish 闭环,与 Claude Code 原生 hook/subagent 集成深。硬技术 4.7:工作流被编译成可解析状态机 + 测试不变量 + 发布连续性门禁,营销与实质约 5:95。劣:仅 v0.6 早期、单人主导、AGPL 强 copyleft(商用闭源需法务评估)。概念完整,但采用风险偏高。

oh-my-openagent(code-yeongyu,SUL-1.0 非开源)——oh-my-zsh 式的多模型编排 harness,主打模型无关 + 低成本,给不同模型各写一套 prompt。硬技术 5.0,是这批里最像"真软件"的:21 万行生产 TS + 更多测试,哈希锚定编辑、LSP、AST-Grep 三样硬技术全有可运行实现,用 TS 编译器 API 做源码级元审计当门禁。❗硬伤:SUL 许可禁商用分发(非开源)、深度绑定 OpenCode/Codex、与上游模型厂商关系紧张、实质是单人 + 自家 bot 高速 dogfooding。能力强,但许可与平台风险大。

everything-claude-code (ECC)(affaan-m,MIT)——最"大而全"的工具箱:278 个 skill + 67 subagents + 94 commands + 语言专用 rules,纯官方扩展点集成,供应链安全 CI 齐全。硬技术 4.0:门控 TDD 流水线、供应链 IOC 扫描、多语言 rules 都是真的。但两个招牌数字有水分:README 宣称的 “889 skills” 实为 278(其余是 i18n 翻译 + 多编辑器镜像凑数),“AgentShield 1282 测试/102 规则” 在本仓库内零实现(是外部 npm 包的自述,不可验证)。当素材库/最佳实践参考最合适,别无脑全量安装。

硬技术程度:是口号还是真材实料?

把 12 个仓库全部 clone 到本地,每个派独立 agent 只读源码,按 5 个维度打分(1-5,5=最硬核具体):① 工程规范强制度 ② 最佳实践编码 ③ 技术选择意见强度 ④ 内容丰富度 ⑤ 自身仓库工程硬度。

项目综合①规范强制②实践编码③技术意见④丰富度⑤自身工程强制方式
gstack5.055555CI 门禁 + 静态 tripwire 测试
oh-my-openagent5.055555源码级元审计测试 + hook
trellis4.7455*/无关55测试不变量 + 发布门禁
compound-eng4.555355enum schema + CI + 跨模型对抗评审
gsd-core4.545255变异测试棘轮 + AST 级反假测试 lint
agent-skills4.545455三层校验(结构/路由/行为)
BMAD-METHOD4.045254确定性校验器 + 元工具自测
spec-kit4.034155门禁引擎(内容留空给用户填)
OpenSpec4.053.514.54Zod schema + 编译器级冲突检测
superpowers4.045243.5hook 注入 + AI 自觉(自身无 CI)
ECC4.0453.544CI 校验 + 供应链扫描
mattpocock/skills3.545243CLAUDE.md+ADR 约束(无测试/lint)

* trellis/gstack/oh-my-openagent/agent-skills 对用户项目技术无关,但对自身 + 内置脚本强钦定;③ 列反映后者。

几个关键结论:

  1. 没有一个是"空泛口号”——全部 4 分以上。 即便看起来最"轻"的 superpowers、agent-skills,进入 SKILL.md 内部都是可执行到命令级的硬内容;营销话术普遍只存在于 README 门面。
  2. 分成两个物种:“真软件” vs “纯 Markdown 剧本”。 真软件(大型 TS/Node 应用 + 测试 + CI):oh-my-openagent、trellis、gsd-core、compound、OpenSpec、gstack、BMAD、ECC;纯 Markdown 剧本(靠 AI 遵循、机器强制少):superpowers、agent-skills。
  3. “技术选择意见强度”(③列)决定适配面。 刻意技术无关的(spec-kit/OpenSpec/gsd-core/BMAD/superpowers)一套方法论适配任意语言,但开箱约束偏软;强钦定栈的(agent-skills=TS/React、gstack=Bun/Chromium、oh-my-openagent=Bun/tsgo)开箱即用但适配面窄。
  4. “强制方式"拉开工程档次。 机器 fail-closed 门禁最硬(gsd-core 的变异测试棘轮、oh-my-openagent 的编译器级元审计、compound 的 enum schema、OpenSpec 的 delta 冲突检测);靠 AI 自觉 + 说服话术较软(superpowers 的 Iron Law + 反规避对照表——这套"反偷懒借口"其实 agent-skills/gstack 也都有)。

一句话: 差异不在"有没有真货”,而在(a)重工程真软件还是纯提示剧本、(b)钦定技术栈还是技术无关、(c)机器门禁还是 AI 自觉。工程硬度天花板是 gsd-core / oh-my-openagent。

扩展点是怎么注册的?

12 个框架都建立在 Claude Code 的原生扩展点词汇之上,差异在用不用、怎么下发。

原生注册"契约"

扩展点注册文件关键字段 / 触发方式
plugin.claude-plugin/plugin.jsonname/version + 可选指针 commands/skills/agents/hooks
marketplace.claude-plugin/marketplace.jsonplugins[](含 source),/plugin marketplace add <repo> 发现
skillskills/<name>/SKILL.mdfrontmatter 仅 name+description;模型按 description 自动触发
commandcommands/<name>.md(或 .toml)frontmatter name/description/argument-hint/allowed-tools;用户 / 显式调用
subagentagents/<name>.mdfrontmatter name/description/tools(白名单)/model/color
hookhooks/hooks.json事件 SessionStart/PreToolUse/PostToolUse/Stop → matcher → command,路径用 ${CLAUDE_PLUGIN_ROOT}
tool(MCP).mcp.jsonmcpServers map,type: stdio|http

关键区分:skill = 模型自动触发的能力包;command = 用户 / 手动触发;subagent = 可委派的独立上下文。三者 frontmatter 与目录都不同。

四种注册范式

范式成员机制安装方式
A 原生 plugin 清单式superpowers、agent-skills、gsd-core、compound、ECC、BMAD、mattpocock自己就是 Claude 插件,plugin.json+marketplace.json/plugin marketplace add → /plugin install
B CLI 生成器 / 多适配器式spec-kit、OpenSpec、trellis一套源,init 时按目标 agent 编译成不同格式specify init / openspec init / trellis init
C 安装脚本 symlink 式gstacksetup 把 repo symlink 进各家 skills/ 目录./setup
D 编程式 / 宿主 API 式oh-my-openagentagent/hook 写在 TS 代码里,经宿主 plugin interface 注册bunx omo install

范式 A 的 plugin.json 指向资产分三种风格:裸清单(superpowers,靠约定目录被扫描)、目录指针(gsd-core,"skills":"./skills/")、显式文件数组(agent-skills,逐个列 agents);BMAD 更进一步在 marketplace.json 里拆成多个子插件。

范式 B 是"技术无关"三家的实现根基:spec-kit 用 agents.py 注册表把一条命令渲染成 markdown/toml/yaml/SKILL.md 四种格式;OpenSpec 用 29 个 TS 适配器(各实现 getFilePath()+formatFile());trellis 为每个平台备一个模板目录、init 时按平台拷贝。

范式 D 的 oh-my-openagent 本质是 OpenCode 的 TS 插件,agent/hook 在代码里注册,同时另做一套 Codex 静态插件——是编程式 + 静态混合。

几点横切观察:

  • .agents/ 正成为跨工具事实标准——多数项目都在原生 .claude/ 之外建了这个中立目录。
  • 多平台镜像两种做法:提交期静态镜像(ECC 把 skill 复制成多语言/多编辑器多份,正是"889"虚胖来源)vs 安装期动态生成(范式 B)。
  • hook 复杂度天差地别:superpowers 仅 1 个 SessionStart hook;gsd-core 全事件覆盖(prompt-guard/read-guard/context-monitor…);ECC 的 hook 里内联一大段 JS 引导器兼容多种安装路径,最重。

一句话: 范式 A 是"我就是个 Claude 插件"(绑定深、开箱即用);范式 B 是"我是编译器,把一套源翻译成 N 家格式"(平台无关,代价是多一层生成器);范式 C 是"symlink 进去就行";范式 D 是"写进宿主代码 API"(能力最强,但与宿主强耦合)。

对各家 Coding Agent 的支持矩阵

排版:coding agent 作行,12 项目作列(短代号)。取证方法:范式 B(生成器)按其适配器/集成/模板目录清单计(有代码实证的"一等公民"支持);范式 A/C/D 按已提交的平台目录计。这是"一等适配"的下限,不是"能不能用"的上限——通用 SKILL.md/plugin 格式任何兼容工具都能读,只是没提交专属目录。

列代号:BMAD=BMAD-METHOD、SK=spec-kit、OS=OpenSpec、GSD=gsd-core、TR=trellis、CE=compound-engineering、ECC=everything-claude-code、SP=superpowers、AS=agent-skills、GST=gstack、OMO=oh-my-openagent、MP=mattpocock/skills。

Coding AgentBMADSKOSGSDTRCEECCSPASGSTOMOMP计
Codex CLI✅✅✅✅✅✅✅✅✅✅✅✅12
Claude Code✅✅✅✅✅✅✅✅✅✅✅11
OpenCode✅✅✅✅✅✅✅✅✅✅✅11
Cursor✅✅✅✅✅✅✅✅✅✅10
Gemini CLI✅✅✅✅✅✅✅7
Pi✅✅✅✅✅✅✅7
Kiro✅✅✅✅✅✅6
Trae✅✅✅✅✅✅6
Cline✅✅✅✅✅5
CodeBuddy✅✅✅✅✅5
GitHub Copilot✅✅✅✅✅5
Kimi✅✅✅✅✅5
Qwen Code✅✅✅✅✅5
Factory Droid✅✅✅✅4
Hermes✅✅✅✅4
Kilo Code✅✅✅✅4
Qoder✅✅✅✅4
Antigravity✅✅✅3
Auggie✅✅✅3
Bob✅✅✅3
Junie✅✅✅3
Windsurf✅✅✅3
Zcode✅✅✅3
Agy✅✅2
Amp✅✅2
Crush✅✅2
Devin✅✅2
Firebender✅✅2
Goose✅✅2
Lingma✅✅2
Mistral Vibe✅✅2
OMP✅✅2
OpenClaw✅✅2
Roo Code✅✅2
Rovo Dev✅✅2
Zed✅✅2
iFlow✅✅2
Adal✅1
Amazon Q✅1
Augment✅1
CodeWhale✅1
Command Code✅1
Continue✅1
Cortex✅1
Costrict✅1
Forge✅1
Grok✅1
Kode✅1
Mux✅1
Neovate✅1
Ona✅1
OpenHands✅1
Pochi✅1
Reasonix✅1
Replit✅1
Shai✅1
Slate✅1
Tabnine✅1
VS Code✅1
Warp✅1
Zencoder✅1
每项目一等适配合计44332718151097493261

去重后共覆盖 61 个 coding agent。计数 1-2 的长尾几乎全被 BMAD、spec-kit、OpenSpec 三家瓜分。

读表要点:

  1. 四个"通用底座":Codex CLI、OpenCode、Claude Code、Cursor 被 10-12 家全覆盖,是当前 agent 生态的最大公约数。想让工作流被最多框架支持,优先押这四个。
  2. 覆盖广度 = 范式决定:范式 B 的生成器天生广(BMAD 44、spec-kit 33、OpenSpec 27,多加一个 agent 只是多写一个适配器);最窄的是 oh-my-openagent(3,编程式深绑 OpenCode/Codex)和 mattpocock/skills(2,只 Claude Code + Codex)。广度与深度此消彼长。
  3. 长尾即"跑马圈地":只被一家支持的 20+ 个冷门 agent(Warp/Replit/OpenHands/Amazon Q…)几乎全被 BMAD 和 spec-kit/OpenSpec 瓜分,在比拼"支持最多工具"的营销位。

横向规律

  1. 都是"提示词/工作流编排层",没有新增底层能力——上限全部受宿主模型与 agent 平台能力约束。没有一个是"银弹"。
  2. 趋同的四/五阶段循环:几乎所有项目都收敛到 Plan → Implement → Verify → Ship/Compound + 子 agent 隔离 + 落盘状态持久化。这已是 2026 年的事实标准范式。
  3. “平台无关"是新标配:几乎每家都在 .claude/.cursor/.codex/.gemini/... 各建目录,Claude Code 通常是主 harness。
  4. 成熟度普遍虚高:绝大多数仓库年龄 < 1 年却已到 v2~v6,破坏性变更频繁;高 star ≠ 生产验证。
  5. 巴士因子被严重低估:spec-kit / BMAD / compound-engineering 有真正的团队/社区;gstack / trellis / oh-my-openagent / OpenSpec / agent-skills 高度依赖单一作者。
  6. 许可证要认真看:多数 MIT,但 oh-my-openagent(SUL 非开源禁商用) 和 trellis(AGPL 传染性) 对企业集成是实打实的坑。

选型建议

按 个人 vs 团队 × 轻量 vs 重流程

轻量 / 快速迭代重流程 / 强纪律
个人开发者OpenSpec(棕地小改)、gsd-core(多 runtime)superpowers / agent-skills(单人也要高质量 TDD)
团队compound-engineering(规划前置 + 经验复用)BMAD-METHOD(完整可追溯 SDLC)

按具体场景

  • 已有代码库、只想加点规格约束、讨厌仪式 → OpenSpec(delta 规格)
  • 想要官方背书、跨多种 AI 工具通用、绿地棕地都做 → spec-kit
  • 团队级、要角色分工和完整敏捷流程、甚至扩到非软件领域 → BMAD-METHOD
  • 单人但坚持严格 TDD 和代码质量 → superpowers 或 agent-skills(后者 SDLC 覆盖更系统、偏 Web 栈)
  • 认同"重计划评审、沉淀复利"哲学、追求评审质量 → compound-engineering
  • 想借鉴抗上下文腐烂 / 跨会话记忆的设计 → 参考 gsd-core / trellis(注意 gsd-core 的治理背景与 trellis 的 AGPL)
  • 想抄一套现成 skills/subagents 做二次开发 → ECC 当素材库
  • 需谨慎评估:gstack(无 release、单人、营销制度化)、oh-my-openagent(SUL 非开源 + 平台绑定)、gsd-core(rug-pull 历史包袱)

结语

一年之内,coding agent 工作流框架已经从"几段提示词"进化成"带变异测试、AST 级 lint、跨模型对抗评审的真软件”。它们在硬技术上普遍超出预期——真正需要甄别的不是"有没有货",而是:它是重工程还是提示剧本、绑不绑你的技术栈、靠机器门禁还是 AI 自觉、许可证和巴士因子能不能进你的生产环境。 想稳,选官方 spec-kit;想轻,选 OpenSpec;想要完整团队流程,选 BMAD;想要工程纪律,看 superpowers/agent-skills——但无论选谁,先看清许可证和维护结构,再决定是否押注。

附:参评项目

数据为 2026-07 快照,会随时间变化;各项目自述指标带 marketing 性质,本文以源码级核实为准。