QQ ブラウザ、チーム文脈で AI を進化させる実践を公開

QQ ブラウザにおける、チーム文脈の中で AI が継続的に進化するためのエンジニアリング実践

著者：linjangyang、lypeerluo、kehawang、yansycao

個人開発における AI コーディングの効率化はもはや疑いの余地がありません。しかし、チーム規模が拡大すると、より本質的な課題が浮き彫りになります。それは、各セッションで陥ったトラブルや修正から得られた有効な知見が、セッション終了と同時にリセットされてしまう点です。

現在の業界における Agent の経験管理の取り組みは、「個人の記憶」に焦点を当てることが多いですが、AI が毎回プロジェクトに入るたびに「ゼロからスタート」する循環を打破するには、チームの経験を継続的に捕捉し、精製・蓄積して、AI にプロジェクトの文脈ごと引き継ぐことができるシステムが必要です。本稿では、このシステムの 0 から 1 の構築プロセスを共有します。初版では候補となる経験の 90% が不要なものであったというスタート地点から、レビュー（Review）、重複排除（Dedup）、統合（Merge）という 3 層のガバナンス・ループを確立するまでの道のり、そして各段階で直面した実務的な課題への対応策と、それを支えた実験データや再現可能なメソドロジーについて解説します。

一、「そんなことはやるな。このフックは同期で報告してはいけない」

これは半年前に行われた CodeBuddy のセッションでの出来事です。当時、停止フック（stop hook）の報告機能を実装中で、AI は自然に「同期での報告」を提案しました。多くの報告シナリオでは同期で十分なので、これは妥当な回答でした。

しかし、コードレビューの際に私たちは修正を加えました。「必ず非同期で行う必要がある。そうしなければ停止フックがプロセスをブロックし、その後の処理がタイムアウトしてしまうからだ」という理由からです。AI はフィードバックに基づいてコードを修正し、セッションは正常に終了しました。

問題は、セッションが終わった後に起こりました。

一週間後、別のメンバーのセッションで同じシナリオが発生しました。しかし、AI には前回のセッションの文脈が存在しないため、再び「同期での報告」を提案してしまいました。そのコードの元開発者ではないメンバーは、レビュー時にこの落とし穴に気づくことができませんでした。コードはマージされ、テスト環境になって初めて問題が露呈します。停止フックの処理でプロセスがブロックされ、連鎖的なタイムアウトエラーが発生したのです。

これが「経験の断絶」です。AI ができないから起きたことではありません。そのセッション内では修正を受け入れ、正しく動作していました。しかし、その修正は发起者の頭の中だけで完結し、AI 自体は何も覚えていないのです。

より広く見れば、チームが AI コーディングを継続的に深く活用する中で、以下のような 4 つの課題に直面しています。

・経験が捨てられる：一つのセッションで試行錯誤して得た解決策は、セッションが終わると同時にリセットされてしまう。次のメンバーが同じ問題に直面した際、AI はまたゼロからスタートすることになる。

繰り返される失敗：プロジェクトの隠れた制約

「このディレクトリのコードは第三者サービスにアクセスする際、特別なプロキシを経由しなければならない」「モジュール間のスイッチ参照には文字列パラメータを直接使用できない。スイッチの使用タイミングの問題により、常にデフォルトでオフになってしまうからだ」——これらのルールは git blame の履歴に残っているが、公式ドキュメントには記載されていない。担当者が変わったりセッションが変わったりすれば、同じ過ちを繰り返す可能性が高い。

知識の断片化

ベテラン社員の間には「こうすべきだ」という暗黙のパターンが存在するが、それを文書化する動機を持つ人は誰もいない。ドキュメントはコードの変更速度に追いついていない。AI 時代において重要なのは知識管理ではなく、運である——今回のセッションのコンテキストが過去の履歴をたまたまカバーしていれば成功し、カバーできていなければ失敗する。

AI は常に「新人」

AI はプロジェクトを選ばない。新しいモジュールに入っても、アーキテクチャの境界線や歴史的な負債、チームが過去に陥った落とし穴について知らない。コードを書く能力は不足していないが、「このチーム特有の文脈」を欠いている。

したがって、本質的な課題は「AI にどうやってコーディングを高速化させるか」ではなく、AI がプロジェクトに入るたびに「ゼロから始めさせられる」という循環を打破することにある。そのためには、チームの経験を継続的に捕捉・精製・蓄積し、AI がプロジェクトの文脈を持って参画できるシステムが必要だ。

