快手、AI 活用による機能フラグ全ライフサイクル管理を提案

「最高のガバナンスとは、ガバナンスそのものが忘れ去られること。最も優れたシステムとは、自らを管理できるシステムである。」

微サービスとアジャイルな開発サイクルの深化に伴い、機能フラグ（Feature Flag）は現代のソフトウェアデリバリーにおける不可欠なリスク制御手段となっています。しかし、業務が極めて複雑で、イテレーションが非常に速い超大規模システムである快手のような環境では、長期にわたって存続する多数のフラグが、重たい隠れた技術負債へと変貌しつつあります。

本稿は、QCon 全球ソフトウェア開発大会 2026 北京大会で、快手のシニアサーバーサイドアーキテクトである閻文亮氏が行った基調講演「機能フラグを自己消滅させる：AI によるフルライフサイクルガバナンス」の内容を整理したものです。氏は、AI を活用した機能フラグの全ライフサイクルガバナンスにおける実践を振り返り、ガバナンスの行き詰まり、AI エージェントの実装プロセス、ダブルエンジンによる安全バリア、自己進化メカニズム、そして AI ネイティブなガバナンスパターンの進化に至るまでの全体像について解説しました。

一、Feature Flag の価値と隠れた技術負債：ビジネスの必須要件から技術負債の罠へ

快手アプリは起動時にバックエンドサーバーの特定のインターフェースを呼び出します。ある時、このインターフェースが新機能のアップデートにより、クライアント側で互換性のないフィールドを返したことが原因で、アプリがクラッシュしました。バックエンドの開発チームは即座にコードをロールバックしましたが、クラッシュが発生したのは起動直後の極めて早い段階であり、その時点でクライアント側はまだ修正されたコードを取得できていませんでした。結果として再度クラッシュし、「起動すればクラッシュ、再起動してもクラッシュ」という無限ループに陥ってしまいました。

当時、クライアント側の「安全装置」や「セーフティモード」は未だ不十分でした。最終的にはユーザーに対してアンインストールと再インストールを促すしか手がなく、この状況に直面した開発者の心境は想像に難くありませんでした——極めて焦り、必死の思いで対応していたことでしょう。

その時、誰もが繰り返し問うていた命題があります。「どうすれば、新機能のリリースをもっと自信を持って、余裕を持って行えるのか？」

これに対する標準的な答えが「Feature Flag（機能フラグ）」です。これは本質的に、機能のリリースとコードのデプロイを分離するソフトウェア技術です。仮に当時、万全なフラグ管理機能が備わっていたなら、新機能はまず内部ユーザー向けに限定して開放し、モニタリングで問題が確認されてから段階的に外部へ展開できたはずです。そうすれば、今回のような大規模障害は回避できた可能性が高いのです。

さらに、Feature Flag（機能フラグ）を使えば、コードのリリースと機能の公開を完全に切り離すことができます。

例えば、A・B・C の 3 つの機能を同時にリリースする際、もし B に問題が発生しても、スイッチがなければ 3 つ全体を巻き戻さざるを得ず、結果として A と C も延期せざるを得なくなります。しかし Feature Flag を使っていれば、B の機能だけをオフにすればよく、A と C には影響がありません。

このように、Feature Flag は非常に強力なツールです。特に AI コーディングが主流となった現在では、コードを自分で書くのではなくすべて AI に生成させるため、リリースに対する不安はより大きくなっています。そのため、Feature Flag を活用してリリースの自信を持つことが、以前にも増して重要になっています。

しかし、その反面で Feature Flag があまりに便利であるがゆえに、快手（Kuaishou）のプロダクションコード内には膨大な数の機能フラグが存在しています。誇張ではなく、コードを数行読むだけで必ず 1 つは見つかるほどです。

例えば、快手の検索業務に関するコードを見てみると、検索自体のためのスイッチだけでなく、ローカルライフや EC（電子商取引）関連のスイッチも混在しています。その理由は、快手のビジネスフローが極めて複雑であるためです。あるコンテンツを検索する際にも、ローカルライフのフィードや EC の商品が表示される可能性があります。こうした多様な機能のためにスイッチが積み重なり、それぞれの役割や責任範囲が曖昧になっていきました。

