MiniMax 的 Jarvis 之路：Mavis 在多 Agent 工程化上的选择

锐意创新的某企业里，一位开发者在借助 AI 赶一个跨文件的代码重构项目，并行推进行业研究、生成技术报告和 PPT。单 Agent 接下任务后，其前期表现让开发者频频点头，但执行到一半突然停住汇报进度；继续推进时，上下文膨胀导致风格漂移、引用出错；更加要命的是 IM 里业务方还在协商追加需求，它却陷入长时间无响应……

这就是近半年来单 Agent 方案在企业落地时常见的尴尬场面。为此，业界纷纷推进多 Agent 协作来应对复杂长程任务。从 OpenAI Agents SDK 的显式 handoff，到 LangGraph 的流程图编排，再到 Claude Code Teams 的 Lead-Teammate 机制，各家都在探索如何让多个 Agent 真正协同工作。我国 AI 独角兽MiniMax桌面端Agent新增了Agent Teams功能，并起名为Mavis，以代码状态机驱动的确定性 runtime 为路径，以“工程可靠性”之名，杀入了这一领域。

多Agent路线分歧的本质

单纯依赖单 Agent 处理长链路、高复杂度任务存在结构性局限。MiniMax 技术博客中指出，单 Agent 容易在中途意外停止、上下文过长导致质量退化、阻塞用户即时交互，且 prompt 层面的角色扮演难以实现真正的职责分工，这些问题在 IM 场景、Coding 全流程、并行研究和文档交付中尤为突出。该观点在 X（Twitter） 上被大量引用和点赞。

但共识之下，多 Agent 路线选择出现了明显分化。一些方案倾向于 prompt/Skill 驱动的角色扮演与临时任务派发（handoff），主 Agent 把子任务扔给另一个 Agent，拿到结果后继续；另一些转向显式流程编排，如 LangGraph 用有向图定义分支、循环和状态恢复；还有 Claude Teams 等强调 Lead Agent 分配独立上下文的 Teammate 模式。

但 MiniMax 有自己的思考和答案。他们认为，把多 Agent 简单等同于“写几段 prompt 让模型扮演不同角色”，在真实业务中难以稳定。真正的团队协作需要一套基础设施：谁来拆解任务、执行到什么状态、卡住或失败如何恢复、谁来验收、过程记录如何审计，这些“手册写不了”的部分，必须由底层系统支撑。

因此，MiniMax Mavis 的选择，是构建确定性的代码驱动 runtime，而非依赖模型的自发编排。相比之下，这条路径在当前路线之争中显得务实而鲜明。

Mavis的独特技术路线

Mavis Agent Teams 的核心在于Team Engine——一套以代码状态机驱动的运行时系统。它将每个 Agent 的运行周期明确划分为 producing（执行）、verifying（验证）、done（完成）等阶段，通过确定性逻辑约束取代模型的模糊判断。

Agent Team采用Leader-Worker-Verifier三角色架构。Leader（类似 Owner）负责理解用户目标、拆分子任务、调度资源和最终聚合结果；Worker 专注具体执行，可根据任务配备不同工具、上下文和输出协议；Verifier 则承担质量门禁职责。它与 Worker 形成对抗关系：Worker 的目标是“完成”，Verifier 的目标是“挑问题”，双方通过多轮迭代逼近可靠交付。这种目标函数互为反向的设计，形成控制论层面的制衡，显著区别于单纯的自检机制或可选验证步骤。

上下文隔离是另一大亮点。不同于共享同一膨胀对话历史的做法，Mavis 中每个 Agent 只持有与自身职责相关的上下文，通过结构化摘要和文件路径进行慢通信。这有效避免了 token 爆炸和干扰，同时保留了必要的信息流动。Agent 间还实现了“同权”接口：用户能对 Agent 执行的操作（prompt、spawn、abort 等），Agent 之间以及 Team Engine 也能通过统一协议完成。这让协作从一次性的函数调用，升级为可持续的多轮交互。

与其他路线对比，Mavis 的特点更加突出。OpenAI Agents SDK 擅长清晰的顺序 handoff 和内置安全检查，适合路由与 triage 类场景，但并行能力和长生命周期管理相对有限；LangGraph 提供强大的显式流程和 checkpoint 恢复，适合高度自定义的复杂工作流，但调试成本较高；Claude Teams 强调 Lead 与独立上下文 Teammate 的协作，在集成体验上连贯，却仍较多依赖模型自主判断。

