作者 | 闫文亮，快手资深服务端架构师

审核｜Kitty

策划 | QCon 全球软件开发大会

随着微服务与敏捷迭代的深化，功能开关已成为现代软件交付不可或缺的风险控制手段。但在快手这样业务高度复杂、迭代极其迅猛的超大规模系统中，大量长期存活的开关正在演变为一种沉重的隐性技术债。

本文整理自快手资深服务端架构师闫文亮在 QCon 全球软件开发大会 2026 北京站的分享《让开关自我消亡：AI 赋能的 Feature Flag 全生命周期治理》。他在分享中对 AI 赋能开关全生命周期治理的完整实践进行了复盘，内容涵盖从治理困局、AI Agent 的工程落地，到双引擎安全护栏、自进化机制，以及 AI Native 治理范式的演进全过程。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

1Feature 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 治理的新时代。

2治理 Agent 的演进与工程落地：从 Demo 到工程落地

回顾快手开关治理的整体历程：2025 年之前，主要采用运动式治理，拉人推业务，效果差、效率低；2025 年上半年，我们推出了 AI 开关治理 Agent，帮助业务提效，极大减少人工介入；从 2026 年至今，我们正在构建 AI Native 开关治理，其核心思想已不再是人全程治理开关，而是“让开关自己下线”。AI Native 强调的是，搭建一套让 AI 觉得治理效率高的整体环境，而不是让人感觉治理效率高的方式。

把时间拉回 2025 年上半年，当时我正在使用 Cursor 开发一个需求，与 Cursor 来回拉扯调试，反复沟通它都搞不明白的时候，系统弹出了一条消息，告知我名下有多少个开关需要治理。我随手就把这个需求丢给了 Cursor，说“开关 A 已经百分百推全了，帮我把无用代码和开关下线掉”。Cursor 很快就完成修改，而且格式和代码逻辑非常正确。这个体验让我们当即意识到：既然 AI 能搞定单个开关的治理，那能否规模化？不可能让每个人都装一个 Cursor 一个一个治理，于是我们直接调用大模型 API，尝试做批量治理。

我们快速搭建了一个 Demo，流程极其简单：第一步，定位到开关被哪些代码引用，找到这些文件之后，通过 Git Open API 把源代码拉到本地内存中；第二步，将源代码和要修改的需求（即提示词）交给大模型；第三步，大模型修改完后返回，再通过 Git Open API 提起一个远程 MR，流程就此结束。然而，这个迫不及待投入试用的 Demo 立即暴露了大量问题。比如，AI 会把还在使用的 import 语句直接删掉，也就是“减号两行”的问题；或者莫名其妙更改了大小写。当时提示词调优正火，我们也采取了非常传统的调优方式，例如在提示词中加入禁止项命令、提供样本案例、加入思维链提示，要求模型“先思考再修改，不要直接改，怕改错”。通过这些手段，AI 修改开关代码的正确率得到了大幅度提升，在场景较为简单的情况下，正确率一度能达到 70%-80% 的水准。

但即便是百分之七八十，在开关治理场景中，业务是绝不能容忍的。因为只要改错一个业务逻辑，基本上就等同于一个非常严重的线上故障。我举几个触目惊心的例子：第一种，方法名与开关名完全相同，大模型误把方法当成了开关，直接将整个方法删掉，意味着整个功能模块全部失效。第二种，把逻辑改反，原来为 false 时执行 A，改成了返回 true 时执行 A，后果更严重。第三种，开关名混淆，开关 A 和开关 B 命名极其相似，我让 AI 下线 A，结果它把 B 也一并下线。第四种，无关代码修改，完全不相干的逻辑，AI 莫名其妙也要去动一下。当时我们就清醒地意识到，完全信任大模型，基本等于被动等待故障发生。绝不能指望大模型永远不出错，因此必须建立起一套足够完善的安全护栏，拦截所有错误，防止错误代码透传到线上。

OpenAI 的联创 Andrej Karpathy 曾分享过一种 Vibe Coding 体验：他使用 AI 生成代码时，已经不再看结果，全盘接受 AI 生成的代码，一旦遇到报错信息，就原样复制粘贴过去，什么都不说，往往就能解决问题。我们在日常使用 AI 对话框时也有类似感受，当大模型第一次回答不符合预期时，采用追问的方式进行纠偏，常常也能解决。这种方式就是多轮对话。

