规格与任务治理
把需求、设计与验收条件写成可追踪的仓库产物,让人和 Agent 围绕同一份规格协作。
重点解决
- 明确需求、范围与验收标准
- 将设计拆成可分派的工作包
- 记录评审、接受与合并决策
能力边界
规格本身不会替你启动 Agent、恢复进程或解决代码冲突。Spec Kitty 延伸到任务状态与工作区治理,覆盖范围比纯规格工具更广。
代表项目 · 展开了解定位与区别
举个例子:登录功能先定义登录方式、失败表现与验收用例,再交给执行者实现。
A FIELD GUIDE TO MULTI-AGENT DEVELOPMENT
从开发方法到执行调度,理解多 Agent 开发系统的七种形态、协作方式与能力边界。为你的下一个项目,找到合适的起点。
职责可以组合,产品可以跨层。
多 Agent 的价值,来自清晰的分工与可验证的结果。
THE LANDSCAPE
按主要职责理解这个生态。分类是选型工具,
不是严格分区;同一产品可以横跨多个类别。
左右滑动查看全部 7 类系统
把需求、设计与验收条件写成可追踪的仓库产物,让人和 Agent 围绕同一份规格协作。
规格本身不会替你启动 Agent、恢复进程或解决代码冲突。Spec Kitty 延伸到任务状态与工作区治理,覆盖范围比纯规格工具更广。
代表项目 · 展开了解定位与区别
举个例子:登录功能先定义登录方式、失败表现与验收用例,再交给执行者实现。
把需求讨论、架构思考、实施、测试和评审组织成可复用的开发方法,嵌入现有 coding agent。
写在提示词里的规则,执行效果取决于宿主 Agent、工具与上下文。方法与 Skills 不天然提供进程恢复、并发控制或不可绕过的验收关卡。
代表项目 · 展开了解定位与区别
覆盖产品、架构、UX、开发与测试等视角,并根据任务规模调整规划深度。方法产物可以带入已有交付流程;与 bmad-loop 配合时,再加入程序控制的执行闭环。
阅读官方资料 ↗(新窗口打开)举个例子:开始实现收藏功能前,先澄清取消收藏的行为,再制定计划、写测试并安排独立评审。
由主 Agent 理解整体目标、拆解任务并分派给子 Agent,在独立上下文中工作,再汇总结果推进交付。
新的对话上下文并不等于独立的代码工作区。主 Agent 也可能成为信息和决策瓶颈;子任务输入、输出与验收必须足够清晰。
代表项目 · 展开了解定位与区别
提供子 Agent 与 Agent Teams 两种相关能力。前者主要向调用者返回结果;后者允许团队成员直接通信和共享任务。Agent Teams 仍标为实验性功能,不能把两者的恢复行为视为相同。
阅读官方资料 ↗(新窗口打开)举个例子:主 Agent 先拆出数据模型、API 和界面任务,约定接口后并行实施,最后检查集成结果。
将任务选择、状态转换、重试预算与完成检查交给程序;让 Agent 在受控流程里完成实现、评审和修复。
控制流程的确定性不等于生成代码的正确性。系统只能验证你定义的条件;错误或不完整的验收标准仍可能让有问题的代码通过。
代表项目 · 展开了解定位与区别
以 Python 驱动选择故事、实施、独立评审、验证和提交。开发与评审使用独立会话,程序核对磁盘产物和 Sprint 状态;支持恢复与按阶段选择 coding CLI。目前仍是早期公开测试版。
阅读官方资料 ↗(新窗口打开)举个例子:评审发现缺陷后进入修复;测试失败时不提交;达到重试上限后记录阻塞原因并停止。
管理一组正在工作的 Agent、工作区与任务队列,让并行执行、故障恢复、交接和代码合并具备可观察的秩序。
调度器能安排谁执行,却未必能判断需求是否合理。工作区分开后,依赖、接口冲突与合并后的集成测试仍需要专门处理。
代表项目 · 展开了解定位与区别
围绕协调者、工作 Agent、监控者与合并队列管理开发工作。其 Scheduler 控制分派容量,Refinery 在合并队列中执行验证关卡,适合研究多个执行者持续运行的基础设施。
阅读官方资料 ↗(新窗口打开)Agent Canvas 提供编码 Agent 的控制中心,可连接本地、远程与云端后端,并通过自动化触发工作。它覆盖运行管理,但具体任务闭环仍取决于所用 Agent 与自动化定义。
阅读官方资料 ↗(新窗口打开)举个例子:十个工作包进入队列,只允许三个同时执行;一个失败后恢复,完成的分支经验证后有序合并。
将 Agent、执行环境、任务界面和协作入口整合起来,提供从接收任务到运行、检查与交付的整体使用体验。
平台覆盖面广,但具体控制能力、环境限制和成本需逐项确认。能同时打开多个会话,不代表会自动处理任务依赖或整合结果。
代表项目 · 展开了解定位与区别
生态包含 Agent Canvas、软件 Agent SDK、Agent Server 与自动化组件,支持本地、自托管与云端运行。既可以使用整合后的体验,也可以按组件构建自己的系统。
阅读官方资料 ↗(新窗口打开)举个例子:向平台提交一组库迁移任务,查看每个子任务的工作环境与变更,再逐项验收生成的结果。
提供组织 Agent、状态、消息和工具的编程构件,让开发者自由定义协作逻辑、持久化策略与业务流程。
框架不是开箱即用的软件开发流程。你需要补齐任务模型、代码仓库操作、执行环境、验收规则和产品界面,并承担这些组件的维护责任。
代表项目 · 展开了解定位与区别
提供顺序、并发、交接与团队协作等编排能力,以及检查点、可观察性和人工介入机制。适合需要在既有应用与服务中构建 Agent 工作流的团队。
阅读官方资料 ↗(新窗口打开)举个例子:团队自行实现“读取需求 → 规划 → 分配隔离环境 → 编码 → 独立验收 → 提交 PR”的状态图。
先辨认你得到的是什么。 规格与 Skills 可以服务单 Agent;编排能力需要执行环境;通用框架需要你自己补齐开发流程。它们的交付范围不同。
COMPARE THE RESPONSIBILITIES
不做没有依据的评分。比较谁控制流程、
谁记录状态,以及你需要补齐什么。
左右滑动对照表,查看全部能力维度
| 系统类别 | 主要控制方式 | 核心产物 / 状态 | 你需要负责 | 典型场景 |
|---|---|---|---|---|
| 规格与任务治理 | 人定义意图,工作流管理产物 | 规格、计划、工作包、评审状态 | 确认需求与验收边界 | 需求反复、多人协作、可追溯交付 |
| 开发方法与 Skills | 宿主 Agent 遵循 Skills 与指引 | 设计文档、计划、测试与评审结果 | 选择适当流程并审阅关键决策 | 开发随意、缺少测试、评审不一致 |
| 主 Agent 编排 | 主 Agent 动态规划与分派 | 任务上下文、计划、汇总与进度 | 明确目标、接口与需要介入的决策 | 长任务、上下文膨胀、模块化实施 |
| 程序控制的开发闭环 | 程序状态机与明确的条件判断 | 运行状态、事件、产物与验证证据 | 配置可靠的测试、预算与退出条件 | 反复返工、状态漂移、中断续跑 |
| 多 Agent 运行与调度 | 队列、调度程序与协调 Agent | 任务分派、工作区、运行与合并状态 | 定义资源限制、依赖与合并策略 | 多任务常驻运行、跨工作区交付 |
| 集成式 AI 开发平台 | 平台提供的 Agent 与自动化机制 | 会话、环境、任务记录和代码产物 | 配置项目环境、约束并验收成果 | 希望直接使用完整工作环境 |
| 通用多 Agent 框架 | 由你定义的代码、图与 Agent | 自定义状态、检查点、消息与事件 | 构建并维护整套开发系统 | 自研平台、定制流程、系统集成 |
表中描述各类别的典型侧重,不代表所有产品的默认配置,也不构成性能或成熟度排名。
让不同 Agent 使用各自的对话与信息,控制上下文体积,减少相互影响。
让任务在不同分支和目录中修改文件。仍需处理合并冲突、依赖和集成测试。
通过容器或虚拟机分开进程、依赖与运行资源。隔离范围取决于具体配置。
COLLABORATION PATTERNS
协作模式描述 Agent 之间的关系。
一个开发流程里,通常会组合使用多种模式。
左右滑动查看全部 5 种协作模式
前一阶段的产物,成为下一阶段的输入。
将开发拆成有先后顺序的阶段。每个 Agent 接收上一步的产物,完成自己的职责,再交给下一位执行者。
适合输入输出清楚、前后依赖明确的标准流程;便于检查每个阶段的产物。
前期误解可能沿流程传播,串行步骤限制整体速度。需要设置回退和纠错路径。
相关机制参考:BMAD Method ↗(新窗口打开)
主 Agent 分派任务,子 Agent 返回结果。
主 Agent 制定计划、确定任务边界,将工作交给子 Agent。子 Agent 返回成果后,由主 Agent 汇总、判断下一步并处理依赖。
适合长任务、模块化开发和上下文较多的调查。主 Agent 可以集中维护整体决策。
主 Agent 可能成为瓶颈。子任务说明过少会丢失背景,过多又会增加成本与干扰。
相关机制参考:GSD Core ↗(新窗口打开)
把目标拆成可以独立开展的工作包,同时运行多个 Agent,再对输出进行集成或汇总。拆分依据可以是模块、文件集合或调查方向。
适合批量迁移、模块独立实现和多角度研究;并行部分有机会缩短等待时间。
共享接口、文件冲突和集成验证都会产生额外成本。任务越相互依赖,并行收益越不确定。
消息直接流动,任务需要清晰归属。
Agent 不只向协调者汇报,也可以通过消息与共享任务直接沟通,相互挑战假设或调整分工。团队仍可以保留负责人。
适合复杂问题调查、跨层协调和多视角评审;新发现可以及时影响其他成员。
通信增加模型用量与协调成本。需要明确任务归属、决策记录与结束条件,避免反复讨论。
独立评审增加检查视角,不保证发现所有缺陷。
由一个 Agent 实施,另一个 Agent 根据规格、代码和测试证据进行独立评审。发现问题后退回修复,再次验证,直到满足条件或触发停止规则。
适合需要检查规格符合性和代码质量的工作;可以将评审与实施的上下文分开。
评审同样可能漏错,也可能提出无效修改。需要以证据判断反馈,并设置返工预算。
相关机制参考:bmad-loop ↗(新窗口打开)
FIND YOUR STARTING POINT
从当前最大的开发阻力出发,选择能补齐那一层能力的工具。
先建立规格、验收标准与变更记录。小范围试用 OpenSpec 或 Spec Kit;需要工作包、评审状态与并行工作区时,再看 Spec Kitty。
FROM PROMISE TO EVIDENCE
“支持并行”是一项能力。
是否更快、更可靠,需要同一任务下的证据。
包含数据库变更、API、列表交互与测试。提前写清验收标准,并保留一份独立验收用例。
这是建议的评估方法,本网站未执行各产品的横向性能实测。
从接收需求到验收通过,统计总耗时、模型用量、人工介入和返工次数。
在实施或评审阶段停止进程,再恢复。检查是否重复执行、丢失进度或跳过验证。
观察系统会修复、阻塞还是错误地宣布完成;确认结果与任务看板一致。
让两个任务涉及同一接口,观察冲突处理,并对合并后的整体重新测试。
KEEP EXPLORING
能力描述基于官方文档;分类与选型建议属于编辑分析。
核对日期:2026 年 9 月 21 日。
阅读版本说明 bmad-loop 标注为早期公开测试版;Spec Kitty 主分支为 4.x 候选发布线;Claude Code Agent Teams 仍标注为实验性功能。使用前请核对当前发布说明。
GSD 仓库迁移 原 gsd-build/get-shit-done 已归档 ↗,当前开发延续于 open-gsd/gsd-core。请以新仓库为准。