正在加载，请稍候
外卖平台用多智能体系统清理 6 万个过期开关：单次平均 13.8 分钟、4.79 美元，人工要 1-2 小时。本文把它翻译成软件定制开发项目能直接抄的配置债结算表、四条验收口径与两条反面教训。
一个企业级软件定制开发项目上线三年后，仓库里躺着一千多个开关。没人记得它们管什么，也没人敢删。这不是技术问题，是一笔没人结账的配置债。
InfoQ 在 2026 年 9 月 26 日的报道给出一组可对照的数字：某外卖平台的实验平台在约 623 个仓库里管理着 6 万多个功能开关，每月新增约 2300 个，其中 1000 多个已过期。
他们把过期定义成四条同时成立：90 天内无修改记录、仍被代码引用、尚未归档或退役、且不在排除名单。系统每天为命中的开关创建工单。
这套口径不依赖任何人的记忆，只依赖三条可查事实：最近一次评估时间、当前所有者、还有没有人引用。无主开关的判定也就清楚了——查不到最近评估时间戳、没有 owner、也没有对应工单的那一批。
人工清理一个开关要 1 到 2 小时，多智能体平均 13.8 分钟、4.79 美元。
脚本为什么不行：Uber 开源的 Piranha 走语法树转换，靠结构匹配删代码。定制项目里开关常被包在依赖注入式 Wrapper 中，定义、调用与业务逻辑散落在多个文件，一个布尔开关能牵动 5 到 20 个文件。这种关联在语义层，匹配语法结构识别不出来。
角色于是被切开：只读扫描找引用、影响面判定定策略与回归范围、变更执行改源码与测试、回滚守卫做验证与止损。这与站内把代码审查搬上产线的那套角色拆解是同一回事——崩了以后还能接着跑，靠的是产物，不是记忆。
两阶段交接物很具体。上游由编排型智能体从工单系统取任务、检索仓库，再通过 MCP 查实验平台的发布比例与目标值；工程师确认目标值后，下游才被允许改代码。下游在互相隔离的 Git Worktree 里运行，单仓库最多 4 个并发，跑通构建、测试、增量覆盖率与静态分析才提交合并请求。超时一小时，构建工具禁用守护进程，避免工作区共享状态。
把上面这套翻译成验收用的表，定制项目的负责人可以直接抄：
| 记账项 | 取数方式 | 为什么要留 |
|---|---|---|
| 评估次数 | 每次评估追加一行 | 区分无人问津与刚被复核 |
| 最近命中时间 | 运行时埋点回传 | 决定能否进入删除候选 |
| 依赖代码路径 | 扫描产物落库 | 预估回归范围 |
| 清掉后的回归范围 | 由路径反推用例集 | 写进变更单与回滚预案 |
评估 50 个开关时 45 个直接产出可用的合并请求：31 个首次提交即合入、14 个需再改。简单开关一次成功率 100%，中等 94%，复杂 85%——复杂那 5 个全是深调用链加跨接口传参。
第一条是顺序错。先批量删除再想回滚，等于把灰度开关当垃圾清掉：线上指标一变，你已经没有可以关回去的那根线。正确顺序是先判影响面、再单点删除、逐步扩大，回滚能力保留到变更收敛之后。
第二条是节奏打架。清理任务天然与版本发布抢同一个窗口，绑在同一次上线里，一次常规重构会被拖成两次上线。
另外，自动化不等于不用人。那 5 次需要人工介入的都是走得太深的调用链，把这类任务默认留给工程师更省事。
这套口径的价值不在省几分钟，而在把配置债从一句抱怨变成一张能按月结账的表——这正是定制项目交付后最容易失守的一段。它和「交付的是行为，不是页面数」是同一个立场：验收要对着行为，不是对着数量。
跨平台项目还要多处理一层适配差异，把平台差异关进适配层那份三层能力模型可以直接复用。手上若已有几百个没人认领的开关，可以先把仓库清单和发版节奏发来，按这张表跑一轮只读扫描再决定删哪些。查看蓝曜炬辉的定制开发项目案例。
参考口径是 90 天无修改记录，但要同时满足仍被引用、未归档或退役、不在排除名单。只看时间会把长期稳定的开关误判成垃圾。
灰度开关本身就是回滚手段。批量删掉后线上出问题只能发新版本回退，回滚从分钟级变成小时级。
单次约 13.8 分钟、4.79 美元，对比人工 1 到 2 小时。真正的变量是复杂开关的人工介入比例，评估样本里约占 10%。
该团队在评估的 50 项变更里未发现缺陷或回归，但仍计划补一轮清理后的代码质量检查，例如变量名与语义脱节。