AAGENT ATLAS资料库

A FIELD GUIDE TO MULTI-AGENT DEVELOPMENT

让多个 Agent,
协作成一个系统。

从开发方法到执行调度,理解多 Agent 开发系统的七种形态、协作方式与能力边界。为你的下一个项目,找到合适的起点。

07 系统类别05 协作模式14 代表项目
START WITH THE DISTINCTION

产品负责什么Agent 如何协作

两条独立的轴,一起看才完整。

THE LANDSCAPE

七类系统,各有所长。

按主要职责理解这个生态。分类是选型工具,
不是严格分区;同一产品可以横跨多个类别。

左右滑动查看全部 7 类系统

SPECIFICATION & GOVERNANCE

规格与任务治理

把需求、设计与验收条件写成可追踪的仓库产物,让人和 Agent 围绕同一份规格协作。

这一类系统回答做什么?什么才算完成?

重点解决

  • 明确需求、范围与验收标准
  • 将设计拆成可分派的工作包
  • 记录评审、接受与合并决策

能力边界

规格本身不会替你启动 Agent、恢复进程或解决代码冲突。Spec Kitty 延伸到任务状态与工作区治理,覆盖范围比纯规格工具更广。

代表项目 · 展开了解定位与区别

OpenSpec

围绕每次变更组织提案、规格、设计与任务,允许迭代修改这些产物。适合希望在已有项目中逐步引入规格管理的团队。

阅读官方资料 ↗(新窗口打开)
Spec Kit

从项目原则开始,沿规格、技术计划、任务、实施与收敛检查推进。适合希望统一规格驱动开发流程与模板的团队。

阅读官方资料 ↗(新窗口打开)
Spec Kitty

进一步管理工作包生命周期、评审、验收与合并决策,提供隔离的 Git worktree 和可选看板。适合需要让多名执行者保持任务边界与状态一致的项目。

阅读官方资料 ↗(新窗口打开)

举个例子:登录功能先定义登录方式、失败表现与验收用例,再交给执行者实现。

METHODS & DEVELOPMENT SKILLS

开发方法与 Skills

把需求讨论、架构思考、实施、测试和评审组织成可复用的开发方法,嵌入现有 coding agent。

这一类系统回答应该怎样完成这项开发工作?

重点解决

  • 为不同阶段提供角色与工作指引
  • 明确设计、测试和代码评审的步骤
  • 通过可组合 Skills 复用开发经验

能力边界

写在提示词里的规则,执行效果取决于宿主 Agent、工具与上下文。方法与 Skills 不天然提供进程恢复、并发控制或不可绕过的验收关卡。

代表项目 · 展开了解定位与区别

BMAD Method

覆盖产品、架构、UX、开发与测试等视角,并根据任务规模调整规划深度。方法产物可以带入已有交付流程;与 bmad-loop 配合时,再加入程序控制的执行闭环。

阅读官方资料 ↗(新窗口打开)
Superpowers

以可组合 Skills 组织需求讨论、设计、细粒度计划、开发、测试与评审。适合希望在既有 coding agent 上建立一致开发纪律的使用者。

阅读官方资料 ↗(新窗口打开)

举个例子:开始实现收藏功能前,先澄清取消收藏的行为,再制定计划、写测试并安排独立评审。

LEAD AGENT ORCHESTRATION

主 Agent 编排

由主 Agent 理解整体目标、拆解任务并分派给子 Agent,在独立上下文中工作,再汇总结果推进交付。

这一类系统回答大任务怎样拆开,又怎样收回来?

重点解决

  • 把任务拆成边界明确的子问题
  • 按依赖关系分批或并行执行
  • 控制上下文体积,汇总发现与决策

能力边界

新的对话上下文并不等于独立的代码工作区。主 Agent 也可能成为信息和决策瓶颈;子任务输入、输出与验收必须足够清晰。

代表项目 · 展开了解定位与区别

GSD Core

围绕讨论、规划、执行、验证和交付组织阶段循环,强调研究、规划与实施使用新的子 Agent 上下文,并用持久化产物支持跨会话推进。

阅读官方资料 ↗(新窗口打开)
Claude Code

