MiniMax推出Mavis，多Agent架构打造任务处理新标杆

我布置了一项任务，Agent随即进入规划模式，细致地列出了七个执行步骤。

我确认后，它便开始逐一执行，完成前三步后，它主动暂停并汇报：“1、2、3步骤已完成，具体成果如下……请问是否继续执行4、5、6、7步骤？”

我指示继续，它再接再厉，又完成了两步，再次停下：“4、5步骤已搞定，结果如下……是否推进6、7步骤？”

一整晚下来，让Agent处理长任务时，频繁的“继续”确认成了常态，长程效果大打折扣。

长期以来，我在使用各类Agent完成工作时，都遭遇了类似的体验。

这种体验显然不合逻辑。尽管“适时停下确认”是与AI协作的好习惯，但在许多任务中，我并未要求它停下，它却自行中断了。

MiniMax在其最新技术博客中，将Agent的这种行为归因于“上下文焦虑”。这主要是因为模型对于“何时才算完成超长任务”的判断模糊不清。简而言之，不是不会做，而是不敢做，每完成一步都担心出错，因此半途而废寻求确认。

今日，MiniMax Agent桌面端迎来了一次重大革新，新增了Mavis模式（即“MiniMax as a Jarvis”的缩写）。

让一个Agent担任领导，多个Agent作为员工——这种传统的多Agent架构已不新鲜。但MiniMax指出，以往的主流多Agent架构，实质上是通过提示词编排让模型进行“角色扮演”。然而，这种做法很快就会遇到上下文焦虑、长程任务能力退化、自检难题等瓶颈。

多Agent系统需要一套可靠的基础设施，确保持续运行、维护，且各Agent间不会相互干扰。这正是MiniMax正在努力的方向。

实测体验：让Agent相互“挑刺”

MiniMax将其Agent团队的基础设施命名为Team Engine，该引擎下设有三类核心角色：Leader、Worker、Verifier。顾名思义，分别负责管理、执行和验收。

关键在于，Worker与Verifier之间形成“对抗”关系，确保无法蒙混过关。

前段时间，徽声在线在研究一个课题：“所有对Coding/Agent有抱负的模型厂商，都需打造自己的独立Coding/Agent产品”。

（确实，MiniMax此前曾是个反面教材，但没想到文章未发，它已自我革新！）

于是，我们再次用这个课题在MiniMax的Agent团队上进行了测试。

任务被拆分为五个Worker执行，每个Worker完成后，都会将结果整理并提交给Leader（状态显示为“Mavis发给General”或“General发给Mavis”等）。

有一个Worker运行了12分钟仍未返回结果。徽声在线注意到，Leader等不及了，于是发送了一条bash命令检查其工作状态。

五个Worker全部完成后，Leader又生成了五个Verifier——在任务列表中显示为戴“小黄帽”的Agent。

Verifier迅速发现了错误！其中一个Verifier指出对应Worker的交付成果存在数据错误，给予“失败”评价。随即，对应的Worker重新启动（显示为运行中，带有蓝色小圈标识）。

进入对应Worker的工作区，观察其思考过程：“Verifier拒绝了我之前的交付成果，基于以下三个错误……我需要返回重新核查关键事实，并修正具体数字问题……”

不得不说，Agent之间的“铁面无私”让工作更加可靠。

在五组1v1的Agent对抗中，这种来回确认共发生了数十次。过程中，Mavis还表示“学到了新东西”，并更新了记忆。

上一个任务仍在运行，我们又开启了一个新的深度研究：基于权威数据，分析五一假期的旅游市场，并提交一份多维度分析报告。

这个研究比之前的任务更为复杂。由于需要持续对抗，Agent团队在深度研究上花费的时间远超单Agent。

但最终提交的报告，与其他AI深度研究的结果相比，确实更加干净、可信。

近期，徽声在线筹备了多场线下活动，策划方案一直是个难题。我们将这个任务交给了Mavis，看看效果如何。

我需要策划一场在广州举办的AI开发者线下沙龙，请尽可能全面地提供多个适合百人至千人科技活动的场地及报价，抓取同类活动信息，策划活动主题、宣传、运营等全部工作，并整理成一份严格的商业计划书格式，以及一个符合主题特色、设计精美的网页。

