跳转至

一个 AI 还是不够的：MiniMax Agent Team（Mavis）

Ch04.137 一个 AI 还是不够的：MiniMax Agent Team（Mavis）

📊 Level ⭐⭐ | 13.3KB | entities/minimax-agent-team-mavis-owner-worker-verifier.md

Minimax Agent Team Mavis Owner Worker Verifier

一个 AI 还是不够的：MiniMax Agent Team（Mavis）

作者：MiniMax 稀宇科技 平台：微信 原始链接：https://mp.weixin.qq.com/s/TIL7o92f71DsPPLWT4_37A 抓取日期：2026-05-13 来源：MiniMax

背景

MiniMax 将 Agent 产品升级，新名字：Mavis — MiniMax as a Jarvis。 此次分享做 Agent Team 背后的思考：怎么设计 Agent team？为解决什么问题？付出什么成本？用户什么时候该用 Agent Team、什么时候没必要用？

单 Agent 的四个痛点

痛点一：上下文焦虑

用户给了 7 件事，Agent 做完 3 个就停了，开始汇报"已经完成了 1、2、3，要不要继续做剩下的"。这是因为模型普遍存在上下文焦虑，模型本身对于"超长任务什么时候该停"的判断就是模糊的。

痛点二：注意力漂移

用户体感是，一开始它像个聪明助手，跑着跑着变成了一个容易分心的人。你得不断追问：刚才那条要求还记得吗？那个来源核实过了吗？写着写着风格怎么变了？只要其中一个环节走偏，后面的内容就会沿着偏差继续生成。单 Agent 很难形成自我制衡，它可能很真诚地自检，但检查的仍然是自己刚刚构造出来的东西。

痛点三：IM 场景的延迟期望

在 IM 场景下，用户发一条消息往往是期待几秒内有回应的，哪怕任务很复杂，也希望对方先"收到了，我会怎么做"。但单 Agent 要么给一个很浅的答案，要么让用户盯着对话框等十分钟甚至更久。大量用户反馈"我的 Agent 怎么不回我了"。

痛点四：角色混淆

一个用户同一天可能要写代码、查资料、做 PPT、整理会议纪要、处理表格。每类任务的工具权限、质量标准、交付格式都不同。单 Agent 可以通过 Skill 暂时扮演不同角色，但角色扮演不等于角色分工——真正的分工至少包括工具不同、上下文不同、记忆不同、Skill 不同，输出协议和验收标准也不同。

Agent Team 的核心认知

多 Agent 经常被简化成"写几段 prompt 扮演不同角色"，但这种做法在真实业务里撑不了多久。 可以这样理解：

  • Prompt/Skill 编排 = 写了一份工作手册发给几个人，每人按手册做事
  • Team Engine = 有一套活的系统在背后运转，prompt 只是其中很薄的一层 比如同样是"创建一个任务"这个动作，发起方可能是用户、可能是另一个 Agent、也可能是 Team Engine 的定时监控，每种来源都要走不同的处理逻辑。这些都是 Prompt 没办法做软约束的，必须有一套基础设施。

三个关键架构差异

差异一：对抗式验证

Worker 和 Verifier 之间是对抗关系，类似企业里研发和质量部门的关系，通过多轮对抗式迭代来保证交付质量，而不是靠 Agent 自己说"我做完了"。很多框架里的验证环节是可选的附加步骤，在 MiniMax 这里它是架构的核心。

差异二：状态机管理

用可靠的状态机来管理 Agent 的运行周期，而不是依赖模型的自由判断来决定接下来该干什么。什么时候该验证、什么时候该重试、什么时候该停止，都是引擎层面的硬性约束。

差异三：隔离上下文

Owner-Worker-Verifier 三角色

Owner（项目经理）

负责理解用户目标、拆分子任务、决定执行顺序、分配每个任务由哪个 Worker 来接、合并结果、控制什么时候停止。可以理解为项目经理。

Worker（专业执行）

不同 Worker 可以拥有不同的工具、上下文和输出要求。有的做资料检索，有的写代码，有的生成文档，有的处理表格，有的调用外部系统。Worker 的价值在于专业化，角色越清楚，它的输出就越容易被复用、比较和检查。

Verifier（对抗检查）

可以检查事实来源、跑代码测试、核对格式要求、对照覆盖清单，也可以对 Worker 的结果提出修改意见。 关键设计逻辑：Worker 停止的条件是 Verifier 启动的原因，Verifier 停止的条件是尽可能发现 Worker 的问题，而发现的问题又成为 Worker 重新启动的原因。它们之间是相互制衡的关系。 必要的时候，人类会和 Owner 一起做决策，特别是高风险变更、模糊需求、或者成本继续扩张的时候。

Task 派发 vs Agent Team

