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基础设施命名为Team Engine，该引擎下设有三类核心角色：Leader、Worker、Verifier。顾名思义，分别负责管理、执行和验收。

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

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

（确实，MiniMax此前是个反面案例，但没想到文章还未发布，它就用实际行动证明了自己！）

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

任务被拆分为五个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 Team在深度研究上花费的时间远超一般单Agent。

但最终呈现的报告与其他AI深度研究交付的内容相比，更加干净、可信。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

简而言之，这是在多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 Team架构具体有三类成本：

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

二是共享（上下文信息的）成本。上下文隔离设计在一定程度上就是为了控制这一成本。但即便每个Agent只看其他Agent传递过来的“摘要”，随着Agent Team量级的扩大，存储和分发摘要都会带来成本。

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

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

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

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

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

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

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

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

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

文｜杜晨、张子豪