制定计划的时间比之前的深度研究任务还要长。Mavis回复：“这个任务规模庞大，需要多个Agent并行工作——场地调研、竞品抓取、主题策划、商业计划书、网页开发。”

Mavis的过人之处在于，我们还可以持续追加新需求：

在提交长报告的同时，最好还能起草一份初步的正式合同，包括与场地的合作、与邀请嘉宾的合作等可能涉及的合同，以及前期的财务表格，再提交一份用于汇报方案的PPT，越详细越好。

Agent团队收到新需求后，进一步完善计划并启动更多工作流，最终，我们启动了多达九个并行任务。

查看Mavis的思考过程，发现里面有大量Agent之间互相发送的消息。这些Agents在专门的Team Engine下工作，传递彼此状态，有的等待、有的执行、有的验证。

你看这个Verifier，像不像吹毛求疵的“甲方”？

最终，整个任务交付的文件数量惊人，达到十多个，包括xls、ppt、html网页以及对应的.md版本。

▲ Agent团队生成的财务预算表格，包括项目预算总表、现金流预测、票价和赞助定价模型，以及成本明细台账。

接下来，谈谈Mavis的另一大特性：能连接到聊天平台，支持多任务处理。

与MiniMax此前已支持的OpenClaw、Hermes Agent类似，Mavis也可通过微信、飞书等IM平台分配任务。接入流程极为简化，只需点击设置按钮、扫码、命名，即可在微信/飞书中使用Mavis。

一般的Agent产品连接到IM后，安排一项长时间任务后，往往无法再咨询其他问题。

部分原因在于这些Agent无法同时打开多个对话窗口；另一原因则是工作模式限制，在一个会话中运行多个任务极易导致语境错乱，上下文污染。

MiniMax的解决方案是将“秒回”与“执行”逻辑解耦。

在飞书中，我们让Mavis研究石油涨价情况；任务开始后，又让它研究最近一个月硅谷AI巨头发布的重要产品。

Mavis并未停止之前的任务，直接告知新任务已完成，而石油涨价的任务仍在处理中。

这正是Mavis的另一大设计理念：上下文隔离的优势。

每个Agent团队及其成员仅查看与自己任务相关的信息摘要，仅在需要细节时才阅读全文。

这样做一来控制了token成本，团队规模再大，上下文也不易撑爆；二来防止了上下文污染，Agent在搜索中接触到的错误信息不会影响整个团队。

在最极限的场景下，我们曾在飞书中短时间内给Mavis分配了八个任务，均未发生语境错乱的情况。

整个体验就像与一个认知带宽极高的同事共事：不仅能秒回信息，同时后台干活也不会被打断。想了解进度，直接询问即可，无需担心干扰其“心流”。

处理不同会话的Agent仅查看与自己任务相关的信息，不会共享不断膨胀的对话历史。

可以说，Mavis实现了从IM渠道到任务中枢，再到每个分子Agent的端到端上下文隔离。

最终，它在解答AI大厂本月新发布和具身智能重要产品的同时，也顺利完成了石油任务主线程，提交了一份详细报告，甚至提到了最近日本薯片包装将变为黑白的消息。

经过实测，你是否发现，Mavis的编排策略有点像此前流行的“三省六部”机制？

每个角色的任务、启动时机、交接方式均由引擎层面的状态机决定，而非模型黑箱自行决定。

简而言之，这是在多Agent工作编排中，用工程层面的可控性、严密性、确定性来根治模型的不可控、随机性。

这种思路彻底解决了过去Agent/模型“既当裁判又当选手”的经典问题。

额度统一，Agent充足

实测Mavis后，再谈谈MiniMax做的另一件同样重要的事情，影响所有付费用户：此次，Token Plan与Agent Plan合并了。

合并后，无论是普通用户的“日常使用”，如在官网和App中对话和使用Agent，还是接入官方API调用其他工具（如coding产品或OpenClaw/Hermes Agent），均可使用统一套餐额度。且无论是M2.7及后续旗舰模型，还是音乐、视频、语音等多模态模型，均包含在这一套餐内。

