国产小模型不稳定？别急着换模型，先给你的 Agent 装上 Superpowers

先说结论

很多 Agent 工作流里所谓“国产模型不稳定”，表面看是模型一会儿聪明、一会儿犯糊涂，真正落到工程现场，常常是两个问题叠在一起：一是模型本身参数规模、训练数据和工具调用稳定性确实不如顶级闭源大模型；二是 Agent 没有稳定的方法论和检查点，导致每一次任务都靠即时发挥。前者短期内不一定能解决，后者可以马上解决：给 OpenClaw、HermesAgent、Codex、Claude、Gemini、OpenCode 这类 Agent 安装一套可复用的 Skill 工作流，例如 Superpowers。

Superpowers 不能把小模型“魔改”成大模型，也不能保证所有国产模型突然拥有顶级推理能力。它真正有价值的地方，是把 Agent 的行为从“靠灵感输出”拉回“按流程工作”：先澄清目标，再写设计，再拆计划，再测试，再审查，再验证。对参数较少、上下文保持能力较弱、输出波动较大的模型来说，这种外置流程约束往往比继续堆提示词更有效。

这篇文章想聊一个很现实的问题：当我们把 OpenClaw、HermesAgent、Codex、Claude、Gemini、OpenCode 乃至更多 Agent 放进日常工作流之后，为什么某些模型看起来特别不稳定？又为什么我会建议先安装 Superpowers 这样的 Skill，而不是第一反应就去换模型、加提示词、调温度或者把系统提示写成一篇论文。

为了避免泄露任何隐私信息，本文所有环境、路径、主机、账号、项目名都使用通用示例，不包含真实内网地址、密钥、业务系统名称或个人配置。文中的命令也以官方公开文档和通用安装方式为准，实际使用前请结合你自己的 Agent 版本确认。

图 1：模型能力、上下文、工具调用和流程约束共同决定 Agent 的最终稳定性。Superpowers 解决的是流程约束这一层。

1. “模型不稳定”到底不稳定在哪里

很多人说国产模型不稳定，通常不是指它完全不能回答问题，而是指它在 Agent 场景里不够可靠。单轮聊天时，它可能已经足够流畅；让它解释一段代码、写一个小脚本、整理一份文档，也许效果并不差。但一旦把它放进真正的 Agent 工作流，问题就会被放大。

常见现象大概有这些：

1. 同一个任务，第一次能做对，第二次突然漏掉关键条件。
2. 刚刚同意的约束，过了几轮就忘记，甚至反过来执行。
3. 一边说“我已经验证”，一边其实没有运行任何命令。
4. 修改代码时喜欢顺手重构，结果把无关逻辑也带坏。
5. 遇到报错先猜原因，不先收集证据。
6. 上下文稍微长一点，就开始把旧事实和新事实混在一起。
7. 让它协作多个 Agent 时，谁负责什么、谁已经完成什么，很快变得混乱。

这些问题看起来像“模型智商不够”，但工程上不能只用智商解释。Agent 不是单纯聊天机器人，它是在一条链路里执行任务：理解目标、读取上下文、决定步骤、调用工具、修改文件、运行验证、汇报结果。任何一个环节不稳定，最后都会表现成“模型不稳定”。

如果模型参数规模较小，或者训练中对长程任务、工具调用、代码库编辑、测试驱动开发这类数据覆盖不足，那么它更容易出现三类波动。

第一类是意图波动。用户明明要求“先评估再升级”，Agent 可能直接开始升级；用户要求“不要泄露任何隐私”，Agent 可能在示例里顺手写出真实路径或地址；用户要求“只修这个问题”，Agent 可能把相邻模块一起重构。

第二类是过程波动。它知道应该排查，却不知道排查顺序；知道应该测试，却把测试放在最后；知道应该写计划，却写完计划马上跳到实现；知道应该验证，却只看命令退出码，不看真实效果。

