终端侧智能助手接入第三方大模型能力：架构设计与工程实践

一、背景：终端智能助手为何需要外部模型能力

近年来，智能手机等终端设备开始把“系统级智能助手”作为核心卖点。与以往仅在单一应用内提供问答不同，系统级助手的典型特征是跨应用、跨场景：它需要在写作工具中生成文案、在相册中理解图像、在文档阅读器里解析 PDF 与演示文稿，还要在语音助手中完成多轮问答。这类需求对模型能力的要求相当分散——既要通用知识问答，又要长文本理解，还要多模态感知。

单一自研模型很难在所有维度上同时达到可用水平，因此业界普遍采用“端侧小模型 + 云端大模型 + 第三方能力扩展”的混合架构。本文以某终端厂商近期公布的“系统智能助手在国内接入第三方大模型”的方案为技术背景，抽象出通用的接入架构与工程要点，供开发者在设计类似系统时参考。需要说明的是，本文讨论的是通用技术模式，不针对任何特定商业合作进行描述或评价。

二、整体架构：三层能力编排模型

从工程视角看，这类系统通常可抽象为三层：

┌─────────────────────────────────────────┐
│  交互层：Siri 类语音助手 / 写作工具 / 视觉入口  │
├─────────────────────────────────────────┤
│  编排层：意图识别 → 能力路由 → 结果聚合        │
├─────────────────────────────────────────┤
│  能力层：端侧模型 | 自研云模型 | 第三方扩展能力  │
└─────────────────────────────────────────┘

交互层负责采集用户输入（语音、文本、图像、文档）并呈现结果；编排层是系统的核心，决定一次请求交给哪个能力提供方处理；能力层则是实际执行推理的模型集合。

编排层的关键设计在于能力路由（Capability Routing）。它需要根据意图类型、输入模态、上下文长度、时延预算等信号，动态选择执行路径。例如：

• 简单的本地指令（设闹钟、发短信）→ 端侧模型或规则引擎，零延迟、零数据外发；
• 通用知识问答 → 云端大模型；
• 需要“从零创作原创内容”的长文本任务 → 具备强生成能力的扩展模型；
• 图像/文档理解 → 多模态能力提供方。

路由策略通常以配置表形式维护，便于灰度发布与快速回滚：

{
  "routes": [
    {"intent": "local_command", "handler": "on_device", "fallback": null},
    {"intent": "knowledge_qa", "handler": "cloud_llm", "fallback": "ext_model"},
    {"intent": "long_form_writing", "handler": "ext_model", "fallback": "cloud_llm"},
    {"intent": "image_understanding", "handler": "multimodal_ext", "fallback": "cloud_llm"}
  ],
  "timeout_ms": 8000,
  "max_retry": 1
}

这种“声明式路由 + 运行时兜底”的模式，是保证可用性的基础：当某个能力提供方超时或返回错误时，编排层可以静默降级到备用路径，而不是直接把失败暴露给用户。

三、能力映射：三类典型场景的技术拆解

3.1 语音助手中的“特定请求”接入

在语音助手场景中，第三方模型并非接管全部请求，而是处理特定类型的请求——通常是开放式知识问答、需要外部知识的推理，以及针对照片或文档的追问。这种“局部接入”的设计有其合理性：

• 成本可控：只有走外部模型的请求才产生调用费用，本地可处理的请求保持在端侧；
• 时延可控：端侧与自研云路径的响应时间更稳定；
• 风险可控：接入面越小，数据外发的边界越清晰。

工程上需要解决的一个问题是上下文传递。用户可能在多轮对话中先问一个本地可答的问题，再追问一个需要外部模型的问题。编排层需要维护会话状态，并在路由切换时把必要的上下文（而非全部历史）传递给下游，避免超出上下文窗口或造成不必要的数据外发。

3.2 写作工具的“从零创作”能力

系统级写作工具通常提供改写、润色、摘要等基础功能，这些功能可以完全在端侧或自研云完成。而“从零开始创作原创内容”属于生成式任务，对模型的创作能力要求更高，因此可能路由到扩展模型。

