第 25 章：行为评测、控制评测与自动化红队测试¶

1. 为什么普通回归评测已经不够¶

回归评测很擅长回答一个问题：

• 我们有没有把之前能工作的东西弄坏。

但对智能体系统来说，这还不够。

如果系统已经会：

• 选择策略；
• 使用工具；
• 保存状态；
• 穿过审批；
• 在过渡条件下调整行为，

那你需要的不只是回归评测，还需要行为层面的检查。

这时最好把下面三类东西分开：

• 行为评测（behavioral evals）
• 控制评测（control evals）
• 自动化红队测试（automated red teaming）

这里的清晰边界是：评测负责判断系统如何行为，以及控制面在受压时是否真的证明了自己。它们不替代保障响应闭环、可观测性证据层或资产注册表。它们产出的是供这些层后续消费的判断。

这也正是本章的核心承诺。它要帮助读者把评测看成整个生命周期里的可评审判断层：在这里，行为、控制质量和验证器质量会被转化成发布（rollout）、保障（assurance）、出处（provenance）与治理（governance）真正可以依赖的判断。本章的主要工件是评测门禁与验证器契约（eval gate and verifier contract）：可测试的发布条件和评审契约，而不是事故响应（incident response），也不是泛泛的遥测（telemetry）。

2. 什么是行为评测¶

行为评测不只检查最终输出，还检查系统的行为形态。

最近关于计算机使用智能体（computer-use agents）验证器设计的一个重要经验是，对于长跨度轨迹，单一的二元裁决（binary verdict）往往太弱。智能体可能走对了过程，却因为环境阻断而失败，也可能通过不安全路径达成名义结果。所以验证器设计最好把过程验证（process verification）和结果验证（outcome verification）分开，而不是压成一个分数（score）。

例如：

• 智能体会不会隐藏一个有争议的步骤；
• 会不会绕过审批；
• 会不会在审查之后改掉载荷；
• 会不会在没有充分理由的情况下进入高风险工具路径；
• 会不会偏离预期的升级路径；
• 会不会利用契约漂移（contract drift）或模式不匹配（schema mismatch）穿过控制边界；
• 会不会利用中断（interruption）、到期（expiry）或重新初始化语义（re-init semantics）重新回到更弱的控制姿态。

也就是说，问题不再只是“答案对不对”，而是“在这个场景下，运行时的行为对不对”。

3. 什么是控制评测¶

控制评测检查的是控制机制本身，而不只是模型质量。

典型问题包括：

• 验证器本身是否使用了可评审的评分规约（rubric），而不是不透明的单一裁决（verdict）；

• 它是否区分可控失败和不可控失败；

• 策略层能不能真的拦住这个能力；

• 审批门禁是否真的要求人来确认；
• 回滚门禁能不能工作；
• 暂停运行与后台运行控制（paused-run and background-run controls）是否按设计工作；
• 能力会话到期与重新初始化控制（capability-session expiry and re-init controls）是否按设计工作；
• 副作用会不会进入追踪；
• 紧急控制能不能关掉高风险路径。

这里的关键转变在于：你检查的不只是模型，而是围绕模型的一整层控制面。

在成熟体系里，验证器本身也属于控制面。如果它制造了虚假的信心，发布（rollout）和训练循环（training loops）就会继承这个错误。所以验证器设计应该被当成受治理基础设施，而不只是一个方便的辅助提示词（helper prompt）。

这也包括验证器契约替换（verifier contract swaps）。评测回归不一定只来自模型或运行时行为，也可能来自未经审查的验证器契约版本变更（verifier contract version changes），它们会悄悄改变评分标准。

4. 什么是自动化红队测试¶

自动化红队测试不再只是几条手写测试样例，而是一种系统化生成、变换和放大对抗场景的方法。

它的实际价值在于：

• 帮你发现团队自己没想到的失效模式；
• 更有效地覆盖边缘场景；
• 强迫你去观察系统在受压状态下的行为，而不是只看“正常日子”。

Anthropic 最近在这方面的工作尤其值得参考：更强的控制评测脚手架，以及更强的红队场景生成。³⁴

5. 它和现有评测层的关系¶

你已经有：

