豆包工作开始“调度”多模型

豆包工作今天接入了 Kimi K3.1 Pro、GLM 5.3 和 DeepSeek V4.1 Flash，用户不再只能使用豆包 2.1 Lite、豆包 2.1 Pro 两款自研模型，还能根据任务复杂度、响应速度和额度成本手动“换脑”。

这次更新表面上是模型选择器多了三个名字，实际意义却更大：企业 Agent 正在从绑定单一基座模型的应用，变成负责选择、组合和管理不同模型的调度平台。

豆包工作同时上线了额度消耗倍率、分时优惠和“自动（小额免费）”模式。简单任务仍可由系统自动匹配模型并免费完成，复杂任务则允许用户切换至专业模型，按照界面显示的倍率消耗额度。豆包 2.1 Lite 和 DeepSeek V4.1 Flash 的倍率还被限时下调，明显是在争夺高频、轻量任务。(m.ithome.com)

一次更新，补齐模型、计费和权限三块拼图

多模型 Agent 是能够在同一个任务入口中调用两种或以上基础模型，并按照任务类型、成本或性能选择执行模型的智能体产品。

豆包工作不是在 11 月 12 日才开始尝试多模型，而是分两步推进。

第一步发生在 10 月 29 日，第三方模型服务率先向团队订阅版和企业订阅版开放。企业不需要分别向月之暗面、智谱或 DeepSeek 采购服务，也不用让员工维护多套账号，模型消耗统一从已有 AI 点数中扣除。管理员还可以按成员、部门、群组或全员划定模型权限，决定谁能用、能用哪一个。(ithome.com)

第二步是今天的更新：第三方模型进入更广泛用户的模型列表，额度消耗倍率被直接展示在选择界面，限时优惠也同步上线。

这两步分别解决了企业使用多模型时最现实的两个问题：

1. **模型怎么接入和管理。**企业不再为每家模型厂商单独走采购、账号和权限流程。
2. **模型怎么计费和选择。**用户可以在执行任务之前看到不同模型的额度成本，而不是任务跑完后才发现预算消耗过快。

这比单纯增加一个模型下拉菜单更重要。企业真正需要的从来不是“模型越多越好”，而是把模型能力放进统一的权限、审计和成本体系。

三款第三方模型，不是简单的能力堆叠

模型组合的价值，是让不同能力和成本曲线的模型承接不同任务，而不是让所有模型重复完成同一件事。

从现有定位看，豆包工作接入的三款第三方模型并不处在完全相同的档位。

| 模型 | 更适合的任务方向 | 主要优势 | 使用时应注意的问题 | |---|---|---|---| | DeepSeek V4.1 Flash | 高频分析、代码检查、资料整理、轻量 Agent 任务 | 强调速度和推理效率，豆包工作此次还下调了其额度消耗倍率 | 复杂长程任务不能只看单次响应速度，还要看总轮次和返工率 | | Kimi K3.1 Pro | 长文档、金融研究、复杂表格、长程工具调用 | 支持 100 万 token 上下文，长程 Agent 和办公任务表现突出 | 高能力模型通常意味着更高的额度消耗，需要控制调用范围 | | GLM 5.3 | 复杂工程、代码、安全分析和多步骤任务 | 强化长程工程任务与 Agent 执行能力 | 实际办公效果仍取决于工具适配、提示词和任务拆解质量 | | 豆包 2.1 Lite | 日常问答、改写、摘要、简单办公任务 | 轻量、低成本，并参与此次倍率优惠 | 不适合把所有复杂工作都压在轻量模型上 | | 豆包 2.1 Pro | 飞书上下文相关的复杂办公任务 | 与豆包工作、飞书权限及工具体系结合更直接 | 面对特定专业任务，未必始终优于第三方模型 |

Kimi K3.1 Pro 是其中定位最高的一款。公开信息显示，该模型支持 100 万 token 上下文，在 Terminal-Bench 4.0 上取得 65.7%，在 OfficeQA Pro v2 和 SpreadsheetBench v2 上分别取得 64.4 和 36.3，重点强化代码、金融研究、表格和长程 Agent 任务。(ithome.com)

DeepSeek V4.1 Flash 更值得关注的则是效率路线。其技术报告显示，通过跨层 KV Cache 复用、FP4 KV Cache 等设计，单 token 的全局 KV Cache 占用降至 890 字节，约为 DeepSeek V4 Flash 的四分之一。对长上下文 Agent 来说，缓存占用降低不只是论文指标，它直接关系到推理吞吐量、并发能力和平台最终能给出的价格。(arxiv.org)

GLM 5.3 的角色介于两者之间，更偏向复杂工程和长程执行。公开资料显示，其相对上一代 GLM 5.2 的性能提升达到 50%，重点覆盖代码审查、漏洞发现和复杂工程任务。(ithome.com)

