本地模型这个话题这两年从“玩具”变成了“生产力工具”的分水岭其实就发生在最近一年。我最早在本地跑模型纯粹是为了断网环境下也能有个能对话的东西那时候7B模型答个稍微绕一点的问题就开始胡言乱语上下文一长就失忆。但现在情况完全不一样了本地模型配合Agent、CLI工具链、skills体系已经能撑起一套相当完整的自动化工作流。这篇文章我想聊的不是“怎么装一个本地模型”这种入门话题而是把我在实际项目里摸出来的边界感讲清楚——哪些事本地模型能干得漂亮哪些事它天生干不了以及围绕Agent、CLI、skills、harness这些概念怎么搭出一套真正能用的东西。1. 本地模型到底解决了什么问题又卡在哪里1.1 从“能跑”到“能用”的那条线很多人对本地模型的第一印象是“免费”和“隐私”这两个确实是最直接的驱动力。但真正让我把本地模型纳入日常工作流的是延迟可控和调用无上限这两点。云端API你调一次要等网络往返批量处理的时候还要考虑配额和费用而本地模型一旦加载进显存推理速度就只取决于你的硬件想跑多少轮就跑多少轮。但“能跑”和“能用”之间有一条很明显的线。我自己的判断标准是这样的如果一个任务需要模型在单轮对话内完成明确指令本地模型基本没问题如果任务需要多轮推理、工具调用、长上下文记忆那就要看模型规模和量化精度了。7B级别的模型在量化到4bit之后做简单的文本分类、信息抽取、格式转换很稳但一旦涉及多步逻辑推理错误率会明显上升。这里有个很实际的例子。我做过一个本地文档问答的小工具用7B模型做检索后的答案生成。单看每个回答语句通顺、格式正确但把十个回答连起来看会发现它在不同轮次里对同一个概念给出了互相矛盾的解释。这就是小模型的典型问题没有稳定的世界观它的输出高度依赖当前上下文的局部模式而不是一个连贯的知识体系。1.2 显存、量化与上下文长度的三角关系本地模型部署最核心的约束就是显存。我整理了一个实际测试下来的对照表方便你快速判断自己的硬件能撑到什么程度模型规模量化方式显存占用约可用上下文实际体验7BQ4_K_M5-6GB8K日常问答流畅长文吃力7BQ8_08-9GB8K质量提升有限显存翻倍13BQ4_K_M9-10GB8K推理能力明显好于7B32BQ4_K_M20-22GB16K接近可用生产力70BQ4_K_M40GB32K需要多卡或大显存这张表里最关键的信息不是数字本身而是量化精度对推理能力的影响是非线性的。Q4到Q8的质量提升在7B模型上几乎感知不到但在32B以上模型上就能明显感觉到逻辑连贯性的差异。所以我的建议是优先堆模型规模而不是堆量化精度。同样16GB显存跑13B的Q4比跑7B的Q8要划算得多。上下文长度是另一个容易被忽视的坑。很多人看到模型标称支持128K上下文就以为可以随便塞但实际上有效上下文和标称上下文是两回事。我实测下来7B模型在超过4K token之后对开头内容的注意力就明显衰减了到8K基本就是“看了但没记住”。32B模型在16K以内还能保持较好的召回再长就开始丢信息。所以如果你要做长文档处理要么上更大模型要么做分段摘要再汇总别指望小模型能一口气吃下整本书。1.3 本地向量模型被低估的检索基石聊本地模型大部分人关注的是生成模型但本地向量模型其实是整个本地AI栈里最实用、最稳定的一环。原因很简单向量模型的任务是固定的——把文本映射到语义空间这个任务对模型规模的要求远低于生成任务。一个几百MB的向量模型在语义相似度任务上的表现可以非常接近大模型。我在本地知识库项目里用的是BGE系列的中文向量模型配合简单的余弦相似度检索效果比很多云端方案还稳。因为向量模型不需要推理能力它只需要表征能力而表征能力在小模型上已经做得相当好了。这意味着你可以在完全离线的环境下搭出一套“向量检索本地生成”的完整问答系统而且响应速度极快。这里有个实操细节向量模型的归一化很重要。如果你自己算相似度记得先对向量做L2归一化然后用点积代替余弦相似度计算量能省一半。很多框架默认帮你做了但如果你手写检索逻辑这一步漏了会导致相似度排序完全乱掉。2. Agent与CLI本地模型真正发挥价值的地方2.1 Agent不是“更聪明的对话”而是“能动手的执行者”Agent这个词现在被用得很泛但它的核心定义其实很清晰Agent是一个能感知环境、做出决策、执行动作的循环系统。和普通对话模型最大的区别在于Agent的输出不是给用户看的文本而是给系统执行的指令。这个区别决定了本地模型在Agent场景下的定位。对话场景里模型输出质量差一点用户还能自己脑补修正但Agent场景里模型输出一个错误的工具调用参数整个流程就直接崩了。所以本地模型做Agent对模型能力的要求比做对话高得多。我自己的经验是7B模型做Agent基本不可用它会在工具选择上反复横跳或者在参数格式上出错。13B模型勉强能跑简单的单工具Agent但一旦工具数量超过三个选择准确率就掉得厉害。32B模型是我认为的Agent可用门槛它能稳定地做工具选择、参数填充和多步规划。但这里有个反直觉的结论本地模型做Agent瓶颈往往不在模型本身而在harness的设计。harness这个词最近很热它指的是包裹在模型外面的那层工程框架——负责解析模型输出、执行工具调用、管理上下文、处理错误重试。一个好的harness能让13B模型跑出接近32B的效果而一个差的harness会让70B模型也频繁翻车。2.2 CLI是Agent最自然的交互界面为什么CLI在Agent场景里这么重要因为命令行天然就是结构化的。一个CLI工具接受明确的参数、返回明确的输出这正好匹配Agent“决策-执行-观察”的循环。相比之下GUI界面的信息密度低、状态隐式Agent很难从中提取有效的反馈信号。我实际用下来codex cli这类工具的设计思路很值得借鉴。它把模型能力封装成一系列命令每个命令有明确的输入输出契约。Agent只需要决定“调用哪个命令、传什么参数”剩下的交给CLI去执行。这种分层设计的好处是模型不需要理解底层实现只需要理解命令的语义。这里有个实操建议如果你要自己搭AgentCLI的流程命令的粒度要设计得恰到好处。太粗模型不知道怎么填参数太细模型要在大量命令里做选择准确率会下降。我的经验是单个Agent的工具集控制在5-8个命令比较合适每个命令的参数不超过4个且参数类型尽量用枚举而不是自由文本。2.3 skills体系把领域知识从模型里剥离出来skills这个概念最近在Agent圈子里很火它的本质是把特定领域的操作知识从模型权重里剥离出来变成可插拔的模块。这个思路对本地模型尤其重要因为本地模型的参数量有限不可能把所有领域知识都塞进去。我理解skills的方式是这样的模型负责“通用推理”skills负责“领域操作”。比如你要做一个代码审查的Agent模型不需要知道你们团队的代码规范它只需要知道“调用代码规范检查skill把结果整合成审查意见”。规范本身写在skill里可以随时更新不用重新训练模型。这种架构对本地模型的意义在于它把模型的能力需求从“全知”降到了“会调度”。一个32B模型如果配上设计良好的skills在特定领域的表现可以超过没有skills的70B模型。因为领域知识的准确性由skill保证模型只需要做它擅长的语义理解和流程编排。我在实际项目里踩过一个坑skills的描述文本非常关键。模型是根据skill的描述来决定要不要调用的如果描述写得含糊模型就会在多个skill之间犹豫或者干脆不调用。我后来把每个skill的描述都改成“当用户需要做X时使用此skill输入是Y输出是Z”这种格式调用准确率立刻上了一个台阶。3. harness工程决定本地Agent成败的隐形层3.1 harness和Agent的区别以及为什么它更重要很多人把harness和Agent混为一谈但这两个东西的职责完全不同。Agent是决策逻辑harness是执行环境。Agent决定“做什么”harness负责“怎么做到”。我打个比方Agent像是一个项目经理harness像是他手下的执行团队和办公系统。项目经理再聪明如果执行团队不给力、办公系统天天出bug项目照样做不成。反过来一个普通的项目经理配上一个高效的执行团队也能把事办得不错。harness具体要处理哪些事我列一下我在项目里实际遇到的输出解析模型返回的是自然语言harness要从中提取出结构化的工具调用指令参数校验模型填的参数可能类型不对、格式不对harness要在执行前拦截错误重试工具调用失败时harness要决定是重试、换工具还是报错上下文管理多轮工具调用后上下文会膨胀harness要做压缩和裁剪状态追踪记录每一步的执行结果供后续决策参考这些事情听起来琐碎但每一件做不好都会导致Agent流程崩溃。我见过太多人把精力全花在调模型上结果harness写得一塌糊涂最后怪模型不行。实际上在本地模型场景下harness的优化空间比模型本身大得多。3.2 输出解析本地模型最容易翻车的地方本地模型在输出结构化内容时稳定性远不如大模型。大模型经过大量指令微调能很好地遵循“请用JSON格式输出”这类要求但本地小模型经常会加一些额外的解释文字或者JSON格式有细微错误。我的解决方案是多层解析第一层用正则提取可能的JSON块第二层用宽松的JSON解析器能容忍尾逗号、单引号等第三层如果还失败就把原始输出喂回模型让它修正。这个三层机制把解析成功率从60%左右提到了95%以上。还有一个技巧是在prompt里给示例。不要只说“输出JSON”而是给一个完整的输入输出示例。本地模型对示例的模仿能力很强给了示例之后格式错误率会大幅下降。这个技巧在skills调用场景下尤其有效因为skill的输入输出格式是固定的给一个示例就能让模型稳定遵循。3.3 上下文压缩让本地模型跑长流程的关键本地模型的上下文窗口有限但Agent流程往往需要多轮工具调用上下文会迅速膨胀。如果不做压缩跑到第五六轮的时候模型就已经“忘记”最初的目标了。我试过几种压缩策略最后稳定下来的是分层摘要把早期的工具调用结果压缩成一句话摘要保留最近的完整结果。具体做法是当上下文超过阈值时把最老的一批消息交给模型做摘要然后用摘要替换原始消息。这里有个细节摘要要保留关键实体和数值。我一开始让模型自由摘要结果它把重要的ID和参数都省略了导致后续调用找不到目标。后来我改成结构化摘要模板强制保留“操作类型、目标对象、关键结果”三个字段问题就解决了。另一个策略是外部记忆。把工具调用的完整结果存到外部存储上下文里只保留结果的引用和摘要。需要详细信息时Agent可以主动去查。这种方式对本地模型特别友好因为它把上下文压力转移到了外部系统。4. 本地模型的边界哪些事真的做不了4.1 需要世界知识的任务本地模型最大的硬伤是知识覆盖度。一个7B或13B的模型训练数据量有限很多领域知识它根本没有。你问它某个具体产品的API用法它可能会编一个看起来很像但完全错误的答案。这个问题的严重性在于模型不知道自己不知道。它会用非常自信的语气给出错误信息这在Agent场景下是致命的。我的应对方式是所有需要事实性知识的环节都走外部检索不让模型凭记忆回答。模型只负责理解问题、组织检索query、整合检索结果不负责提供事实。4.2 需要精确计算的任务本地模型做数学计算的能力很弱即使是32B模型做多位数乘法也经常出错。这不是模型大小的问题而是Transformer架构本身不擅长精确计算。大模型之所以看起来会算数是因为它们见过大量计算示例能模式匹配出结果但一旦数字超出训练分布就会出错。我的做法是所有计算都交给工具。模型只负责把自然语言问题转成计算表达式实际计算由代码执行。这个原则在Agent设计里非常重要——模型做它擅长的语义理解工具做它擅长的精确执行。4.3 需要最新信息的任务本地模型的知识截止于训练时间之后发生的事情它一概不知。这个边界很清晰但实际使用中容易被忽略。比如你问它“最新的XX框架怎么用”它可能会给你一个过时的答案而且不告诉你这是过时的。解决方案还是检索增强。把最新信息通过检索注入上下文让模型基于检索结果回答。但这里有个坑本地模型对上下文的利用率不高如果检索结果太长它可能只用了开头部分。所以检索结果的排序和截断很重要要把最相关的信息放在最前面并且控制总长度。5. 一套可落地的本地Agent工作流5.1 硬件与模型选型基于我自己的实践给一个务实的配置建议场景推荐配置模型选择说明个人学习16GB显存13B Q4能跑Agent但复杂任务吃力小团队工具24GB显存32B Q4Agent可用门槛推荐生产环境48GB显存70B Q4或多卡接近云端体验如果显存不够可以考虑CPUGPU混合推理但速度会慢很多只适合对延迟不敏感的场景。另外内存也很关键模型加载时需要把权重读进内存再传到显存内存不足会导致加载失败。5.2 工具链搭建顺序我建议的搭建顺序是先向量检索再CLI工具最后Agent编排。这个顺序的原因是每一步都能独立验证不会因为后面的问题导致前面也跑不起来。第一步搭本地向量检索。选一个中文效果好的向量模型把文档切块、向量化、存进本地向量库。这一步做完你就有了一个能用的本地知识库。第二步封装CLI工具。把常用的操作封装成命令行工具每个工具输入输出明确。这一步做完你就有了Agent的“手”。第三步接Agent框架。把向量检索和CLI工具注册成Agent的skill让模型来调度。这一步做完整个流程就闭环了。5.3 实测中的意外情况我在实际跑这套流程时遇到过几个意料之外的问题分享出来帮你避坑第一个是模型加载顺序。如果你同时加载生成模型和向量模型显存分配会互相挤占。我的做法是先加载向量模型它小再加载生成模型并且给生成模型留足显存余量。第二个是CLI工具的权限。Agent调用CLI工具时如果工具需要文件系统权限或网络权限要提前配好否则会在运行时突然失败。我建议在开发阶段就给足权限上线前再收紧。第三个是上下文里的工具结果格式。工具返回的结果如果格式不统一模型理解起来会很吃力。我后来强制所有工具返回JSON格式并且在harness里做统一包装模型的理解准确率明显提升。6. 关于本地模型边界的一些个人体会本地模型的能力边界本质上是由参数量、训练数据、架构三者共同决定的。参数量决定了它能容纳多少知识训练数据决定了它见过什么架构决定了它擅长什么类型的任务。这三个因素里参数量是最难突破的因为它直接对应硬件成本。但边界不等于限制。我在实际项目里最大的体会是本地模型的价值不在于它自己能做多少而在于它能调度多少。一个32B的本地模型配上好的harness和skills能完成的任务远超它单独的能力。这就像一个人个人能力有限但如果会用工具、会协作能做成的事就大得多。另一个体会是本地模型的“慢”反而是一种优势。云端API响应太快你来不及思考就得到了答案容易跳过验证环节。本地模型推理慢你有时间去看它的推理过程去判断它的输出是否合理。这种“慢”在需要严谨性的场景下反而是好事。最后说一个很实际的点不要追求本地模型完全替代云端。我现在的做法是混合使用——简单任务、隐私敏感任务、批量任务走本地复杂推理、需要最新知识的任务走云端。这种混合模式比单纯依赖任何一方都更稳。本地模型的意义不是取代谁而是在特定场景下提供一种可控、可预期、可离线运行的选项。这个选项在很多时候比“最强模型”更有价值。