本地大模型能接 WorkBuddy 干活吗？Ollama 免费方案的分工边界

 

同一家 40 人的设计公司，IT 负责人和财务负责人对"AI 办公预算"吵了一周：IT 列出的方案是 Ollama 加本地模型，零订阅费、数据不出公司电脑；财务拿到报价单却直摇头，说云端 AI 订阅一年一个人头好几百，全员上本地不是更省？第三个人事主管插了一句：员工说本地模型"慢得离谱还老出错"。三方各执一词的根源，是没人说清一件事：本地 3B/4B 小模型接进 WorkBuddy 这类 Agent 工作台后，哪些活干得了、哪些活干不了。把这条分工边界画清楚，免费方案才能真落地，而不是落地即翻车。

 

先搞懂 WorkBuddy 的重 harness：你敲一行字，模型收到一整包

 

WorkBuddy 接飞书、钉钉靠的是连接器（Connector）加 MCP 协议：连接器是插头，MCP 是插座标准，授权之后模型就能按需调用平台上的工具和内容。但插上插头不代表模型能可靠干活，问题出在 Agent 工作台的重 harness 架构上。WorkBuddy 策略产品经理在工程复盘里把一次调用抽象成一个公式：输出等于模型处理系统提示词、工具、会话历史、其他上下文加用户指令的总和。这意味着你敲一行"帮我读这份飞书文档"，模型实际收到的是七层隐形包裹：系统提示词（岗位说明书加能力地图加权限边界）、三层记忆（云端记忆、用户级本地记忆、工作区记忆）、全部工具和技能的 Schema 定义、模式片段、专家人设、项目信息、会话历史。前六层你都没手写，全是 harness 自动拼装。

 

最容易被忽视的是工具 Schema 的常驻开销。通用 Agent 工程共识是一个工具定义约 100 到 300 token，不调用也占上下文；15 个工具就是 1500 到 4500 token，30 个工具可达 3000 到 8000 token。WorkBuddy 接入了 60 多个连接器与 100 多个技能，哪怕只做一件小事，这一整片 Schema 也常驻。这套包裹对所有 Agent 软件都存在，不是 WorkBuddy 独有——豆包、千问的云端产品同样有，只是它们用 200B 以上的云端大模型扛，你感觉不到。

 

本地 3B/4B 为什么慢、为什么翻车

 

把七层包裹全部交给本地 3B/4B 模型，会出现三类失配。第一类是每轮重读整包上下文：Agent 是循环结构，每一步都把系统提示、记忆、全部工具 Schema、历史重新喂给模型，4B 模型读一长串规则再决策，天然比裸推理慢。第二类是有效上下文窗口小：量化 8B 模型经 Ollama 干净运行通常只到 4096 token，推到 8192 注意力质量就明显下降，上下文越长算力成本近似平方上升，延迟从毫秒级跳到秒级。第三类是工具调用可靠性差：4B 模型从三五个工具里选远比从全套里选可靠，漏调工具、生成畸形 JSON、编造参数的概率明显更高；实测里 B390 显卡配 4B 模型跑"联网搜最新新闻"，慢（整包重读）加旧（工具调用失败后退回记忆编旧闻），双重翻车。

 

拿豆包千问对比要诚实：它们不是"更好"，而是"你根本没得选"。豆包千问是付费云端服务，只跑云端大模型，不支持接入你的本地模型，所以"小模型扛不动重 harness"这个故障在它们身上不发生；代价是付费或免费额度加限流，且数据上云。豆包自身也有上下文瓶颈：官方最长 32768 token，接近上限延迟明显上升；第三方实测有效窗口约 3200 token，超限自动截断首部。WorkBuddy 的特殊之处在于通过自定义模型接口可以接 Ollama（地址填 127.0.0.1:11434/v1），让你既有本地免费模型可用，又能随时切云端模型，选择权在自己手里。

 

分工边界：本地承包八成，云端留给两成

 

本地 3B/4B 的甜区清单：写周报、改邮件、润色中英文文案；读本地 PDF、Word、Excel 文档，提炼要点、总结会议纪要；把表格数据写成文字说明、做简单数据归类；写不太复杂的代码（一段处理 Excel 的 Python、一个 SQL 查询）；简单翻译改写续写。这些任务的共同点是单步、私密、重复——不限额、不排队、免费、数据不出本机。前提条件也要记住：单步任务、不挂专家团、不调复杂技能链、连接器操作保留人工确认。

 

必须交给云端的清单：联网搜最新信息（本地小模型不可靠）；飞书钉钉多步自动化编排（技能链长，小模型易失手）；专家团深度分析（上下文膨胀）；复杂推理和超长文档精准分析。一句话概括：本地模型是自己家的 WiFi，免费不限量随时用，但带宽有限跑不了大型游戏；云端模型是 5G 套餐，速度快功能全，但要付费有额度。正确姿势是本地承包八成常规私密办公，云端只用在需要新鲜和复杂的那两成——而且腾讯混元旗舰模型当前免费，也要省着用，别把稀缺云端额度浪费在"帮我改个错别字"上。

 

三步接入和四条减负建议

 

接入流程三步。头一步装 Ollama 并下载模型：核显、AMD 或 CPU 用户执行 ollama pull qwen3.5:4b-q4_K_M，NVIDIA 用户执行 ollama pull qwen3.5:4b-nvfp4。接着一步在 WorkBuddy 添加自定义模型：设置、模型、添加模型、自定义，API 地址填 http://127.0.0.1:11434/v1，选刚下载的模型名保存。末一步授权连接器：以飞书为例，连接器页面搜索飞书、按 OAuth 流程登录、按需勾选权限，回对话直接说"帮我读这份飞书文档的摘要"即可。隐私边界要讲清：Ollama 本身不联网，数据不离开你的电脑；但接了飞书钉钉连接器后，相关指令和数据会按对应平台的正常流程在平台间传输，这和直接用豆包千问办公一样，使用前留意平台隐私条款。

 

让本地小模型跑得更稳的四条减负建议。其一，减少工具数量：只连接真正需要的三到五个连接器，别全开，每少一个工具省约 100 到 300 token 的 Schema 开销。其二，不用专家团：单任务用单一模型，避免上下文成倍膨胀。其三，单步任务：把复杂任务拆成多个简单对话，每轮只做一个动作，降低工具调用失败率。其四，缩短对话历史：每轮对话控制在三到五轮内，过长任务另起一轮。复杂活儿明确交给云端模型，既避免本地翻车，也不浪费本地模型的免费额度。

 

零成本方案的真实边界在哪儿，现在可以给出行动判断了：如果你所在的公司对数据出域高度敏感（设计稿、合同、客户数据），本地模型承包日常八成文书工作是完全可行的省钱路径，值得本周就装 Ollama 试一轮；如果你的核心诉求是联网情报、多步编排这类重活，那免费的本地方案不是替代品，是搭配云端使用的分工方案——按这个边界配置，才不会出现"免费的用不起、付费的白花钱"的错配局面。

 

周报、纪要、文书这些私密重复的活儿交给本地免费模型承包，联网搜索、多步编排留给云端旗舰——这是 WorkBuddy 自定义模型接口交付的成本结构优化，订阅费和隐私风险同时可控。云巴巴（yun88.com）作为腾讯云AI智能体示范伙伴、WorkBuddy核心伙伴，已为多家企业梳理过本地模型与云端模型的分工配置方案，Ollama 环境搭建、模型选型、连接器权限最小化清单均有现成实施模板，官网留言或联系我们即可获取适配你公司数据敏感度的配置建议。