---
title: 一个 AI 还是不够的：MiniMax Agent Team（Mavis）
source_url: https://mp.weixin.qq.com/s/TIL7o92f71DsPPLWT4_37A
publish_date: 2026-05-13
tags: [wechat, article, agent, harness]
review_value: 7
review_confidence: 7
review_recommendation: neutral
sha256: 2f7bcc77e39ede64debcfc7f2cc897893a65833820584938dfc3dc0e48348b38
---
# 一个 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 的运行周期，而不是依赖模型的自由判断来决定接下来该干什么。什么时候该验证、什么时候该重试、什么时候该停止，都是引擎层面的**硬性约束**。
### 差异三：隔离上下文
受到 Harness 思想的启发，意识到大模型的上下文是宝贵的资源。通过拆分任务和职责分类，**让每个环节的上下文相互隔离**，而不是所有 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 定义目标和结构 → Writer 负责正文 → Formatter 负责版式 → Tool Agent 调用文档工具 → Evaluator 独立检查。文档生成从一次性文本生成变成了**构建流水线**。
## 成本分析
### 单 Agent vs 多 Agent 的成本研究
引用论文 **Cost of Consensus**：在特定模型和同质 debate 设置下，多 Agent 的 token 消耗可能达到单 Agent 自我修正的 **2.1 到 3.4 倍**，准确率却没有提升甚至更差。
**结论**：没有结构、没有验证、没有停止条件的多 Agent 是不成立的。但这个结论不能外推为所有多 Agent 都是浪费的。
### 三类额外成本
**交接成本**：信息在 Agent 之间传递时需要重新组织。研究 Agent 收回来几十个网页，写作 Agent 可能是用不了的。**做法**：让 Agent 之间通过结构化的文件和摘要来通信，而不是把所有上下文塞进一个 prompt。
**共享成本**：每多共享一段内容，每个 Agent 每一轮都要为它付 token。**做法**：按需加载，每个 Agent 只看到跟自己任务相关的信息摘要，需要细节时再读全文。
**聚合成本**：派十个 Agent 并行查资料很容易，但把十份结果合成一份事实一致、引用准确、风格统一的交付物很难。这一步没有捷径，Owner 要花真实的精力去合并。
### Verifier 的三笔成本
1. **验证本身**：认真验证就是要花时间和 token，走过场不如不设
2. **重试成本**：需要退出机制，否则越跑越贵
3. **人类决策成本**：高风险动作（如合并代码）不能让 Agent 拍板，必须人类签字；Agent 交付的不只是结果，还要留下完整过程记录让人能判断和接管
## 什么时候用 Agent Team
**Team 不是默认选项，是策略选项。**
| 场景 | 建议 |
|------|------|
| 任务越复杂、链路越长、风险越高、经验越可复用 | 值得上 Team |
| 任务越短、越低风险、越确定 | 单 Agent 甚至脚本就够了 |