每次看到有人把“本地模型”当作“断网版云模型”用的时候我都替他捏把汗。作为实际跑过Agent项目的人我必须说清楚一件事这两者的差别不是“一个能离线、一个不能离线”这么简单而是权限边界和可靠性边界完全不一样。我自己的日常就是Claude Code里调LM Studio本地模型、Ollama跑小参数私有模型做Agent工具调用同时还要把Codex沙盒、云端API这类高能力模型接入同一套Agent体系。真正的问题从来不是“本地模型能不能打”而是——当Agent的任务里同时混着敏感数据和普通请求时任务路由要怎么分才不会把本地的秘密泄到云端。这篇文章就是围绕这个核心痛点展开写给正在做Agent开发、手里有敏感数据诉求、又考虑用本地模型做兜底的团队和个人开发者。1. 别把本地模型当“断网版云模型”——差的不是网速是权限边界1.1 为什么会有“断网版云模型”这种错觉很多人在最开始接触本地模型时脑子里的预期是“云模型能干的活本地模型断网也能干只是笨一点。”这个预期一半对、一半坑。对的那一半是模型架构同源、prompt方法通用你在云端能用到的思维链技巧本地模型基本也能用坑的那一半是本地模型和云模型在“能力密度”上完全是两种物种。打个比方云模型像一个随时待命的专家团队什么都会但你需要把问题资料送到人家的会议室去本地模型像你自己工位上的资深同事能力范围有限但资料全程不出你的办公室。如果你把本地模型当“断网版专家团队”用就会默认所有任务都能在本地完成只是效果差一点。可实际跑下来你会发现代码生成质量、长上下文理解、工具调用准确性这些硬指标本地模型和云模型的差距是数量级的不是“差一点”。更关键的是很多人没有意识到本地模型不是云模型的“阉割版”它是一个独立的计算实体。它跑在你的机器上用你的显存吃你的CPU它的能力边界由你的硬件决定而不是由订阅费决定。这个概念不掰扯清楚后面所有关于路由的讨论都是空中楼阁。1.2 本地模型的真实定位可信计算边界从安全架构的角度看本地模型最重要的价值不是“离线可用”而是“数据不出域”。这个“域”可以是你的个人电脑、公司内网、或者一个私有化的K8s集群。只要推理过程发生在这个域内数据就始终在你自己的控制范围内你不需要信任任何第三方服务器、不需要担心日志留存、不需要纠结API厂商的数据使用条款。这个特性和云模型形成了非常清晰的互补关系。云模型擅长的是“高能力泛化”任务——比如复杂代码重构、长文档综合理解、开放式创意生成本地模型擅长的是“高隐私密度”任务——比如处理客户名单、内部源代码片段、密钥样例、未公开的财务数据。所以我在项目里从来不用“本地模型能不能替代云模型”这个思路来选型而是问自己一句话这个任务如果交给云端泄露了会怎样如果答案是“会出事”那不管本地模型能力够不够都得优先考虑本地。这就是信任边界对路由决策的首要约束力。1.3 安全不是给云断网而是给数据分路很多团队处理敏感数据的第一反应是“那就别用云模型了全部走本地”。这个思路在数据安全上是对的但在Agent实操里会撞墙。因为Agent的能力上限往往就取决于底层模型的上限你让一个7B模型去写复杂的业务重构代码、去分析几千行的日志、去形成一份严谨的架构评审意见结果基本是灾难。真正的解法不是“一刀切禁用云模型”而是“让数据分路走”。把任务拆开剥离出哪些部分是核心敏感的哪些部分是外围的、可以放心的。比如一个“分析代码库安全隐患”的任务主体逻辑是扫描、定位、过滤这些可以用本地模型完成但最终生成一份综合报告、建议改进方案的时候报告的模板和表述完全不含敏感源码完全可以交给云模型润色。这就是“任务路由”存在的前提所有Agent任务本质上都是可分解的路由层就是在分解之后根据每一段的数据密级和能力需求决定走本地还是走云端。我把这个叫做“数据分路”它比“给云断网”优雅得多也实用得多。2. Agent任务路由的核心三个信号决定本地还是云端2.1 路由的本质是“信任×能力”二维决策在做路由设计的时候我踩过的最大的坑就是把路由做成了一维判断“这个请求是敏感的就本地不敏感就云”。结果很快发现敏感度判断只是必要条件不是充分条件。一个任务即使完全不敏感但如果本地模型能力不够硬跑本地只会让Agent疯狂出错、重试、最后超时。所以我在实际项目里把路由决策框架设计成二维的横轴是数据密级纵轴是任务复杂度。数据密级决定“能不能走云”任务复杂度决定“该不该走云”。只有两个维度都满足条件才把请求放行到云端否则就留在本地执行或者走一个“本地初筛云端精修”的混合链路。这个二维矩阵的直观理解是任务类型数据低敏感数据高敏感低复杂度重命名、字段提取、简单QA云端便宜快本地能力够用高复杂度代码重构、长文档总结、复杂Agent编排云端能力优先混合链路本地先脱敏/初筛云端再精修我后面会展开“混合链路”的具体做法。这里先记住一个结论路由不是“本地还是云”的二元对立而是“这个任务的哪一段应该在哪里跑”的过程决策。2.2 信号一数据密级——本地模型的看门狗职责数据密级怎么判断不能靠拍脑袋要有一套可执行的敏感检测规则。我在项目里落地的是一个“三级密级标注”体系L1 公开数据比如从公开仓库拉下来的代码、网上能搜到的文档、没有业务标识的测试数据。可以放心走云端。L2 内部数据公司内部文档、未公开的业务逻辑、但与用户隐私无关的代码。走云端有风险但风险可控可以通过脱敏处理后放行。L3 极敏感数据涉及用户个人身份信息、密钥、客户名单、未公开财报、核心算法源码。这类数据默认全部留在本地除非经过严格脱敏或者特殊审批。这个分级不是ACL那种静态权限而是动态的、内容相关的。因为Agent输入往往是混杂的一个请求里可能既有公开上下文、又有内部代码片段。我的做法是在路由层加一道“敏感内容扫描”用正则和关键词规则先跑一遍命中L3规则的就强制本地命中L2的就先问用户“要不要脱敏后走云”L1就直接放行。这个扫描层就像一个看门狗它的职责不是替模型做决定而是把数据密级这个信号量化出来给路由决策提供依据。2.3 信号二能力需求——什么时候必须放行云端本地模型再努力能力天花板就摆在那里。以我常用的几款本地模型为例7B级别的模型擅长单点问答、简单代码生成、结构化信息提取13B-32B级别的模型可以做中等复杂度的代码修改、基础工具调用要稳定跑Agent自动化流程至少需要70B级别以上的模型而70B量化模型跑起来显存就要48GB很多开发者的个人机器根本扛不住。所以在判断能力需求时我一般用三个指标快速评估上下文长度任务是单轮问答还是需要携带大量上下文本地模型一旦上下文撑爆会出现严重的“中途失忆”Agent前面的步骤全部白搭。工具调用准确率Agent的核心是“会调用工具、能解析工具返回值”。本地小模型经常出现参数格式错误、函数名拼错、JSON解析失败。如果任务链路里工具很多就要认真掂量本地模型能不能稳定跑完。代码生成质量涉及复杂逻辑的代码改写本地模型和云模型的差距非常明显。云模型能理解整个项目的语义本地模型经常只盯着眼前那一段代码硬改改完就是行为不符合预期。如果这三个指标里有任何一个明显不满足那就说明这是一个“必须放行云端”的任务。在这些场景里硬用本地模型不是安全是给自己挖坑。2.4 信号三实时性与成本——把延迟变成路由参数很多人容易忽略的是路由决策不应该只看“安不安全”和“能不能跑”还要看“等不等得起”。本地推理的延迟和云端API的延迟在Agent场景下的表现差异很大。本地模型跑一个中等复杂度的生成任务大概需要几秒到几十秒云模型通常1-3秒就能返回但受网络和限流影响偶尔会突然飙到十几秒。所以在路由层我还会加一个“实时性信号”如果任务是一个用户在线等待的交互式请求我倾向于优先走云除非数据敏感如果任务是后台批量处理的离线任务我可以接受更大的延迟就倾向于走本地因为本地没有按token计费批量跑长任务能省一大笔钱。成本也是一个容易被忽视的信号。云端API的token费用在单次请求里看着不贵但Agent是循环调用模型的一个稍复杂的任务可能来回调用几十次。有一次我跑一个自动化测试用例生成任务一晚上几千次API调用第二天账单让我直接清醒了。从那以后凡是能接受延迟的批处理任务我都默认先走本地这就是成本信号对路由的约束。3. 实操落地我在Agent项目里怎么搭任务路由层3.1 基础设施本地模型服务与Agent框架的对接方式说了这么多原理终于到落地环节。先把基础设施说清楚本地模型怎么和Agent框架对接。目前市面上主流的Agent框架包括Claude Code、Codex、自研的Agent开发框架都支持通过OpenAI兼容的API端点接入自定义模型。也就是说你只要在本地跑一个支持OpenAI API格式的推理服务Agent框架就能直接调用。我现在的标准配置是本地推理服务Ollama或者LM Studio。Ollama胜在命令行友好、模型管理简单适合自己写脚本的场景LM Studio胜在图形界面方便、对GGUF模型格式支持好适合日常调试。两者都支持OpenAI兼容端点。本地模型选择隐私优先场景用7B/8B模型比如Qwen系列、Llama系列保底场景用13B-32B模型对显存有信心的可以尝试70B量化。云模型接入保留正常的OpenAI兼容云端API端点或者通过Agent框架自带的企业版网关能力接入。具体的对接配置不复杂核心就是改一个base_url。Ollama跑起来之后OpenAI兼容端点是http://localhost:11434/v1LM Studio是http://localhost:1234/v1。你在Agent框架的配置文件里把这个base_url指过去模型名填成你本地拉取的模型名就能让Claude Code这类工具用上本地模型。一个小提示如果你在Windows上用LM Studio记得装好之后先跑一个测试请求确认返回格式是OpenAI兼容的choices数组结构而不是LM Studio的旧格式。我遇到过好几次Agent侧解析失败最后发现是base_url指到了非标准端口。3.2 路由网关的实现一份可抄的Python示例要真正实现“任务路由”不能只在Agent框架里静态指定一个模型。我的做法是写一个轻量级的路由网关夹在Agent和模型之间拦截所有请求做密级扫描、能力判断、然后转发到不同的后端。下面是一份可以直接上手的Python路由网关示例我项目里就是基于它迭代的。首先是配置文件{ backends: { local: { type: openai_compatible, base_url: http://localhost:11434/v1, model: qwen2.5:7b, max_tokens: 4096 }, cloud: { type: openai_compatible, base_url: https://api.example.com/v1, model: gpt-4o, api_key_env: CLOUD_API_KEY, max_tokens: 8192 } }, sensitive_policy: { force_local_keywords: [secret, private_key, client_name, password], deny_cloud_patterns: [-----BEGIN.*PRIVATE KEY-----, AKID[0-9A-Za-z]{16}] } }然后是路由核心逻辑我简化处理了但主干逻辑完整保留import json import re from openai import OpenAI def load_config(pathrouter_config.json): with open(path, r, encodingutf-8) as f: return json.load(f) def check_sensitive(text: str, policy: dict) - str: # 返回 L1 / L2 / L3 for pattern in policy.get(deny_cloud_patterns, []): if re.search(pattern, text): return L3 for keyword in policy.get(force_local_keywords, []): if keyword.lower() in text.lower(): return L2 return L1 def needs_cloud(task_desc: str, content: str) - bool: # 简单能力评估任务描述里出现这些关键词默认认为本地模型能力不足 high_complexity_keywords [重构, 总结报告, 分析架构, 撰写方案, code review] context_len_estimate len(content) if context_len_estimate 6000: return True for kw in high_complexity_keywords: if kw in task_desc: return True return False def route_request(messages, task_desc, cfgNone): if cfg is None: cfg load_config() full_text \n.join(m[content] for m in messages) level check_sensitive(full_text, cfg[sensitive_policy]) if level L3: backend cfg[backends][local] elif level L2: backend cfg[backends][local] # 保守策略内部数据默认走本地 else: backend cfg[backends][cloud] if needs_cloud(task_desc, full_text) else cfg[backends][local] client OpenAI(base_urlbackend[base_url], api_keybackend.get(api_key, no-key)) response client.chat.completions.create( modelbackend[model], messagesmessages, max_tokensbackend[max_tokens] ) return response.choices[0].message.content, backend[name] if name in backend else backend[type]这个示例的逻辑是先做敏感扫描L3强制本地L2也保守走本地你可以在实际项目里改成“脱敏后放行”L1再结合任务复杂度决定后端。实际跑起来之后你会发现大量纯公开、低复杂度的任务被分流到本地只有真正需要能力上限的任务才会上云敏感数据始终留在本地。3.3 敏感检测与任务分类一条规则表胜过十个prompt在3.2的代码里敏感检测用的是关键词和正则表示式。这套方法看起来朴素但在生产里异常稳定。我自己一开始也尝试过用LLM做敏感内容分类让模型自己判断“这个请求能不能走云”结果发现两个问题一是额外引入一次模型调用延迟和成本都上去了二是模型对敏感内容的判断标准不稳定同一个请求有时候判L1有时候判L3。痛定思痛之后我把敏感检测彻底改成了规则表驱动。规则表按两类维护一类是“强制本地”的关键词命中即L3另一类是“禁止上云”的内容模式比如密钥块、身份证号、银行卡号等正则。这样虽然检测能力不如模型灵活但胜在确定性高、可审计、零误判逃逸。路由层要的是“宁可错杀不可放过”规则表最合适。任务分类也是同一个思路。判断“是否复杂任务”用关键词表就够了不需要真的去理解任务语义。我维护了一张“复杂任务特征词”表包括重构、架构、长文档、综合报告、多表关联等。命中就提高云端概率。这种规则表的好处是任何一次误判都能定位、修表、回归完全可控。3.4 沙盒隔离与并发控制路由之外的最后一环任务路由解决的是“请求去哪”的问题但Agent跑起来之后还有两个绕不开的工程问题隔离和并发。先说隔离。你的Agent一旦能调用本地和云端两侧的模型就意味着它同时拥有本地数据访问能力和网络能力。如果Agent被恶意prompt注入诱导它读取本地敏感文件然后拼接进云端请求路由层的敏感扫描是在请求层面拦截的但如果注入发生在Agent内部路由层是看不见的。所以我现在的做法是涉及L3数据的任务Agent运行环境放在一个网络隔离的沙盒里沙盒内禁止任何外连请求除了本地推理服务。这就是热词里“沙盒”的实际用途——它不是防Agent乱跑而是让Agent即使被注入也没有通道把数据送出去。再说并发。热词里有“ai agent怎么扛并发”这个实际问题。本地模型扛并发的能力很弱一块显卡同时跑多个推理请求会出现显存溢出、排队、超时。我的经验是本地后端用Ollama的时候通过环境变量限制并发数比如OLLAMA_NUM_PARALLEL1让请求串行跑云后端则要做好限流重试不能把云API的限额抱怨全抛给用户。路由层实际上还承担了一个轻量级调度器的角色控制每个后端的最大并发量超出的请求排队等待。4. 踩坑实录7个你在文档里看不到的路由问题4.1 格式一致性本地模型能跑通但返回格式会“温柔地”跑偏这是我最先撞上的坑。云模型经过大规模指令微调返回JSON的格式极其稳定本地小模型不是不稳而是“温柔地跑偏”。比如让它返回一个工具调用参数它会在JSON外面包一层解释文字“好的我来为你调用工具参数如下{tool: ...}”。这个多余的包装会让Agent框架的解析器直接报错。排查思路很简单把同一个prompt分别发给本地模型和云模型对比返回格式你会发现差异非常大。解决办法不是去微调模型成本太高而是在路由网关里加一个“格式规整层”针对本地模型返回结果做一次后处理。比如提取JSON片段、把markdown代码块剥掉、强制JSON解析。我在代码里是这样写的import json import re def extract_json(text: str) - dict: match re.search(r\{.*\}, text, re.DOTALL) if not match: raise ValueError(no json found) return json.loads(match.group(0))这个函数看起来很粗暴但实测对本地模型特别管用。注意路由网关里的这个规整层只对本地模型生效云端模型的返回按原样透传避免无谓的二次解析引入Bug。4.2 敏感检测误杀关键词表太激进会把正常任务卡死在本地刚开始我建敏感关键词表的时候把“customer”“user”“client”这类单词都加了进去。结果整个Agent瞬间“偏瘫”几乎所有对话都被打上L2/L3标签全部走本地而本地模型能力又跟不上最终用户体验极差。后来我改成了“上下文感知命中”而不是“单词命中”。比如“client”这个单词只有在“client_name”“client_list”“client_contact”这类组合词里才触发敏感规则单出现“client”当主语时不算敏感。代码实现上就是从简单的in判断改成正则word-boundary匹配比如\bclient_(name|list|contact)\b。之后误杀率大幅下降。这里给大家一个经验值敏感规则表宁可少而精准不要多而散。每加一条规则都要跑一遍回归用例确认它不会把正常的公开任务拦下来。因为你每拦下一个任务就意味着把负担转嫁给了本地模型而本地模型才是真正的瓶颈。4.3 路由层本身会成为单点故障路由网关接管了所有请求那网关挂了Agent就全挂了。这个坑我是被线上事故教育过之后才重视起来的。最开始我的路由网关没做降级策略结果有一次本地推理服务OOM网关连续超时整个Agent项目都不可用。现在我的设计是路由判定失败默认走本地还是默认走云端要分情况。如果判定失败的原因是无法确认数据密级那默认走本地宁可牺牲能力不能把未知数据放出去如果判定失败的原因是本地服务不可用那走云端但要打一个“降级”日志。做成两层熔断本地挂了自动切云云不可用自动切本地两边都不可用则直接终止Agent任务而不是盲等。4.4 Agent循环调用时的延迟叠加Agent不是一次模型调用它是一连串模型调用。每轮Agent循环都要走一遍路由网关敏感扫描、复杂度判断、转发、等待响应。如果单个环节耗时50毫秒循环20轮就是1秒看起来不算大但真实场景里本地模型单次生成就要几十秒再加上路由开销一次自动化任务跑下来三四十分钟很正常。我的优化方案是做“session级路由缓存”。在一个相同的Agent任务会话里如果前几轮已经判定过数据密级和任务类型后续轮次直接复用判定结果不再重新扫描。只有新增内容命中敏感规则才升级密级重新路由。这个缓存能把路由开销从“每轮都付”降到“一个任务付一次”效果非常显著。4.5 本地模型不联网不等于工具调用不联网这是最容易被误解的一点。很多人以为把请求路由到本地模型整个链路就安全了。不对。Agent框架除了调用模型还要调用工具——搜索、读文件、执行代码、调内部API。这些工具调用发生在Agent层不在模型层。所以即使模型推理在本地Agent框架本身还有网络权限的话上下文里的数据依然可能被工具泄露出去。所以我在沙盒一节提到过L3任务必须运行在禁止外联的沙盒环境里。但这里还要补充一点那云端模型呢如果Agent里混着云端模型的循环沙盒网络策略就会冲突。我的解法是把Agent的“工具层”和“模型层”拆成两个独立进程工具层根据任务密级分配网络权限模型层只管推理。这样本地模型无网工具进程处理L3任务云模型外联工具进程处理L1任务同一套Agent框架里两个角色互不干扰。4.6 上下文长度估算不准导致路由判断错误在2.4的示例代码里我用len(content)估算上下文长度实际项目中这是不够的。一段中文文本的字符数不等于token数尤其是包含代码时token密度会忽高忽低。我遇到过很多次估算长度只有3000字符实际token却有8000本地模型直接上下文溢出Agent中途失忆。现在我的做法是引入tiktoken做真实token计数。路由网关里加一个轻量级计数函数用真实token数参与决策而不是字符串长度。代价是多一次计算但换来了路由判断的可靠性非常值得。4.7 混合链路的关键脱敏模板要极端简单最后说混合链路。这是很多团队都会走向的终极形态本地模型先做敏感信息识别和脱敏把代码里的真实变量名、业务名替换成占位符然后脱敏后的文本送云端做精修最后回到本地替换回来。这个链路听起来完美但我第一次实现的时候被脱敏-还原这件事折磨得够呛。核心教训是脱敏模板要极端简单不要搞复杂映射。我一开始设计了可逆加密脱敏方案替换之后还能加密还原结果云端模型在精修的时候把占位符也改了导致还原阶段全部错位。后来改成最简单的“UUID随机映射表”替换时生成一份映射字典云端只负责改代码逻辑不允许动占位符回来之后再按字典还原。虽然会有少量语义损失但稳定性和可解释性都远胜复杂方案。我的路由配置心得默认先问“数据会不会疼”项目跑到现在我形成一个比较顺手的路由配置模板分享给你。数据分级是路由的第一道阀门本地模型和云模型各自设定“擅长沙盒”本地负责密钥检测、脱敏、简单提取、批量处理云负责复杂重构、综合方案、长文档理解。两者之间用规则表联动规则表宁可少而准不要贪多。我个人在实际项目里的体会是路由设计最忌讳一步到位。不要一开始就想着把完美方案全做了而是先跑一个“L3强制本地L1全走云”的最小闭环观察流量分布、误杀率、延迟数据再逐步把L2的混合链路加进来。安全性和可用性的平衡不是设计出来的是一轮轮调出来的。最后再分享一个小技巧在路由网关里把每一次路由决策都打日志包括密级、能力评分、后端选择、延迟。出问题时先看路由日志不要急着去看模型输出。绝大多数Agent的“诡异行为”往下追两三级都能发现是路由层把请求送错了地方。