一台以智能体为卖点的手机要拿入网许可，多出来什么材料
一、许可审的是设备与网络的接口行为，不是宣传语
据公开报道，有终端品牌在发布会后不足百日就宣布其首款以大模型为原生能力的智能体手机取得入网许可并随后上市。这条时间线不是本篇的判断依据，但它把一个问题推到台面上：这类设备的卖点恰恰是“设备会自己做主发起行为”，而入网类许可一贯关注的是设备与网络之间的接口行为是否可预期。卖点与审查对象之间没有冲突，冲突在资料——过去的终端不会主动决定“什么时候联网、连到哪里、连了传什么”，现在会了。
对企业侧来说，这意味着申报材料的工作量不在射频那一块，那一块流程成熟；工作量在把智能体能力从一段产品描述，改写成一组可核对、可复现、可关闭的行为定义。写不出这组定义，资料就只能靠演示视频撑，而演示视频说明不了“不演示的时候它干什么”。
我们给客户做终端配套的管理与合规工具时，遇到过的真实卡点都在这里：产品团队的能力描述是形容词（更懂你、更主动），合规与测试团队需要的是动词加对象加条件。本篇要处理的就是这次翻译。
二、四个常规面，每面都要自己先有证据
入网类许可通常覆盖四件事。逐面看企业侧要准备什么，准备的是自证材料而不是别人的结论。
| 常规面 | 关注什么 | 企业侧要自备的东西 | 最容易漏的一项 |
|---|---|---|---|
| 射频与制式符合性 | 发射指标、频段与制式支持是否与申报一致 | 硬件设计变更记录、实际出货配置与申报配置的一致性核对表 | 同一型号多硬件版本混线出货，版本与申报参数对不上 |
| 网络接口与协议行为 | 设备接入网络时的协议实现、寻址与重连行为 | 出网行为矩阵：什么条件下发起连接、连接谁、多久一次、失败怎么退避 | 后台常驻服务的周期性外联没进矩阵，被当成“系统行为”忽略 |
| 安全与隐私基线 | 权限模型、数据流向、更新通道安全 | 采集清单、目的说明、权利实现路径、权限申请与实际使用一致性说明 | 权限申请了但只在智能体自主决策路径上使用，说明里没有体现这条路径 |
| 标识与资料一致性 | 型号、界面标识、说明书与实际能力是否一致 | 说明书与界面文案的能力描述源、能力开关的实际默认值快照 | 宣传口径写了的能力，出厂默认是关的，资料里没写明 |
四项里真正会反复返工的是网络接口行为面。传统终端的行为矩阵由应用开发者写死，可枚举；智能体主导的行为矩阵由策略与模型输出共同决定，同一句用户指令在不同上下文里可能触发不同的外联。这就引出新增的申报面。
三、智能体带来的四个新增申报面
- 自主联网的触发条件。哪些事件会让设备在没有用户显式点击的情况下发起网络请求：定时任务、本地事件（连接耳机、进入某网络）、模型判断“该查一下了”、来自云端任务的推送回执。每一类都要写明判据、频率上限和抑制条件。
- 可访问的目标范围。不是列域名清单，而是把目标类型写清：自有服务、第三方服务能力、用户指定站点、由搜索结果动态给出的地址。最后两类风险最高，必须有范围收缩机制与白名单降级路径，并说明降级后功能如何变化。
- 本地与云端的分工。哪些推理在端侧完成，哪些必须上传；上传的最小单位是什么（原始音频、识别后的文本、抽取后的意图结构、还是脱敏后的摘要）；模型版本与云端服务版本变更时，这套分工是否改变。
- 用户能否一键停止。有一个总开关，能同时停掉自主联网、后台任务与云端委托执行；关闭后设备应退回到普通终端行为。这一条是可控性的核心，也是最容易只做界面不做实效的：界面上关了，后台任务队列里还有已排队的动作。
四个面共同的验收点是“开关的实效”。我们在实现时要求开关动作写进一条持久化的策略记录，所有出网路径发起前都读这条记录，而不是只在 UI 层拦住入口。
四、把智能体能力写成可测试项：五字段行为清单
能力描述要变成清单，每条一个动作，五个字段。
- 能触发什么动作：写成“对象加效果”，例如向云端提交文本并取回结果、在用户已登录的第三方服务上创建一个待办项、修改本机一项系统设置。凡是落在“修改设置、发送内容、发起支付、删除数据”上的动作必须单独成条。
- 动作的前置条件：需要哪一类上下文、依赖哪个已授权账号、是否要求网络类型或电量条件。
- 需要什么授权：对应到系统权限名与用户确认环节，并标注该授权是否可撤销、撤销后动作是否自动失效。
- 失败时的表现：静默失败、提示用户、重试还是降级为人工确认；重试的次数与退避策略。
- 能否被用户完全关闭：三档之一（不可关、可关但影响功能、默认关闭需显式开启）。
这份清单同时是测试的输入和日志的字段定义。取证方式是把它变成可复核日志：每条记录至少含动作发起时刻、动作标识、目标地址类型、当次授权状态、执行结果与用户可见的提示形式。日志的价值在于能回答“那次是谁让它做的”——用户手动、任务计划还是模型自主判定，这个来源字段没有的话，任何一次异常外联都无法解释。演示视频在这里替代不了日志，因为视频只覆盖了拍摄到的那一次路径，而许可与追责关心的是没被拍到的那些次。
五、授权分三档，端云分工决定材料厚度
授权与提示建议固定三档，并且每一档在界面和日志上都有落地要求。
首次授权：一次说明用途与数据范围，界面文案要与采集清单逐字同源，日志记录授权版本号和文案版本。按次确认：每次执行前出现，只对高影响动作启用，界面要写明这次要发到哪一类目标，日志记录用户的选择。默认关闭：智能体不得自主执行，即使模型判定该做也只能提示用户；日志记录被抑制的次数——这个数字很关键，它能暴露“策略过严导致功能不可用”，也能证明用户主动放弃过。
端侧模型和云侧调用的差别会直接改变材料厚度。端侧完成的部分，要说明模型是否可更新、更新后行为是否改变；云侧完成的部分，要说明哪些数据离开设备、离开到什么粒度、服务端留存多久、用户删除请求能否落到物理清除。最容易被忽略的是中间态：为了提升响应速度在端侧缓存的上下文片段，它既算采集也算留存，必须进采集清单，不能因为“只存在内存里”就不写。
隐私基线的四项材料要能互相引用得上。采集清单里的每一项，在目的说明里有一句解释，在权利实现路径里有一个可操作入口，在一致性说明里能对应到实际调用该权限的代码路径。四份材料各写各的，是这类争议最常见的来源。
六、迭代期的一致性与上市前那份清单
软件持续更新会带来一个传统终端不太尖锐的问题：能力变了，资料还一致吗。工程上的处置不是每改一次就重走流程，而是事先把“变更分级”定在自己这边——影响出网目标类型、影响数据离机粒度、影响自主执行权限的改动算一类，必须在资料更新并确认前不进入全量推送；只改模型权重不改行为面的算另一类，保留行为清单与日志字段不变即可通过回归比对确认一致。灰度期间的行为差异要单独处理：灰度批次和全量批次的行为清单版本不同，日志里就必须带版本号，否则事后无法判断某条外联出自哪个策略。
上市前的准备清单，按可核对项写：许可状态与型号、硬件版本、出货软件版本三者对得上；说明书里的能力与限制描述与实际默认开关一致；面向用户的总关闭入口在设置里能被找到并且实测有效；投诉与咨询渠道有明确受理人和响应流程；异常事件（失控外联、误执行、误删）的响应流程含断网与远端撤销的动作序列，并演练过一次。
配套服务商也会被动卷入。客户在采购这类终端做批量部署时，建议问五个问题：能否提供行为清单与关闭后的实效验证方式；设备管理侧能不能看到每条自主动作的日志；策略变更与软件更新是否分批推送、企业能否延后接受；出网目标能否被企业侧网络策略约束；发生误执行时的责任与处置流程写到哪一级。这五个问题回答不了的批次，不适合进生产与涉密场景。
对洹拓这样替客户做终端配套系统与交付的一方来说，判断标准其实很朴素：能不能用一条日志把一个动作追溯到某个授权和某个开关状态。做到这一点，“智能体原生”就从一句宣传语变成一组可交付的工程事实；做不到，它就只是一个需要在争议发生时重新解释的形容词。