所有额度共享，用户可自行决定如何使用。MiniMax还提供福利：此前同时订阅两个方案的用户，将额外赠送一个月会员。

为何要这样做？从用户角度出发，其实很合理。

说白了，Agent时代，用户付费动机源于对“模型算力”的需求。随着模型在coding、agent、多模态能力上的提升，这些需求场景将愈发多元，自然发生在模型厂商的产品内（官网、独立产品、CLI）及产品外（接入外部API的独立部署Agent）。

这也是各大AI巨头面临的问题：OpenAI目前用户订阅与API计费仍分开，Anthropic亦然；至于更小的Agent创业公司，则用自己的订阅费用代替用户支付底层API费用。

此次，MiniMax率先拆除了产品矩阵内部的壁垒。徽声在线认为，在模型极度商品化、用户总涌向最新、最便宜模型API的今天，这种统一套餐策略反而有助于模型厂商维护用户忠诚度。

再回到产品本身。

如前所述，徽声在线正在撰写一篇关于“对coding/agent认真的模型厂商，必须打造自己的coding/agent产品”的文章。MiniMax虽迟但到。

今日，Mavis并非首个押注多Agent架构的产品。过去半年里，ChatGPT、Manus、Genspark等公司均加入了这场“多Agent”战争。

实测跑完后，徽声在线的感受是，Mavis在“产品自主完成极复杂/极长程任务”方面，表现优于同行，架构也更稳定。当其他产品的多Agent仍停留在提示词编排、拆任务层面时，Mavis已在工程层面实现了对抗式硬约束——这带来的体验差异显著。

然而，这套架构虽美好，也有绕不开的现实：成本高昂。

MiniMax在技术博客中提出了多Agent的“共识成本”(Cost of Consensus)。简而言之，几个Agent相互“制衡”虽使工作过程和结果更可靠，但取得共识的过程需付出成本，token消耗数倍于单一Agent；且如同吵架般，吵急眼了也可能偏离主题，准确率不升反降。

根据MiniMax梳理，其Agent团队架构具体有三类成本：

一是交接成本。信息在Agent间传递时需重新组织，每次交接均需将信息“翻译”为下一个Agent能用的形态，耗费token；

二是共享（上下文信息）成本。上下文隔离设计在一定程度上控制了这一成本。但即便每个Agent仅查看其他Agent传递的“摘要”，随着Agent团队规模扩大，存储和分发摘要也会带来成本；

三是聚合成本。徽声在线一直想强调：别以为那种拥有成百上千个skill、设计了极其复杂的“三省六部”制度的工作流就是终极解决方案——很多时候并非如此，反而可能落入token厂商的陷阱……你确实让工作变得更细致了，但同时也需要花费更多token去聚合和整理最终结果。

这些成本加起来意味着，多Agent并非“Agent越多越好”的简单逻辑。

但换个角度看：信息交互越复杂的工作，往往本身价值就越高。一份需多方核查、反复校验的深度研究报告与一个随手问的问题，或许不应以同一套逻辑衡量成本。Mavis虽贵，但贵在认真，而认真处理的任务本就值得这个价。

宁愿花费更多成本确保万无一失，也不愿糊弄了事，这才是复杂任务背后的高价值用户所看重的。

当然，MiniMax团队也进行了一些工程设计以避免程序冗余带来的token浪费。

MiniMax对用户的建议是：Agent团队是为“贵且复杂”的任务准备的，是一个策略选项，而非默认选项。用户需自行判断任务的复杂程度、链路长短、风险、经验复用价值——这些越高，越值得使用Agent团队。反之，则完全可以使用单Agent，甚至普通聊天。

多Agent一定更聪明吗？非也。但Mavis的意义在于，让那些真正复杂、知识密集型的任务，不依赖模型自行决定，而是交给一套经过验证的、有对抗、有核查、有权责划分和奖惩制度的工程系统。

它不一定让AI变得更聪明，但绝对会让AI更难偷懒——这也是大模型长期存在的难题。

毕竟，在真正的人际工作中，我们其实并不需要同事多聪明……只要不偷懒、不耍小聪明，往往就够了，不是吗？

文｜杜晨、张子豪