二、初版の失敗：出力の 90% が実用不可能

最初の案は非常に単純だった。CodeBuddy の Plugin Hook を活用してすべての開発会話をアップロードし、AI にそれを読み込ませて自動的に経験を抽出する。プロンプトの核心はたった一言、「価値があると思う内容を抽出してください」——境界線の判断や除外ルールもすべてモデルに任せた。

論理的には成り立つ：会話には情報が含まれており、モデルも十分に賢いからだ。このプロセスは次の 2 ステップで構成される。

会話のアップロード → 経験の抽出 → データベースへの登録と公開

しかしすぐに分かったのは、抽出された経験の約 90% が「無価値な経験」であり、その後の作業を円滑にするものではないということだ。ここで言う「無価値」とは主観的な評価ではなく、「後続の Agent がそれを参照した際に行動が前向きに変化したか」という基準で判断したものである。さらに、この問題には単一の欠陥があるのではなく、4 つの構造的な問題が重なっている。

第一層：ノイズが多すぎる

元の会話には大量のデバッグ過程——「続ける」「再試行」「ダメだ、別の方法を試そう」——や失敗への道筋が含まれている。これらは経験ではなく、単なるプロセスの記録に過ぎない。モデルは区別せずにすべて抽出してしまう。例えば、「何度か試せばうまくいく」という経験が抽出されたケースがあるが、これは運を頼っているだけで、判断の蓄積ではない。

第二層：文脈の欠落

抽出された経験は元の文脈から切り離されると歪んでしまう。ある時、システムが「stop hook は非同期処理が必要だ」というルールを抽出したが、これは一見正しそうに見えるものの、実際には特定の工程や特定の場合にのみ適用されるルールだった。条件付けなしでこのルールを適用すると、後続の Agent がすべての hook シーンで無差別に非同期処理を行い、新たなバグを引き起こすことになる。

第三層：誤った誘導

経験がないことよりも危険なのは、間違った経験である。「タイムアウトしたらパラメータを大きくする」という経験が抽出されてデータベースに登録されたケースがある。根本原因はそこではなく、これは単なる応急処置に過ぎない。Agent が同様の問題に遭遇した際、この経験に基づいてまずパラメータを変更しようとし、根本原因の調査をおろそかにして、システム的に間違った方向へ進んでしまう。

第四層：価値の定義が困難

LLM の要約能力は一般領域では非常に高いが、経験抽出という文脈では、多くの出力が表面的なものに留まってしまう。「複雑な問題にはコンテキストを多く収集する」——この言葉は常に正しいように見えるが、具体的なエンジニアリングの現場では指導的な意味を持たない。AI はこれを読んでも、次に何をすべきか分からない。

これらの 4 つの問題が浮き彫りにした核心的事実は、「プロセスの記録＝経験ではない」という点である。自動抽出によって候補セットを拡大する一方で、ノイズも同時に増幅している。フィルタリングなしの自動抽出は、単なるゴミの増幅器に過ぎない。AI に自らの出力する経験の価値を判断させることは、審判が同時に選手を務めることと同じで、エンジニアリングの現場では無効だ。

三、既存の解決策が機能しない理由

失敗之后，我们系统性地审视了业界在“Agent 经验管理”方向上的方案。

ClaudeCode AutoDream は単一セッション内での自動記憶整理——ExtractMemories でエンティティ・嗜好・状態を抽出し、Auto Dream が非同期でマージする——に焦点を当てている。その位置づけは「単一の Agent の文脈を継続させる」ことであり、プロセスの記憶を永続的な記憶として保存するものだ。しかし、チームの境界を意識しておらず、何を長期的に残すべきか、何が単なる一時的な状態なのかを区別しない。

Hermes Agent はプロンプト駆動型のメモリ戦略システムです。特定の条件（タスクの成功や課題解決など）で振り返りをトリガーしますが、これは「いつ記憶するか」を解決するものであり、「何を記憶すべきか」という価値判断までは解決できません。また、システムレベルでの重複排除や出典の追跡も欠如しています。

Mem0 はエージェント向けの長期メモリインフラストラクチャです。ADD（追加）、UPDATE（更新）、DELETE（削除）、NONE（何もしない）という 4 つの判定と、混合検索機能、そして完全なライフサイクル管理を備えています。しかし、この設計には「記憶は概ね価値がある」という前提が置かれており、プログラミングのようなノイズの多い対話シーンでは、この前提は成り立ちません。

