# MiniMax Agent Team：为长期运行与持续演进而生 - 来源：MiniMax：Blog（网页） - 作者：MiniMax - 发布时间：2026-05-27 00:00 - AIHOT 分数：75 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.virxact.com/items/cmpunu0g50003slbr6n7p2gqa - 原文链接：https://www.minimax.io/blog/minimax-agent-team-long-running-1779893953 ## 精选理由 MiniMax 把 Agent 从单兵作战升级成团队协作，解决了长任务里「Agent 变蠢」和「为什么没理我」两大痛点，做复杂任务的可以认真看看。 ## AI 摘要 MiniMax对其Agent Team进行了整体升级并更名为Mavis。本次更新的核心是推出Agent Teams功能，允许用户在MiniMax Agent桌面端并行运行多个不同角色的智能体，组成团队以协作处理单一智能体难以完成的复杂长时任务。同时，原有的TokenPlan与Agent Plan合并为统一订阅，整合了CLI、API及Agent对M2.7模型、音乐、视频和语音功能的访问，其信用额度可在智能体与API之间共享。此次升级旨在解决单智能体在执行长期任务时容易出现的停滞、判断模糊及质量衰退问题，通过主智能体快速响应、任务拆分并行执行与关键节点汇报的机制，提供更流畅的用户体验。 ## 正文 今天我们正式推出 MiniMax Agent 的整体升级。我们为升级后的 Agent 赋予了一个新名字：Mavis —— MiniMax as a Jarvis，你的 AI 管家。 本次发布带来以下更新： 推出 Agent 团队功能。在 MiniMax Agent 桌面端，你现在可以并行运行多个 Agent，创建不同角色的 Agent，并让它们组成一个团队，协作完成复杂任务——非常适合单个 Agent 无法独立完成的冗长、复杂工作。 合并 TokenPlan 与 Agent Plan。一个订阅方案即可统一覆盖 M2.7、音乐、视频和语音场景下的 CLI、API 和 Agent。Agent 与 API 之间共享额度，使用更灵活。如果你此前同时订阅了两种方案，将额外获赠一个月的会员资格。 MiniMax Agent 团队升级横幅 这次我们想分享 Agent 团队背后的思考：我们是如何设计 Agent 团队的？它解决了什么问题？我们付出了什么代价？用户何时应该采用 Agent 团队，何时又不需要？ 让我们先回顾一下当今单 Agent 模式的实际执行方式。 “帮我整理一篇关于 Agent 团队的长文。信息必须基于 2026 年的最新数据，并同时输出 Markdown 和 HTML 版本。” 过去，我们会把这句话交给一个强大的 AI 助手。它会立即回复，将一大段文字推回聊天窗口。体验看似流畅，但随着交付质量要求的提高，问题逐渐浮现：谁来搜集资料？谁来核实事实？谁来排版文档？而今天的工作完成后，系统下次还会记得这些坑吗？ 1. 为什么我们需要 Agent 团队 即使你可以通过迭代技能让单个 Agent 表现出色，但当单个 Agent 产出最终结果时，它不可避免地既是裁判又是选手。这一矛盾正是 Agent 团队的出发点。 Agent 团队将原本压在一个 Agent 身上的复杂任务，转化为一个拥有前台和后台、具备验收环节、并带有记忆的流程。用户仍然只发送一条消息，但 Agent 团队系统会自行决定是否拆分任务、哪些角色可以并行运行、哪些结果必须经过验证、以及哪些经验应该被保留。 延续上述场景。 “帮我整理一篇关于智能体团队的深度长文。信息必须基于2026年的最新数据，并同时交付Markdown和HTML版本。” 单个智能体或许能流畅完成这项任务，就像坐在用户身边的同事。当用户说“润色这段文字”时，它能立即编辑；当用户说“这里格式不对”时，它能马上确认。但一些问题也随之显现：1）如果用户不下达指令，智能体就会停下来，用户不得不持续告诉它“确认”或“继续”。 单个智能体会在用户意想不到的时刻停下来。 用户经常看到，一个智能体有7项待办事项，却在完成3项编辑后停下来开始汇报：“我已经完成了编辑1、2、3——您希望我继续处理其他5项吗？” 这种情况之所以发生，是因为模型普遍存在上下文焦虑，而针对超长任务的训练本身就需要巨大的资金、时间和算法投入。模型对于任务何时可以结束的判断是模糊的。 单个智能体会随时间推移变得越来越笨——在长任务上退化尤为明显。 用户常常感觉，随着智能体运行，它从“一个聪明的助手”变成了“在管理一个忙碌但容易分心的人”。用户不停地问：你还记得之前那个要求吗？为什么你把研究任务变成了产品营销宣传？ 只要一步出现偏差，下游的所有内容都会沿着这个偏差持续生成。 更糟糕的是，单个智能体很少能形成自然的“制衡机制”。它可能会诚实地进行自我检查，但它检查的仍然是它自己刚刚构建的那个场景。 单个智能体也无法对长周期任务做出快速响应。 尤其是在即时通讯场景中（通过消息应用驱动智能体），用户的耐心非常有限。在IM中发送消息后，用户期望在几秒钟内得到回复。即使任务很复杂，用户仍然希望首先收到类似这样的回复：“收到，我将执行以下操作，完成后会回来汇报。”他们不想盯着聊天框等上十分钟、半小时甚至更久，只为确认任务已经启动。 “为什么我的智能体不回复我”是我们收到的最大单一类别的用户反馈。 智能体团队提供了一种不同的体验。主智能体首先快速响应用户：我已收到任务，目标已确认，我将在后台进行拆分和执行。任务被分解为多个片段包或多个版本，并并行执行。 用户不再需要等待每个子步骤完成。他们会在关键检查点收到报告：任务已开始、遇到阻塞、需要决策、已完成。 他们还可以随时与主智能体聊天：“我刚有了另一个想法，你能顺便也研究一下吗”，主智能体可以回应：“当然，我现在就启动另一个智能体组，有进展时向你汇报。顺便说一下，正在进行的任务中，5 个已完成 2 个，剩余 3 个中有 2 个处于验证阶段，最后一个我会持续关注。” 就像一个贴心的朋友，能秒回你的微信消息。 跳出任何一个具体任务，我们自然必须接受用户需求的多样性以及跨领域的角色分工。 在同一天，同一个用户可能会让智能体写代码、收集信息、制作幻灯片、总结会议、阅读 PDF、处理电子表格、处理报销、规划项目以及生成周报。每种任务都有不同的输入结构、工具权限、质量标准、风险等级和交付格式。 单个智能体可以通过技能临时扮演不同角色，但角色扮演并不等同于角色专业化。真正的专业化，仅从上下文角度来看，至少包含四个维度：不同的工具、不同的上下文、不同的记忆、不同的技能。从结果方面来看，输出协议和验收标准也不同。假设我们已经构建了上述的智能体团队系统——承担不同职责的智能体可以反复处理自己领域内的任务，将陷阱转化为记忆，将有价值的操作转化为技能，就像一群与用户长期合作的同事，各自在自己的岗位上不断精进。 2. 当今行业中的多智能体协作 产品 / 引擎 多个智能体如何协作 优势 局限性 OpenAI Agents SDK 一个智能体可以将任务移交给另一个智能体，或者临时调用另一个智能体获取专门结果，然后自身继续执行。该框架会持久化对话、检查输入输出合规性，并记录执行过程。 清晰的协作模型，适合在专业智能体之间拆分任务； 内置安全检查与流程记录，易于产品化； 适用于客服、业务流程和工具调用场景。 多个智能体通常按顺序接力——原生并行能力有限； 智能体在同一框架内运行，因此隔离性较弱； 更适合产品内协作，而非大规模独立任务执行。 LangGraph 将多个智能体置于显式工作流中，每个智能体负责一个步骤。一个监督智能体可以决定由谁处理下一步，或者将复杂任务拆分为多层团队。系统会保存中间状态，支持暂停、恢复和人工干预。 可控的流程，适合复杂业务逻辑； 表达分支、循环和多层任务； 支持进度保存与恢复，适用于长时间运行的工作流； 输出可追溯、可调试，有助于成本控制； 构建和调试成本较高； 智能体主要在同一系统内协作——独立执行能力较弱； 复杂工作流需要较强的工程设计能力。 OpenCode OpenCode 本身主要是一个单智能体产品，不专注于多智能体协作。其核心价值在于将命令、技能、权限和会话统一到同一执行路径上，因此可以作为外部多智能体系统的底层执行层。 统一的命令系统，细粒度的权限控制——作为可靠的编码智能体基础扎实； 人类与智能体的操作遵循相同规则；非常适合作为更大系统内的执行引擎。 内部没有完整的智能体团队机制； 不处理智能体间的分工、通信、验证或调度； 团队协作必须由外部系统补充。 OMC / oh-my-claudecode——团队流水线 多个智能体按阶段接力：规划、需求、执行、验证。若验证失败，流程进入修复阶段，随后重新执行或重新验证，直至完成或彻底失败。 完整流程涵盖规划、需求、执行、验证与修复； 验证失败后持续修复——绝不半途而废； 非常适合复杂编码任务。 重量级流程——对简单任务而言开销过高； 依赖终端环境及多个后台窗口； 阶段固定——中途调整计划成本高昂。 Claude Code — 团队版 一个主导智能体创建团队，并将任务分配给多个团队成员。每个团队成员拥有独立的上下文、模型和权限集，可独立执行任务。主导智能体负责分发任务、监控状态、发送消息以及关闭成员；团队成员在任务完成时报告状态。 与 Claude Code 深度集成，用户体验连贯一致； 成员间上下文隔离，适合并行分工； 具备完整的任务管理、消息传递、空闲通知和关闭确认功能——团队协作相对完善。 调度依赖主导智能体自身的判断——稳定性取决于模型； 复杂依赖关系不够明确； 部分运行模式依赖终端窗口——跨会话长时间运行能力有限。 OMC Ralph 循环 / Ralph 模式 Ralph 持续推动任务前进。它通常将并行执行与验证配对：多个执行单元推进任务，随后反复检查结果；发现问题即进行修补，直至通过或达到上限。 强调完成质量，适合需要反复打磨的任务； 桥接执行与验证，减少“半途而废”的模式； 适用于复杂的开发和修复工作。 运行时间和成本较高； 若检查标准不明确，反复修复可能收益有限； 必须设定迭代上限、成本上限和停止条件。 OMC 自动驾驶 + Ralph 自动驾驶将任务拆解为完整链条：分析需求与技术方案、起草实施计划、执行，然后让 Ralph 持续完成和修复，最后以构建、检查、测试和多角度验证收尾。 覆盖从需求理解到最终验证的全流程； 适用于完全自动化的复杂任务执行； Ralph 会在执行后持续修复问题，提升交付质量。 系统流程较长——适合复杂任务，不适合轻量级调整； 每个阶段依赖前一阶段——上游理解偏差会污染下游； 需要明确的验收标准，否则后期验证质量会下降。 3. MiniMax Agent Team：在受约束的多智能体循环基础上，赋予每个智能体更多自由度 MiniMax 的 Agent Team 是一个多智能体系统，由主智能体主导，将复杂任务拆解为并行子任务分发给一批智能体，并内置对抗性质量关卡——这是一个由确定性代码逻辑驱动的智能体循环。受 Ralph-Loop 和 Harness 启发，我们认识到模型上下文非常宝贵；通过拆分任务和分类职责，每个步骤都能获得上下文隔离，从而提升智能体输出的整体质量。 Leader、Worker 和 Verifier 的基本协作流程 要将多智能体从概念转化为可用的产品，需要一个基本的协作流程。我们将其简化为三种角色类型：Leader、Worker 和 Verifier。 Leader 将用户目标转化为任务结构。 Worker 执行具体的子任务。不同的 Worker 可以拥有不同的工具、上下文和输出要求。有些 Worker 负责调研，有些负责编辑代码。Worker 的价值在于专业化：角色越清晰，Worker 的输出就越容易被复用、比较和审查。 Verifier 将"做完了"转变为"可以交付了"。它可以检查来源、覆盖清单和风险边界，也可以对 Worker 的结果提出修改建议。这体现了 Agent Team 的设计逻辑：Worker Agent 和 Verifier Agent 处于对抗关系。两者都以完成为目标，但一个完成会触发另一个启动——就像公司内部的研发和质检，通过多轮对抗迭代交付高质量结果，而无需 CEO（人类用户）进行微观管理。 与只能创建任务并接收单轮结果的任务工具相比，智能体团队是一个你可以随时与之互动的团队。 传统任务工具通常停留在模型工具调用层：主智能体调用一个任务/调度/生成式工具，传入提示词，然后等待子智能体返回一段文本或摘要。这种机制适用于短周期、低风险、局部探索性任务——例如，让另一个模型快速搜索文件、总结材料、验证某个想法或生成候选答案。尽管目前后台已有子智能体在运行，但智能体之间的通信本质上仍是单次输入/输出——没有多轮对话，也无法实时报告问题和冲突。 为了保持团队稳定运行，我们选择了一个可靠的状态机来管理每个智能体的运行生命周期。一个生命周期就是一个会话，而状态机就是团队引擎。团队引擎通过“生成→验证→完成”来管理每项任务。当验证失败时，团队引擎会再次唤醒生成节点以继续编辑。领导者全程获取团队引擎的最新状态，可以主动确认任务细节，甚至可以向当前正在运行的生成或验证智能体发送补充提示词。协作关系不再局限于一次函数调用，而是在多轮交互中变为主动推送加按需查询。 每次智能体团队运行都具有长期价值。本次运行的经验可以沉淀到记忆和技能中，从而使每个具体智能体在如何与用户协作、高效完成任务方面变得更加主动，也让所有智能体更了解用户。 智能体间通信设计：智能体与人类拥有同等权利。 在设计智能体应如何协作时，最直接的思路是观察当前人类与智能体的协作方式。用户可以通过前端界面提示、生成、中止和终止一个智能体，这意味着智能体本身也应该能够对另一个智能体执行这些操作。我们将用户对智能体的操作抽象为一个接口，而这些操作的实际执行者可以是用户、另一个智能体，或者智能体团队引擎。 当然，这种设计必须保持其边界：“平等权利”并不意味着智能体获得无限权限，也不意味着人类退出问责链条。恰恰相反——只有当智能体与人类共享同一个可审计的协作界面时，权限、责任和风险才更容易被看清。 3.1. 核心场景一：即时通讯集成，异步执行与快速响应 即时通讯交互的约束条件很特殊。当用户发送消息时，他们期望在几秒内得到反馈，但许多任务天然需要几分钟甚至几小时才能执行完毕：研究、起草会议纪要、制作幻灯片、运行测试。如果系统让用户等待最终结果，体验就会变成“智能体在聊天框里消失了”。 单个智能体在这里很容易陷入两难境地：要么为了快速回复而给出浅显的答案，要么以长时间沉默为代价完成完整任务。更糟的是，即时通讯对话会持续进行——用户可能会在任务执行中途提出新需求、切换话题或提出另一个问题。如果长时间任务和当前对话绑定在同一个上下文中，系统既无法保持响应速度，也无法避免后台任务被新消息污染。 这与 Google A2A 协议中关于长时间运行任务、状态更新和人在回环的设计原则相呼应。Anthropic 的托管智能体博客文章指出，“会话不等同于模型上下文窗口”，长时间任务需要一个可恢复的会话日志作为外部上下文对象。 行业共识正在形成：IM 异步执行的根本逻辑在于，当一个任务跨越多个消息轮次、多个工具和多个智能体时，你无法依赖任何一个模型的当前上下文保持完整。系统必须将任务状态、事件日志、文件产物和决策记录作为可恢复的对象进行持久化。智能体协作本质上是一项有状态的长期任务。 IM 异步执行场景 3.2. 核心场景二：编码框架（Coding Harness） Agent Team 项目大量借鉴了框架（Harness）的思维模式。框架比“智能体写代码”更进一步：智能体必须遵循完整的开发生命周期——代码存在于分支上，执行在沙箱中，编辑以差异（diff）形式呈现，测试可重新运行，审查留有记录，失败可回放，必要时任务可按角色拆分。智能体的停止条件与确定性的、可观测的外部系统绑定。 编码任务中开发者/测试者/审查者的角色分工 一个精心设计的编码框架（Coding Harness）至少包含四种角色类型。 领导者（Leader）是控制平面。它首先判断任务是否值得启动一个团队：修复拼写错误或替换常量可能由单个智能体或脚本完成成本更低；而跨文件理解和并行比较不同方案才是团队（Team）的用武之地。它还决定任务的粒度：是否先阅读代码，是否并行探索方案，是否先编写复现测试，失败时重试多少次，以及何时升级到人工处理。 开发者（Developer）负责实现，拥有明确的工作简报：需求、相关文件、项目约束和禁止操作。其输出不仅是自然语言解释，还包括变更原因、潜在风险和验证建议。 测试者（Tester）将“看起来能运行”转变为“有外部证据支撑”。它定位现有测试入口，压缩失败日志，并在需要时添加最小复现用例。关键在于以工具为根基：验证结果来自命令、测试或可执行的检查。 审阅者与测试者不同。测试回答的是“它通过了已知检查吗？”；审阅关心的是“应该以这种方式修改吗？”它检查抽象边界、兼容性、错误处理、引入的依赖项、权限扩展，以及日志是否泄露敏感信息。审阅者还可以并行运行，并具备专业化分工：一个负责可维护性的通用审阅者，一个负责输入/凭证/网络边界的安全审阅者，一个负责业务语义的领域审阅者。 自动化测试、代码审查和人工验收如何衔接 第一层是自动化测试和静态检查。Harness 将测试、代码检查、构建和格式检查视为一等公民。在开发者修改代码后，测试者运行验证；如果失败，由领导者决定是让开发者修复、要求测试者提供更多日志，还是上报环境问题。 第二层是代码审查。一个审阅者智能体可以自动进行第一轮检查，以捕获未使用的变量、遗漏的异常分支、公共 API 破坏、危险的 shell 调用、日志中的密钥、超出范围的文件编辑等问题。 3.3. 核心场景三：并行信息检索与研究 单个智能体会遇到研究速度慢、上下文被污染或危险注入、证据在上下文中丢失以及研究方向有偏差的问题。智能体团队的价值在于将研究拆分为并行的信息通道，然后通过验证者和综合者将结果合并为结构化的结论。重点在于设计一个可信的研究流程，该流程既快速，又能摆脱单个智能体的思维定式，从不同角度和正反两方面收集并确认信息。 独立的验证者如何减少引用错误和事实性模型幻觉 验证者首先检查来源的可验证性。正式来源应使用稳定的 URL：官方页面、会议页面、作者博客。搜索缓存和聚合页面只能作为线索，不能作为正式结论的证据。验证者还会检查来源状态是否过时，以及是否存在反证来否定该说法的真实性。 并行信息检索与研究 3.4. 核心场景四：流水线式办公文档撰写 当单个智能体撰写文档时，最容易产生的错觉是：只要模型能写，就能交付。当用户说“帮我创建一份报告/Excel/PDF”时，单个智能体通常会先生成一大段文本，然后尝试一次性完成格式化、检查和修正。短文档可以靠一个上下文窗口撑过去；一旦任务变成长篇报告、正式合同或财务电子表格，问题就会迅速暴露：内容规划、素材来源、结构一致性、图表对象、页眉/页脚以及导出质量，全部挤在一个上下文和一个执行循环里。 智能体团队将结果从“可生产”提升到“可交付” 多智能体协作将文档交付拆分为多个可验证的阶段。规划器首先定义文档目标和结构；写作器生成正文；格式化器处理布局和文件对象；评估器独立检查内容、格式和文件完整性。这种拆分将“文档生成”从一次性文本生成转变为更接近 CI/CD 构建流水线的方式：每个步骤都产生中间产物，每个步骤都有检查，每个步骤在失败时都可以在本地重试。 流水线式办公文档写作 4. 开发过程中的难题与反思 团队协作带来的上下文成本 一组协作的智能体会暴露出一种新的成本：交接成本、共享成本和聚合成本。这些成本没有一个是“靠稍微大一点的模型上下文窗口就能解决的”。 交接成本：同一份信息需要在智能体之间重新组织。研究智能体收集了几十页资料后，将其交接给写作智能体。写作智能体需要一份已经经过初步研究的文档。写作智能体还必须将写作结果交接给格式检查智能体。目前我们通过制作交接产物来处理这个问题：1) 可读的交接文件，2) 跨智能体的共享记事本文件。工作节点通过文件路径加摘要的方式进行缓慢且无干扰的通信，避免一次性把所有内容塞进上下文。 共享成本：即“让每个智能体都能看到所有信息”的代价。每多共享一个部分，每个工作单元在每一轮都要消耗额外的模型 token。当某个智能体在执行中途遇到问题时，它应当以正确的方式写入记忆，以便将该经验广播到所有正在运行和即将启动的智能体的上下文窗口中。我们采用三种方式来维护这类共享信息：1）智能体内部记忆——该智能体在本轮运行中的经验；同一智能体的后续运行会获得提示，正在运行的智能体也会立即收到通知；2）智能体间通信 CLI——智能体可以直接与其他运行中的节点进行中断式通信；3）前面提到的白板——与 1 和 2（均为主动通知）相比，白板支持持久化存储更大体量的信息，其他智能体可以在需要时按需更优雅地拉取。 聚合成本：将多个工作单元的输出合并为一份可交付成果所需的工作量。并行收集 10 个版本的材料很容易，但要将它们合并成一篇事实一致、引用对齐、风格统一文章却很难。在这一步，领导者的任务是“将 10 份合并为 1 份”，而不是“再叫几个人来提供更多材料”。认识到这一成本高昂，是设计团队的第一步。 时间/模型 token 消耗与结果投入产出比之间的权衡 以往研究中的多智能体很少与高投入产出比划等号。论文《共识的成本》声称，在特定模型和同质化辩论设置下，消耗量可达独立自我修正的 2.1–3.4 倍模型 token，而准确率不仅没有提升，有时反而下降。结论很明确：没有结构、没有停止条件的“更多”只是在并行地扩散不确定性——一个简单的 AI 聊天室很难保证最终输出的质量。 投资回报率还包括用户的等待时间。尽管我们将长任务改为异步执行，并允许用户随时与主智能体对话——从而减少了用户对即时交互的需求——但整体交付时间仍然在增加。与单个智能体一次性完成所有任务相比，智能体团队不可避免地要按 1-2-3-4 的顺序执行。我们思考了很多关于如何控制合理的拆分粒度，以及如何平衡“大任务交付效果差”与“过度拆分导致交付过慢”的问题。我们相信，随着模型智能的提升，在后台运行团队并在完成后主动报告，是用任务结构来换取“在同一对话中盯着智能体缓慢生成”的心理成本。多智能体的价值与成本在此同时显现：用户愿意为可验证、可恢复、可审计的结果等待更长时间——只要过程是透明的。 我们相信，一旦用户看到智能体团队交付的高质量结果，他们对智能体的信任就会提升，从而释放自己的带宽，进行更深入、更广泛的思考——做一个拥有人文关怀的思考者，而将思考的执行和结果的交付任务交给智能体团队。 验证器、重试和主智能体决策的成本 验证器是团队从演示走向交付的关键。 第一个成本是验证本身。编码任务需要运行测试；研究任务需要交叉核对来源并确认引用边界；验证越严格，成本就越高；流于形式的验证只会带来一种虚假的“似乎通过了”的感觉。 第二个成本是重试策略。如果一个工作智能体持续陷入“修改一点——被验证器拒绝——再修改一点”的循环，整个方案的成本只会越来越高。 第三个成本是主智能体的决策不能模糊。在面对高风险操作时——如合并代码、覆盖生产数据——最终判断必须由人类签字确认。GitHub Copilot 云端智能体的官方文档将整个流程保留在 GitHub 内部：方案、提交、日志和拉取请求都可供团队审查；更新日志还指出，在拉取请求最终确定之前会进行安全性和质量分析。 它所指向的方向很明确：智能体交付不仅包含结果，还包含一条可回放、可问责的轨迹。 多智能体系统是一个运行时，而非提示词编排 跳出模型和上下文，回到我们构建系统的方式：多智能体常常被简化为“写几个提示词/技能，让模型扮演角色”。在我们的实际代码中，这种简化仅仅是初始演示；真正的复杂性隐藏在细节之中，所有这一切都是为了用户能享受“只需聊天”的流畅体验。团队引擎需要管理许多复杂的对象和状态转换，以便智能体团队的运行足够自动化且可观测。渲染层必须吸收来自多个参与者（用户、智能体、团队引擎等）对同一概念的操作：例如“创建任务”可能来自多个来源。渲染复杂性的另一个来源是消息来源。除了用户与智能体的对话，还有智能体之间的对话、来自定时任务的消息、团队引擎的周期性监控，以及来自即时通讯工具的用户消息。背后这些繁重的软件工程工作，全都是为了让用户从一个整洁的界面浏览精心排列的信息源。 行业资料也指向了同样的方向。OpenAI Agents SDK 的官方文档强调了沙箱、工作空间、交接和追踪；AWS AgentCore 的官方发布将运行时、内存、身份、网关、浏览器列为企业级模块。它们共同表明一件事：智能体产品的重心正在从“编写提示词”转向“维护控制平面”。 承认智能体团队是一个运行时，会改变产品判断。新功能不能仅靠提示词来修补——它们需要运行时中的事件和可观测性；权限、运行时约束和内存写入约束不能仅依赖智能体的自律——它们需要适当的软/硬门控和拦截器。将多智能体作为运行时来维护，远比将其作为提示词模板来维护要繁重得多，但只有这样，它才能可靠地服务于实际工作。 5. 经验教训 5.1 多智能体的存在是为了更可靠地完成复杂任务 多智能体的核心在于结构。没有结构的多智能体，只是更昂贵的并发执行；而有结构的多智能体，则是一个可委派、可并行、可验证的执行系统。 因此，在判断一个多智能体产品是否有价值时，不要看它能同时启动多少个智能体。要看它能否回答几个问题：为何拆分、如何验证、何时停止、如何从故障中恢复、如何管理记忆。答案越清晰，多智能体就越像一个生产系统；答案越模糊，它就越像一个演示用的群聊。 5.2 团队价值取决于任务复杂度，但 ROI 不能仅凭短期判断 团队模式只是其中一种选择。任务越长、链条越深、风险越高、经验越可复用——团队模式带来的收益就越有可能超过其成本；任务越短、风险越低、确定性越强，单个智能体或经典自动化方案就越占优势。我们不应鼓励用户“凡事都拉起一个团队”，而应帮助他们判断何时协作值得投入，何时应保持简洁。 无论你选择团队模式还是单个智能体来执行任务，你仍然需要记忆、技能以及类似的机制，以便智能体能够在长期内持续进步。即使团队模式消耗了更多 token 和更多时间，智能体也应该带着更丰富的经验和记忆离开。从长远来看，一个更了解用户、经验更丰富的智能体的成长，应该被纳入 ROI 的计算之中。因为一旦我们相信某个智能体拥有足够的记忆和技能，团队模式就应该是该智能体最省心的执行方式。 5.3 未来的智能体将更像一个长期的数字团队 遵循“智能体间通信设计：智能体与人类拥有平等权利”中提到的设计思路，未来的智能体产品将向人类和智能体双方开放完全对等的控制接口与数据流。人类将更多地依赖管理面板来配置智能体的角色、能力和边界，分配任务，并在关键检查点交由人类判断。而该面板本身也可以由智能体控制。整体运行状态可能更接近前面提到的低效AI聊天室。AI能否完全接管管理与调度，使管理面板/团队引擎变得越来越轻量——这仍有待更强大的模型出现。 多智能体的存在是为了将AI从“一次性工具”转变为“长期伙伴”——并从提升个人效率，转向将人类从具体的执行工作中解放出来。 6. 开源及使用方法 我们最新的MiniMax智能体即将开源。考虑到工作规模及内部迭代速度，开源版本预计将与MiniMax M3模型一同发布。 在开源之前，我们的桌面应用已正式发布，欢迎下载试用：