用多智能体 LLM 系统自动化大规模 Feature Flag 清理：DoorDash 的工业应用案例

问题

Feature Flag 用于功能的渐进式发布或实验，但发布完成后会变成技术债，还存在休眠代码被重新启用的风险。DoorDash 在 623 个代码仓库中有超过 5.6 万个 Flag（内部称为 DV），截至 2026 年 5 月有 1,659 个处于过时状态。手动清理每个需要 1～2 小时（内部估计）。Piranha 等基于 AST 的规则工具由于依赖注入包装器模式、非布尔型 Flag 以及跨多个文件的修改，无法应用于这一环境。

方法

这是用 Google ADK 构建的两阶段多智能体系统。在第一阶段，基于 Claude Sonnet 4.6 的 Orchestrator 读取 Jira 工单，通过 MCP 从实验平台查询实际生产环境的发布状态（发布比例、最终值），查找代码引用并生成清理报告。工程师确认目标值后，在第二阶段，基于 Claude Opus 4.6 的移除智能体为每个 Flag 在隔离的 git worktree 中并行工作（每个仓库最多 4 个）。移除智能体依次完成常量、包装器和调用处的删除，条件语句简化，测试修改，构建与测试通过，补丁覆盖率达到 95% 以上以及 Detekt lint 检查，然后创建 PR。每个智能体还设有 1 小时超时。

结果

• 在最近 50 个 Flag 清理中，31 个（62%）首次尝试即被原样批准，14 个（28%）经小幅修改后获批，5 个（10%）需要工程师介入。整体清理成功率为 90%。
• CI 首次通过率为 88%（44/50）。6 次失败均由补丁覆盖率不足导致，而非错误的代码变更。
• 按复杂度划分的成功率为：简单 100%（6/6），中等 94%（17/18），复杂 85%（22/26）。作者分析认为，失败原因不是 Flag 类型或文件数量，而是跨越多个接口的深层调用链。
• 每个平均 13.8 分钟（中位数 12.3 分钟），LLM API 成本平均 4.79 美元（中位数 3.49 美元）。明显短于内部估计的手动工作时间（1～2 小时）。
• 作者报告称，在生成的全部 50 个 PR 中均未观察到 bug 或回归。他们的解读是，局限在于完整性（遗漏部分死代码），而不在于正确性。

局限

仅在一家公司的 Kotlin 代码仓库、特定 DV 访问模式（依赖注入包装器）上评估了 50 个案例。每个 Flag 只运行一次，未能考察 LLM 非确定性的影响。复杂度分类由作者事后确定，手动清理 1～2 小时是内部估计而非实测。开发者反馈是非正式收集的。没有在同一数据上与 Piranha 等基线进行直接对比的实验。推广到其他语言或 Flag 框架需要进一步验证。

意义

这是将编码智能体投入实际生产代码库中重复性清理工作的案例，以数字公开了成功率、成本、时间和失败原因。作者提出了实践中的前提条件：查询实际发布状态的数据源、用于并行工作的 worktree 隔离，以及创建 PR 之前的确定性验证关卡。对考虑类似自动化的团队具有直接参考价值。

关键术语

Feature Flag

一种无需重新部署代码、通过运行时配置开启或关闭功能的机制。用于渐进式发布、A/B 测试和紧急关停。

MCP(Model Context Protocol)

让 LLM 智能体以标准方式调用外部工具和数据源的协议。在该系统中用于查询实验平台的实际发布状态。

git worktree

允许在一个仓库中同时使用多个工作目录的 git 功能。用于隔离并行智能体，防止它们互相覆盖文件。

补丁覆盖率（Patch Coverage）

本次变更所修改的代码行中被测试执行的比例。该系统将 95% 以上作为创建 PR 的条件。

原文

• arXiv 摘要页
• PDF
• HTML 全文
• Hugging Face

作者: Atharv Chandratre, Jai Datar · 发布 2026-10-22 · 许可 arXiv 비독점 배포 라이선스 · 基于全文分析

本解读是 AI 阅读论文后撰写的摘要，请以论文原文为准。