提供子 Agent 与 Agent Teams 两种相关能力。前者主要向调用者返回结果;后者允许团队成员直接通信和共享任务。Agent Teams 仍标为实验性功能,不能把两者的恢复行为视为相同。

阅读官方资料 ↗(新窗口打开)

举个例子:主 Agent 先拆出数据模型、API 和界面任务,约定接口后并行实施,最后检查集成结果。

PROGRAMMATIC DEVELOPMENT LOOPS

程序控制的开发闭环

将任务选择、状态转换、重试预算与完成检查交给程序;让 Agent 在受控流程里完成实现、评审和修复。

这一类系统回答下一步做什么,由什么条件决定?

重点解决

  • 用明确状态机推进开发步骤
  • 验证产物、状态与测试结果的一致性
  • 保存运行状态,限定重试与停止条件

能力边界

控制流程的确定性不等于生成代码的正确性。系统只能验证你定义的条件;错误或不完整的验收标准仍可能让有问题的代码通过。

代表项目 · 展开了解定位与区别

bmad-loop

以 Python 驱动选择故事、实施、独立评审、验证和提交。开发与评审使用独立会话,程序核对磁盘产物和 Sprint 状态;支持恢复与按阶段选择 coding CLI。目前仍是早期公开测试版。

阅读官方资料 ↗(新窗口打开)

举个例子:评审发现缺陷后进入修复;测试失败时不提交;达到重试上限后记录阻塞原因并停止。

RUNTIME & FLEET SCHEDULING

多 Agent 运行与调度

管理一组正在工作的 Agent、工作区与任务队列,让并行执行、故障恢复、交接和代码合并具备可观察的秩序。

这一类系统回答很多任务同时运行,怎样保持有序?

重点解决

  • 控制并发、分派任务与资源使用
  • 监控卡住或失败的执行者并恢复
  • 隔离工作区,组织交接与合并队列

能力边界

调度器能安排谁执行,却未必能判断需求是否合理。工作区分开后,依赖、接口冲突与合并后的集成测试仍需要专门处理。

代表项目 · 展开了解定位与区别

Gas Town

围绕协调者、工作 Agent、监控者与合并队列管理开发工作。其 Scheduler 控制分派容量,Refinery 在合并队列中执行验证关卡,适合研究多个执行者持续运行的基础设施。

阅读官方资料 ↗(新窗口打开)
OpenHands

Agent Canvas 提供编码 Agent 的控制中心,可连接本地、远程与云端后端,并通过自动化触发工作。它覆盖运行管理,但具体任务闭环仍取决于所用 Agent 与自动化定义。

阅读官方资料 ↗(新窗口打开)

举个例子:十个工作包进入队列,只允许三个同时执行;一个失败后恢复,完成的分支经验证后有序合并。

INTEGRATED DEVELOPMENT PLATFORMS

集成式 AI 开发平台

将 Agent、执行环境、任务界面和协作入口整合起来,提供从接收任务到运行、检查与交付的整体使用体验。

这一类系统回答能否直接把任务交给一套完整平台?

重点解决

  • 提供现成的执行环境与任务入口
  • 在统一界面查看运行过程和结果
  • 整合并行会话、自动化和开发工具

能力边界

平台覆盖面广,但具体控制能力、环境限制和成本需逐项确认。能同时打开多个会话,不代表会自动处理任务依赖或整合结果。

代表项目 · 展开了解定位与区别

Devin

协调会话可以拆分大型任务,启动运行在独立虚拟机中的 managed Devins,监控进度并汇总结果。适合评估完整平台如何处理批量迁移、多模块工作和持续交付。

阅读官方资料 ↗(新窗口打开)
OpenHands

生态包含 Agent Canvas、软件 Agent SDK、Agent Server 与自动化组件,支持本地、自托管与云端运行。既可以使用整合后的体验,也可以按组件构建自己的系统。

阅读官方资料 ↗(新窗口打开)

举个例子:向平台提交一组库迁移任务,查看每个子任务的工作环境与变更,再逐项验收生成的结果。

GENERAL-PURPOSE AGENT FRAMEWORKS

通用多 Agent 框架

