异步软件工程代理的有效策略

提出CAID框架，基于SWE原语实现多代理分支合并协作

前置知识

依赖图

依赖图是有向图 G = (V, E)，其中每个节点 v 属于 V 对应一个工作单元，每条有向边 (v_i, v_j) 属于 E 表示 v_j 依赖于 v_i。在 CAID 中，管理器构建依赖图来组织工作，确定任务执行的先后顺序。一个工作单元 v_j 只有在所有依赖都满足时才可委托，即对于所有 (v_i, v_j) 属于 E，v_i 属于 C_t，其中 C_t 是第 t 轮已完成并集成到主分支的单元集合。

理解依赖图是读懂本文的关键，因为 CAID 的核心机制就是基于依赖图进行任务分解和委托，确定哪些任务可以并行执行，哪些必须串行等待。

分支合并协调

分支合并协调是软件工程中的经典协作模式，多个开发者在独立的分支上工作，通过 git commit 提交变更，通过 git merge 合并到主分支。CAID 将这种模式扩展到多智能体系统，每个工程师代理在独立的 git worktree 中工作，管理器通过 git merge 将完成的变更集成到主分支。如果发生冲突，生成冲突的工程师负责解决。

这是本文的核心创新，理解分支合并协调的机制对于理解 CAID 如何解决多代理协作中的冲突和干扰问题至关重要。

Git worktree

Git worktree 是 Git 的一个功能，允许在同一个仓库中创建多个独立的工作目录，每个工作目录对应不同的分支。这些工作目录完全隔离，一个工作目录中的修改不会影响其他工作目录。CAID 为每个工程师代理创建独立的 worktree，确保并行编辑在物理上是分离的，不会互相干扰。

这是 CAID 实现工作区隔离的核心技术原语，理解它对于理解 CAID 如何避免多代理协作中的物理冲突很重要。

研究动机

随着基于 LLM 的软件工程代理能力的提升，我们期望它们能够承担更多任务。虽然几年前解决 GitHub 上的独立问题还是主要挑战，但现在我们要求代理从头构建大型应用或实现整篇研究论文。单个代理执行大型任务需要很长的实际时间，而且在长周期的共享工件任务中，多个代理的协作面临核心挑战：当多个代理需要修改共享资源时，它们的编辑会互相干扰。例如，一个代理重命名函数，而另一个代理编写仍然调用其旧名称的新代码。即使每个代理在隔离中产生高质量输出，集成也经常失败，因为并行代理对共享状态产生不一致的视图，导致不兼容的变更和执行冲突。这些冲突通常只在集成时被发现，修复不是一行补丁而是至少一个代理工作的完整修订。

本文的目标是本文研究的问题是：如何能够协调多个代理以有效的方式在共享工件上异步协作？具体而言，本文的目标是引入一种结构化的多代理协调范式，基于成熟的软件工程协作原语，解决并发编辑干扰、依赖同步困难、部分进展整合成连贯整体困难等问题，在保持准确性的同时及时完成长周期任务。

与已有工作不同的是，与已有研究不同，本文不研究如何分解和分配任务，而是专注于异步多代理协作在共享工件上的核心挑战：当多个代理并发修改代码库时的物理干扰和集成冲突。虽然人类软件工程团队已经开发了成熟的协作基础设施来缓解这些挑战（如 git worktree、合并工作流、测试套件），但大多数多智能体系统仍然依赖语言驱动的架构，在共享代码库中经常遇到执行冲突。本文的独特切入点是将这些成熟的软件工程协作原语直接映射到多智能体系统的协调机制上，将协调视为对版本化工件及其集成的显式控制。

核心方法

CAID（Centralized Asynchronous Isolated Delegation）是一个基于分支合并的多智能体系统，用于长周期软件工程任务。其整体思路是：一个中央管理器动态分解任务并委托给多个工程师代理，这些工程师代理在隔离的工作区中并发执行。具体而言，管理器首先探索仓库结构，构建依赖图，确定任务执行的顺序。然后，管理器为每个工程师创建独立的 git worktree，确保并行编辑在物理上是分离的。工程师在隔离中实现、自验证，并通过 git commit 提交变更。管理器通过 git merge 将完成的变更集成到主分支，并根据测试验证决定是否保留更新。整个过程是异步的：管理器监听完成信号，动态更新依赖状态，早期完成的工程师可以分配新的可执行任务单元，而依赖未满足的工程师保持空闲。这种设计将人类软件工程团队的成熟协作原语（版本控制、隔离工作区、测试验证、依赖管理）直接应用于多智能体系统。

