代理式编程：AI Agent如何重塑遗留系统现代化改造

开发者的隐痛：60%的时间都在"考古"

有件事大多数软件团队心知肚明却常常避而不谈——开发人员花在理解现有系统上的时间，远比写新代码要多。研究显示，大约60%到70%的开发时间都耗在了理解上下文上，然后才能安全地动手改代码。

这就像你拿到了一栋不是你亲手盖的房子的钥匙。你当然能看到各个房间，但你根本不明白为什么壁橱里会有个电灯开关，或者为什么浴室的一根水管会通到厨房。你得先把这些都搞清楚，才能安全地进行改造。

而代理式编程（Agentic Coding）的出现，正在从根本上改变这一现状。它指的是一种AI系统，能够自主地探索和理解代码库，提出修改建议，并在几乎不需要人工干预的情况下执行任务。

技术背景：什么是代理式编程？ 代理式编程是大型语言模型（LLM）与自主任务执行能力结合的产物。与传统的AI代码补全工具（如早期的GitHub Copilot）不同，Agentic Coding系统能够主动调用工具、读写文件、执行命令，并在多步骤任务中保持上下文记忆。其底层通常基于ReAct（Reasoning + Acting）框架或类似的"思考-行动-观察"循环，使AI能够像人类工程师一样迭代地探索未知代码库。代表性产品包括Anthropic的Claude配合工具调用、OpenAI的Codex Agent、以及专为代码库分析设计的Cursor Agent模式等。

值得注意的是，代理式编程并非凭空出现，而是AI辅助编程工具经历三个阶段演进的结果：第一阶段是静态代码补全（如早期IntelliSense），其本质是基于语法规则的自动完成，不具备语义理解能力；第二阶段是基于LLM的上下文感知补全（如GitHub Copilot初版），能够理解代码意图但仍是被动响应；第三阶段才是具备工具调用和自主规划能力的Agent系统，能够主动发起多步骤行动序列。这一演进的关键技术突破是**Function Calling（函数调用）**能力的成熟——OpenAI于2023年6月正式发布该能力，使LLM能够以结构化方式调用外部工具、文件系统和执行环境，从"回答问题"升级为"完成任务"。正是这一能力，让AI第一次真正具备了在复杂代码库中"自主考古"的条件。ReAct框架则进一步解决了多步骤任务中的规划问题：AI在每一步行动前先进行显式推理（Reasoning），执行后观察结果（Observation），再决定下一步行动（Acting），这种循环使其能够在遇到意外情况时自我纠正，而非盲目执行预设脚本。

接下来我们通过一个金融服务公司的真实场景，来看看这种智能编码方式如何解决软件工程中最大的挑战之一——遗留系统现代化改造。

场景还原：当金融系统需要"动手术"

假设我们是一家金融服务公司，运行着一个庞大的Java应用程序。这个系统集客户账户、贷款审批、支付处理和报告流程于一身。现在有个新需求：增加一个实时的、由AI驱动的风险评分功能，让客户可以及时获得贷款审批结果。

听着很棒，对吧？但要实现它，团队必须进行现代化改造——同时不能把现在还能用的功能搞坏了。

冰山之下：理解丢失才是真正的敌人

遗留系统现代化改造的挑战其实并不在于那些老旧的代码本身，问题在于理解丢失。可以把它想象成一座冰山：你能看到的代码只是冰山一角，水面之下是那些随着时间流逝而消失的一切——

• 为什么贷款审批流程要按特定顺序执行检查？
• 为什么定期的报表任务要在凌晨两点运行？
• 为什么在支付流程里改一行代码曾经导致客户账户冻结了四个小时？

当初编写这些代码的人也许已经离职了，这些知识被埋没在了多年的补丁和更新之下。

