全局 AGENTS 路由协议

全局 AGENTS 路由协议，让 Superpowers 与 gstack 明确分工，避免双重自动触发、重复接管流程、或相互覆盖默认控制权。

# 全局 AGENTS 路由协议

目的：让 `Superpowers` 与 `gstack` 明确分工，避免双重自动触发、重复接管流程、或相互覆盖默认控制权。

## 1. 最高优先级

优先级从高到低如下：

1. 用户当前回合的明确指令
    
2. 当前项目目录下的 `AGENTS.md`
    
3. 本全局 `AGENTS.md`
    
4. 已安装插件或 skill 的默认说明
    
    规则：
    

- 如果用户明确点名某个插件、skill、命令或工作流，直接执行，不做二次路由争夺。
    
- 如果项目内 `AGENTS.md` 与本文件冲突，以项目内文件为准。
    
- 本文件只负责路由和职责边界，不负责强制引入第三套工作流。
    

## 2. 主职责分工

### Superpowers 的职责

`Superpowers` 是默认的通用研发流程框架，适用于以下任务：

- 需求澄清
    
- 方案讨论
    
- 写 spec
    
- 写 implementation plan
    
- TDD
    
- 系统化调试
    
- 子代理协作开发
    
- 开发分支收尾
    
    出现以下意图时，优先让 `Superpowers` 接管：
    
- “帮我规划这个功能”
    
- “先写方案/设计/计划”
    
- “按 TDD 做”
    
- “系统化排查这个 bug”
    
- “把这件事拆给多个 agent 做”
    
- “收尾这个开发分支”
    
    细粒度触发词：
    
- `superpowers:brainstorming` 适用于需求模糊、方案未定、需要先澄清目标与边界 典型表达：
    
    - “这个值不值得做”
        
    - “先帮我想方案”
        
    - “我有个想法，帮我整理一下”
        
- `superpowers:writing-plans` 适用于方案已定，需要拆实现步骤、文件落点、验证步骤 典型表达：
    
    - “给我一个实施计划”
        
    - “拆成可执行步骤”
        
    - “告诉我先改哪些文件”
        
- `superpowers:systematic-debugging` 适用于 bug、异常、结果不对、状态漂移、偶发问题 典型表达：
    
    - “为什么坏了”
        
    - “帮我排查这个 bug”
        
    - “结果不对，但我不知道根因”
        
- `superpowers:test-driven-development` 适用于新增功能、逻辑重写、可测试边界清晰的实现任务 典型表达：
    
    - “按 TDD 做”
        
    - “先补测试再改”
        
    - “重写这段逻辑但别回归”
        
- `superpowers:verification-before-completion` 适用于已经做完实现，需要在结束前验证行为、回归与交付质量 触发时机：
    
    - 声称“已经修好/已经完成”之前
        
    - bug 修复后
        
    - 策略或执行逻辑改动后
        
    - 任何高风险改动收尾前
        
- `superpowers:subagent-driven-development` 适用于任务可拆分、上下文较大、需要多 agent 并行推进 典型表达：
    
    - “拆给多个 agent 做”
        
    - “这个任务很大，分工推进”
        
    - “并行处理多个子任务”
        

### gstack 的职责

`gstack` 只负责专项能力，不作为默认总控框架。优先用于以下任务：

- 浏览器联调与真实页面操作
    
- 端到端 QA
    
- 上线前后验证
    
- benchmark / 性能回归
    
- canary / 发布后巡检
    
- security / CSO 审计
    
- 设计评审与视觉 QA
    
- ship / deploy / PR 流程
    
- checkpoint / resume
    
- 文档发版收尾
    
    出现以下意图时，优先让 `gstack` 接管：
    
- “打开网页看看”
    
- “测一下这个流程”
    
- “做 QA / review / benchmark / canary”
    
- “发版 / ship / deploy / 提 PR”
    
- “做安全检查”
    
- “保存进度 / 恢复上下文”
    

## 3. 量化任务路由

量化、交易、回测、执行链路相关任务，按下面方式细分，不要混用。

### 策略设计与信号定义

默认走 `Superpowers`。

适用：

- 定义买卖条件
    
- 把主观交易想法翻译成可执行规则
    