基于这一思想，我们搭建了基于 Session 的多轮对话实现。大模型本身没有记忆，因此我们将整个上下文对话全部持久化存储。当遇到错误时，将历史消息连同错误信息一并再次提交给大模型，让它在既有上下文的基础上给出改进。那么，有了多轮对话之后，另一个关键问题随之而来：如何检测 AI 是否出错？我们必须构建一个极强的校验框架。

这个校验框架被设计为可扩展的，能支持全方位的检测插件来做 Bad Case 拦截。目前我们沉淀了两大类检测插件。第一类是逻辑检查插件，例如检查是否误删了无关开关，检查布尔逻辑是否被改反，检查业务逻辑是否完整，检查是否误删了非开关相关的代码等。第二类是编译检查类插件，包括代码是否符合 Checkstyle 规范，是否存在语法错误，流水线编译能否通过等等。

将强校验框架与多轮对话结合，第一道安全护栏就成型了。流程是：源代码和修改指令交给大模型后，输出结果首先经过第一道安全护栏的校验，包括语法检测、逻辑检测或编译检测等。如果安全护栏未通过，会把历史消息与错误信息再次返回给大模型，让大模型持续迭代修改，直至第一道安全护栏全部通过，我们才认为暂时没有问题。

然而，安全护栏本身是持续进化的，各类 Bad Case 必然还会存在，不可能百分之百拦截所有错误。于是我们设计了第二道安全护栏——最直接想到的就是人工兜底。因为在 AI 出现之前，代码本来就需要人工 Review 之后才能上线；有了 AI 后，我们在想能不能用大模型替代人工 Review，反正大模型本来就是替人干活的。我们做了一个实验：用三个大模型去 Review 主大模型生成的代码，判断是否有错。三个模型互相独立、不共享上下文，采取少数服从多数的原则，两个或以上通过才视作通过。

但这里有一个很难回避的 Bug：你怎么保证评测大模型就一定没问题？这本质上是用概率事件解决概率事件，Review 结果无法保证百分之百正确率。既然无法保证，那还是需要百分之百的人工 Review。打个比方，AI 说“我改这段代码的正确率有 99%，改一百个会错一个，但我不能告诉你是哪一个错了”，此时你是不是还得把一百个全部看一遍？这意味着人工参与度根本没有降低。

为了真正降低人工参与，我们调研到一篇论文《程序辅助语言模型》，其核心思想是利用大语言模型解读自然语言问题，并将推理步骤升华为生成程序，同时将解决步骤交由 Python 解释器继续执行。这让我想起之前一位同事的经历：他让大模型生成一百个字符串并按逗号拼接，大模型很快拼接完成，肉眼检查以为没问题，后来却发现少了两个字符串，肉眼极难查出。后来我告诉他，以后大模型干活的时候，不要让它直接出结果，而是让它写一段脚本，你先 Review 这个脚本，再让脚本去执行，这样几乎不会出错。我们将这个思想应用到了治理上：用确定性的程序检测替代人工兜底复核。

具体实现是，AI 改完代码后，我们再让一个 AST（抽象语法树）引擎把同一段代码再改一遍。如果 AST 引擎改出的代码与 AI 改出的代码完全一致，我们就认为没有问题，不需要人工复核；如果不一致，再人工介入。

AST 引擎采用的是规则加有向图的架构。我们将规则原子化，一条规则只做一件事，例如只做 if 清理，或者只做删除字段、删除方法等。整个 AST 引擎由一个有向图驱动，逐步执行各个规则，最终达到修改代码的平衡状态。由此我们形成了大模型生成与 AST 校验的双引擎架构范式：大模型像一个勘探者，处理代码的模糊性，生成创新方案，解决硬编码无法覆盖的问题；而 AST 引擎是一个校验者，依靠程序规则确保零故障。

阶段性总结整体流程：拿到原始代码以及修改提示词之后，首先将提示词给到大模型，大模型修改完成后经过第一道安全护栏，即逻辑检测、编译检测等。第一道安全护栏通过后，继续交由 AST 引擎再改一遍。改完之后，将 AST 结果与 AI 结果做 Diff，如果一致，我们就认为 Review 通过，人工不再介入；如果有差异，则走第二道安全护栏，即人工 Review，直到通过为止。实践表明，AST 引擎可以帮我们拦截非常庞大的 Review 成本。