提供组织 Agent、状态、消息和工具的编程构件,让开发者自由定义协作逻辑、持久化策略与业务流程。

这一类系统回答怎样构建属于自己的 Agent 系统?

重点解决

  • 定义图、任务、事件或角色协作
  • 连接模型、工具、记忆与运行状态
  • 实现人工介入、持久化与可观察性

能力边界

框架不是开箱即用的软件开发流程。你需要补齐任务模型、代码仓库操作、执行环境、验收规则和产品界面,并承担这些组件的维护责任。

代表项目 · 展开了解定位与区别

LangGraph

以图和状态组织长时间运行的 Agent,提供持久执行、记忆和人工介入等基础能力。适合需要细粒度定义执行路径与恢复行为的自研系统。

阅读官方资料 ↗(新窗口打开)
CrewAI

Crews 组织基于角色的 Agent 协作,Flows 提供事件驱动的流程控制。两者可以组合,适合把灵活的角色协作放进有结构的业务流程。

阅读官方资料 ↗(新窗口打开)
Microsoft Agent Framework

提供顺序、并发、交接与团队协作等编排能力,以及检查点、可观察性和人工介入机制。适合需要在既有应用与服务中构建 Agent 工作流的团队。

阅读官方资料 ↗(新窗口打开)

举个例子:团队自行实现“读取需求 → 规划 → 分配隔离环境 → 编码 → 独立验收 → 提交 PR”的状态图。

先辨认你得到的是什么。 规格与 Skills 可以服务单 Agent;编排能力需要执行环境;通用框架需要你自己补齐开发流程。它们的交付范围不同。

COMPARE THE RESPONSIBILITIES

相似的功能名,不同的责任边界。

不做没有依据的评分。比较谁控制流程、
谁记录状态,以及你需要补齐什么。

左右滑动对照表,查看全部能力维度

按控制方式、核心产物、人工责任和典型场景比较七类系统
系统类别主要控制方式核心产物 / 状态你需要负责典型场景
规格与任务治理人定义意图,工作流管理产物规格、计划、工作包、评审状态确认需求与验收边界需求反复、多人协作、可追溯交付
开发方法与 Skills宿主 Agent 遵循 Skills 与指引设计文档、计划、测试与评审结果选择适当流程并审阅关键决策开发随意、缺少测试、评审不一致
主 Agent 编排主 Agent 动态规划与分派任务上下文、计划、汇总与进度明确目标、接口与需要介入的决策长任务、上下文膨胀、模块化实施
程序控制的开发闭环程序状态机与明确的条件判断运行状态、事件、产物与验证证据配置可靠的测试、预算与退出条件反复返工、状态漂移、中断续跑
多 Agent 运行与调度队列、调度程序与协调 Agent任务分派、工作区、运行与合并状态定义资源限制、依赖与合并策略多任务常驻运行、跨工作区交付
集成式 AI 开发平台平台提供的 Agent 与自动化机制会话、环境、任务记录和代码产物配置项目环境、约束并验收成果希望直接使用完整工作环境
通用多 Agent 框架由你定义的代码、图与 Agent自定义状态、检查点、消息与事件构建并维护整套开发系统自研平台、定制流程、系统集成

表中描述各类别的典型侧重,不代表所有产品的默认配置,也不构成性能或成熟度排名。

CONTEXT

上下文隔离

让不同 Agent 使用各自的对话与信息,控制上下文体积,减少相互影响。

WORKTREE

代码工作区隔离

让任务在不同分支和目录中修改文件。仍需处理合并冲突、依赖和集成测试。

SANDBOX

执行环境隔离

通过容器或虚拟机分开进程、依赖与运行资源。隔离范围取决于具体配置。

COLLABORATION PATTERNS

同一套工具,可以有不同的组织方式。

协作模式描述 Agent 之间的关系。
一个开发流程里,通常会组合使用多种模式。

左右滑动查看全部 5 种协作模式

一步一个角色,沿产物交接。

将开发拆成有先后顺序的阶段。每个 Agent 接收上一步的产物,完成自己的职责,再交给下一位执行者。

适合什么

适合输入输出清楚、前后依赖明确的标准流程;便于检查每个阶段的产物。

需要权衡