これらを比較すると、共通する限界が見えてきます。どちらも「個人の記憶」に焦点を当て、「より多く記憶すること」を追求しています。私たちが目指すべきは逆です。「チームの経験の質」に焦点を当て、「より少なく、しかしより信頼性の高いもの」を残すことです。それは適用範囲や制約条件、出典のエビデンスを伴ったエンジニアリングの知見です。業界に既存の解決策がないため、私たちは自らの手で模索する必要があります。

四、チーム経験とは何か——エージェントの視点から再定義する

経験システムの最終的な利用者であるのは人間ではなく、エージェントです。エージェントの動作は明確です。入力（ここで呼び出された経験が含まれる）を受け取り、意思決定を行い、出力を生成します。この仕組みに基づけば、ある情報を「経験」と見なす基準はただ一つに絞られます。

それは、「呼び出された後に、エージェントが前向きな行動変容を起こせるか」です。

これにより、「経験」という概念は「価値のあるテキストの断片」から、「エージェントの行動を変えられるかどうか」という実証可能な工程基準へと固定されます。

この基準に基づけば、合格するチーム経験にはいくつかの条件が同時に満たされる必要があります。具体的には、実際の対話からの出典であること、エビデンスで裏付けられていること、プロジェクト固有のもの（汎用的な常識ではない）こと、そして将来の類似シーンで再利用可能であることです。その中で最も重要なのが「容易に発見できない」という点です。もしエージェント自身で推論できる情報であれば、それを呼び出すことに追加価値はありません。

では、何が「容易に発見できない」のでしょうか？エージェントが要件を理解するプロセスを分解し、3 つの視点（レンズ）に分けて考えます。

1. 用語のレンズ（意味的に発見不可能）

プロジェクト内部で使われる専門用語、略語、通称は、字面からは全く推測できません。例えば、「D サイト」がプロジェクト内では違法コピーサイト、「A サイト」がアダルトサイトを指す場合などです。AI は単に文字列として「D」「A」しか見ておらず、背後にある意味を理解していません。こうした名称は対話の中で頻繁に登場しますが、AI がその真意を推し量ることは永遠にできません。

1. 索引のレンズ（位置が発見不可能）

特定のツールやディレクトリ、機能への入口が、直感的な経路から外れているケースです。例えば、「ダイレクトページ機能は xhome モジュールにあり、重要なクラス名は FastCutXXX です」といった情報です。コードを読んでも見つからないため、「どこを探せばいいか」を知っている必要があります。

1. 論理のレンズ（行動が発見不可能）

直感に反するエンジニアリング上の制約や、暗黙のメカニズムです。冒頭で触れた「stop hook は同期的な報告を行ってはならない」というルールが典型例です。AI の通常の推論では、「報告は軽量な操作なので同期でも問題ない」と考えがちですが、実際の現場には競合によるブロックリスクが存在します。また、「モジュール間のスイッチ参照に文字列パラメータを直接使ってはいけない」といったケースもあります。確かにスイッチには String 型のパラメータが存在しますが、使用タイミングの問題により、それを使うと効果が常にデフォルトの「オフ」状態になってしまいます。こうした落とし穴は、通常の推論では導き出せません。

これら 3 つのレンズは、トピック（フロントエンドかバックエンドか）や重要度（高・中・低）で分類したものではありません。そのような分類法は列挙しきれないほど多岐にわたる上、主観的な判断に依存して不安定だからです。ここで重要なのは、認知上の障壁という客観的な事実です。「エージェントが自分自身でこの情報を発見できるか」という問いには、明確な判定が可能です。

xhome モジュールの FastCutXXX を明示的に指す必要があります。

論理的な視点と、行動の不検出性について。stop hook の同期アップロードも重要です。AI の一般的な推論では、並行処理によるブロッキングリスクを導き出すことはできません。

五、システム連携：課題が迫る中で進化する

実際のエンジニアリング現場に戻りましょう。初期の 2 ステップ連携は動作しましたが、運用を開始すると次々と問題が露呈しました。いずれも設計段階では予測されていなかったものです。

問題 1： 生データをそのままモデルに投入すると、テーマが混在しノイズが多く、コンテキストが溢れてしまいます。経験則から「単発の対話」で判断できるものではありません。「失敗→修正→修復→採用」という一連のプロセス全体を見る必要があります。