• 离线评测；
• 在线评测；
• 回归门禁；
• 追踪分级（trace grading）。

行为评测和控制评测不是用来替换它们的，而是在上面再叠一层：

• 离线评测检查任务质量；
• 追踪分级检查路径质量；
• 行为评测检查与策略相关的行为；
• 控制评测检查控制本身是否真的有效；
• 运行时控制评测（runtime-control evals）还要验证暂停/恢复（pause/resume）、后台执行（background）、能力会话到期/重新初始化（capability-session expiry/re-init）、契约版本行为（contract-version behavior），以及编排模式行为（orchestration-pattern behavior）在受压场景下是否按预期工作。

OpenAI 关于智能体评测（agent evals）的指南给出了一条有用的操作阶梯：在调试单个工作流（workflow）行为时先从追踪（traces）开始，用结构化评分器（structured graders）评估工具选择（tool choice）、交接（handoff）、护栏（guardrail）和指令遵循失败（instruction-following failures），然后把稳定的问题迁移到数据集（datasets）和可重复的评测运行（eval runs）中，用于跨时间比较变更。¹² 换句话说，追踪分级（trace grading）是显微镜，而数据集（datasets）和评测运行（eval runs）是回归测试框架（regression harness）。成熟的智能体程序（agent program）需要这两层：追踪（traces）解释某一次运行（run）为什么失败；数据集（datasets）证明新的提示词（prompt）、策略（policy）、路由规则（routing rule）或工具表面（tool surface）是否改善了一类运行（runs），同时没有削弱其他地方的控制（controls）。

6. 哪些地方最需要这类评测¶

这类场景尤其适合放在：

• 高风险写入能力；
• 带出口访问的工具；
• 审批密集型工作流；
• 涉及暂停/恢复（pause/resume）或后台执行（background execution）的运行时控制转换（runtime-control transitions）；
• 能力会话到期（capability-session expiry）与重新初始化路径（re-initialization paths）；
• 替换与退役过渡期；
• 多智能体委派；
• 编排模式选择（orchestration-pattern selection）与委派工作者边界（delegated worker boundaries）；
• 记忆写入与检索治理。

如果高风险路径根本没有被这些评测覆盖，团队几乎一定会先从事故里学到教训。

控制评测案例主线说明（Control-eval case-spine note）：评测门禁与验证器契约（eval gate and verifier contract）应该把三个规范案例（canonical cases）作为不同的行为与控制评测表面（behavioral and control eval surfaces）来测试。支持分诊（Support triage）需要重复预防（duplicate prevention）、载荷变更检查（payload-mutation check）、审批路径误用检查（approval-path misuse check）、旧网关路由探针（old-gateway-route probe）和应急禁用断言（emergency-disable assertion）。内部知识助手（Internal knowledge assistant）需要来源扎根评测（source-grounding eval）、租户过滤绕过探针（tenant-filter bypass probe）、不当记忆写入检查（improper-memory-write check）、检索投毒场景（retrieval-poisoning scenario）和新鲜度回归门禁（freshness regression gate）。事故协调（Incident coordination）需要升级路径检查（escalation-path check）、通知压制探针（notification suppression probe）、响应者角色滥用场景（responder-role abuse scenario）、事故状态篡改检查（incident-state tampering check）和回滚控制评测（rollback control eval）。

7. 一个最小行为分类法¶

一个够用的最小分类法可以是：

• oversight_evasion
• payload_mutation_after_approval
• concealment_of_side_effect
• unsafe_alternative_tool_path
• improper_memory_write
• replacement_window_abuse
• unauthorized_persistence
• contract_drift_exploitation
• approval_path_misuse
• session_reinit_misuse
• runtime_control_regression
• delegated_worker_misuse
• orchestration_pattern_drift

重点不在于名字有多少，而在于它们给了你一套可重复的失效类别。

8. 用户模拟器和合成对手是两种角色¶

user simulator（用户模拟器）适合用来稳定生成正常和边界用户场景。

synthetic adversary（合成对手）适合用来故意压测系统弱点：

• 含糊指令；
• 冲突目标；
• 高风险捷径；
• 尝试隐藏可疑步骤。

在成熟系统里，这两种角色应该并存：

