MiniMax Agent Team: 为长程任务，持续进化而生

今天我们介绍 MiniMax Agent 的整体升级，我们将升级后的 Agent 起了个新名字：Mavis — MiniMax as a Jarvis，你的 AI 管家。

这次进行了以下更新：

• 上线 Agent Teams。MiniMax Agent 桌面端现在支持多个 Agent 并行工作，你可以创建不同角色的 Agent，让它们组成一个团队协作完成任务，适合那些又长又复杂、一个 Agent 搞不定的任务。
• TokenPlan 和 Agent Plan 合并。一份订阅，CLI、API、Agent 全打通，M2.7、音乐、视频、语音所有模型都包含在内。Credits 额度在 Agent 和 API 之间可以共享，用法更灵活。如果你之前同时订阅了两个 Plan，会额外赠送一个月会员

此次，我们想跟大家分享我们做 Agent Teams 背后的思考：我们是怎么设计 Agent team 的？是为了解决什么问题？我们付出了什么成本？用户该什么时候该用 Agent Team、什么时候没必要用？

我们先回到当前单体Agent是怎么执行的。

“帮我整理一篇关于Agent Team 的长文，信息要基于2026年的最新数据，分别交付 Markdown 和 HTML 版本。”

在过去，我们会把这句话交给一个强大的 AI 助手。它会立刻开始回答，把一大段文字推回聊天窗口。这种体验很顺，但当任务的交付质量的要求变高时，问题也会出现：资料谁来查？事实谁来核？文档谁来排？如果今天做完了，下次系统还会不会记得这次踩过的坑？

1. 为什么要有Agent Team

虽然可以通过迭代Skill，让单体Agent在任务中出色交付，但一个Agent完成的结果交付必然意味着它即是裁判又是选手。这个矛盾就是我们建设Agent Team的出发点。

Agent Team 把一个原本压在单个Agent的复杂任务，改造成一个有前后台、有验收、有记忆的工作过程。用户仍然只发出一条消息，但背后的Agent Team系统会判断是否需要拆分，哪些角色可以并行，哪些结果必须验证，哪些经验应该沉淀。

继续我们的场景。

“帮我整理一篇关于Agent Team 的长文，信息要基于2026年的最新数据，分别交付 Markdown 和 HTML 版本。”

单 Agent 可能能够顺利完成这个任务，像一个坐在用户旁边的同事。用户问“这段话怎么润色”，它可以马上改；“这个地方格式有问题”，他马上去确认。但这里暴露了几个问题：1、用户如果不指挥，Agent就会停住，需要用户不断的执行“确认”、“继续”等指令。

• 单 Agent 会在用户意想不到的时候停下来。

用户往往会遇到Agent要干7个事情，但是它完成3个改动后就停下来开始汇报了，说“我已经完成了123的修改，是否需要继续让我做剩下5个修改”。

这是因为模型普遍存在上下文焦虑，对于超长任务的训练本身需要投入大量的金钱、时间成本和算法优化。模型对于一个任务什么时候可以停止的判断是模糊的。

• 单 Agent 会越来越笨，特别在长任务方面退化明显。

用户往往会有体感，随着Agent的执行，它从“一个聪明助手”变成“我在带一个很忙但容易分心的人”。用户不断追问：刚才那条要求还记得吗？你为什么又把研究任务写成产品营销了？只要其中一个环节走偏，后面的内容就会沿着偏差继续生成。更麻烦的是，单 Agent 很难天然形成“相互制衡”。它可能很真诚地自检，但它检查的仍然是自己刚刚构造出来的现场。

• 单Agent同时也无法快速响应长周期任务。

特别是在IM场景（通过通讯软件控制Agent的场景）下，用户的耐心非常短。用户从IM发出一条消息，期待的是几秒内得到回应。哪怕任务很复杂，用户也希望对方先回复：“我知道了，我会怎么做，完成后回来找你。”不希望盯着一个对话框等十分钟、半小时甚至更久，只为了确认任务有没有开始。“我的Agent怎么不回我了”是我们收到的最大量的用户反馈。

Agent Team 则能提供不同的体验。主 Agent 先快速响应用户：收到任务，确认目标，说明会在后台拆分执行。把任务拆成多个章节包或多个版本，并行执行。

用户不必等待每个子步骤完成，可以在关键节点收到汇报：任务已开始、遇到阻塞、需要决策、已经完成。

也可以随时和主Agent聊天：“我刚刚还有一个新的想法，你顺便帮我去研究一下”， 主Agent可以随时响应：“好的，我现在再开启一组Agent研究，有新的进展随时汇报。同时和你交代一下，已经在执行的任务中已经完成了2/5，未完成的3个任务中有2个已经进入核查阶段，还有一个任务我会继续盯着。”