このように大量に蓄積されたスイッチは、4 つの深刻な課題をもたらしています。

まず第一に、コードの保守コストが急増することです。新人がプロジェクトを引き継ぐ際、無数のスイッチの中から論理を整理し、どの部分が有効で、どの部分が廃止されたのかを判断する必要があります。AI コーディング時代においては、コードが自分自身の手によって書かれたものではないため、誰しもが新人同様の状況に置かれ、コストは依然として高いままです。特に AI がコードを読み込む場合、どのロジック分岐を実行すべきかを決定するために各スイッチシステムの値を参照する必要があり、これはさらにコストを増大させます。

第二に、計算リソースの浪費です。呼び出しや論理判断のたびに、どのブランチへ進むべきかを確認する処理が発生します。これが積み重なると、無視できないほどのリソース損失となります。例えば、快手のショート動画メイン業務（上下流は除く）では、1 秒間にスイッチを参照する回数がなんと 155 億回に達しています。

第三に、帯域幅のリソース浪費です。クライアント側でも機能リリースのためにスイッチを利用する必要があり、その値はバックエンドサービスから配信されます。その結果、1 つの API で配信されるスイッチの数が膨大になり、帯域コストが莫大なものになります。快手では、スイッチの配信だけで毎年数百万円の帯域コストが発生しています。

第四に、隠れた安定性のリスクです。期限切れとなったスイッチは、時折「完全に展開済み」の値を取得できず、古いロジックへ分岐してしまいます。これがオンライン上の問題を引き起こす原因となります。実際の事例として、数年前にすでに 100% 展開済みのスイッチがありながら、古いロジックが削除されず、そのまま放置されていたケースがあります。ある日、小さなバグによってスイッチの値が取得できず、予期せぬ異常が発生しました。業務チームは徹夜で調査を続け、ようやく根本原因を特定することができました。

つまり、すでに 100% 展開済みのスイッチであっても、適切に管理されなければ、いつ爆発してもおかしくない時限爆弾となり得るのです。

既然危害如此明确，为什么业务团队仍缺乏治理的动力？首先，开启开关极其容易：只需一分钟写一个 if 语句，就能解决发布风险、赋予发布自信、实现部署与发布的解耦。但删除一个开关却复杂得多：需要梳理上下游业务、评估下线风险、修改代码、重新发布并测试，耗时短则一小时，长则更久。

其次，在心态上，加开关是顺手的事，而删开关既无直接收益又需承担风险，业务人员自然不愿主动去做。再次，从组织层面看，员工离职交接时往往会留下所谓“后人的智慧”：我创建的开关我不删，留给后人治理；后人一看，不知这开关的用途，担心下线有风险，干脆放着不动。再加上跨部门合作的开关职责不清，人人都不敢动。债务越积越多，谁也不愿删除，形成了一个死循环。从快手某部门的开关增长数据来看，每年新增量高达数千个。

尤其值得警惕的是，麻省理工学院的一位教授曾预言：“人工智能就像一张全新的信用卡，让我们以前所未有的方式积累技术债。”人写代码的速度有限，债务还有时间修复；但如果未来代码都由 AI 生成，技术债将呈爆发式增长。如果当下不开始治理，后续的时间窗口可能都会错过。

过去我们也尝试过多种传统治理手段：例如建立平台规范、为开关设定下线时间、搭建审计看板等，但这高度依赖业务的自觉性，执行力度参差不齐；也有编写自动化脚本删除开关的做法，效率尚可，但一旦遇到代码嵌套或业务逻辑复杂的场景，极易出错；再熟悉不过的是开展专项治理行动，拉一群人同步进度、强推治理。这种运动式治理确实立竿见影，但往往是一阵风过后不久就反弹，反弹后再拉人治理，治完又反弹，形成“治而不绝”的死循环。治理速度远远跟不上开关新增的速度。

直到 AI 的出现，才真正让我们看到了打破这一死循环的可能。2024 年下半年，我们判断，用 AI 治理开关的内外部条件已经成熟：外部，大模型迭代极快、API 成本持续下降，模型在代码理解与修改上的能力已趋可靠；内部，我们对高效、安全且尽可能无需人工介入的治理方式有着迫切需求，加之公司 AI 基础设施的持续投入，我们认为时机刚刚好。快手由此跨入了 AI 治理的新时代。

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

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

