别装错了！Superpowers 和 OMO 只该选一个
别装错了！Superpowers 和 OMO 只该选一个
一个你一定经历过的场景
你给 Agent 一个需求：「帮我加个用户认证模块」。
然后你泡了杯咖啡回来，发现它已经写了 800 行代码——但用的是你项目里根本没有的 JWT 库，认证逻辑跑在错误的中间件层，而且完全跳过了你上周刚定的 session 过期策略。你问它为什么不用项目里已有的认证中间件，它振振有词地解释了一通"JWT 的优势"，好像它才是这个项目的架构师。
这不是模型蠢。模型聪明得很。问题在于：它太急着动手了。 在它看来，写代码就是它的使命，而你那句模糊的需求指令，它选择用自己最擅长的方式去"填补空白"——用代码。至于你的真实意图、项目的技术栈约束、已有的代码规范，这些都是它主动跳过的"障碍物"。
或者另一个场景：你让它重构一个有 47 个文件的服务层。它改了 15 个文件就告诉你「已完成」，剩下的要么忘了，要么上下文窗口溢出，改到一半就开始编造已经不存在的函数签名。你打开代码一看，新调用的方法在旧文件里根本没有定义，而旧文件里被删除的方法还有三个地方在引用。整个项目跑不起来了。
这两种失败，看起来都是"Agent 不够好"。但实际上，它们指向的是完全不同的两个问题。
第一种——急着写代码——是纪律问题。模型有能力做对，但它没有足够的约束去保证每次都做对。
第二种——一个 Agent 干不完——是产能问题。单个 Agent 的上下文窗口和并行能力有物理上限，任务超过这个上限，再守纪律也没用。
这两个痛点，恰好是今天 AI 编程领域最值得关注的两套解法各自瞄准的靶心。一个叫 Superpowers，一个叫 OMO。
而你可能正打算把两个都装上——千万别。
Superpowers：给 Agent 立规矩
先说清楚一个背景。Superpowers 的作者是 Jesse Vincent——RT（Request Tracker）的创始人，现在运营 Prime Radiant 公司。这是一个写过大型工程软件、吃过流程管理苦头的人。GitHub 上 obra/superpowers 已经攒了 236K+ stars，MIT 协议，完全开源。
它的核心思路一句话就能说清：Agent 不是不够聪明，是太自由了。
Superpowers 做的事情，是通过一种叫 SKILL.md 的文件，给 Agent 注入强制性的行为约束。不是建议，不是提示词技巧，是约束——Agent 每次响应之前，都会自动检查有没有匹配的 Skill，有就必须执行，不可跳过。
它的标准流程是四个字：先想后做。
具体来说，Agent 收到你的需求后，不会直接写代码，而是走这样一条路：
- Brainstorm：先跟你讨论方案，澄清模糊需求
- Git Worktree：拉一个隔离的工作分支，不碰你的主干
- Plan：输出结构化执行计划
- TDD Execute：测试驱动开发，写一个测试跑一个测试
注意，这不是 Agent 的"建议流程"，而是 Skill 文件强制规定的。你见过那种「让 Agent 先做计划再做」的 prompt 技巧吧？Superpowers 的区别在于，它是硬编码到执行循环里的，Agent 绕不过去。
还有一个很务实的设计：子 Agent 开发模式（subagent-driven-development）。每个子任务派给一个独立的子 Agent 执行，主 Agent 只负责协调。这样做的好处很直接——上下文不漂移。一个 Agent 从头干到尾，聊了 200 轮之后，它早就忘了第 3 轮你说的话。子 Agent 模式让每个任务在干净的上下文里执行。
Superpowers 最让人舒服的一点是安装门槛几乎为零。一行命令搞定：
claude plugin add obra/superpowers而且它支持 8 个平台：Claude Code、Codex、Cursor、OpenCode、Gemini CLI、Copilot CLI、Factory Droid、Antigravity。一套 Skill 文件，在哪个平台上行为都一致。这对同时用 Cursor 写前端、用 Claude Code 做后端的人来说，太友好了。
说到底，Superpowers 信的是纪律。 它认为问题不在模型的能力上限，而在执行流程没有约束。就像一个手艺精湛但容易走神的工匠，你不需要换一个更厉害的工匠——你需要给他一本施工规范手册，告诉他：先量尺寸，再选材料，然后才能动锯子。手册不会让他的手艺变好，但能保证他不犯低级错误。
这个思路的背后，其实是对当前大语言模型一个很清醒的判断：模型已经足够聪明了，真正的瓶颈在于执行过程的不可控性。 GPT-4 级别的模型完全有能力做好需求分析和技术方案设计，但它在"自由模式"下没有动力这么做——因为写代码比思考更"高效"，至少从 Token 生成角度看是如此。Superpowers 要做的，就是扭转这个激励结构。
OMO：拉一支团队来干
OMO（Oh-My-OpenAgent，原名 Oh-My-OpenCode）走的是完全不同的路线。
作者 code-yeongyu 是一位独立开发者，GitHub 仓库在 code-yeongyu/oh-my-openagent。如果说 Superpowers 解决的是「一个 Agent 不守规矩」，OMO 解决的就是「一个 Agent 根本干不完」。
它的核心理念是：单个 Agent 的能力天花板太低了，突破上限的方式不是等模型变强，而是用数量和专业化分工。
OMO 内置了 7 个专职 Agent，每个都有希腊神话色彩的名字和明确分工：
- Sisyphus——编排者，负责拆解任务、分配工作，像项目经理
- Hephaestus——深度执行者，专门啃硬骨头，做最复杂的实现
- Oracle——架构顾问，给出技术方案建议
- Librarian——文档搜索专家，帮你查 API 文档
- Explorer——代码探索者，快速扫描理解现有代码库
- Designer——UI 设计专用 Agent
- Fixer——修 Bug 专家
光看这个分工你就明白了：OMO 不是让一个 Agent 穿多件衣服，而是真的起 7 个 Agent 并行跑。它甚至有 Team Mode，一个 Lead Agent 带 8 个成员 Agent 同时开工，配 tmux 多窗口可视化，你能实时看到每个 Agent 在干什么。
但 OMO 真正硬核的技术创新，不在"多 Agent"这个概念——这个概念谁都能讲——而在它解决了一个非常具体的工程问题：Agent 编辑代码不可靠。
这个问题在社区里被叫做 Harness Problem。你让 Agent 用 sed 或类似工具改代码，它经常会改错位置、改错内容、甚至把文件搞乱。原因很简单：文本编辑工具依赖行号或字符串匹配，但 Agent 的上下文窗口是有限的，它"记不清"文件的精确内容。
OMO 的解法叫 Hash-Anchored Edits（内容哈希锚定编辑）。原理是：对要编辑的代码片段计算内容哈希，用哈希值做锚点来定位修改位置。不依赖行号，不依赖模糊匹配——内容对不上就拒绝执行。这是一个很聪明的设计，从根本上解决了 Agent “手抖"的问题。
OMO 还有一些值得注意的设计：
- IntentGate：分析用户输入的真实意图后再行动，避免字面理解需求
- Ralph Loop：自引用循环机制，任务不达 100% 完成度就反复迭代，不停
- 内置 MCP 工具链：Exa（网页搜索）、Context7（文档查询）、Grep.app（GitHub 代码搜索）开箱即用
- LSP 集成 + AST-Grep：支持多语言的语法树级别搜索替换，比正则匹配靠谱太多
OMO 有两个版本。Ultimate 版基于 OpenCode，需要装 Bun 运行时，功能最全；Light 版基于 Codex，npm 一行装好，叫 LazyCodex，适合快速体验。
不过得说实话：OMO 的配置复杂度是明显高于 Superpowers 的。 官方文档甚至建议"让 AI 帮你安装配置”——这本身就说明了一切。对于一个多 Agent 编排系统来说，这个复杂度是合理的，但它确实存在。
说到底，OMO 信的是暴力。 单个 Agent 不够用？那就拉一支团队，专业分工，并行推进。就像组建一支施工队——不是给一个工匠定规矩，而是招募木工、电工、水暖工，各有专长，同时开工。
这个思路背后同样有一个清醒的判断：再守纪律的单个 Agent，也无法突破上下文窗口和串行执行的物理限制。 一个 Agent 同时只能看这么多 Token，同时只能做一件事。当任务复杂到需要"先理解 50 个文件的依赖关系、再制定重构方案、然后并行修改 20 个文件"时，纪律帮不了你——你需要的是分而治之，需要并行。
两种哲学，两种路径，它们解决的是 AI 编程中完全不同维度的问题。理解这一点，是做正确选型的前提。
为什么两个不能一起装
这是这篇文章最实用的一段，请认真看。
你可能会想：Superpowers 管纪律，OMO 管编排，两个一起装不就完美互补了吗？逻辑上听起来合理，但实际上行不通。
OMO 和 Superpowers 在机制上存在直接冲突。具体来说，当 OMO 启用时，它会接管 Agent 的 Skill 注册流程，导致 Superpowers 的 Skill 文件虽然可见，但无法被正常调用。这意味着你精心配置的 brainstorm → plan → TDD 流程，在 OMO 接管的那一刻就失效了。你在 GitHub Issue #2745 里可以看到详细的讨论。
这不是谁的 Bug，而是两个工具的设计哲学在同一个控制平面上打架了。
Superpowers 的工作方式是在 Agent 的响应循环里插入一道"检查站"：每次响应前检查有没有匹配的 Skill，有就必须执行。而 OMO 需要用自己的编排逻辑接管整个任务分配和执行流程——从 IntentGate 分析意图，到 Sisyphus 分配任务，再到各专职 Agent 并行执行。两者都想做 Agent 行为的"最高指挥官"，但一个系统里只能有一个指挥官。
更深层的原因是：这两个工具对"Agent 行为的核心问题是什么"这个问题的回答是互斥的。Superpowers 认为核心问题是"单个 Agent 的行为不可控"，所以它的解决方案是给单个 Agent 上枷锁。OMO 认为核心问题是"单个 Agent 的能力不够用"，所以它的解决方案是让多个 Agent 分工协作。你不可能同时让一个 Agent “更守规矩地慢慢做"和"并行地快速干”——这是两个方向上的优化。
社区里的共识也在收敛到这个方向：这俩工具不是互补关系，而是替代关系。 选一个，装好，用透。
到底选谁：场景决策树
聊了这么多原理，到了给结论的时候。我按几种典型场景给出明确建议。
场景一：个人项目 / 副业 / 独立开发
选 Superpowers。
理由很简单。个人项目最怕的不是效率低，是返工。Agent 急着写代码、跑偏方向、漏掉需求，这些才是时间杀手。Superpowers 的 brainstorm → plan → TDD 流程能从源头压住这些问题，而且 Token 消耗增加不多——它只是让 Agent 多想几步，不是多起几个实例。
你一个人用，不需要 Team Mode，不需要 7 个 Agent 并行。一个守纪律的 Agent，比一支需要你协调的小队省心得多。你想想看，OMO 的 Team Mode 跑起来，你在 tmux 里盯着 8 个窗口——你是开发者还是项目经理？个人项目的核心优势就是灵活和快速决策，Superpowers 恰恰不会增加你的管理负担，反而帮你减少返工成本。
还有一个现实考量：Superpowers 零配置。你不需要研究文档、配置 Agent 角色、调试编排逻辑。一行 claude plugin add obra/superpowers 装完就生效。对于"今晚想搞个想法"的场景，这就是最大的优势。
场景二：中型项目 / 小团队协作
Superpowers 为主，OMO 备选。
中型项目的特点是：需求清晰但实现量大，模块边界明确。Superpowers 的子 Agent 开发模式在这里很好用——每个模块派一个子 Agent，干净利落。
但如果你的项目里有一个特别复杂的子系统（比如需要同时搜索大量文档、做多语言代码重构、还要跑 UI 设计迭代），OMO 的专业 Agent 分工会有明显优势。这时候可以考虑在特定子项目里单独用 OMO。
注意：不是同时装两个，而是按项目选择。
场景三：大型工程 / 企业级重构
选 OMO。
当你在面对一个几十甚至上百个文件的重构任务时，单个 Agent 的上下文窗口就是硬约束。不管它多守纪律，它就是记不住那么多文件的细节。你给它 200K 的上下文窗口，一个 100 文件的项目可能就占掉一大半，剩下留给推理和执行的空间捉襟见肘。
OMO 的多 Agent 并行架构在这里才能发挥真正的价值：Explorer 扫描代码快速建立全局认知，Librarian 查文档确保方案可行，Hephaestus 做深度实现，Fixer 修 Bug——各干各的，并行推进。每个 Agent 的上下文窗口只需要关注自己负责的那一部分，整体认知能力通过信息汇总来实现，而不是靠一个 Agent 把所有东西塞进一个窗口。
Team Mode 的 Lead + 8 成员配置，正是为这种场景设计的。Sisyphus 作为编排者负责拆解和协调，确保各 Agent 之间信息对齐，避免"左脚穿右鞋"的问题。
Hash-Anchored Edits 在这种大规模编辑场景下也尤为重要——Agent 改的文件越多，出错的概率越高。传统编辑工具靠行号或字符串匹配，大规模批量编辑时出错率会指数级上升。哈希锚定通过内容校验来定位修改位置，从机制上保证了编辑可靠性，这是面向大规模工程的刚需设计。
代价是 Token 消耗会明显增大——多个 Agent 并行意味着多次 API 调用，成本可能是一个 Agent 方案的 3-5 倍甚至更多。但大型工程的预算通常也允许这个开销，而且省下来的人工时间远超 Token 成本。
场景四：快速原型 / Hackathon / 验证想法
两个都不急用，但如果非要选，Superpowers。
理由：零配置，一行装好，立刻生效。OMO 的安装和配置本身就需要时间，快速验证场景不值得花这个成本。
一句话总结
如果你只能记住一条原则：
Superpowers 解决的是「Agent 不好好干」，OMO 解决的是「Agent 干不完」。前者是纪律问题，后者是产能问题。
你的 Agent 经常跑偏、跳过需求、选错技术方案？装 Superpowers，给它立规矩。
你的任务太大、一个 Agent 上下文不够用、需要并行推进？装 OMO，给它拉一支团队。
两个都很优秀，两个都有明确的适用场景。但如果你同时装了两个，你既得不到 Superpowers 的纪律，也得不到 OMO 的编排能力——只会得到一个互相打架的混乱系统。
选一个，用透它。
这才是工具选型的正确姿势。