CAID 的核心创新是将分支合并协调（branch-and-merge coordination）作为多智能体软件工程的核心协调机制，并使用成熟的软件工程原语（SWE primitives）来实现它。具体而言，CAID 使用依赖图进行调度约束，确定安全的任务委托顺序；使用 git worktree 实现工作区隔离，每个代理在独立的工作树中工作；使用 git commit 和 git pull request 进行结构化信号传递，代理通过提交报告完成；使用 git merge 进行输出集成，完成的变更合并到主分支；使用合并冲突解决进行冲突处理，工程师自己解决集成冲突；使用代码审查进行验证，工程师进行自验证；使用 asyncio 并行执行实现并发执行，多个代理并发运行；使用事件循环加 await 进行协调循环，等待完成然后集成然后重新分配任务；使用 git reset --hard HEAD 进行状态同步，工作树同步到最新的集成状态。这些原语构成了隔离、委托、异步执行和集成的操作构建块。

方法步骤详情

CAID 的完整工作流程包括以下步骤：首先，任务规范和依赖建模，管理器将仓库结构表示为有向图 G = (V, E)，其中每个节点 v 属于 V 对应一个工作单元，每条有向边 (v_i, v_j) 属于 E 表示 v_j 依赖于 v_i。然后，依赖感知的任务委托，管理器将依赖结构转换为小的可执行任务单元，分配给每个工程师。管理器将实现工作分成最多 N 个主要任务组，其中 N 是允许并发工作的最大工程师数量。管理器激活最多 N 个工程师，针对依赖已满足的任务组。接下来，工作区隔离和集成，使用 git worktree 确保每个工程师在其自己的工作树中工作，只修改该工作区内的文件。集成通过标准的 git commit 和 git merge 操作执行。工程师完成实现和自验证后，从其分支提交。管理器尝试将此分支合并到主分支。如果发生合并冲突，产生冲突提交的工程师负责解决。然后，通信和异步执行，使用结构化的 JSON 协议作为管理器和工程师代理之间的通信接口。执行围绕一个异步管理器控制的事件循环组织。一旦委托任务，每个工程师作为独立的协程运行。工程师调用语言模型调用，修改其工作树中的代码，执行验证命令如运行测试。管理器监听完成信号，并在提交提交时动态更新依赖状态。最后，自验证和终止，为确保实现质量，要求每个工程师在提交提交之前验证自己的实现。工程师在其工作树中执行验证。当可执行测试可用时，工程师运行直接导入或引用修改文件的测试子集。如果成功集成了验证提交，管理器将其集成到主分支并更新依赖状态。

技术新颖性

CAID 的技术新颖性在于首次将软件工程中的分支合并协调系统地应用于多智能体系统，并提供了完整的实现框架。与依赖自由形式对话的多智能体系统不同，CAID 使用结构化的 JSON 指令和 git 提交作为代理之间的通信，避免了代理之间的不对齐，这是多智能体系统中识别的主要失败模式。与依赖角色扮演的多智能体系统不同，CAID 不关注代理的角色分配，而是专注于并发工作的物理隔离、集成和验证。与依赖隐式协调的多智能体系统不同，CAID 通过中央管理器显式委托任务，并通过版本控制机制物理隔离并发代理的工作空间，防止集成冲突。实验表明，这种基于 SWE 原语的方法在长周期共享工件任务上提供了一种实用且可扩展的架构基础。

**Figure 1**: Overview of CAID Workflow. The Manager explores the SWE tasks, builds a dependency graph to decompose tasks into parallelizable groups, and creates isolated git worktrees for every onboarded engineer. In the asynchronous loop, engineers independently implement, self-verify, and make a commit. Upon any engineer's completion, the Manager merges to main and dynamically updates the task delegation plan before reassigning the next task. After the asynchronous loop, the manager does a final review before submitting the final product.

实验结果

