orchestrating-adversarial-reviews

<!-- safety-scan: ignore RM_RF_ROOT,CURL_PIPE_SH,PROMPT_INJECTION 本 skill 把危险命令(| tail 吞退出码、docker rm 误删、agent 谎报)列为反模式教学，自身不执行 --> <!-- safety-scan: ignore TOOLS_PRIVILEGED 知识型 skill，仅 Read；文中 Workflow / docker / go / git 命令由 agent 自有工具执行，非本 skill 落盘运行 --> # 对抗验证编排 · orchestrating-adversarial-reviews > 单个 agent 会谎报"已修复 / 全覆盖 / 没问题"。结论的可信度不来自"谁说的"，来自"扛过几次推翻"。 > 本 skill 是**编排骨架**：fan-out 发现 → 三棱镜对抗验证 → 证明性 guard → 守卫式上线。 > 信级：运行时行为 / 证明测试 > 多 agent 多数裁决 > 单 agent 自报（永远 `[unverified]`）。 ## 核心信条 1. **不信单 agent 自报。** finder 会噪音误报，implementer 会谎称"已修复/全覆盖"。每个高价值结论必须被独立 agent 用**不同视角**尝试推翻。 2. **可证伪 > 可声称。** 修复必须配一个"退回漏洞代码就 FAIL、修好才 PASS"的 **load-bearing 证明测试**。没有证明测试的"已修复"等于没修。 3. **失败方向要对。** 守卫链里任何一步的退出码都不能被管道遮住；破坏性动作前置可逆检查。 ## 何时使用 | 场景 | 用 | 理由 | |------|----|------| | 授权安全审计 / 加固闭环 | ✅ | 首个范例，见 [workflow](references/workflow.md) | | 大面积代码审查（多维度、需高可信） | ✅ | dimensions → find → 对抗验证 | | 研究综合 / 事实核查（结论要扛得住） | ✅ | 多源 fan-out + 证伪棱镜 | | 大规模迁移 / 重构（site 发现 + 逐项验证） | ✅ | pipeline 逐项独立 + 证明测试 | ## 何时不使用 - ❌ 单文件、低风险、机械改动——直接做完跑测试，别套编排（参见 `shipping-changes` 的"何时不使用"）。 - ❌ 用户没有 opt-in 多-agent 编排 / 没开 ultracode——Workflow 会 fan-out 几十个 agent 烧大量 token，必须显式授权。 - ❌ 只需要"找什么洞"的知识——那是 `securing-systems` / `analyzing-security`，本 skill 不重写知识，只编排。 ## 编排骨架（三相） ``` Recon (fan-out) 每维一个 finder, 并行深读, schema 出结构化 findings | pipeline 而非 barrier: 维度A的发现可在维度B还在找时就进验证 v Verify (三棱镜) 每条 finding 派 N 个 verifier, 各执一镜, 默认怀疑 | 可利用性 / 正确性 / 证伪猎杀 —— 票数 >= 多...