Superpowers 多 Agent 开发卡住怎么排查？2026 环境检查

Superpowers 的跨 harness 移植指南把“每次会话启动时自动注入”列为一项硬性要求；因此，先确认当前 coding harness 能否注入会话、提供文件与 Shell 工具并派发子任务，再检查插件是否启用。缺少必要能力时，切换到支持的工作流或人工串行执行，不要反复重装。官方移植指南

本周建议动作：用一个最小任务复现问题，并记录第一次异常发生的环节。这样你能区分技能未触发、工具受阻和子任务没回传，而不是把它们都归因于安装失败。

适合已安装 Superpowers、却遇到技能没触发或多 Agent 流程中断的开发者；也适合在不同 coding harness 间切换的工程师，以及需要维护远程开发会话的团队。

先看症状：技能没触发，还是子任务派发失败？

Superpowers 不只是技能文件。官方说明将它描述为由技能和初始指令组成的开发工作流；而具体安装方式会因 harness 不同而变化。项目 README 因此，先定位问题在哪个环节，再决定是否检查安装。

用一个不会修改重要文件的最小任务复现，例如要求 AI 编程 Agent 阅读指定文件、说明一处可验证的问题，并把结果交回主会话。只观察可见事件，不推断模型内部发生了什么。

首次异常位置	更可能的故障来源	你应先检查什么
会话刚启动，技能没有出现	插件未启用、启动注入未运行，或当前 harness 加载机制不同	新会话是否读取插件；会话启动日志是否有注入记录
技能已出现，但没有开始派发	任务描述、技能流程或子任务工具能力不匹配	任务是否明确要求派发；当前 harness 是否提供派发能力
子任务已派发，但没有可用结果	子任务未执行完、输出没写回，或会话状态中断	子任务状态、日志、结果回传位置
有结果，但报告称已完成、证据不完整	验证未执行、工具不可用，或失败信息未保留	测试命令、实际输出、失败状态和审查记录

注意：最小复现的目标是找断点，不是证明模型“为什么这么想”。只根据日志和可见任务状态下结论。

技能未触发：从会话注入开始检查

技能文件存在，不等于当前会话已经加载。项目的 using-superpowers 技能用于建立查找和使用技能的工作方式；官方移植指南则要求 harness 能在每次会话开始时自动把相关指令放进上下文。using-superpowers 技能说明

逐项核对：

✅ 当前插件或扩展确实安装在你正在使用的 harness，而不是只装在另一款工具里。
✅ 插件状态为启用；若首次启用需要批准，完成批准后再开新会话。
✅ 启动机制能自动加载技能或注入指令，而不是要求你每次手动粘贴提示词。
✅ 新会话已创建；安装或更新后，旧会话不一定重新执行启动注入。
✅ 技能目录和入口文件能被当前 harness 发现；不要只凭“磁盘上有文件”判断加载成功。

项目 README 对不同 harness 分别列出安装方式；移植指南还说明，支持机制可以是启动钩子、插件回调或 harness 提供的指令文件约定。用户自行拼接文件、手动补提示词，并不等同于官方集成或稳定支持。项目安装说明官方移植指南

更换 coding harness 后，不要假设插件会跟着迁移。逐一确认新环境的安装渠道、技能发现方式、启动注入机制和当前会话状态。能看到技能文件，但启动时没有注入记录，问题更可能在集成方式，而非技能内容本身。

第一步：对照能力，而不是猜工具名

Superpowers 的多 Agent 技能需要工作环境支持任务派发；项目的子 Agent 开发技能把“派发实现任务”作为工作流的一部分。子 Agent 开发技能但“安装了 Superpowers”和“当前会话有子 Agent 工具”是两回事。

必要能力	怎么确认	缺少时的判定
会话启动注入	查看 harness 插件状态、启动日志或可见的启动提示	技能不能自动进入新会话；先修安装或改用支持的入口
文件读取与写入	用低风险任务确认可读取指定文件；需要改文件时，确认写入工具可用	只读任务可继续；实现任务不能假定写入成功
Shell 命令	确认允许执行项目约定的测试命令，并检查权限提示或拒绝日志	命令被拒绝就处理授权；工具不存在则停止试猜名称
子任务派发	确认工具清单或运行界面确有派发功能，并观察是否产生子任务状态	无派发能力时，使用人工拆分、串行执行和逐项审查

不同 harness 的技能加载方式、插件安装方式和可用工具可能不同。当前官方支持什么，以 Superpowers 对应 harness 文档和运行时实际能力为准；社区适配或个人配置不应直接当作官方兼容承诺。

如果派发动作没有出现在工具清单里，不要轮流尝试猜测的工具名，也不要通过关闭所有权限来“验证”。先确认 harness 是否支持子任务；权限问题则查看具体拒绝的工具和路径。运行时的权限提示确实可能阻止工具执行，且不同环境的批准流程并不相同。工具权限与审批说明运行时审批状态说明

