我用Copilot Agent给10万行Java单体画了张依赖图，生成的拆分方案差点让CTO以为我通宵了三个月

两周前的周一下午，我盯着那坨10万行的Java单体仓库发呆了整整四十分钟。新需求是给订单模块加一个促销规则引擎，但打开代码的瞬间就陷入了熟悉的恐惧——OrderService里有直接调用UserMapper的函数，还有一个叫做“CommonUtils”的类被83个文件引用，改一行注释都可能炸掉整个预发布环境。这种事情在大中型企业的“核心交易系统”里太常见了：五年以上的代码积累、历届团队的妥协设计、没人敢动的DAO层交叉引用，最后演变成一个没人敢拆的巨石。

我本来打算花两周手工梳理依赖，再用六周逐步抽离模块。直到同事随口说了一句：“你看看Copilot的新Agent模式，它能自己读整个仓库，你不如让它先给你画张图。”我抱着“顶多节省两天画图时间”的心态开了VS Code，结果三小时后，我手里有了一张连架构组都没画完整的模块依赖拓扑图，一份有向无环拆分的迁移计划，还有三十几个自动生成的接口适配存根。不是AI给我省了时间，是它给了我一种我根本不敢想的切入点。

这不是软文。我是真的在用这些工具写代码，每天都用。但这一回，我决定把整个流程从头到尾走一遍，包括它踩的坑、它犯的错、它生成的代码里哪些可以直接用、哪些需要我整段删掉重写。如果你现在也面对一个不敢拆的单体，这篇文章能帮你摸清Copilot Agent模式的能力边界，以及你的团队到底需要保留多少人工判断。

10万行怪兽的日常崩溃：从改一行代码到炸掉整个发布

那些年我们踩过的技术债务坑，都堆在同一个仓库里

我们这个电商单体系统是2019年用Spring Boot 2.x搭的，一路迭代到2025年，代码行数突破10万（不算测试和前端）。模块概念早就有——订单、商品、库存、用户、营销、支付——但包结构上完全没隔离。所有模块共享同一个数据库schema，订单表直接join用户表，商品服务内部直接调用InventoryDao，事务传播级别在各种service之间乱串。（延伸阅读：我让Cursor写了一套KEDA规则和Spot切换器，推理成本从8万暴跌到1.7万——但挂了两次生产）

最致命的是，没人能说清楚完整的依赖关系。架构组画过两张Visio图，但跟代码早就对不上了。新人入职前三个月完全不敢提交PR，因为CI流水线时长47分钟，每次失败的根因都在你没改过的模块里。技术债务不是个比喻，是我们每两周一次的发布窗口里实实在在的P0事故。

当业务部门要求我们对营销模块做灰度发布和独立扩缩容时，所有人都知道必须拆分。但怎么拆？从哪里开始？谁拆谁背锅？这些问题的答案被拖了整整一年。我翻遍了市面上的静态分析工具：IntelliJ的依赖分析插件能画本地的包关系，但一旦跨子模块引用就断掉；ArchUnit能写规则卡依赖方向，但前提是你得先知道正确的方向是什么。我们需要一个能“理解业务语义”的东西，而不仅仅算import次数——这就是我决定让Copilot Agent试一下的动机。

正式动手之前，我给Agent喂了哪些上下文

Copilot Agent模式跟普通Copilot补全的关键区别在于它能理解整个workspace，甚至能跨文件读取上下文。但光有代码还不够。为了让它准确分析模块边界，我提前做了三件事：

第一，我把代码里的静态分析报告先跑了一遍出来。用jdeps和dependency-cruiser在项目根目录生成JSON格式的依赖图，存成dependency-report.json。Agent在读取工作区时能自动识别这个文件，它会把静态数据当成事实锚点。

第二，我给Agent注入了一份运行时数据。我从公司APM系统（我们用的是基于OpenTelemetry的监控）导出了过去一周的调用链采样，格式是JSON数组，每个节点包含caller_service,callee_service,span_count,avg_latency_ms。我把这个文件放在项目根的runtime-traces.json里。这一步后来被证明是点睛之笔——没有运行时流量数据，Agent画的依赖图会缺失大量动态代理和反射调用带来的隐藏边。