行业背景：遗留系统与技术债 遗留系统（Legacy System）在金融、医疗、政府等行业尤为普遍。据Gartner估计，全球企业IT支出中约有60-80%用于维护现有系统，而非构建新功能。Java 8于2014年发布，其长期支持（LTS）版本至今仍被大量金融机构使用，原因在于迁移成本极高——不仅涉及代码兼容性，还牵涉监管合规认证、第三方库授权等复杂因素。技术债（Technical Debt）这一概念由Ward Cunningham于1992年提出，用以描述为追求短期速度而牺牲长期代码质量所积累的"利息"，遗留系统正是技术债长期累积的典型形态。

技术债在金融行业的成本远超一般认知。麦肯锡2023年研究显示，大型银行平均有35%的IT预算被技术债的利息所消耗，部分机构高达70%。Java 8在金融机构的持续使用不仅是技术惯性，更涉及监管合规的锁定效应——许多金融机构的核心系统通过了特定Java版本的监管认证，升级意味着重新认证，成本可能高达数千万美元。这也解释了为什么"现代化改造"在金融行业往往是一个需要以年为单位规划的战略项目，而非单纯的技术升级。

值得关注的是，技术债的积累往往遵循一种"利滚利"的复利模式：早期为赶工期而跳过的文档编写，会导致后续维护者需要花更多时间理解代码；理解成本的增加又迫使维护者采取更保守的"最小改动"策略，进一步加剧代码的碎片化；碎片化的代码又使新功能开发更加困难，形成恶性循环。这正是为什么许多金融机构的遗留系统会在某个临界点突然变得"无人敢动"——技术债的利息已经超过了系统的改造能力。从博弈论角度看，这一临界点往往伴随着一种"集体理性陷阱"：每个开发者个体都知道系统需要根本性重构，但每个人都倾向于选择最小改动以规避个人风险，最终导致系统整体持续恶化。代理式编程的出现，在某种程度上正是通过降低"理解成本"这一关键变量，试图打破这一集体理性陷阱。

遗留系统的三大"暗礁"

当团队试图加入新的风险评分工具时，有三个方面让他们觉得特别棘手：

1. 纠缠的依赖关系

应用程序的不同部分随着时间推移变得深度关联，其方式团队从未完全理清过。修改一下利率的计算方式，合规报告系统就突然开始标记错误的账户。为什么？因为两者悄悄共享了一个团队无人知晓的数据表。

2. 框架与版本缺口

系统运行在Java 8上，它在线程和内存管理方面的处理方式与现代版本截然不同。像升级到Java 17这样看似常规的操作，都能暴露出数十个隐藏的兼容性问题，以及团队多年未碰的库。

3. 未记录的外部连接

系统连接着外部信用机构、支付网络和监管报告系统，每一个都有自己严格的数据格式要求。改变内部一个字段的格式，可能导致一份夜间合规报告开始拒绝提交，而团队中没有人能立刻理解原因。

所有这些加在一起，就是那60%到70%开发时间神秘消失的真正原因。团队一直无法真正推进业务部门要求的实时风险评分——每次接近完成，系统可能崩溃的复杂性又把他们拉了回去。

AI开发伙伴的五步现代化周期

而这正是代理式编程中的AI Agent被设计来解决的问题。可以把AI开发伙伴想象成一个建筑检查员——他能对整个系统进行X光扫描，在任何人拿起锤子之前就追踪每一条线路、绘制好每一条管道。

重要的是，这并非一次性完成，而是一个可迭代的现代化周期：了解现状→做安全改动→验证→在此基础上扩展。

第一步：分析代码库，构建工作模型

AI Agent会分析整个应用程序，构建一个关于一切如何连接的工作模型，包括调用路径、数据流和隐藏的依赖关系。

技术原理：静态分析与语义理解的结合 AI Agent分析代码库并构建"工作模型"的能力，建立在静态代码分析（Static Code Analysis）和调用图（Call Graph）构建技术之上。传统工具如SonarQube、Understand等已能生成依赖关系图，但它们输出的是结构化数据，需要人工解读。现代Agentic系统的突破在于将这些图谱与自然语言推理结合——AI不仅能绘制"A调用B"的关系，还能推断"为什么A必须在B之前调用"的业务语义。这种语义理解能力来源于LLM在海量代码和技术文档上的预训练，使其能够识别金融领域特有的合规检查模式、事务顺序约束等隐性规则。