这里可能产生两个核心疑问。第一个疑问是，AST 引擎本身一定正确吗？ 没有人能保证自己写的代码百分之百正确。我们也有一些兜底方案，比如在流水线中沿用快手的准入条件，包括单元测试、集成测试、流量录制回放、Diff 等。但这依然无法完全保证代码修改的正确率。最核心的思想是，我们为什么能用 AST 替代人工 Review？并不是因为 AST 百分百正确，而是我们将业务治理的压力从业务侧转移到了平台侧。此前，推业务去治理，业务改代码有可能改错，责任全在业务；现在业务不用再自己改代码，AI 去改代码，AST 去 Review。如果这一整套流程出了问题，责任归属平台。平台方不再只是一个提供提效工具的协助角色，而是与业务方站在一起、帮业务承担治理责任的同行者。这种责任转移极大提升了业务方配合治理的意愿。而且，AST 引擎与 AI 引擎同时改错代码的概率，我个人认为几乎为零——一个不确定性的生成结果加上一个确定性的程序，两者同时错且错得一模一样，这个概率极低。同时，两个引擎可以互补互反哺：当 AST 认为 AI 改错时，可以反过来优化 AI；反之亦然。

第二个疑问是，既然已经有了 AST 引擎，还需要 AI 引擎吗？ 结果是以 AST 引擎为最终上限，那 AST 是不是就意味着一定对？看这样一个例子：假设没有 AI 引擎，从原始代码到 AST 引擎改完代码，由于 AST 必然不能百分之百覆盖所有场景，有些复杂场景之下肯定会改错，而你又无法预知哪些场景不支持，于是依然需要百分之百人工 Review。但如果加上 AI 引擎，只用 AST 的流程肯定还需要人工 Review，而 AI+AST 的流程却可以将人工 Review 成本降到极低，因为只有在两个引擎发生分歧时才需要人介入。

3自我进化：人工到系统自升级

即便有了 AI+AST 双引擎，AST 引擎和校验插件本身仍然是不完善的，它们会遗留一些未拦截住的 Bad Case。当时我们维护这套系统的投入不到一个人力，人工维护成本极高，引发了一连串问题：效率低，每天要人工 Review 大量 MR，导致 Review 积压排队；人力成本浪费，AI 改对的绝大多数结果还需要人从中寻找错误的；滞后性强，AST 引擎和校验插件的版本迭代速度因人力瓶颈而持续跟不上。我们开始认真思考，如何让 AST 和校验插件实现自进化，使人工参与度再进一步降低。

评测体系的底层是数据采集层。AST 引擎 Review 通过的 Case 会自动进入评测集；人工 Review 通过的 Case，也视为正确，自动进入评测集；但人工 Review 拒绝的 Case，会进入一个重要 Case 评测集，其决策是：未来做评测回溯时，这些 Case 必须百分之百通过，也就是说，犯过的错误绝对不能再犯。评测集构建完毕后，进入上层标注环节，标注完成后走到评测执行层，这里会构建与线上隔离的评测用流水线与环境。最终数据流入分析层，进行链路分析及结果回溯。

如果能打通这一套链路，并让 AI 驱动整个系统自进化，就能形成一个正向飞轮：人工标注完成，系统自动优化→自动执行评测→评测通过后正确率提升→正确率提升后人工标注量减少→减少后继续反馈到这个回路，最终人工标注量趋近于零。

具体怎么进化？我们对之前打标的所有历史 Case 进行了回溯，基本上可以分为两类：第一类，人工复核后发现 AI 改错了，说明检测插件能力没有到位，未能把错误拦截住，这证明当前存在盲区，必须优化检测插件；第二类，人工标注是正确的，证明 AI 都改对了，但你居然还是让人去看了，这说明 AST Review 没有拦截住，需要优化 AST 引擎。

由此我们设计出一个双 Agent 专项升级体系。针对“人工标注正确”的场景，将此类 Case 交给 AST 能力升级 Agent，由它分析为什么 AST 没有拦截住，为什么系统判断出错，然后自主完成修复（如优化 AST 引擎代码）。改完并部署后，自动触发评测，评测结果没有问题便上线。针对“人工标注错误”的场景，则交给 检测插件升级 Agent，由其定位为什么检测插件没有拦截住，进行插件代码补齐，同样自动评测后上线。

