首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >智能体和具身智能,为什么被单独做安全评测

智能体和具身智能,为什么被单独做安全评测

原创
作者头像
AI算法大模型备案当当
发布于 2026-10-16 10:02:06
发布于 2026-10-16 10:02:06
320
举报

声明:本文基于公开发布的框架信息、官方会议报道与公开政策文本整理,不含任何产品推广,也不构成法律意见。涉及具体项目的验收标准,请以主管部门发布的框架原文与属地要求为准。

0 先说结论

2026 年 10 月 15 日,在山东济南举办的 2026 人工智能产业大会开幕式上,《工业和信息化领域人工智能安全评测框架(2026 版)》正式发布。该框架在工业和信息化部网络安全管理局的指导支持下,由中国人工智能产业发展联盟会同有关单位研究编制。

框架在"应用安全"这一层,把智能体安全和具身智能安全单独列了出来,并对四个维度设置了评测要求:权限安全、行为安全、记忆安全、工具调用安全。

值得注意的是:这四个维度里,一个"内容"概念都没有。

这不是疏漏,而是这份框架最值得读懂的地方。它说明安全问题的作用对象变了:

  • 大模型时代问的是"它说了什么";
  • 智能体时代问的是"它做了什么、能碰到什么、代表谁行动";
  • 具身智能时代问的是"它的动作会不会造成物理后果"。

一句话概括全文:智能体和具身智能被单列,不是因为它们更危险,而是因为它们风险的作用对象从内容扩展到了行为与物理世界,而现有的内容侧工具箱对这两层基本无效。


1 先看清这一批次发生了什么

把时间线摆出来,能看出这不是一个孤立动作。

时间

事件

落点

2026-06

工业和信息化部、国务院国资委联合印发《关于联合开展 2026 年度人形机器人与具身智能实景实训专项行动的通知》,部署 6 项主要任务

推动规模化落地

2026-06-01

《YD/T 6770—2026 人工智能 关键基础技术 具身智能基准测试方法》实施,工信部批准发布

统一能力评测标尺

同期

《人形机器人 全生命周期管理规范》发布,明确"一机一码",每台设备从出厂到报废拥有唯一、不可更改的专属编号

解决溯源与权责

2026-10-15

《工业和信息化领域人工智能安全评测框架(2026 版)》发布

统一安全评测标尺

这四步的顺序有讲究:先推动落地,再统一能力标尺,同时解决溯源,最后补上安全标尺。

前两步回答的是"这台设备/这个智能体能不能干好活";最后一步回答的是"用起来安不安全"。这是两个不同的问题,此前国内在这两个方面都缺少可对照的统一依据。

配套专项行动的目标数据可以看出监管对落地速度的预期:到 2026 年底,人形机器人等重点产品在一批代表性场景中率先完成应用验证和常态部署,凝练形成百个以上高价值应用场景,带动形成万台级规模落地能力。而 2025 年的基数侧数据显示,国内整机企业数量已超 140 家,发布人形机器人产品超 330 款,出货量约 1.7 万台。


2 根因:风险的落点外移了三层

这是理解整份框架的关键。

层次

风险问题

典型后果

后果可否撤回

内容层

它说了什么

违法不良信息、虚假信息、有害建议

可删、可更正、可下架

行为层

它做了什么、能访问什么、代表谁行动

越权调用接口、误改数据、凭证外泄、流程被绕过

往往已落库、已发出,撤回成本高

物理层

它的动作造成什么物理后果

产线扰动、生产事故、人身伤害、核心工艺数据外泄

基本不可撤回

三层是递进关系:每往上一层,后果的不可逆性就增加一档。

内容层的错误,最坏情况是声誉损失加整改;行为层的错误,可能是一次已经写入生产库的误操作;物理层的错误,是撞了、摔了、伤了人。

