小米 MiMo-V2.6-Pro 上线 WorkBuddy：1M 上下文 + 多智能体，这波升级到底能干什么

小米技术今天宣布，Xiaomi MiMo-V2.6-Pro 正式上线 WorkBuddy。这是小米自研大模型第一次以「主力可选模型」的身份进入办公智能体平台，最扎眼的两个参数是：支持 1M 超长上下文，以及多智能体分工协作。

1M 上下文意味着什么

简单算一下：1M token 大约相当于 150 万中文汉字，或者三四个 300 页的 PDF。此前主流办公助手通常卡在 128K～200K 区间，一份长财报加几个附件就爆上下文了，模型只能靠「摘要 – 丢失 – 再摘要」的方式接力，越接越糊。

放到实际场景里，1M 上下文带来的变化有三个：

• 整本资料一次喂完：不用再手动拆章节、拼摘要，直接丢一本说明书或整套合同进去。
• 全局一致性：写长文、改长代码时不会前后矛盾，因为模型一直「记得」开头怎么定的调子。
• 跨文档比对：把三个版本的需求文档同时放进去，让它逐条列差异，这在法律和审计场景里很实用。

多智能体分工，和单模型有什么区别

多智能体不是把一个问题丢给几个模型投票，而是把一件事拆成角色：规划者、检索者、写作、审校。WorkBuddy 里接入 MiMo-V2.6-Pro 之后，可以按任务把子角色分下去，主智能体负责汇总。

好处是每个子角色上下文更短、目标更单一，出错不容易一路传下去；代价是 token 消耗成倍增长，以及调度逻辑一旦设计不好，就会出现「互相踢皮球」——你让它写方案，它开了五个子智能体先开个会。

值得关注的几个点

1. 真实可用的上下限：宣称 1M 和「1M 里准确率不衰减」是两回事，长上下文普遍存在中段遗忘（lost in the middle），实际建议重要信息放头尾。
2. 成本：长上下文是按 token 计费的，一次投喂 80 万 token 的账单会比你想的肉疼，处理长文档建议先做结构化预处理。
3. 和国产同类的对比：同一天还有 DeepSeek、GLM 的新版本在灰度，长上下文已经是国产模型的标配竞争点，比的是「同长度下的准确率」而不是「能塞多长」。

对普通用户来说，最实际的建议是：把 MiMo-V2.6-Pro 当成处理长材料的工具，短任务用不着上这么重的模型；对开发者来说，多智能体编排能力比上下文长度更值得试，因为它决定了你能把多大的一件事交给它。