一手实测：MiniMax 全新发布 Mavis，是什么？

把 Agent 从单体，组成一支可以协作的 Agent Teams。

进入 2026 年的这几个月，所有 AI 基础模型厂商的产品方向都很一致：

把 Agent 从单体，组成一支可以协作的 Agent Teams。

前天晚上，Claude Code 发了 2.1.139 版本，最显眼的更新是 Agent View。在 CLI 里敲一句 Claude Agents，所有在跑的 session 全列出来，状态、阻塞点、需要决策的节点可以一个屏幕里看全。

再往前翻，其他厂商也都围绕着自己的多 Agent 框架，做了大量优化。可以说，Agent 产品的重心，正在从 Prompt 层往下沉到 Runtime 层。

今天早上，MiniMax 也上新了。MiniMax Agent 桌面端这次整体升级，起了个新名字叫 Mavis，MiniMax as a Jarvis，并随之附带了 Tech Blog。

这次更新的核心做了 2 件事：

第一，上线 Agent Teams。

桌面端现在支持多个 Agent 并行工作，你可以定义 Leader、Worker、Verifier 这样的角色组合，让一个团队去接长程、复杂的任务。

第二，TokenPlan 和 Agent Plan 合并。

一份订阅打通 CLI、API、Agent 三端，M2.7、音乐、视频、语音所有模型都包在里面，Credits 额度在 Agent 和 API 之间可以共享。之前同时订阅两个 Plan 的用户，额外送一个月会员。

🚥

接下来我们用一个完整的多 Agent 制作电商站案例，把 Mavis 的 Agent Teamss 跑了一遍，分享我们的体验与对 Tech Blog 的观察。

让 Mavis 搭一家智能家居电商网站

我们设计了一个相对复杂的综合任务，用来看 Agent Team 在真实链路上的表现。

首先，需要下载 MiniMax Agent 桌面版，链接如下：

agent.minimaxi.com/download

下载后就能看到它已经配置好了一个默认的 Agent，叫做 Mavis。

桌面版左侧是 Agent 列表，每个 Agent 对应一个固定的角色。系统默认带了三个，自己再加也很简单，填一个名称、写一段职责描述就行。一次可以建多个 Agent，最后把它们组成一个 Agent Team。

我自己加了一个叫 Leader 的 Agent。它的职责是拆解项目流程，把子任务分配给其他 Agent，监督进度，控制每一步的停止与交付节点。

每个 Agent 还可以单独设置工作目录。这样不同 Agent 拿到的是不同的本地上下文，最后再串联起来一起跑。

这次让 Agent Team 跑的是一个相对完整的任务：自主调研北美智能家居市场。整套链路里有几条分工，市场调研、产品信息搜集、前端开发、网站搭建，分别落到不同的 Agent 上。

先说结论。这一版桌面版最关键的更新是 Agent Teams。和之前的单 Agent 模式相比，它能把多个 Agent 拉起来并行执行，Agent 之间的衔接也比之前更紧。其中比较关键的一个角色是 Verifier Agent，系统默认带，作用是复核其他 Agent 在任务中的执行情况，把出现的问题挑出来。

下达「北美智能家居电商站」这个任务之后，系统会先盘点已经设置过的所有 Agent，判断哪些可以参与这次任务，再把它们集合成一个 Agent Team。

接着是任务拆解。Mavis 会按提示词把整个任务切成若干子任务，比如把市场调研派给 Worker Researcher，前端开发、产品数据收集、内容撰写、调研、复核也分别落到对应的 Agent 上。

拆完之后，子任务会先送到 Leader 这里，由它做第一轮节点审阅，再读取并执行分配下来的任务。

任务真正跑起来的时候，可以看到市场调研、前端开发、后端开发是并行进行的，另外有两个任务需要等前面节点到某个状态才会启动。比如「30 个产品的数据」会等市场调研跑完后再开始。

市场调研报告做得比较细。市场规模数据来自 Fortune Business Insights、Global Growth Insights 等行业报告，品牌和价格数据来自 Amazon 这类官方公开信息，用户痛点则取自公开的用户反馈分析报告，每一类数据都标了出处。

整个执行过程里，比较值得注意的是 Mavis 这次在「核验」这件事上加了权重。

之前在单 Agent 模式下，一个 Agent 既是执行者也是审核者，自己跑完任务再自己验收一遍，多数时候直接判通过然后进入下一步。一旦中间某一环走偏，后面的链路也会跟着变掉。

这一版的逻辑是按 Cycle 走的：每跑完一个 Cycle 触发一次核验，由 Verifier Agent 来检查整批任务。比如这一次有三个任务在核验阶段没过，问题既有程序层面的，也有内容层面的。问题被标出来之后，对应的 Agent 会把这部分任务重做或重新交付。

