AI Agent 重构单体应用实战1Password 经验与避坑指南引言2026年5月1Password 公开了他们使用 AI Agent 重构核心 Go 单体应用 B5 的实战经验。这篇分享在 HackerNews 上引起了广泛讨论——不因为 Agent 完美无缺恰恰相反因为它诚实展示了 Agent 重构的「能」与「不能」。作为开发者你可能已经在用 Cursor、Copilot 辅助编程。但当任务从「写一个函数」升级到「重构整个服务架构」时Agent 的真实表现如何让我们从 1Password 的实战中寻找答案。背景1Password 的 Go 单体 B51Password 的核心后端是一个名为 B5 的 Go 单体应用已运行多年在生产环境中的可靠性和扩展性表现良好。但随着功能和团队的增长他们需要更清晰的服务边界更独立的部署单元更灵活的团队 ownership简单说需要把单体拆成微服务。这就是典型的 Monolith Decomposition单体分解问题。Agent 的强项分析、规划与确定性工具依赖分析与排序单体分解的第一个难题是从哪开始拆在涉及敏感数据密码管理器的系统中提取顺序是一个正确性约束。顺序不对可能引入数据泄露或一致性问题。1Password 团队构建了一个 Agent 工具链结合了多个数据源# 简化的 Agent 工具链架构importsqlite3,jsonfromdatadog_api_clientimportApiClientfromtypingimportDict,ListclassMonolithAnalyzer:单体应用分析 Agentdef__init__(self,code_path:str,db_path:str):self.code_pathcode_path self.db_pathdb_pathdefanalyze_dependencies(self)-Dict[str,List[str]]:1. SSA 分析代码结构 2. SQL 解析数据依赖 3. DataDog MCP运行时耦合度 return{domain_ownership:self._ssa_analysis(),data_dependencies:self._sql_dependency_analysis(),runtime_coupling:self._runtime_coupling_analysis()}def_ssa_analysis(self)-Dict:静态单赋值分析 - 理解代码结构# Agent 帮助编写了 SSA 分析工具的部分代码passdef_sql_dependency_analysis(self)-Dict:解析 SQL 查询识别数据依赖passdef_runtime_coupling_analysis(self)-Dict:通过 APM 数据理解运行时调用关系pass这个分析产出了一张领域所有权地图、一张耦合图和一张依赖图。结果与资深工程师的手工分析基本一致——建议从Vault有自己的 API、数据集和安全边界开始拆分。确定性工具模式1Password 发现了一个关键模式用 Agent 构建确定性工具而不是依赖 Agent 持续解释。# 示例Agent 辅助生成的确定性重构工具defgenerate_refactoring_manifest(codebase_path:str)-list: 通过 SSA 分析生成每个调用点的确定性清单。 Agent 编写了这个工具但工具本身是确定性的。 manifest[]# SSA 分析所有调用点forcall_siteinanalyze_all_call_sites(codebase_path):manifest.append({file:call_site.file,line:call_site.line,pattern:classify_pattern(call_site),suggested_action:generate_template(call_site)})returnmanifest核心洞察是让 Agent 生成确定性工件然后强制通过这些约束执行。这大幅减少了 Agent 的非确定性风险。Agent 的弱项复杂序列与推测行为痛点 1顺序约束错误当任务复杂度上升时Agent 开始犯错例如Agent 会在更新插入新行的代码之前尝试回填 UUID 列。这个顺序会引入静默数据丢失即使底层系统是容错的。原因是Agent 缺乏对系统级约束的理解。它在局部「看起来合理」的决策在全局可能是灾难性的。痛点 2推测行为Speculation1Password 团队观察到一种反复出现的模式——推测当 Agent 缺乏足够的上下文时它会用假设填补空白。这些假设在局部看似合理但在全局层面是错误的。这不是 Agent 的「bug」——这是语言模型非确定性的固有特征。解决方案也很明确让规格说明比 Agent 更精确Make the specification tighter than the agent。痛点 3生产力增益有限在复杂任务上Agent 的生产力提升大约是20-30%。# 实际生产力对比productivity{well_specified_tasks:{improvement:50-80%,agent_role:高效执行者},complex_sequences:{improvement:20-30%,agent_role:辅助工具},novel_architecture:{improvement:10%,agent_role:无法替代人类}}Agent 很有帮助但不能替代资深工程师的领域判断。实战建议如何正确使用 Agent 重构建议 1问题边界先行Agent 在问题完全指定且边界清晰时表现最佳。开始重构前先把规格写清楚# 好Agent 能高效执行的明确规格task_spec 将 UserService 中的 SendWelcomeEmail 方法提取到独立的 NotificationService。 - 输入UserID (int) - 输出bool - 依赖EmailTemplateRepo, MailClient - 约束保持现有错误处理逻辑不变 - 测试现有单元测试必须全部通过 建议 2非确定性必须严格约束classAgentGuard:Agent 执行防护层defverify_sequence(self,actions:list)-list:验证操作序列是否违反约束violations[]fori,actioninenumerate(actions):ifself._has_order_violation(action,actions[:i]):violations.append(action)returnviolationsdef_has_order_violation(self,action,preceding)-bool:检查是否违反顺序约束# 例如先回填数据再修改代码pass建议 3多 Agent 并行考虑冲突同时运行多个 Agent 可能很有效但仅在变更相互独立且冲突被结构性消除时。否则可能增加不一致性。建议 4覆盖率的正确理解目标不是让 Agent 处理所有情况而是让它在理解充分的模式上自信执行遇到超出规格的情况时优雅地交给人类。2026 年 AI Agent 重构的现状从工具链角度看目前 Agent 重构的能力光谱任务类型Agent 表现人类参与度代码分析/依赖映射✅ 优秀低模式化代码生成✅ 良好中简单的服务提取⚠️ 可辅助中高复杂架构变更❌ 不可靠高安全敏感重构❌ 需人工审核非常高总结1Password 的实战经验告诉我们AI Agent 重构的真相是分析阶段Agent 非常出色——阅读代码、分析结构、确定依赖执行阶段Agent 有用但有限——在边界清晰的任务上效率提升显著关键发现用 Agent 构建确定性工具比依赖 Agent 直接执行更可靠生产力简单任务 50-80% 提升复杂任务 20-30%全新架构 10%最大风险Agent 的推测行为可能导致静默错误必须有防护机制AI Agent 不会替代工程师的判断力但它可以成为工程师手中更强大的工具。关键在于理解它的边界用对地方。对于正在探索 AI Agent 重构团队不妨从分析阶段的依赖映射和模式化代码生成开始逐步建立信任再扩展到更复杂的执行任务。你可以在 zidongai.com.cn 查看更多 AI 自动化实战案例。