重生之我在AI时代当老板：让一群Agent互相PUA

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