框架在"业务安全"维度把工业场景定位为"贯穿研发设计、中试验证、生产制造、营销服务、运营管理全流程",把电信场景定位为覆盖网络规划建设、运营优化、运维、云资源智能调度、云业务安全防御等关键环节——这两个场景的共同点是:环节之间是连续的,任何一环出问题都会向下一环传导。

这也是为什么工业场景不能用通用互联网标准套用。公开的框架解读里给出的理由是明确的:工业环境具备强实时、高可靠、高后果三个特殊属性,通用标准难以直接照搬;在工业环境下,算法幻觉、数据泄露、模型漂移一旦发生,可能直接造成产线扰动、生产事故以及核心工艺数据外泄。


3 为什么旧工具箱管不到行为层

很多人第一反应是:"内容审核做得严一点不就行了?"

不行。不是不够严,是工具与风险不对位。逐个说明。

已有的控制手段

它实际管的事

在行为层的失效点

内容审核 / 敏感词过滤

输入输出的文本、图片内容

管不到"智能体越权调用了一个删除接口"——这句话本身可能完全合规

拒答率指标

模型面对敏感提问时是否拒答

管不到"任务结束后权限没有收回,仍可写库"

生成合成内容标识

生成内容的显式与隐式标注

管不到"凭证被写进长期记忆,并在后续任务里被读出"

语料安全 / 数据来源合规

训练数据的合法性与质量

管不到"第三方插件在运行期窃取数据"

对齐与提示词工程

引导模型行为倾向

管不到"一段文档里的指令改变了智能体的执行目标"

这里有一个认知上的分界线需要说清:内容审核是一层"检查",而智能体需要的是一层"控制"。

检查层判断的是"这段内容能不能通过";控制层决定的是"这个身份能不能读这个数据集、能不能调这个工具、能不能把这个动作继续下去"。

只做检查层的系统,会出现一种很难察觉的失效:把危险的措辞全部拦住了,却放行了一个权限过大的智能体。 攻击者甚至不需要让智能体说出任何明显不当的话,只要能把一个合法请求导向一个不该用的工具或过宽的口令,就能造成实质后果。

框架把"应用安全"的评测维度设为权限安全、行为安全、记忆安全、工具调用安全,四个全部是行为侧概念,正是对这个分界线的确认。


4 为什么是工信部,而不是网信办

这个问题问得好,因为它解释了框架的视角从哪里来。

两个序列管的是不同的事:

序列

管什么

风险落点

典型后果

网信序列

信息服务——内容、舆论、传播

内容层

影响舆论秩序、侵害公民权益

工信序列

产业——工业、电信、制造业

行为层与物理层

影响生产安全、人身安全、业务连续性

一份生成式服务的备案,解决的是"这项服务能不能对外提供";而一个智能体在生产环节做错一件事,解决的是"这条产线还能不能继续运行"。

看框架的三维结构就能看得很清楚:

维度

覆盖内容

定位

通用安全

数据安全、模型安全、基础设施安全

基础共性,解决数据集污染、模型投毒、算力环境漏洞

应用安全

智能体安全、具身智能安全——权限安全、行为安全、记忆安全、工具调用安全

新型应用安全

业务安全

工业场景安全(研发设计→中试验证→生产制造→营销服务→运营管理全流程)、电信场景安全(网络规划建设、运营优化、运维、云资源智能调度、云业务智能运维、云业务安全防御)

重点业务场景安全

"业务安全"这一层的存在,是工信部视角最直接的体现:它把安全要求嵌入到了业务全生命周期,而不是停在技术栈里。


5 应用安全四个评测维度的工程含义

这一节是全文最需要落到工程语言的部分。框架给出了四个维度,具体评测条目细则目前未见公开全文,所以下面讲的是这四个维度对应的工程控制位置,不是框架原文条目。

维度

风险形态

对应的工程控制位置

权限安全

权限给多了、给久了

运行时身份、最小权限、零常驻权限、任务级授权与回收

行为安全

自主规划偏离目标、被诱导改变执行路径

