MiniMax推出Mavis智能体架构解析

给AI助手下达一个长任务，它开启了规划模式，列出了七个步骤。批准之后，它开始执行，跑了三步，然后停下来汇报：“已完成步骤一、二、三，结果分别是这些……请问是否继续四、五、六、七？”

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

回答继续。它又跑了两步，再次停下：“已完成步骤四、五，结果如下……请问是否继续六、七？”

一个晚上下来，本想让它处理些长线工作，结果对话框里来来回回全是“继续”的确认。很长一段时间里，使用各类智能体（Agent）的体验，大抵如此。

这种体验多少有些不合逻辑。虽然“中途确认”是与AI协作时的一个好习惯，但在许多任务中，用户并未主动要求暂停，它却自行中断了。MiniMax在最新的技术博客中将智能体产品的这种行为归因于“上下文焦虑”。核心问题在于，模型自身对于“超长任务何时才算完成”的判断是模糊的。简而言之，不是能力不足，而是信心不足——每完成一步都担心出错，所以干到一半就要停下来请示。

近期，MiniMax的智能体桌面端完成了一次重要更新，引入了一个名为Ma vis的新模式（实为“MiniMax as a Jarvis”的缩写）。

要知道，让一个智能体当老板，一组智能体当员工——这种传统的多智能体框架已不新鲜。但MiniMax指出，此前主流的多智能体框架，本质上仍是依靠提示词编排让模型进行“角色扮演”。这种做法难以持久，很快就会遇到前述的上下文焦虑、长程任务退化、自我检查等难题。

一个可靠的多智能体系统，需要一套能够持续运行、持续维护，且智能体之间不会“相互媾和”的基础设施。这正是MiniMax正在构建的。

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

MiniMax为其智能体团队基础设施命名为Team Engine（团队引擎），引擎下管理着三类核心角色：领导者（Leader）、工作者（Worker）、验证者（Verifier）。顾名思义，分别负责管理、执行与验收。

最关键的不同在于，工作者与验证者之间是“对抗”关系，谁也别想蒙混过关。

此前，我们正好在研究一个课题：“所有在编程/智能体领域有抱负的模型厂商，都必须推出自己的独立编程/智能体产品”。（没错，MiniMax此前曾是一个反面案例，但没想到文章还没发布，它就用行动证明了自己。）

于是，我们再次将这个课题交给MiniMax的智能体团队来执行。

该任务被拆分给5个工作者。每个工作者完成后，都会将结果整理交给领导者（在界面上显示为“Ma vis发给General”或“General发给Ma vis”等状态）。

其中一位工作者运行了12分钟仍未返回结果。我们注意到，领导者等不及了，发出了一条bash命令来检查其工作状态。

待5位工作者全部完成后，领导者又生成了5个验证者——在任务列表中显示为头戴“小黄帽”的智能体。

验证者很快发现了错误！其中一位验证者找到了对应工作者交付成果中的明确数据错误，给出了“失败”的判定。紧接着，对应的工作者被重新启动（显示为运行中，伴有蓝色圆圈标识）。

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

不得不说，智能体之间“铁面无私”，工作起来确实可靠。

这样的来回拉锯，在五组一对一的智能体对抗中，总共发生了数十次。过程中，Ma vis还表示“学到了新东西”，并顺手更新了记忆。

让上一个任务继续运行，我们再开启一项新的深度研究：基于权威数据口径分析五一假期的旅游市场，并交付一份多维度分析报告。

这项研究比刚才的任务更为复杂。而且由于需要持续对抗，智能体团队在深度研究上花费的时间，也远超一般的单智能体。

但最终呈现的报告，与其他AI深度研究交付的内容相比，确实干净不少，可信度也更高。

最近我们筹备多场线下活动，策划方案一直是难题。我们也把这个任务交给Ma vis试试效果。

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

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

Ma vis的过人之处还在于，我们可以持续追加新需求：在提供长报告的同时，最好还能起草初步的正式合同（涉及场地合作、嘉宾邀请等可能涉及的合同），以及前期的财务表格，再提供一份用于汇报方案的PPT，越详细越好。

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

点开Ma vis的思考过程，能看到大量智能体之间互相发送的消息。这些智能体在专门的Team Engine下工作，传递彼此状态，有的在等待、有的在执行、有的在验证。

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

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

智能体团队生成的财务预算表格，涵盖了项目预算总表、现金流预测、票价与赞助定价模型，以及成本明细台账。

连接与并行：像与高带宽同事共事

接下来谈谈Ma vis的另一大特性：能连接到聊天平台，且支持多任务并行。

与MiniMax此前已支持的OpenClaw、Hermes Agent类似，Ma vis本身也可以通过微信、飞书这两个即时通讯（IM）渠道来分配任务。接入流程也极度简化，只需点击设置按钮、扫码、命名，即可在微信或飞书中使用Ma vis。

一般的智能体产品连接到IM后，如果分配一项需要长时间完成的任务，往往在消息发送后，就无法再咨询其他问题。部分原因在于这些智能体无法同时打开多个对话窗口；另一个原因则是其工作模式的限制——在单一会话中运行多个任务极易出现语境错乱，导致上下文污染。

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

我们在飞书里让它研究近期石油涨价；任务开始后，又让它研究最近一个月硅谷AI巨头发布的重要产品。Ma vis没有停止之前的任务，直接告知新任务已接收，而石油涨价的任务仍在后台处理。

