从单打独斗到团队协作，AI Agent的进化远比想象中更早到来。当大部分玩家仍在打磨一个“更听话”的智能体时，MiniMax悄然交出了一份关于“组织架构”的答卷。这背后不仅仅是代码层面的分工，或许预示着人机协作关系的一次底层重构。
这一切的起点，源于一次略带慵懒的实验。给Mavis丢下一个“做一个HTML专题页”的模糊指令后，便午睡去了。醒来后发现，它竟自行运转了28分钟，最终交付的不仅是一个功能完整的页面，更意外开启了硅基生物的“职场”体验——它自己组建了团队。
Mavis，这个名字本身就带有隐喻（MiniMax as a Jarvis）。但相比钢铁侠的全能管家，它更像是引入了一套层级分明的管理系统：Leader负责战略拆解，Worker负责执行落地，Verifier负责质量把控。当一个目标被分解后，你会发现，用户不再需要化身提示词工程师，去反复纠正每一个细节；只需要像CEO一样，对负责人交代一句即可。
Mavis，MiniMax as a Jarvis。
有意思的名字。想了解一下，但有点懒，不太想看技术blog。正好最近不是流行用AI做HTML吗，我就给它丢了这么一个任务：基于Mavis的blog，做一个能放进文章展示的HTML专题页。对，就这么一句话，没咋认真想prompt。
然后趁它在思考，我去午睡了。想着睡醒再给feedback。结果我起来，打开一看，发现它竟然回了一句：
完成了。
不是？？从收到Prompt到交付，完全没停，一口气跑了整整28分钟。
真就交付的HTML，图文并茂能交互的那种。不过，我一瞟侧边栏，不对劲。怎么冒出来这么多对话框？？我记得我就开了一个啊？？？
点进去看才发现，原来这都是Mavis自己组的团队。它们一直在内部交流、开会、分配任务……说真的，这一下，终于体会到了当老板的感觉。使唤人太爽了。更别说使唤这么多人，还可以让Mavis唱红脸，帮我PUA。
从技术层面看，这种架构本质上是对“长程任务”痛点的精准打击。过去，单Agent模式下，用户要面对三大崩溃：频繁请示“继续”、随着上下文增长而逐渐“变笨”、以及后台静默带来的焦虑。这并非模型能力不足，而是架构层面的先天缺陷——单Agent既要当运动员，又要当裁判，还无法有效隔离不同任务段的上下文干扰。
这是MiniMax全新的Agent产品。严谨点说，是一群Agent。
说实话，我自己都觉得最开始给的这个prompt，有点「不负责任」。只给了一个目标，没有给每一步的具体指令。如果按照正常的习惯，我一般会跟AI反复沟通很多次，精研细琢，最后让它生成一份完整的Plan。但出乎意料的是，这次真就One Take，啥额外的指示都没有给，最后就拿到结果了。
我去看了看博客，发现其中的秘诀在于Agent Team。啥是Agent Team？
其实就是团队分工，Mavis这有三个角色：Leader负责统筹全局，Worker负责具体执行，Verifier负责验收质量。比如这个叫Mavis的，就是Leader，它是我的第一话事人，会指挥其他Agent干活。
没想到啊没想到，硅基生物也玩起「上下级」这一套了。
这样最大的一个好处就是，用户只需要「会跟负责人说话」，不需要是提示词工程师。中间的拆解、分工、迭代，全部交给Agent Team自己搞定。首先是Leader收到任务，然后做任务拆解，把一个大目标拆成若干子任务。接着，每个子任务分配给不同角色的Agent牛马。我这个任务用到了3个Worker。一个负责内容创作，一个负责设计，一个程序员负责生成HTML。
中间呢，还会有个叫Verifier的介入验收。从事实准确性、页面可读性、代码可运行性……这几个角度入手监督，并最终生成验收报告。
下面就是验收时间！带大家简单看看，我的Mavis最终做出来的HTML专题页。仔细看，竟然还是星尘背景的，有粒子动效。
Mavis自己开盒自己的工作流，以这种step时间线的方式呈现，中间这条线还是脉冲的。
还有个使用场景界面，真帮我大忙了，如果用文字方式呈现的话，不知道得写多长。大家自己看吧，哪些任务适合Agent Team做。
说实话，如果单Agent来做这件事，我大概要说十几次「继续」，还得在过程中反复纠错。但现在这些全被Agent Team内部消化了。效果好是一方面，另一方面，看它们自己叽里咕噜工作还挺有意思。像角色扮演一样，相当有情绪价值了。主要让我的Leader，PUA其他Agent，真有点爽。
你是一个高级前端开发。今天早上你交付了一个index-v2.html，现在被老板骂得狗血淋头。
原话：这个什么破页面？做完你自己照着截个图看看，好意思说是科技公司产品专题页？配色暗沉得像上世纪的财务软件，动画只有一个脉冲点在那里……
（ps：这不是我的原话啊！污蔑，明明是它自己想的！！）
最后回到大家最关心的问题——价格咋样啊？
毕竟听到多Agent工作流，第一反应肯定是：这得多贵？Token无限流咱可遭不住啊。当然了，多Agent肯定比单Agent的Token消耗大。这没办法，就跟用HTML替代Markdown一样，好的体验就是要付费的，也正常。但我觉得，最关键的，还是在于实际效果如何。如果效果好，能节省时间，也赚了。而且MiniMax这次也挺实在。TokenPlan和Agent Plan，合并了。
一份订阅，CLI、API、Agent全打通，M2.7、音乐、视频、语音所有模型都包含在内。Credits额度在Agent和API之间共享，一份钱干两份事。之前同时订阅了两个Plan的用户，额外赠送一个月会员。
之所以这么兴奋，是因为这真是困扰我许久的使用痛点。
崩溃一：Agent总偷懒。你让AI写一篇报告，它写了3段就停下来——「我已经完成了1/2/3，需要继续吗？」像听不懂话一样！！你说继续，它又停。再说继续，又停。一个晚上下来，你有一半时间在打「继续」「继续」「继续」…… 崩溃二：长任务越跑越笨。一开始它像个聪明助手，跑着跑着，变成了你在带一个很忙但容易分心的人。你得不断追问——刚才那条要求还记得吗？你为什么又把研究任务写成产品营销了？ 崩溃三：冷暴力……在微信/飞书里给AI发消息，要么30秒丢一个浅答案，要么你盯着对话框等10分钟没任何反馈。「不是，你咋不回我了，干到哪了啊？？」这是我经常在IM跟小龙虾发的高频词。这三个场景，应该所有重度AI用户都经历过。
所以，长程任务到底难在哪？这次MiniMax在技术博客中，也给出了答案。
简单来说，这就是单Agent出生就带着的“魔咒”。主要还是上下文的问题。首先，单Agent有上下文焦虑。这其实是个很深层的话题。对于超长任务的训练本身需要投入大量的金钱、时间成本和算法优化，大家没那么多资源向这块倾斜。这就导致，模型对于「超长任务什么时候该停」的判断，普遍是模糊的。它不知道一个任务什么时候算「做完」，所以一直怕做错，怕给Token干崩了，干一半就停下问。这就像让一个很谨慎的实习生做事，每完成一步都要请示一下。关键是，即便说像不要钱一样，疯狂灌上下文，效果也并不好。这在目前是无解的。底层注意力的问题，随着上下文越来越长，Agent会从一个聪明助手变成了一个容易走神的人。只能随时压缩上下文。但这肯定会丢掉一些信息，而且很容易让用户焦虑。更麻烦的是，单Agent很难形成自我制衡。它可能很真诚地自检，但检查的仍然是自己刚刚构造出来的东西。毕竟，又当选手又当裁判，做得对不对确实很难评判。最后的最后，还有一个很现实的问题——单Agent没法快速响应长程任务。你甚至就没法跟它做长程的事。因为它一旦干起活来，不太好通过IM跟它交流。长任务和当前对话绑在同一个上下文里，如果放任新消息进来，容易干扰原来的任务。但如果不引导，又只能干等着。这就很尴尬。
归根结底，这些不是模型能力问题。是架构问题。所以回到Mavis，它们的Agent Team其实就是冲着这个架构来的。思路很直接：一个主Agent牵头，Leader、Worker、Verifier三类角色分工合作。这里有一个关键的设计——Worker和Verifier之间是对抗关系。Worker停止的条件是Verifier启动的原因，Verifier停止的条件是尽可能发现Worker的问题，而发现的问题又成为Worker重新启动的原因。类似企业里研发和质量部门的关系，通过多轮对抗式迭代，交付高质量的结果。不需要CEO（也就是你）事无巨细地介入。
而这个底层，是一个状态机，叫做Team Engine。什么时候该验证、什么时候该重试、什么时候该停止……都是引擎层面的硬性约束，不靠模型自由发挥。这样，协作关系也不再被限制为一次函数调用，而是变成主动推送、按需查询的多轮交互。最后，再说一个我觉得很酷的设计：Agent与人类同权。用户可以对Agent进行prompt、spawn、abort、kill这些操作，Agent自己也有能力对另一个Agent做同样的事情。真正操作Agent的渠道可以是用户、其他Agent或Team Engine。走的是同一套协议。谁做了什么、有没有越权，都可以审计追溯。当然，涉及到高风险的节点，还是得human in the loop。
那把这些事情做完后，能实现什么效果？就是彻底解决掉上面提到的三个崩溃。1、不再停下来问你。 Leader统筹全局目标，Worker只管执行子任务，停止条件由Team Engine控制，不再是模型自己模糊地判断「够了吗」。 2、不再越跑越笨。 每个Worker上下文隔离，查资料的不会被写代码的信息污染。Verifier用独立视角审查，不是自己检查自己。 3、IM再不会不回消息。 （ps：记得要先给权限）主Agent先秒回确认收到，具体任务拆到后台并行执行，关键节点主动汇报。你甚至可以中途加需求：「我刚想到一个新方向，巴拉巴拉……你顺便帮我查一下。」主Agent可以马上回：「好的，我现在再开启一组Agent研究，有新的进展随时汇报。顺便和你交代一下，已经在执行的任务中完成了2/5，剩下的有2个在核查，还有1个在跑。」说真的，这个体验，太省心了……像极了一个飞书时刻在线的同事，完全不需要加急。
以前我们总在琢磨怎么把一个Agent「养」成超人。希望它更聪明、更全能，什么都能干。但有时候我也会想，Agent的能力或许天生就是有限的，AI从来没有电影里那么全知全能。既然如此，其实也不该给单个Agent太大的压力。这也是Mavis这次给我的最大感触。除了模型本身的升级，Agent架构的更新，其实也能带来巨大的体验提升。而且把目光放回眼前，比起一个遥不可及的AGI，我们的确更迫切地需要适配于实际应用场景的Harness。但这也意味着，人机交互另一方的我们，也得相应地改变自己的工作习惯和思考方式。你现在不是在跟一个AI聊天。你在管理一个团队。多Agent时代，每个人都要学着去担任那个更高的角色。MiniMax的设计也指向这个方向。在他们的设想里，后续Agent产品会让人类更多通过管理面板去配置Agent角色、能力和边界，分配任务。此时真正重要的能力，就不止是单纯地写提示词了。
最后，咱还是现实点，说回「经济性」。在算力不够用的当下，每个Token都有实实在在的价格标签，token消耗和效果是个无法规避的trade off。其实，MiniMax在blog里也有一段专门讲这件事——他们没有回避多Agent「贵」。交接要成本，共享要成本，聚合也要成本……当然。但问题是，研究Agent收来几十个网页，交接给写作Agent的时候，信息需要被重新组织——很难。这些不是「模型再大一点」就能解决的。有些事情，就是得上多Agent才能解决的。所以，MiniMax的思路一直是实用优先。正视成本，不代表就要因噎废食，而是要通过工程框架来把控ROI。Team Engine就是这个作用：判断什么时候需要Agent Team、什么时候单Agent就够了。
有一篇论文，叫Cost of Consensus。其中有一个反直觉发现：在特定模型和同质debate设置下，多Agent的token消耗可能达到单Agent自我修正的2.1到3.4倍。而准确率，却没有提升。没有结构、没有验证、没有停止条件的「多Agent」，就是在浪费Token。那不叫团队合作，那叫AI聊天室。Team，从来不是默认选项。对于简单任务而言，单Agent绰绰有余。甚至有些时候脚本就够了。不是所有事都要开会。但当你真的需要开会的时候，有一个靠谱的团队，肯定比一个人闭门造车强。
对了。MiniMax说会开源这个Agent Team，预计会和MiniMax M3一起放出来。桌面端下载：agent.minimaxi.com/download