这里有一个容易被忽视的工程细节：写作工具的输入往往是编辑器中的选区或全文。如果用户选中的是一篇长文档，直接整段外发既不经济也不安全。常见做法是先做本地预处理——提取关键段落、压缩上下文、去除明显的敏感信息——再交给外部模型。预处理的质量直接决定了生成结果的相关性。

3.3 视觉智能中的图文理解

视觉智能场景包括通过摄像头识别周围物体、场所，并对图像内容进行问答。这类请求的特点是数据量大、隐私敏感度高。工程上通常采取以下策略：

• 端侧预筛：先在设备上完成目标检测、OCR 等轻量任务，只把需要深度理解的图像区域上传；
• 分辨率降采样：在满足识别精度的前提下压缩图像，减少传输开销；
• 显式授权：首次使用视觉能力时向用户说明数据流向，并提供关闭入口。

四、账号体系与隐私边界：可复用的设计范式

第三方能力接入必然涉及账号与数据归属问题。业界已经形成一套相对成熟的设计范式，其核心是“免登录可用、登录增强”的双模式：

免登录模式下，用户无需绑定第三方账号即可使用扩展能力。此时的关键约束是：请求与回复不应与用户的设备账号关联，不应被持久化保存，也不应用于模型训练。这实际上要求能力提供方以无状态方式处理请求，编排层在转发时剥离设备标识等关联信息。

登录模式下，用户主动绑定第三方账号，此时请求可保存至该账号的历史记录，并适用该账号的服务条款与隐私政策。用户由此获得跨设备的历史同步、套餐权益等增强功能。

这一范式的工程实现要点包括：

1. Token 隔离：第三方账号的凭证应存储在独立的安全域（如安全隔区），不与系统账号凭证混用；
2. 请求标注：每次外发请求携带明确的模式标记（匿名/绑定），供下游执行相应的数据处理策略；
3. 可撤回：用户解绑账号后，系统应停止向其历史记录写入新数据，并提供清除指引；
4. 透明度：在系统设置中清晰展示“哪些请求走了外部模型”，让用户可审计。

五、合规与本地化：不可回避的工程约束

在中国市场提供此类能力，需要满足一系列合规要求，这些要求会直接转化为技术设计约束：

• 数据出境与本地化：能力提供方需在境内具备合规的推理基础设施，请求与回复的处理链路应可审计；
• 内容安全：生成式输出需经过内容过滤，过滤环节应部署在返回用户之前的链路上；
• 模型备案：对外提供服务的生成式模型需完成相应备案，终端厂商在选型时应核验能力提供方的合规资质；
• 未成年人保护：需提供使用时长管理、内容分级等机制。

对开发者而言，这意味着能力层不能是黑盒。编排层需要保留对输入输出的可观测性，日志（脱敏后）应能支撑合规审计与问题回溯。

六、工程实践建议

结合上述分析，给出几条可落地的建议：

1. 把路由做成配置而非硬编码。能力提供方可能变更、灰度、下线，路由表应支持热更新。
2. 为每条路径设定独立的超时与降级策略。外部模型的时延分布与自研服务不同，统一超时会误伤。
3. 默认最小化数据外发。能端侧做的绝不云侧做，能传摘要绝不传全文，能传区域绝不传整图。
4. 建立端到端可观测性。至少记录：请求 ID、路由决策、各段耗时、降级事件、错误码。这些数据是优化体验与排查问题的依据。
5. 隐私设计前置。在需求评审阶段就明确“哪些数据会离开设备”，而不是上线前再补授权弹窗。

七、结语

终端智能助手接入第三方大模型能力，本质上是一个能力编排与边界治理的问题。技术难点不在于调用一个模型接口，而在于：如何在一套系统里同时容纳端侧、自研云与外部能力，如何让路由决策既高效又可控，如何在提供能力的同时把数据外发面收敛到最小。把这几件事设计清楚，系统才具备长期演进的基础。对于正在构建类似能力的团队，建议优先把编排层与隐私边界做成平台化组件——这两块的复用价值，远高于任何单点功能的实现。