本地模型不是断网版云模型：Agent任务路由怎么分才不泄密

Google刚给Antigravity SDK加入本地模型支持，最值得学的不是“离线也能聊天”，而是怎样把一个任务拆给不同模型。通俗地说，任务路由就是先判断哪些信息能离开设备、哪一步需要更强能力、失败会造成什么后果，再决定由本地还是云端执行。学会它，你能省成本，也能把敏感源码留在机器里。

最新事件：95个云端Token只负责规划

Google在2026年9月23日发布的官方技术文章中宣布，Antigravity SDK可通过LiteRT运行Gemma 4 26B A4B，也可接Ollama、LM Studio和vLLM等OpenAI兼容本地服务。官方建议设备拥有超过24GB显存或统一内存。

演示中，云端Gemini 3.8 Flash只根据文件名和任务描述拆解审计计划，没有接收源码；三个本地Gemma实例再复现漏洞、写补丁、互评并跑回归测试。官方记录显示，云端只用95个Token，97.2%的Token在本地处理。这是一次演示数据，不代表所有仓库都能达到同样比例。

概念解决什么问题

把所有任务都交给云模型，能力强但可能触碰隐私、网络和预算限制；全部放本地，又可能遇到显存不足、复杂规划不稳或知识过时。任务路由让一个Agent系统按约束组合不同执行者，并为每次跨边界传输留下理由。

可以把它类比成医院分诊：前台只收集必要症状，普通问题去门诊，危急情况升级专家，病历不会为了“方便”广播给所有科室。类比的边界是，模型不会像医生一样天然承担责任；路由规则、权限和审计仍由系统设计者负责。

去掉类比后的准确定义是：**任务路由是根据输入标签、数据策略、能力要求、成本预算和失败风险，将任务及其最小必要上下文分配给不同模型或工具的控制层。**它不只是模型选择，还包括脱敏、降级、超时、人工审批与结果校验。

flowchart TD
    A[用户任务] --> B[提取元数据与敏感标签]
    B --> C{源码或个人数据?}
    C -- 是 --> D[本地执行器]
    C -- 否 --> E{需要复杂规划?}
    E -- 是 --> F[云端规划器]
    E -- 否 --> D
    F --> G[只返回步骤与约束]
    G --> D
    D --> H[本地测试与策略校验]
    H --> I{高风险写操作?}
    I -- 是 --> J[人工审批]
    I -- 否 --> K[交付结果与审计记录]
    J --> K

最小实践：先写策略，再接模型

这个纯Python示例不调用任何模型，而是把路由决策做成可测试函数。无需安装依赖，保存为router.py后运行python3 router.py。

<span>from</span> dataclasses <span>import</span> dataclass

<span>@dataclass</span>
<span>class</span> <span>Task</span>:
    name: <span>str</span>
    contains_source: <span>bool</span> = <span>False</span>
    contains_personal_data: <span>bool</span> = <span>False</span>
    needs_frontier_reasoning: <span>bool</span> = <span>False</span>
    writes_external_system: <span>bool</span> = <span>False</span>

<span>def</span> <span>route</span>(<span>task: Task</span>) -> <span>dict</span>:
    sensitive = task.contains_source <span>or</span> task.contains_personal_data
    <span>if</span> sensitive:
        executor = <span>"local"</span>
        cloud_context = {<span>"task"</span>: task.name, <span>"data"</span>: <span>"redacted"</span>}
    <span>elif</span> task.needs_frontier_reasoning:
        executor = <span>"cloud"</span>
        cloud_context = {<span>"task"</span>: task.name}
    <span>else</span>:
        executor = <span>"local"</span>
        cloud_context = <span>None</span>

    <span>return</span> {
        <span>"executor"</span>: executor,
        <span>"cloud_context"</span>: cloud_context,
        <span>"approval"</span>: task.writes_external_system,
    }

cases = [
    Task(<span>"审计 auth.py"</span>, contains_source=<span>True</span>),
    Task(<span>"规划公开文档迁移"</span>, needs_frontier_reasoning=<span>True</span>),
    Task(<span>"发布补丁"</span>, contains_source=<span>True</span>, writes_external_system=<span>True</span>),
]
<span>for</span> item <span>in</span> cases:
    <span>print</span>(item.name, route(item))

关键点有三处：先用明确标签判断敏感性；云端上下文只保留完成规划所需的元数据；写外部系统即使本地执行也要审批。本次已用Python 3.9实际运行，三条任务分别路由到本地、云端和“本地加审批”。这验证的是策略逻辑，不是Antigravity、Gemma或真实安全隔离。

真实系统还应为每次决策记录策略版本、输入标签、选择结果和审批人，但不要把被保护的原文再次抄进日志。路由失败也必须“关闭式”处理：本地模型不可用时返回明确错误，不能为了可用性悄悄把源码升级发送到云端。上线前可用一组带敏感标记的固定任务做回归，确保更换模型或SDK后，数据边界没有随默认配置变化，审计记录也仍然完整可追溯。

三个常见误区

第一，“本地”不等于安全。模型进程若能读整个家目录、访问网络或拿到Git凭据，风险仍在。第二，脱敏不是删掉文件内容就结束；文件名、错误栈和测试数据也可能泄密。第三，强模型不该自动拿到更多权限。推理能力与授权范围是两条轴，复杂规划可以只看摘要，执行仍受本地工具白名单约束。

适用、不适用与我的判断

混合路由适合企业源码审计、离线现场设备、受监管数据处理，以及大量低风险本地任务配少量云端规划。它不适合硬件不足却强行跑大模型，也不适合必须把完整上下文上传才能完成的任务；这时应改流程或使用合规托管环境。

我的判断是，混合Agent的长期优势不是“本地便宜”，而是让每一份上下文都有清晰去向。官方演示的95个云端Token很亮眼，但生产指标应是越权传输为零、路由可解释、降级可预测，以及本地失败时不会静默把原始数据转发到云端。

5分钟实践题

给你自己的一个Agent任务列出四栏：原始输入、可上传摘要、必须本地处理的内容、需要审批的动作。再把上面代码新增一条规则：个人数据即使已经脱敏，若要发外部邮件仍必须审批。最后写一个断言，确保它不会被路由为“云端直接执行”。

如果你的Agent只能把一种信息留在本地，你会优先保护源码、客户数据，还是完整对话记录？

关注「蜗牛聊AI」，一起看懂技术变化背后的真正机会。

本文首发于 java4u.cn，转载请注明出处。