点进去看才发现，原来这都是Mavis自己组的团队。它们一直在内部交流、开会、分配任务……
如果按照正常的习惯，我一般会跟AI反复沟通很多次，精研细琢，最后让它生成一份完整的Plan。
但出乎意料的是，这次真就One Take，啥额外的指示都没有给，最后就拿到结果了。
其实就是团队分工，Mavis这有三个角色：Leader负责统筹全局，Worker负责具体执行，Verifier负责验收质量。
比如这个叫Mavis的，就是Leader，它是我的第一话事人，会指挥其他Agent干活。
从事实准确性、页面可读性、代码可运行性……这几个角度入手监督，并最终生成验收报告。
Mavis自己开盒自己的工作流，以这种step时间线的方式呈现，中间这条线还是脉冲的。
说实话，如果单Agent来做这件事，我大概要说十几次「继续」，还得在过程中反复纠错。
你是一个高级前端开发。今天早上你交付了一个index-v2.html，现在被老板骂得狗血淋头。
原话：这个什么破页面？做完你自己照着截个图看看，好意思说是科技公司产品专题页？配色暗沉得像上世纪的财务软件，动画只有一个脉冲点在那里……
毕竟听到多Agent工作流，第一反应肯定是：这得多贵？Token无限流咱可遭不住啊。
一份订阅，CLI、API、Agent全打通，M2.7、音乐、视频、语音所有模型都包含在内。
在微信/飞书里给AI发消息，要么30秒丢一个浅答案，要么你盯着对话框等10分钟没任何反馈。
这其实是个很深层的话题。对于超长任务的训练本身需要投入大量的金钱、时间成本和算法优化，大家没那么多资源向这块倾斜。
它不知道一个任务什么时候算「做完」，所以一直怕做错，怕给Token干崩了，干一半就停下问。
底层注意力的问题，随着上下文越来越长，Agent会从一个聪明助手变成了一个容易走神的人。
思路很直接：一个主Agent牵头，Leader、Worker、Verifier三类角色分工合作。
Worker停止的条件是Verifier启动的原因，Verifier停止的条件是尽可能发现Worker的问题，而发现的问题又成为Worker重新启动的原因。
什么时候该验证、什么时候该重试、什么时候该停止……都是引擎层面的硬性约束，不靠模型自由发挥。
用户可以对Agent进行prompt、spawn、abort、kill这些操作，Agent自己也有能力对另一个Agent做同样的事情。
Leader统筹全局目标，Worker只管执行子任务，停止条件由Team Engine控制，不再是模型自己模糊地判断「够了吗」。
每个Worker上下文隔离，查资料的不会被写代码的信息污染。Verifier用独立视角审查，不是自己检查自己。
顺便和你交代一下，已经在执行的任务中完成了2/5，剩下的有2个在核查，还有1个在跑。
以前我们总在琢磨怎么把一个Agent「养」成超人。希望它更聪明、更全能，什么都能干。
但有时候我也会想，Agent的能力或许天生就是有限的，AI从来没有电影里那么全知全能。
而且把目光放回眼前，比起一个遥不可及的AGI，我们的确更迫切地需要适配于实际应用场景的Harness。
在他们的设想里，后续Agent产品会让人类更多通过管理面板去配置Agent角色、能力和边界，分配任务。
在算力不够用的当下，每个Token都有实实在在的价格标签，token消耗和效果是个无法规避的trade off。
但问题是，研究Agent收来几十个网页，交接给写作Agent的时候，信息需要被重新组织——
Team Engine就是这个作用：判断什么时候需要Agent Team、什么时候单Agent就够了。
其中有一个反直觉发现：在特定模型和同质debate设置下，多Agent的token消耗可能达到单Agent自我修正的2.1到3.4倍。
MiniMax说会开源这个Agent Team，预计会和MiniMax M3一起放出来。
量子位 QbitAI