第三类是证据波动。它会把“我认为可行”说成“已经验证”；把“官方文档大概这么说”说成“官方明确要求”；把“日志里可能有这个原因”说成“根因已经确定”。在生产系统和真实代码库里，这种波动比文风不好更危险。

所以，参数少带来的问题不只是回答短一点、知识少一点，而是在长链路任务里更难保持稳定的工作纪律。

2. 为什么继续堆提示词通常不够

很多人的第一反应是把系统提示写得更长：你必须先分析、必须先计划、必须运行测试、必须不要泄露隐私、必须不要跳步、必须遵循最佳实践。这个方向不是错的，但它很快会遇到上限。

长提示词有三个问题。

第一，提示词越长，模型越容易只记住其中一部分。尤其在上下文已经很长、还混入代码、日志、网页、命令输出之后，一段“请严格遵守”的文字并不等于真正的执行约束。

第二，提示词很难形成状态机。比如“先写测试再实现”不是一句口号，而是一组可检查的步骤：先写失败测试，确认它失败，再写最小实现，确认它通过，再重构，再提交。仅靠自然语言提醒，很难强制 Agent 在每个节点停下来。

第三，提示词不擅长复用。你可以给 Codex 写一套提示，给 Claude 写一套提示，给 Gemini 写一套提示，再给 OpenCode 写一套提示。但每套工具的加载机制、文件位置、技能发现、子 Agent 调度方式都不同。久而久之，你维护的不是方法论，而是一堆散落的“祖传 prompt”。

这就是 Skill 的价值。Skill 不是单纯的一段提示词，而是一份可被 Agent 发现、加载、触发的工作说明。它通常包含触发条件、步骤清单、工具映射、检查点、反模式和验证要求。对 Agent 来说，Skill 更像“操作规程”，不是“情绪鼓励”。

图 2：不稳定输出往往来自缺少检查点，而不是缺少一句更强硬的提示词。

3. Superpowers 是什么

Superpowers 是 Jesse Vincent / obra 维护的一套 Agentic Skills 框架和软件开发方法论。它的官方定位很直接：给编码 Agent 一套完整的软件开发工作流，这套工作流建立在一组可组合的 skills 之上，并通过初始说明确保 Agent 会在合适的时机使用它们。

换成更接地气的话：Superpowers 不是让 Agent 多背几个命令，而是给 Agent 装上一套“工程纪律包”。

它包含的技能大致可以分成几类：

这套东西对大模型也有用，但对小模型、国产模型、混合 Agent 工作流更明显。原因很简单：模型越强，越可能靠内部能力“自己补流程”；模型越弱，越需要外部流程把它扶住。Superpowers 不是替代模型能力，而是把容易漂移的部分外置成可重复的步骤。

4. 为什么它能缓解小模型输出不稳定

我不建议把 Superpowers 说成“增强智商”的工具。更准确的说法是：它降低了 Agent 对模型临场发挥的依赖。

一个没有 Skill 的 Agent 接到任务时，内部大概会发生这样的事：理解用户需求，猜一个合理方案，开始执行，遇到问题再修，最后总结。这个流程短任务还行，长任务就很危险。因为每一步都没有硬检查点，模型状态稍微飘一下，输出就会偏。

装上 Superpowers 后，任务会被拆成更稳定的外部流程。例如：

1. 创建功能或修改行为前，先触发 brainstorming，确认目标和方案。
2. 有明确设计后，触发 writing-plans，把任务拆成短步骤。
3. 需要隔离开发时，触发 using-git-worktrees，避免污染主工作区。
4. 写功能时，触发 test-driven-development，先看到失败测试。
5. 遇到 bug 时，触发 systematic-debugging，先收集证据再修。
6. 准备交付时，触发 verification-before-completion，必须运行验证。
7. 完成分支时，触发 finishing-a-development-branch，决定合并、保留、PR 或清理。

这些步骤本质上是在给模型加“轨道”。模型可以在轨道里发挥，但不应该随意跳轨。对于参数较少、上下文保持较弱、容易自信过头的模型来说，轨道比鼓励更重要。

这也是为什么我认为 Superpowers 特别适合下面几类场景：