像极了一个能秒回用户微信消息的贴心好友。

• 跳出某一个具体的任务，我们自然要接受用户需求的多样性和不同领域的角色的分工

一个用户可能在同一天要求 Agent 写代码、查资料、做 PPT、整理会议纪要、读 PDF、处理表格、处理报销、规划项目、生成周报。每类任务的输入结构、工具权限、质量标准、风险等级和交付格式都不同。

单 Agent 可以通过 Skill 暂时扮演不同角色，但角色扮演不等于角色分工。真正的分工从上下文方面至少包括四个维度：工具不同、上下文不同、记忆不同、Skill不同。从结果上看，输出协议不同、验收标准也不同。假设我们已经在上文中。构建出了Agent Team的系统，那么不同职责的Agent能更高频的接触到自己领域的任务，将踩到的坑形成记忆，将有价值的动作形成Skill。像一群和用户长期合作的同事，在各自的职能上越变越好。

2. 当前行业中的 多Agent 合作实践

3. MiniMax Agent Team：在约束多Agent循环的基础上，给予每个Agent更高的自由度

MiniMax的Agent Team是一个由某个主Agent牵头，把复杂任务拆成多个可并行的任务分配给一批Agent并发执行，自带对抗性的质量门禁的多Agent系统，是确定性的代码逻辑驱动的Agent循环。我们受到了Raplh-Loop和Harness思想的启发，意识到大模型的上下文是宝贵的，通过拆分任务和职责分类，让每个环节的Context隔离，提高整体的Agent产出质量。

• Leader、Worker、Verifier 的基本协作流

为了让多 Agent 从概念变成可用产品，需要一个基本协作流。我们把它简化为三类角色：Leader、Worker、Verifier。

Leader 负责把用户目标转化为任务结构。

Worker 负责执行具体子任务。不同 Worker 可以拥有不同工具、上下文和输出要求。有的 Worker 做资料检索，有的做代码编辑。Worker 的价值在于专业化：角色越清楚，Worker 的输出越容易被复用、比较和检查。

Verifier 负责把“完成了”变成“可以交付”。它可以检查事实来源、覆盖清单、风险边界，也可以对 Worker 的结果提出修改意见。体现了Agent Team的设计逻辑：WorkerAgent 与 VerifierAgent 是对抗关系。双方都以运行结束为目标，但一方运行结束会引发另一方的运行开始。类似企业中的研发和质量部门，通过多轮对抗式迭代，交付高质量的结果，无需CEO（人类用户）事无巨细的介入。

• 相比只能创建任务、获取结果一次收发的Task工具，Agent Team是一个可随时互动的团队。

传统 Task 工具通常发生在模型工具调用层：主 Agent 调用一个 task、dispatch 或 spawn 类工具，传入一段 prompt，等待子 Agent 返回一段文本或摘要。这类机制适合短生命周期、低风险、局部探索型任务，例如让另一个模型快速搜索文件、归纳材料、检查一个思路或生成候选答案。虽然目前存在后台运行的SubAgent，但本质Agent之间的通讯还是一次输入输出，无法多轮对话，实时上报遇到的问题和矛盾。

为了让Team稳定运行，我们选择了可靠的状态机去对每个Agent的运行周期进行管理，一个运行周期就是一个Session，这个状态机就是Team Engine。Team Engine会按照producing、verifying、done去管理每一个任务。当verifying未通过时，Team Engine会重新唤起producing节点继续修改。Leader在这个过程中会即会收到Team Engine的最新状态汇报，也可以主动确认具体的任务细节，甚至可以随时向正在运行的producing、verifying 的Agent发送补充 prompt。协作关系不再被限制为一次函数调用，而是变成主动推送、按需查询的多轮交互。

每一次Agent Team的运行都是有长期价值的。本次执行的经验也可以沉淀为记忆、Skill，让每个具体的Agent更主动地去了解如何与用户协作，高效完成任务，也支持所有的Agent更了解用户。

• Agent 间通讯设计：Agent 与人类同权

我们在设计和思考Agent应如何相互协作时最直接的思路就是去思考人和Agent是如何协作的。用户可以对Agent在前端交互上进行 prompt、spawn、abort、kill等操作，那么意味着Agent自己应也需要有能力对另一个Agent完成上述动作。我们将用户可以对Agent的操作抽象为接口，那么真实操作这些Agent的渠道就可以是用户、其他Agent或AgentTeam的引擎。

