agent-red-team

name	agent-red-team
description	使用双 Agent 左右互搏防止“目标坍缩/自圆其说”。当用户提到让另一个 Agent 挑刺、红队测试、反例驱动、边界场景攻击、验证测试是否有意义时触发。

Agent Red Team

将任务拆为两个互相制衡的角色，并保持“需求契约不可被实现方改写”。

角色定义

• Agent A (Builder): 实现业务代码与修复缺陷。
• Agent B (Challenger): 只负责找反例、写破坏性测试、构造极端输入。
• User (Director): 持有最终业务规则与验收口径。

执行流程

1. 冻结契约

• 先把业务规则写成不可变输入（Gherkin/.feature、接口契约、示例数据结构）。
• 明确规则: Agent A 不得修改契约；只能改实现代码。

2. 先由 Challenger 出题

• 要求 Agent B 先产出至少 3 类“高破坏性”场景：
• 边界值（空值、最小/最大、越界）
• 时序问题（重复点击、并发、重试、延迟）
• 异常路径（网络失败、部分成功、脏数据）

3. Builder 再实现

• Agent A 仅根据已冻结契约和挑战用例实现。
• 若失败，优先修实现；禁止“改测试迎合代码”。

4. 对抗复盘

• 让 Agent B 审查通过用例是否“真能抓错”，指出“为了绿而绿”的测试。
• 要求补充至少 1 个此前遗漏的反例。

5. 变异检验（可选但推荐）

• 在关键判断上注入最小 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. [修复点]

### 变异检验
- 注入变异: [是/否，内容]
- 测试是否捕获: [是/否]

### 结论
- 当前是否达到“非自证”测试标准: [是/否]
- 剩余风险: [列表]