synexasMATRIX
预约演示
行业分析

先把测试固定下来。
再判断控制是否有效。

新增控制应接受发现原问题的那套评估,而不是换一套更容易通过的测试。Microsoft 的 run-assert-eval 示例提供了有用的方法:保留测试,审查执行机制,分别检查禁止行为和正常任务。但两次统计的适用会话数不同,也仍有失败,因此不能仅凭更好看的汇总结果决定验收。

生成的编辑配图:日光照亮的桌面上放着没有可读文字、带有横线的空白草稿纸、单独合上的深色证据册和一把放大镜。
生成的编辑配图:空白草稿纸、单独的证据册与放大镜,用来表达拟定要求和核查证据之间的区别。这不是真实测试、审计、客户记录或安全证据。
一览

分数变好之前,
先让比较可追溯。

评估范围

明确一种禁止行为,以及必须继续完成的正常任务。评估预定控制变更时,保持行为定义、测试用例和评判方法不变。这是在保留同一项测试,并不等于证明了所有安全属性。

可比证据

把风险探索与效果比较分开。新发现的风险可以补充下一轮评估,但在评估控制时悄悄替换用例,就改变了原来的问题。新增覆盖应单独标识,不应混入看似一致的前后对比。

审查责任归属

生成的策略仍然只是草案。依赖复测结果前,需要由人审查决策规则、执行边界及其与智能体的连接方式。规则看起来合理,不代表预定执行路径确实使用了它。

验收决定

除了汇总分数,还应索取逐例结果、适用性判定和未解决的失败。分别记录禁止行为违规和正常任务未完成的情况,再由明确的负责人作出验收决定。

核查要点

从一个失败出发,
明确测试究竟在问什么。

在 Microsoft 展示的完整示例中,重要的材料不只是生成的策略,还有随策略一起进入下一轮运行的那套评估。Microsoft 于 2026 年 9 月 24 日推出 run-assert-eval,将其描述为连接风险发现、可衡量的行为要求、运行时控制与复测的工作流程。其 Command Line 文章称,行为定义、测试用例和评判方法保持不变,策略则是预定的干预变化。对企业评审人员而言,这对应一个具体问题:团队能否指出复用的究竟是哪一套评估,并解释它周围有哪些变化?换上一批更容易的用例,可能得到更好的结果,却没有回答原来的失败是否得到处理。因此,保留测试是解释干预结果的前提,不是证明因果关系的捷径。

当风险发现与验收处于同一流程时,这一区分尤其重要。风险发现问的是还可能出现什么问题;干预评估问的是,在完成经审查的变更后,智能体面对既定要求会如何表现。两者都有价值,但提供的证据不同。我们建议的验收做法是,将原始评估保留为可识别的记录,另行加入新发现的测试覆盖。禁止行为的定义应足够具体,让一次失败能够支持有针对性的决策。同时还要写明哪些获得授权的正常任务应继续成功完成。否则,一个只是拒绝更多请求的控制,也可能显得有效,却让智能体更难使用。Microsoft 明确区分了这两类结果;不应把任何一类藏进一个好看的综合分数。

核查要点

固定评估,
逐例核对统计范围。

Microsoft 表示,加入控制后的运行复用了基线评估中缓存的材料。但文章重点展示的基线与控制后汇总结果,使用了不同数量的适用会话。解释这些汇总结果前,需要逐例核对。固定的测试集与纳入某项统计的适用子集并不是同一个概念:保留了用例,不代表已经解释哪些会话符合每项指标的统计条件。应追问每次运行有哪些用例适用、分类为什么发生变化,以及每个结果如何对应到具体用例。不能把重点展示的数字当成分母相同的配对比较,也不应据此绘制数值型前后对比图。使用同一评判者有助于保留评判方法,但不会使其永不出错,也不能消除适用性差异。有用的比较应从可追溯的用例开始,而不是假定两个总数代表同一批对象。