Task 派发 Agent Team
本质 一次收发，像发邮件等回复 持续在线，像开工作群
中间状态 主 Agent 不知道 Worker 可主动上报
补充通道 无 Owner 随时可补充指令
失败处理 卡住没法喊人 Verifier 可直接打回
持续协作的底层支撑：Team Engine 管理每个 Agent 当前处在什么阶段（等待/执行/验证/已完成）。同一个 Agent 重试时还能复用之前的上下文，不用从头来过。

IM 场景落地

核心思路：快回复 + 后台执行 主 Agent 收到消息后先快速响应：收到了，目标确认，我会怎么做。然后把具体任务拆到后台，分配给不同的 Worker 并行执行。用户不用盯着对话框等，关键节点会收到汇报。 体验上就像一个能秒回你微信、同时后台还在帮你干活的同事。

Verifier 在研究场景的具体工作

来源检查

引用的是不是一个别人也能打开、也能验证的稳定链接？官方页面、论文、GitHub 仓库算稳定来源；搜索引擎缓存页、打不开的社区帖、聚合站二手转述只能当线索。

时效检查

一个来源上周访问不了但这周恢复了，报告里不能还留着"无法确认"的标注；页面的发布日期没核实过，就不能在报告里写成确定时间。 独立 Verifier 的价值：它和做研究的 Worker 不共享同一个上下文，没有"我刚查过所以应该没错"的惯性。

文档场景：能做 ≠ 能交付

单 Agent 做文档最容易出现的错觉就是：只要模型会写，就等于能交付。 长报告、正式合同、财务表格、项目复盘 PPT 有太多信息——内容规划、资料引用、结构一致性、版式规范、文件格式、表格公式、图表对象、页眉页脚、目录、导出质量——都会挤在同一个上下文和同一个执行循环里。 Agent Team 做法：Planner 定义目标和结构 → Write

深度分析

超越"角色扮演"的多 Agent 范式 MiniMax 的 Owner-Worker-Verifier 模型揭示了一个关键认知：多 Agent 的价值不在于让多个模型"扮演不同角色"，而在于通过基础设施层面的解耦实现真正的任务分工。这与企业中的研发-质检对抗关系本质上是一致的。 上下文隔离作为核心竞争力 文章指出的"第三个关键架构差异"——隔离上下文——直接呼应了 Harness Engineering 的核心原则：大模型上下文是稀缺资源，需要按职责分类管理，而非共享一个不断膨胀的对话历史。这解释了为什么 MiniMax 选择让每个 Agent 只看到与自身任务相关的信息摘要，需要细节时再读全文。 对抗验证的架构地位 在 MiniMax 的设计里，Verifier 是架构核心而非可选项。Worker 停止的条件触发 Verifier 启动，而 Verifier 发现的问题又成为 Worker 重新启动的原因，形成相互制衡的闭环。这与 Harness 中 evaluator 的对抗定位高度一致。 成本约束下的 Agent Team 适用边界 论文 Cost of Consensus 指出，无结构的多 Agent 验证会产生 2.1 到 3.4 倍的 token 消耗，而准确率未必提升。这解释了为什么 MiniMax 强调"Team 不是默认选项，是策略选项"：任务越复杂、链路越长、风险越高、经验越可复用的场景，才值得上 Team。

实践启示

1. 从"角色扮演"到"架构分工" 避免陷入多 Agent 就是写几段 prompt 的误解。真正的架构分工需要：工具不同、上下文不同、记忆不同、Skill 不同，输出协议和验收标准也不同。角色越清楚，输出越容易被复用、比较和检查。 2. 交接成本是隐形瓶颈 研究 Agent 收回来几十个网页，写作 Agent 可能用不了。Agent 之间应通过结构化的文件和摘要来通信，而不是把所有上下文塞进一个 prompt。在设计多 Agent 通信协议时，需要提前考虑信息重新组织的开销。 3. Verifier 是基础设施，不是可选项 认真验证就是要花时间和 token，走过场不如不设。同时需要明确的退出机制，否则越跑越贵。高风险动作（如合并代码）不能让 Agent 拍板，必须人类签字。 4. IM 场景的核心设计：快回复 + 后台执行 主 Agent 先快速响应"收到了，目标确认，我会怎么做"，然后把具体任务拆到后台并行执行，用户不用盯着对话框等，关键节点会收到汇报。这本质上是一个能秒回你微信、同时后台还在帮你干活的同事模型。 5. 何时采用 Agent Team | 维度 | 有利于 Agent Team | 有利于单 Agent | |---|---|---| | 任务复杂度 | 长链路、多阶段 | 简单直接 | | 风险等级 | 高风险、高价值 | 低风险 | | 可复用性 | 经验可复用 | 一次性任务 | | 响应期待 | 可延迟 | 需即时 | 何时不用 Agent Team：任务越短、越低风险、越确定，单 Agent 甚至脚本就够了。没有结构、没有验证、没有停止条件的多 Agent 是不成立的。

相关实体