Jay 发自 凹非寺
量子位 | 公众号 QbitAI
终于，不用一直对AI说「继续」了……
刚刚，MiniMax推出了新Agent。
Mavis，MiniMax as a Jarvis。
有意思的名字。
想了解一下，但有点懒，不太想看技术blog。
正好最近不是流行用AI做HTML吗，我就给它丢了这么一个任务：
基于Mavis的blog，做一个能放进文章展示的HTML专题页。
对，就这么一句话，没咋认真想prompt。
然后趁它在思考，我去午睡了。想着睡醒再给feedback。
结果我起来，打开一看，发现它竟然回了一句：
完成了。
不是？？
从收到Prompt到交付，完全没停，一口气跑了整整28分钟。
真就交付的HTML，图文并茂能交互的那种。
不过，我一瞟侧边栏，不对劲。
怎么冒出来这么多对话框？？
我记得我就开了一个啊？？？
点进去看才发现，原来这都是Mavis自己组的团队。它们一直在内部交流、开会、分配任务……
说真的，这一下，终于体会到了当老板的感觉。
使唤人太爽了。更别说使唤这么多人，还可以让Mavis唱红脸，帮我PUA。
（bushi）
这是MiniMax全新的Agent产品。
严谨点说，是一群Agent。
一群Agent帮我做了个HTML专题页
说实话，我自己都觉得最开始给的这个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的用户，额外赠送一个月会员。
为什么一个AI不够用了？
之所以这么兴奋，是因为这真是困扰我许久的使用痛点。
如果你也是一名vibe coding爱好者，你一定经历过这三个崩溃瞬间——
△图为AI生成
崩溃一：Agent总偷懒。
你让AI写一篇报告，它写了3段就停下来——
我已经完成了1/2/3，需要继续吗？
像听不懂话一样！！
你说继续，它又停。再说继续，又停。
一个晚上下来，你有一半时间在打「继续」「继续」「继续」……
崩溃二：长任务越跑越笨。
一开始它像个聪明助手，跑着跑着，变成了你在带一个很忙但容易分心的人。
你得不断追问——刚才那条要求还记得吗？你为什么又把研究任务写成产品营销了？
崩溃三：冷暴力……
在微信/飞书里给AI发消息，要么30秒丢一个浅答案，要么你盯着对话框等10分钟没任何反馈。
不是，你咋不回我了，干到哪了啊？？
这是我经常在IM跟小龙虾发的高频词。
这三个场景，应该所有重度AI用户都经历过。
所以，长程任务到底难在哪？
这次MiniMax在技术博客中，也给出了答案。
△图为AI生成
简单来说，这就是单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「养」成超人。希望它更聪明、更全能，什么都能干。
但有时候我也会想，Agent的能力或许天生就是有限的，AI从来没有电影里那么全知全能。
既然如此，其实也不该给单个Agent太大的压力。
这也是Mavis这次给我的最大感触。
除了模型本身的升级，Agent架构的更新，其实也能带来巨大的体验提升。
而且把目光放回眼前，比起一个遥不可及的AGI，我们的确更迫切地需要适配于实际应用场景的Harness。
但这也意味着，人机交互另一方的我们，也得相应地改变自己的工作习惯和思考方式。
你现在不是在跟一个AI聊天。
你在管理一个团队。
多Agent时代，每个人都要学着去担任那个更高的角色。
MiniMax的设计也指向这个方向。
在他们的设想里，后续Agent产品会让人类更多通过管理面板去配置Agent角色、能力和边界，分配任务。
此时真正重要的能力，就不止是单纯地写提示词了。
△图为AI生成
最后，咱还是现实点，说回「经济性」。
在算力不够用的当下，每个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
热门跟贴