ARTICLE · 1330861

你的 App 该不该让 Agent 调用?智能体终端新规

发布时间：2026-11-08 16:06:34 最近访问：2026-11-08 16:06:34

《工业和信息化部办公厅关于加强智能体终端设备进网管理的通知》，文号工信厅信管〔2026〕42 号，落款 2026 年 10 月 24 日；全文由中国工信新闻网、中宏网于 11 月 6 日刊载，工信部官网政策解读与央广网解读在 11 月 7 日发布（工信部官网政策解读页、中国工信新闻网 2026-11-06、央广网 2026-11-07）。学姐的解读：这是「10 月底成文、11 月初集中公开」，不是 11/6 新发的文；排期请以落款与官方解读页为准，别把披露日当生效日。

最容易被跳过的是通知第四部分那句：「应用分发平台应推动应用程序开发者，通过电子签名主动声明是否同意智能体调用，未经声明同意的，智能体不得强制调用调取应用。」（同前通知全文）

多数解读盯着「AI 手机有准生证」，但对做产品的人这句分量更重：「我的 App 能不能被 Agent 调用」不再是技术事实，而是一个需要签字、默认不同意的授权字段。今天讲你要交付什么、怎么建这套能力、哪些坑别踩。

一、从「能不能调」到「有没有权调」

场景：用户让手机智能体「查账单顺手设个超额提醒」，智能体要拉起运营商 App、读账单、写日历。过去讨论的是有没有深链、页面改版会不会挂、风控会不会判成自动化流量——全是能不能。

这份通知把问题换成有没有权：调用前得有一份由应用开发者主动作出、带电子签名的声明；没有声明，智能体不得强制调用调取应用。政策解读也把「约束智能体强制调用、不兼容安装等行为，落实知情权、选择权」写进了积极作用（工信部官网政策解读，2026-11-07）。

顺本系列脉络看更清楚：10-18 B 讲《你的 Agent 会被挡在门外》，被调用方靠 robots 与风控被动设墙；11-06 B 讲动作取证层，把拦截与回放拆两层。今天监管把那道墙从「被调用方自己搭」改成「由被调用方主动签字、调用方必须遵守」——举证责任换了位置。

学姐的解读：默认值从 opt-out 反转成 opt-in，直接后果是「同意」不再是一次勾选，而是要版本化、可撤回、可审计的对象。你若只加个布尔字段 allow_agent_call，半年后一定返工，原因见第三节。

二、先分清你是谁：四类主体，四套交付物

很多人第一反应是「手机厂商的事」，其实不是。按通知四部分任务逐条对齐（均为工信厅信管〔2026〕42 号原文）：

主体	核心义务	交出什么	触发时点
智能体开发者	与终端适配验证，管好权限调用、通信能力、网络与数据安全、用户权益、任务执行；设置页公示适配验证列表（列明已适配的终端型号及操作系统信息）	公示列表 + 上架前提交给平台的适配验证情况	上架前、适配范围变更
终端生产企业	进网检测中开展适配验证；涉诈风险安全评估与反诈能力前置性评测；保证进网许可证前后一致性；重大变化报备并重检；OTA 报方案与报告	升级方案、升级报告、一致性证明、报备	许可前后、每次 OTA
应用分发平台	推动 App 开发者电子签名声明；分发页公示适配验证列表；不向用户提供不兼容型号的智能体下载安装；在架巡查，未适配者限期整改或下架	声明受理与公示、兼容性校验、处置记录	上架审核、在架持续
应用程序开发者	通过电子签名主动声明是否同意智能体调用	一份带签名的授权声明	上架 / 声明变更

学姐的解读：最容易漏的是最后一行。你可能只维护一个上架的 App，但声明义务落在你身上；「未经声明同意不得强制调用」约束的是智能体侧，等于平台替你把「不同意」执行掉了。这份文件对纯 App 团队不是无感的。

三、调用授权怎么设计：三种策略，别用布尔值

策略	合规成本	生态流量	风险敞口	可逆性	学姐的判断
全量同意	低	最高	大：任意智能体可调任意能力，出事难定位	差	只适合纯工具、无敏感动作的 App
全量拒绝	最低	归零	最小	好	短期省事，等于退出智能体入口，别当长期方案
分级 opt-in（推荐）	中，要维护能力清单与版本	可控	可按能力收窄	好，可按条撤回	唯一兼顾合规与生态的做法

推荐第三条不是因为折中好听：通知只规定了「是否同意」这个最粗粒度——声明设计得越结构化，将来监管细化时改动越小。建议至少含 6 个字段：

▪︎ app_id + app_version：绑定哪个包、哪个版本；升级后重新确认还是自动继承要写清；

▪︎ allowed_capabilities：允许调用的能力枚举（「读公开页面」「读取账户摘要」「发起交易」分开列），不要总开关；