确认决策提交之后，下一个 Cycle 才会启动。在 Cycle 2 里，Market Research 会被重新核实，前端那部分也会重做一遍交付，测试阶段则继续往后补。

「决策已提交。Cycle 2 即将启动。」

到这一轮，前端页面（首页、产品列表、购物车、导航栏）全部完成，并通过验证。

产品数据这一类内容会经过多轮反复的测试和修订。最终落到结果里的字段比较细：产品名称、价格、数据来源、网站简介，再加上像地区这样的细分维度。这些数据相比之前的版本，是经过多轮 Verifier 核验之后才确定下来的。

在实际执行过程中，还有一个比较有意思的细节。

以前大多数 Agent 的对话流是这样：它在执行任务的时候，你插不进话，想补一句需求只能先暂停，等它停下再说。

Mavis 这次不一样，Agent 自己在干活的同时，你可以随时检查、确认，也可以直接在对话里追加新需求，两条线互不打扰，需求会被它自然接进当前的任务队列。

最后出来的网站完成度挺高。整体风格是粉色撞色加粗黑描边，现代感很强。功能上，主登录页、主落地页、产品介绍、加入购物车、FAQ 支持区都齐了，商品图用的是 Agent 自己搜集回来的真实素材，带各类标签。

具体到商品，Agent 前期就把北美主流品牌调研过一遍，比如 Google 的 Nest 系列，每个产品都配了简介、规格标签、价格，甚至能跳到对应的外部商品页，然后支持一键加入购物车。

结账这边做了一个完整的 demo checkout，可以自由加购，后端还带了一个简易数据库：

另外，这一版的 Mavis 也支持直接绑定 IM 工具，整个接入过程很简单：

Tech Blog 里的 3 个值得注意的点，和一次订阅方式的调整

做完这个测试，我又把 MiniMax 今天发的 Tech Blog 翻了一遍，完整 Blog 在知乎，链接如下：

https://zhuanlan.zhihu.com/p/2037877345634276836[1]

Blog 里有一些值得注意的小亮点，也代表了背后团队的判断。

【1】最核心的一句话是：多 Agent 系统是 runtime，不是 prompt 编排。

真正的团队协作要回答的是「谁分配任务、卡住了怎么办、做完了谁验收」这类问题，prompt 层只能做软约束，必须有一套持续运行的引擎在背后撑着。

MiniMax 把它叫 Team Engine，和 OpenAI 的 Agents SDK、Google 的 ADK、Claude Code 的 Agent View 基本是同一件事。

可以说，Agent 产品的重心，已经从 prompt 层转到 runtime 层了，这在 2026 年 5 月更像行业共识。

这个判断对用户的影响其实比较直接。过去两年大家讨论 Agent，多少都被「Prompt 工程」这个词带着走，好像 Prompt 写好了，事情就办完一半。但真到了长程任务上，Prompt 再细，也架不住模型在多步任务里上下文溢出、混乱。

Prompt 更像脚本，runtime 是执行它的环境，脚本再整齐，环境不稳的话结果也稳不了。厂商们今年集体往 runtime 这层下重注，对普通用户而言多出来的一个好处是：你不用太懂 Prompt，长任务也有机会稳定跑完。

【2】单 Agent 不能自己又当裁判又当选手。

Worker 和 Verifier 的目标函数互相反向，Worker 想做完，Verifier 想挑毛病，两者不共享上下文。这种设计有点像控制论里的闭环，两个极性相反的力把质量约束在稳定区间。

单 Agent 最大的问题就是自己当裁判又当选手，靠单体迭代永远解决不了。

这点我的感受比较深。在很多 Agent 产品里，Verifier 这个角色更像一个「礼貌性的盖章人」，这个比喻比较贴近。

Agent 自己给自己进行验证，而验证的结果往往由于模型本身的「偏好」，扫描不出太多的重要错误，几乎不打回。

原因也很简单，它和 Worker 共享同一套上下文、同一套判断标准，看 Worker 的产出怎么看怎么合理。Mavis 这次的做法是把 Verifier 的目标函数改成了「找问题」，再加上上下文隔离。

换个角度看，相当于不再让团队内部 PM 自检。这件事对使用者最直接的影响是在真实业务场景下，Agent 的工作效率、以及带来的价值会明显一些。

【3】多 Agent 有三类单 Agent 不会遇到的成本：交接成本（信息在 Agent 之间要重新组织）、共享成本（全量共享会把上下文撑爆）、聚合成本（把十份结果合成一份一致的交付物没有捷径）。

