📌 一句话摘要

本文深入分析了 MiniMax 旗下多 Agent 协作系统 Mavis 的技术架构，重点介绍了其 Leader-Worker-Verifier 三权分立、代码状态机驱动和对抗式质检机制，并分享了实际使用体验。

📝 详细摘要

文章以作者从 Claude Code 转向 Mavis 的亲身经历为引，深入探讨了多 Agent 协作系统的技术实现。核心观点是，真正的多 Agent 系统不应只是 Prompt 层面的角色扮演，而应是一个完整的运行时系统。文章详细拆解了 Mavis 的 Teams 架构：Leader 负责任务拆解，Worker 负责执行，Verifier 负责验收，三者形成目标互逆的对抗关系。这种架构通过代码状态机驱动，而非依赖 Prompt 编排，实现了任务进度管理、失败处理和过程追溯。文章对比了 OpenAI、AWS、Google 等行业动向，指出多 Agent 系统的重心已转向基础设施。此外，文章还介绍了 Mavis 的上下文隔离设计、对抗式质检机制的实际效果、开箱体验、订阅体系以及 IM 异步执行等工程化亮点。

💡 主要观点

1. 真正的多 Agent 系统是一个运行时系统，而非 Prompt 编排。 Mavis 采用代码状态机驱动，有专门的角色分工、状态记录和失败处理机制，而不是让模型通过角色扮演的 Prompt 进行简单对话。
2. Leader-Worker-Verifier 三权分立架构是核心创新。 Leader 拆解任务，Worker 执行，Verifier 验收，三者目标互逆形成对抗关系，解决了单 Agent 自我审视的局限性，提升了交付质量。
3. 上下文隔离设计是保证对抗机制有效性的关键。 Worker 和 Verifier 的上下文完全隔离，只能通过结构化摘要通信，确保双方目标产生真正张力，避免因信息共享而降低质检标准。
4. 多 Agent 系统的行业重心已从模型转向基础设施。 OpenAI、AWS、Google 等大厂的最新动作表明，多 Agent 系统的核心挑战在于任务规划、跨智能体协作和过程追溯等基础设施能力。

💬 文章金句

• 给一个 Agent 一个长任务...它要自己拆解自己要查什么资料，自己写出来自己看对不对，写错了自己检查自己改。这不光是个能力问题，是个权力分离的问题。
• 这种对抗关系...不是那种硬编码的规则校验，是让两个 Agent 站在不同的立场上博弈。
• 真正的多 Agent 系统是一个 Runtime，不是一套 Prompt 编排。
• 没有结构、没有验证、没有停止条件的多 Agent，只是把单一模型的不确定性并行扩散了。而在 Mavis 的 Engine 约束下，不确定性是在收敛的。

📊 文章信息

阅读完整文章