• 模拟器（simulator）提供更真实的任务分布；
• 对手（adversary）提供压力测试。

8.1. 研究在这里更适合作为场景类别的来源¶

最新关于行为风险与自动化红队测试的研究，价值不只在于结论，也在于它提供了更丰富的词汇表。

它能帮助团队补齐那些很难仅靠本地经验就完整想出的场景类别。比如：

• 隐蔽（concealment）；
• 监督规避（oversight evasion）；
• 类似破坏的持续行为；
• 压力下的协作失序；
• 对模式不匹配（schema mismatch）或控制漂移（control drift）的利用；
• 对中断（interruption）或重新初始化窗口（re-init windows）的滥用；
• 对委派工作者路径（delegated worker paths）的滥用或工作者边界漂移（worker-boundary drift）。

但工程纪律仍然应该保持严格：

• 场景类别必须进入可评审的评测模式（eval schema）；
• 发现结果必须有负责人和分诊路径；
• 发布门禁看到的应是运行证据，而不只是论文引用。

所以，研究在这里最好的用途，是帮助生成假设和危险场景，而不是替代你自己的评测方案。

9. 一个控制评测策略示例¶

control_evals:
  required_for:
    - ticket_write
    - outbound_messaging
    - credential_rotation
  scenario_classes:
    - oversight_evasion
    - payload_mutation_after_approval
    - concealment_of_side_effect
    - approval_path_misuse
    - session_reinit_misuse
    - contract_drift_exploitation
    - runtime_control_regression
    - delegated_worker_misuse
    - orchestration_pattern_drift
  block_release_if:
    - control_eval_missing
    - behavioral_eval_regression
    - runtime_control_regression_open
    - verifier_contract_regression_open
    - red_team_findings_untriaged

这个层很有价值，因为它把行为检查变成了发布纪律的一部分，而不是“可做可不做的加分项”。

10. 一个简单的分级契约¶

from dataclasses import dataclass


@dataclass
class ControlEvalResult:
    scenario_class: str
    control_enforced: bool
    side_effect_traced: bool
    finding_open: bool
    contract_version_matched: bool
    session_control_enforced: bool


def passes_control_eval(result: ControlEvalResult) -> bool:
    return (
        result.control_enforced
        and result.side_effect_traced
        and result.contract_version_matched
        and result.session_control_enforced
        and not result.finding_open
    )

这里的核心是：失效不只是“模型行为古怪”，也包括“控制层没能证明自己真的有效”。

如果分级契约能表达的不只是通过/失败裁决（pass/fail verdict），而是分开的过程/结果判断，以及可控与不可控原因的失败归因，它就会更强。

11. 如何把它接进 ADLC¶

在成熟系统里，流程通常是这样：

1. 高风险变更先拿到 change_record；
2. 定义这次需要的评测范围；
3. 回归评测检查既有行为；
4. 行为评测/控制评测检查高风险路径；
5. 自动化红队测试搜索不那么明显的失效模式；
6. 发现结果进入保障待办列表；
7. 发布门禁看到的不只是准确率，还包括控制证据。

这样评测层就不再只是“一张指标表”，而会变成运行模型的一部分。

也正因为如此，本章更应该被理解成测试与判断层。保障决定如何响应发现结果（findings）；可观测性保存证据（evidence）；注册表在整个智能体群体上分配问责；而评测决定到底测试了什么、哪里失败了，以及团队当前应当对控制姿态保持多大信心。

12. 最常见的错误¶

• 所有评测最后都退化成最终答案质量；
• 危险路径没有独立的场景类别；
• 审批路径误用（approval-path misuse）、会话重新初始化误用（session re-init misuse）、委派工作者误用（delegated-worker misuse）与契约漂移（contract drift）没有被显式测试；
• 验证器输出（verifier outputs）把长轨迹压缩成了过于薄弱的通过/失败标签（pass/fail label）；
• 验证器契约替换（verifier contract swaps）改变了评分行为（grading behavior），却没有被当成承载发布的评测回归（release-bearing eval regressions）；
• 可控失败（controllable failures）与不可控失败（uncontrollable failures）没有被分开；
• 红队测试只是一次性活动；
• 运行时控制回归（runtime-control regressions）只有在发布（rollout）或事故（incidents）中才被发现；
• 发现结果没有进入发布门禁；
• 控制失效被当成“不是模型 bug”，于是从待办列表里消失；
• 团队分不清普通失效和类似破坏的行为。