Mavis 则在异步 IM 响应、Coding Harness、并行研究和文档流水线等四个场景中展现了工程适配性。在 IM 中，主 Agent 秒级回复用户并后台并行拆解，用户随时可插话而不污染任务上下文；在 Coding 中，Developer/Tester/Reviewer 分工配合 tool-grounded 验证和审查记录，形成类似 Harness 的全流程闭环；在研究场景，多 Worker 并行搜集 + 独立 Verifier 核查来源可复查性，降低幻觉；在文档写作中，Planner-Writer-Formatter-Evaluator 构成 CI/CD 式的可验证流水线，每步失败都能局部重试。

没有结构、验证和停止条件的“多 Agent”，只是把不确定性并行扩散。Mavis 的 Team Engine 把收敛不确定性作为核心目标，这正是 Minimax技术路线的独特价值所在。

成本权衡与生产落地能力

考量落地成本，MiniMax 明确将 Agent Teams 定位为策略选项，而非默认模式——它适合复杂、长链路、高风险、经验可复用的任务，简单任务仍推荐单 Agent 或脚本。

MiniMax 清醒地认识到多 Agent 必然带来新增开销：交接成本（信息在 Agent 间需重新组织）、共享成本（过多广播导致 token 浪费）、聚合成本（Leader 合并多版本结果的难度）。同时，Verifier 的认真验证和重试策略也会推高消耗。论文《Cost of Consensus》曾指出，无结构的多 Agent 可能消耗 2-3 倍 token 却未必提升质量，MiniMax 通过状态机、隔离通信和退出机制来缓解这一问题。

在实际落地中，M2.7 等模型的 coding/agent 优化提供了性价比支撑。长期看，每次 Team 执行的经验可沉淀为记忆和 Skill，让单个 Agent 越用越懂用户。X 上用户观点也印证了这一点：有人赞赏状态机带来的可靠性提升和混合模型潜力（MiniMax 推理 + 其他模型审计），也有人提醒 handoff 过程中的信任与安全设计需持续关注。

对于企业用户而言，总体 ROI 取决于场景：交付确定性、可恢复性和审计轨迹的提升，往往能抵消短期 token 成本，尤其在生产环境中。

对开发者的价值与行业影响

Mavis 的实用价值首先体现在门槛降低。一份订阅打通 Token Plan 与 Agent Plan，CLI、API、桌面 Agent 额度共享，覆盖 M2.7 及多模态模型，这让开发者无需在不同产品间切换。桌面端 + IM 异步执行，进一步解放了“盯对话”的负担，让开发者能像管理真实团队一样调度 AI。

更深层的影响在于生产力跃迁。开发者得以从繁重的执行细节中抽身，转向更高阶的架构设计和创新思考，从“写代码的执行者”转向“设计工作流与验收标准的架构师与管理者”。Agent Teams 提供的可交互、可审计过程，也为企业级部署提供了基础。

从行业层面看，Mavis 推动国产 Agent 从演示级向生产级系统跃迁，强化了 runtime 基础设施的重要性，同时丰富了多 Agent 路线选项。

当然，正所谓“没有银弹”，开发者仍需保持清醒：任何路线都不是万能的，需根据任务复杂度、可靠性需求和预算，在不同方案中做出判断。信任设计、人类决策介入点和长期记忆管理，仍是值得持续投入的领域。

在多 Agent 实践已成必然的当下，MiniMax Mavis Agent Teams 交出了一份注重工程确定性和落地平衡的答卷。它没有追求最炫的技术概念，而是通过状态机、对抗闭环和核心场景适配，试图解决真实工作中的多 Agent 协作交付难题，推动 AI 真正成为专业员工团队，并初步取得了预期的效果。未来随着开源推进（预计与 M3 模型同期）和更多开发者实践，其价值将得到进一步验证。

对开发者而言，技术选择重要的是找到最匹配自己场景的可靠交付方式。着手构建“工程可靠性”的 Mavis，无疑为这一探索增添了值得关注的选项。