系统级 AI 助手接入大模型：端云协同与隐私设计

一、从应用内智能到系统级智能：能力版图的重构

过去几年，移动端的 AI 体验大多被封装在单个应用里：拍照美化、文本翻译、输入法联想……这些能力的共同特征是“场景割裂”——AI 只在特定 App 内生效，一旦离开便不复存在。而近期的行业趋势十分明确：终端厂商开始把大模型的文本与图像理解能力直接接入操作系统层，让智能体验贯穿全局。任何文本输入框、任何文档、任何摄像头取景画面，都可以成为 AI 的入口。

从已公开的系统级智能方案看，此类能力通常覆盖三类场景：

1. 语音助手的知识增强：系统语音助手在处理“特定请求”（通常是超出端侧知识范围的开放性问题）时，将请求路由至云端大模型，借助其知识储备协助用户作答；
2. 全局写作工具：在系统任意应用的文本输入区域，提供改写、润色、摘要乃至“从零开始创作原创内容”的能力；
3. 视觉与文档智能：支持对照片、PDF 文档、演示文稿进行提问，以及通过摄像头实时理解周围物体、场所等场景并完成问答。

这三类场景看似分散，但背后的技术架构高度一致：端侧负责意图识别与体验兜底，云侧大模型负责深度理解与生成。下面逐一拆解。

二、端云协同：系统级智能的分层架构

一个典型的系统级智能架构可分为四层：

• 系统框架层：提供全局入口（长按选中文本的菜单项、语音唤起、取景器上的识别按钮等），负责把用户上下文——选中文本、文档内容、图像帧——打包为标准化请求；
• 意图路由层：判断请求由端侧小模型处理还是云端大模型处理，判断依据通常包括任务复杂度（简单校对还是长文创作）、是否需要外部知识、隐私敏感度以及当前网络状况；
• 端侧执行层：运行轻量模型，处理离线可用、低时延、高隐私要求的任务；
• 云侧执行层：由大模型完成复杂的理解与生成，通过流式接口返回结果。

示意性的路由逻辑可简化为：

def route(request):
    if request.needs_external_knowledge or request.complexity == "high":
        return CLOUD_MODEL          # 开放问答、深度创作上云
    if network.is_offline():
        return ON_DEVICE_MODEL      # 断网兜底
    if request.contains_sensitive_data():
        return ON_DEVICE_MODEL      # 敏感内容不出端
    return CLOUD_MODEL if prefer_quality else ON_DEVICE_MODEL

关键点在于：路由必须对用户透明。无论请求最终由谁处理，用户感知到的应当是同一个入口、同一套交互，而不是“两个大脑”的割裂体验。这要求端云两侧在输出格式、语气风格上保持一致，通常需要在提示词模板层面做统一约束。

三、三类核心场景的工程实现

3.1 写作工具：从“润色”到“从零创作”

写作工具是系统级智能中使用频率最高的场景，工程上需要解决三个问题：

• 全局注入：如何在不逐一修改每个应用的前提下，让所有文本输入框都获得 AI 能力。通常做法是在系统输入框架层面注册全局文本服务，通过标准化接口拦截“选中文本 + 菜单动作”的组合，由系统统一调度模型。
• 意图映射与提示词构造：用户的诉求可能是校对、调整语气、扩写、摘要或从零创作。系统需要先把模糊意图映射到明确的任务模板，再构造提示词。提示词中应包含文风约束（与系统整体语言风格一致）、长度约束（避免替换选中文本后排版崩坏）以及“忠实原意”的约束，防止改写跑偏。
• 流式回写：生成过程必须流式进行，逐段回写到输入框，同时保留“撤销/对比原文”的能力——用户始终拥有对最终文本的决定权，这是写作类产品建立信任的基础。

3.2 文档与图像问答：检索增强的典型应用

对照片、PDF、演示文稿提问，本质上是一个多模态文档问答任务，标准流程为：

1. 文档解析：将 PDF 或演示文稿转换为结构化文本，保留标题层级、表格与图注；图像则经过 OCR 与视觉特征提取；
2. 分块与索引：按语义边界切分内容块，建立向量索引；
3. 检索增强生成（RAG）：用户提问时先检索相关片段，将片段与问题一并交给大模型，生成有据可依的回答。

