当我们谈论编码代理（coding agent）的进化时，通常关注的是模型能力、上下文窗口长度或工具调用能力。然而，Jesse（obra）开源的 Superpowers 项目揭示了一个被低估的维度：如何通过结构化的技能系统，将代理从「执行命令的工具」提升为「理解意图的协作伙伴」。这个框架的核心理念不是让代理更聪明，而是让代理在正确的时间做正确的事。
技能框架的设计哲学
Superpowers 并不是一个传统意义上的代理框架，它更像是一套「元技能系统」。项目作者在文档中明确指出：当用户启动编码代理时，代理不会立即跳入代码编写，而是「后退一步，询问用户真正想要做什么」。这种设计哲学贯穿整个框架，其核心原则可以归纳为三点：首先，系统性优先于临时性，强调流程而非猜测；其次，复杂度最小化是首要目标；最后，用验证替代声明，在真正成功之前不宣布胜利。
这种设计理念与当前流行的 Function Calling 或 Tool Use 范式有本质区别。传统方案中，开发者需要预先定义代理可能使用的工具集合，然后依赖模型的推理能力来决定何时调用哪个工具。Superpowers 的做法是让技能（Skill）成为一等公民，每个技能都是一段可执行的指令模板，包含触发条件、执行步骤和完成标准。当代理识别到当前上下文符合某个技能的触发条件时，系统会自动激活该技能，整个过程对用户透明。
七阶段工作流的工程实现
Superpowers 定义了一套完整的工作流，覆盖了软件开发的完整生命周期。这个工作流由七个核心技能阶段组成，每个阶段都有明确的入口条件和产出标准。
第一阶段是 brainstorming，当代理检测到用户正在讨论功能需求或问题定义时自动触发。这个阶段采用苏格拉底式提问来澄清用户意图，将粗粒度的想法拆解为可验证的设计要点，最终产出结构化的设计文档供用户审阅。第二阶段是 using-git-worktrees，在设计文档获得用户批准后激活，为每个实现任务创建隔离的 Git Worktree 环境，确保多个功能可以并行开发而不互相干扰。第三阶段是 writing-plans，将设计文档转化为可执行的任务清单，每个任务都有精确的文件路径、完整的代码片段和验证步骤，推荐的任务粒度为二到五分钟。
第四阶段是 subagent-driven-development 或 executing-plans，这是整个框架最复杂的能力。代理会将任务分发给子代理并行执行，每个子代理完成后会经历两阶段审查：首先是规格符合性检查，确保实现满足设计要求；其次是代码质量检查，包括测试覆盖率和最佳实践遵循度。官方文档指出，配置良好的 Claude 可以自主工作数小时而不偏离计划。第五阶段是 test-driven-development，在实现过程中强制执行红绿重构循环：先写失败的测试，观察测试失败，编写最小化代码使测试通过，最后重构。关键规则是在测试通过前编写的任何代码都会被删除。
第六阶段是 requesting-code-review，在任务之间自动插入代码审查环节，审查清单包括与计划的符合度、问题严重程度分级等内容，致命问题会阻止开发继续。第七阶段是 finishing-a-development-branch，当所有任务完成后触发，验证测试结果并提供多种后续选择：合并到主分支、创建 Pull Request、保留分支或丢弃。这七个阶段形成了一个完整的闭环，每个阶段都有明确的输入输出契约和转换条件。
技能触发的内部机制
理解 Superpowers 的技能触发机制是工程落地的关键。根据项目文档，技能被组织在一个分层结构中，每个技能包含元数据定义和执行指令两部分。元数据定义了技能的触发条件，这些条件通常是上下文模式匹配，例如当对话中出现「帮我计划这个功能」或「让我们调试这个问题」时，相关技能会自动激活。
触发机制的工程实现有几个值得关注的细节。首先是优先级管理，当多个技能的触发条件同时满足时，系统会根据技能的覆盖范围和当前工作流阶段来确定执行顺序。其次是状态传递，每个阶段完成后会生成结构化的产物，这些产物会被自动注入到下一个阶段的上下文中，使得子代理能够继承完整的项目上下文。第三是回滚策略，如果某个子代理的执行结果未通过审查，系统会自动触发重做流程，而不是继续下一步。
项目提供了针对不同平台的安装方式。Claude Code 用户可以通过插件市场安装：先执行「/plugin marketplace add obra/superpowers-marketplace」添加市场，然后执行「/plugin install superpowers@superpowers-marketplace」完成安装。Cursor 用户直接在 Agent 聊天窗口的市场中搜索安装即可。Codex 和 OpenCode 用户需要手动执行安装脚本，具体步骤可以从项目的 INSTALL 文档中获取。安装完成后，验证方式是启动新的会话并询问一个应该触发技能的问题，例如「帮我规划这个功能」，代理应该自动调用 brainstorming 技能。
与现有架构的关键差异
将 Superpowers 与当前主流的代理架构进行对比，可以发现几个显著的工程差异。在意图识别层面，传统的 Function Calling 依赖模型自己的能力来推断用户意图，而 Superpowers 通过显式的技能层来规范化这个过程。在工作流编排层面，LangChain 或 AutoGen 等框架通常需要开发者显式定义工作流步骤，Superpowers 的技能系统则实现了自动状态转移。在工具集成层面，Superpowers 不关注具体工具的实现细节，而是关注使用工具的流程规范，这种关注点分离使得框架更具通用性。
子代理驱动开发是 Superpowers 最具特色的工程能力。不同于简单的任务分解，这个模式强调的是「代理可以驱动其他代理」这一能力。每个子代理都是独立的执行单元，拥有自己的上下文和工具集，主代理扮演的是任务调度和质量控制的角色。这种架构在处理复杂项目时特别有效，因为可以将不同类型的问题分配给专门化的子代理处理。
从工程落地的角度看，Superpowers 为组织带来的价值主要体现在三个方面：标准化团队的开发流程，通过强制执行工作流阶段来减少过程变异；提升代理的可靠性，明确的完成标准使得代理的行为更可预测；支持增量扩展，新的技能可以按照统一规范添加到系统中而不影响现有能力。这些特性使得 Superpowers 不仅仅是一个工具，而是一种软件工程方法论的载体。
资料来源：GitHub 仓库 obra/superpowers（MIT License）