1. 你用的是国产开源模型、本地模型、量化模型，单轮能力可以，但长任务容易飘。
2. 你把多个 Agent 串起来，让 OpenClaw 调度、HermesAgent 执行、Codex 改代码、Claude 审查、Gemini 查资料。
3. 你经常让 Agent 操作真实仓库、真实服务、真实配置，不允许它凭空声明完成。
4. 你希望不同 Agent 使用同一套工程习惯，而不是每个工具都有一套口头约定。
5. 你已经写了很多系统提示，但效果仍然依赖当天模型状态和上下文质量。

5. 安装前先理解：每个 Agent 要分别安装

一个容易误解的点是：Superpowers 不是“装到电脑上一次，所有 Agent 自动都有”。不同 Agent 的插件系统、技能目录和加载机制不同，所以官方 README 也明确写了：如果你使用多个 harness，需要分别安装。

这点很重要。比如你在 Claude Code 里装了 Superpowers，并不代表 Codex CLI 自动能用；你在 Codex 里做了 symlink，也不代表 OpenCode 会读取同一个目录；Gemini CLI 又有自己的 extension 机制。多 Agent 用户最好把安装当成一张清单逐项确认。

图 3：Superpowers 不是单点安装，而是按 Agent 分别接入。

下面按常见 Agent 说明安装方式。命令来自 Superpowers 官方 README 和对应安装文档；如果官方后续更新，请以项目仓库为准。

5.1 Claude Code

Claude Code 现在可以通过官方插件市场安装：

/plugin install superpowers@claude-plugins-official

也可以先添加 Superpowers 自己的 marketplace，再安装：

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

安装完成后，重新开启会话，观察 Agent 是否会在合适任务前主动加载相关技能。你也可以直接问它是否知道 Superpowers、有哪些 skills 可用。

5.2 Codex CLI

官方 README 里提到 Codex CLI 可以从插件界面安装：

/plugins

在插件搜索界面里搜索：

superpowers

然后选择安装插件。

如果你使用的是支持原生 skill discovery 的 Codex，也可以按照官方 .codex/INSTALL.md 的方式，用 clone + symlink 接入：

git clone https://github.com/obra/superpowers.git ~/.codex/superpowers
mkdir -p ~/.agents/skills
ln -s ~/.codex/superpowers/skills ~/.agents/skills/superpowers

然后重启 Codex，让它重新发现 skills。验证方式是检查 symlink 是否存在：

ls -la ~/.agents/skills/superpowers

如果你以前用过旧版 bootstrap 方式，官方文档建议更新仓库、建立新的 skills symlink，并移除旧的 bootstrap block。

5.3 Codex App

Codex App 的入口更偏图形化：打开侧边栏的 Plugins，在 Coding 分类里找到 Superpowers，点击 + 并按提示安装。它和 Codex CLI 一样走官方插件市场，但操作入口不同。

5.4 Gemini CLI

Gemini CLI 使用 extension 机制：

gemini extensions install https://github.com/obra/superpowers

后续更新可以执行：

gemini extensions update superpowers

Gemini 的加载方式和 Claude/Codex 不同，所以不要假设共享目录会自动生效。安装后最好新开会话，并让 Gemini 说明当前可用技能。

5.5 OpenCode

OpenCode 有自己的插件配置。官方 .opencode/INSTALL.md 建议在全局或项目级 opencode.json 中加入：

{
  "plugin": ["superpowers@git+https://github.com/obra/superpowers.git"]
}

然后重启 OpenCode。验证可以直接问：

Tell me about your superpowers

如果旧版本曾经用过 clone + symlink，需要清理旧的 symlink 和旧配置，再按新的 plugin 方式安装。OpenCode 文档还提醒：某些 OpenCode 和 Bun 版本可能会缓存 git 依赖，如果更新后没有生效，可以清理缓存或重新安装插件。

5.6 Factory Droid

Droid 的安装方式是先添加 marketplace，再安装插件：