更深层的技术原理在于**程序切片（Program Slicing）**与语义嵌入（Semantic Embedding）的结合。程序切片技术最早由Mark Weiser于1984年提出，其核心思想是：给定程序中的一个兴趣点（如某个变量的赋值），自动计算所有可能影响该点行为的代码语句集合，形成一个"切片"。这一技术能够从任意代码点出发，自动追踪所有影响该点行为的代码路径，将数百万行代码中的相关逻辑精准提取出来。语义嵌入则将代码片段转化为高维向量空间中的点，使功能相似但写法不同的代码在向量空间中彼此靠近——这使AI能够识别出"这段Java代码和那段Kotlin代码实际上在做同一件事"的等价关系。两者结合，使AI Agent能够在数百万行代码中精准定位"贷款审批必须按特定顺序执行"这类隐性约束——这正是人类工程师需要数周时间才能发现的内容。

对于金融系统而言，这种能力尤为关键：许多合规约束从未被显式编码为注释或文档，而是以特定的调用顺序、数据流向等隐性方式存在于代码结构中。程序切片与语义嵌入的结合，本质上是在将这些"沉默的知识"（Tacit Knowledge）重新显式化——这与知识管理领域中野中郁次郎（Ikujiro Nonaka）提出的"知识螺旋"理论高度契合：隐性知识通过外化（Externalization）转化为显性知识，才能被组织有效传承和利用。AI Agent在此扮演的角色，正是这一外化过程的自动化执行者。

几乎立刻，它就发现了团队以前不知道的事情：每笔贷款申请实际上都会触发一个非常特定的序列——信用核查→观察名单审查→合规验证，且顺序严格，从未在任何地方被记录下来。没有这一发现，团队就可能分离错误的逻辑，贷款决策将开始返回错误的结果。在改动任何代码之前，这个风险就已经被消除了。

第二步：确定安全的改动范围

模型就位后，AI Agent会提议在哪个安全位置拆分贷款决策逻辑——不只是提取什么，还包括什么依赖于它、它依赖什么，以及新服务应该如何与系统其他部分通信。它会标记边界条件、共享数据和隐藏的耦合，团队不用猜该在哪里划清界限，而是在验证一个已经被映射好的边界。

架构模式：绞杀者无花果模式（Strangler Fig Pattern） AI Agent"确定安全改动范围"的工作方式，与软件架构领域著名的**绞杀者无花果模式（Strangler Fig Pattern）**高度契合。这一模式由Martin Fowler于2004年提出，灵感来自热带雨林中绞杀者无花果树的生长方式：新树围绕老树生长，逐渐取代老树，而老树在整个过程中持续提供支撑，直到被完全替代。在软件工程中，这意味着新系统逐步"包裹"旧系统，每次只迁移一个功能模块，而非一次性重写整个系统。这种方式将大型迁移项目分解为一系列小型、可验证的步骤，每一步都可以独立回滚，大幅降低了整体风险。AI Agent在此模式中的价值在于：它能够精确识别哪些模块之间的耦合度足够低，可以安全地作为第一批迁移对象，从而为绞杀者模式的执行提供数据驱动的优先级排序，而非依赖架构师的主观判断。

第三步：生成测试覆盖率

在改动任何东西之前，AI会根据它发现的内容生成一整套测试——不仅仅是快乐路径（Happy Path），还包括边界情况：信用检查超时、部分申请失败、客户在流程中途被标记等。

测试方法论：从快乐路径到真实行为覆盖 软件测试中的"快乐路径"（Happy Path）指系统在所有输入均符合预期、无异常情况下的正常执行流程。然而真实系统的故障几乎从不发生在快乐路径上，而是发生在边界条件（Edge Cases）和异常场景中。传统测试覆盖率工具（如JaCoCo）只能衡量代码行是否被执行，无法保证业务场景的完整性。AI生成测试的优势在于：它能从代码的实际行为中反向推导出测试用例，而非依赖开发者的主观想象。这与基于属性的测试（Property-Based Testing）理念相近，但更贴近业务语义，对于金融系统中的超时处理、部分失败回滚等场景尤为关键。

