MiniMax 把旗下 Agent 升级为 Agent Team，并取名 Mavis（MiniMax as a Jarvis）。这次升级讲的故事，不是「模型又强了」，而是「单个智能体为什么不够用」。官方在说明里直言：当任务变长、变复杂，单智能体既是选手又是裁判，会系统地出问题——答着答着停了、越跑越偏、自己审自己还显得很自信。Agent Team 的解法，是把一个人扛所有事的单智能体，拆成有前店后厂、有验收、有记忆的一支队伍。
单智能体长任务里的三类失稳
MiniMax 总结的三类失稳，其实很多重度用户都撞过。其一是中途停滞：单智能体跑长任务时，常常在用户没命令的地方停住，等用户一句「继续」才动，体验像在带一个容易走神的下属。其二是逐步漂移：前面定好的目标，跑到后面被带偏，且一旦偏了，后续全跟着偏。其三是自审自判：单智能体自己写稿、自己校验、自己打分，既是运动员又是裁判员，缺少真正独立的把关。这三点不是提示词没写好，而是「单一主体包揽全流程」这个结构本身带出来的。
增量认知：过去我们习惯把长任务失败归咎于「模型不够强」，MiniMax 把这口锅换了个位置：问题在结构。当同一个智能体既生产又验收，漂移和停滞几乎是必然的；要破局，得把生产、校验、记忆拆给不同角色，而不是指望一个更聪明的单体。
这个判断和同期不少多智能体研究相互印证：长程、稀疏依赖的任务适合多角色协作，而紧密耦合的顺序流程，强行拆团队反而增加开销。换句话说，Agent Team 不是银弹，它针对的是「长且杂」那一类任务，对「短且顺」的活，单智能体仍更划算。
前店后厂：拆任务、并行跑、做验收
Agent Team 的运作方式是：用户只发一条消息，主 Agent 先确认目标，再把任务拆成若干角色并行推进——调研的调研、写作的写作、校验的校验，结果汇总回主 Agent。关键点有两个。一是验收机制：不是谁先说完谁算数，而是有专门的校验角色把关，缓解「自己审自己」的盲区。二是跨会话记忆：这次踩的坑、这次验证过的结论，下次还能用，避免同一个错误反复犯。
对用户来说，体验上的差别很具体。过去单智能体写完一长篇，你不知道它哪段是编的、哪段是查的；Agent Team 让主 Agent 先回一句「收到，我这么拆、后台跑」，把「黑盒」变成「有分工的车间」。用户不必盯着每一步，但可以知道活被分给了谁、谁来验收、经验有没有留下。
团队化的代价与适用边界
团队化不是免费午餐。拆角色、并行跑、做验收，每一步都吃 token、吃时延、吃协调成本。MiniMax 自己也承认，对短平快的任务，单智能体更合适；Agent Team 的甜区在「长、复杂、要多人视角」的工作，比如长文撰写、跨源调研、带多步交付的项目。这也提醒使用者：别因为有了团队就什么都丢给团队，先判断任务是不是真的需要多角色。
边界提醒：「多智能体更聪明」是个容易误导的直觉。MiniMax 的案例说明，团队化的收益来自分工与制衡，而非角色数量本身；若任务紧密耦合、依赖顺序强，拆太多角色只会增加协调损耗与成本。选不选 Agent Team，看任务结构，不看热度。
Mavis 这次升级，给行业递了一个清醒的样本：长任务智能体的瓶颈，未必在单模型能力，而在「选手兼裁判」的结构缺陷。把生产、校验、记忆拆开，让一支队伍代替一个全能个体，是多智能体走向可用的关键一步。至于它能不能扛住真实长任务的考验，还要看跨会话记忆与验收机制在复杂场景下的稳定性。