在两个长周期软件工程基准上的实验表明，基于分支合并的多智能体系统 CAID 相比单智能体基线具有一致的优势。在 PaperBench 上，多智能体协调为较弱的单智能体运行带来了显著的收益：MiniMax 2.5 在多智能体执行下达到 36.7%，而单智能体分数仅为 10.4%。改进不仅限于较弱的模型，使用 Claude 4.5，多智能体执行达到 63.3%，相比单智能体的 57.2%。在 Commit0-Lite 上，发现了相同的模式。Claude 4.5 从 53.1% 提升到 59.1%，MiniMax 2.5 在多智能体执行下达到 57.0%。这些结果表明性能差距不是由更改底层模型解释的，而是由更改执行方法解释的。CAID 中工程师在单独的分支中工作，变更仅通过显式合并和测试验证进入主分支。这使得并行工作可用，通过隔离实现与集成，工程师可以在不覆盖彼此中间状态的情况下本地迭代，而集成失败在合并时通过与特定更新关联的具体测试信号显现。实验进一步揭示了重要的战略含义：多智能体协调不应被视为单智能体失败后的后备。单智能体加多智能体设置近似于首先尝试单智能体，然后在必要时执行协调执行的实用策略。然而，这种顺序策略产生近乎加法的运行时间和成本，而最终性能接近直接多智能体结果。例如，在 PaperBench 上使用 Claude Sonnet 4.5，组合策略达到 66.8%，仅略高于多智能体分数 63.3%，但运行时间从 2080.4 秒增加到 3883.9 秒，成本从 9.3 上升到 12.6。在 Commit0-Lite 上使用 MiniMax 2.5，多智能体分数为 57.0%，组合策略保持 57.0%，而运行时间和成本都大幅增加。这些结果给出了一个清晰的策略洞察：对于长周期共享工件任务，将多智能体协调视为单智能体尝试后的后备是低效的。更具成本效益的策略是从一开始就采用协调的多智能体执行，而不是仅在失败后切换。关于迭代预算的实验表明，单智能体无法利用更多迭代。运行单智能体 max_iterations = 100 和 max_iterations = 200，将迭代限制翻倍仅产生最终性能的边际改进，在某些情况下甚至导致结果下降。在 PaperBench 上，从 100 到 200 迭代的增量对 GLM 4.7 和 MiniMax 2.5 保持很小，对于 Claude Sonnet 4.5 变为负值。在 Commit0-Lite 上，改进同样有限，MiniMax 2.5 在增加迭代预算时显示负增量。CAID 相对于单智能体 100 次迭代的基线获得的分数增益远大于仅增加单智能体迭代预算获得的增益。例如，在 PaperBench 上，MiniMax 2.5 的多智能体改进超过 25 个百分点，而将迭代限制翻倍仅产生小的变化。这些结果表明，单独扩展迭代预算不能解决单智能体的基本瓶颈，也不能可靠地改进长周期任务的最终性能，而多智能体协调在相同的基线参考下产生显著更大的增益。

**Table 1**: Mapping between concrete SWE primitives and multi-agent coordination mechanisms in CAID. Each primitive serves as an operational building block for isolation, delegation, asynchronous execution, and integration.

**Table 2**: Main results on Commit0 and PaperBench. We compare single-agent baselines with CAID (2 engineers on PaperBench and 4 engineers on Commit0) under the same model and iteration budget.

**Table 3**: We compare soft context isolation and worktree isolation on PaperBench and Commit0-Lite.

**Figure 2**: CAID effectively utilizes iteration budgets. We compare the final score and the iteration utilization between single-agent runs with different iteration limits and CAID.

**Figure 3**: Effect of the number of engineer agents on runtime, pass rate, and cost for Commit0-Lite and PaperBench. We provide the single-agent baselines here for comparison.

**Figure 4**: Execution timelines on the minitorch repository for a single-agent run and two CAID runs. The bars in the Gantt plot indicate file-level implementation intervals and manager phases. The runs differ in which modules are assigned and actively developed, resulting in distinct execution trajectories and pass rates.

**Figure 5**: Runtime (s) vs. pass rate (%) of a subset of the Commit0 under three coordination prompts (1) Round-Manager Review: the manager reviews each round before integration; (2) Engineer Self-Verification: engineers verify locally without repeated managerial review; and (3) Efficiency-Prioritized: all agents are instructed to prioritize runtime efficiency.

查看结构化数据

任务	指标	本文	基线	提升
PaperBench (MiniMax 2.5)	Score	36.7%	10.4%	+26.3 percentage points
PaperBench (Claude Sonnet 4.5)	Score	63.3%	57.2%	+6.1 percentage points
PaperBench (GLM 4.7)	Score	45.4%	38.0%	+7.4 percentage points
Commit0-Lite (MiniMax 2.5)	Score	57.0%	42.3%	+14.7 percentage points
Commit0-Lite (Claude Sonnet 4.5)	Score	59.1%	53.1%	+6.0 percentage points
Commit0-Lite (GLM 4.7)	Score	46.5%	42.8%	+3.7 percentage points