这一方法在学术上与**变异测试（Mutation Testing）**有深刻关联。变异测试由Richard Lipton于1971年首次提出，其核心思想是：通过故意向代码引入小错误（称为"变异体"，如将>改为>=，或将+改为-），检验现有测试套件是否能捕获这些错误。若测试未能检测到变异体，说明测试本身存在盲区。变异测试评估的是测试质量而非仅仅是覆盖率——一个测试套件可以达到100%行覆盖率，却对大量变异体"视而不见"。AI生成的测试天然倾向于覆盖那些"变异体最容易存活"的高风险区域——即那些逻辑复杂、边界模糊的代码路径，因为这些区域在AI的语义分析中会呈现出更高的"不确定性信号"。

对于金融系统而言，这意味着AI会优先生成针对金额计算精度（浮点数精度陷阱）、并发事务冲突（竞态条件）、网络超时重试（幂等性保证）等场景的测试，而这些恰恰是人工测试最容易遗漏、却在生产环境中最频繁引发故障的地方。值得一提的是，金融领域的浮点数精度问题有其特殊性：IEEE 754标准下的浮点运算在处理货币金额时会产生不可预测的舍入误差（如0.1 + 0.2 ≠ 0.3），这正是金融系统普遍使用BigDecimal而非double的原因。AI在分析遗留代码时，能够识别出那些错误使用浮点类型处理货币的历史代码，并生成专门针对精度边界的测试用例，这类细节往往是人工审查最容易忽视的系统性风险。

AI围绕真实行为构建覆盖率，而不仅仅是团队自以为系统在做什么。这在所有场景下都可行吗？不一定。但这比团队从头开始能真正创建的覆盖率要高得多，尤其是在时间紧迫的情况下。

第四步：开发人员审查和批准

这时候开发人员重新介入。他们审查提议的边界、验证假设并检查生成的测试，然后在每一步继续推进之前进行批准。

关键区别在于：他们不是要花上几周时间在遗留代码里翻找、试图弄清楚什么跟什么在通信，而是带着他们的判断力直接介入决策环节。

人机协作模式：以人为中心的AI工作流 这一步骤体现了当前AI辅助工程实践中的核心设计原则——人在回路（Human-in-the-Loop，HITL）。HITL并非简单地在AI流程中插入人工审批节点，而是一种经过深思熟虑的权责分配设计：将AI的优势（大规模信息处理、模式识别、不知疲倦的代码扫描）与人类的优势（业务判断、伦理评估、对组织上下文的理解）精确对齐到各自最擅长的任务上。在这一框架下，开发者的角色从"信息收集者"升级为"决策者"——他们不再需要花费大量时间收集做决策所需的信息，而是直接面对已经被AI整理好的决策材料，将认知资源集中在真正需要人类判断的地方。这种模式在医疗AI辅助诊断、自动驾驶安全员等领域已有成熟实践，其共同特征是：AI处理信息密集型任务，人类保留最终决策权，且人类的介入点被精心设计在"信息充分但决策尚未执行"的关键节点上。

第五步：新旧系统并行运行

一旦引入新系统，它不会立即取代旧系统，而是和旧系统一起运行——同样的输入，两个输出。如果出现任何差异，AI Agent会立刻标记出来，提供完整上下文：什么变了、差异在哪里。团队能在客户看到之前、在问题进入监管报告之前尽早修复问题。

