Agent squads 强调不同代理的角色分工，fleets 强调多个代理并行运行，Managed Agents 则描述由服务平台托管代理执行的方式。企业是否需要多代理，应看任务能否独立拆分、结果能否合并，以及协调成本是否低于节省的时间。
角色分工、并行与托管是三种不同选择
GitHub 在 2026 年 9 月的术语解释中，用 squad 描述承担不同职责的一组代理，用 fleet 描述并行工作的组织方式。它们回答谁负责什么、哪些工作同时进行，并不直接决定代理运行在本地还是云端。
Anthropic 在 2026 年 4 月的工程文章中介绍了 Managed Agents 的托管思路，将会话、执行循环与沙箱等部分分开讨论。托管能够减少部分运行维护，但不会自动替团队定义任务目标、校验业务事实或解决角色之间的意见冲突。
什么时候一个代理就够用？
输入较少、步骤强依赖、结果容易检查的任务，通常先用一个代理更清楚。假设整理一份客户会议纪要，需要从原文抽取行动项，再核对负责人和日期；拆成多个代理可能只增加传递上下文的工作量。
若单代理失败，先检查是否缺少数据、工具和完成条件。把同一个模糊需求复制给更多代理，往往只会产生多份不同说法。多代理无法替代正确的问题定义，也不能用多数意见来判断业务事实。
哪些工作适合拆成多个代理？
不同资料源之间相对独立、可按统一口径汇总的任务更适合并行。例如分析一批公开产品说明，可以按产品分配检索任务，要求每个代理都交付功能证据、发布日期、适用范围和未确认事项，再由主流程合并。
任务之间应有明确接口。资料收集者不擅自生成采购结论，撰写者不把未确认事项改写为事实，复核者能够回到原始链接检查。这里的角色不是为了模拟公司组织图，而是为了减少遗漏和降低相互干扰。
如何防止多个代理改坏同一份成果？
把独立工作放在互不覆盖的文件或数据范围内，明确由谁负责最终合并。若代理共同修改一个文档，应使用可以检查差异的机制，并保留每次变更依据。无法隔离的写入应串行处理。
对于业务系统，任务分配还需要包含客户、订单或项目标识，防止多个代理重复创建记录。一个代理报告“已完成”，主流程仍应读取实际结果。内部消息是线索，业务系统与交付文件才是验收依据。
托管代理需要保留哪些任务状态？
长任务至少应保存任务目标、输入材料版本、已完成步骤、输出位置和异常原因。平台重新调度执行环境后，代理需要能从这些状态继续工作，而不是依赖某台电脑中未保存的终端会话。
Anthropic 的托管架构文章强调稳定接口与可演进执行系统之间的关系。对使用者而言，更实际的问题是：能否查看执行记录，能否停止任务，失败后能否重试，以及已经生成的文件和数据是否仍能找到。
费用与速度应该怎样比较？
并行可以减少墙上时间，却可能增加模型调用与重复读取成本。衡量时把协调、合并、复核和返工一起计算。假设三个代理各自总结相同资料，虽然同时完成，却未必比一个代理做一次结构化抽取更经济。
也不要只看单次试验的速度。持续运行时，任务排队、工具限流和平台资源约束都会影响结果。先用固定的一组真实任务比较单代理与多代理，再决定是否扩大，而不是因为工具支持并行就默认全部并行。
小团队最容易执行的起步方式
从一个主流程加少量独立执行者开始。主流程负责需求、任务分配和最终结果；执行者只处理明确范围；复核时检查来源和交付物，不把模型之间相互认可当成验证。
可以先记录每项任务的输入、负责人、状态和输出链接，直接复用现有项目文档与日志系统。等任务量和失败模式稳定后，再判断是否需要购买托管能力或开发更复杂的编排界面。组织多代理工作的核心是让职责和证据流动清楚。
怎样设计多代理之间的交接单？
可以用一份短文档统一交付格式：本任务覆盖范围、确认事实、证据链接、未确认事项和输出位置。以资料研究为例，每个代理都注明检索日期与资料版本，主流程只合并能回到来源核实的结论。遇到两个来源矛盾时，先核对对象、日期和上下文，不采用简单投票。
交接还要说明是否已经改变外部状态。生成了一份更新建议，与已经修改数据库是不同结果；保留的草稿地址，与公开可访问页面也不能互相替代。主流程在合并前回读实际记录，可以避免把多个代理的口头进度误写成整项工作已经完成。这种小而明确的约定，通常比增加更多角色名称更能提高协作质量。
官方资料与核验范围
本文资料核验日期为 2026 年 10 月 17 日。下列日期指对应公告或工程文章的发布日期，不代表概念首次出现；产品可用范围、版本与接入条件请以官方当前说明为准。文中业务案例为帮助理解而设计的假设示例，不是实测成绩或客户交付承诺。