catoncat Agent Red Team
将任务拆为两个互相制衡的角色，并保持“需求契约不可被实现方改写”。
角色定义
Agent A (Builder): 实现业务代码与修复缺陷。Agent B (Challenger): 只负责找反例、写破坏性测试、构造极端输入。User (Director): 持有最终业务规则与验收口径。
执行流程
- 冻结契约
- 先把业务规则写成不可变输入（
Gherkin/.feature、接口契约、示例数据结构）。 - 明确规则:
Agent A不得修改契约；只能改实现代码。
- 先由 Challenger 出题
- 要求
Agent B先产出至少 3 类“高破坏性”场景： - 边界值（空值、最小/最大、越界）
- 时序问题（重复点击、并发、重试、延迟）
- 异常路径（网络失败、部分成功、脏数据）
- Builder 再实现
Agent A仅根据已冻结契约和挑战用例实现。- 若失败，优先修实现；禁止“改测试迎合代码”。
- 对抗复盘
- 让
Agent B审查通过用例是否“真能抓错”，指出“为了绿而绿”的测试。 - 要求补充至少 1 个此前遗漏的反例。
- 变异检验（可选但推荐）
- 在关键判断上注入最小 bug（如
>改>=、&&改||）。 - 若现有测试不失败，则判定测试过松，回到步骤 2 重写挑战用例。
Prompt 模板
给 Builder
你是 Agent A（开发者）。
约束：不得修改 .feature/契约/测试数据结构。
任务：只修改业务实现，让当前失败用例通过。
输出：改动文件、原因、仍未覆盖的风险。
给 Challenger
你是 Agent B（挑刺者/红队 QA）。
目标：证明 Agent A 的实现不可靠。
请基于既定业务规则，先给出 3-5 个最可能击穿实现的边界场景，
并写成可执行测试；重点覆盖空数据、网络抖动、重复操作、异常恢复。
禁止为迎合当前实现而放宽断言。
给双 Agent 的裁决规则
1) 需求契约不可变（除非用户明确批准）。
2) 测试失败时优先修实现，不优先改断言。
3) 每次通过后必须新增一个反例测试。
4) 关键路径至少做一次变异检验。
输出格式
## Red Team 回合结果
### 冻结契约
- [规则1]
- [规则2]
### Challenger 新增攻击场景
1. [场景 + 预期]
2. [场景 + 预期]
3. [场景 + 预期]
### Builder 修复摘要
1. [改动文件]
2. [修复点]
### 变异检验
- 注入变异: [是/否，内容]
- 测试是否捕获: [是/否]
### 结论
- 当前是否达到“非自证”测试标准: [是/否]
- 剩余风险: [列表]