DoorDash 多智能体LLM系统自动清理 6 万个功能开关

一句话结论

DoorDash 部署多智能体大模型系统自动清理过期功能开关，单次成本 4.79 美元，效率较人工提升 5 至 8 倍。

关键要点

• 该系统在 50 个过期开关测试中，为 45 个生成可用 Pull Request，单次平均耗时 13.8 分钟，成本 4.79 美元，人工需 1 至 2 小时
• 单次清理平均修改 5 到 20 个文件（含测试文件），每个仓库最多 4 个 Agent 并行，Agent 超时上限 1 小时
• 31 个 Pull Request 首次提交即合并，14 个需修改，5 个需工程师介入；简单、中等、复杂开关一次性成功率分别为 100%、94%、85%
• 当前约 6.23 万个开关分布于 623 个仓库，每月新增约 2,300 个，其中 1,000 多个被标记为过期
• 系统基于 Agent Development Kit 构建，Claude Sonnet 编排 Agent 与 Claude Opus 清理 Agent 协同运作

背景与事实

DoorDash 的实验平台在约 623 个代码仓库中管理 6 万多个功能开关，每月新增约 2,300 个。公司发现有 1,000 多个开关已过期。过期判定标准为：90 天内无修改记录、仍被代码引用、未归档或退役，且未被明确排除。系统每天为识别出的过期开关生成 Jira 工单，驱动清理流程。

DoorDash 采用依赖注入式 Wrapper，开关定义、客户端调用和业务逻辑分散在多个文件中。即使简单布尔型开关，单次清理平均修改 5 到 20 个文件，包括测试文件。现有方案 Uber 开源的 Piranha 基于抽象语法树（AST）转换，无法覆盖 DoorDash 依赖注入模式，因为开关与应用逻辑的关联属于语义层面，无法仅靠语法结构匹配识别。

该系统基于谷歌 Agent Development Kit，分两个阶段运作。第一阶段，Claude Sonnet 驱动的编排 Agent 从 Jira 获取工单，搜索相关代码仓库，通过 Model Context Protocol（MCP）查询实验平台，获取发布比例和目标值等元数据。工程师审核报告并确认目标值后，系统才进入第二阶段。第二阶段，Claude Opus 驱动的清理 Agent 在隔离的 Git Worktree 中运行，每个仓库最多 4 个 Agent 并行。Agent 定位所有引用，确定清理策略，修改源代码和测试，执行构建、测试、JaCoCo 补丁覆盖率检查和 Detekt 静态分析，全部通过后才创建 Pull Request。每个 Agent 超时 1 小时，Gradle 禁用 Daemon 模式，防止不同 Worktree 共享状态。

在 50 个过期开关评估中，31 个 Pull Request 首次提交即合并，14 个需修改，5 个需工程师介入。简单开关一次性成功率 100%，中等 94%，复杂 85%。5 次人工介入均涉及深层调用链和跨接口参数传递。50 项代码变更中未发现 Bug 或回归问题。单次平均耗时 13.8 分钟，成本 4.79 美元。

影响分析

对中文开发者与从业者而言，该方案揭示了大模型在大规模代码维护场景的工程化落地路径。影响判断：依赖注入等复杂架构模式下，基于 AST 的静态分析工具存在固有局限，需借助语义理解能力；多智能体架构配合隔离工作区和多重验证门槛，可将高风险自动化操作控制在可接受范围内。但 85% 复杂开关成功率意味着仍须保留人工兜底，尤其涉及跨接口参数传递时。该模式适合功能开关管理成熟、仓库数量大、过期清理负担重的中大型研发团队。

适用边界

该结论不适用于以下场景：代码库未建立统一实验平台或功能开关管理系统的团队；功能开关数量极少、人工清理成本可接受的项目；依赖单一静态分析即可覆盖清理需求的简单架构。评估数据基于 50 个过期开关的有限样本，6.23 万开关规模下的整体成功率与成本曲线尚未经完整验证；Agent 并发上限、超时设置和验证工具链的组合高度依赖 DoorDash 技术栈，直接移植需重新适配。

孤本观察

4.79 美元的单次成本与 13.8 分钟耗时表明，大模型清理工具的经济可行性已跨过临界点。判断：未来功能开关治理将从人工周期性清理转向持续自动维护，代码仓库中语义层面的架构模式将成为自动化工具设计的关键瓶颈。

来源：InfoQ 中文 AI