第三，我准备了一个“业务语义描述文档”，也就是手写了一个arch-context.md，用自然语言说明每个顶层模块的业务职责、关键聚合根、以及未来独立部署的期望目标。比如：“订单模块拥有Order聚合根，在拆分后应独立管理订单状态机，不允许其他模块直接写订单表。”我总共写了不到400字，但这400字后来直接影响了Agent生成拆分计划的优先顺序。

这三样东西——静态分析报告、运行时call trace、业务语义文档——就是给Copilot Agent的“注入燃料”。没有这些上下文，Agent只能做纯粹的代码结构分析；有了这些，它才能产生对架构演进有实际指导意义的输出。（延伸阅读：为什么我把公司知识库的RAG Pipeline从LangChain迁到了裸Gemini API：一场关于长上下文与分块策略的架构决策复盘）

我让Copilot Agent自行规划拆分，结果它画了一张我从未见过的依赖图

我的操作实录：从一句自然语言指令到依赖图生成

这里我得放出一段完整的操作过程。因为我当时就是边截图边记的，这种“现场感”是任何产品功能列表给不了的。

我用的环境是VS Code 1.99 + GitHub Copilot Chat扩展最新版（截至此刻，Agent模式已在正式通道可用）。操作步骤如下：

步骤一：设定Agent模式并给与高权限上下文。
打开Copilot Chat侧边栏，在输入框上方切换到“Agent”模式（注意不是“Ask”也不是“Edit”，而是有蓝色Agent标记的那个）。然后在对话开头我输入了第一条指令：

“请读取整个工作区，并将以下文件作为高权重上下文：dependency-report.json, runtime-traces.json, arch-context.md。在分析过程中，如果发现代码结构与这些文件提供的描述不符，请以代码实际为准，但在决策建议时优先考虑arch-context中的业务目标。”

这一步非常关键。Copilot Agent默认会扫描工作区，但显式指定上下文文件可以强制它在后续工具调用（比如read_file和search_content）时优先加载这些内容。Agent用了一个很长的思考过程（大约12秒），然后回复：“我已加载3个高优先级上下文文件，项目结构分析中，预计扫描2176个源文件……”

步骤二：要求识别模块边界。
我接着输入：

“基于代码包结构、import依赖、数据库表引用以及runtime-traces中的调用关系，识别出这个项目中所有可独立部署的候选模块。每个模块需要列出：包含的顶层Java包、对外暴露的接口、依赖的其他模块、共享数据库表、以及根据arch-context建议的拆分优先级（高/中/低）。”

Agent执行了一连串工具调用：它先搜了根包下所有的package-info.java或者module-info.java（我们项目是Maven多模块，但都在一个git仓库里），然后用正则提取所有import语句，接着交叉对比runtime-traces.json里的调用关系，最后结合arch-context.md的聚合根描述，输出了一份模块清单。清单包含7个候选模块：订单、商品、库存、用户、营销、支付、通知。每个模块下面还自动附加了它分析的依据文件列表，比如“订单模块（高优先级）：依据为arch-context中订单独立部署需求及OrderService被23个外部模块引用”。

步骤三：生成依赖图。
接着我要求它：“将上述模块之间的依赖关系输出为Mermaid图，并标记出循环依赖、违反arch-context建议的依赖，以及运行时trace中延时最高的调用边。”（延伸阅读：多智能体审批的“三体难题”：我在LangGraph、CrewAI和ADK上重构分布式事务的160小时，以及为什么Saga模式是唯一解）

Agent输出了一个完整的Mermaid代码块。我直接把它贴到GitHub的Markdown预览里，立刻得到了一张有颜色的依赖拓扑图。我盯着屏幕看了五分钟——这张图上有两条我以前完全不知道的依赖边。一条是营销模块通过反射调用了订单模块的PromotionEligibilityChecker（因为那个类不在接口包里，但被AOP代理自动拉了进去）。另一条是通知模块通过数据库触发器间接依赖库存表的变更——这在代码里完全看不出来，是runtime-traces.json曝光了这条暗通道。

