多 Agent 如何协作完成复杂任务？从 GCA 看任务编排与执行控制

多个 Agent 协作完成复杂任务时，除了任务的分工之外，还要处理依赖关系、并发冲突和结果验证等问题。一个 Agent 修改了上游的文件，可能会让其他 Agent 的工作失效。因此，如何协调 Agent 之间的执行、确保最终结果的可靠性，是多 Agent 系统要解决的问题。

腾讯团队在论文「Game-Creation-Agents: Autonomous Game Production」中提出了 GCA 的概念。它以自动生成可运行的浏览器游戏为场景，通过八个专职 Agent 完成设计、实现、集成和验证。论文还详细介绍了 GCA 是如何通过任务编排、制品所有权、状态管理和验证机制来组织多个 Agent 协作，并在执行中断或验证失败时恢复和修复任务。

多 Agent 的任务编排

GCA 由一个编排器（Orchestrator）和八个专职 Agent 组成。编排器负责安排任务的顺序、管理依赖关系和切换控制阶段，各个 Agent 则负责具体的工作，并生成相应的交付产物。

论文将八个 Agent 的职责划分如下：

在这套架构中，每个 Agent 都有明确的输入、输出和负责维护的制品。编排器根据各阶段的执行结果，检查任务的依赖关系和交付条件，再决定何时启动后续任务。而具体的设计、代码和素材修改则由相应的 Agent 来完成。

图注：GCA 整体执行流水线

如上图所示，GCA 先由 Design Agent 根据用户的需求生成多模态的设计文档，并明确功能和规则、状态变化、场景要求、视觉参考和可测试的目标。如果待执行的任务还需要预先定义关卡的数据，系统会调用 Level-design Agent。接着，Scaffold Agent 会根据设计文档来生成基于 Phaser 4 游戏引擎的运行框架，以及后续实现和验证需要使用的机器可读契约。

完成这些准备工作后，系统进入功能实现和素材生产阶段。这两类任务可以同时推进，但各自采用不同的执行方式。

功能实现部分会按照设计文档中的场景顺序逐个执行。由于不同场景可能共享代码文件或运行结构，如果多个 Implement Agent 同时修改这些内容，容易产生文件冲突，因此 GCA 会选择串行执行。

素材生产则采用并行方式。系统将素材分成多个独立批次，交给不同的 Assets Agent 处理，每个 Agent 只能修改自己负责的素材文件和元数据，不能直接修改共享的资源清单。

等所有素材批次完成后，系统统一归并生成资源清单，再由 Asset-integration Agent 将素材接入运行系统，完成资源预加载、动画配置、显示比例调整和界面绑定。

归并时还要检查素材是否齐全。如果某个必需的素材生成失败，系统会将其记录为缺失项；对于通过代码生成的图形、运行时生成的文本等无需独立素材文件的内容，则会单独标注，避免后续检查将其误判为缺失。

GCA 根据任务的文件依赖和写入范围决定是否并行执行。需要修改共享代码的任务依次进行，能够独立生成文件的任务则并行处理，再通过统一归并完成集成，以减少多个 Agent 同时修改文件产生的冲突。

除了控制任务的执行顺序，编排器还需要检查每个阶段的实际输出。即使 Agent 已经报告完成，系统仍会确认约定的文件是否存在、内容是否符合契约，以及文件是否属于当前任务和工作区。

例如，Scaffold Agent 报告完成后，如果某个必要的测试文件仍然缺失，编排器就会阻止流水线进入下一阶段。只有输出检查通过之后，后面的任务才能继续执行，从而避免上游任务中的问题被带入后续的流程中。

制品契约与权限控制

任务分工明确之后，GCA 还要解决两个问题。一个是如何让上下游 Agent 按照一致的要求工作，另一个是如何避免多个 Agent 在执行过程中产生文件冲突。

对于第一个问题，GCA 使用机器可读的制品契约。在多 Agent 协作中，如果上游只提供自然语言文档，下游 Agent 可能对同一需求产生不同的理解。例如，设计文档要求某次操作完成后更新计数器并显示新的状态，但 Implement Agent 可能只更新界面，却遗漏了内部状态变化。

为此，GCA 在设计阶段之后设置了 Scaffold 阶段，将设计文档转换为运行框架、交互契约、目标约束、布局规则和确定性测试。以计数器为例，契约可以明确需要触发的输入事件、预期的状态变化和界面反馈。Implement Agent 根据契约实现功能，Verify Agent 则通过对应测试检查结果。

