使用AI代理重构单体应用的经验教训

# 我们使用AI智能体重构单体应用所学到的 | 1Password 来源：https://1password.com/blog/what-we-learned-using-ai-agents-to-refactor-a-monolith **AI智能体正越来越多地被用于重构大型代码库，但许多团队对它们在哪里成功、在哪里失败缺乏清晰的理解。在1Password，我们将智能体工具应用于一个数百万行代码的Go单体应用，在本文中，我们将分享哪些方法有效、哪些出了问题，以及这对在生产系统中采用AI的团队意味着什么。** 情况是这样的：1Password运行着一个名为B5的大型Go单体应用。它多年来一直是我们产品的基础，在生产环境中无论是可靠性还是规模都表现良好。 现在，Unified Access（https://1password.com/product/unified-access）旨在支持高请求率、低延迟下的人类和智能体驱动的工作流。随着我们不断添加和增强其功能，需要更清晰的服务边界和更独立的扩展特性。随着时间的推移，这意味着要以一种保留我们已建立的隐私、性能、可靠性和安全属性的方式来演进系统的各个部分。 想出一个可行的方案来解决这个问题，听起来很适合交给智能体来做。 在我们的案例中，这意味着应用*智能体重构*：使用AI智能体来分析、规划并跨代码库执行变更，从依赖映射到系统分解。 故事的某个版本是这样的：智能体工具分析大型代码库，生成一个清晰的提取计划，然后服务分解沿着可预测的路径进行。 那个版本的部分情节确实如预期般发生了。我们构建了一个智能体工具链，分析了数百万行代码，给出了一个清晰、可辩护的提取顺序，这项工作显著改善了我们对系统分解的思考方式。 然而，最终更有价值的是，当我们将这些工具应用于生产环境中的真实变更时所学的经验。那部分往往被轻描淡写，而它实际上决定了这种方法是否有效。 ## 构建分析层 我们要回答的第一个问题是排序。在一个大规模处理敏感数据的系统中，提取顺序是一个正确性约束。如果顺序搞错了，就可能引入难以检测、事后更难撤销的细微故障。 为了解决这个问题，我们构建了一个智能体工具链，结合了几种不同的信息来源。 我们使用了Go SSA（https://pkg.go.dev/golang.org/x/tools/go/ssa）分析来理解代码结构，SQL解析来识别数据依赖，以及DataDog MCP集成来引入运行时耦合数据。这些结合起来，为我们提供了领域所有权映射、耦合图以及优先提取顺序。 输出结果与经验丰富的工程师审视系统时预期的结果大致吻合。它建议从Vault开始，因为它有自己的API、数据集和安全边界，然后是Billing，接着是AuthN和AuthZ，而Identity作为核心保留。 一种特别有效的模式是使用智能体来构建确定性工具，而不是依赖它们进行持续的解释。在这种情况下，智能体帮助编写了SSA分析器的部分代码，该分析器随后生成了一个可复现的领域映射。这个区别很重要，因为一旦工具存在，你就是在对一个稳定的产物进行推理，而不是争论模型认为系统是什么样子。 这项工作带来的一个意想不到的好处是，我们为支持分析而添加的仪器化也提高了我们在DataDog中的端到端事务可见性，这在此项目之外也很有用。 一张图表，展示了1Password团队如何将任务划分为确定性工具和非确定性工具，用于领域映射和提取。 ## 找到人与智能体的比例 与提取分析并行，我们将相同的方法应用于代码库中一项长期存在的清理任务。 我们的Go服务器使用`MustBegin`来启动数据库事务，这在失败时会触发panic。这种行为在早期是有意义的，因为它能在开发过程中快速暴露数据库问题，但在生产规模下，当连接超时或请求上下文被取消时，这并不是你想要的行为。在这些情况下，返回一个干净的错误才是正确的结果。 迁移需要更新生产和测试代码中的3,000多个调用点，这就是为什么它一直积压在待办清单中。 我们采取的方法非常有条理。我们使用SSA生成了每个调用点的确定性清单，将这些点分类为少量模式，并为每种模式定义了显式模板。然后，我们编写了一份详细的操作手册，准确描述了智能体应如何执行迁移，包括常见故障模式列表，以及关于何时停止并升级而不要猜测的明确指示。为了扩展执行规模，我们使用git worktrees并行运行多个智能体，以便变更保持隔离。 执行本身只花了几个小时。大部分时间花在构建工具和编写规范上。 一张图表，展示了人类和智能体在1Password智能体重构项目中的协作方式。 这个比例是重要部分。当工作被完整指定并有边界时，智能体既快速又准确。当它们遇到规范之外的东西时，系统会设计成将其暴露出来，而不是试图隐式地解决。 ## 智能体需要更强约束的地方 然后我们转向了一项更复杂的任务：从单体应用中提取一个服务。 即使对于相对较小的服务，这类工作需要跨模式演进、读写路径、部署顺序和共享数据契约进行协调变更。这些是相互依赖的决策，需要按正确顺序进行。我们在此任务中看到的主要问题与排序和不变量有关。 例如，智能体会尝试在更新负责插入新行的代码之前回填UUID列。这种顺序会导致静默的数据丢失，即使底层系统在其他方面设计良好。在其他情况下，它会把共享表当作由新服务独立拥有，这会在部署时产生冲突。即使我们提供了关于排序和约束的明确指令，这些模式依然持续出现。 我们还看到一种重复出现的行为，我们内部称为“推测”。当智能体缺乏足够的上下文时，它会用看似合理但未经验证的假设来填补空白。在一个案例中，它推断某个标识符格式是ULID，并将该假设传播到一系列变更中，最终导致整个会话需要回滚。 > “有效的模式是使用智能体生成确定性产物，然后强制通过那些约束来执行。例如，在Cursor中，我们看到许多客户使用Plan Mode搭配更大、更慢的模型（如GPT5.4或Opus）来生成一个具体的plan.md文件，根据需要编辑该文件，然后实际使用更小、更快的、擅长编码的模型（如Composer）来构建。”——Tido Carriero，Cursor工程副总裁 对于这类工作，生产力提升是真实的但较为有限。实际上，我们看到了大约20-30%的改进。智能体很有帮助，但并没有取代仔细协调和审查的需要。 这指向了1Password正在经历的更广泛的转变。AI智能体正在成为系统中一种新的参与者，它引入了传统模型未设计来处理的非确定性、持久性和规模。这不仅对工程工作流有影响，也对跨系统的访问和信任管理方式有影响。 ## 给在代码中使用AI智能体的团队的经验教训 其他团队可以从1Password的经验中汲取许多教训，并且它们的应用范围超出了这一单一用例。 ### 教训一：智能体重构的瓶颈不是代码生成 智能体在阅读代码、分析结构以及草拟变更方面非常有效。困难在于管理那些有排序约束或难以撤销的决策序列。这包括模式变更、部署顺序和共享状态边界。如果这些处理不当，无论生成的代码多么干净，系统都会失败。 ### 教训二：非确定性需要小心地加以控制 语言模型是非确定性的，这在一定程度上正是它们有用的原因。然而，在生产迁移的上下文中，这种可变性成为了风险源。对我们来说行之有效的模式是使用智能体来构建确定性工具，如分析器和清单，然后将后续工作约束在这些输出上。这创建了一个稳定的基础，即使智能体本身并非完全可预测。 ### 教训三：不完整的规范会导致隐式的规范 当智能体没有足够的上下文时，它会填补空白，通常以局部合理但全局错误的方式。解决这个问题的唯一可靠方法是使规范显式化，包括不变量、排序约束，以及对于任何超出定义模式的情况的明确升级路径。 另一个重要的转变是关于如何思考覆盖范围。目标不是让智能体处理每一种可能的情况，而是让它在充分理解的模式上自信地执行，并在遇到模棱两可时迅速升级。这需要有意识地确定自动化在哪里停止，人类判断在哪里介入。 ### 教训四：只有解决了隔离问题，并行才有效 同时运行多个智能体可能非常有效，但前提是变更相互独立且冲突在结构上被消除。否则，你最终会增大不一致的表面积，而不是减少执行时间。 ## 这对1Password的智能体方法有何影响 我们正在整个工程组织中推广智能体工具，并清楚了解它在哪里能提供杠杆作用。 我们知道，当问题被充分指定时智能体最有效，而确定性工具提供了使其成为可能的约束。工程师仍然负责定义系统边界、建模依赖关系以及确保排序正确。 这些见解将帮助我们转变分配给工程师的工作性质，理解到最高杠杆的活动不是编写代码或提示模型，而是定义能够安全且可预测地执行的系统。 我们正在处理的问题，包括在实时流量下分解生产系统以及构建多智能体执行结构，目前还没有成熟的操作手册。我们正在实时构建这些手册，而这正是大部分有趣工程工作发生的地方。 如果你喜欢解决这类问题，我们正在招聘（https://jobs.ashbyhq.com/1password?departmentId=96a94955-dadd-4290-94ad-1ab70ecccace）。