有界共同研讨：怎样复核一份 AI 红队测试记录

作者：ming（ming8m） · 更新：2026-10-02

项目规范入口：ming8m/agent-hub。本文依据 55809f1 的共同研讨实现，给出评阅方法；示例不是已交付项目或模型实测结果。

红队记录常同时包含输入、模型输出和测试者的解释。复核的第一步是让分析者分清这三类信息：输入出现了什么、输出实际做了什么、测试者由此推断了什么。OWASP 将外部网页或文件中的指令影响模型行为列入间接提示注入；具体影响仍取决于应用能力与业务情境。OWASP LLM01

Agent Hub 的共同研讨需要一位独立主持和两至三位已注册分析者。分析者先分别回答，主持比较意见；出现可处理的分歧时，相关分析者最多进行一轮定向复核，主持随后给出结论。它适合限定问题、保留不同意见，而不是无限增加讨论轮数。有界研讨源码

把一次评阅压缩成四步

1. 准备同一份脱敏资料：任务要求、控制输入、待测输入、完整输出、时间和平台。删除“肯定成功”这样的预设结论，另列测试者的初步判断。
2. 配置主持与分析者，选择共同研讨。两位分析者至少预留六个调用和任务槽，三位至少八个；这些槽位覆盖可能发生的复核阶段，不代表每次都用完。
3. 提交一个限定任务：“仅依据所给记录判断是否偏离摘要要求；指出证据位置、替代解释和未知项。”首轮可分别关注任务行为和证据完整性。
4. 查看原始响应、分歧与最终结论。对仍缺输入或执行日志的事项保留“待验证”，随后安排人工复现。

这张表是判定示例，没有任何一行被当作真实测试结果。尤其不能只搜索标记词：模型可能在拒绝或分析时引用标记，出现同一个词并不自动意味着遵从了资料中的指令。

实现最多接受三个分歧，每项分歧需要引用不同分析者的成功响应 ID。最终决策引用相关响应，并允许保留未解决事项。失败或超时的分析者应视为覆盖缺口，不能计为赞成票。普通分析的 evidence 字段是文本数组；检查响应 ID 的合法性也无法证明文本中的事实真实。

如果两人对同一句输出理解不同，定向复核应只追问那句话与任务要求之间的关系。新增资料则应明确版本，避免主持把不同输入上的结论混在一起。对于泄露、越权或外部执行，另行核对实际系统记录。共同研讨形成的是有出处的评阅意见，本文不把主持结论写成漏洞已验证，也未报告成功率或效率提升。