Search Layer v2.2 — 意図感知多源検索プロトコル

四つのソースが同等のレベルです：Brave (web_search) + Exa + Tavily + Grok。意図に応じて自動的に戦略を選択し、重みを調整し、合成を行います。

実行フロー

ユーザーのクエリ
    ↓
[Phase 1] 意図分類 → 検索戦略の決定
    ↓
[Phase 2] クエリ分解 & 拡張 → サブクエリの生成
    ↓
[Phase 3] 多源並列検索 → Brave + search.py (Exa + Tavily + Grok)
    ↓
[Phase 4] 結果の統合 & ソート → 重複排除 + 意図による重み付けスコアリング
    ↓
[Phase 5] 知識合成 → 構造化された出力

Phase 1: 意図分類

検索リクエストを受け取った後、まず意図のタイプを判断し、次に検索戦略を決定します。ユーザーにどのモードを使用するかを尋ねないでください。

詳細な分類ガイドは references/intent-guide.md を参照してください。

判断ルール：

1. クエリ内の信号語をスキャンします
2. 複数のタイプが一致する場合は、最も具体的なものを選択します
3. 判断できない場合は、デフォルトで exploratory を使用します

Phase 2: クエリ分解 & 拡張

意図のタイプに基づいて、ユーザーのクエリをサブクエリのセットに拡張します。

共通ルール

• 技術的な同義語の自動拡張：k8s→Kubernetes, JS→JavaScript, Go→Golang, Postgres→PostgreSQL
• 中国語の技術クエリ：英語のバリアントも生成します（例： "Rust 异步编程" → 追加で "Rust async programming" を検索）

意図による拡張

Phase 3: 多源並列検索

Step 1: Brave（すべてのモード）

各サブクエリに対して web_search を呼び出します。意図に freshness の要件がある場合は、freshness パラメータを渡します。

web_search(query="Deno 2.0 latest 2026", freshness="pw")

Step 2: Exa + Tavily + Grok（Deep / Answer モード）

サブクエリに対して search.py を呼び出し、意図と freshness を渡します。

python3 /home/node/.openclaw/workspace/skills/search-layer/scripts/search.py \
  --queries "子查询1" "子查询2" "子查询3" \
  --mode deep \
  --intent status \
  --freshness pw \
  --num 5

各モードのソース参加マトリックス： | 模式 | Exa | Tavily | Grok | 说明 | |------|-----|--------|------|------| | fast | ✅ | ❌ | fallback | Exa を優先します。Exa のキーがない場合は Grok を使用します | | deep | ✅ | ✅ | ✅ | 3つのソースを並行して実行します | | answer | ❌ | ✅ | ❌ | Tavily のみ（AI answer を含む） |

パラメータの説明： | 参数 | 说明 | |------|------| | --queries | 複数のサブクエリを並行して実行します（位置パラメータを使用して単一のクエリを渡すこともできます） | | --mode | fast / deep / answer | | --intent | 意図のタイプ。スコアリングの重みに影響します（渡さない場合はスコアリングされず、v1 と同じ動作になります） | | --freshness | pd(24h) / pw(週) / pm(月) / py(年) | | --domain-boost | カンマ区切りのドメイン。一致する結果の信頼性スコアに +0.2 します | | --num | ソースごと、クエリごとの結果数 |

Grok ソースの説明：

• completions API を介して Grok モデル（grok-4.1-fast）を呼び出し、そのリアルタイムの知識を利用して構造化された検索結果を返します
• 時間に敏感なクエリを自動的に検出し、現在の時間のコンテキストを注入します
• deep モードで Exa、Tavily と並行して実行します
• ~/.openclaw/credentials/search.json で Grok の apiUrl、apiKey、model を構成する必要があります（または、環境変数 GROK_API_URL、GROK_API_KEY、GROK_MODEL を使用します）
• Grok の構成が欠落している場合は、自動的に Exa + Tavily のデュアルソースにダウングレードします

Step 3: 統合

Brave の結果と search.py の出力を統合します。canonical URL で重複排除し、ソースをマークします。

search.py が score フィールドを返した場合は、それを使用してソートします。Brave の結果に score がない場合は、同じ意図の重み付け式を使用して補完します。