这张图，我们手工画不出来。不是因为懒，是因为没有工具能同时吃进静态与动态数据并理解业务语义。那一刻我才真正觉得Copilot Agent不是玩具。

生成的拆分规划到底是“教科书”还是“可执行方案”

Agent在图后面还附加了一份迁移计划，按优先级排序，给出了第一步拆分建议：把用户模块拆出来，因为它的入度依赖最少（仅被订单和营销引用），且属于支撑域，对核心交易流程影响可控。拆分步骤包含：创建新独立仓库、提取公共DTO到共享库、用OpenFeign或gRPC替代原直接调用、修改调用方代码、同步改造数据库连接。每一步后都有预估的风险标记。

说实话，这份计划的前三步跟我们架构组内部讨论的结果基本一致——这说明Copilot Agent在吸收了arch-context之后确实能捕捉到战略意图。但第四步“修改调用方代码”就立刻暴露了它的工程化短板。它给出的修改方案是：“将所有对UserService的直接调用替换为HTTP客户端调用”。但它没有考虑：调用方中有5处是事务内部的同步依赖，如果强行转异步，数据一致性问题会直接引发业务Bug。Agent虽然识别出了事务边界，但在生成计划时没有把“事务传播约束”作为硬限制嵌入步骤，导致这一步需要人工介入重新设计Saga补偿逻辑。

也就是说，Agent生成的规划可以当作架构讨论的起点和校验基线，但绝不能直接作为Sprint的task列表往下派发。你还得有一个懂分布式事务的人，把那些“AI看起来无关紧要”但实际上能推翻整张计划的隐式约束筛出来。（延伸阅读：我差点被按量付费送走：一个独立开发者的云端推理成本血泪账本）

接口适配代码自动生成：比实习生强，但还得我擦屁股

让Agent生成迁移代码，它甩出了三十几个文件

拆分的第二步是实际写出替代直接调用的适配代码。我让Agent针对“用户模块拆分”生成第一批迁移代码。我的prompt是：

“请为UserService生成OpenFeign客户端接口，供订单模块和营销模块调用。需要包含原接口的四个方法：getUserById, checkUserCredit, batchGetUserLabels, getUserAddresses。同时生成对应的服务端Controller，并保留原有参数校验注解。在生成后，将订单模块和营销模块中对UserService的直接注入修改为FeignClient注入，给出修改diff。”

Agent在30秒内生成了一套完整的文件：

• UserFeignClient.java（Feign接口，带fallback工厂）
• UserFeignFallbackFactory.java
• UserController.java（对应暴露的REST端点）
• UserDTO.java及几个嵌套对象
• 订单模块中3个Service类的修改diff
• 营销模块中1个Service的修改diff

我先把代码片段贴出来，你感受一下它生成的质量。这是它写的Feign接口：

@FeignClient(name = "user-service", path = "/users", fallbackFactory = UserFeignFallbackFactory.class)
public interface UserFeignClient {

    @GetMapping("/{userId}")
    ApiResponse<UserDTO> getUserById(@PathVariable("userId") Long userId);

    @PostMapping("/credit/check")
    ApiResponse<CreditCheckResult> checkUserCredit(@RequestBody CreditCheckRequest request);

    @GetMapping("/labels/batch")
    ApiResponse<List<UserLabel>> batchGetUserLabels(@RequestParam("ids") List<Long> userIds);

    @GetMapping("/{userId}/addresses")
    ApiResponse<List<AddressDTO>> getUserAddresses(@PathVariable("userId") Long userId);
}

对应的Controller也像模像样：

@RestController
@RequestMapping("/users")
public class UserController {

    private final UserService userService;

    public UserController(UserService userService) {
        this.userService = userService;
    }