振り返れば、2025 年の上半期のことだ。当時私は Cursor を使ってある機能の開発を進めていたが、Cursor とのやり取りで何度も行き違いが生じ、システムが「管理すべきスイッチ（Feature Flag）の数」を警告するメッセージを表示した。その時、私は即座に Cursor に指示を出した。「スイッチ A はすでに 100% ロールアウト済みだ。不要なコードとスイッチを削除してくれ」と。

Cursor はすぐに修正を終え、コードのフォーマットやロジックも正確だった。この体験から私たちは、「AI が単一のスイッチ管理をこなせるなら、それをスケーラブルにできないか？」と考えた。しかし、全員が Cursor を導入して手作業で一つずつ管理するのは現実的ではない。そこで、大規模な管理のために大規模言語モデル（LLM）の API を直接呼び出すアプローチを試みた。

すぐにデモを構築し、プロセスは極めてシンプルだった。まず、スイッチがどのコードから参照されているかを特定し、Git Open API を使って該当ファイルのソースコードをローカルメモリに取得する。次に、そのソースコードと修正指示（プロンプト）を LLM に渡す。最後に、LLM が修正した結果を受け取り、再び Git Open API を経由してリモートで MR（Merge Request）を作成すれば完了だ。

しかし、この試作デモはすぐに多くの課題を露呈させた。例えば、AI はまだ使用されている import 文を削除してしまう「減号二行」の問題や、意味もなく大文字・小文字を変更するケースが頻発した。当時はプロンプトのチューニングが注目されていたこともあり、私たちは伝統的な手法を採用した。具体的には、禁止事項をプロンプトに明記したり、サンプル事例を提供したり、「思考してから修正せよ」という Chain of Thought（思考連鎖）を指示して「安易に変更せず、誤りを防ぐ」よう求めた。

これらの対策により、AI によるスイッチコードの修正精度は大幅に向上し、比較的シンプルなシナリオでは 70%〜80% の水準まで達した。

しかし、スイッチ管理という文脈において、70%〜80% の精度では業務上許容できない。なぜなら、論理を一つでも誤って修正すれば、それは重大なオンライン障害に直結するからだ。以下に、実際に起きた恐ろしい事例を挙げる。

第一に、メソッド名とスイッチ名が完全に一致している場合、AI がメソッドをスイッチと誤認し、関数自体を削除してしまうケースだ。これにより、機能モジュール全体が無効化される。

第二に、ロジックの反転である。本来は false の時に A を実行するロジックを、true の時に A を実行するように変更されてしまう。これはより深刻な結果を招く。

第三に、スイッチ名の混同だ。スイッチ A と B が非常に似ている場合、「A を削除して」と指示しても、AI は B も一緒に削除してしまう。

第四に、無関係なコードの改変である。全く関係ないロジックに対して、AI が理由もなく手を加えてしまうケースだ。

これらの事例から、私たちは明確に認識した。大規模言語モデルを完全に信頼することは、障害が起きるのを待つことと同じだ。AI が常に正確であるはずがないため、すべての誤りを検知・阻止し、誤ったコードが本番環境へ漏れないよう、堅牢なセーフティネット（安全装置）を構築する必要がある。

OpenAI の共同創設者であるアンドレイ・カルパティ氏は、Vibe Coding（感覚的なコーディング）という体験を共有したことがあります。彼は AI にコード生成を任せる際、結果を確認せず、AI が出力したコードをそのまま受け入れるそうです。エラーメッセージが出たら、それをコピーして AI に入力するだけで、何も追加の説明を加えずに解決してしまうのです。日常で AI チャットボットを使う際にも似た感覚があります。大モデルが最初の回答で期待通りの結果を出さなかった場合、追問することで修正を促せば、多くのケースで問題が解消されます。これが多輪対話の基本的な考え方です。

この考え方を元に、セッションベースの多輪対話システムを構築しました。大モデル自体には記憶機能がないため、会話全体のコンテキスト（文脈）をすべて永続化して保存しています。エラーが発生した際、過去のメッセージ履歴とエラー情報をセットで再度大モデルに送信し、既存の文脈を踏まえた上で改善案を出させるようにしています。