- 指标、因子、信号组合设计
    
- 策略模块结构设计
    
    默认审查视角：
    
- `William`
    
- `Charlotte`
    
- 复杂结构补 `Benjamin`
    

### 回测与统计评估

默认走 `Superpowers`。

适用：

- 回测框架开发
    
- 样本切分
    
- 指标统计
    
- 参数敏感性分析
    
- 稳健性与过拟合检查
    
    默认审查视角：
    
- `Charlotte`
    
- `William`
    
- 涉及实现正确性时补 `Benjamin`
    

### 数据清洗与特征构造

默认走 `Superpowers`。

适用：

- K 线、tick、订单簿数据清洗
    
- 缺失值、脏数据、重复数据处理
    
- 特征工程
    
- 数据对齐与时间戳修复
    
    默认审查视角：
    
- `Benjamin`
    
- `Charlotte`
    
- 涉及吞吐与批处理性能时补 `Henry`
    

### 实盘执行与交易链路

默认走 `Superpowers`，但如果目标是验证线上链路、发布后检查、浏览器后台操作或运行态巡检，补 `gstack`。

适用：

- 下单执行逻辑
    
- 仓位管理
    
- 风控触发
    
- 订单状态机
    
- 交易所 API 交互
    
- 线上执行链路排查
    
    默认审查视角：
    
- `William`
    
- `Lucas`
    
- `Henry`
    
- 架构较复杂时补 `Noah`
    

### 风控与异常恢复

默认走 `Superpowers`。

适用：

- 止损止盈
    
- 熔断
    
- 仓位限制
    
- 异常状态恢复
    
- 网络断连、重试、补单、幂等设计
    
    默认审查视角：
    
- `Lucas`
    
- `William`
    
- `Noah`
    

### 发布验证与运行监控

默认走 `gstack`。

适用：

- 上线前检查
    
- 发布后巡检
    
- benchmark
    
- canary
    
- 真实页面或控制台验证
    
- 安全检查
    
    默认审查视角：
    
- `Henry`
    
- `Lucas`
    
- 安全相关补 `Harper`
    

## 4. 缠论量化规则

当用户提到以下概念时，默认视为“缠论量化任务”：

- 分型
    
- 笔
    
- 段
    
- 中枢
    
- 背驰
    
- 一类买点 / 二类买点 / 三类买点
    
- 一类卖点 / 二类卖点 / 三类卖点
    
- 同级别分解
    
- 多级别联立
    
- 走势类型
    
    主流程默认仍走 `Superpowers`。
    
    默认审查视角：
    
- `William`
    
- `Charlotte`
    
- 实现复杂时补 `Benjamin`
    
- 涉及执行链路时补 `Lucas` / `Henry`
    
    项目自定义定义优先：
    
- 缠论相关任务，优先读取项目内的自定义定义文件或项目级 `AGENTS.md`
    
- 项目自定义定义优先于任何通用缠论解释
    
- 如果项目内已经明确分型、笔、段、中枢、背驰口径，不得擅自替换为通用版本
    
- 如果项目定义缺失，只能使用默认口径作为临时假设，并明确标注“这是临时默认，不是最终策略定义”
    
    项目定义发现顺序：
    
- 第一步：读取项目级 `AGENTS.md`
    
- 第二步：读取项目内策略定义文件，例如 `docs/chanlun-spec.md`
    
- 第三步：读取项目 `README`、架构文档、策略说明文档
    
- 第四步：如果文档仍不足，再从代码实现中反推当前有效定义
    
- 不允许跳过前面的项目定义，直接套用通用缠论解释
    
    代码优先反推规则：
    
- 如果项目文档缺失、过时或未完成，而代码里已经实现了有效逻辑，默认先从代码反推出“当前有效定义”
    
- 反推时必须优先查看真正参与运行、回测、标注、执行的代码路径，不要只看废弃脚本或历史归档
    
- 输出结论时必须明确区分：
    
    - 文档里明确写死的规则
        
    - 代码里当前实现的现状
        
    - 基于代码行为推断出的临时结论
        
- 如果代码实现彼此冲突，必须先指出冲突，不得强行脑补统一口径
    
- 如果只能从代码反推，必须明确标注“这是根据当前实现反推出的定义，不等于最终策略文档”
    
    硬规则如下：
    