换句话说，豆包工作现在拥有了一套相对清晰的模型梯队：轻量任务交给 Lite 或 Flash，复杂通用任务交给 Pro，长上下文和专业工作可以切换 Kimi 或 GLM。

但模型聚合，还不能直接等同于自动路由

模型路由是系统根据任务内容、模型能力、响应延迟和调用成本，自动选择执行模型的调度机制。

需要泼一点冷水：豆包工作已经具备多模型入口，但目前还不能确认它已经实现了覆盖复杂任务的完整自动路由。

此次公开信息显示，“自动（小额免费）”模式会根据任务规模匹配模型；当任务复杂度提高时，用户仍需要手动切换至豆包 2.1 Pro 或第三方模型。也就是说，自动调度目前至少明确覆盖简单小额任务，但专业模型之间如何选择，主要决定权仍在用户手里。(m.ithome.com)

真正成熟的多模型路由，至少要同时完成四个判断：

• **能力判断：**任务是长文档分析、代码执行、视觉理解，还是普通改写？
• **成本判断：**更强的模型能否通过减少返工和工具调用次数，抵消更高的单次价格？
• **延迟判断：**用户是在等待一句答案，还是允许 Agent 在后台运行半小时？
• **风险判断：**任务是否包含企业敏感数据，所选模型和工具是否具备相应权限？

例如，一份包含 30 个附件的行业研究报告，看起来应该交给支持超长上下文的模型。但如果模型一次读入所有文件后生成大量无关内容，最终成本可能比“轻量模型先筛选材料、强模型再写核心结论”的两阶段方案更高。

因此，多模型路由不是“挑一个最强模型”，而是像云计算调度器一样，把不同计算资源放到最合适的环节。豆包工作今天迈出的是第一步：先让模型可选、价格可见，再逐步把选择过程自动化。

额度倍率，比模型名单更值得关注

额度消耗倍率是平台将不同模型的实际资源成本换算成统一账户额度的计价系数。

豆包工作没有让用户直接面对每百万 token 输入、输出价格，而是把底层成本转换为更容易理解的额度倍率。倍率越低，同等任务消耗的账户额度越少；倍率越高，意味着模型能力或运行成本通常更高。

这种设计对普通用户更友好，但也隐藏了一个问题：同一个任务没有完全固定的 token 消耗，倍率也不等于最终任务成本。

一个倍率较高但能一次完成任务的模型，可能比需要反复修改五次的低倍率模型更便宜。相反，用旗舰模型批量改写 200 个商品标题，即使质量略高，也可能是明显的资源浪费。

更合理的比较方式不是只看倍率，而是看“成功交付一个任务需要多少额度”。这个指标至少包括：

• 首次生成消耗的额度；
• 工具调用和联网检索消耗；
• 用户要求修改的次数；
• 任务失败或中断后的重试成本；
• Agent 运行时产生的上下文累积。

豆包工作把倍率直接放进模型选择界面，依然是正确方向。过去模型成本藏在后台，用户只能凭“这个模型听起来更强”做选择；现在成本第一次成为产品交互的一部分。

限时下调豆包 2.1 Lite 和 DeepSeek V4.1 Flash 的倍率，也说明字节正在主动引导流量分层：高频任务尽量进入低成本模型，只有高难度任务才消耗昂贵模型的算力。这与云服务中的冷热分层存储很像——不是所有数据都需要放在最贵的介质上，也不是所有办公任务都值得调用旗舰模型。

企业买的不是模型，而是统一控制面

企业 AI 控制面是集中管理模型、人员权限、数据范围、额度和审计记录的后台系统。

企业部署 Agent 最麻烦的部分，通常不是员工不会提问，而是模型使用逐渐失控：有人处理合同，有人分析客户数据，有人把整个内部文档库交给一个未经审批的模型，财务部门还要面对多个供应商的账单。

豆包工作的优势在于，它已经把模型选择放入现有企业管理框架。管理员可以按成员、部门和群组配置权限，并把不同模型的消耗统一计入 AI 点数。对于飞书客户来说，豆包工作还能继承企业知识、文档、会议和聊天记录的权限边界，同时保留操作审计与数据隔离。(ithome.com)

这意味着第三方模型在豆包工作中不只是一个聊天窗口，而是被装进了企业的“权限笼子”。

这也是办公 Agent 与通用模型网站的核心差异。通用模型解决“谁回答得更好”，企业 Agent 解决的是“谁能读什么、谁可以调用什么工具、这次任务花了多少钱、出了问题能否追溯”。

