MiniMax 推出了 Mavis，活脱脱的 Agent「三省六部」

我下了一个任务，agent 开启了 plan 模式，规划了 7 个步骤。

我批准了，它开始跑，跑了三个步骤，然后停下来汇报：「我已经完成了 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 框架，其实本质上就是靠提示词编排来让模型玩「角色扮演」role play。但这种做法撑不了多久，就会遇到包括前面提到的上下文焦虑、长程任务退化、自检等难题。

多 Agent 系统，需要一套持续运行、持续维护，并且多个 agent 之间不会「媾和」的可靠基础设施。这就是 MiniMax 在做的事。

实测体验：让 agent 给对方「挑刺」

MiniMax 给它的 Agent Team 基础设施起的名字叫做 Team Engine，引擎下面挂着三类核心角色：Leader、Worker、Verifier。顾名思义，一类做管理，一类干活，一类验收。

最关键的差异在于，Worker 和 Verifier 之间是「对抗」的关系，谁也没法蒙混过关。

前段时间，APPSO 正好在研究一个课题：「所有对 Coding/Agent 有所抱负的模型厂商，都要做自己的独立 Coding/Agent 产品」。

（没错，MiniMax 在此之前是个反面案例，但没想到文章还没发出来，就已经证明自己了！）

于是我们又用这个课题再在 MiniMax 的 Agent Team 上跑了一次。

这个任务拆分出了 5 个 worker，每个 worker 完成任务后，都会整理结果交给 leader（显示状态「Mavis 发给 General」或者「General 发给 Mavis」等等。）

有一个 worker，运行了 12 分钟还没有返回结果。APPSO 注意到，这个 leader 等不及了，于是发了一条 bash 命令检查其工作状态：

在 5 个 worker 都完成后，leader 又生成了 5 个 verifier ——在任务列表中显示为带着「小黄帽」的 agent：

Verifier 很快就找到了错误！其中一个 verifier 发现了对应的 worker 交付成果中存在明确的数据错误，给出了「失败」的判罚。紧接着，与之对应的 worker 重新启动（显示为运行中，会有一个蓝色小圈的标识）。

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

还别说，agent 跟 agent 之间「铁面无私」，工作起来真的可靠。

这样的来来回回，在五组 1v1 的 agent 对抗当中，总共发生了数十次。过程中，Mavis 还表示这次「学到了新东西」，并顺手更新了一下记忆。

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

这个研究比刚才的任务更加复杂。而且因为要持续对抗，Agent Team 在深度研究上所花的时间，也远比一般的单 Agent 要长。

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

最近 APPSO 筹备了很多场线下活动，做策划想方案一直是个难题。我们也把这个任务交给 Mavis 看看效果怎么样。

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

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

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

给我长报告的同时，最好还能给我起草一份初步的正式合同，和场地的合作、以及和邀请嘉宾的合作、等等可能涉及的合同，还有前期的财务表格，再给我一份用来汇报这套方案的 PPT，越详细越好。

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

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

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

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

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

接下来再说一下这次 Mavis 的另一大特性：能连接到聊天平台，还支持多任务。

和 MiniMax 此前已经支持的 OpenClaw、Hermes Agent 类似，Mavis 本身也可以通过微信、飞书这两个 IM 管道来实现任务分配。接入流程也极度简化，只要点击设置按钮、扫码、命名，我们就能在微信 / 飞书里面使用 Mavis 了。

一般的 Agent 产品连接到 IM 当中里，我们给他安排一项需要长时间完成的任务，往往是消息发送之后，就不能再和他咨询别的问题。

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

MiniMax 的解决方案，是把「秒回」和「执行」的逻辑解耦。

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

Mavis 没有停止之前的任务，直接告诉我新任务已经完成了，而石油涨价的任务还在处理。

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

每个 Agent Team，以及 team 里的每个 agent，都只看到跟自己任务相关的信息摘要，只有需要细节的时候才会去读全文。

这么做一来 token 成本受控，团队规模再大，上下文也不容易撑爆；二来防上下文污染，agent 在搜索中接触到的错误信息不会让全队阵亡。

在最极限的场景下，我们试过通过飞书在极短时间内给他分配 8 个任务，都没有发生语境错乱的情况。

整个体验，很像跟一个认知带宽极高的同事共事：不仅能秒回信息、同时后台干活也不会被打断。想了解一下进度，大可直接问，不用担心干扰它的「心流」。

处理不同会话的 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 先一步把自己产品矩阵内部的墙拆掉了。而 APPSO 认为，在模型极度商品化、用户总是一窝蜂涌向最新、最便宜模型 API 的今天，这种统一套餐的策略，反而有助于为模型厂商维护用户忠诚度。

再回到产品本身。

如前所述，APPSO 正在写一篇关于「对 coding/agent 认真的模型厂商，必须要做自己的 coding/agent 产品」的文章。MiniMax 可以说是虽迟但到。

在今天，Mavis 也不是第一个押注多 agent 架构的产品。在过去半年里，ChatGPT、Manus、Genspark 等公司都参与到这场「多 agent」的战争当中。

而在实测跑完之后，APPSO 的感受是，Mavis 在「产品自己跑完一个极复杂 / 极长程任务」这件事上，做的比同行效果更好、架构也更稳定。当其它产品的多 agent 停留在提示词编排、拆任务上的时候，Mavis 做出了工程层面的对抗式硬约束——这带来的体感差异，足够明显。

不过，这套架构看起来美好，也有绕不开的现实：贵。

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

根据 MiniMax 梳理，其 Agent Team 架构具体来说有三类成本：

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

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

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

这些成本加起来，意味着多 agent 这件事从来不是「越多 agent 越好」的简单逻辑。

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

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

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

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

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

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

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

文｜杜晨、张子豪