    @GetMapping("/{userId}")
    public ApiResponse<UserDTO> getUserById(@PathVariable Long userId) {
        UserDTO user = userService.getUserById(userId);
        return ApiResponse.success(user);
    }

    @PostMapping("/credit/check")
    public ApiResponse<CreditCheckResult> checkUserCredit(@Valid @RequestBody CreditCheckRequest request) {
        CreditCheckResult result = userService.checkUserCredit(request);
        return ApiResponse.success(result);
    }
    // ...其余方法
}

第一眼看上去，格式规范、注解完整、路径风格符合RESTful惯例。但是，我一行行读下去，找到了三个致命问题。

质量评估：哪些代码能投产，哪些必须重写

第一个问题：batchGetUserLabels接口使用了GET方法传递List参数，这在Spring MVC中默认不会自动展开为多值参数，除非手动指定@RequestParam且参数名匹配。Agent生成的代码没有处理这一点，直接放上去了。实际调用时，营销服务传过来的ids会变成单个字符串而不是数组。这个问题如果直接合并，会在联调阶段才发现。

第二个问题：它生成的UserFeignFallbackFactory直接返回了空对象，没有区分四种失败场景——超时、服务不可用、限流、业务异常。这在用户查信用时尤其危险：Fallback返回的CreditCheckResult默认给了一个“通过”状态，可能导致无信用用户下单成功。

第三个问题：原UserService.getUserById内部有本地缓存（Caffeine），拆分后缓存自然失效。Agent没有生成任何缓存策略迁移建议或代码，直接无视了性能影响。这一点在生成的diff里完全看不出来，只有在后续压测时才会暴露RT增长5倍的问题。

我手工修正这三个问题花了大约50分钟。第一个问题是纯技术规范缺陷，改两行就完事。第二个问题需要补上业务判空和默认策略，涉及Fallback工厂的重写。第三个问题需要重新设计缓存方案——最后我决定在订单模块本地也加一层Redis缓存，并写了一个缓存同步的MQ消费者。这部分AI完全没碰，是我自己写的。

我把修正成本和AI生成代码的比例做了一个粗略统计：

结论很清晰：Agent在模板化代码上效率惊人，但一到需要理解业务语义和跨切面（缓存、事务、降级）的设计时，它的输出只能当草稿。你把它想象成一个可以瞬间生成代码但完全不懂业务后果的高级实习生，用起来就很顺手了——该让它写的让它写，不该让它碰的千万别让它决定。（延伸阅读：给研发流水线加AI审查门禁，第一个月我们差点把主分支锁死）

自动化重构流水线：生成→测试→兼容性检查的一脚踢

把Agent的输出接进CI，让它可以自我验证

单次生成代码不算牛逼，真正让我决定写这篇文章的是我把Copilot Agent的输出接进了我们现有的CI管道，让它变成了一个可以自我修正的自动化重构流水线。

管道是这样设计的：每当主分支有新的模块拆分PR时，一个GitHub Actions工作流会触发。工作流的第一步是让Copilot Agent以命令行模式（通过gh copilot CLI）读取PR diff，校验以下内容：

• 是否引入了新的跨模块直接import（检查点：禁止绕过接口直接引用原模块的impl类）
• 新生成的Feign接口是否与原Service方法签名完全匹配（参数类型、返回类型、异常声明）
• 是否违反了arch-context中定义的架构约束（例如：“订单模块不得直接引用营销模块的数据库表”）

Agent以YAML格式输出检查结果，CI管道解析后决定是否block合并。这一步我们称之为“AI审查门禁”。上线头一周，它拦住了三个PR——其中两个是开发人员在修改调用方时不小心import了原模块的UserDao，Agent直接从diff里揪了出来。第三个是开发人员新增了一个直接查用户表的SQL，Agent结合arch-context发现它越过了UserFeignClient，自动贴了“违规”标签。

