← 交付方法总览
质量体系可泛化原则
红队与安全 Eval（Red-Team & Safety Eval）
质量
常规 Eval 测的是正常使用下的表现，红队测的是被有意诱导后的最坏行为。两者覆盖的风险完全不同，前者全绿不代表后者安全。
什么时候需要它
- 系统即将面向外部用户开放
- Agent 拥有会产生副作用的工具或能访问敏感数据
核心内容
它决定什么
公开的是判断与判据。客户口径、私有阈值和内部示例不在其中。
越权与信息泄露
试图让 Agent 说出它不该访问的数据、透露系统提示词、或以更高权限执行操作。判据是它是否稳定拒绝，而不是是否偶尔拒绝。
提示注入
把指令藏在被检索的文档、用户上传的内容或工具返回值里。这类攻击不需要用户直接输入恶意内容，因此最容易被忽略。
有害与违规内容
在国内运营的系统还要覆盖内容合规要求。这一层通常需要独立的审核链路，不能只靠模型自觉。
诱导编造
用不存在的前提提问，看它是纠正前提还是顺着编。这是有据性在对抗条件下的检验。
副作用操作的确认
对会产生真实影响的动作，测试它是否在没有明确确认的情况下被诱导执行。保持人工确认可以是正确的终态。
红队用例要固化成回归
一次红队发现的问题如果不进回归集，下次改动就可能悄悄退回去。安全用例的回归价值高于普通用例。
怎么判断它真的到位
- 存在一组安全用例，覆盖越权、注入、编造和副作用四类
- 安全用例进了发布前必跑的集合，不是一次性演练
- 对高风险动作的人工确认路径有测试覆盖
常见误区
- 只测直接的恶意提问，忽略藏在检索内容里的注入
- 红队做过一次就归档，后续改动无人重测
- 把内容合规完全交给模型判断，没有独立审核链路
这套方法怎么落到你的项目
这是我们交付生产级 AI Agent 的公开、脱敏方法骨架。真正落地时，从 AI Agent 生产就绪审查与路线图 入手，或先用 生产上线前深检 定位薄弱环节。