智能体终端进网怎么落地：适配验证、OTA 变更与分发声明的四道门

2026 年 11 月 6 日，工业和信息化部办公厅发布《关于加强智能体终端设备进网管理的通知》（工信厅信管〔2026〕42 号，成文日期 10 月 24 日）。文件不长，但把一件此前没有明确入口的事写进了流程：预置智能体的手机、平板、可穿戴设备，在申请进网许可之前，要先回答四个问题——适配做过没有、进网检测怎么过、OTA 升级怎么报、应用分发怎么声明。

很多团队第一反应是「我们不做手机，这事和我们无关」。但只要产品链条里出现预置智能体、终端适配、应用分发中的任何一环，文件就会以不同形式落到你头上：终端厂商要保证获证前后一致，智能体开发者要提交适配验证情况，应用开发者要通过电子签名声明是否同意智能体调用，分发平台要公示适配列表并做在架巡查。本文按这四道门拆开，给出可以放进研发流程的五张表和验收口径。文中的表格与顺序是我们做项目时的模板，不是文件原文；具体适用以主管部门和检测机构口径为准，不构成法律意见。

一、先把适用范围说清：管的是「预置智能体的终端」

文件开头给了两个定义。智能体是「具备自主感知、记忆、决策、交互与执行能力的智能系统」；智能体终端是「预置安装智能体的手机、平板、可穿戴设备等电信终端设备」。前者划定能力边界，后者划定设备边界。

这意味着两件事。第一，纯粹在云端运行、没有预置到终端里的智能体，不直接落入「智能体终端」这个定义；但只要它通过应用分发平台上架，第一项和第四项任务里的适配验证、分发声明仍然会落到开发者和平台身上。第二，预置是关键词。出厂预装、系统级集成、随设备一起交付的智能体，才需要在进网检测里过适配验证；后装 App 里的智能体，走的是应用分发那条线。两条线的责任主体不同，不能互相替代。

这张表容易被忽略的是最后一列。文件用的词是「应当」「须」「不得」，落到项目上就是「拿得出证据」。没有证据，动作做了也等于没做。

二、第一道门：适配验证，把「能跑」变成「能核对」

第一项任务要求智能体开发者加强与终端设备的适配验证，重点管五件事：权限调用、通信能力、网络与数据安全、用户权益、任务执行。文件还要求开发者在产品设置页面向用户公示适配验证列表，列明已完成适配的终端型号与操作系统信息；智能体在应用分发平台上架前，要向平台提交适配验证情况。

「适配」在演示阶段和在合规阶段是两件事。演示阶段只要在一台机器上跑通主流程就算完成；合规阶段要回答的是：换一个型号、换一个系统版本、换一种权限组合，表现是否仍然可预期。我们通常把适配拆成三类测试：

• 权限类：相机、麦克风、定位、通讯录、通知、无障碍、后台运行、网络访问，逐项记录「申请时机、拒绝后的降级路径、用户可见的说明」。
• 任务类：多步任务的暂停、恢复、取消、超时、重复执行；跨应用调用时对方拒绝或中途退出；任务执行到一半设备锁屏、断网、切后台。
• 数据类：哪些字段出设备、落在哪里、保存多久、用户能否查看和删除；日志里是否出现不该出现的敏感字段。

适配矩阵不要按「机型」堆，而要按「机型 × 系统版本 × 关键权限」建行。一行只回答一个问题：这个组合下，主流程是否通过、失败时是什么表现、证据在哪。矩阵的列建议固定为：终端型号、系统版本、芯片平台、关键权限、主流程结果、失败场景、证据链接、复测日期。矩阵一旦固定，后面进网、OTA、分发都能复用同一套证据。

三、第二道门：进网检测，预置智能体要过检测

第二项任务是这次文件的重心。预置智能体的终端，须在进网检测中依据有关标准开展智能体适配验证；依法开展涉诈风险安全评估和反诈能力前置性评测，落实重要通信工作要求。终端上使用的智能体应参考智能体互联系列国家标准配备身份码。终端生产企业要保证获证前后的一致性；发生重大变化，向工信部报备并按要求开展进网检测。

这里有三个工程点，容易被「送检」两个字盖过去。

第一，身份码不是一把 API Key。API Key 可以复制、共享、轮换；身份码要能对应到一个可注册、可追溯、可吊销的主体。做法上先建内部台账：一个智能体一行，写清名称、归属终端、版本、能力范围、责任部门、上线时间。对外调用时由台账编号派生凭证，不要让所有智能体共用一个平台账号——吊销时会把无关业务一起停掉。

