Uber 如何让 AI 安全地删代码：AutoClean 清理 1.6 万个过期 Flag、百万行代码的 Agent 工程实践
@UberEng 团队用 AutoClean 系统自动清理已全量上线的过期 feature flag，累计清理了 1.6 万多个 flag、超过 100 万行代码。核心思路是：确定性的事交给工具，需要判断的事交给 Agent，正确性交给 CI 加多层验证，最后的业务决策留给人。
https://www.uber.com/us/en/blog/ai-code-cleanup/
面对的问题：删代码比写代码难
Flag 全量上线后，残留的条件分支、参数、配置和测试就成了技术债。它不仅拖累工程师，也让 AI Agent 读更多死代码，会话更长、成本更高。清理看起来是"搜索加删除"，其实是一条传播链：把 flag 内联成 true 只是第一步，接下来要判断函数参数能不能删（要查所有调用方）、旧分支是否已经不可达、配置字段还有没有别处依赖、测试该删还是该改写。Uber 团队的判断是：静态工具擅长确定性改写，AI 的价值在这些传播决策上。
三阶段架构
1. 改写：Agent 有文件搜索和编辑能力，布尔代数和条件化简则通过 MCP 调用 Uber 自己的确定性引擎 PolyglotPiranha 来做，因为条件化简一旦出错就会悄悄改变线上走哪个分支。Agent 循环执行，直到没有可清理的为止。
2. 修 CI：以 monorepo 的全量 CI 为准，而不是只看本地测试。失败先交给便宜的确定性修复器（未使用的默认值、lint），处理不了的再交给 Agent 修复器（比如测试该删还是改写），反复推送直到变绿或者用完重试次数。关键约束是权限收窄：测试修复器只能改测试文件，否则 Agent 会去改生产代码来让测试通过。
3. 验证：CI 绿了也不等于正确。Agent 可能删掉本该保留的测试，也可能停得太早没清理干净。所以先跑静态检查，再交给 Agent 验证层 CodeCourt。
CodeCourt：最值得借鉴的设计
把观察到的 Agent 失败模式写成明确的正确性属性，每条属性由一个专门的审查 Agent 并行检查：只删不增、行为语义不变、不偏离目标（不顺手删其他 flag）、不留 Agent 痕迹（比如推理注释）。全部通过才进入人工审查，任意一条失败就直接放弃这个 diff。团队早期试过用单个 Agent 端到端审查，效果不如拆成多个聚焦的审查者。
背后的原因是：指令一多，长任务 Agent 就容易遗漏约束，倾向于只追求"CI 通过"这种最直接的信号。所以把约束从执行循环中剥离出来，放到验收端去检查。