任务作用域约束、计划审核点、不可逆动作前置审批、异常动作中断

记忆安全

长期记忆被写入或读走、跨用户污染

记忆写入白名单、用户级隔离、凭证禁入、留存期限与定期审计

工具调用安全

工具来源不可信、参数伪造、越权操作

工具登记制、默认拒绝、单任务调用上限、参数校验、高风险环节人工审批

有两点值得单独说。

第一,权限安全的难点不在"给多少",在"什么时候收回"。 大量事故不是权限过宽本身造成的,而是任务结束后权限仍在。工程上的对应做法是零常驻权限:按任务申请、按任务回收,而不是给一个可以跨任务复用的长期角色。

第二,工具调用安全的第一原则应该是默认拒绝。 未登记的工具一律不调用,规则没覆盖的情形一律转人工复核,不做默认放行。这与内容审核领域的 fail-closed 是同一个原则,但执行位置从审核服务移到了工具网关。


6 责任链条:为什么还需要"一机一码"

具身智能还有一层特殊性:它的落地是多方协作的产物,而事故发生时责任边界容易模糊。

一台在产线上作业的人形机器人,涉及用户单位(场景提供方)、整机企业、模型算法供应商、零部件供应链企业等多方主体。公开的框架解读里点出的现实问题是:人机交互、算法升级、事故处置过程中,多方主体的责任划分不清,容易出现责任推诿、溯源无据。

配套的《人形机器人 全生命周期管理规范》用"一机一码"回应这个问题:每台人形机器人从出厂到报废的全生命周期中,都必须拥有一个唯一、不可更改的专属编号。

这与软件侧的可审计是同一个思路的两端:

  • 软件侧:智能体的每一次动作有调用日志、权限变更记录、审批记录,做到可审计;
  • 硬件侧:每一台设备有唯一编号,做到可溯源。

两端合起来,才能在一次事故之后回答"是谁的哪一步造成的"。



7 上线前验收清单

建议把验收口径定为四项:可控、可审计、可中断、可追责。以下条目按这四个口径分组,可直接当检查表用。

A 可控(7)

  • [ ] 智能体有独立的运行时身份,不复用个人账号凭据
  • [ ] 权限按任务申请、按任务回收,无常驻权限
  • [ ] 允许与禁止的任务类型已书面声明,超范围请求一律拒绝
  • [ ] 工具按风险分级,不可逆动作前置人工审批
  • [ ] 工具采取登记制,未登记工具一律拒绝(不做默认放行)
  • [ ] 单任务工具调用次数设上限,防失控循环
  • [ ] 高风险动作(支付、账号变更、数据导出)已列入禁止清单

B 可审计(5)

  • [ ] 每次工具调用留有日志,含身份、动作、规则依据、结果
  • [ ] 审批类动作记录审批人与理由
  • [ ] 权限变更单独留痕,可回溯到变更发起人
  • [ ] 日志集中存储,本地不可删除或修改
  • [ ] 日志留存期限已明确,并满足行业与属地要求

C 可中断(4)

  • [ ] 提供一键停止能力,可中断正在进行中的任务链
  • [ ] 异常调用行为有监测,达阈值自动触发中断
  • [ ] 中断后状态可回滚,或至少可定位到中断点
  • [ ] 人工接管路径已演练,不是写在文档里

D 可追责(4)

  • [ ] 每个动作可归属到具体的智能体、任务与责任人
  • [ ] 涉及第三方工具或插件的,来源与版本已登记
  • [ ] 涉及硬件设备的,唯一编号管理已落实
  • [ ] 事故处置流程明确多方主体责任边界

E 记忆与外部内容(4)

  • [ ] 记忆按用户隔离,无跨用户复用
  • [ ] 凭证与原始提示词禁止写入记忆
  • [ ] 外部内容进入上下文前做指令剥离处理
  • [ ] 记忆内容有定期审计机制

