DoorDash 如何用多 Agent 系统清理 6 万个 Feature Flag

导语

Feature Flag 能帮助团队控制发布节奏、开展实验，但长期遗留的开关也会逐渐变成代码债务。DoorDash 在大规模实验平台上尝试引入多 Agent LLM 系统，自动识别并清理不再活跃的 Flag，把原本需要人工追踪、修改和验证的工作串成一条流水线。

核心要点

• DoorDash 的实验平台覆盖约 623 个代码仓库，管理超过 6 万个 Feature Flag，每月新增约 2,300 个。
• 当 Flag 连续 90 天没有修改记录、仍被代码引用，且没有归档、退役或明确排除时，系统会将其标记为过期，并每天创建 Jira 工单。
• 清理流程分为编排和执行两个阶段：前者获取仓库及实验数据，后者负责定位引用、修改代码并完成验证。
• 在 50 个过期 Flag 的评估中，系统生成了 45 个可用 Pull Request，平均每次耗时 13.8 分钟，成本为 4.79 美元。

为什么清理并不简单

DoorDash 使用依赖注入式 Wrapper 管理 Flag。一个开关的定义、客户端调用和业务逻辑可能分散在多个文件中，连同测试代码在内，一次清理可能需要修改 5 至 20 个文件。仅依靠语法匹配，很难判断一个 Flag 在业务调用链中的真实关系。

这也是基于 AST 的工具面临的限制。Uber 开源的 Piranha 可以按照规则识别并移除部分过期 Flag，但 DoorDash 发现，其依赖注入模式涉及语义层面的关联，无法完全通过语法结构覆盖。LLM Agent 的价值在于，它可以在代码搜索、上下文理解和修改策略之间进行组合，而不是只执行预先写好的转换规则。

两阶段 Agent 工作流

第一阶段由 Claude Sonnet 驱动的编排 Agent 从 Jira 获取任务，搜索相关仓库，并通过 MCP 查询实验平台，读取发布比例和目标值等元数据。工程师需要先审核报告并确认目标值，系统才会进入代码修改阶段。这个人工确认点避免了 Agent 在实验状态不明确时直接删除逻辑。

第二阶段由 Claude Opus 驱动的清理 Agent 执行修改。每个任务在隔离的 Git Worktree 中运行，同一仓库最多并发四个 Agent。Agent 会定位全部引用，选择清理方案，修改源代码和测试，并运行构建、测试、JaCoCo 补丁覆盖率检查及 Detekt 静态分析。只有通过这些检查，系统才创建 Pull Request；单个 Agent 的超时时间为一小时，Gradle 则关闭 Daemon，以减少不同 Worktree 之间的状态干扰。

效果与边界

评估中，31 个 Pull Request 首次提交后即合并，14 个需要修改，另有 5 个任务需要工程师介入。简单 Flag 的一次性清理成功率为 100%，中等复杂度为 94%，复杂 Flag 为 85%。需要人工介入的任务都涉及较深调用链或跨接口参数传递。DoorDash 表示，50 项代码变更中没有发现 Bug 或回归问题。

这项实践说明，Agent 自动化的重点不只是“让模型改代码”，而是把数据查询、审批、隔离执行和多层验证组合起来。它也显示出明显边界：越接近隐含业务语义、跨接口传播的代码，越难完全自动化。DoorDash 后续计划为低风险任务增加置信度评分，并在清理后加入代码质量检查，以发现移除 Flag 后遗留的误导性变量名等问题。

对其他工程团队而言，Feature Flag 清理是一个相对适合 Agent 化的场景：任务目标明确、结果可通过测试验证，同时又足以暴露纯规则工具在复杂代码结构中的不足。真正可复制的经验，可能不是某个模型名称，而是“机器执行、人工确认、隔离变更、自动验收”的工程闭环。

来源：InfoQ 中文