第二，获证前后一致性要留基线。送检时的版本、权限、工具清单、模型配置、分发渠道，都要形成一份基线。之后每次变更都拿基线比对，而不是凭记忆判断「这次改动不大」。文件没有给出「重大变化」的量化标准，企业内部要先把判定规则写下来，再按规则报备。我们常用的判定表如下，属于项目模板，不是监管口径：

第三，涉诈与反诈评测要前置。文件把涉诈风险安全评估和反诈能力前置性评测写进了进网环节，说明它不再是上线后的运营动作。工程上要准备的是：账号与设备风控、异常调用频次、批量注册与群发能力、支付与转账相关动作的拦截、可疑行为的留痕与上报。哪些能力必须做、做到什么程度，以检测机构依据的标准为准，企业不要自行降低口径。

这一道门的交付物不是一份 PPT，而是三样可核对的东西：身份码与版本基线表、适配矩阵（与第一道门共用）、变更报备包（变化说明、回归结果、风险措施）。

四、第三道门：OTA 现网升级，先报方案再推

第三项任务针对现网升级。终端生产企业通过 OTA 等方式开展智能体现网升级的，应向工信部提交现网升级方案，明确升级时间、规模、用户群体、业务场景、服务内容、业务经营模式、网络和数据安全措施、反电信网络诈骗措施等内容，并同步做好重要通信工作。升级结束后，向工信部提交现网升级报告，经工信部组织专家评估、征求意见后方可正式向用户提供服务。

这段话里有两个时间点，项目排期时不能混：升级前交方案，升级后交报告，正式服务要等评估和征求意见完成。很多团队习惯「先灰度、再补材料」，文件把顺序倒了过来：方案在前，报告在后，正式放量排在后面。

工程上建议把 OTA 拆成四段：

1. 变更评估：这次升级动了模型、权限、工具、数据、分发中的哪几项；是否触及第二道门的「重大变化」；如果触及，先走报备和检测，不要直接推。
2. 方案与告知：按文件列的八项内容写方案；同时准备用户告知模板，说明升级内容、影响范围、可回退方式。
3. 灰度与回滚：先在内部和少量用户上验证；保留上一版本的回滚包和回滚条件；回滚演练要留记录，不要只写在方案里。
4. 报告与放量：升级结束提交报告；评估和征求意见完成后再正式放量；放量后继续观察异常调用、投诉和反诈指标。

这一道门容易被低估的是「用户群体」和「业务经营模式」两栏。前者决定灰度范围，后者决定升级后是否出现新的收费、订阅或分成安排。两栏写不清，方案会在评审时被打回。

五、第四道门：分发管理，App 开发者要表态

第四项任务把应用分发平台拉了进来。平台应推动应用程序开发者，通过电子签名主动声明是否同意智能体调用；未经声明同意的，智能体不得强制调用调取应用。平台应在分发页面向用户公示智能体适配验证列表，不得为用户提供不兼容设备型号的智能体下载和安装服务；还应加强在架智能体适配验证情况巡查，对未完成适配验证的智能体采取限期整改、下架处置等措施。

这条对做 App 的团队影响直接：以前「是否允许智能体调用」是一个产品策略，现在要变成一个可签名、可公示、可巡查的声明。工程上至少要做四件事：

• 声明字段：在分发资料里增加「是否同意智能体调用」的电子签名声明，明确同意范围（哪些能力、哪些页面、哪些数据）。
• 兼容清单：列出已完成适配的终端型号和系统版本；不兼容的型号不提供下载和安装。
• 拒绝路径：用户或应用拒绝调用时，智能体要有降级方案，不能卡死在半途；降级方案要可测试。
• 留痕：声明版本、签名时间、调用方、被调用能力、成功与失败结果，都要能查。后面平台巡查或用户投诉，拿得出记录。

对智能体开发者来说，这一条还意味着「先谈授权，再谈能力」。不能默认所有 App 都愿意被调用；对方没有声明同意，就不能强制调用。把授权当成产品设计的一部分，而不是上线前补一张表。

六、把四道门落成五张表

政策文件给的是任务，研发团队需要的是能更新、能验收的载体。我们通常落成五张表，规模按项目裁剪，但字段不要省：

五张表不需要一次做完。先做「一机型、一智能体、一条主流程」的最小闭环，把证据链跑通，再扩型号和场景。扩的时候复用同一套字段，不要每个项目重新发明一套 Excel。

七、交付物与验收指标