前期误解可能沿流程传播,串行步骤限制整体速度。需要设置回退和纠错路径。

相关机制参考:BMAD Method ↗(新窗口打开)

分派局部问题,保持整体目标。

主 Agent 制定计划、确定任务边界,将工作交给子 Agent。子 Agent 返回成果后,由主 Agent 汇总、判断下一步并处理依赖。

适合什么

适合长任务、模块化开发和上下文较多的调查。主 Agent 可以集中维护整体决策。

需要权衡

主 Agent 可能成为瓶颈。子任务说明过少会丢失背景,过多又会增加成本与干扰。

相关机制参考:GSD Core ↗(新窗口打开)

任务独立时,让工作同时发生。

把目标拆成可以独立开展的工作包,同时运行多个 Agent,再对输出进行集成或汇总。拆分依据可以是模块、文件集合或调查方向。

适合什么

适合批量迁移、模块独立实现和多角度研究;并行部分有机会缩短等待时间。

需要权衡

共享接口、文件冲突和集成验证都会产生额外成本。任务越相互依赖,并行收益越不确定。

相关机制参考:Devin Managed Devins ↗(新窗口打开)

成员直接交流,共享发现。

Agent 不只向协调者汇报,也可以通过消息与共享任务直接沟通,相互挑战假设或调整分工。团队仍可以保留负责人。

适合什么

适合复杂问题调查、跨层协调和多视角评审;新发现可以及时影响其他成员。

需要权衡

通信增加模型用量与协调成本。需要明确任务归属、决策记录与结束条件,避免反复讨论。

相关机制参考:Claude Code Agent Teams ↗(新窗口打开)

用新的视角检查实施结果。

由一个 Agent 实施,另一个 Agent 根据规格、代码和测试证据进行独立评审。发现问题后退回修复,再次验证,直到满足条件或触发停止规则。

适合什么

适合需要检查规格符合性和代码质量的工作;可以将评审与实施的上下文分开。

需要权衡

评审同样可能漏错,也可能提出无效修改。需要以证据判断反馈,并设置返工预算。

相关机制参考:bmad-loop ↗(新窗口打开)

FIND YOUR STARTING POINT

先找到问题,再选择系统。

从当前最大的开发阻力出发,选择能补齐那一层能力的工具。

需求总在变,Agent 容易跑偏

先建立规格、验收标准与变更记录。小范围试用 OpenSpec 或 Spec Kit;需要工作包、评审状态与并行工作区时,再看 Spec Kitty。

代码能写出来,开发过程不稳定

先补齐设计、测试和评审纪律。研究 Superpowers 的可组合 Skills,或 BMAD 的分阶段方法,并对实际执行情况进行检查。

任务太长,做到一半就丢上下文

研究 GSD 的阶段循环与独立上下文。明确每个子任务的输入、产物和验收标准,再考虑并行拆分。

进度显示完成,产物却没有通过验证

关注程序控制的状态与验证关卡。研究 bmad-loop 如何核对产物和任务状态,并为失败设置明确的重试预算。

任务越来越多,手动管理会话很累

关注 Gas Town 的调度、监控与合并队列。也可评估 OpenHands 的运行控制台,确认各自的环境与运维成本。

FROM PROMISE TO EVIDENCE

用一次小实验,验证你的选择。

“支持并行”是一项能力。
是否更快、更可靠,需要同一任务下的证据。

BENCHMARK BRIEF

给一个已有应用
增加「项目收藏」功能。

包含数据库变更、API、列表交互与测试。提前写清验收标准,并保留一份独立验收用例。

同一仓库起点同一任务范围记录模型与预算

这是建议的评估方法,本网站未执行各产品的横向性能实测。

  1. 记录完整交付成本

    从接收需求到验收通过,统计总耗时、模型用量、人工介入和返工次数。

  2. 制造一次中断

    在实施或评审阶段停止进程,再恢复。检查是否重复执行、丢失进度或跳过验证。

  3. 保留一个失败测试

    观察系统会修复、阻塞还是错误地宣布完成;确认结果与任务看板一致。

  4. 检查并行工作的整合

    让两个任务涉及同一接口,观察冲突处理,并对合并后的整体重新测试。