→ そこで「テーマ別グループ化」を追加しました。モデルにセッションの概要を提示させ、テーマごとにセグメントを分割し、その後個別に抽出を行います。

問題 2： 抽出したデータをそのままデータベースに保存すると、約 90% がノイズ（ゴミデータ）でした。

→ そこで「Review（品質審査）」を追加しました。保存前に品質のゲートキーパーを設置します。

問題 3： グループやセッションが異なることで、重複する候補経験が生まれます。

→ そこで「Dedup（候補の重複排除）」を追加しました。保存前に重複を特定し統合します。

問題 4： 保存後、長期的なメンテナンスができず、新しい経験と過去の経験の関係性が不明確になります。

→ そこで「Merge（履歴との統合）」を追加しました。新規作成、更新、スキップ、あるいは過去のデータとの競合があるかを判断します。

これにより、最終的な連携フローは以下のようになります：

会話のアップロード → テーマ別グループ化 → 経験抽出 → Review → Dedup → Merge → データベース保存 → 検索・統計

見落としがちですが重要なのが「テーマ別グループ化」です。2 つのグループで比較実験を行いました。片方はグループ化したセグメントにセッション概要を付与し、もう片方は付与しないというものです。結果、概要を付けたグループの方がノイズが多くなりました。なぜなら、概要がモデルに対して一般化された推論を促してしまい、そのセグメント内で実際に起きた具体的な経験から逸れてしまったからです。グループ化の粒度だけで十分でした。

六、3 層ガバナンス：「動く」から「使える」へ

連携を構築したことは第一歩に過ぎません。システムを信頼できるものにするのは、「Review」「Dedup」「Merge」という 3 層のガバナンスです。これら 3 つは目標も戦略もデフォルトの方向性も異なりますが、根底にある駆動方法は共通しています。「エラー分析→ルール抽象化→評価検証」です。

6.1 抽出：ノイズの排除から評価主導へ

3 層について語る前に、まず源流となる「経験抽出」のプロセス自体をどう継続的に改善するかを説明する必要があります。

初期版で「経験を抽出できること」は証明されましたが、品質にはばらつきがありました。「良い経験」を一発で定義するのは難しいですが、「ノイズ（ゴミ）の経験」の特徴なら归纳しやすいです。そこで私たちは「まずノイズの研究から始め、そこから良い経験を逆算する」というアプローチを取りました。

大量の注釈データを通じて、9 つの典型的なノイズ特徴を归纳しました：

1. 事実誤認：存在しない制約を捏造したり、会話中の一時的な発言をルールとして扱ったりする。
2. 一般常識：どのプロジェクトでも通用するため、チーム固有の特性が反映されていない。
3. 会話要約：プロセスの復述に留まり、再利用可能な判断として定着していない。
4. 単発ケース：現在のタスクには有効だが、他へ転用できない。
5. ユーザーの主観的嗜好：個人の選択であり、チームの規範を代表するものではない。
6. コンテキスト欠如：どのモジュール・コンポーネント・インターフェースに対応するかが不明。
7. 粒度の混在：1 つの経験の中に一般ルールとケース固有の情報が混ざっている。
8. 実行不可能：抽象的なアドバイスのみで、Agent が何を実行すべきか分からない。
9. エビデンス不足：会話内に十分な根拠がなく、モデルが過度に推測している。

これら 9 つの特徴を踏まえ、2 つの工程化アプローチを進めました：

「标注路径」では、候補となる経験データに価値のラベル付け（高価値・低価値・ゴミ）を行い、ゴミについてはその原因を特定し、共通するパターンを抽出して、最終的にラベリングルールとレビュー基準へと変換します。このプロセスにより、「経験の質」という主観的な感覚を、議論可能で合意形成できる対象へと昇華させることができます。こうして構築された評価セットは、その後のプロンプト修正の効果測定に継続的に活用されます。

「可聴経路（監査可能なパス）」では、モデルに対して各経験データについて3 つの観点からの説明を求めます。「なぜこれが経験と言えるのか（解決した再利用可能な問題か、プロジェクト固有のものか）」「プロンプト内のどの除外ルールに該当し、どのようなゴミチェックを通過したのか」「会話のどのやり取りがその判断を支えているのか」です。これによりモデルの判断プロセスがブラックボックス化されず、後続のプロンプト改善において誤りの原因を特定する根拠となります。