提醒：没有子 Agent 工具，通常仍可用 Superpowers 的技能指导你拆解和完成任务；但派发型步骤要改成你手动逐项执行。不要把“人工串行完成”记录成“子 Agent 成功启动”。

子 Agent 没有结果：从任务状态追到主会话

派发后没有回传，不足以证明子 Agent 没有运行。你要分别查派发是否发出、子任务是否有状态变化、结果是否写回主流程，以及会话有没有重启或上下文压缩。只记录日志能证明的事情。

可见证据	可以得出的判断	不能据此断定
有派发记录，但没有完成状态	子任务可能尚未完成，或执行被中断	模型内部是否“忘记任务”
子任务完成，但主会话看不到结果	回传、状态同步或会话恢复环节需要检查	任务内容必然丢失
会话重新启动后没有原任务进度	检查恢复记录、任务文件和日志	仅凭新会话断定插件损坏
任务描述依赖主会话未提供的信息	子任务上下文可能不足	将问题直接归咎于工具权限

把任务描述写成可独立执行的单元：给出目标、相关文件或路径、允许的操作、完成条件，以及结果应返回到哪里。不要假定子任务能自动继承主会话中所有讨论。长会话发生压缩或重启时，先查运行时是否提供恢复状态，再核对任务状态和结果文件；没有证据，就把结论写成“未确认”。

第二步：把“已验证”与“没有验证”分开

工作流报告不完整时，分别记录测试命令、实际输出、退出状态和代码审查结果。命令没有执行，不等于测试通过；工具不存在，不等于测试失败；测试报错，也不代表子任务一定没有完成。

验证记录	应如何判定
测试命令已运行且返回失败	记为真实测试失败，保留输出和失败原因
测试命令未运行	记为未验证，并说明未执行原因
Shell 工具缺失或权限阻止执行	记为工具不可用或执行受阻，不标注测试通过
有测试结果，但缺少审查结果	保留测试状态，并单独标出审查未完成
子任务报告完成，但没有结果文件或验证证据	标记为待核验，再由主会话检查产物

Superpowers 的子 Agent 开发流程涉及实现与审查环节，因此你应分别留存实现结果、验证证据和审查结论，不能用一句“完成”替代这些记录。

按条件选修复方案：配置问题还是能力边界？

使用下面的分支，避免把每一种异常都变成重装问题：

若新会话没有加载技能，但当前 harness 支持启动注入：检查插件是否启用、安装渠道是否正确，以及启动机制是否获准运行；修复后重新开会话复测。
若技能已加载，文件与 Shell 工具可用，但派发失败：检查子任务工具是否真实存在、是否被运行策略阻止，以及任务是否包含独立执行所需的上下文。
若 harness 没有会话启动注入：不要把每次手动粘贴提示词称作自动支持；改用官方支持的 harness，或明确记录为人工辅助流程。
若 harness 没有子 Agent 工具：保留可用的技能指导，改为人工拆分、串行执行、逐项测试与审查；不要再尝试重装来补出不存在的能力。
若问题只在远程会话或会话恢复后出现：先核对插件状态、权限、会话日志和工作区恢复情况，再用同一最小任务复测。运行环境和工作区状态不同，结果也可能不同。

第三步：留下可复现记录，再决定是否升级

建立一份简短的故障记录。只填实际观察到的内容，不记录用户凭据或项目机密。团队在远程环境交接时，可以把帮助中心的环境支持入口纳入内部排查流程；记录本身仍应保存在你有权限访问的位置。

记录字段	填写内容
问题现象	首次异常发生在会话启动、技能调用、工具执行还是结果回传
运行环境	harness 名称与版本、远程或本地、会话是否新建或恢复
插件状态	安装来源、启用状态、启动注入是否可观察
工具状态	文件读写、Shell、子任务派发分别可用、受阻或缺失
最小复现	任务输入、操作步骤、可观察的预期结果
修复与复测	修改了什么；相同任务再次运行后出现什么结果

升级插件、切换 harness 或调整运行策略后，用同一份最小复现重新测试，并对照原始记录。若断点消失，记录具体改变；若仍出现，保留新日志与状态，不要把“重装过”当作排查结论。项目文档指出 harness 的集成机制会变化；重新核对对应文档，比沿用过期的安装步骤可靠。

如果你的当前方案依赖手动补提示词、反复授权，或在远程会话中难以确认插件和工作区状态，这些都是可见的维护成本；但若你需要长期稳定的重负载环境或必须连接特定物理设备，租赁并不一定合适。若你只是需要临时、可独立验证的开发环境，可以对照 Hashvps 的方案说明，先确认交付方式和所需工具是否匹配，再决定是否租用 Mac。