当然，这种设计必须保持边界：平权不意味着 Agent 获得无限权限，也不意味着人类退出责任链。恰恰相反，只有当 Agent 和人类共享同一个可审计协作面，权限、责任和风险才更容易被看见。

3.1. 核心场景一：接入 IM，异步执行快速响应

IM 的交互约束很特别。用户发消息时，预期是秒级反馈；但很多任务天然需要分钟级甚至小时级执行：研究资料、整理会议纪要、生成 PPT、跑代码测试。如果系统让用户一直等最终结果，体验会变成“Agent在聊天框里失踪了”。

单 Agent 在这里容易陷入两难：要么为了快速回复，只给一个浅答案；要么为了完整完成任务，让用户长时间无反馈。更糟的是，IM 对话还会继续发生。用户可能中途追加要求、切换话题、问另一个问题。如果长任务和当前对话绑在同一个上下文里，系统既难以保持响应速度，也难以保证后台任务不被新消息污染。

这和 Google A2A 官方协议中对 long-running tasks、状态更新、human-in-the-loop 的设计原则有呼应。Anthropic Managed Agents 官方博客提出“session 不等于模型 context window”，长任务需要可恢复的 session log 作为外部上下文对象。

说明行业共识正在形成：IM 异步执行的底层逻辑：当任务跨越多轮消息、多个工具、多个 Agent，不能依赖某个模型当前上下文一直不丢。系统需要把任务状态、事件日志、文件产物、决策记录保存为可恢复对象。Agent 协作是带状态的长期任务。

3.2. 核心场景二：Coding Harness

AgentTeam的项目很大程度上受到了Harness思想的启发和激励。Harness强调的事情是在基础的写代码基础上更进一步的思想：Agent不仅需要写代码，还需要跟进开发的全流程，把代码要有分支，执行要有沙箱，修改要有 diff，测试要能重跑，审查要有记录，失败要能回放，必要时还要能把任务拆给不同角色。让Agent运行的停止条件绑定到有确定性可观测的外部系统。

• Coding 任务下 developer / tester / reviewer 分工

一个工程化 Coding Harness 至少包含四类角色。

Leader 是控制面，它首先判断任务是否值得启动 Team：改错别字、替换常量可能单 Agent 或脚本更便宜；跨文件理解、多方案并行比选，才更适合 Team。它还要决定拆解粒度：是否先读代码，是否并行探索方案，是否先写复现测试，失败后重试几次，什么时候升级给人类。

Developer 负责实现，它有一个明确工作目标：需求、相关文件、项目约束和禁止事项。它的输出也不只是自然语言说明，而包括 修改理由、潜在风险和验证建议。

Tester 负责把“看起来能运行”变成“有外部证据”。它要找现有测试入口、压缩失败日志，并在必要时补充最小复现。关键是 tool-grounded：验证结果来自命令、测试或可执行检查。

Reviewer 不等同于 Tester。测试回答“是否通过已知验证”，Review 更关心“是否应该这样改”。它要检查抽象边界、兼容性、错误处理、依赖引入、权限扩大、日志是否暴露敏感信息。Reviewer 也可以分工并发：普通 reviewer 看可维护性，security reviewer 看输入/凭证/网络边界，domain reviewer 看业务语义。

• 自动化测试、代码审查和人工验收如何接入

第一层是自动化测试和静态检查。Harness 把 test、lint、build、format check 视为一等公民。Developer 修改后，Tester 执行验证；失败时，Leader 判断是让 Developer 修复、让 Tester 补日志，还是把环境问题上报。

第二层是代码审查。Reviewer Agent 可以先做自动初审，提前发现未使用变量、异常分支遗漏、公共 API 破坏、危险 shell 调用、secret 日志、越界改文件等问题。

3.3. 核心场景三：并行信息检索和研究

单 Agent 会遭遇研究速度慢、上下文被污染或危险注入、证据链迷失在上下文中、调研方向有偏向性等问题。Agent Team 的价值，是把研究过程拆成并行信息通道，再通过 verifier 和 synthesizer 合并为结构化结论。重点设计可信研究流水线，保证研究效率高的同时能跳出单Agent 的研究思路，从不同角度、正反面进行信息的搜集和确认。

• 独立 verifier 如何降低引用错误和事实幻觉

Verifier 首先检查来源可复查性。正式来源应尽量使用稳定 URL：官方页面、会议页面、作者博客。而搜索缓存、聚合页、只能作为线索，不能支撑正式结论。Verifier 还检查来源状态是否过期，是否存在反面证据否认真实性等。

3.4. 核心场景四：流水线式办公文档写作

