功能开关让上线更灵活，也会留下长期成本：实验结束后，条件分支、测试和配置可能继续存在。DoorDash 面对超过 60,000 个功能开关、623 个代码仓库，构建了一套多智能体 LLM 系统来自动化清理过期开关。值得关注的不只是模型改代码，而是实时实验数据、工程师审批、隔离工作区和自动验证如何配合。
删除开关之前，先确认它真的可以退役
看到某个开关很久没有修改，并不等于可以删除它。清理需要回答两个不同的问题：这个开关是否已经结束使命，以及代码应该保留哪条路径。
来源摘要指出，DoorDash 的流程通过 MCP 接入实时实验数据，并包含工程师审批。两者分别提供运行状态依据和人工决策关口。摘要没有披露具体审批顺序或数据字段，因此不能把某一种实现当成它的实际架构。
在自己的系统中，可以这样实践：让智能体先提交退役依据，列出实验状态、预期保留分支、代码引用和待确认事项，再由负责人批准修改。对数据不完整、仍承担回滚职责或存在特殊用户配置的开关，应暂停自动清理。
代码里的默认值不是生产环境的事实。 即使模型准确理解了条件表达式，也可能选错应该保留的业务行为。
多智能体的价值，在于受控并行
DoorDash 的工作流结合了并行智能体和隔离的 Git worktree。工程上的意义很直接：多个任务可以同时修改代码，而不必共享同一个工作目录。
但 worktree 只隔离工作树，并不自动解决语义冲突。两个开关可能影响同一个函数；两份 PR 分别通过测试，合并后仍可能出现行为变化。共享数据库、测试端口和外部服务也不会因为 worktree 不同就自然隔离。
可以将任务拆成“确认退役条件、修改代码、验证差异”三个职责，但这是可采用的设计，不是摘要披露的 DoorDash 智能体分工。每个任务都应携带明确的开关标识、目标仓库、保留行为和审批记录，避免智能体自行扩张修改范围。
可以这样实践：给每次清理建立独立工作区
下面是一个最小本地示例，不是 DoorDash 的内部实现。假设当前目录是 Git 仓库，并已确认开关可以退役。运行前修改 FLAG 和 BASE；分支名及目标目录必须尚不存在。脚本只创建工作区，不会删除代码或提交 PR。
#!/usr/bin/env bash
set -euo pipefail
FLAG="checkout_old_flow"
BASE="HEAD"
ROOT="$(git rev-parse --show-toplevel)"
BRANCH="cleanup/${FLAG}"
WORKTREE="$(dirname "$ROOT")/$(basename "$ROOT")-${FLAG}"
git -C "$ROOT" worktree add -b "$BRANCH" "$WORKTREE" "$BASE"
printf 'Workspace: %s\n' "$WORKTREE"
git -C "$WORKTREE" grep -n -F "$FLAG" -- . || {
status=$?
if [ "$status" -ne 1 ]; then
exit "$status"
fi
}
进入输出的工作区后，可以给编码智能体提供下面的任务约束。替换占位内容，并附上经过批准的实验状态证据：
目标开关：<flag_id>
审批记录：<approval_reference>
已确认保留的行为：<approved_behavior>
只修改与该开关退役直接相关的代码、测试和配置。
不要根据默认值推断线上行为。
遇到动态引用、状态证据冲突或不明确的分支语义时，停止并报告。
完成后列出修改文件、验证命令、验证结果和未解决风险。
不得自行合并或部署。
修改后，在该工作区运行 git diff --check、git diff --stat 和仓库规定的测试命令。前者只能发现部分差异格式问题，不能证明业务正确。自动验证还应检查相关分支测试、类型检查和残留引用；字符串搜索也不能覆盖所有动态构造的开关名。
如何理解 45/50 的结果
在 50 个开关的评估中，45 个产出了可用 PR，对应 90%；每次清理平均耗时 13.8 分钟、成本 4.79 美元。
这些数字说明该评估中的流程能够较快地产出可供使用的代码变更，但不能直接解读为“90% 的开关可以无人值守删除”。可用 PR 不等于已经合并，也不等于部署后没有问题。摘要没有说明其余 5 个案例的失败原因，也没有明确成本是否包含人工审查等全部投入。更不能据此认定全部 60,000 多个开关都已完成清理。
落地时，先选择实验已结束、保留行为明确、测试覆盖较好的开关试点。除 PR 产出率外，还应记录审查耗时、合并率、回滚率和人工修正量。真正值得扩大的是经过验证的退役流程：用实时数据确定行为，用审批明确责任，用隔离支持并行，再用测试和审查约束修改。