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

## 摘要

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




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

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/d8ea66ff2fa48e290d71b7c2f5662bcd.png)

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

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

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

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

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

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

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

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

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

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

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


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/9ca049623e3365db66062dfba212eff6.png)


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

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

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

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

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

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

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

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


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/b5aea160fa55e8743fb012fb05d91dfb.png)


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

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

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

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

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

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

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

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

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

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

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

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

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

### 这套判定怎么落成一张表

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

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

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

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

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

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

### 一句话收尾

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

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

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


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

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

测试

人工智能

架构设计

摘要：本文提出按错判风险与可逆性双维度划分Agent决策权限，细分为四档判定：高危不可逆须人工签字、高危可逆留回滚开关、低危不可逆事后可追、低危可逆全自动。重点强调未知异常必须升级人工，可逆性需实测验证，并警惕两个常见误判：将未知当低危、将可逆当随便测。

数据一致性

软件测试

客服工单

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

腾讯 IEG 的多 Agent 测试框架，把决策权按两个维度分掉了-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