腾讯 IEG 的多 Agent 测试框架，把决策权按两个维度分掉了

一句话定位：这不是"怎么让 Agent 自动把测试跑完"，而是"测试结论里哪一部分可以不由人签字"——被测对象是决策权的分配规则，不是 Agent 的准确率。同样的判定可迁移到发布审批、退款审批、权限变更、库存超卖处置、客服工单升级。

摘要

在 2026 腾讯全球数字生态大会上，腾讯 IEG 的多 Agent 测试框架被一句话带过：按错判风险和可逆性分配决策权，高危指令和未知异常交给人。这句话短，**但它给出了一个测试行业争了很久的问题的可操作答案——什么时候该让人签字。**这篇把这两个维度展开成四档判定，给出每一档的断言写法、证据要求，以及最容易做错的两件事：把"未知"当成"低风险"，以及把"可逆"当成"随便测"。原文未给出任何效果数字，本文也不编。

“AI 能不能自己做发布决策”，这个问题在过去一年被问了很多遍，答案通常落在两个极端：要么"必须人签字"，要么"已经端到端全自动"。

2026 年 11 月 5 日那场腾讯全球数字生态大会的报道里，有一句话给出了第三种答案，而且短得几乎被忽略：腾讯 IEG 的多 Agent 测试框架，按错判风险和可逆性分配决策权，高危指令和未知异常交给人。

我要说明材料属性：这是一句媒体转述的发布内容，出自署名"机器之心官方账号"的报道，不是腾讯官方的技术博客，原文没有展开机制细节，也没有给出任何效果数字。下面写的方法，是我按这两个维度在测试实践里能落地的方式整理的，不是对腾讯内部方法的还原。

我之所以觉得这句话值得单独写一篇，是因为它把"要不要人签字"从一个态度问题变成了一个分类问题。

两个维度不是一回事，混在一起就会失效

多数团队判断"这步要不要人确认"，用的是感觉：重要就找人，不重要就放过。感觉的毛病是不稳定，换个人答案就变。

原文给的两个维度，恰好把感觉拆成了两个可以分别判断的问题。

第一个，错判风险：这一步判错了，代价有多大。注意是"判错"的代价，不是"做错"的代价——测试 Agent 判错有两种，把好的判成坏的（误杀），把坏的判成好的（漏放）。这两种的代价经常不对称。

第二个，可逆性：判错之后，能不能撤回。能一键回滚的发布和已经发出去的退款，可逆性完全不同。

这两个维度交叉，会得到四种情况，而它们的处置方式应该完全不同。

• 高危、不可逆：必须人签字，而且签字前要看到证据
• 高危、可逆：可以自动执行，但必须留回滚开关和限流
• 低危、不可逆：不需要人事前签字，但必须事后可追
• 低危、可逆：全自动，连记录都可以稀疏

下面这张矩阵就是这个四档判定。请特别注意右上和左下两个格子，它们是最容易被合并处理的。

"未知异常"为什么值得单独拎出来

原文那两个词里，我认为"未知异常"比"高危指令"更值得琢磨。

高危指令是可以枚举的：删除数据、发起退款、改权限、发布上线。你列一张表，把它标成高危，规则就写完了。

未知异常不能枚举。它的定义恰恰是"没见过"。而人类在这个位置有一个天然优势：**不知道自己不知道的时候，会停下来。**模型不太会，它倾向于给出一个看起来合理的处置。

所以"未知异常交给人"这句话真正的工程含义是：系统里必须存在一个"我不认识这个"的状态，而且这个状态能被触发。 没有这个状态，所有异常都会被迫归入已知类别，然后按已知类别的规则处理掉。

这条要求可以直接写成一条测试用例：给测试 Agent 一条明显不属于任何已知类别的失败现象（比如日志里出现了一个从未见过的错误码，且堆栈指向一个刚上线的模块），断言它不给出判定，而是升级。

如果它给出了判定，哪怕判定"看起来是对的"，这条用例也应该算失败。因为它证明系统缺少"未知"这个状态——而一个在未知情况下仍会下结论的测试 Agent，比一个明确说"我不知道"的 Agent 危险得多。

下面这张图把这条逻辑画成漏斗：进来的异常逐层分类，最后一层必须有一支流向"人"，而不是全部被回收进已知桶。

可逆性这一维，测试上要比产品定义更严

可逆性看起来是产品属性，实际上是一个需要验证的假设。

产品说"这次发布可以回滚"，这只是一句声明。回滚能不能在 5 分钟内完成、回滚后数据状态是否一致、回滚会不会丢掉这期间的合法写入，都是要测的。

所以可逆性这一维，正确的用法不是"产品声称可逆就当它可逆"，而是先测出它的实际可逆性，再决定决策权。

具体怎么测：对每一个被标注为"可逆"的动作，做一次真实的回滚演练，记录三件事——回滚耗时、回滚后的数据一致性检查结果、以及回滚期间发生的合法写入有没有被覆盖。

三件事里任何一件不达标，这个动作就该从"可逆"档移到"不可逆"档，决策权也随之收紧。这是一个很实用的联动：你测出来的可逆性，直接决定 Agent 有没有权限自己干。

两个高频错误：把未知当低危，把可逆当随便测

第一，把"未知"当成"低风险"。

默认行为是：规则匹配不上，就按最低风险处理，放行。这个默认选择在功能测试里问题不大，在 Agent 测试里很危险——因为 Agent 的失败模式本身就是长尾的，没匹配上往往意味着"这是新情况"，而不是"这是小事"。

正确的默认是反过来：**没匹配上，按最高干预等级处理。**代价是升级变多，收益是新的失败模式不会被悄悄放过。

第二，把"可逆"当成"随便测"。

可逆的动作确实可以放宽事前审批，但不能放宽事后证据。原文在别处提到的一层意思可以借过来：风险发现、分析和处置要跟上业务运行的速度。翻成测试语言：可逆动作的验收重心从"事前批准"挪到"事后可追"——每一次自动执行都要能回答"谁在什么时候基于什么判定做的"。

这两条都不需要模型能力做前提，只要改默认值和留痕字段，成本很低。

这套判定怎么落成一张表

前面三节讲的是判断逻辑，落地需要一张每个动作一行、每行四列的对照表。我把四列写出来，你照着填就能用。

第一列是动作名，要具体到可执行，比如"回滚上一次发布"而不是"发布管理"。

第二列是错判代价，分两类填：误杀会怎样（好版本被拦下，损失是什么）、漏放会怎样（坏版本被放出去，损失是什么）。两类分开填，因为它们的量级经常差好几倍。

第三列是可逆性实测结果，填前面演练得到的三项：耗时、一致性、写入覆盖。

第四列是决策权，四档之一，并写明证据要求。

这张表的用处不在于填完之后照着执行，在于填的过程中会暴露一批"团队里没人真的验过它可不可逆"的动作。我在自己的项目里第一次填的时候，有三分之一的"可逆"其实是"理论上可逆，没练过"。

一句话收尾

原文那句话只有二十来个字，但它给出的方向是清楚的：测试 Agent 的权限，不该由一个统一的自动化率决定，而该由每个动作自己的风险与可逆性决定。

这个思路对测试团队还有一层额外价值。它意味着"AI 测试覆盖率"这个指标本身是有问题的——覆盖率只在权限边界内才有意义。一个 90% 自动判定的系统，如果那 10% 是全部高危动作，它的实际风险可能比 50% 的系统更低。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。