一个 AI 还是不够

📌 一句话摘要

MiniMax 推出多 Agent 协作系统 Mavis，通过 Leader-Worker-Verifier 架构和对抗性质量门禁，解决单 Agent 在复杂任务中的痛点，并分享了其设计理念、技术架构、成本考量与适用场景。

📝 详细摘要

本文是 MiniMax 对其全新多 Agent 系统 Mavis（Agent Teams）的深度技术分享。文章首先指出单 Agent 在复杂任务中的四大痛点：任务中途意外停止、长任务质量衰减、无法快速响应用户、角色分工不明确。为解决这些问题，MiniMax 设计了基于 Leader-Worker-Verifier 三层架构的 Agent Team，强调多 Agent 系统本质是一套需要持续运行和维护的基础设施，而非简单的 Prompt 编排。文章详细阐述了其核心设计差异：对抗性的质量门禁（Worker 与 Verifier 相互制衡）、确定性的状态机驱动逻辑、以及上下文隔离机制。随后，文章深入分析了四个核心落地场景：IM 通讯（将秒回与执行分离）、代码开发（全流程跟进与审查）、研究调研（并行信息通道与独立验证）、办公文档（流水线式生成与检查）。最后，文章坦诚讨论了多 Agent 带来的三类成本（交接、共享、聚合）以及验证的平衡问题，并给出了何时该使用 Agent Team 的决策建议。

💡 主要观点

1. 单 Agent 在复杂任务中存在四大核心痛点：任务中断、质量衰减、响应延迟、角色分工模糊。 模型对超长任务的停止判断模糊，导致任务中途停滞；长任务执行中易偏离初始目标且难以自我纠正；执行长任务时无法快速响应用户新消息；单一 Agent 难以同时管理不同任务所需的工具、上下文和验收标准。
2. 多 Agent 系统的本质是基础设施，而非 Prompt 编排。 真正的多 Agent 协作需要一套支撑系统（Team Engine）来管理任务分配、状态追踪、错误恢复和结果验收，Prompt 和 Skill 只是其中薄薄的一层，无法形成稳定可靠的持续交付。
3. MiniMax 的 Agent Team 采用 Leader-Worker-Verifier 三层架构，核心在于对抗性质量门禁和确定性逻辑驱动。 Leader 负责拆解和调度，Worker 负责执行，Verifier 负责独立检查。Worker 和 Verifier 之间是对抗关系，通过多轮迭代保证质量。系统由状态机驱动，而非模型自由判断，确保行为确定性。同时，各 Agent 上下文隔离，避免信息膨胀和污染。
4. Agent Team 在 IM、Coding、研究、办公文档四大场景中具有显著优势。 在 IM 中，将秒回用户与后台执行分离；在 Coding 中，实现全流程跟进与审查；在研究场景中，通过并行信息通道和独立 Verifier 提升效率和结论可靠性；在办公文档中，将生成过程拆解为可验证的流水线。
5. 多 Agent 协作会引入交接、共享、聚合三类额外成本，需要结构性设计来平衡。 信息在 Agent 间传递需要重新组织（交接成本）；共享上下文会线性增加 token 消耗（共享成本）；合并多路并行结果需要 Leader 投入真实精力（聚合成本）。Agent Team 是策略选项，适用于复杂、长链路、高风险任务，简单任务用单 Agent 或脚本更优。

💬 文章金句

• 一个 Agent 同时当裁判又当选手就会产生问题，这是靠单体迭代很难解决的。
• 多 Agent 系统不是 Prompt/Skill 编排，而是一套需要持续运行和维护的基础设施。
• Agent 产品的重心正在从写 prompt 转向维护这套基础设施。
• 让 Agent 运行的停止条件绑定到有确定性、可观测的外部系统。
• 没有结构、没有验证、没有停止条件的多 Agent 是不成立的。

📊 文章信息

阅读完整文章