droid plugin marketplace add https://github.com/obra/superpowers
droid plugin install superpowers@superpowers

如果你在 Droid、Codex、Claude Code 之间切换，不要偷懒共用一个“心理上的安装状态”。每个工具都要实际验证。

5.7 Cursor 和 GitHub Copilot CLI

Cursor Agent chat 可以使用：

/add-plugin superpowers

或者在插件市场里搜索 Superpowers。

GitHub Copilot CLI 的安装方式是：

copilot plugin marketplace add obra/superpowers-marketplace
copilot plugin install superpowers@superpowers-marketplace

这类工具不是本文重点，但如果你的日常工作流里也会调用它们，原则一样：分别安装、分别验证、分别更新。

6. OpenClaw / HermesAgent 怎么接入

OpenClaw 和 HermesAgent 这类自建或二次封装 Agent，情况会比官方 CLI 更灵活。因为它们可能不是 Superpowers 官方 README 里直接列出的 harness，也可能运行在网关、插件、会话路由或多模型调度层之上。

这里不要机械照搬某个工具的安装命令，而应该抓住核心：让 Agent 能在会话开始时读取 using-superpowers，并能在任务触发时加载对应 SKILL.md。

一个比较稳妥的接入方式是：

1. 在 Agent 的可读目录里放置 Superpowers 仓库或 skills 目录。
2. 在该 Agent 的系统提示、初始化指令或插件配置中加入“启动时加载 using-superpowers”的要求。
3. 把工具名映射清楚。例如某些 Skill 里写的是 Claude Code 的 Task、TodoWrite、Skill，你的 Agent 可能对应子任务调度、计划列表或本地 skill loader。
4. 对不能支持的能力明确降级。例如没有子 Agent，就用单 Agent 批次执行；没有 worktree 管理权限，就要求先报告不能隔离。
5. 做一次验证任务，不要只看“安装成功”。例如让它解释什么时候会使用 systematic-debugging，或者让它在一个小 bug 上走完整证据链。

如果 OpenClaw 负责调度、HermesAgent 负责某个消息通道或自动化执行，我更建议把 Superpowers 当成“执行层工作规程”，而不是只放在最外层调度器里。调度器知道流程当然有帮助，但真正修改文件、运行命令、提交结果的那个 Agent 也必须知道流程。否则调度器说“请先验证”，执行 Agent 仍然可能只写一句“已验证”。

图 4：自建 Agent 接入时，重点不是复制某条命令，而是让执行者真正能加载、触发和遵守 Skill。

7. 装完以后，怎么判断真的生效

很多插件安装的问题不在安装，而在验证。尤其对 Agent 来说，“能看到文件”不等于“会按流程执行”，“会背 skill 名字”也不等于“任务中会触发”。

我建议至少做五个验证。

第一，问它当前有哪些 Superpowers skills。一个正常接入的 Agent 应该能列出或说明 using-superpowers、brainstorming、systematic-debugging、verification-before-completion 等核心技能。

第二，给它一个小功能需求，观察它是否先澄清目标或提出设计，而不是立刻改文件。注意这里不是要求永远拖慢速度，而是确认它知道“创建功能或修改行为前应该先设计”。

第三，给它一个明确 bug，观察它是否先收集证据。比如让它分析一个失败测试、一个日志错误、一个无法启动的服务。它应该先看现象、复现、收集日志、提出最小假设，而不是上来就改配置。

第四，让它完成任务后必须运行验证命令。它应该报告具体运行了什么、结果是什么、还有什么没有验证，而不是只写“应该可以”。

第五，在多 Agent 场景里，让不同 Agent 分别说明同一个流程。例如 Codex 负责实现、Claude 负责 review、Gemini 负责资料核对。它们不一定每个都完整执行所有 Skill，但至少应该知道自己的边界和检查点。

8. Superpowers 不是万能药

把话说清楚：Superpowers 不能解决所有问题。