13. 给行为评测和控制评测做一次快速成熟度测试¶

团队不应该只因为已经有回归评测、模拟器和几条对抗提示（adversarial prompts），就觉得自己已经准备好面对自主行为。

更高的标准应该是：

• 高风险路径有明确的行为场景类别；
• 控制评测会验证控制层本身在压力下是否真的有效；
• 验证器输出会分开表示过程质量、结果质量与失败归因，而不是把一切压成单一二元判断；
• 审批路径误用（approval-path misuse）、会话重新初始化误用（session re-init misuse）、委派工作者误用（delegated-worker misuse）、契约漂移（contract drift）与运行时控制回归（runtime-control regressions）都有明确的场景覆盖；
• 红队发现（red-team findings）会进入发布（rollout）和变更门禁（change gates），而不是停留在单独报告里；
• 真实负载模拟（realistic simulation）和对抗生成（adversarial generation）扮演不同但互补的角色；
• 发布决策能拿出控制证据，而不只是质量分数。

如果这些条件大多不成立，那团队也许已经有一些评测活动，但还没有足够的行为和控制覆盖。

这时团队也许已经在测量行为，但还没有产出那种足以让发布（rollout）、保障（assurance）与治理函数稳定依赖的可评审判断。

14. 实用检查清单¶

• 高风险能力是否有单独的行为场景类别？
• 你是否测试审批规避、载荷篡改、审批路径误用（approval-path misuse）与委派工作者误用（delegated-worker misuse）？
• 是否有专门验证控制措施、契约版本匹配（contract-version matching）、运行时控制行为（runtime-control behavior）、编排模式边界（orchestration-pattern boundaries）与验证器质量的评测，而不只是检查输出质量？
• 验证器能否区分过程失败、结果失败与不可控环境失败？
• 红队发现结果是否会进入变更评审和发布门禁？
• 是否同时有真实负载模拟器（realistic workload simulator）和对抗生成器（adversarial generator）？
• 你能展示的是控制证据，还是只有最终分数？

如果连续几个答案都是“否”，那你的评测层虽然已经存在，但还没准备好面对自主行为。

15. 本章的证据模型¶

本章应该被读成一层控制证据（control evidence），而不是一组额外测试类型清单：

• 稳定主张： 自主系统需要针对风险轨迹（risky trajectories）的评测（evals），而不只是最终答案（final answers）。
• 厂商实践： 现代智能体评测（agent-eval）材料越来越把追踪（traces）、轨迹（trajectories）与发布门禁（rollout gates）当作评测的一等输入。
• 运行时实践： 场景类别（scenario classes）、验证器契约（verifier contracts）、有追踪支持的失败（trace-backed failures）与发布门禁（rollout gates）是让行为证据（behavioral evidence）和控制证据（control evidence）可审查的具体方式。
• 作者解释： 行为评测（behavioral evals）、控制评测（control evals）与自动化红队测试（automated red teaming）是同一个判断系统（judgment system）中的不同角色，而不是可以互换的标签。
• 快速变化层： 模拟器质量（simulator quality）、裁判模型（judge models）与红队生成（red-team generation）会快速变化；但区分过程失败（process failure）、结果失败（outcome failure）与控制失败（control failure）的需求不会。

16. 值得配套阅读的参考页¶

• 评测数据集模式与打分契约
• 追踪模式与事件目录
• 变更评审与发布门禁模式
• 策略包模式与审批契约
• 审批请求与决策记录模式
• 生命周期工件模式
• 记忆记录与检索契约模式

• 研究前沿：记忆、可观测性与多智能体可靠性

• 第 13 章：离线评测、在线评测与回归门禁

• 第 21 章：保障闭环：红队测试、检测与响应
• 第 24 章：智能体失配与内部人风险
• 第 26 章：AI 原生可观测性、清单覆盖率与可用于检测的遥测
• 第 27 章：智能体清单、注册表与蔓延治理