一次进网合规做完，建议至少留下六样东西：适配矩阵、权限与工具调用清单、身份码与版本基线表、OTA 方案与报告模板、分发声明与兼容清单、变更报备记录。少一样，下一次升级或换人时都要从头再问一遍。

验收不看演示，看证据。可以设四个指标，具体数值按项目和主管部门要求定，不要写成对外承诺：

• 适配覆盖率：目标机型 × 系统版本的关键组合中，有测试记录和失败降级路径的比例。
• 权限可解释率：清单里的每项权限，都能说清用途、申请时机、拒绝后的表现和用户告知位置。
• OTA 回滚演练通过率：随机抽取一次升级，能否按预案回滚到上一版本，回滚后主流程是否恢复。
• 分发声明覆盖率：上架智能体与应用中，完成电子签名声明和兼容清单的比例；未完成的是否有整改计划。

八、边界与成本

边界先说清。文件管的是预置智能体的电信终端进网管理，不是所有 AI 应用都要进网；云端智能体、纯软件产品、后装 App 的适用方式不同，具体以主管部门和检测机构口径为准。文件里的「应当」「须」是法定义务，文中的五张表、四道门和判定规则是我们的项目模板，不是监管原文；涉及具体产品能否上市、是否需要检测，建议在立项阶段就向检测机构做一次预沟通。本文不构成法律意见。

成本主要不在写文档，而在三处：一是机型与系统版本的适配测试，机型越多、权限越复杂，人天越高；二是送检与整改的往返，尤其是涉诈评测和反诈能力前置评测；三是 OTA 的方案、报告、评估与回滚演练，属于持续性投入，不是一次性项目。省钱的顺序建议反过来：先把权限和工具清单收敛，减少需要测试的组合；再把适配矩阵固定，复用证据；随后再扩机型。不要一上来铺全型号，证据链没跑通，铺得越宽返工越多。

九、常见问题

问：只做 App、不做终端，这个文件管得到吗？文件直接约束的是预置智能体的终端进网；但智能体通过应用分发平台上架时，适配验证提交、分发声明、兼容清单仍然会落到开发者和平台身上。做 App 的团队至少要准备第四道门里的声明与兼容材料。

问：智能体在云端、不预置到终端，还要不要做身份码？文件的原话是「终端上使用的智能体」应参考互联系列国家标准配备身份码。云端智能体是否落入、以何种方式落入，取决于它是否随终端交付、是否在终端上被调用。建议先在内部建台账，把编号规则定下来，再按主管部门口径映射，不要等到送检前才补。

问：身份码去哪里申请？文件说的是「参考智能体互联系列国家标准配备」，没有在这份通知里规定具体申请入口。企业可以先做内部身份码与台账，等外部节点和标准细则明确后再做映射；关键是每个智能体有独立编号，而不是所有智能体共用一个大账号。

问：每次 OTA 都要专家评估吗？文件要求现网升级提交方案，升级结束后提交报告，经工信部组织专家评估、征求意见后方可正式向用户提供服务。内部可以把变更分为重大与一般，重大变化按报备和检测走，一般变更留记录；但「一般」的判定要有书面规则，不能靠口头判断。

问：出口机型要不要按这个做？这份文件是中国进网管理规则，出口市场另有当地法规与认证要求，不能互相替代。做全球机型时，建议把中国进网、欧盟合规、目标市场认证拆成三条并行的工作流，共用适配矩阵和版本基线，但不要共用结论。

附：口径与来源

《工业和信息化部办公厅关于加强智能体终端设备进网管理的通知》（工信厅信管〔2026〕42 号），成文日期 2026 年 10 月 24 日，发布日期 2026 年 11 月 6 日，工业和信息化部信息通信管理局发布。文件定义、四项任务、身份码、涉诈风险安全评估与反诈能力前置性评测、OTA 方案与报告、分发声明与在架巡查等表述，均以工信部原文及政策解读为准。

政策解读见工信部《〈关于加强智能体终端设备进网管理的通知〉政策解读》（2026 年 11 月 6 日）；公开报道可交叉核对光明网、经济参考报 2026 年 11 月 10 日，央广网 2026 年 11 月 7 日，以及中国日报、全国电子商务公共服务网转载。不同媒体对「四方面内容」的概括一致，但个别细节表述有差异，引用时以工信部原文为准。

文中的四道门、五张表、重大变化判定表与验收指标，为美辰信息技术在 APP、IoT 与智能体项目中的实践模板，不代表监管要求，也不构成法律意见；具体产品是否需要进网检测、如何开展适配验证，以主管部门和检测机构口径为准。