它不能让一个本来不会写 Rust 的模型突然写出高质量 Rust；不能让一个上下文窗口太小的模型完整记住几十万行代码；不能让一个工具调用能力不稳定的 Agent 永远不掉链；不能替你绕过权限、网络、依赖和运行环境限制；也不能自动判断你的业务取舍。

它能做的是减少四类常见事故。

第一，减少“没想清楚就动手”。有 brainstorming 和 writing-plans，Agent 更不容易直接冲进实现。

第二，减少“没证据就修”。有 systematic-debugging，Agent 更不容易把猜测当根因。

第三，减少“没测试就交付”。有 test-driven-development 和 verification-before-completion，Agent 更不容易只靠语言自证完成。

第四，减少“多个 Agent 各干各的”。有统一的技能词汇和流程，OpenClaw、HermesAgent、Codex、Claude、Gemini、OpenCode 至少能围绕同一套工作规程协作。

换句话说，Superpowers 提供的是可重复的工程行为，不是神奇的模型增强。你仍然要选择合适的模型，仍然要限制权限，仍然要保护密钥，仍然要做代码审查，仍然要看真实日志和真实测试结果。

9. 一个推荐的落地顺序

如果你现在有一堆 Agent，并且已经明显感觉小模型输出不稳定，我建议不要一次性全改。可以按下面的顺序来：

1. 先选一个最常用的 Agent，比如 Codex 或 Claude Code，安装 Superpowers。
2. 用一个低风险仓库做验证，不要一上来操作生产配置。
3. 先练 debugging 和 verification，不急着上 subagent-driven-development。
4. 等你确认流程有效，再把 Gemini、OpenCode、Droid 或其他 Agent 接进来。
5. 最后再考虑 OpenClaw / HermesAgent 这类自建调度层的统一接入。

这个顺序有个好处：先把“单 Agent 的纪律”跑通，再扩大到“多 Agent 的协作”。否则多个不稳定 Agent 同时接入，只会把问题变成并发混乱。

我个人最看重的三个 Skill 是：

1. systematic-debugging：遇到故障先证据后假设。
2. verification-before-completion：完成前必须真的验证。
3. writing-plans：把大任务拆成小步骤，降低模型临场负担。

如果你的模型能力偏弱，甚至可以先不追求完整 Superpowers 工作流，只把这三类纪律固化下来，输出稳定性也会明显改善。

10. 最后：别把模型能力和工程纪律混为一谈

国产模型能力不够，很多时候确实和参数规模、训练质量、工具调用数据、长上下文能力有关。这个现实不需要回避。顶级闭源大模型在复杂推理、长程一致性、代码库理解、工具调用恢复方面，仍然有明显优势。

但如果因此得出“只能等更大模型”的结论，就太被动了。Agent 的稳定性从来不是模型一个因素决定的。模型只是发动机，Skill 是驾驶规程，测试是刹车，日志是仪表盘，权限是护栏，版本控制是安全带。发动机不够强时，更不能把其他东西拆掉。

Superpowers 的意义就在这里：它不给你承诺奇迹，只给你一套可执行的工程纪律。对强模型，它让输出更稳；对弱模型，它让错误更早暴露；对多 Agent，它让协作有共同语言；对真实项目，它让“已完成”回到证据上，而不是停留在一句漂亮总结里。

所以，如果你正在用 OpenClaw、HermesAgent、Codex、Claude、Gemini、OpenCode 或其他 Agent，又经常被小模型的随机发挥折磨，我的建议很简单：先别急着把提示词写到两千行，也别急着把所有问题都归咎于模型。先给 Agent 装上 Superpowers，让它按流程工作。等流程稳定后，你再判断到底是模型真的不够，还是以前只是没有把 Agent 当工程系统来管理。

来源与延伸阅读

• Superpowers GitHub 仓库：https://github.com/obra/superpowers
• Superpowers Codex 安装文档：https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.codex/INSTALL.md
• Superpowers OpenCode 安装文档：https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md
• Gemini CLI extension 安装方式、Claude Code / Codex / Droid / Cursor / Copilot CLI 安装方式，以 Superpowers README 当前说明为准。