8 几个常见误判

  1. 把它当成强制准入。 框架的定位是评测框架、评测方法与实施要求,公开表述明确不设过高准入门槛,支持企业分阶段完成安全能力建设。它是统一标尺,不是许可条件。
  2. 以为内容审核做得严就够了。 内容审核是检查层,解决的是"说了什么";智能体需要的是控制层,解决的是"能做什么"。
  3. 以为智能体只是"更聪明的问答"。 判断分界是能不能产生副作用。一旦接入工具,能查库、能改动、能发消息,就进入行为侧。
  4. 以为把提示词写好就能约束行为。 系统提示词可以引导,但不是可靠的安全边界。权限校验、资源归属检查、高风险审批应当放在确定性代码或下游系统里执行。
  5. 只关注模型本身,不关注运行时身份。 智能体的危险能力常常是间接的:一条看起来正常的回答,可能触发一次写入、一次审批、一次敏感记录读取。
  6. 忽略记忆这一层。 记忆同时是数据和指令载体,写入不加约束、隔离不到位,就会成为污染与注入的通道。
  7. 把"能力基准测试"当成"安全评测"。 具身智能的基准测试方法解决的是能力可比可测;安全评测框架解决的是风险可控可查。两者互补,不能互相替代。
  8. 验收只看上线那一刻。 智能体的行为不是生成时固定的,它会随上下文、工具集、权限变化而变化。验收口径要能覆盖运行期。

9 结语

把这篇收敛成一句话:智能体和具身智能被单独评测,是因为它们把 AI 的安全问题从"说了什么"推到了"做了什么",再从"做了什么"推到了"会造成什么物理后果"。而内容侧的工具箱对后两层基本无效。

对企业来说,这份框架带来的最直接变化不是新增了一道审批,而是验收口径变了:

  • 以前验收一个 AI 产品,看的是内容安全、拒答率、标识合规;
  • 现在验收一个智能体,要能回答:它有哪些权限、什么时候收回、能调哪些工具、记忆里放了什么、出事之后能不能定位到具体动作。

如果你只从这篇里拿走一件事,就拿走这个:现在去把你的智能体能调用的工具列一张清单,逐个标上风险和是否需要人工审批。 这份清单不长,但它是所有后续控制的基础——没有它,权限、审计、中断都无从谈起。


附一 主要依据

  • 《工业和信息化领域人工智能安全评测框架(2026 版)》(2026-10-15 于 2026 人工智能产业大会开幕式发布,工业和信息化部网络安全管理局指导支持,中国人工智能产业发展联盟会同有关单位研究编制)
  • 《关于联合开展 2026 年度人形机器人与具身智能实景实训专项行动的通知》(工业和信息化部、国务院国资委,2026-06)
  • 《YD/T 6770—2026 人工智能 关键基础技术 具身智能基准测试方法》(2026-06-01 实施)
  • 《人形机器人 全生命周期管理规范》("一机一码"全生命周期管理要求)
  • 2026 人工智能产业大会公开发布内容与官方媒体报道

附二 三件可以立刻做的事

  1. 列工具清单。 把智能体当前可调用的接口、插件、外部服务全部列出,逐个标注风险等级与是否需要人工审批。
  2. 核权限回收。 检查现有权限是任务级还是常驻;常驻的,规划改为按任务申请与回收。
  3. 查记忆写入。 确认记忆是否按用户隔离、是否禁止写入凭证、外部检索结果是否只读。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 0 先说结论
  • 1 先看清这一批次发生了什么
  • 2 根因:风险的落点外移了三层
  • 3 为什么旧工具箱管不到行为层
  • 4 为什么是工信部,而不是网信办
  • 5 应用安全四个评测维度的工程含义
  • 6 责任链条:为什么还需要"一机一码"
  • 7 上线前验收清单
  • 8 几个常见误判
  • 9 结语
  • 附一 主要依据
  • 附二 三件可以立刻做的事
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档