▪︎ allowed_agent_scope：允许哪些智能体（按唯一身份码或类别白名单），呼应通知要求的唯一身份码；

▪︎ valid_from / valid_until：有效期，避免一份声明无限期生效；

▪︎ signature + signed_at：电子签名与时间，用于不可抵赖与审计；

▪︎ revoke_path / change_log：撤回入口与变更记录，每次改动留版本。

两处必须辨析：

▪︎ 电子签名声明 ≠ 用户隐私授权弹窗。前者是开发者对分发平台作出的「第三方智能体能否调用本应用」授权，依据这份通知；后者是用户对 App 作出的个人信息处理同意，依据是个人信息保护法。主体、留存对象、撤回路径、审计方都不同，不能复用同一个勾选。

▪︎ 「不得强制调用」≠「不得调用」。通知约束的是「未经声明同意的，智能体不得强制调用」。学姐如实说：什么叫强制、用户主动发起算不算，通知没给判定口径。别自行解读成全面禁令，也别当没约束——先把日志留全（谁发起、调了哪个能力、依据哪份声明版本），等实施细则。

四、适配验证：从「演示成功一次」到「持续可靠」

通知要求智能体开发者与终端做适配验证，在产品设置页公示适配验证列表（列明已适配终端型号及操作系统信息），上架前把适配验证情况提交给分发平台。

央广网 11-07 引 DCCI 互联网研究院院长刘兴亮，把复杂度讲得很到位：「一个任务能在某款手机上完成，换一个型号、一个操作系统版本，能否依然稳定执行？权限是否合适，数据是否安全，执行结果是否符合用户预期？」；这意味着智能体产品要从「演示成功一次」走向「在明确支持的设备上持续可靠」；对终端厂商是「手机卖出去，责任还要跟着升级走」；对分发平台是审核延伸到兼容性与调用授权（央广网，2026-11-07）。

学姐的解读：这里冒出的是一个三维版本矩阵——终端型号 × 操作系统版本 × 智能体版本。App 时代兼容矩阵是「机型 × OS」两维，Agent 时代多了「智能体版本」：同一份声明、同一个 App，换个智能体版本行为可能就变。这与今天 A 篇「评测报告必须加模型版本 + harness 版本」是同一规律的监管侧投影。凡对外声称「支持什么」，都得回答「哪个版本上支持」。

用例模板（可直接抄）：以任务清单为行（查账单 / 设提醒 / 改套餐），以型号 × OS × 智能体版本为列，每格记四问结论 + 证据链接 + 测试时间：稳定执行（跨 N 次重复一致，不是跑通一次）、权限最小、数据安全、结果符合用户预期。

建法	覆盖率	成本	可公示性	跨版本维护	适用阶段
人工矩阵逐项测	中	高	好，证据完整	差，每版重来	首发、机型少
自动化回归 + 真机型池	高	前期大、边际低	好，自动生成列表	好	有持续发版后必走
只测旗舰机型	低	最低	差，公示列表撑不住	差	不建议，把风险留给用户

学姐的解读：别把适配验证当一次性过检成本。公示列表本身是信任凭证，能复用到客服话术、售前材料、渠道审核；做成自动生成的资产比临时补材料省得多。

五、OTA 现网升级：发版不再只是内部决定

通知第三部分：终端生产企业通过 OTA 做智能体现网升级，须提交现网升级方案，明确升级时间、规模、用户群体、业务场景、服务内容、业务经营模式、网络和数据安全措施、反电信网络诈骗措施等；升级结束后提交现网升级报告，经工信部组织专家评估、征求意见后，方可正式向用户提供服务。配套三条：终端智能体应参考智能体互联系列国家标准配备唯一身份码；保证进网许可证前后一致性；发生重大变化须报备并重新开展进网检测。

学姐的解读，三条落到排期上：

▪︎ 灰度发布的外部评审窗口被写进流程。「方案 → 报告 → 专家评估 + 征求意见 → 才可正式提供服务」，这段时长不在你控制内。做版本计划时别把内部发版日当成可对外承诺的上线日，要预留不确定窗口。这是最常被漏的排期坑。

▪︎ 「一致性」要求你先定义什么叫「重大变化」。建一份能力变更清单，给新增能力、权限范围扩大、调用第三方应用变化、智能体版本升级分别设触发阈值。没有这张表，每次评审都要从头吵。

▪︎ 唯一身份码让标准从「有」走到「被引用」。11-02 B 讲过 11 月 1 日生效的一批 AI 国家标准（含智能体互联系列）；这份通知明确写「参考智能体互联系列国家标准配备唯一身份码」，是下游监管文件开始引用标准的信号，比厂商发布会实在。

再辨析一组：现网升级评估 ≠ 应用商店版本审核。前者管已售出终端的能力变化，触发主体是终端生产企业，关注涉诈风险与数据安全；后者管应用包上架，触发主体是开发者。同一款产品可能两边都要走，别用一套材料硬凑。