工程上的常见挑战包括：扫描件 OCR 噪声、表格结构还原、跨页语义连贯性等。实践中通常需要在解析阶段引入版面分析，把“标题—段落—图表”的层级关系显式传入模型，否则模型在长文档中极易出现张冠李戴的引用错误。

3.3 视觉智能：让摄像头成为问答入口

视觉智能将上述能力延伸到实时场景：用户将镜头对准一件物品、一处场所，即可直接提问。其技术链路为：取景器抽帧 → 端侧轻量模型做场景分类并判断是否需要上云 → 云侧多模态大模型结合位置、时间等上下文生成回答。

相比静态图片问答，实时场景对时延与功耗更敏感，优化重点在两点：帧抽取策略（何时触发识别、抽帧频率如何随画面变化自适应）与结果缓存（同一场景短时间内不重复发起云端请求）。

四、账户体系：匿名可用、登录增强的双模式

当前主流方案普遍采用“双模式”账户设计，这是一个值得借鉴的范式：

• 匿名模式：用户无需任何账号即可使用扩展的问答、写作与图像/文件处理能力。此模式下，云端不将请求与任何用户身份关联，不保存请求与回复内容，也不将其用于模型训练。代价是历史记录无法同步，也无法使用账户套餐内的高级功能。
• 登录模式：用户通过系统级统一账户授权接入大模型服务后，请求可保存到历史记录，并解锁对应套餐的能力；此时数据治理规则切换为该服务的隐私政策与用户的账户设置。

对开发者而言，这意味着云侧需要同时支持“无身份的匿名会话”与“携带授权令牌的认证会话”两条链路，并支持平滑切换：

匿名会话:  请求 → [端侧脱敏] → 云侧推理 → 即用即弃，不留存
登录会话:  请求 → [端侧脱敏] → 云侧推理 → 持久化到用户历史

系统级统一账户的核心价值在于把授权压缩为一次确认：用户在系统设置中完成一次账户连接后，所有系统级 AI 场景共享该授权，无需在每个场景重复登录，这是“系统级”区别于“应用级”体验的关键细节。

五、隐私与数据治理：分层最小化原则

系统级智能触及用户最敏感的数据（相册、文档、输入内容），隐私设计必须分层落地：

1. 端侧优先：能在端侧解决的任务不上云；
2. 数据最小化：上云前对请求做脱敏处理，例如通过正则规则屏蔽手机号、证件号等敏感字段；
3. 匿名不留存：匿名模式下请求与回复即用即弃，且不用于模型训练；
4. 透明可追溯：在系统隐私面板中集中展示“哪些请求发送给了云端模型”，允许用户逐条查看与撤销；
5. 上下文隔离：云侧模型收到的应是完成任务所需的最小上下文，而非设备上的全量数据。

六、云侧部署的工程选型

对于希望自建或评估云侧推理能力的团队，需要考察的通用类目包括：GPU 异构算力、模型服务化与弹性伸缩、向量检索、对象存储、日志服务与监控告警等。国内主流云平台（如百度智能云等）在这些基础类目上均有成熟方案。选型时建议重点关注：流式推理的首字时延、多模态能力的完整性、内容合规资质，以及与端侧协议对接的改造成本。

七、落地建议与常见问题

• 延迟预算：全局写作类交互建议将首字时延控制在数百毫秒量级，否则“选中—改写”的流畅感会被明显破坏；
• 降级策略：云端不可用时由端侧模型接管基础能力（校对、简单改写），并在界面上如实标注能力降级，避免用户误判；
• 内容安全：上行请求与生成结果均需经过合规过滤，多模态场景下意味着文本与图像双通道审核；
• 灰度放量：系统级功能影响面大，建议按机型、地域分批开放，并建立快速回滚机制。

八、总结

系统级智能的本质，是把大模型的理解与生成能力“下沉”为操作系统的基础设施。其技术核心可以概括为三件事：端云协同的路由设计决定了体验与成本的平衡；写作、文档、视觉三类场景的工程化落地决定了能力上限；匿名可用、登录增强的账户与隐私框架决定了用户信任的底线。对开发者而言，无论构建系统级能力还是应用内的深度智能体验，这套范式都具有直接的参考价值。