大规模重构通常涉及数十到数百个文件，覆盖多个模块和功能区域。使用传统串行方式逐个文件处理，耗时长且容易被中断打断，一旦中断往往需要重新梳理上下文，重构周期被大幅拉长。
并行重构通过将任务分配给多个子代理同时执行，能够显著缩短重构周期，将原本需要数天甚至数周的工作压缩到数小时内完成。当修改零散分布在多个文件中时，并行处理的优势尤为明显——重构速度与参与的子代理数量近似成正比。
此外，并行重构还能降低单次任务的心智负担：每个子代理只需专注于自己负责的那部分文件，不需要掌握整个代码库的全部细节，从而减少出错概率。
合理的任务分解是并行重构的基石。分解不当会导致子代理之间频繁冲突和大量重复劳动。以下是三种主流的分解方式：
将需要重构的文件均分给多个子代理，每个代理负责一组文件的独立重构。这种方式实现简单，适合文件间耦合度较低的场景，例如统一修改配置文件格式、更新版权声明、批量重命名局部变量等机械性重构。缺点是当文件之间存在跨文件引用时，容易产生不一致。
根据功能模块（如用户模块、订单模块、支付模块）分配重构任务，每个子代理负责整个模块中所有文件的重构，确保模块内部的一致性。这种方式适合模块间接口相对稳定、模块内部需要大量修改的场景。整体质量更高，但对Master制定模块接口规范的能力要求也更高。
将不同类型的重构操作（如重命名、提取方法、移动文件、修改接口签名）分开处理，由不同子代理专门执行特定类型的重构。每种重构模式全局搜索替换，减少遗漏。这种方式适合全仓库统一执行某类操作的场景，但需要严格定义操作边界，避免不同类型的修改互相覆盖。
无论采用哪种分解方式，都强烈建议为每个子代理创建独立的git worktree。worktree是Git提供的特性，允许在同一仓库上同时签出多个工作目录，彼此完全隔离。这样每个子代理的修改互不干扰，即便出现错误也不会影响其他代理的进度。
并行重构最大的风险在于各子代理各行其是，导致最终合并时出现大量冲突和风格不统一的问题。因此，必须在重构开始前由Master制定统一的规范。
Master（主代理）负责编写重构规范文档，明确命名规则、代码风格、接口签名约定等。规范文档应放在所有子代理都能访问到的共享路径中，作为重构的"宪法"。
所有Worker（工作子代理）在开始重构前必须读取并理解Master制定的规范文档，严格遵循相同的重构规范进行操作。任何对规范的疑问或建议，应由Master统一解答和更新。
Worker之间通过共享文件了解其他模块的变化。例如，当Worker A修改了某个公共接口时，应及时更新接口变更日志文件，供Worker B参考。这种方式可以有效避免命名冲突和重复工作。
重构完成后，必须进行系统性的检查以确保代码库整体正确性和一致性。这是并行重构与传统串行重构最大不同的环节——并行重构的检查必须更加全面和严格。
不同代理修改的不同模块之间可能存在相互引用。例如，模块A调用了模块B的某个方法，而两个模块可能由不同的代理重构。需要逐一检查跨模块引用的方法名、参数列表、返回值是否匹配。
使用工具扫描所有公共接口的签名变化，确保调用方和被调用方之间的契约关系没有被破坏。任何不兼容的修改都应在合并前修复。
运行完整的单元测试、集成测试和端到端测试套件。重构应保持测试全部通过——任何测试失败都意味着重构引入了问题，需要立即定位和修复。
在合并前，Master应审查所有子代理分支的Git diff，从整体上把握变更范围，发现潜在的逻辑错误或遗漏。重点关注被删除的代码——重构最容易犯的错误就是无意中删除了仍有用的功能。
核心原则：重构的本质是在不改变外部行为的前提下改善内部结构。一致性检查的核心就是验证"行为不变"这个前提是否仍然成立。
所有子代理完成重构并通过自查后，进入结果合并阶段。这是并行重构的最后一步，也是最有挑战性的一步。
每个子代理在各自的worktree中将修改提交到独立的分支。分支命名应清晰标识责任模块，例如 refactor/user-module、refactor/order-module。
Master（主代理）逐个合并各个子分支到主分支。合并顺序应从改动最小的分支开始，逐步合并改动较大的分支，将冲突控制在最小范围。
并行重构的合并冲突通常源于多个Worker修改了同一文件的邻近区域。解决冲突时需要参看改规范文档，判断各方的修改意图，必要时与相关Worker沟通确认。
每次合并一个分支后都运行一次完整测试套件，确保持续集成的稳定性。所有分支合并完成后，再执行一轮全量回归测试，包括性能测试和冒烟测试。
在实际的并行重构过程中，以下几类问题最为常见，需要提前做好预案：