この 2 つのパスを整備することで、プロンプトの改良は「なんとなく良くないから直してみる」という感覚的な作業から、明確な構造化されたフローへと進化します。具体的には、「固定された会話サンプルを用意」→「現行のプロンプトで抽出」→「人手によるラベル付けと照合」→「誤りの分析」→「プロンプトの修正」→「再評価」→「指標の変化を比較」という一連の流れです。

評価では、3 つの主要指標を同時に確認します。Recall（再現率）は「抽出すべきものをどれだけ拾えたか」、Precision（適合率）は「抽出されたもののうちどれがゴミでないか」、Garbage Rate（ゴミ率）は「不要なものをどれだけ引き出してしまったか」を示します。いずれかの指標だけを重視するのは危険です。適合率だけを追うとモデルが過度に保守的になり、再現率だけを追うとゴミが増加してしまいます。目指すべきは、ゴミ率を下げつつ、全体の抽出品質が低下しないように両立させることです。

6.2 Review：ソースコード探索による事実性の検証

Review の役割は、データ登録前に明確なゴミをブロックすることです。戦略としては「デフォルトで保持し、特定のフィルタリングを行う」アプローチを採用します。網羅的に厳しくするのではなく、「事実誤認・バイアス」「文脈の欠落」「粒度の混在」という 3 つの明確なゴミカテゴリーに対してのみ、正確に拦截（ブロック）を行います。さらに「経験として不適切なカテゴリ」を最後のセーフティネットとして配置します。

この設計思想の背景にはリスク管理があります。経験システムにおける最大のリスクは、「良い経験を逃すこと」が「少しだけ質の低い経験が入ること」よりも深刻であるという判断です。デフォルトで保持する方針をとることで、Review 工程が厳しすぎて高価値なコンテンツを誤って削除してしまう事態を防ぎます。

プロンプトによる判定フレームワークは以下の 4 ステップに収束しました。「事実誤認・バイアスのチェック」→「文脈の欠落チェック」→「粒度の混在チェック」→「経験不適切カテゴリでの兜底（セーフティネット）」。これまでに 3 回の迭代を経て、「全体のリニューアル」から「境界線の強化」、そして「バイアスルールの硬化」へと進化し、ゴミの漏洩は着実に改善されています。

しかし、テキストのみによる判断には本質的な限界があります。モデルは、経験データ内で言及されている技術的事実が実際に存在するかどうかを検証することができないのです。

実際の事例を紹介します。システムはある経験データを抽出しました。「Android のリスト開発において FastScrollBar を連携させる際は、attachToQBListView() メソッドを使用すべき」という内容です。テキスト上では論理が一貫しており、具体的なシナリオ、メソッド名、操作手順が明記されているため、純粋なテキストレビューであれば通過する可能性が高いケースでした。

しかし、私たちはソースコード探索を導入しました。コードベース内で FastScrollBar のクラス定義を検索した結果、同クラスには attachToRecyclerView() と attach() の 2 つのメソッドしか存在せず、attachToQBListView() というメソッドは存在しないことが判明しました。正しくは「FastScrollBarCompat.attachToQBRecyclerView()」です。この経験データは事実誤認と判定され、即座にブロックされました。

【レビュー対象候補エンティティ】──▶ コードの痕跡を抽出: "FastScrollBar", "attachToQBListView"

│

▼ Code Explorer によるソースコードの特定検索

[QQBrowser ソースコードライブラリ] ──▶ クラス"FastScrollBar"に一致 (収束成功)

│

▼ メンバ関数レベルでの事実検証

発見：このクラスには attachToRecyclerView() と attach() の 2 つしかメソッドが存在しない。

attachToQBListView() は存在しない。

(正しいメソッドは FastScrollBarCompat.attachToQBRecyclerView() に属する)

│

▼

[ S1_FACTUAL_ERROR 検知] この経験がデータベースに記録されれば、エージェントはリスト関連の場面で指示に従って存在しないメソッドを呼び出そうとし、コンパイルエラーが発生します。さらに厄介なのは、エージェントが自分の理解不足を疑い、経験自体の問題を疑わずに、試行錯誤の悪循環に陥ってしまう点です。

6.3 Dedup：厳格さを優先し、橋渡し的な統合は禁止

