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 一起放出来。
