9 月 24 日，小米 MiMo 负责人罗福莉公布面向 MiMo-V3 的核心架构 HySparse2，明确的靶心是"下一代长上下文 Agent"。这则消息的份量，不在一个新模型的名字，而在于它揭示了行业正在发生的一次底层转向：当 Agent 成为大模型的主战场，模型架构本身开始被"Agent 真正的工作方式"重新设计。
聊天和 Agent，是两种工作负载
要理解 HySparse2 在解决什么，先得看清 Agent 和普通聊天到底哪里不同。普通对话里，模型面对的通常就是一段用户问题；而 Agent 在完成一项复杂任务时，需要反复搜索网页、读取文件、调用工具，再根据返回结果推进下一步。一条简单的工具调用，可能带回来一整份文档或大量执行日志；随着任务推进，模型还要保留此前的操作记录，并从越来越长的历史里找到"下一步真正需要的内容"。
这意味着，过去主要面向聊天场景设计的大模型架构，开始不适应新的负载了。上下文不再是"几轮对话"，而可能是一份数十页的报告、多个网页、会议记录、代码，以及一长串工具调用历史。谁能用更低成本保存和读取这些上下文，谁就直接决定了 Agent 的响应速度和使用成本。
HySparse2 做了什么
HySparse2 的思路很直接：减少模型反复"读材料"的计算量，同时压低保存历史信息所需要的缓存。在 80B-A3B MoE 模型、100 万 Token 上下文的测试中，相比 MiMo-V2.6 使用的 HybridSWA 架构，HySparse2 的长文本预填充计算量降至约 1/5，KV Cache 则从约 12GB 降至 2.7GB。
这两个数字意味着什么？预填充计算量降到五分之一，等于 Agent 每处理一轮长材料，算得更快、更省；KV Cache 从 12GB 砍到 2.7GB，则意味着同样长的历史，"记忆"占用的显存大幅缩水——这对需要在端侧或有限显存里跑长任务的场景尤其关键。稀疏激活机制与路径优化的组合，让模型在多轮对话、工具调用、复杂任务编排下，既降低推理耗时与算力消耗，又保持长上下文的稳定性。
小米自己的 Agent 探索已经在路上
架构不是孤立发布的，它对应着小米已经铺开的 Agent 产品尝试。今年 3 月，小米启动 Xiaomimiclaw 封测——基于 MiMo 大模型构建的 Agent 测试产品，最初让 Agent 直接调用手机应用、系统能力及米家设备；4 月进一步扩展到 PC 和 Mac，支持文档整理、数据分析和批量文件处理等桌面任务，并尝试手机、电脑和 IoT 设备之间的跨端协作。miclaw 已在 9 月 21 日结束近半年的封测。与此同时，HyperOS 4 计划上线"超级小爱专家模式"，把复杂任务规划、跨应用操作和"人车家"生态联动放进系统级入口。
从产品变化看，小米的 Agent 探索正在从一个独立测试产品，向操作系统和"人车家"生态内部延伸；而 HySparse2 透露的是另一层变化——在应用层寻找 Agent 入口的同时，小米已经开始按照 Agent 真正工作的方式，重新设计下一代 MiMo 模型。这也是小米继 MiMo-V2.6 登顶开源模型榜之后，在大模型架构层面的又一核心技术动作。
行业背景：Agent 正从"聊几句"变成"连续工作"
把视野拉宽，这股"为 Agent 重设计架构"的潮水不是小米一家在涌动。办公是最典型场景之一：今年以来，腾讯 WorkBuddy、百度搭子、阿里千问办公等产品陆续把 Agent 带入桌面，能力从"回答问题"延伸到读取本地文件、处理表格、制作文档、跨软件执行任务。当 Agent 从"聊几句话"变成连续工作几十分钟甚至更久，模型面对的就不再是一段问题，而是一堆需要被高效保存和检索的上下文。
此前的 MiMo-V2.6 已经展示了小米在"全模态 + 大规模 Live RL"上的工程能力；HySparse2 则把战线下探到更底层的注意力与缓存机制。两条线合起来看，国产大模型公司正在从"堆参数、拼跑分"，走向"围绕真实工作负载做系统级优化"的成熟阶段。
冷静判断：这是工程演进，不是魔法
需要划清边界：HySparse2 是架构层面的效率优化，不是某个"突然变聪明"的通用突破。2.7GB 的 KV Cache 在百万 Token 尺度下已经很省，但端侧设备要真正跑起这种长上下文 Agent，依然受限于显存、功耗和散热；而在云端，省下来的缓存也意味着可以塞下更长、更复杂的任务历史。换句话说，它降低的是门槛，不是消除门槛。
但方向足够清晰：当 Agent 成为模型能力落地的主战场，架构之争就从"谁能答得对"延伸到"谁能又长又省地干完活"。小米这一步，把"为 Agent 重构模型"从口号变成了可量化的工程指标——预填充 1/5、KV Cache 2.7GB，这两个数字会是对标者们接下来绕不开的参照线。