一句话看懂：DoorDash 用一套多 Agent 大模型系统自动清理代码库里的过期 Feature Flag，50 个过期 Flag 中有 45 个生成了可用 PR，单次清理平均 13.8 分钟、成本 4.79 美元，而人工通常要 1 到 2 小时。
事件核心：发生了什么
DoorDash 的实验平台在约 623 个代码仓库中管理着 6 万多个 Feature Flag，每月新增约 2,300 个，其中 1,000 多个被判定为过期——90 天内无修改记录、仍被代码引用、未归档退役。清理难点在于其依赖注入式 Wrapper 让 Flag 定义、客户端调用和业务逻辑分散在多个文件，一个布尔型 Flag 往往要改 5 到 20 个文件。Uber 开源的 Piranha 依赖抽象语法树做规则转换，无法覆盖这种语义层面的关联，DoorDash 因此转向基于 LLM 的多 Agent 方案。
系统基于谷歌 Agent Development Kit，分两阶段：先由 Claude Sonnet 驱动的编排 Agent 从 Jira 取工单、搜索仓库，并通过 Model Context Protocol 查询实验平台元数据，经工程师确认目标值后再改代码；随后由 Claude Opus 驱动的清理 Agent 在隔离的 Git Worktree 中运行，每个仓库最多 4 个 Agent 并行，执行修改、构建、测试、JaCoCo 补丁覆盖率检查和 Detekt 静态分析，全部通过才创建 PR。评估中 31 个 PR 首次提交即合并，14 个需修改，5 个需人工介入；简单 Flag 一次性成功率 100%，中等 94%，复杂 85%，未发现 Bug 或回归。
为什么重要
这提供了一个少见的“可核查账本”：把 LLM Agent 放进有明确验证闭环的工程流程，而不是停留在写代码演示。成本 4.79 美元对 1 到 2 小时人工，说明在边界清晰、验证标准客观的软件维护场景里，多 Agent 加 MCP 这类标准化工具接口已具备经济性。它也划出了规则方法与 LLM 方法的分界——AST 擅长语法结构，语义关联仍要靠模型推理，两者更可能是互补而非替代。
对用户/开发者/创作者的影响
对研发团队，可复用的思路是“先审核、再动代码、后验证”的护栏设计：隔离 Worktree 避免状态污染、禁用 Gradle Daemon、设置超时，以及只有全部门禁通过才允许提 PR。对平台和工具链开发者，MCP 作为连接外部系统与 AI 应用的标准化接口值得提前适配，因为这类内部平台的元数据接入会越来越频繁。目前公开信息显示，该工作已被 ICSME 2026 Industry Track 收录，但 DoorDash 尚未说明是否会开源或对外提供产品化版本。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是计划中的置信度评分和清理后代码质量检查能否降低那 5 次人工介入所暴露的深层调用链问题；二是简单到复杂 Flag 成功率从 100% 降到 85% 的曲线，在多仓库、多语言环境下会如何变化；三是 Uber Piranha 等规则方案与 Agent 方案是否会出现融合路线，以及其他大厂是否跟进披露类似内部系统的投入产出数据。
来源：InfoQ CN