单 Agent 做文档时，最容易出现的错觉是：只要模型会写，就等于能交付。用户说“帮我做一份报告 / Excel / PDF”，单 Agent 往往会先生成一大段文本，再尝试一次性排版、检查格式、修错误。短文档还可以靠一次上下文完成；一旦任务变成长报告、正式合同、财务表格，问题就会迅速暴露：内容规划、资料引用、结构一致性、图表对象、页眉页脚、导出质量，都挤在同一个上下文和同一个执行循环里。

• AgentTeam让结果从“能生产”跨越到“能交付”

多 Agent 协作把文档交付拆成多个可验证阶段。Planner 先定义文档目标和结构；Writer 负责正文；Formatter 负责版式和文件对象；Evaluator 独立检查内容、格式和文件完整性。这样的拆分把“文档生成”从一次性文本生成，变成类似 CI/CD 的构建流水线：每一步产出中间件，每一步都有检查，每一步失败都能局部重试。

4. 开发过程中的难点和思考

• Team 合作带来的上下文成本

一组 Agent 协作，会暴露一类新的成本：交接成本、共享、聚合成本。这种成本都不是“模型的Context Window再大一点就能解决”的。

交接成本指的是同样一段信息在不同 Agent 之间需要被重新组织。研究 Agent 收来的几十个网页后交接给写作Agent。写作Agent它需要一份经过初步研究的文档。写作Agent同样也需要交接一个写作结果给格式检查Agent。我们现在的处理方式是把交接物变成：1、可读的交接文件 2、多个Agent的共享留言板文件；Worker 之间通过这些文件的路径加摘要进行不打断的慢通信，避免一口气全部塞到上下文里。

共享成本指的是“给所有 Agent 看到所有信息”的代价。每多一段共享内容，每个 Worker 的每一轮都要为它付 token。当某个Agent执行过程中遇到问题时，他应该通过正确的方式写记忆，进而确保能广播到所有运行的/待运行的Agent的上下文中。我们采用了三种方式来维护这类共享信息：1、Agent内的记忆，此Agent的一次经验，同样的Agent后续执行会收到提示，甚至执行中的Agent也会被立刻通知。2、Agent之间的通讯CLI，Agent有能力直接和其他的运行节点对话，进行打断式的沟通 3、上述提到的白板能力，相比1和2 的主动通知，白板能够支持保存更大量的信息，其他Agent在使用的时候也可以更优雅的按需获取。

聚合成本指的是把多个 Worker 的结果合成一个交付物所需要的工作量。并行收集 10 个版本的资料容易，把它们合成一份事实一致、引用对得上、风格统一的文章很难。Leader 在这一步要做的，往往是“把 10 份合到 1 份”而不是“多调几个人补充”。承认这件事昂贵，是设计 Team 时的第一步。

• 时间 / Token 消耗与结果 ROI 的平衡

多 Agent 在过去的研究里很难和高ROI划等号。论文 Cost of Consensus 在特定模型与同质 debate 设置中声称，消耗可能达到 isolated self-correction 的 2.1–3.4 倍 token，准确率却没有提升甚至更差。这条结论指出一个清楚的事实：没有结构、没有停止条件的“多”，只是把不确定性并行扩散，简单的AI聊天室很难保证最终结果的质量。

ROI 也包括用户的等待。我们虽然已经把长任务异步化、让用户能随时和Leader的Agent沟通，能够降低用户即时的沟通诉求，但是整体任务的交付时间还是变长了，相比单个Agent的一口气做完，Agent Team不可避免需要按顺序执行1234。我们思考了很久如何控制合理的拆分粒度以及平衡大任务效果差、小任务拆太细交付慢的问题。我们相信随着模型智能水平的提高，后台跑Team，完成后主动汇报，就是用任务结构换掉了“同一个对话里盯着 Agent 慢慢生成”的心理成本。多 Agent 的价值在这里和成本一起出现：用户愿意为可验证、可恢复、可审计的结果等更长，前提是过程透明。并且我们相信当用户看到Agent Team完成的高质量结果后，对Agent信任度提高。会更加解放自己的思路，让自己去进行更深刻，更广泛的思考，做一个有人味的思想者，把执行思想和落地结果的任务交给Agent Team。

• Verifier、重试和 Leader decision 的成本

Verifier 是 Team 从演示走向交付的关键。

第一类成本是验证本身。一次代码任务要跑测试；一次研究任务要核对来源、确认引用边界；验证越认真，消耗越高；验证只走个过场，就只剩“看起来通过”的虚假安全感。

第二类成本是重试策略。如果 Worker 一直在“改一点—被 verifier 退回—再改一点”里转圈，整个 plan 会越跑越贵。

