DoorDash 清理过期开关：50 个里 45 个可用，一次 4.79 美元
DoorDash 用一套多智能体系统清理代码库里过期的功能开关。在 50 个开关的评估中，系统为 45 个生成了可用的合并请求：31 个首次提交即被合并，14 个需要修改，另有 5 个要工程师介入。平均每次 13.8 分钟、4.79 美元，人工估计要 1 到 2 小时。动代码之前必须有工程师确认目标值，合并请求只有通过构建、测试、覆盖率和静态分析之后才会创建。
编辑标为信号级，适合持续跟踪。
本页目录11 节
记录
信号正文
#问题有多大
DoorDash 的实验平台在约 623 个代码仓库里管着 6 万多个功能开关，每月新增约 2,300 个，其中 1,000 多个已经过期。过期的定义是：90 天内没有修改记录，仍被代码引用，没有归档或退役，也没有被明确排除。系统每天为识别出的开关创建工单。
清理并不简单。DoorDash 用依赖注入式的包装，开关的定义、调用和业务逻辑可能散在多个文件里，一个布尔型开关也可能要改 5 到 20 个文件，包括测试。
为什么不用现成的工具
Uber 开源的 Piranha 基于抽象语法树做转换，是按规则来的。DoorDash 发现它覆盖不了自己的依赖注入写法：开关与业务逻辑之间的关联是语义上的，不是匹配语法结构就能识别的。
两个阶段
第一阶段，只读。一个编排智能体从工单系统取过期开关，搜索相关仓库，并通过 MCP 查询实验平台，拿到发布比例和目标值。它生成报告，由工程师审核并确认目标值之后，系统才开始改代码。
第二阶段，修改。清理智能体在相互隔离的 Git 工作树里运行，每个仓库最多同时 4 个。它定位开关的所有引用，确定清理策略，修改源码和测试，然后执行构建、测试、补丁覆盖率检查和静态分析。全部通过才创建合并请求。每个智能体的超时是 1 小时；构建工具以禁用守护进程的方式运行，防止不同工作树之间共享状态。
两个阶段用的模型不同：编排用 Claude Sonnet，清理用 Claude Opus。工作流建在 Google 的智能体开发套件上。
结果
- 50 个开关中 45 个生成了可用的合并请求
- 31 个首次提交即合并，14 个需要修改，5 个需要工程师介入
- 一次性成功率：简单开关 100%，中等复杂度 94%，复杂 85%
- 平均每次 13.8 分钟，4.79 美元
- 5 次人工介入都涉及较深的调用链和跨接口的参数传递
- 50 项变更中没有发现缺陷或回归
读的时候要带着的限定
评估的样本是 50 个，而待清理的过期开关有 1,000 多个；报道没有说明这 50 个是怎样选出来的。「没有发现缺陷」是 DoorDash 自己的说法。DoorDash 接下来打算为低风险任务加置信度评分，并在清理后增加一轮代码质量检查，比如移除开关之后变量名是否变得有误导性。
这项工作已被 ICSME 2026 的工业界专题收录。本条依据 InfoQ 的报道写成，没有读到 DoorDash 的原文。
为什么是现在
为什么重要
#这是一个边界划得很清楚的智能体用例：任务定义明确、有现成的验收检查、每一步都可以回滚。它给出了每次任务的时间和花费，让别的团队可以拿自己的人工成本去对照。
背景
技术背景
#功能开关让一段代码可以在不重新部署的情况下打开或关闭，常用于灰度发布。功能全量上线之后开关就没用了，但相关代码往往留在原处，成为没人敢动的负担。Git 工作树让同一个仓库同时检出多份互不干扰的副本。
关注人群
谁该关注
#下一步
学习路径
#- 先读《AI 试点范围界定》：什么样的任务适合作为第一批
- 读《完成判定与验收信号》：这里的验收是四道自动检查
- 读本站那条 180 万美元的智能体账单：每次任务的成本为什么必须可见
- 在你的代码库里找一类定义清楚、可自动验收的重复修改，估算人工成本
关系网络
在技术网络中的位置
#当前技术与相邻技术、技能和背景知识的连接，点击节点可继续探索。
延伸思考
后续问题
#- 你的代码库里，哪一类重复修改有现成的自动验收？
- 人工确认应该放在智能体动手之前，还是之后？
- 一次任务 4.79 美元，和你们的人工成本相比如何？
发布记录
收录于
#收录这条信号的技术简报，新的在前；最后一行是它那一周的周回顾。标签是它在那一期所在的栏目。
来源参考