Dedup（重複排除）の役割は、候補となる経験セット内で重複を検出し、その後の処理における冗長な判断を減らすことです。この層で最も懸念されるリスクは「重複を見逃すこと」ではなく、「誤って重複と判定すること」、つまり本来独立して保持すべき 2 つの経験を誤って統合し、境界情報が汚染されてしまう点です。

そのため、方針は明確に「厳格さを優先する」ことにしています。以下の厳格な拒否ルールを設けます。

• When（適用条件）が異なる場合は統合不可：結論が似ていても、適用シーンが異なれば別々の経験として扱う。
• 主たる結論のタイプが異なる場合は統合不可：操作の提案、リスク回避策、トラブルシューティング方法などは混同してはならない。
• 局部的なサブメカニズムに関する経験と、システム全体に関する経験は統合不可：粒度が異なり、互いに代替できないため。
• 同じ技術的事実でも用途が異なる場合は統合不可：例えばある API を「性能最適化」と「互換性対応」の両方で使用する場合、「同じ API に関わるから」という理由だけで統合してはならない。

最も重要なのは「橋渡し的な統合（ブリッジ型マージ）の禁止」です。A と B が処理結果で重なり、B と C も関連しているとしても、それをもって A と C が重複であると推論することはできません。経験の境界は適用シーンの制約条件によって定義されるものであり、意味が似ているからといって経験が等価であるわけではありません。一度橋渡し的な統合を行って境界の異なる経験を連結・統合してしまうと、その境界情報は二度と復元できないまま失われてしまいます。

260 件の経験、4 つのグループを対象とした評価では、全体の F1 スコアは 71.79% でした。しかし、より注目すべき指標は「厳密な重複」のケースにおける性能です。What（内容）と When（条件）が完全に一致する経験については、Recall が 91.67% に達しています。これは、最も核心的な重複排除の目標において、この戦略が有効であることを示しています。

見落としが発生したのは主に、What が「包含」または「部分的に重なる」、When が「異なる」または「部分的に重なる」といった境界が曖昧な組み合わせの場合です。こうしたケースでは、戦略はあえて差異を保護し、安易な統合を行わない方向で動作しています。

值得注意的是，这 260 条经验是分 4 批独立进行的，batch 之间表现差异明显。最极端的是 batch_004，仅识别出 6 个人工正例中的 1 个——该 batch 的正例全部落在非"双强一致"的组合上。这说明去重 prompt 对边界的敏感度在输入特征分布变化时仍有波动。

值得注意的是、この 260 件の経験は 4 つのバッチに分けて独立して評価されましたが、バッチ間での性能差は顕著でした。最も極端なケースは batch_004 で、人工的に作成された正例 6 件中わずか 1 件しか検出できませんでした。このバッチに含まれる正例はすべて、「二つの強一致条件」を満たさない組み合わせに属していました。これは、重複排除のプロンプトが、入力特徴の分布が変化した際に境界に対する感度にばらつきが生じることを示しています。

6.4 Merge：唯一の目標を最優先し、歴史的な境界を守る

Merge（統合）は、経験データベースへの登録前の最終チェックです。新しい経験と既存の履歴データベースとの関係を判断し、以下の 4 つのアクションのいずれかを実行します。

• create：データベース内に同種の対象となる経験が存在しない場合、新規に登録する。
• update：既存の経験と同じ方向性を持つが、実質的な新情報を含む場合は、統合して更新する。

新経験と既存の核心結論が互いに代替可能な場合は「スキップ」、直接衝突する場合は「コントラディクト」として人工判断を要請します。

戦略には三つの主要な軸があります。

第一に、判定目標を最優先で決定することです。まず歴史データベースから新経験に関連するサブセットを呼び出し、「唯一最適な経験目標」が存在するかを確認します。もし該当しない場合（例えば新経験が複数の歴史経験と関連しているが、いずれも同一の維持可能な経験には属さない場合）は、デフォルトで「新規作成（Create）」へ回帰させます。このルールにより、「無理なマッチング」を根本的に防止し、不完全な一致しかできない歴史経験を強引に更新目標として押し付けることで境界線が汚染されるのを防ぎます。

第二に、更新（Update）には自己検査が必要です。すべての更新処理に対して内部品質チェックを追加します。具体的には、統合後の「When（いつ）」が過度に一般化して元の経験のシナリオ制約を失っていないか、「What（何を）」が最も具体的かつ安全で実行可能なアクション提案を残しているか、「Why（なぜ）」が核心メカニズムを保っているか、そして元々の経験の根拠がない新たな結論を導入していないかを検証します。現在、最も顕著な課題は「更新過剰」です。Recall（再現率）は 96.30% と高いものの、Precision（適合率）は 78.79% に留まっています。これは、更新すべき対象の大部分が検出されている一方で、モデルに明らかな「積極的な統合傾向」があり、本来は新規作成すべき内容まで更新と判定してしまっていることを意味します。