工程实践：影子模式（Shadow Mode） 这种"新旧系统并行运行"的方式在工程领域称为影子模式（Shadow Mode）或暗启动（Dark Launch），是大规模系统迁移的标准安全实践。其核心思想是：新系统接收与旧系统完全相同的生产流量，但其输出结果不对外暴露，仅用于内部对比验证。Netflix、Google等科技公司在关键系统迁移中广泛采用此模式——Google曾在其广告竞价系统迁移中使用影子模式运行长达18个月，才完全切换到新系统。影子模式的技术实现通常依赖流量复制（Traffic Mirroring）或请求分叉（Request Forking）机制，确保新旧系统接收到完全一致的输入，从而使输出差异能够被精确归因于系统逻辑的变化而非输入差异。

在金融场景下，影子模式的意义远超工程层面，具有直接的法律合规价值。巴塞尔协议III和各国金融监管机构对系统变更均有明确的验证要求，美国OCC（货币监理署）的技术风险管理指引明确要求关键系统变更需有"平行运行"记录，且平行运行期间的差异必须被记录、分析和解释。影子模式产生的差异报告不仅是技术文档，在监管审查中可作为系统等效性验证的法律证据——这使其在金融场景下从"最佳实践"升级为"合规必要条件"。对于中国市场，银保监会的《银行业金融机构信息科技风险管理指引》同样对重大系统变更的验证程序有类似要求，影子模式的记录可直接支撑合规审计材料的准备。

值得注意的是，AI Agent在影子模式中的角色不仅是被动记录差异，更能主动分析差异的根因——区分"这是预期的行为改进"与"这是意外的回归缺陷"，大幅降低人工审查的工作量。这种能力依赖于AI在第一步构建的代码工作模型：当差异出现时，AI能够将差异与已知的代码变更精确对应，而非仅仅呈现一个"新旧输出不一致"的黑盒结论。从某种意义上说，影子模式与AI分析能力的结合，将传统的"发现问题→人工排查→定位根因"流程压缩为"发现问题→AI定位根因→人工确认"，这一效率提升在高频交易、实时风控等对响应速度要求极高的金融场景中具有决定性价值。

安全措施：三道不可或缺的防线

让AI去处理一个涉及真实贷款申请、合规报告、监管审查的系统，这可不是团队应该掉以轻心的事。只有当控制、验证和可追溯性从一开始就构建好时，代理式编程才行得通。具体体现在三个方面：

1. 人工批准：任何改动，尤其是那些影响报告管道的改动，都必须经过开发人员审查和批准后才能进行
2. 完整的变更历史：一切都记录在Git中，易于审查、易于回滚
3. 没有自主部署：在任何东西上线之前，开发人员始终掌握着控制权

这些安全措施让整个方法足够可靠，团队可以在真实用户和监管机构每天都要依赖的系统上放心使用。

可追溯性的深层价值：从工程实践到监管语言 上述三道防线的共同底层逻辑是可追溯性（Traceability）——每一个决策、每一次变更都有清晰的来源记录和责任归属。在软件工程中，Git提供的版本控制是可追溯性的技术基础；但在金融监管语境下，可追溯性还有更深的含义：它是**问责制（Accountability）**的技术实现。当监管机构询问"为什么这个贷款决策在某个时间点发生了变化"时，完整的变更历史不仅能回答"什么变了"，还能回答"谁批准了这个变更"、"基于什么分析做出的决策"。这种从技术记录到监管证据的转化，正是将AI辅助工具引入受监管行业的核心挑战——工具本身的能力固然重要，但其产生的决策轨迹是否符合监管机构对"可解释性"和"可审计性"的要求，往往才是决定能否真正落地的关键因素。

从"考古"到"交付"：代理式编程的核心价值

最终，这个开发团队按时交付了实时风险评分功能。以前浪费的时间——那些花在"考古"旧代码上的精力——现在直接转化为了实际的开发工作。

代理式编程的核心价值并不在于替代开发者，而在于将开发者从理解丢失的泥潭中解放出来，让他们把判断力和创造力用在真正需要的地方。在遗留系统现代化改造这个领域，AI Agent正在从"锦上添花"变成"不可或缺"。

你们团队现在是怎么应对遗留系统的现代化改造的？

核心要点