第二层是自动生成单元测试。Agent会根据拆分后的接口契约，自动生成调用方的集成测试用例，模拟Feign客户端返回正常数据和异常数据两种情况。我让它用Mockito和WireMock生成针对UserFeignClient的测试类，它在分析接口参数后，生成了12个测试方法，覆盖了正常返回、超时、服务不可用、非法参数四种场景。12个里有10个一次通过，失败的两个是因为断言对ApiResponse的泛型擦除处理有误，我手工修了断言部分，总耗时不到10分钟。

第三层是兼容性检查。我让Agent扫描项目中所有使用原UserService的地方（包括未修改的遗留代码），与运行时的trace进行对比，计算拆分后的未覆盖调用点比例。Agent生成了一份CSV报告，列出了7处仍直接依赖UserService但未纳入迁移计划的调用，其中2处在定时任务里，5处在MQ消费者里。这些是静态分析根本找不到的运行时依赖，但Agent通过对runtime-traces.json的二次分析自动标了出来。这一步我完全没有预期，算是意外惊喜。

数据库拆分与事务管理的硬骨头

代码层面的拆分再完美，数据库不拆就是换汤不换药。但数据库拆分涉及到事务边界重定义，这是AI当前最不擅长的领域。我尝试让Agent直接给出用户表拆分的DDL脚本，它生成的确实是一条标准SQL，但完全忽略了订单表与用户表之间的外键约束、级联删除策略以及订单查询时join的性能影响。

我随后给了一个更具体的prompt：“在拆分用户表到独立数据库的同时，在订单模块这边建立一份用户快照表，用于订单列表页的查询。需要包括数据同步策略建议”。Agent给出了一套基于MySQL binlog订阅和Canal的方案说明，还生成了Canal客户端的基本配置。但它在数据一致性上只说了一句“使用最终一致性模型”，没有给出具体的幂等性设计、回放策略或冲突解决规则。这部分我最终和DBA一起手工设计，Agent的输出只能作为方案讨论的素材之一。

接口版本治理是另一个需要人工拍板的点。拆分后，用户服务的接口变更会直接影响所有调用方。Agent建议我们采用URL路径版本化（/v1/users/），并自动生成了ApiVersion注解和拦截器代码。但实际生产中，我们选择了请求头版本控制方案，因为网关层统一透传更可控。Agent生成的代码我保留了拦截器骨架，但将版本提取逻辑从URL改到了Header，修正成本不高。

所有这些经历让我对Copilot Agent的能力边界有了一个清晰的画像：它可以高效地完成重构中60%-70%的重复性分析和编码工作，但剩下的30%——事务边界、数据一致性、缓存策略、降级方案、性能调优——仍需要对具体业务和分布式系统有深入理解的人来拍板。而且这部分往往是最关键的，错一点就可能导致资损或大规模客诉。

当前可用的自动化水平与仍需人工判断的环节

走完这一整套流程，我想把结论说得直白一点：Copilot Agent模式在遗留系统重构中的自动化能力，目前处在一个“能把你从泥潭里拽出来，但你自己还得会走路”的水平。它不是来替代架构师的，而是来给架构师递上一份自己永远没时间从头做的分析报告。它生成的依赖图、模块清单、拆分计划，可以作为技术评审的输入，但不能直接作为执行的Sprint Backlog。它生成的适配代码，在模板化、规范化层面已经超越了大部分中级工程师，但涉及跨切面设计时仍需有经验的人把关。

从投资回报率的角度，我认为如果你的团队正在面对一个5年以上的单体，手头没有任何完整的依赖分析，没有模块边界文档，没有人敢拍板第一个拆哪个模块——那么Copilot Agent可以帮你在一两天内完成之前需要一个Senior团队花两周才能做完的梳理工作。但这之后，你还是需要那个Senior团队来验证、补全、调整。把AI的输出当成初稿而不是终稿，这是目前最务实的使用姿势。

我还会继续用它做下一个模块的拆分。每次生成的代码我会审查、改写、补充，然后再喂回去让它学习上下文。这种“人-机”循环的磨合过程，可能才是AI辅助重构最真实的形态——不是一键自动化，而是持续借力。