多輪対話が可能になったことで、新たな課題が浮かび上がりました。「AI がどこまで間違えているか」を検知する方法です。そこで、強力な検証フレームワークを構築しました。

この検証フレームワークは拡張性を重視し、あらゆる種類の検出プラグインをサポートして不良ケース（Bad Case）をブロックできるように設計されています。現在、2 つ主要なカテゴリの検出プラグインを実装しています。1 つ目はロジックチェック用プラグインです。不要なスイッチが誤って削除されていないか、ブール論理が逆転していないか、ビジネスロジックに抜けがないか、スイッチ関連以外のコードが誤って削除されていないかなどをチェックします。2 つ目はコンパイルチェック用プラグインで、Checkstyle などのコーディング規約に準拠しているか、構文エラーはないか、パイプラインでのコンパイルが成功するかなどを検証します。

この強力な検証フレームワークと多輪対話を組み合わせることで、最初の安全装置（セーフティネット）が完成しました。具体的なフローは以下の通りです。ソースコードと修正指示を大モデルに渡した出力結果は、まず第一の安全装置でチェックされます。ここでは構文解析、ロジック検証、コンパイルテストなどが行われます。もし安全装置を通過できなかった場合、過去のメッセージ履歴とエラー情報を再度大モデルへ返し、大モデルが継続的に修正を加え、すべての安全チェックに合格するまでループします。これで初めて「一応問題ない」と判断されます。

しかし、安全装置自体も常に進化し続けるものであり、あらゆる不良ケースを 100% 防ぐことは不可能です。そこで、第二の安全装置として「人間の最終チェック」を導入しました。AI が登場する以前から、コードは人間によるレビューを経てからリリースするのが常識でした。AI の時代になっても、この原則は変わりません。大モデルが人間に代わって作業を行うのは事実ですが、では大モデル自身でコードレビューを行えないかという実験を行いました。

具体的には、3 つの異なる大モデルを使って、メインの大モデルが生成したコードを検証する実験です。これら 3 つのモデルは互いに独立しており、コンテキスト（文脈）を共有しません。少数決を採用し、3 つのうち 2 つ以上が「問題なし」と判断した場合にのみ、その結果を承認します。

しかし、避けて通れないバグがあります。大規模言語モデル（LLM）による評価が本当に正しいとどうやって保証できるのでしょうか？これは本質的に「確率的事象で確率的事象を解決する」試みであり、レビュー結果の 100% の正確性を保証することはできません。もし 100% の保証ができないなら、結局は人間による 100% のレビューが必要になってしまいます。

例えてみましょう。AI が「このコード修正の正解率は 99% です。100 個修正すれば 1 つ間違いますが、どの箇所が間違っているかは教えられません」と言った場合、あなたは 100 個すべてを人間で確認する必要があるでしょうか？そうであれば、人間の関与は全く減りません。

真に人間の介入を減らすために、私たちは『Program-Aided Language Models（プログラム支援型言語モデル）』という論文を調査しました。この論文の核心は、大規模言語モデルが自然言語による質問を読み解き、推論ステップを生成するプログラムへと昇華させ、実際の解決ステップは Python などのインタプリタに任せるという考え方です。

これは以前、同僚が経験した話と重なります。彼は LLM に「100 個の文字列を生成してカンマで連結して」と指示しました。LLM は瞬時に結果を出力し、目視で確認しても問題ないと思われました。しかし後になってみると、2 つの文字列が欠落していることが発覚しました。目で追うだけではその欠落を見つけるのは極めて困難です。

私は彼にこうアドバイスしました。「今後は LLM に直接結果を出させるのではなく、スクリプトを書かせてください。まずそのスクリプトを人間がレビューし、その後で実行すれば、ほぼ間違いなく正確な結果が得られます」と。この考え方をコードガバナンスに応用したのが、本稿の提案です。つまり、人間の最終チェックに頼るのではなく、確定的なプログラムによる検出で代替するのです。

