DoorDash以多智能体清理6万余个Feature Flag

DoorDash搭建了一套多智能体LLM系统，用于自动发现并移除代码库中不再活跃的Feature Flag。系统结合实验平台实时数据、工程师审批、隔离式Git Worktree和自动化验证。在50个过期Flag的评估中，有45个生成了可用的Pull Request，单次清理平均耗时13.8分钟、成本4.79美元；人工完成同类工作通常需要1至2小时。

目前，DoorDash的实验平台覆盖约623个代码仓库，管理着超过6万个Feature Flag，并且每月新增约2300个。若某个Flag连续90天没有修改记录、仍被代码引用、未归档或退役，且没有被明确排除，系统就会将其判定为过期Flag。系统每天根据识别结果创建Jira工单，推动后续治理流程。

由于采用依赖注入式Wrapper，清理工作并不只是删除一处条件判断。Flag定义、客户端调用和业务逻辑往往分布于多个文件，一个简单的布尔Flag也可能涉及5至20个源代码及测试文件的修改。

现有的规则型工具无法完全适配这一架构。Uber开源的Piranha通过抽象语法树转换识别并删除过期Flag代码，但依赖注入下，Flag与业务逻辑的关联更多属于语义关系，难以仅靠语法结构匹配发现。DoorDash因此采用LLM方案，形成与AST规则工具不同的技术路径。

这套工作流基于谷歌Agent Development Kit，分为两个阶段。第一阶段由Claude Sonnet驱动的编排Agent从Jira读取工单，搜索相关仓库，并通过Model Context Protocol访问实验平台，获取发布比例、目标值等元数据。工程师先审核报告并确认目标值，系统随后才会执行代码修改；MCP则负责以标准化方式连接外部工具和资源。

第二阶段由Claude Opus驱动的清理Agent完成实际变更。Agent在相互隔离的Git Worktree中运行，每个仓库最多同时运行4个Agent，负责查找Flag的全部引用、制定清理方案、修改源代码和测试，并依次执行构建、测试、JaCoCo补丁覆盖率检查及Detekt静态分析。只有全部检查通过后才会创建Pull Request。单个Agent最长运行1小时，Gradle关闭Daemon，以避免不同Worktree共享状态。

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

DoorDash后续计划为低风险任务加入置信度评分，并在清理结束后增加代码质量检查，以发现删除Flag后可能留下的变量名误导等问题。该项目已被ICSME 2026 Industry Track收录。