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

Documentation Index

Fetch the complete documentation index at: https://agent.minimaxi.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

先看单 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 可能能够顺利完成这个任务，像一个坐在用户旁边的同事。用户问”这段话怎么润色”，它可以马上改；“这个地方格式有问题”，它马上去确认。但这里暴露了几个问题： 单 Agent 会在用户意想不到的时候停下来。 用户往往会遇到 Agent 要干 7 件事情，但是它完成 3 个改动后就停下来开始汇报了，说”我已经完成了 1/2/3 的修改，是否需要继续让我做剩下 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 循环。我们受到了 Ralph-Loop 和 Harness 思想的启发，意识到大模型的上下文是宝贵的，通过拆分任务和职责分类，让每个环节的 Context 隔离，提高整体的 Agent 产出质量。 Leader、Worker、Verifier 的基本协作流 为了让多 Agent 从概念变成可用产品，需要一个基本协作流。我们把它简化为三类角色：Leader、Worker、Verifier。

• Leader 负责把用户目标转化为任务结构。
• Worker 负责执行具体子任务。不同 Worker 可以拥有不同工具、上下文和输出要求。有的 Worker 做资料检索，有的做代码编辑。Worker 的价值在于专业化：角色越清楚，Worker 的输出越容易被复用、比较和检查。
• Verifier 负责把”完成了”变成”可以交付”。它可以检查事实来源、覆盖清单、风险边界，也可以对 Worker 的结果提出修改意见。

这体现了 Agent Team 的设计逻辑：Worker Agent 与 Verifier Agent 是对抗关系。双方都以运行结束为目标，但一方运行结束会引发另一方的运行开始。类似企业中的研发和质量部门，通过多轮对抗式迭代，交付高质量的结果，无需 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 或 Agent Team 的引擎。 当然，这种设计必须保持边界：平权不意味着 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

Agent Team 的项目很大程度上受到了 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 往往会先生成一大段文本，再尝试一次性排版、检查格式、修错误。短文档还可以靠一次上下文完成；一旦任务变成长报告、正式合同、财务表格，问题就会迅速暴露：内容规划、资料引用、结构一致性、图表对象、页眉页脚、导出质量，都挤在同一个上下文和同一个执行循环里。 Agent Team 让结果从”能生产”跨越到”能交付” 多 Agent 协作把文档交付拆成多个可验证阶段。Planner 先定义文档目标和结构；Writer 负责正文；Formatter 负责版式和文件对象；Evaluator 独立检查内容、格式和文件完整性。这样的拆分把”文档生成”从一次性文本生成，变成类似 CI/CD 的构建流水线：每一步产出中间件，每一步都有检查，每一步失败都能局部重试。

​

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

​

4.1. 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 时的第一步。

​

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

多 Agent 在过去的研究里很难和高 ROI 划等号。论文 Cost of Consensus 在特定模型与同质 debate 设置中声称，消耗可能达到 isolated self-correction 的 2.1–3.4 倍 token，准确率却没有提升甚至更差。这条结论指出一个清楚的事实：没有结构、没有停止条件的”多”，只是把不确定性并行扩散，简单的 AI 聊天室很难保证最终结果的质量。 ROI 也包括用户的等待。我们虽然已经把长任务异步化、让用户能随时和 Leader 的 Agent 沟通，能够降低用户即时的沟通诉求,但是整体任务的交付时间还是变长了，相比单个 Agent 的一口气做完，Agent Team 不可避免需要按顺序执行。我们思考了很久如何控制合理的拆分粒度以及平衡大任务效果差、小任务拆太细交付慢的问题。 我们相信随着模型智能水平的提高，后台跑 Team、完成后主动汇报，就是用任务结构换掉了”同一个对话里盯着 Agent 慢慢生成”的心理成本。多 Agent 的价值在这里和成本一起出现：用户愿意为可验证、可恢复、可审计的结果等更长，前提是过程透明。并且我们相信当用户看到 Agent Team 完成的高质量结果后，对 Agent 信任度提高，会更加解放自己的思路，让自己去进行更深刻、更广泛的思考，做一个有人味的思想者，把执行思想和落地结果的任务交给 Agent Team。

​

4.3. Verifier、重试和 Leader decision 的成本

Verifier 是 Team 从演示走向交付的关键。 第一类成本是验证本身。一次代码任务要跑测试；一次研究任务要核对来源、确认引用边界；验证越认真，消耗越高；验证只走个过场，就只剩”看起来通过”的虚假安全感。 第二类成本是重试策略。如果 Worker 一直在”改一点—被 verifier 退回—再改一点”里转圈，整个 plan 会越跑越贵。 第三类成本是 Leader decision 不能被模糊。在高风险动作面前——是否合并代码、是否覆盖线上数据，最终判断必须有人类签字。GitHub Copilot cloud agent 的官方文档把整个流程留在 GitHub 内：计划、提交、日志、PR 都可被团队审查；相关 changelog 也提到在 PR finalized 前会进行安全和质量分析。它指出的方向很清楚：Agent 交付的除了结果，还有可回放、可追责的轨迹。

​

4.4. 多 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 的两类产品。