2026年4月24日 · 阅读 —
别再让 AI 工具互相打架了：Superpowers 与 gstack 的全局路由协议
别再让 AI 工具互相打架了：Superpowers 与 gstack 的全局路由协议
在 AI 编程和自动化工作流越来越复杂之后，很多人会遇到一个很烦的问题：
不是工具不够强，而是工具太多了，开始互相抢活。
一个负责规划，一个负责执行，一个擅长浏览器操作，一个擅长调试排障。单看都很好，但一旦没有边界，结果往往是：
- 两套流程同时自动触发
- 都想接管当前任务
- 一个刚开始拆计划，另一个已经准备接管验证
- 默认控制权来回覆盖
- 最终用户反而要花精力“协调工具”
这不是“智能”，这是内耗。
所以，我专门写了一份全局 AGENTS 路由协议，核心目标只有一个：
让 Superpowers 和 gstack 明确分工，不抢主控，不重复接管，不互相覆盖。
这篇文章，就把这套协议的设计思路讲清楚。
一、先解决最根本的问题：谁说了算？
任何多 Agent、多 Skill、多插件协作系统，如果不先定义优先级，后面所有分工都会失效。
我给这套协议定的最高优先级顺序是：
- 用户当前回合的明确指令
- 当前项目目录下的
AGENTS.md - 全局
AGENTS.md - 插件或 skill 自带的默认说明
这背后的原则非常简单：
1. 用户明确点名，直接服从
如果用户明确说：
- 用 Superpowers
- 用 gstack
- 用某个指定 skill
- 用某个命令或工作流
那就直接执行，不要搞“智能二次分流”。
因为用户已经完成了路由决策，系统不应该再抢方向盘。
2. 项目规则高于全局规则
不同项目有不同的工程背景、文档结构、执行约束。
所以如果项目内已经有自己的 AGENTS.md，那项目规则优先，全局规则只能退到辅助地位。
3. 全局协议只做“边界管理”
这份全局协议的职责不是替代所有工作流，而是解决：
- 谁是主流程
- 谁是补充能力
- 什么情况下切换
- 什么情况下不能双开
也就是说，它只做路由裁判，不做一切事务的总控制器。
二、核心分工：Superpowers 管通用研发，gstack 管专项工程能力
这套协议最重要的设计，就是给两个能力框架明确定位。
Superpowers 是什么？
我把 Superpowers 定义成默认的通用研发流程框架。
它适合接管的任务包括：
- 需求澄清
- 方案讨论
- 写 spec
- 写 implementation plan
- TDD
- 系统化调试
- 子代理协作开发
- 开发分支收尾
也就是说，只要任务属于“怎么做、怎么拆、怎么改、怎么查”这一类，默认就归 Superpowers。
典型触发意图
比如这些表达，天然应该走 Superpowers：
- 帮我规划这个功能
- 先写方案
- 给我一个实施计划
- 按 TDD 做
- 系统化排查这个 bug
- 把这件事拆给多个 agent 做
- 收尾这个开发分支
更细的 skill 路由
为了让路由更清晰，我又把 Superpowers 内部再细分成几类典型工作模式：
-
superpowers:brainstorming
适用于需求模糊、方向未定、先要澄清目标 -
superpowers:writing-plans
适用于方案已定，需要拆文件落点、实现步骤、验证方式 -
superpowers:systematic-debugging
适用于 bug 排查、结果不对、状态漂移、偶发问题 -
superpowers:test-driven-development
适用于新增功能、逻辑重写、先补测试再改代码 -
superpowers:verification-before-completion
适用于准备收尾前，做完整验证和风险回归 -
superpowers:subagent-driven-development
适用于任务很大、可拆分、适合多个 agent 并行推进
所以，Superpowers 的本质不是“某个技能”，而是一个通用研发主流程容器。
gstack 是什么？
我把 gstack 定义为专项能力框架，不是默认总控。
它只负责那些明显偏“验证、运行态、页面、上线、巡检”的任务，比如：
- 浏览器联调和真实页面操作
- 端到端 QA
- 上线前后验证
- benchmark / 性能回归
- canary / 发布后巡检
- security / CSO 审计
- 设计评审与视觉 QA
- ship / deploy / PR 流程
- checkpoint / resume
- 文档发版收尾
典型触发意图
比如这些请求，更适合 gstack：
- 打开网页看看
- 测一下这个流程
- 做 QA
- 做 benchmark
- 做 canary
- 做安全检查
- 发版
- deploy
- 提 PR
- 保存进度
- 恢复上下文
换句话说：
Superpowers 负责“研发主流程”，gstack 负责“专项工程动作”。
三、为什么一定要防止“双主流程”？
很多 AI 工作流系统的最大问题，不是能力不够，而是：
两个框架都觉得自己有资格接管。
这会直接导致三类问题：
1. 重复启动
一个准备写计划，一个准备开 QA，一个要先补测试，一个又要先巡检。
结果是，同一轮任务里两个框架同时起手。
2. 默认控制权冲突
用户没明确指定时，双方都试图当“默认入口”，最后谁都不服谁。
3. 用户心智被打散
用户本来只想解决问题，结果还得理解：
- 为什么这次是它先接管？
- 为什么另一个突然插进来？
- 为什么流程被改造成了审批链？
所以这份协议里有一条非常关键的硬规则：
默认一回合只允许一个“主流程框架”接管当前任务。
具体规则是：
- 用户明确指定
Superpowers，就直接用Superpowers - 用户明确指定
gstack，就直接用gstack - 请求明显属于
gstack的专项能力时，优先gstack - 其他一般开发任务，默认
Superpowers - 如果
gstack已经接管，就不要再隐式触发Superpowers当第二主流程 - 如果
Superpowers已经接管，就不要再隐式触发gstack当第二主流程 - 只有主流程明确需要专项能力时，另一方才能作为补充能力出现
这一条是整份协议最关键的稳定器。
四、补充调用可以有，但不能“反向劫持”
很多人一听“一回合只允许一个主框架”，会担心：
那岂不是太死板？
其实不是。
我限制的是双主控，不是限制协作。
比如下面这种组合是允许的：
Superpowers负责规划与实现，最后调用gstack做浏览器 QASuperpowers负责系统化调试，最后调用gstack做上线后巡检gstack负责 canary 和页面验证，但不反过来接管实现计划和 TDD
这里的关键不是“能不能调另一个”，而是：
谁是主流程，谁是补充能力，必须清楚。
不能出现这种情况：
- 本来是实现任务，结果 gstack 先把节奏带走
- 本来是 QA 任务，结果 Superpowers 又硬插进来重做一遍计划
- 一个只是辅助调用，最后却反向劫持了整个任务控制权
所以我把边界写得很明确：
主流程可以按需调用另一侧能力，但补充能力不能反向升级成新的主流程。
五、量化任务为什么要单独立规矩？
量化、交易、回测、执行链路类任务，跟普通研发任务不一样。
因为这一类任务最容易出现一种假象：
“图上看起来对，但实际上不可交易。”
所以在协议里，我专门给量化任务单独加了一层硬规则。
1. 策略设计与信号定义，默认走 Superpowers
适用范围：
- 定义买卖条件
- 把主观交易想法翻译成规则
- 指标、因子、信号组合设计
- 策略模块结构设计
默认审查视角：
WilliamCharlotte- 复杂实现时补
Benjamin
2. 回测与统计评估，默认走 Superpowers
适用范围：
- 回测框架开发
- 样本切分
- 指标统计
- 参数敏感性分析
- 稳健性与过拟合检查
默认审查视角：
CharlotteWilliam- 涉及实现正确性时补
Benjamin
3. 数据清洗与特征构造，默认走 Superpowers
适用范围：
- K 线、tick、订单簿清洗
- 缺失值、脏数据、重复数据处理
- 特征工程
- 数据对齐与时间戳修复
默认审查视角：
BenjaminCharlotte- 涉及批处理性能时补
Henry
4. 实盘执行与交易链路，主流程还是 Superpowers
但如果任务目标变成：
- 验证线上链路
- 发布后检查
- 浏览器后台操作
- 运行态巡检
那就允许补 gstack。
默认审查视角：
WilliamLucasHenry- 架构复杂时补
Noah
5. 发布验证与运行监控，默认走 gstack
这部分包括：
- 上线前检查
- 发布后巡检
- benchmark
- canary
- 真实页面或控制台验证
- 安全检查
默认审查视角：
HenryLucas- 安全相关补
Harper
六、缠论任务最容易踩坑，所以必须先尊重“项目定义”
缠论是量化场景里最容易“同名不同义”的领域。
因为很多概念听起来一样，但在不同项目里口径可能完全不同，比如：
- 分型
- 笔
- 段
- 中枢
- 背驰
- 一二三类买卖点
- 同级别分解
- 多级别联立
- 走势类型
如果不先看项目定义，直接套一个通用缠论解释，基本一定会出事。
所以我在协议里加了一个非常硬的原则：
缠论相关任务，项目自定义定义优先于任何通用解释。
定义发现顺序
必须按顺序找：
- 项目级
AGENTS.md - 项目策略定义文件，比如
docs/chanlun-spec.md README、架构文档、策略说明文档- 如果文档还不够，再从代码实现反推当前有效定义
不能一上来就拿通用缠论知识硬套。
如果只能从代码反推
那也必须明确区分三件事：
- 文档里明确写死的规则
- 代码里当前实际实现的现状
- 基于代码行为推断出的临时结论
而且必须写明：
这是根据当前实现反推出的定义，不等于最终策略文档。
这一步非常重要，因为很多策略系统都是：
- 文档过时
- 代码先跑起来了
- 真正生效的是代码，不是文档
如果这时还装作“定义已经统一”，就会把后续回测、执行、解释全部带偏。
七、缠论量化最怕“主观化”，所以必须先量化结构定义
协议里我给缠论加了几条强制校验项，本质上就是一句话：
所有结构定义都必须能落到代码。
比如：
结构定义必须先量化
所有分型、笔、段、中枢定义必须明确：
- 包含关系怎么处理
- 未完成 K 线是否参与判定
- 实时结构与回看结构是否一致
不能接受这种表述：
- 看起来像
- 感觉结构成立了
- 这里应该算一个中枢
这种说法适合聊天，不适合量化系统。
多级别联立必须说明对齐方式
必须明确：
- 各级别 K 线如何同步
- 低级别信号怎么映射到高级别结构
- 触发时点来自哪个级别
- 在哪根 bar 上确认
不能默认认为多级别天然同步。
背驰必须说明量化口径
必须明确到底依据什么判断背驰，比如：
- MACD 柱面积
- 黄白线斜率
- 波动率归一化后的力度比较
- 成交量或成交额辅助确认
不能只说一句：
“这里明显背驰。”
因为“明显”本身不能回测，也不能复现。
买卖点必须检查交易可执行性
必须区分：
- 图形成立时点
- 真实可下单时点
还必须把：
- 手续费
- 滑点
- 延迟
- 分型确认滞后
都纳入评估。
否则就会出现一种假策略：
图上每一笔都很漂亮，实盘根本打不出来。
回测与实盘一致性必须单独说明
必须检查：
- 是否区分事后标注结构与实时可得结构
- 是否存在重绘
- 信号确认延迟有多大
- 中枢扩展或结构破坏后，原信号如何失效
如果这几点不说清楚，很多“高胜率策略”都只是回看幻觉。
八、量化任务必须有一套统一的强制校验项
除了缠论专项规则外，我又给所有量化任务统一加了几条硬规则。
策略设计
必须说明：
- 信号依赖的数据粒度
- 触发时点
- 是否会重绘
- 手续费、滑点、延迟是否入模
- 哪些前提还没有验证
回测与评估
必须说明：
- 样本区间
- 交易品种
- 周期
- 数据来源
- 是否区分 in-sample / out-of-sample
- 资金曲线计算方式
默认不能只报收益率，还要同时给：
- 最大回撤
- 胜率
- 盈亏比
- 交易次数
- 成本后结果
如果样本太少、明显过拟合、统计失真，必须直接指出。
数据处理
必须说明：
- 缺失值
- 重复值
- 脏数据
- 时区
- 复权
- 时间对齐
不能默认假设数据天然干净。
实盘执行
必须检查：
- 幂等
- 重试
- 断连恢复
- 订单状态一致性
并明确区分：
- 信号生成成功
- 订单实际成交成功
涉及真实资金时，默认按高风险任务处理。
风控
必须明确：
- 触发条件
- 执行动作
- 恢复条件
- 极端行情处理路径
- 拒单、断网、异常状态的恢复方案
任何自动补单、自动重试、自动加仓逻辑，都必须高风险审查。
结论输出
任何量化结论都要分成三部分：
- 已验证事实
- 依赖假设
- 仍需验证的风险
证据不够时，不能把策略直接说成“可用”或“稳健”。
九、这套协议其实不是在“加规则”，而是在减少混乱
很多人看到这种协议，会觉得：
这是不是又加了一堆限制？
但我真正想解决的，不是把系统变复杂，而是把复杂性从运行时前移到规则层。
也就是说：
- 不要等两个框架打起来，再临场协调
- 不要等量化结论出错，再追问定义到底是什么
- 不要等上线前才发现执行链路和验证链路混在一起
- 不要等策略回测很好看，才发现信号其实不可交易
这套协议的价值，不在于“写得很全”，而在于它解决了三个高频失控点：
1. 解决主控冲突
谁负责规划，谁负责专项动作，先定清楚。
2. 解决领域定义漂移
尤其是缠论、交易、执行链路这类高歧义任务，必须先对齐项目口径。
3. 解决“看起来完整，实际上不可执行”的假严谨
很多流程文档写得很漂亮，但没有真正落到：
- 可代码化
- 可验证
- 可交易
- 可回放
- 可复现
而这份协议就是逼系统始终朝“可执行”靠拢。
十、最后给这套协议一句话总结
我在协议最后写了一条默认策略，其实就是整篇文章的结论：
- 通用研发流程，走
Superpowers - 专项工程能力，走
gstack - 用户明确指定，直接服从
- 一回合只允许一个主框架，另一方只能作为补充能力出现
说白了，真正好用的 AI 协作系统，不是“所有能力都能自动触发”。
而是：
该谁上，就谁上；不该抢活，就别抢。
这才是一个多 Agent 系统真正成熟的开始。