对话数,不是失败次数

智能体的原始运行

40段对话被判定与 Microsoft 的客户数据披露检查相关,并纳入计数。

采用所提议控制措施的运行

在采用所提议控制措施的运行中,34段对话被判定与这项检查相关,并纳入计数。

这些数字在数什么
统计的是被判定与这项特定检查相关的对话,不是数据披露次数、成功完成的任务数或安全评分。
这些总数不能说明什么
两个总数不同。本文尚未确认两次运行纳入的用例中,哪些能够一一对应。
接下来要核查什么
在得出安全性结论前,先核查纳入了哪些用例、为何被视为相关,以及仍存在哪些失败。
这些数字来自 Microsoft 的具体示例,并非我们开展的测试。这两个总数既不能证明比较的是一一对应的用例,也不能证明安全性有所提升。
核查要点

生成提供草案,
执行机制仍须由人审查。

来源明确指出,生成不等于自动批准:在加入控制后的运行开始前,必须审查策略、执行说明、干预位置以及与目标智能体的连接。这是实质性的责任交接,而不是补办手续。评审人员需要理解执行的是什么决策、它在哪里生效,以及被评估的智能体是否确实经过这一边界。执行约定不清楚,重复测试也无法弥补。我们建议在审查记录中区分自动生成的材料与人已接受用于评估的版本,明确预定控制变更,并披露其他可能影响解释的变化。如果必须调整用例或评判标准,应保留为新的评估版本,而不是继续悄悄称其为原来的比较。目标是留下可检查的决策链条,而不是宣称自动化已经批准了自己的产出。

核查要点

保留失败,
把验收决定写清楚。

Microsoft 的示例在应用控制后,仍然存在禁止行为违规。这些残留失败应进入决策记录,不能被“问题已经解决”的笼统结论掩盖。公布的样本中,控制后结果也没有观察到正常任务违规;但这并不能证明正常工作在所有场景下都不受影响。接受控制前,应追问:这些证据对应哪项要求,哪些用例仍未解决,下一步由谁负责?测试覆盖了哪些正常任务预期,还有哪些相关工作不在样本中?评审人员能否检查适用性判定,并区分一次拒绝与一次成功完成的授权任务?负责人应写明,是接受已评估的范围、缩小范围,还是要求继续处理,并记录理由。这些是我们提出的验收问题,不是来自我们亲自测试的部署结论。配套流程图用于组织这些检查,并不表示已经测得成功。

从明确要求到有人负责的验收决定

  1. 明确行为预期
  2. 固定评估
  3. 审查执行机制
  4. 逐例追溯比较
  5. 保留失败并决策

明确一种禁止行为,以及应继续成功完成的授权任务。

保持行为定义、用例和评判方法不变;后续新增内容单独标识。

依赖复测前,由人审查生成的策略、执行边界及其与智能体的连接。

使用保留的测试评估预定控制变更;解释汇总结果前,逐例核对适用性。

分别记录禁止行为违规和正常任务失败,保留未解决用例,并明确决策负责人。

依据 Microsoft 评估流程整理的建议检查步骤。这不是测量结果;仍须逐例核对适用性,并保留尚未解决的失败。
来源

两篇 Microsoft 文章,
一组边界明确的证据。

Command Line 文章提供了方法和由供应商报告的完整示例。9 月 24 日的 Azure 公告说明 run-assert-eval 在 Microsoft 更广泛智能体治理流程中的位置,但不是独立佐证。我们没有运行该产品,也没有测试真实部署。本文分析的是供应商报告的评估证据,并提出验收问题;它不是普遍安全性的证明,不是在报告真实事件,也不构成部署批准。

让 AI 真正帮上忙,
从您的实际工作开始。

请描述团队反复处理的任务,不要提供机密文件。我们会演示 Matrix 如何处理相似工作。

预约演示
下载

安全说明

请提供收件信息。