5月13日消息,MiniMax 对其桌面端 Agent 产品进行了全面升级,并将其正式更名为 Mavis(MiniMax as a Jarvis)。此次升级的核心亮点是 Agent Teams 功能——用户可创建由多个不同角色的 Agent 组成的团队,协作完成单个 Agent 难以处理的复杂长任务。同时,此前分开的 API 与 Agent 订阅计划已合并为统一方案,CLI、API 与 Agent 完全互通、共享额度。
单 Agent 长任务的四重困境
MiniMax 在技术方案中直言不讳地指出了当前单 Agent 架构在处理长任务时面临的四个核心问题:
- 执行过程中意外中断——超过上下文窗口后模型行为不可预测,任务可能无声失败
- 超长上下文导致输出质量持续下降——无论模型窗口多大,质量随上下文长度增加而衰减是普遍现象
- 长任务阻塞实时交互——用户提交一个耗时任务后,必须等待完成才能进行其他操作
- Prompt 级角色扮演无法实现真正的分工——在一个共享上下文中要求不同角色各司其职,本质上是让一个大脑同时扮演多个身份,效果有限
Agent Teams:代码状态机驱动的工程化协作
Mavis 解决上述问题的思路不是「更好的 Prompt」,而是代码状态机——用确定的工程架构替代模糊的 Prompt 编排来驱动多 Agent 协作。
Agent Teams 定义了三种明确角色:
| | |
|---|
| | 负责将复杂任务拆解为可执行的子任务,并管理整体进度 |
| | |
| | |
其中,Verifier 与 Worker 构成对抗机制——Worker 负责产出,Verifier 负责挑错,二者职责分离、利益对立,类似软件开发中开发与 QA 的经典分工。
关键设计决策:上下文严格隔离。 每个角色的上下文完全相互独立,角色之间不共享任何对话历史或中间状态。通信只能通过结构化摘要进行——Owner 以任务摘要下发给 Worker,Worker 以结果摘要回复 Owner,Verifier 以验证报告回传 Owner。这种设计从架构层面杜绝了「一个 Agent 的幻觉污染另一个 Agent 的上下文」这一多 Agent 系统的典型陷阱。
从「Prompt 工程」到「Agent 工程」的范式切换
MiniMax 选择代码状态机而非 Prompt 编排来实现多 Agent 协作,是一个值得注意的设计取向:
- Prompt 编排:在共享上下文中用角色设定和指令约束 Agent 行为,本质上是「说服」模型按预期工作——弹性大但不可靠,长任务中尤其容易跑偏
- 代码状态机:用确定的状态转换和严格的数据边界定义 Agent 行为,本质上是「约束」模型在限定范围内执行——弹性小但可预期、可审计、可调试
这本质上是将软件工程的成熟方法论引入 AI Agent 领域:不再把 Agent 当作「一个人」来对话和管理,而是当作「一个模块」来设计、调度和测试。
对于开发者群体而言,CLI + API + Agent 全面打通且共享额度的设计,意味着 MinMax 将 Agent 定位为可编程的基础设施而非独立的对话产品——开发者可以在代码中直接调用 Agent 能力,而不必在 API 和对话界面之间切换。