具体的な実装では、AI がコードを修正した後、AST（抽象構文木）エンジンが同じコードに対して再度修正を行います。もし AST エンジンが生成したコードと AI が生成したコードが完全に一致すれば、問題なしとして人間のレビューは不要です。両者が不一致であれば、初めて人間が介入します。

AST エンジンは、ルールと有向グラフを組み合わせたアーキテクチャを採用しています。ルールは原子化されており、1 つのルールは 1 つのことだけを行います。例えば「if 文の整理」や「フィールドの削除」「メソッドの削除」などです。AST エンジン全体は有向グラフによって駆動され、各ルールを順次実行することで、コード修正の平衡状態に到達します。

これにより、「大規模言語モデルによる生成」と「AST による検証」を組み合わせた双エンジンアーキテクチャが確立されました。大規模言語モデルは探検者のように振る舞い、コードの曖昧性を処理し、革新的な解決策を提案して、ハードコーディングではカバーしきれない問題を解決します。一方、AST エンジンはその検証者として機能し、プログラムルールによってゼロ障害を確保します。

全体のフローを段階的にまとめると以下のようになります。まず、元のコードと修正指示（プロンプト）を取得します。これを大規模言語モデルに渡して修正を行います。その後、第 1 の安全装置として、ロジックチェックやコンパイルチェックなどを実行します。この第 1 の安全装置を通過したら、AST エンジンが再度コードを修正します。

修正完了後、AST の結果と AI の結果を Diff（差分）比較します。両者が一致すればレビュー合格とし、人間の介入は不要です。もし差異があれば、第 2 の安全装置として人間によるレビューに移行し、問題が解消されるまで続けます。実践の結果、この AST エンジンによって膨大なレビューコストを大幅に削減できることが確認されています。

ここには二つの核心的な疑問が生じます。

第一に、AST エンジンは本当に正しいのかという点です。誰が自分の書いたコードを 100% 正確だと保証できるでしょうか？私たちはいくつかのセーフティネットを用意しています。例えば、クイックハンド（Kuaishou）の採用基準をパイプラインで引き継ぎ、ユニットテストやインテグレーションテスト、トラフィックの録画再生、Diff 確認などを適用します。しかし、これらだけでコード変更の正確性を完全に保証することはできません。

最も重要な考え方は、「なぜ AST で人手によるレビュー（Code Review）を代替できるのか」という点です。それは AST が 100% 正しいからではありません。むしろ、業務側のガバナンス（管理・統制）の負担をプラットフォーム側に移したからです。以前は、業務側がコードを変更してガバナンスを行う必要があり、もし間違えれば責任も業務側にありました。しかし現在では、業務側は自分でコードを変更する必要がなく、AI が変更を行い、AST がレビューを行います。もしこの一連のプロセスに問題が生じても、その責任はプラットフォーム側が負います。

プラットフォーム側は単なる効率化ツールの提供者という役割を超え、業務側と共に立ち、ガバナンスの責任を共に担うパートナーとなりました。この責任の移転により、業務側のガバナンスへの協力度が劇的に向上しました。また、AST エンジンと AI エンジンの両方が同時にコードを間違える確率は、私個人の見解ではほぼゼロだと考えています。不確実な生成結果と、決定論的なプログラムが、同じ間違いを犯す可能性は極めて低いからです。

さらに、両者のエンジンはお互いに補完し合い、強化し合います。AST が AI の変更を誤りと判断すれば、それをフィードバックして AI を最適化できます。逆に、AI が AST の判定に疑問を呈すれば、AST の精度向上にも寄与します。

第二の疑問は、「AST エンジンがあるなら、なぜ AI エンジンも必要なのか」という点です。「AST エンジンを最終的な上限とする」のであれば、AST は必ずしも正しいとは限りません。例を見てみましょう。AI エンジンがない場合、元のコードから AST エンジンによる変更完了までを想定します。AST はすべてのシナリオを 100% カバーできないため、複雑なケースでは間違いが発生し、かつどのシナリオに対応していないかを事前に予測することはできません。その結果、依然として 100% の人手によるレビューが必要になります。

しかし、AI エンジンを加えることで状況は変わります。AST 単独のプロセスでは人手によるレビューが必須ですが、「AI+AST」の組み合わせであれば、人手によるレビューコストを極めて低いレベルに抑えられます。なぜなら、両者のエンジンで判断が分かれた場合のみ、人間が介入すればよいからです。