这些契约和测试在代码实现前生成，让下游 Agent 能够依据统一的要求执行任务，也减少了实现过程中随意调整验收标准的情况。不过，契约本身也可能存在遗漏或错误，因此 GCA 会在 Scaffold 阶段结束时进行检查，确认运行框架、测试和契约满足后续阶段的要求。

对于文件冲突，GCA 采用单一写入者机制，为每类制品指定唯一的负责 Agent。例如，Design Agent 维护设计文档，Implement Agent 修改场景代码，Assets Agent 负责素材文件。其他 Agent 即使发现问题，也不能直接修改不属于自己的制品。

图注：单一写入者机制

这一机制由统一的 MCP 控制层执行。GCA 将制品生成、文件操作和验证功能接入一个 MCP 服务，共定义了 55 个工具，覆盖生命周期管理、素材生成、验证、视觉元素定位、后处理、视频录制和布局等操作。

这些工具具有明确的输入输出定义，服务端还会检查操作涉及的文件路径、运行身份和制品状态。例如，Agent 请求修改文件时，MCP 服务会先确认目标路径是否在其允许写入的范围内，越权操作会在文件修改前被拒绝。

如果 Verify Agent 在测试中发现某个交互功能存在问题，它需要生成结构化的失败报告，再由编排器将修复任务交给负责相关代码的 Implement Agent。通过这种方式，系统能够明确每次修改的责任方，并根据制品所有权分配后续修复任务。

除了控制同一流水线内部的文件修改，GCA 还通过工作区独占租约隔离不同的流水线。工具访问工作区前，服务端会固定目标目录并获取租约，防止两个独立流水线同时向同一目录写入内容。

工作区租约和单一写入者机制分别处理不同层次的冲突：前者负责隔离不同的流水线，后者限制同一流水线内部各个 Agent 的写入权限。对于写入范围互不重叠的任务，系统仍然允许它们并行执行，从而在控制文件冲突的同时保留必要的并发能力。

这些权限规则也说明，Agent 能够请求某项工具操作，并不代表它一定拥有对应的执行权限。最终能否修改文件，由 MCP 服务端根据工作区、路径和制品归属来决定。

执行状态与中断恢复

当任务持续经过多个阶段，仅依靠文件是否存在、Agent 是否返回成功，还不足以判断当前的执行状态。例如，系统完成一次验证后，Implement Agent 又修改了代码。如果编排器继续使用修改前的验证报告，就可能将未经检查的新版本认定为合格。

为此，GCA 使用三个标识，将关键产物和验证证据与具体的执行状态关联起来：

• 运行标识（Run ID）：区分不同的任务流水线。

• 构建摘要（Build Digest）：标识被验证的产物版本。

• 验证轮次（Verification Epoch）：区分同一任务中的多次验证。

这些标识会记录在相关产物和验证报告中。每当系统要执行验证门禁时，都会检查报告对应的运行任务、构建摘要和验证轮次是否与当前的状态一致。即使旧报告中的检查全部通过，只要构建版本发生变化，这份报告就不能继续作用于当前的版本。

除了关联验证的结果，GCA 还使用由服务端签发的交接记录，来记录不同阶段的关键状态变化。例如，Scaffold 阶段重新生成契约时，会记录因此失效的下游文件；素材归并时，会记录实际接收的素材批次；集成完成后，则记录对应的构建版本。

这些记录由 MCP 服务生成，Agent 不能使用自己编写的文字总结替代它们。当上游任务发生变化时，编排器可以根据交接记录来确定哪些下游制品需要被重新处理，避免重复检查整条任务链路。

这套记录机制也为中断恢复提供了依据。长任务可能因网络异常、模型调用超时或进程重启而中断，系统需要尽可能地复用已经完成的工作，同时避免将不完整或过期的文件当成有效结果。

恢复时，GCA 会检查持久化的任务状态、制品、交接记录及所有权信息，从最近一个有效的阶段边界继续执行。例如，设计文档和运行框架已经通过检查，只有部分素材批次尚未完成，系统便可以保留有效的上游结果，继续处理剩余任务。

不过，现有文件能否复用，还取决于它是否属于当前任务、交接记录是否有效，以及相关内容是否因上游修改而失效。即使某个阶段留下了完成标记，系统也需要核对实际状态。

