MiniMax推出Mavis:用多Agent团队解决长任务“半路停工”

179次阅读
没有评论

共计 1367 个字符,预计需要花费 4 分钟才能阅读完成。

!
先看结论

让 AI 不再反复追问“要继续吗”, 正成为 Agent 产品的新竞争点 。MiniMax 近日推出的新 Agent 产品 Mavis, 把重点放在“多 Agent 团队协作”上: 用户只提出目标, 系统内部则由不同角色的 Agent 拆解、执行、验收, 尝试把长程任务从单点对话变成可管理的工作流。

📌 从一个 Agent 到一支 Agent Team

Mavis 的核心并不是让单个 AI 承担所有事情, 而是引入类似团队分工的结构 。根据公开介绍, 它包含三类主要角色:Leader 负责理解目标和统筹任务,Worker 负责具体执行,Verifier 则负责检查结果质量。

这种设计的直接变化是, 用户不必把每一步提示词都写得极细 。一个较粗略的目标会先由 Leader 拆成多个子任务, 再分配给不同 Worker 推进; 完成后,Verifier 从事实准确性、可读性、代码可运行性等角度进行验收, 并推动必要的修改。

🔍 它想解决长任务里的三个痛点

重度使用 AI 的人, 对长任务中的卡顿并不陌生: 写到一半停下、上下文越长越容易跑偏、后台执行时缺少状态反馈 。Mavis 的多 Agent 架构, 正是针对这些问题提出的一种工程化解法。

  • 不频繁中断: 任务何时继续、何时验收, 不完全依赖模型自行判断, 而由工作流机制约束。
  • 降低上下文污染: 不同 Worker 承担不同子任务, 研究、写作、开发等信息相对隔离。
  • 增加质量制衡:Verifier 以独立角色审查 Worker 产出, 避免“自己检查自己”的局限。
  • 改善反馈体验: 主 Agent 可先确认收到任务, 再在后台推进, 并在关键节点汇报进度。

💡 Team Engine 是背后的关键机制

材料中提到,Mavis 底层有一个名为 Team Engine 的状态机, 用来决定何时验证、何时重试、何时停止。与单纯让模型自由发挥相比, 这类机制更像是在 Agent 之外加了一层流程管理。

其中一个值得注意的设计, 是 Worker 与 Verifier 之间存在一定“对抗式”关系:Worker 提交结果后 ,Verifier 尽可能发现问题; 问题再成为 Worker 继续修改的依据。它类似企业中的研发与质检协作, 通过多轮迭代提升交付质量。

此外,Mavis 还强调 Agent 之间可通过统一协议进行操作, 例如生成新 Agent、终止任务等 ; 高风险环节仍需要人类介入。这意味着系统并非完全放任自动化, 而是在权限与审计上保留边界。

📊 看点: 多 Agent 更强, 也更贵

多 Agent 带来的体验提升并非没有代价。 多个角色之间交接、共享、汇总信息 , 都会增加 Token 与算力消耗。MiniMax 方面也没有回避这一点, 而是将重点放在“是否值得”上: 如果多 Agent 能明显节省人工反复沟通与返工时间, 成本才有被接受的空间。

在产品层面,MiniMax 这次还调整了订阅策略 , 将 Token Plan 与 Agent Plan 合并,CLI、API、Agent 以及部分模型能力纳入同一订阅体系,Credits 可在 Agent 和 API 之间共享。对于此前同时订阅两个方案的用户, 官方还提到会额外赠送一个月会员。

🚀 行业观察: 使用 AI 可能从“写提示词”转向“管团队”

围绕“重生之我在 AI 时代当老板: 让一群 Agent 互相 PUA”,这一部分可从背景、现状与影响三个角度理解其关键信息。结合已公开内容来看,核心结论是趋势已较为明确,但细节仍需结合后续进展持续观察。

本文基于公开信息整理, 如有侵权请联系删除。
正文完
 1