三、自己進化：人手からシステムへの自立的なアップグレード

AI と AST のダブルエンジン体制を整えても、AST エンジンや検証プラグイン自体は完璧ではありません。未検出の「Bad Case（失敗事例）」が残ってしまうことがあります。当時、このシステムの維持に要するコストは 1 人月未満でしたが、人手によるメンテナンスのコストは極めて高く、一連の問題を引き起こしました。

具体的には、効率性の低下です。毎日大量の MR（Merge Request）を人手でレビューする必要があり、レビューが溜まって待ち行列が発生します。また、人件費の無駄も生じます。AI が正しく修正した結果のほとんどから、人間が誤りを見つけ出す必要があるからです。さらに、対応の遅れも深刻です。AST エンジンや検証プラグインのバージョン更新速度が、人手のボトルネックにより常に追いついていませんでした。

そこで私たちは、AST と検証プラグインを自己進化させ、人間の関与をさらに減らす方法を真剣に考え始めました。

自己進化を実現する前に、人間がシステムを最適化する方法を例に考えてみましょう。必ず根拠を持って最適化する必要があります。つまり、每一次の変更が正しいのか間違っているのかを知る必要があります。これは業界で広く採用されている手法であり、「評価体系（ベンチマーク）」を構築することです。

私たちのプロセスは以下の通りです。コード変更が完了するたびに、Trace（追跡ログ）に基づいて、AI のプロンプト、レスポンス、AST エンジンの結果、検証プラグインの結果をすべてデータベースに保存します。次に、すべての結果に対して人手によるラベル付けを行います。AST レビューで既に合格したケースを除き、すべてのケースについて人手でのレビューを実施します。

その後、ダッシュボードを整備し、ラベル付け結果を可視化します。毎日分析会議を開催し、「どこが間違っていたのか」「なぜ間違えたのか」を特定し、AST エンジンの最適化か、検証プラグインの最適化かを判断して対策を講じます。最適化が完了したら、以前に保存されたすべての履歴データに基づいて評価を遡行（バックテスト）します。

この評価の遡行結果は非常に明確です。「正解なら正解」「誤りなら誤り」という結論が、プログラムによって即座に導き出されます。

評価システムの基盤となるのはデータ収集層です。AST エンジンによるレビューを通過したケースは自動的に評価セットに追加されます。同様に、人間が手動でレビューして「正しい」と判断されたケースも評価セットへ自動登録されます。

一方、人間が手動レビューで却下したケースは、「重要ケース評価セット」へと送られます。ここでのルールは明確です。将来の評価を遡る際、これらのケースは 100% の確率で通過させる必要があります。つまり、一度犯したミスを二度と繰り返してはならないのです。

このように評価セットが構築されると、次は上位レイヤーである注釈（ラベリング）工程へと進みます。注釈作業が完了すれば、いよいよ実行層へ移行します。ここでは本番環境から完全に隔離された、評価専用のパイプラインと環境を構築します。最終的にデータは分析層に流れ込み、リンク解析や結果の遡及調査が行われます。

この一連のチェーンを確立し、AI がシステム全体の自己進化を駆動できれば、正のフィードバックループ（フライングホイール）が形成されます。具体的には以下の通りです。

人間による注釈完了 → システムの自動最適化 → 自動評価の実行 → 評価通過による精度向上 → 精度向上に伴う人間の注釈量減少 → 削減された注釈量が再びループにフィードバック → 最終的に人間の注釈量はゼロに漸近する。

では、具体的にどのように進化していくのでしょうか。私たちは過去に行われたすべてのラベル付けケースを遡って分析しました。その結果、大きく分けて二つのパターンが存在することが分かりました。

第一のタイプは、「人間が再確認したところ AI の修正が間違っていた」というケースです。これは検出プラグインの能力不足を示しており、エラーを適切にブロックできていなかったことを意味します。つまり、現在のシステムには「盲点」があり、検出プラグインの最適化が必須であることを示しています。

第二のタイプは、「人間の注釈が正しく、AI も修正を完了していた」というケースです。しかし、なぜか人間が確認作業を行ってしまいました。これは AST Review がエラーをブロックしきれなかったことを意味しており、AST エンジンの改善が必要であるという証拠になります。