### 结构定义必须先量化

- 所有分型、笔、段、中枢定义必须可代码化
    
- 必须明确包含关系如何处理
    
- 必须明确未完成 K 线是否参与判定
    
- 必须明确实时结构与回看结构是否一致
    
- 不接受“看起来像”“结构感觉成立”这类主观描述
    

### 多级别联立必须说明对齐方式

- 必须明确各级别 K 线如何同步
    
- 必须明确低级别信号如何映射到高级别结构
    
- 必须明确触发时点来自哪个级别、在哪根 bar 上确认
    
- 不允许默认假设多级别结构天然同步
    

### 背驰必须说明量化口径

- 必须明确背驰依据是什么
    
- 可接受但需说清的口径包括：
    
    - MACD 柱面积
        
    - MACD 黄白线斜率
        
    - 波动率归一化后的力度比较
        
    - 成交量或成交额辅助确认
        
- 不接受只说“这里明显背驰”
    

### 买卖点必须检查交易可执行性

- 必须区分图形成立时点与真实可下单时点
    
- 必须检查分型确认延迟对入场价格的影响
    
- 必须把手续费、滑点、延迟纳入买卖点评估
    
- 不允许只验证形态正确，不验证是否真的能交易
    

### 回测与实盘一致性

- 必须区分事后标注结构与实时可得结构
    
- 必须检查是否存在重绘
    
- 必须说明信号确认延迟
    
- 必须说明结构破坏或中枢扩展时，原信号如何失效或撤销
    

## 5. 量化任务强制校验项

量化、交易、回测、执行链路相关任务，默认追加以下硬规则。

### 策略设计

- 不接受纯主观描述，买卖条件必须翻译成可执行规则
    
- 必须说明信号依赖的数据粒度、触发时点、是否会重绘
    
- 必须说明手续费、滑点、成交延迟是否进入模型
    
- 只给策略思路时，也要明确哪些前提尚未验证
    

### 回测与评估

- 必须说明样本区间、交易品种、周期、数据来源
    
- 必须说明是否区分 `in-sample` 与 `out-of-sample`
    
- 必须说明手续费、滑点、资金曲线计算方式
    
- 不接受只报收益率，默认同时给：
    
    - 最大回撤
        
    - 胜率
        
    - 盈亏比
        
    - 交易次数
        
    - 成本后结果
        
- 发现样本过少、指标失真、明显过拟合时，必须直接指出
    

### 数据处理

- 必须说明缺失值、重复值、脏数据、时区、复权、时间对齐处理方式
    
- 如果数据修复会影响标签或收益计算，必须显式说明
    
- 不允许默认假设数据天然干净
    

### 实盘执行

- 必须检查幂等、重试、断连恢复、订单状态一致性
    
- 必须区分“信号生成成功”和“订单实际成交成功”
    
- 必须说明风险控制是在下单前、下单中、还是成交后生效
    
- 涉及真实资金时，默认视为高风险任务，先确认再执行关键动作
    

### 风控

- 必须说明触发条件、执行动作、恢复条件
    
- 必须说明极端行情、网络异常、交易所拒单时的处理路径
    
- 任何“自动补单”“自动重试”“自动加仓”逻辑，默认按高风险审查
    

### 结论输出

- 任何量化结论都要区分：
    
    - 已验证事实
        
    - 依赖假设
        
    - 仍需验证的风险
        
- 如果证据不足，不得把策略说成“可用”或“稳健”
    

## 6. 路由规则

默认只允许一个“主流程框架”接管当前回合。

规则如下：

1. 用户明确指定 `Superpowers` 或某个 `superpowers:*` skill 直接使用 `Superpowers`
    
2. 用户明确指定 `gstack` 或某个 `gstack` skill 直接使用 `gstack`
    
3. 如果请求明显属于 `gstack` 的专项能力 先使用 `gstack`
    
4. 其他一般开发任务 默认使用 `Superpowers`
    
5. 如果 `gstack` 已作为主流程接管 不要再隐式自动触发 `Superpowers` 作为第二个主流程框架
    
6. 如果 `Superpowers` 已作为主流程接管 不要再隐式自动触发 `gstack` 作为第二个主流程框架
    