第三类成本是 Leader decision 不能被模糊。在高风险动作面前——是否合并代码、是否覆盖线上数据最终判断必须有人类签字。GitHub Copilot cloud agent 的官方文档把整个流程留在 GitHub 内：计划、提交、日志、PR 都可被团队审查；相关 changelog 也提到在 PR finalized 前会进行安全和质量分析。它指出的方向很清楚：Agent 交付的除了结果，还有可回放、可追责的轨迹。

• 多 Agent 系统是 runtime，不是 prompt 编排

离开模型和上下文，回到我们的系统是怎么建设的：多 Agent 经常被简化成“写好几段 prompt /skills 让模型扮演不同角色”。在 我们的真实代码里，这种简化只是最初的演示demo，实际上的代码复杂度隐藏在很多的细节中，只为了让用户有“只要对话就行了”的丝滑体验。Team Engine 需要管理多种复杂对象和状态转化，以保证Agent Team的运行能够足够自动化和可观测；渲染层面要承接人/Agent/Team Engine等多个角色对同一个概念的操作：比如同样是创建一个任务，就需要处理多种来源。渲染的另一头复杂度来自消息的来源。除了用户和Agent的对话内容，还有Agent之间的对话内容、定时任务的消息、Team Engine的定时监控、还有来自IM的用户消息等。背后复杂的软件工程，都是为了用户能够在简洁的界面上浏览被仔细安排过的信息来源。

行业资料也在指向同一方向。OpenAI Agents SDK 的官方说明强调 sandbox、workspace、handoff、tracing；AWS AgentCore 的官方发布把 Runtime、Memory、Identity、Gateway、Browser等列为企业级模块。它们共同提示一件事：Agent 产品的重心正在从“写 prompt”转向“维护控制面”。

承认 Agent Team 是 runtime，会改变产品判断。新功能不能只靠 prompt 修补，要在 runtime 里加事件、加可观测；权限和运行时的约束、写记忆的约束不能只靠 Agent 自觉，要执行恰当的软硬门禁和拦截；把多 Agent 当 runtime 维护，比把它当 prompt 模板维护要重得多，但只有这样才能稳定服务真实工作。

5. 启发

5.1 多 Agent为了更可靠地完成复杂任务

多 Agent 的核心是结构。没有结构的多 Agent 只是更贵的并发；有结构的多 Agent 才是可委派、可并行、可验证的执行系统。

因此判断一个多 Agent 产品是否有价值，不能看它能同时启动多少 Agent，而要看它是否能回答几个问题：为什么要拆分、如何验收、何时停止、失败如何恢复、如何管理记忆。这些问题回答得越清楚，多 Agent 越像生产系统；回答不清楚就越像演示中的群聊。

5.2 Team 的价值取决于复杂度，但ROI不能只看短期。

Team 只是可选项。任务越复杂、链路越长、风险越高、经验越可复用，Team 的收益越可能超过成本；任务越短、越低风险、越确定，单 Agent 或传统自动化越可能更优。不应鼓励用户“凡事开 Team”，而应帮助用户判断什么时候值得协作、什么时候应该保持简单。

无论选择Team或者单个Agent直接执行，都需要通过记忆、Skill等手段让Agent进行长期进步。确保即使使用Team使用了更多Token和时间，但也让Agent拿到了更多的经验和记忆。从长期来看需要将每个更懂用户更老练的Agent的成长作为ROI的考虑。因为当我们认为Agent拥有足够多的记忆和Skill，Team应该就是最解放人类双手的Agent执行模式。

5.3 未来的 Agent 会更像长期协作的数字团队

跟随Agent 间通讯设计：Agent 与人类同权部分提到的设计。后续Agent产品会在给人类和Agent开放完全对等的控制接口、数据流通。人类会更多的基于管理面板去配置Agent角色、Agent的能力和边界、分配任务。并在关键的节点交给人类决策。以及这个面板也可以由一个Agent来控制。整体的运行逻辑可能更接近，前文中提到的低效率的AI聊天室。是否能完全交给AI进行管理调度，让管理面板/Team Engine越来越轻量，还需要更强的模型出现。

多 Agent 是为了让 AI 从“单次工具”走向“长期伙伴”，从个人效率提升转变为把人从具体的开发中解放出来的关键一环。

6. 开源和如何使用

我们最新的MiniMax Agent在不久后会开源，由于工作量较大且内部迭代较快，预计与MiniMax M3的模型一起发布。

在开源之前，我们的桌面端现在已经正式发布了，也欢迎您尝试下载体验：https://agent.minimaxi.com/download。目前只需要有一个MiniMax订阅，就能享受到Agent和TokenPlan的两类产品。