第三に、コントラディクト（矛盾）は自動的に見過ごしたり、自動で決断したりしません。矛盾とは、チームの新しい認知と古い認知が不一致を示している状態であり、それ自体が貴重なシグナルです。システムは単にこれをマークするだけで、具体的な意思決定は人工判断のプロセスへ委ねます。

六回の実験と 157 の統計サンプルにおいて、全体の F1 スコアは 94.27% を達成しました。新規作成（Create）が最も安定した主要カテゴリで F1 は 96.46%、「唯一の目標がない場合は作成する」という判断ロジックはすでに信頼性が高いと言えます。スキップ（Skip）の適合率は 100% に達しており、モデルが「スキップ」と判定すればほぼ正解ですが、再現率は 85.71% とまだ低く、一部の真のスキップケースが更新や新規作成へ誤って振り分けられています。更新（Update）は改善余地が最も大きいカテゴリです。

七、運用開始後

完全な三層ガバナンス・ファネルを経た結果、初期の抽出ゴミ率 90% から、ガバナンス後の有効率 95%、そして最終的な入库率平均 80% へと改善しました。多くの会話サマリーや汎用的なアドバイス、一時的なケース、文脈に欠ける断片的な内容は、抽出段階で阻止され、候補経験は逐層のフィルタリングと統合によってさらに絞り込まれました。

現在、チーム経験システムは QQ ブラウザチームの 6 つのリポジトリで定常運用されており、50 名以上の開発者の日常開発セッションをカバーしています。これまでに 1,236 回の独立した対話を収集し、そこから 1,022 件の候補経験を抽出。三層ガバナンスを経て最終的に 789 件の高信頼度経験が登録されました。パイプラインはすでに 30 回以上安定して稼働しています。

7.1 システムの完全な運用ライフサイクル

2026/05/27 の実際の Pipeline 実行事例を通じて、システムがどのように動作するかを見てみましょう。

今回の処理では、元の会話記録 39 件に対し、初期段階で候補経験 34 件を抽出。レビュー後に 3 件がブロックされ、歴史経験庫との統合で 1 件が処理され、最終的に登録されたのは 30 件でした。

「ForbiddenController に新しい無効化機能を追加するには、3 つの場所を同時に修正する必要がある」という候補経験が審査で却下されました。その理由は、「単に修正箇所のリストを示し、どこをどう直せばいいかを読者に伝えるだけでは不十分だから」です。これは、レビュー・ゲートウェイが「技術的事実」の境界線を正確に見極め、適切な判断を下したことを裏付けています。

一方、「Chromium のソースコード層からは hooks 層を経由してのみ UBA 機能をアクセスできる」という候補経験は、目に見えにくい技術的事実の結果を説明しているため、審査を通過し、知識ベースに登録されました。

その後の Agent と協働する開発シーンでは、TDev を駆使して要件実装のフローを回す際、会話内の特定のフェーズ（探索段階）で自動的に過去の経験を引き出す試みがトリガーされます。

7.2 検索結果の活用：既存インフラの再利用

この検索機能において、私たちは新たに仕組みを作るのではなく、社内に既に存在する知識基盤を深く活用しました。

• 保存と登録: 3 段階のガバナンスを通過した経験は、自動的に IWIKI の経験スペースへ書き込まれます。
• 自動インデックス化: Knot 知識ベースシステムが IWIKI の経験コンテンツをリアルタイムで監視し、自動的にインデックスを作成。ベクトルとキーワード索引を生成します。
• MCP 検索ブリッジ: Knot は標準的な MCP プロトコルサービスを提供します。Agent はセッション中に自動的に Knot の MCP インターフェースを呼び出し、関連する経験を検索してコンテキストに注入します。
• 監視バイパス: 検索フローにはレポート用のバイパスを追加し、検索の成功率和件数をリアルタイムで記録しています。

最新の 125 件の実際の開発における検索結果の分析では、リクエストレベルでの検索成功率は 68.8%、未ヒット（no_hit）はわずか 4.8% でした。平均して 1 回の検索ごとに 2.4 件の経験が注入され、平均検索時間は 1,299 ミリ秒です。

