MiniMax Agent 升级更名为 Mavis，推出多 Agent 并行协作系统
声明：文档由AI根据原文生成。
MiniMax Agent 升级发布，新品牌 Mavis 亮相
2026年5月27日，MiniMax 宣布其 Agent 系统完成整体升级，并启用新品牌名 Mavis（MiniMax as a Jarvis），定位为"AI 管家"。此次升级包含两项核心变动：桌面端上线 Agent Teams 多智能体协作功能，以及将 TokenPlan 与 Agent Plan 合并为统一订阅体系。
合并后的订阅方案覆盖 CLI、API、Agent 三类入口，包含 M2.7、音乐、视频、语音等全部模型。Credits 额度可在 Agent 与 API 之间共享。对于此前同时订阅两个 Plan 的用户，MiniMax 额外赠送一个月会员。
单体 Agent 的瓶颈：为何需要 Agent Team
MiniMax 团队回顾了单体 Agent 的执行模式。以"整理一篇基于2026年最新数据的 Agent Team 长文，分别交付 Markdown 和 HTML 版本"为例，传统单 Agent 会立即开始生成并推送结果。这种模式在简单任务中体验流畅，但面对高质量交付要求时暴露出三类问题：
执行中断频繁。 模型普遍存在上下文焦虑，对超长任务的停止判断模糊。用户常遇到 Agent 完成部分修改后暂停汇报，等待"是否继续"的确认指令。
长任务质量退化。 随着执行推进，Agent 从"聪明助手"变为"易分心的协作者"，环节偏差会沿链条放大。自检只能检查自身构造的内容，难以形成有效制衡。
异步响应缺失。 在 IM 场景下，用户发出消息后期待秒级反馈，而非盯着对话框等待十分钟以上。"我的 Agent 怎么不回我了"是 MiniMax 收到的最高频用户反馈。
Agent Team 的解决路径是：主 Agent 快速响应确认目标，后台拆分任务并行执行，用户在关键节点收到状态汇报，也可随时追加需求。
行业多 Agent 协作方案对比
MiniMax 梳理了当前主流多 Agent 协作机制的技术特征与局限：
| 产品 / 引擎 | 多 Agent 如何协作 | 优势 | 局限性 |
|---|---|---|---|
| OpenAI Agents SDK | 一个 Agent 可以把任务交给另一个 Agent 继续处理，也可以临时调用另一个 Agent 获取专业结果，然后自己继续完成任务。系统负责保存对话过程、检查输入输出是否合规，并记录执行过程。 | 协作方式清晰，适合把任务分给不同专业 Agent；内置安全检查和过程记录，便于产品化；适合客服、业务流程、工具调用类场景。 | 多个 Agent 通常按顺序接力，天然并行能力有限；Agent 运行在同一套框架内，隔离性较弱；更适合产品内协作，不适合大规模独立任务执行。 |
| LangGraph | 把多个 Agent 放进一个明确的流程中，每个 Agent 负责其中一步。可以由一个主管 Agent 判断下一步交给谁，也可以把复杂任务拆成多层团队。系统会保存中间状态，便于暂停、恢复和人工介入。 | 流程可控，适合复杂业务；能表达分支、循环和多层任务；支持保存进度和恢复执行，适合长流程应用；交付结果可追溯和排查，适合降低成本。 | 搭建和调试成本较高；多个 Agent 主要在同一系统内协作，独立运行能力较弱；复杂流程需要较强的工程设计。 |
| OpenCode | OpenCode 本身主要是单 Agent 产品，不主打多个 Agent 互相协作。它的核心价值在于让不同命令、技能、权限和会话走同一套执行路径，因此可以作为外部多 Agent 系统里的底层执行能力。 | 命令体系统一，权限控制细，适合做可靠的编码 Agent；人类操作和 Agent 操作可以复用同一套规则；适合作为更大系统里的执行引擎。 | 内部没有完整的多 Agent 团队机制；不负责多个 Agent 的分工、通信、验收和调度；如果要做团队协作，需要外部系统补齐。 |
| OMC / oh-my-claudecode — Team Pipeline | 多个 Agent 按阶段接力：先制定计划，再整理需求，再执行，再验证。如果验证不通过，就进入修复阶段，修复后重新执行或重新验证，直到完成或失败。 | 过程完整，覆盖计划、需求、执行、验证、修复；验证失败后能继续修，不会停在半成品；适合复杂代码任务。 | 流程较重，简单任务使用成本高；依赖终端环境和多个后台窗口；阶段固定，想要临时调整方案的成本较高。 |
| Claude Code — Teams 机制 | 一个 Lead Agent 创建团队，给多个 Teammate 分配任务。每个 Teammate 有独立上下文、模型和权限，可以单独执行任务。Lead 负责派发任务、查看状态、发送消息、关闭成员，Teammate 完成后会回报状态。 | 和 Claude Code 深度集成，使用体验连贯；成员之间上下文隔离，适合多人分工；支持任务管理、消息沟通、空闲通知和关闭确认，团队协作能力比较完整。 | 任务安排主要依赖 Lead Agent 自己判断，稳定性受模型影响；复杂依赖关系不够明确；部分运行方式依赖终端窗口，跨会话长期运行能力有限。 |
| OMC Ralph Loop / Ralph Mode | Ralph 负责让任务持续推进。它通常配合并行执行和验证流程：先让多个执行单元推进任务，再反复检查结果；发现问题就继续修，直到通过或达到上限。 | 强调完成质量，适合需要反复打磨的任务；能把执行和验证连接起来，减少"做了一半就结束"的情况；适合复杂开发和修复类任务。 | 运行时间和成本可能较高；如果检查标准不清，可能反复修但效果有限；必须设置迭代上限、成本上限和停止条件。 |
| OMC Autopilot + Ralph | Autopilot 把任务拆成完整链路：先分析需求和技术方案，再制定实施计划，然后执行，之后由 Ralph 持续补完和修复，最后进入构建、检查、测试和多角度验证。 | 覆盖从需求理解到最终验证的完整过程；适合复杂任务自动推进；Ralph 能在执行后继续修复问题，提高交付质量。 | 系统流程较长，适合复杂任务，不适合轻量修改；每个阶段都依赖前一阶段质量，前面理解错了会影响后续；需要明确验收标准，否则后期验证效果会下降。 |
Mavis 的三角色架构与状态机设计
Mavis 的 Agent Team 由主 Agent 牵头，将复杂任务拆分为多个可并行子任务分配给一批 Agent 并发执行，内置对抗性质量门禁，采用确定性代码逻辑驱动的 Agent 循环。设计灵感来源于 Ralph-Loop 与 Harness 思想，核心机制是通过任务拆分与职责隔离保护大模型的上下文资源。
三类基础角色：Leader、Worker、Verifier
Leader 负责将用户目标转化为任务结构；Worker 执行具体子任务，可配置不同工具、上下文与输出要求；Verifier 将"完成了"转化为"可以交付"，检查事实来源、覆盖清单与风险边界，对 Worker 结果提出修改意见。Worker 与 Verifier 形成对抗关系：一方运行结束会触发另一方启动，通过多轮迭代交付高质量结果。
Team Engine 状态机管理
区别于传统 Task 工具的一次性输入输出，Agent Team 采用可随时互动的团队模式。Team Engine 作为状态机，按 producing、verifying、done 三态管理每个 Agent 的运行周期（一个运行周期即一个 Session）。验证未通过时自动唤起 producing 节点修改。Leader 可接收状态汇报、确认任务细节，或向运行中的 Agent 发送补充 prompt。
Agent 间通讯：Agent 与人类同权
Mavis 将用户对 Agent 的操作（prompt、spawn、abort、kill 等）抽象为统一接口，操作渠道可以是用户、其他 Agent 或 Team Engine。平权设计不意味着 Agent 获得无限权限，而是通过共享可审计协作面，使权限、责任和风险更易被看见。
四大核心应用场景
IM 异步执行：秒级响应与长任务后台运行
IM 场景的特殊约束在于用户期待秒级反馈，但复杂任务需要分钟级甚至小时级执行。Mavis 的主 Agent 先快速确认任务并说明执行计划，后台拆分并行处理，关键节点主动汇报状态。用户可随时追加新需求，主 Agent 即时响应并同步已有任务进度。
Coding Harness：全工程化开发流程
受 Harness 思想启发，Mavis 的 Coding 场景设置四类角色：Leader 判断任务是否值得启动 Team 并控制拆解粒度；Developer 负责实现，输出包含修改理由、潜在风险与验证建议；Tester 将"看起来能运行"转化为有外部证据的验证，结果来自命令、测试或可执行检查；Reviewer 关注"是否应该这样改"，检查抽象边界、兼容性、错误处理等，可进一步分工为普通 reviewer、security reviewer、domain reviewer。
Harness 将 test、lint、build、format check 视为一等公民，Reviewer Agent 先做自动初审，高风险动作（合并代码、覆盖线上数据）最终由人类签字确认。
并行信息检索与研究：多通道验证降低幻觉
单 Agent 研究存在速度慢、上下文污染、证据链迷失、方向有偏等问题。Mavis 将研究拆为并行信息通道，通过 verifier 与 synthesizer 合并为结构化结论。Verifier 检查来源可复查性，优先使用稳定 URL，排查反面证据与过期状态。
流水线式办公文档写作：从"能生产"到"能交付"
长文档、正式合同、财务表格等任务中，内容规划、资料引用、结构一致性、图表对象、页眉页脚、导出质量等环节挤在同一上下文内。Mavis 将文档交付拆为 Planner（定义目标结构）、Writer（正文）、Formatter（版式文件对象）、Evaluator（独立检查内容格式完整性）四个可验证阶段，形成类似 CI/CD 的构建流水线。
工程挑战：上下文成本、ROI 平衡与运行时复杂性
三类上下文成本。 交接成本：信息在不同 Agent 间需重新组织，Mavis 采用可读交接文件与共享留言板实现不打断的慢通信。共享成本：每段共享内容都会增加各 Worker 的 token 消耗，通过 Agent 内记忆、Agent 间 CLI 通讯、白板三种方式维护。聚合成本：将多 Worker 结果合成为事实一致、引用对应、风格统一的交付物，Leader 需承担"10 份合到 1 份"的工作量。
ROI 与时间权衡。 论文《Cost of Consensus》指出，无结构的同质 debate 消耗可达孤立自纠正的 2.1–3.4 倍 token，准确率未提升甚至更差。Mavis 通过控制拆分粒度、异步化降低用户心理成本，以任务结构换取"盯着 Agent 生成"的等待焦虑。长期视角下，Agent 通过记忆与 Skill 积累成长，Team 模式将成为解放人类执行劳动的关键路径。
Verifier 与重试策略。 验证本身、重试循环、Leader 决策三类成本需精细管理。GitHub Copilot cloud agent 的做法被引用为参照：计划、提交、日志、PR 全程可审查，PR 定稿前进行安全与质量分析。
从 prompt 编排到 runtime 建设。 Mavis 的实际代码复杂度远超"多段 prompt 扮演不同角色"的演示层面。Team Engine 需管理多种对象与状态转化，渲染层需承接用户、Agent、Team Engine 等多角色对同一概念的操作，消息来源涵盖用户对话、Agent 间对话、定时任务、监控消息、IM 消息等。OpenAI Agents SDK 的 sandbox/workspace/handoff/tracing、AWS AgentCore 的 Runtime/Memory/Identity/Gateway/Browser 等模块，均指向同一趋势：Agent 产品重心从"写 prompt"转向"维护控制面"。
设计原则与未来方向
Mavis 团队提出三项核心判断：多 Agent 的价值取决于结构而非数量，需回答"为何拆分、如何验收、何时停止、失败如何恢复、如何管理记忆"；Team 是可选方案而非默认方案，复杂度、链路长度、风险等级与经验复用性决定其收益是否超过成本；未来 Agent 将更像长期协作的数字团队，人类与 Agent 共享对等的控制接口与数据流通，管理面板本身也可由 Agent 控制。
MiniMax 表示，Mavis 桌面端已正式发布，用户可前往 https://agent.minimaxi.com/download 下载体验，现有 MiniMax 订阅即可同时使用 Agent 与 TokenPlan 两类产品。Mavis 预计将与 MiniMax M3 模型同步开源。