让开关自我消亡：AI 赋能的 Feature Flag 全生命周期治理

随着微服务与敏捷迭代的深化，功能开关已成为现代软件交付不可或缺的风险控制手段。但在快手这样业务高度复杂、迭代极其迅猛的超大规模系统中，大量长期存活的开关正在演变为一种沉重的隐性技术债。本文整理自快手资深服务端架构师闫文亮在 QCon 全球软件开发大会 2026 北京站的分享《让开关自我消亡：AI 赋能的 Feature Flag 全生命周期治理》。他在分享中对 AI 赋能开关全生命周期治理的完整实践进行了复盘，内容涵盖从治理困局、AI Agent 的工程落地，到双引擎安全护栏、自进化机制，以及 AI Native 治理范式的演进全过程。 以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。 Feature Flag价值与隐形技术债：从业务刚需到技术债陷阱 快手 APP 在启动时会调用后端服务器的一个接口。有一次，这个接口因升级新功能返回了一个客户端不兼容的字段，造成 APP 崩溃。后端同学发现后立刻对代码进行了回滚，但由于崩溃发生在启动阶段的极早期，客户端此时还没有拉到修正后的代码，于是再次崩溃。启动即崩溃，再启动再崩溃，由此陷入无限循环。当时客户端的“安全气垫”和“安全模式”还远未完善，最终只能引导用户卸载重装。可以想象，如果你是这个需求的后端研发，心情会是怎样的——极度匆忙，连滚带爬。彼时大家必然在反复追问一个命题：怎样能让发布新功能更加自信，从从容容、游刃有余？ 这个问题的一个标准答案，就是 Feature Flag，即功能开关。它本质上是一种使功能发布与代码部署解耦的软件技术。理论上，如果当时拥有完善的开关能力，新功能可以被优先开放给内部用户，待监控确认无误后再逐步对外放量，这场大规模故障就很可能不会发生。 更进一步，Feature Flag 可以将代码发布和功能发布完全解耦。设想一个场景：ABC 三个需求一起上线，如果 B 出了问题，没有开关就只能把三个需求整体回滚，导致 A 和 C 被迫延期；而有了开关，仅需关闭 B 功能即可，A 与 C 不受任何影响。正因如此，在如今 AI Coding 时代，大家已经不自己写代码了，全都是 AI 生成代码，在发布 AI 代码时心里可能更加没底，就愈发需要 Feature Flag 来帮助建立发布自信。 然而，也正因为开关太好用，快手的生产代码中存在着数量极为庞大的 Feature Flag。毫不夸张地讲，代码几步之内就能发现一个开关。以快手搜索业务的一段代码为例，其中不仅包含着搜索自身的开关，还夹杂着本地生活的开关、电商的开关等等。原因是快手的业务链路极为复杂，搜索某个内容时可能会下发本地生活 Feed 或电商商品，各类开关因此越积越多，职责划分也逐渐模糊。 大量堆积的开关带来了四个维度的切肤之痛。首先是代码维护成本飙升：新人接手项目时，必须在一堆开关里仔细梳理逻辑，判断哪段代码有效、哪段已经废弃。在 AI Coding 时代，由于代码并非自己亲手所写，每个人在梳理开关和业务时都像新人一样，成本同样高昂。尤其当 AI 去阅读代码时，它需要去查询各个开关系统的返回值以确定走什么逻辑分支，这又进一步拉高了成本。第二是浪费计算资源：每一次调用、每一次逻辑判断，都意味着要判断开关到底走哪个分支，日积月累也是不小的损耗。我们查得快手短视频主业务（不包括上下游），每秒调用的开关次数就达 155 亿次。第三是浪费带宽资源：客户端同样需要使用开关进行功能发布，开关值需要后端服务下发，导致单个接口下发的开关数量极多，带宽成本惊人。快手每年仅因开关下发而产生的带宽成本就有 几百万。第四是隐藏稳定性风险。过期开关会偶发性地拉不到已推全的值，导致走到旧逻辑，触发线上问题。真实的案例是，一个早几年就已经推全的开关，旧逻辑始终没有下线，开关被遗忘，旧逻辑也无人维护。某一天某个小 Bug 导致开关没有拉到值，异常立刻被触发，业务团队连夜排查了非常久才定位到根因。可以说，哪怕已经推全的开关，如果不加治理，就可能成为一颗随时引爆的定时炸弹。 既然危害如此明确，业务团队为什么仍然缺乏治理的动力？首先，加开关极其容易，一分钟写一个 if 语句就能解决极大问题——消除发布风险、赋予发布自信、实现部署与发布解耦。但删除一个开关，则需要梳理上下游业务、评估下线风险、修改代码、发布、测试，短则一个小时，长则更长。其次，心态上，加开关是顺手的事，而删开关毫无收益且要承担风险，业务同学自然不愿意主动去做。再次，组织上，离职人员交接时往往会留下“后人的智慧”：我创建的开关我不删，留给后人治理；后人一看，也不知道这个开关是干什么的，下线肯定有风险，干脆放着不动。再加上跨部门合作的开关职责不清，所有人都不敢动。债务越积越多，谁也不愿删除，形成了一个死循环。从快手某个部门的开关增长数据来看，基本上每年都有大几千的增长量。 尤其值得警惕的是，麻省理工学院的一位教授曾预言：“人工智能就像一张全新的信用卡，让我们以前所未有的方式来积累技术债。”人写代码速度有限，债务还有时间修复；如果未来代码都由 AI 来写，技术债将呈爆发式增长。如果当下不开始治理，后续的时间窗口可能都会错过。过去我们也尝试过多种传统治理手段，例如做平台规范治理，给开关设定下线时间，搭建审计看板，但这依赖于业务的自觉性，执行力度参差不齐；也可能写一些自动化脚本去删除开关，效率尚可，但一遇到代码开关嵌套或业务逻辑复杂的场景，基本就会改错；再熟悉不过的是搞专项治理行动，拉一群人大规模同步进度、强推治理，这种运动式治理确实立竿见影，但往往是一阵风过后不久就反弹，反弹之后再拉一群人再治理，治理完再反弹，形成一个“治而不绝”的治理死循环。治理速度远远跟不上开关新增速度。 直到 AI 的出现，才真正让我们看到了打破这一死循环的可能。2024 年下半年，我们判断，用 AI 治理开关的内外部条件已经成熟。外部，大模型迭代极快，API 成本持续下降，模型在代码理解与修改上的能力已经可靠；内部，我们对高效、安全且尽可能无需人工介入的治理方式有着迫切需求，加之公司 AI 基础设施持续投入，我们认为时机刚刚好。快手跨入了 AI 治理的新时代。 治理Agent的演进与工程落地：从Demo到工程落地 回顾快手开关治理的整体历程：2025 年之前，主要采用运动式治理，拉人推业务，效果差、效率低；2025 年上半年，我们推出了 AI 开关治理 Agent，帮助业务提效，极大减少人工介入；从 2026 年至今，我们正在构建 AI Native 开关治理，其核心思想已不再是人全程治理开关，而是“让开关自己下线”。AI Native 强调的是，搭建一套让 AI 觉得治理效率高的整体环境，而不是让人感觉治理效率高的方式。 把时间拉回 2025 年上半年，当时我正在使用 Cursor 开发一个需求，与 Cursor 来回拉扯调试，反复沟通它都搞不明白的时候，系统弹出了一条消息，告知我名下有多少个开关需要治理。我随手就把这个需求丢给了 Cursor，说“开关 A 已经百分百推全了，帮我把无用代码和开关下线掉”。Cursor 很快就完成修改，而且格式和代码逻辑非常正确。这个体验让我们当即意识到：既然 AI 能搞定单个开关的治理，那能否规模化？不可能让每个人都装一个 Cur