局限与改进

CAID 的局限性包括成本和运行时间。尽管 CAID 提高了长周期共享工件任务的成功率，但它引入了非平凡的协调开销。在实验中，多智能体执行始终比单智能体基线产生更高的 API 成本，而尽管并行执行，实际运行时间没有大幅减少。这反映了一个基本的权衡：结构化隔离、集成和验证提高了稳定性，但需要额外的通信轮次、合并操作和测试执行。特别是，虽然工程师并发运行，但集成仍然是顺序的和测试门的，限制了端到端加速。第二个局限性在于中央管理器的任务分解和委托能力。在当前实现中，任务分配主要依赖于提示工程启发式而不是学习型委托策略。虽然结果表明架构隔离和集成是稳定性的主导因素，但弱或次优的任务分解仍然可以降低整体有效性。第三个局限性是评估专注于软件工程基准，这提供了明确的工作区边界、版本控制基础设施和可执行测试套件。这些属性使软件开发成为研究隔离、集成和依赖感知协调的天然合适测试台。然而，并非所有长周期共享工件任务都具有如此明确定义的边界或客观验证机制。

独立分析的弱点

CAID 的第一个弱点是协调开销。在实验中，多智能体执行的运行时间和成本通常高于单智能体基线，尽管并行执行。这表明当前的 CAID 实现在调度效率、冗余验证周期和合并或修剪中间状态的决策方面还有优化空间。改进方向包括：实现更智能的调度算法，减少不必要的集成轮次；优化测试执行策略，避免重复运行相同的测试；学习何时合并或修剪中间状态，减少集成开销。第二个弱点是任务分解能力。当前实现主要依赖于提示工程启发式，这意味着管理器的任务分解和委托能力依赖于提示的质量和特定任务的结构。改进方向包括：引入基于强化学习的委托策略，使管理器能够学习如何根据反馈改进任务分配；实现依赖感知的规划模块，使管理器能够更准确地推断任务的依赖结构；开发自适应子任务细化策略，使管理器能够根据执行反馈动态调整任务的粒度和边界。第三个弱点是对软件工程任务特有基础设施的依赖。CAID 严重依赖于版本控制基础设施（如 git）和可执行测试套件，这对于非编码任务可能不可用。改进方向包括：设计其他形式的隔离机制（如基于内容的隔离、基于时间戳的隔离）；开发其他形式的集成和验证方法（如基于语义的集成、基于反馈的验证）；评估框架在非编码设置中的适用性。

未来方向

作者提出的未来工作方向包括：改进调度效率，减少冗余验证周期，学习何时合并或修剪中间状态；探索强化学习基础的委托策略、依赖感知的规划模块或自适应子任务细化策略，以改进全局目标和孤立执行之间的对齐；将 CAID 扩展到非编码领域，如文档合成、研究规划或多模态工件构建。基于当前成果可延伸的未来工作方向包括：探索更复杂的多智能体协调模式，如动态调整工程师数量、自适应选择协调策略；研究如何在更大规模的多智能体系统中保持协调稳定性；探索如何将 CAID 的原则应用于其他类型的共享工件任务，如科学计算、数据分析等；研究如何将人类专家纳入 CAID 框架，实现人机协作的软件工程。

复现评估

CAID 的复现性评估：代码已在 GitHub 上开源，项目地址为 https://github.com/JiayiGeng/CAID。实验基于开源的 OpenHands agent SDK 构建，版本为 1.11.0。评估使用两个公开基准：Commit0 和 PaperBench。实验配置在论文中详细描述，包括迭代次数、工程师数量、实现轮数等。对于 Commit0 和 PaperBench，使用 2 个实现轮数。在主要结果中，在 PaperBench 上使用一个中央管理器和 2 个工程师代理，在 Commit0 上使用 4 个工程师代理。模型配置包括三个语言模型：两个开源模型（GLM 4.7 和 MiniMax 2.5）和一个闭源模型（Claude-4.5-Sonnet）。单智能体基线使用 max_iterations = 100，多智能体运行使用 max_iterations = 50 给中央管理器，max_iterations = 80 给每个软件工程师代理。由于模型是闭源的或需要 API 访问，复现需要相应的 API 密钥和计算预算。复现难度中等，主要挑战在于获取模型访问权限和处理长周期任务的执行时间。

异步软件工程代理的有效策略 Effective Strategies for Asynchronous Software Engineering Agents