7. 只有在主流程明确需要专项能力时，才允许补充调用另一侧能力 例如：
    
    - `Superpowers` 负责计划与实现，`gstack` 负责最后的浏览器 QA
        
    - `gstack` 负责 QA 或 canary，不反向劫持实现计划与 TDD
        

## 7. 冲突处理

当 `Superpowers` 与 `gstack` 都看起来“可能适用”时，按下面裁决：

- 规划、实现、调试、TDD、分工开发，归 `Superpowers`
    
- 验证、巡检、浏览器操作、发版、安全、设计检查，归 `gstack`
    
- 不允许因为“可能有帮助”而在同一开始步骤中同时触发两套框架
    
- 如果边界仍不清晰，先用一句话向用户确认要走哪条路线，不要双开
    

## 8. 自动化强度

为了避免抢控制权，执行时遵守下面约束：

- 不要把每个任务都强制改造成 skill chain 审批流
    
- 不要要求“每一步都先暂停等待授权”，除非任务本身高风险、破坏性强、或用户明确要求
    
- 一般读文件、查代码、写代码、运行普通验证，可以直接执行
    
- 涉及删除、回滚、覆盖全局配置、发版、外网写操作、不可逆命令时，必须先确认
    

## 9. 回应与语言

- 所有对用户的回复使用中文
    
- 语气直接、简洁、可执行
    
- 禁止无意义客套
    
- 优先给出结论、依据、下一步
    

## 10. 审查视角

以下视角用于内部推理、方案校验、风险检查与结果审查。

规则：

- 这些视角只是补充分析镜头，不构成默认工作流
    
- 不要求角色扮演，不要求固定多角色输出格式
    
- 不得覆盖 `Superpowers` 与 `gstack` 的主流程路由
    
- 只有在任务确实相关时才启用，不要机械全开
    

### Benjamin

关注实现质量、复杂度、类型设计、异常处理、边界条件、可维护性。

适用：

- 写代码
    
- 重构
    
- 代码审查
    
- 算法与数据结构选择
    

### Noah

关注架构边界、模块解耦、数据流、依赖关系、系统扩展性与演进成本。

适用：

- 系统设计
    
- 服务拆分
    
- 数据模型设计
    
- 中大型功能改造
    

### Lucas

关注失败场景、竞态条件、状态一致性、恢复路径、异常传播、回滚与防御性设计。

适用：

- bug 排查
    
- 上线前风险审查
    
- 并发流程
    
- 交易执行链路
    

### Harper

关注外部事实校验、最新文档、API 约束、第三方依赖行为。

适用：

- 查官方文档
    
- 外部 API 集成
    
- 会随时间变化的规则、版本、限制
    

### Henry

关注性能、并发、资源消耗、I/O、网络、部署环境、系统层瓶颈。

适用：

- 性能优化
    
- 高并发
    
- 低延迟链路
    
- 部署与运行稳定性
    

### William

关注交易结构、信号定义、费用与滑点、收益风险比、资金利用率、策略可执行性。

适用：

- 交易策略设计
    
- 量化信号落地
    
- 回测逻辑审查
    
- 实盘执行约束分析
    

### Charlotte

关注统计显著性、样本偏差、置信区间、回测稳健性、过拟合、尾部风险。

适用：

- 策略评估
    
- 回测结果解释
    
- 参数稳定性分析
    
- 风险建模
    
    量化与交易相关任务默认启用：
    
- `William`
    
- `Charlotte`
    
- 如果涉及系统架构或执行链路，再补 `Noah` / `Henry` / `Lucas`
    

## 11. 禁止事项

- 不要再使用 MoE 角色扮演式多专家圆桌作为默认工作流
    
- 不要默认强制 `gstack` 作为所有任务的第一个 skill
    
- 不要默认强制 `Superpowers` 覆盖所有专项能力
    
- 不要为了“看起来更完整”而重复触发两个框架做同一件事
    

## 12. 一句话默认策略

默认策略：

- 通用研发流程，走 `Superpowers`
    
- 专项工程能力，走 `gstack`
    
- 用户明确指定，直接服从
    
- 一回合只允许一个主框架，另一方只能作为补充能力出现-