这正是Ma vis的另一大设计理念：上下文隔离带来的好处。

每个智能体团队，以及团队中的每个智能体，都只看到与自己任务相关的信息摘要，仅在需要细节时才会去读取全文。这样做一来控制了token成本，团队规模再大，上下文也不易撑爆；二来防止了上下文污染，智能体在搜索中接触到的错误信息不会导致全队“阵亡”。在最极限的测试中，我们尝试通过飞书在极短时间内分配8个任务，均未发生语境错乱。

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

处理不同会话的智能体，只看到与自己任务相关的信息，不会共享一个不断膨胀的对话历史。可以说，Ma vis实现了从IM渠道，到任务中枢，再到子任务中每个分子智能体——端到端的上下文隔离。

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

经过实测，你是否发现Ma vis这套编排策略，有点像此前火过一阵的“三省六部”技能？每个角色做什么，何时启动、何时交接，将由引擎层面的状态机来决定，而非模型在黑箱中自行“拍脑门”。说白了，这就是在多智能体工作编排中，用工程层面的可控性、严密性、确定性，来根治模型的不可控与随机性。这种思路，彻底解决了过去智能体/模型“既当裁判又当选手”的经典问题。

额度统一，智能体管够

实测Ma vis之后，再来谈谈MiniMax所做的另一件同样重要、影响所有付费用户的事：此次更新中，Token套餐与智能体套餐合并了。

合并之后，无论是普通用户的“日常使用”（如在官网和App内对话、使用智能体），还是通过官方API调用其他工具（例如编程产品或OpenClaw/Hermes Agent），现在都可以使用统一的套餐额度。并且，无论是M2.7及后续的旗舰模型，还是音乐、视频、语音等多模态模型，全部包含在这一套餐之下。所有额度共享，如何花费由用户自己决定。MiniMax还给出福利：此前同时订阅两个方案的用户，将额外获赠一个月会员。

为何要做这件事？从用户视角看其实很合理。在智能体时代，用户的付费动机源于对“模型算力”的需求，而这些需求场景随着模型在编程、智能体、多模态能力上的提升，只会愈发多元，自然会发生在模型厂商的产品内（官网、独立产品、命令行界面）以及产品外（接入外部API的独立部署智能体）。这其实也是各大AI巨头都在面对的问题：OpenAI目前用户订阅和API计费仍是分开的，Anthropic同样；至于更小的智能体创业公司，则是用自己的订阅费用来替用户支付底层API费用。

这一次，MiniMax率先拆掉了自己产品矩阵内部的墙。我们认为，在模型极度商品化、用户总是一窝蜂涌向最新、最便宜模型API的今天，这种统一套餐的策略，反而有助于模型厂商维护用户忠诚度。

成本与价值：多智能体并非“越多越好”

再回到产品本身。如前所述，我们正在撰写关于“对编程/智能体认真的模型厂商，必须要做自己的编程/智能体产品”的文章。MiniMax可以说是虽迟但到。在今天，Ma vis也不是第一个押注多智能体架构的产品。过去半年里，ChatGPT、Manus、Genspark等公司都参与了这场“多智能体”的竞争。

而在实际测试后，我们的感受是，Ma vis在“独立完成一个极复杂/极长程任务”这件事上，比同行效果更好、架构也更稳定。当其他产品的多智能体仍停留在提示词编排、任务拆分层面时，Ma vis做出了工程层面的对抗式硬约束——这带来的体验差异，足够明显。

不过，这套架构看似美好，也有绕不开的现实：成本高昂。

MiniMax在技术博客中提出了多智能体的“共识成本”。用人话说，几个智能体彼此“制衡”，的确让工作过程和结果更靠谱，但取得共识的过程是有代价的，token消耗数倍于单一智能体；而且就像吵架一样，吵急了也有可能偏离主题，导致准确率不升反降。

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

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

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

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

这些成本加起来，意味着多智能体从来不是“越多智能体越好”的简单逻辑。

但换个角度看：信息交互越复杂的工作，其本身价值往往就越高。一份需要多方核查、反复校验的深度研究报告，和一个随手可答的问题，或许就不应该用同一套逻辑去衡量成本。Ma vis贵，贵在它认真，而认真处理的那些任务，本就值得这个价。宁愿花更多成本确保万无一失，也不愿糊弄了事，这才是复杂任务背后高价值用户所看重的。

当然，MiniMax团队也做了一些工程设计来避免程序冗余带来的token浪费。MiniMax对用户的建议是：智能体团队是为“昂贵且复杂”的任务准备的，是一个策略选项，而非默认选项。用户需自行判断任务的复杂程度、链路长短、风险、经验复用的价值——这些越高，越值得使用智能体团队。反之，完全可以用单智能体，甚至普通的聊天模式。

多智能体一定更聪明吗？未必。但Ma vis的意义在于，让那些真正复杂、知识密集型的任务，不再交给模型自己“拍脑门”，而是交给一套经过验证的、有对抗、有核查、有权责划分和奖惩制度的工程系统。它不一定让AI变得更聪明，但绝对会让AI更难偷懒——这也是大模型本身长期存在的老大难问题。毕竟在真实的人际协作中，我们其实并不总是需要同事多聪明……只要不偷懒、不耍小聪明，往往就已经足够了，不是吗？