对于工具调用超时，GCA 还会区分请求超时和任务失败。调用方没有及时收到响应时，服务端任务可能仍在运行；如果立即重新派发新任务，就可能造成重复执行或文件冲突。因此，编排器会先检查持久化任务记录，确认执行的状态后再决定如何处理任务。

不同的阶段也有不同的恢复规则。Implement 阶段不会因为一次超时就自动重新执行整个场景的生成任务，部分问题会转入后续的修复流程；Verify 阶段则可以根据检查点恢复同一轮的验证结果，复用已经完成的验证任务。

通过版本标识、交接记录和阶段检查，GCA 能够在任务中断后判断哪些结果仍然有效，并从相应的位置恢复执行，减少重复工作和状态冲突。

验证机制与定向修复

完成代码和素材的集成工作后，GCA 还要检查最终的产物是否符合用户的需求。由于任务从自然语言描述开始，系统一般不会有现成的完整测试套件，因此 GCA 会在 Scaffold 阶段提前生成可执行的契约和测试，并在构建完成后通过实际运行来验证结果。

验证分为多个层次。静态检查负责确认文件的结构、契约和资源引用是否还有效；Playwright 测试通过模拟鼠标、键盘等输入，检查交互行为和状态变化；Play Agent 则根据运行界面和环境状态进行探索，补充固定测试难以覆盖的操作。此外，布局检查会检测元素的位置、边界和重叠情况，视觉比较则根据设计文档中的参考图评估实际的界面效果。

这些检查产生的结果分为两类。例如，文件是否存在、计数器是否正确变化、界面元素是否重叠，都可以通过程序进行确定性检查；而视觉风格是否符合设计、界面呈现是否完整，则需要模型根据预先定义的标准进行评估。

GCA 会分别记录确定性检查和模型评估，并通过固定的评估标准、模型和采样参数，来减少模型评估结果带来的波动。后续的验证流程也会结合这两个记录来判断当前构建是否满足要求。

分层验证与发布门禁

GCA 使用有向无环图来组织验证任务。它会根据依赖关系并行地执行各项检查，并将对应结果汇总为报告。为了兼顾修复效率和最终的交付质量，系统将验证分为迭代模式和完整模式。前者会执行浏览器测试、交互探索、视觉比较、布局及运行时的资源检查，为修复提供反馈；后者在此基础上增加录制、视频分析和性能采样，用于最终发布前的检查。

每轮验证都会与当前的运行标识、构建摘要、运行地址、契约和验证轮次绑定，确保各项结果都对应同一个构建版本。即使部分检查失败，系统也会保留已生成的证据，记录具体的失败原因，并尽可能完成本轮报告的汇总。编排器随后根据报告执行相应的验证门禁，决定任务能否继续推进。

论文将门禁划分为四级，对应不同阶段的检查要求：

其中，scaffold_done 用于早期的运行框架检查；iteration_ready 覆盖结构、资源、交互、视觉和运行状态等内容；first_pass_complete 增加录制与性能证据；最终的 ready_to_ship 还会检查未解决的问题、质量评审结果和必要的优化轮次。由于部分早期契约检查会在实现完成后被新的检查替代，四级门禁的条件并非简单累加。

图注：四级验证门禁

各阶段只有满足全部必需检查，才能通过相应门禁。论文还规定了具体的验证阈值，例如 Play Agent 的加权准确率至少达到 0.8、帧率中位数不低于 24 FPS、启动时间不超过 10 秒等。这些参数统一保存在 gca.config.yaml 中，可以根据运行环境调整。如果存在未通过的检查，系统会保留失败记录，并将问题交给后续修复流程。

除了程序化验证，GCA 还通过独立的 Critic Agent 评估最终产物的交付质量。Critic 不查看源代码，只根据设计文档、截图、视频分析、交互报告和验证结果，从视觉质量、核心机制、完整度、完成度和素材适配情况五个维度进行判断。

论文设置的默认规则是，五个维度的评分均达到 0.7 才能通过评审；只要有一项低于 0.5，就会直接拒绝，其余情况也默认拒绝。如果构建无法启动、出现致命错误或截图为空，同样会直接拒绝。Critic 的评审结果还要与确定性门禁共同满足，当前构建才能进入发布阶段。

失败归属与定向修复