从商业角度看，模型厂商可能会逐渐退到能力供应层，Agent 平台则掌握用户入口、任务上下文、计费关系和模型分发权。谁能决定一个任务最终流向豆包、Kimi、GLM 还是 DeepSeek，谁就掌握了模型时代类似应用商店推荐位的权力。

国内办公 Agent 已经集体转向多模型

办公 Agent 的竞争正在从“我有什么自研模型”，转向“我能否稳定调度行业里最合适的模型”。

豆包工作不是最早走多模型路线的产品。腾讯 WorkBuddy 已接入混元、DeepSeek、GLM 和 Kimi 等模型，并在 10 月 24 日加入 Kimi K3.1 Pro；千问办公也早在 8 月上线 GLM 5.3 和 DeepSeek V4 Pro。(ithome.com)

| 产品 | 已公开的多模型能力 | 当前特点 | 关键挑战 | |---|---|---|---| | 豆包工作 | 豆包 2.1 Lite/Pro，加上 Kimi K3.1 Pro、GLM 5.3、DeepSeek V4.1 Flash | 飞书上下文、统一 AI 点数、倍率展示和企业权限 | 需要证明复杂任务下的自动路由效果 | | 腾讯 WorkBuddy | 混元、DeepSeek、GLM、Kimi 等 | 多模型布局较早，腾讯办公生态入口丰富 | 模型、专家和技能增多后，调度逻辑会更复杂 | | 千问办公 | Qwen 系列，同时开放 GLM 5.3、DeepSeek V4 Pro 等前沿模型 | 阿里模型与企业办公体系结合紧密 | 需要平衡自研模型分发与第三方能力 |

因此，“千问办公仍只坚持自研模型”的说法已经过时。至少从 2026 年 8 月开始，千问办公就已允许用户直接选择 GLM 5.3 和 DeepSeek V4 Pro。现在的行业共识不是要不要接第三方模型，而是接入以后如何管理、如何计费、如何路由。

多模型也会带来新的工程问题

模型可替换性是指同一 Agent 工作流能够在不破坏任务结果的前提下切换不同基础模型。

现实中，这件事远没有切换下拉菜单那么简单。

第一，不同模型对提示词的理解并不完全一致。同一套任务模板，在一个模型上可能稳定输出表格，换到另一个模型后可能加入大量解释文字。

第二，不同模型的工具调用习惯不同。有的模型倾向先规划再调用工具，有的模型会频繁搜索和验证；即使单次价格便宜，过多的调用轮次也会推高总成本。

第三，模型版本会持续更新。平台今天测试通过的工作流，可能在模型升级后出现输出结构变化、工具参数变化或拒答边界变化。

第四，企业需要知道数据流向哪里。统一入口降低了使用门槛，但不等于所有模型在数据保留、训练使用、日志审计和地域合规方面完全相同。

所以，接入模型数量只能算基础能力。真正有壁垒的是持续评测系统：平台需要用真实办公任务测试每个模型的成功率、耗时、总 token、工具调用次数和人工返工率，再决定如何路由。

结论：模型正在变成 Agent 的可替换零件

豆包工作此次更新的真正价值，不是多了三款模型，而是把模型能力变成了可选择、可计价、可管控的企业资源。

对个人用户来说，这意味着处理长文档、代码、调研和表格时多了几个更专业的选项；对企业来说，更重要的是不必为每个模型重新建设采购、权限和用量体系。

但豆包工作距离真正成熟的自动模型路由还有距离。当前的“自动（小额免费）”更像轻量任务分流器，复杂任务仍主要依靠用户理解模型差异并手动选择。

下一阶段的竞争不会是谁接入的模型最多，而是谁能回答三个更难的问题：同一个任务该用哪个模型，什么时候应该切换模型，以及如何在任务成功率不下降的情况下减少额度消耗。

当这些选择逐渐从用户手里转移到 Agent 系统内部，基础模型就会越来越像云计算里的 CPU、GPU 和存储实例：开发者和企业仍然关心性能，但最终购买的是一个能把任务稳定完成的系统，而不是某个模型的名字。

参考来源

• IT之家：豆包工作接入 DeepSeek V4.1 Flash、Kimi K3.1 Pro 等第三方模型——11 月 12 日产品更新、额度倍率与限时优惠信息。
• IT之家：豆包工作向企业客户推出第三方模型服务——10 月 29 日企业版开放范围、权限配置与统一点数说明。
• IT之家：千问办公上线 GLM 5.3 和 DeepSeek V4 Pro——用于核对国内办公 Agent 的多模型竞争情况。
• IT之家：腾讯 WorkBuddy 接入 Kimi K3.1 Pro——包含上下文长度及 Agent、办公任务基准数据。
• Hugging Face：DeepSeek V4.1 Flash 模型页面——DeepSeek 官方开放权重与模型资料。