以 AST 引擎升级 Agent 的工作流为例，其步骤并非直接动手写代码。第一步是需求理解。有一个专门的需求理解 Agent，它不需要做方案设计，也不出 PRD，而是要准确理解“要干什么、怎么干”，并先生成一份文档。文档产出后需要人工 Review，若存在问题则在反馈环路中持续修正，直至通过。第二步由另一个 Agent 负责技术方案编写，包括架构设计、核心思路与流程，同样需要人工 Review。第三步是自动编写代码并进行智能化代码审查。全部审查通过后，触发部署流水线，将代码部署到隔离的评测环境中，进行自动评测，整个循环完成。

至此，我们可以完整地俯瞰治理系统的运转全景。整体流程分为上下两层：上层是完全无需人工参与的自动化链路。原始代码与修改指令交给大模型，大模型改完后由校验插件进行检测，通过后交给 AST 引擎再次修改，修改结果与之前结果做 Diff，如果 Diff 一致，整个流程结束，无需人工介入。下层是带有人工参与但不断反哺上层的进化链路。如果 AST Review 拒绝，则进入人工 Review。若人工 Review 拒绝，将 Case 交给检测插件优化 Agent 去升级校验插件；若人工 Review 通过，则交给 AST 引擎优化 Agent 去升级 AST 引擎。下层的人工参与持续反哺上层，使得人工介入比例越来越低，整个系统成为一个正向自我优化的循环。

当前我们正在全力推进的一项工作，是 AI Native 全生命周期治理。此前的工作仍集中于债务发生之后的“堵”，工作环节都堆在治理链的最后一个环节，非常片面。真正的 AI Native 意味着要覆盖开关的完整生命周期，从源头即参与。

我们正在搭建的系统围绕三个阶段展开。第一，智能创建。在需求研发阶段就让 AI 参与进来，根据需求场景判断该功能是否需要开关，开关的作用到底是什么，是用于放量还是用于功能降级等等，同时给开关打上分类标签。这样开关从一出生就具备了可治理的属性。第二，智能变更。让 AI 参与变更计划制定和放量节奏设计，并且自动巡检相关监控指标，一旦巡检到异常，立即执行变更阻断，防止风险扩大。第三，智能删除。基于创建时已积累的上下文信息，在开关全量放量结束、稳定性验证完成后，无需人工介入，系统自动下线开关。

整体治理架构自底向上分为五层：底层为 AI 基建层，包含大模型、会话存储及多轮对话等基础设施；其上是评测层；再上层是逻辑检测、代码检测、编译检测等安全护栏层；最上层是日常使用的 MR 工具层，例如提代码、拉代码等操作；右侧则是自进化的 Agent，用以持续优化整套系统。

4总结与展望

我们此前经历过运动式治理，也陷入过治理死循环，最终用 AI 打破了困局。我们构建了双引擎架构，通过多轮对话加逻辑验证使自动化流程跑通，又通过双 Agent 的自进化让系统持续自我完善。这与 Harness 现在倡导的理念十分契合，虽然我们并没有刻意去对标这个概念，但在落地过程中，的的确确是在用工程化手段约束 AI、引导 AI。

截至目前，这套系统已经累计自动下线了 1500 个开关，删除 六万多行代码，且实现了 线上零故障。当前准确率在 98% 以上，仍有少量 Case 未能完全拦截，AST 与 AI 引擎的拟合率也达到了 80% 以上，人工成本由此得到极致降低。

最后，我想延展一点思考。虽然我分享的只是一个非常窄的开关治理例子，但所有技术债的治理，只要存在确定性的答案，理论上都可以采用这种范式来执行。例如基础设施的升级，当 RPC SDK 版本太低需要统一升级时，或者代码里写死域名导致没有域名容灾能力需要治理时，都可以复用这套“不确定性探索 + 确定性校验 + 自进化闭环”的方法。此外还包括冷代码的治理，那些线上已经毫无流量却长期驻留在业务里的代码，同样可以采用自动化方式安全删除。最好的治理，是治理本身被遗忘；最好的系统，是系统自己照顾自己。

作者介绍

闫文亮，快手资深服务端架构师。拥有 11 年后端研发经验，现任快手资深服务端架构师，负责快手配置中心、开关系统、API 网关等多个核心系统的架构设计与迭代优化，深耕 Java 服务端研发、平台化建设与 AI 工程化落地领域。主导推进公司 API 网关升级、HTTP 流式框架落地、AI 配置治理、AI 变更质检等重点项目，攻克多项核心技术难题；牵头落地 AI 驱动的开关自动化治理体系，实现规模化开关代码自动修复与技术债高效偿还，持续赋能研发效能与系统稳定性提升。

会议推荐