当门禁检查或 Critic 评审发现问题时，GCA 会将失败的信息整理成结构化的记录，由编排器根据问题类型和制品所有权分配修复任务。例如，交互逻辑错误交给 Implement Agent，资源接入问题交给 Asset-integration Agent，设计规范中的问题则由 Design Agent 处理。

修复时，系统会优先处理设计层面的问题，因为设计文档是后续生成契约、代码和素材的依据。一旦设计发生变化，部分下游制品可能随之失效，编排器需要根据交接记录确定受影响的范围，并重新执行相关的任务。对于代码和素材的修复，只要写入范围互不冲突，就可以并行地执行，等任务完成后再统一汇总结果、更新共享制品，并生成新的构建摘要。

每轮修复完成后，GCA 都会针对更新后的构建重新验证。例如，Implement Agent 修复了交互逻辑，之前的验证报告就不能继续用于发布判断，系统需要重新检查修改后的结果，并在发布前完成完整验证。

为了控制反复修复的成本，GCA 还设置了迭代预算。论文默认要求至少进行一轮修复或优化，最多两轮，同时限制连续阻塞的次数。如果达到预算上限后仍有问题，系统会保留失败记录并停止推进，避免任务陷入无休止的修复循环。

实验结果与系统取舍

为了评估 GCA 的实际效果，作者选择了同样能够根据自然语言需求生成 Phaser 浏览器游戏的 OpenGame 作为对照系统。原始任务池包含 32 项需求，共涉及 795 条必须满足的要求。其中，20 项任务同时具备两套系统的生成结果和经过审查的浏览器测试，被纳入正式实验。

每套系统在每项任务中提供一个固定产物，共计 40 个。研究者对每个产物重复评估三次，最终获得 120 次评估记录。需要注意的是，三次评估使用同一个构建结果，并未重新生成产物，主要用于观察模型评分和运行时行为的波动。

为保证比较公平，两套系统使用相同的任务要求、测试版本、浏览器配置、评估模型和重试规则。外部评估器只能访问原始需求和最终运行产物，无法查看 GCA 内部的设计文档、执行记录、门禁报告或 Critic 结论，避免内部评审结果影响外部评分。

评估过程中，测试程序通过真实浏览器执行点击、键盘输入和拖动等操作，并记录截图、视频及测试断言。随后，GPT-5.6 根据这些执行证据判断需求的完成情况，对失败断言和关键交互进行复核，以评估最终产物的实际表现。

自动评估与人工结果

论文从需求满足度、核心机制、内容完整度、功能性视觉表现和视觉呈现质量五个维度评估最终产物，结果如下：

其中，核心机制和内容完整度主要依据确定性测试评分，视觉相关指标则结合截图、视频和运行证据进行模型评估。需求满足度综合了与任务要求直接相关的检查结果。

GCA 在需求满足度和核心机制方面的表现最突出，分别比 OpenGame 高出 0.130 和 0.197。在内容完整度和功能性视觉表现上，GCA 也有一定优势，但视觉与呈现质量略低于 OpenGame。

研究者还邀请了 10 位参与者，对相同的 20 组产物进行人工比较。在 200 次偏好选择中，GCA 获得 86 次，OpenGame 获得 55 次，其余 59 次为平局。排除平局后，GCA 的偏好比例为 61%，OpenGame 为 39%，差异具有统计显著性（p=0.011）。

整体来看，GCA 在这些任务上的功能实现和需求满足度方面表现要更好，人工评估也更倾向于 GCA。不过，对照实验数据只有 20 组，论文也没有提供完整的组件级消融实验，因此是无法确定 GCA 的制品所有权、工作区租约和验证门禁等机制各自带来了多少收益。

此外，论文没有系统报告端到端执行时间、Token 成本及不同并发配置下的资源消耗。GCA 的设计更适合任务阶段清晰、制品归属明确且能够建立可执行测试的场景；对于共享文件修改频繁或评价标准较为主观的任务，还需要进一步验证协作效率与执行成本。

结语

GCA 通过明确的 Agent 职责、制品归属和执行顺序来组织多个 Agent 完成复杂的任务，并利用状态记录、验证门禁和定向修复机制，管理从任务执行到最终交付的整个过程。

论文的实验结果表明，GCA 在需求满足度和核心功能实现方面取得了更好的表现，但各项机制的独立收益和运行成本仍有待验证。对于多 Agent 长时间协作的系统而言，GCA 在任务编排、状态一致性和结果验证方面的设计，仍具有一定的参考性。