没有结构、没有验证、没有停止条件的多 Agent，只是把不确定性并行扩散。 所以 Team 不是默认选项，是策略选项，任务越复杂、链路越长、风险越高，越值得上 Team。

改个错别字就让 Agent Team 上，那是浪费。

这一段是 Tech Blog 里比较坦诚的部分。多 Agent 这个概念过去一年被讨论得比较多，听上去是「Agent 越多越聪明」的直觉。但 Cost of Consensus 的论文里也提过，无结构的多 Agent 在 token 消耗上能达到单 Agent 自纠错的 2-3 倍，准确率不一定有提升。

MiniMax 自己把这件事讲清楚，等于提醒用户：Team 是一种成本和收益都更高的工具，得放在合适的场景里用。这种主动划界的态度反而比堆功能让人安心一点。

它不会鼓励你用 Team 跑一切任务，但是会帮你识别哪些任务值得上、哪些任务其实单 Agent 就够了。

订阅方式调整了

与这回的 Agent Teams 上线相对应的是，MiniMax 把原来两个独立的订阅 ： TokenPlan 和 Agent Plan ，合并成了一份，算是做了点优化。

合并之后的变化，我大致梳理了下，有下面几点：

【1】一份订阅，全端打通。CLI、API、Agent 桌面端，用同一份订阅都能调用。

【2】所有模型都包含。M2.7、音乐、视频、语音这几个核心模型，全部纳入这一份订阅。

【3】Credits 共享。同一份额度可以在 Agent 和 API 之间自由调度。如果你今天想用 Agent 跑一个长任务，明天想拿 API 去写自定义工具，同一份额度可以自己分配。

【4】之前双订阅用户送一个月会员。这算是对老用户的额外的福利。

这件事放在 Agent Teams 上线这个时间点来看，其实逻辑还挺明确的。

多 Agent 协作天然会比单 Agent 贵，前面讲过交接、共享、聚合这三类新成本。

如果还保持两份订阅各自算账，那用户每次要上 Agent Team 跑一个长程任务前，都得先犹豫一下：这一个任务完整做下来会不会把 Agent Plan 的额度打穿？要不要留点给 API 那边开发用？算得太细，反而不敢放开用。

合并之后，这笔账好算多了。

一份订阅背后，模型付费（API、CLI）和产品付费（Agent 桌面端）的逻辑被打通，额度在两端可以自由调度。一方面可以用 Agent Team 跑具体的任务，剩下的可以用 API 继续精细打磨，同一份 Credits 现在可以自行分配，不用再切账号、不用再分预算。

对开发者和重度用户来说，这等于自由度提高了一档，能力怎么用、什么时候用，决策权算是交给了用户。

对 MiniMax 来说，这也是一个务实的选择：与其让用户在两个计费体系之间反复权衡，不如合成一个池子，降低决策摩擦，用户才敢放开用。

🚥

2026 年 5 月的这一周，Claude Code 上了 Agent View，MiniMax 上了 Agent Teams。再往前看 OpenAI 的 Agents SDK、Google 的 ADK、AWS 的 Agent 框架。

所有 AI 基础模型厂商几乎在同一个时间点，集体把注意力从转向「一组 Agent 怎么稳定协作」。

当单 Agent 在长程任务上的天花板已经快被自己撞到，下一步的差异化大概率只能来自 runtime。

这些就是 2026 年 Agent 产品竞争的新维度。

回到 Mavis 这次更新本身，跑完整套电商案例再看完 Tech Blog，比较意外的是 Verifier 的存在感。过去半年大多数多 Agent 产品里，「核验」都是一个可选模块。

Mavis 这一版把它直接写进了 Cycle 的硬流程，每跑完一轮就强制核验一次，没过就重新核验，看起来像给自己加成本，但实际跑下来长程任务的稳定性确实上来了。

单 Agent 时代「自己当裁判又当选手」的老毛病是被架构层面解掉的，不是靠 prompt 打补丁，效率可能反而提升了。

另外一个体感上的变化是 Mavis 这次更像一个持续在线的工作群，Agent 在跑的时候用户可以随时插话追加需求，Leader 自己会调度到对应的 Worker 上。这件事工程上不容易做，但用户感受上的变化是相对大的。

可以说，Mavis 这次整体选的是一条「重 runtime」的路线作为 MiniMax 在「多 Agent 协作」方向上的的答案。

至于这个答案是否完整、是否好用，推荐大家去试一下。

链接如下：

agent.minimaxi.com/download

文章来自于"十字路口Crossing"，作者 "GaKi"。