このアーキテクチャにより、チームは「経験の精製とガバナンス」という最も重要な課題に集中することが可能になりました。

八、再利用可能な 4 つのメソドロジー

振り返ってみると、価値があるのは特定のプロンプトの書き方やパラメータの調整方法ではなく、数々の失敗から収束した 4 つのエンジニアリング原則です。

第一条：先定义资产边界，再进行自动化沉淀。

初版经验告诉我们最核心的一课是：若不明确“什么算作经验”就直接启动自动提取，系统会将对话摘要、通用建议甚至一次性案例全部塞入数据库。经验系统的核心不在于“多提取”，而在于“高置信度地沉淀”。在工程化落地之前，必须厘清三个问题：什么是经验？什么不是经验？判断标准是什么？

第二条：实施分层治理，切勿试图用一个 Prompt 解决所有问题。

Review（审查）负责拦截垃圾数据，Dedup（去重）负责候选集内的重复项清理，Merge（合并）则专注于历史库的治理。每一层的目标、指标和 Prompt 设计都截然不同。若将它们揉在一起，各层目标便会相互掣肘。使用多个针对性模型各自完成特定任务，远比依赖一个通用大模型一次性全搞定更为可靠。

第三条：默认策略需按业务风险分别设计，不存在统一答案。

在 Review 环节，默认应保留（误删一条高价值经验的代价远高于放行两条垃圾）；在 Dedup 环节，宁可严勿宽（合并错误导致的边界污染是不可逆的）；在 Merge 环节，必须保护历史边界（已有的经验是已验证资产，新经验若要修改它，需跨过更高的门槛）。“宁可错杀”与“宁可放过”的方向在各层截然不同。

第四条：Prompt 优化应从错例中抽象规则，而非凭感觉调整。

我们的 Prompt 迭代并非“效果不好就改一下试试”，而是遵循固定流程：收集错例 → 识别误判类型 → 抽象为可操作规则 → 多轮实验验证效果 → 判断规则是否带来正向收益。同时，利用固定评测集防止数据泄露和过拟合。整个链路是工程化的，而非依赖个人手艺。

结语

经验系统从 0 到 1 的建设已跑通——链路运转正常，三层治理上线，召回机制也在发挥作用。但这仅仅是起点。真正让经验系统从“能用”迈向“可靠”，还有三个环环相扣的方向亟待突破：

经验质量（生产阶段）：当前三层治理生效后，垃圾率已降至约 5%。但事实性错误仍难以仅凭纯文本识别；源码探索目前仅覆盖部分场景；超出“三镜头”之外的边界经验类型尚未被充分识别；评测集规模有限，长尾和冷门主题覆盖不全，Prompt 迭代的边际收益正在收窄。

使用效率（召回阶段）：经验虽能被召回并注入上下文，但命中不等于采纳——目前缺乏观测 Agent 是否真正依据经验改变行为的手段；召回侧的判定目标过于粗放，在相似主题下容易出现“召回了却用不上”的情况。

管理维护（生命周期）：长期未命中、未被采纳的经验缺乏自动淘汰机制，导致库随时间静默膨胀；项目演进时（如模块重构、能力下线），历史经验可能集体失效，目前尚无自动识别“需要复核”的能力。

这三者构成闭环：生产决定基线 → 使用暴露问题 → 维护反哺生产。任一环不闭合，经验系统就会从资产退化为噪声。

最后想说一句：经验系统的本质并非技术系统，而是团队认知能力的工程化管道。过去，经验在人脑中，产出在文档里；现在，经验产生于人与 AI 的对话过程，需要一套管道来捕获、提纯和分发。一旦管道建成，团队便不再依赖“谁在那个时间段在做什么”来传承知识——AI 每次进入项目，都能带着“这个团队积累了什么、在什么场景下该怎么做”的语境。

QQ 浏览器平台技术团队

我们是腾讯 CSIG 旗下负责 QQ 浏览器平台研发的核心技术团队。致力于为超 4 亿用户打造极速、智能、全平台的浏览体验，产品覆盖 Android、iOS、鸿蒙、Windows、macOS 全终端。

团队深耕浏览器底层技术十余年，当前正深度参与 AI 在浏览器的能力落地，持续探索大模型时代技术的新边界。期待与更多同行切磋交流，共同成长。

微信で開くにはこちら