算力伸缩:从单 Agent 到 Agent 集群
当任务规模达到“将千万行老旧 Java 代码库自动化升级至 Java 21 并修复所有已废弃 API”时,依靠单个 Agent 在单台机器上运行需要耗时数十天。
分布式 Agent 调度引擎通过引入微任务拆解机制:
- Master 分解节点:分析工程依赖图,将每个独立的 Maven 模块拆解为独立的迁移任务;
- 并发 Worker 池:每个 Worker 挂载专属的 MCP 工具与只读沙箱,数十个任务在 K8s 集群中并行编译、生成补丁与执行测试;
- 仲裁合并节点(Arbitrator):统一拉取各个 Worker 生成的 Git 分支,执行三方合并并运行全量集成测试,遇到冲突自动唤起冲突解决专用 Agent。
落地步骤:从代码库到任务 DAG
- 建依赖图。解析构建文件(Maven 模块图、Gradle 项目图或包清单),得到模块间的编译依赖关系;
- 拓扑分层。按依赖关系把模块排进若干层,只有同层任务允许并行,跨层任务设置显式的先后约束;
- 定义任务契约。每个微任务写清输入范围(仅本模块源码与声明的依赖制品)、验收标准(本模块编译通过且单测通过)与资源配额,避免 Worker 之间隐式共享状态;
- 调度与限流。队列按优先级派发,设置并发上限(经验值:从集群 CPU 核数的一半起步,观察合并冲突率后再调);
- 小步合并。Worker 完成即回传分支,仲裁节点持续合并并跑增量集成,而不是等所有任务结束后一次性大合并。
并行度与合并策略取舍
| 策略 | 吞吐 | 合并冲突率 | 资源浪费 | 适用阶段 |
|---|---|---|---|---|
| 高并发 + 末端一次性合并 | 表面最高 | 高,常出现返工 | 高 | 不建议 |
| 中并发 + 随做随合 | 稳定 | 低 | 中 | 主流做法 |
| 分层串行 + 层内并发 | 受层宽限制 | 最低 | 低 | 依赖复杂的存量工程 |
验证方法
上线前用一个小仓库做全链路演练,上线后盯三个指标:任务首次通过率(衡量拆解质量)、平均排队时长(衡量并发上限设置)、合并冲突占比(衡量任务边界划分)。冲突占比持续走高时,优先缩小任务粒度或降并发,而不是扩集群——扩集群只会放大冲突源。并发写冲突的具体处理模式见 多 Agent 并发协同中的写冲突控制:分布式锁与乐观并发演进。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| 下游模块 Worker 反复编译失败 | 依赖的上游模块尚未合并 | 按拓扑分层强制先后约束 |
| 同一批任务结果互相覆盖 | 多 Worker 写同一共享目录 | 每个 Worker 独立工作区与分支 |
| 集群空闲但任务积压 | 并发上限按机器数而非依赖层设置 | 按层宽动态调整派发量 |
| 合并后全量测试失败难定位 | 一次性合并跨度过大 | 改为小步合并、每次只引入一个任务 |
小结
拆解引擎是否健康,用一条可量化的标准判断:整体耗时应接近"最深层的路径耗时 + 排队损耗",而不是各任务耗时之和。如果总耗时仍约等于串行总和,说明并行度被任务边界或合并策略卡住,先查依赖分层与冲突率,再考虑加机器。