Phase 3.5: 引用追跡（Thread Pulling）

検索結果に GitHub issue/PR リンクが含まれており、意図が Status または Exploratory の場合、自動的に引用追跡がトリガーされます。

自動トリガー条件

• 意図が status または exploratory である
• 検索結果に github.com/.../issues/ または github.com/.../pull/ URL が含まれている

方式 1: search.py --extract-refs（バッチ）

検索結果から直接引用グラフを抽出します。追加の呼び出しは不要です。

python3 search.py "OpenClaw config validation bug" --mode deep --intent status --extract-refs

出力には refs フィールドが追加され、各結果 URL の引用リストが含まれます。

検索をスキップして、既知の URL から直接引用を抽出することもできます。

python3 search.py --extract-refs-urls "https://github.com/owner/repo/issues/123" "https://github.com/owner/repo/issues/456"

方式 2: fetch-thread（単一 URL のディープクロール）

単一の URL に対して完全なディスカッションフロー + 構造化された引用を取得します。

python3 fetch_thread.py "https://github.com/owner/repo/issues/123" --format json
python3 fetch_thread.py "https://github.com/owner/repo/issues/123" --format markdown
python3 fetch_thread.py "https://github.com/owner/repo/issues/123" --extract-refs-only

GitHub シナリオ（issue/PR）：API を介して本文 + すべての comments + timeline イベント（cross-references、commits）を取得し、以下を抽出します。

• Issue/PR 引用（#123、owner/repo#123）
• Duplicate マーク
• Commit 引用
• 関連する PR/issue（timeline cross-references）
• 外部 URL

一般的な web シナリオ：web fetch + 正規表現による引用リンクの抽出。

Agent 実行フロー

Step 1: search-layer 検索 → 初期結果の取得
Step 2: search.py --extract-refs または fetch-thread → 手がかりグラフの抽出
Step 3: Agent による高価値な手がかりの絞り込み（LLM が追跡する価値のあるものを判断）
Step 4: fetch-thread による各高価値な手がかりのディープクロール
Step 5: 情報が閉じるか、深さの制限に達するまで Step 2-4 を繰り返します（推奨 max_depth=3）

Phase 4: 結果のソート

スコアリング式

score = w_keyword × keyword_match + w_freshness × freshness_score + w_authority × authority_score

重みは意図によって決定されます（Phase 1 の表を参照）。各項目の内訳：

• keyword_match (0-1)：タイトル+概要におけるクエリ語のカバー率
• freshness_score (0-1)：公開日に基づき、新しいほど高い（日付がない場合は=0.5）
• authority_score (0-1)：ドメインの信頼性レベルに基づく
  • Tier 1 (1.0): github.com, stackoverflow.com, 公式ドキュメントサイト
  • Tier 2 (0.8): HN, dev.to, 著名な技術ブログ
  • Tier 3 (0.6): Medium, 掘金, InfoQ
  • Tier 4 (0.4): その他

完全なドメインスコアリングテーブルは references/authority-domains.json を参照してください。

Domain Boost

--domain-boost パラメータを使用して、重み付けするドメインを手動で指定します（一致する結果の信頼性スコアに +0.2 します）。

search.py "query" --mode deep --intent tutorial --domain-boost dev.to,freecodecamp.org

推奨される組み合わせ：

• Tutorial → dev.to, freecodecamp.org, realpython.com, baeldung.com
• Resource → github.com
• News → techcrunch.com, arstechnica.com, theverge.com

Phase 5: 知識合成

結果の数に応じて合成戦略を選択します。

小さな結果セット（≤5 件）

各項目を個別に表示し、各項目にソースラベルとスコアを付けます。

1. [Title](url) — snippet... `[brave, exa]` ⭐0.85
2. [Title](url) — snippet... `[tavily]` ⭐0.72

中程度の結果セット（5〜15 件）

トピックごとにクラスタリングし、各グループの概要を示します。

**トピック A: [説明]**
- [結果1] — 要点... `[source]`
- [結果2] — 要点... `[source]`

**トピック B: [説明]**
- [結果3] — 要点... `[source]`

大きな結果セット（15件以上）

高レベルの概要 + 上位5件 + 詳細なヒント：

[主要な発