算力伸缩：从单 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 独立工作区与分支 |
| 集群空闲但任务积压 | 并发上限按机器数而非依赖层设置 | 按层宽动态调整派发量 |
| 合并后全量测试失败难定位 | 一次性合并跨度过大 | 改为小步合并、每次只引入一个任务 |
小结
拆解引擎是否健康，用一条可量化的标准判断：整体耗时应接近"最深层的路径耗时 + 排队损耗"，而不是各任务耗时之和。如果总耗时仍约等于串行总和，说明并行度被任务边界或合并策略卡住，先查依赖分层与冲突率，再考虑加机器。