これらの洞察に基づき、私たちは「2 つの Agent を活用した特別アップグレードシステム」を設計しました。

まず、「人間の注釈が正しく、AI も正しく修正していたケース」については、AST 能力アップグレード Agent に任せることにします。この Agent はなぜ AST がエラーを検出できなかったのか、なぜシステムの判断が誤ったのかを分析し、自主的に修復を行います（例：AST エンジンのコード最適化）。修正とデプロイが完了すると自動的に評価がトリガーされ、問題がなければ本番へリリースされます。

一方、「人間の注釈が正しくなく、AI の修正も間違っていたケース」については、検出プラグインアップグレード Agent に任せます。この Agent はなぜ検出プラグインがエラーをブロックできなかったのかを特定し、プラグインのコードを補完します。これも同様に自動評価を経てリリースされます。

AST エンジンアップグレード Agent のワークフローを例に挙げると、その手順は即座にコードを書き始めるわけではありません。

最初のステップは「要件の理解」です。専用の要件理解 Agent が担当しますが、この Agent は設計案を作成したり PRD（製品要件定義書）を出したりするのではなく、「何を」「どのように行うべきか」を正確に把握し、まずはドキュメントを生成します。生成されたドキュメントは人間のレビューを経る必要があります。問題があればフィードバックループで修正を繰り返し、承認されるまで続けます。

2 つ目のステップでは、別の Agent が技術的な実装案の作成を担当します。ここではアーキテクチャ設計や核となる考え方、プロセスフローなどが含まれます。これもまた人間のレビューを経なければなりません。

3 つ目のステップは、自動コード生成とインテリジェントなコードレビューです。すべての審査を通過すると、デプロイパイプラインがトリガーされ、コードは隔離された評価環境へデプロイされます。そこで自動評価が行われ、一連のサイクルが完了します。

至此，我们可以完整俯瞰整个治理系统的运作全景。整体流程分为上下两层：上层是完全无需人工参与的自动化链路。原始代码与修改指令交给大模型，大模型改完后由校验插件进行检测，通过后交给 AST 引擎再次修改，修改结果与之前结果做 Diff，如果 Diff 一致，整个流程结束，无需人工介入。

下层是带有人工参与但不断反哺上层的进化链路。如果 AST Review 拒绝，则进入人工 Review。若人工 Review 拒绝，将 Case 交给检测插件优化 Agent 去升级校验插件；若人工 Review 通过，则交给 AST 引擎优化 Agent 去升级 AST 引擎。下层的人工参与持续反哺上层，使得人工介入比例越来越低，整个系统成为一个正向自我优化的循环。

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

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

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

四、总结与展望

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

このシステムはこれまで、自動で 1,500 個の機能フラグを削除し、6 万行以上のコードを整理しました。その結果、本番環境での障害はゼロです。現在の精度は 98% を超えており、まだ完全にブロックできていないケースがわずかに残っていますが、AST（抽象構文木）と AI エンジンの適合率も 80% を上回っています。これにより、人的コストを極限まで削減することに成功しました。

最後に、少し考えを広げてみましょう。私が紹介したのは機能フラグの管理という非常に狭い範囲の事例ですが、技術負債の整理において「正解が明確に存在する」ケースであれば、理論的にはすべてこのアプローチで対応可能です。例えば、インフラのアップグレードで RPC SDK のバージョンが古すぎる場合や、コード内にドメイン名をハードコーディングして災害対策が効かない状態になっている場合などです。これらもすべて、「不確実性の探索＋確定性の検証＋自己進化のループ」という同じ手法で解決できます。

また、不要になった「コールドコード」の管理も同様です。本番環境で全くトラフィックがなくとも、長期間業務システムに残り続けているコードは、自動化された方法で安全に削除できます。最も優れた管理とは、管理そのものが忘れ去られることです。最も優れたシステムとは、システム自身が自らを維持できるものです。

【快手技術交流群】にご参加ください

QR コードをスキャン👇

【原文を読む】をクリックして、講師の PPT を入手してください！

原文を読む

WeChat で開くにはこちらへ