“帮我整理一篇关于 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 个修改”。这是因为模型普遍存在上下文焦虑，对于超长任务的训练本身需要投入大量的金钱、时间成本和算法优化。模型对于一个任务什么时候可以停止的判断是模糊的。
2. 当前行业中的多 Agent 合作实践
3. MiniMax Agent Team：在约束多 Agent 循环的基础上，给予每个 Agent 更高的自由度
MiniMax 的 Agent Team 是一个由某个主 Agent 牵头，把复杂任务拆成多个可并行的任务分配给一批 Agent 并发执行,自带对抗性的质量门禁的多 Agent 系统，是确定性的代码逻辑驱动的 Agent 循环。我们受到了 Ralph-Loop 和 Harness 思想的启发，意识到大模型的上下文是宝贵的，通过拆分任务和职责分类，让每个环节的 Context 隔离，提高整体的 Agent 产出质量。
- Leader 负责把用户目标转化为任务结构。
- Worker 负责执行具体子任务。不同 Worker 可以拥有不同工具、上下文和输出要求。有的 Worker 做资料检索，有的做代码编辑。Worker 的价值在于专业化：角色越清楚，Worker 的输出越容易被复用、比较和检查。
- Verifier 负责把”完成了”变成”可以交付”。它可以检查事实来源、覆盖清单、风险边界，也可以对 Worker 的结果提出修改意见。
producing、verifying、done 去管理每一个任务。当 verifying 未通过时，Team Engine 会重新唤起 producing 节点继续修改。Leader 在这个过程中即会收到 Team Engine 的最新状态汇报，也可以主动确认具体的任务细节，甚至可以随时向正在运行的 producing、verifying 的 Agent 发送补充 prompt。协作关系不再被限制为一次函数调用，而是变成主动推送、按需查询的多轮交互。
每一次 Agent Team 的运行都是有长期价值的。本次执行的经验也可以沉淀为记忆、Skill，让每个具体的 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 看业务语义。
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 的上下文中。我们采用了三种方式来维护这类共享信息:- Agent 内的记忆：此 Agent 的一次经验，同样的 Agent 后续执行会收到提示，甚至执行中的 Agent 也会被立刻通知。
- Agent 之间的通讯 CLI：Agent 有能力直接和其他的运行节点对话，进行打断式的沟通。
- 白板能力：相比 1 和 2 的主动通知，白板能够支持保存更大量的信息，其他 Agent 在使用的时候也可以更优雅地按需获取。