Specialists

Ongrid は 5 つの specialist ペルソナ を同梱します。各々がホスト / クラスタ診断の狭いスライスを所有し、フォーカスした tool bag を持ち、ピアの 領域に属するタスクを明示的に拒否します。coordinator はリクエストの形に 基づいて dispatch し、specialist の when_to_use ブロックが coordinator の LLM に「これが適合する」と伝えます。

ペルソナ	所有	所有しないもの
specialist-compute	CPU、メモリ、load、プロセス、OOM、スケジューラー	ディスク、ネットワーク、サービス再起動
specialist-disk	ファイルシステム、du / find / stat、inode	ネットワーク、プロセス、業務ログ
specialist-network	OVS、netfilter、netns、conntrack、bpf、ルート	ファイルシステム、プロセス
specialist-ops	サービス起動 / 停止 / 再起動、journalctl、パッケージ	クラスタトレンド、ネットワーク内部
specialist-sre	ゴールデン 4 シグナル、SLO、エラーバジェット、トリアージ	単一ホスト bash、深い RCA

なぜ細かく分けるか

tool bag を絞る = システムプロンプトを絞る = トークンあたりの推論が 深まる、です。8 ツールを持つ specialist-network ワーカーは、iptables / nft について、60 ツールの中に たまたま iptables があるだけの coordinator より強い回答を返します。ペルソナの壁は、各ドメインがドメイン特化の KB ヒントをシステムプロンプトに持つことも可能にします。

KB 優先の規約

5 つの specialist すべてが 同じ step 0 から始めます：問題の自然言語 記述で query_knowledge を 1 回呼ぶ。トップ結果のスコアが ≥ 0.6 ならば プレイブックに従い、回答末尾に (参考 KB: <title>) を付けます。これは ランタイムではなくペルソナプロンプトで強制されますが、プロンプトが直接的 なので強いモデルは一貫して従います。

なぜ統一の step 0 か：

• vault はチーム特化のプレイブック（推奨コマンド、既知の罠、エスカレーション パス）を持ちます。あなたの フリートに対してはモデルの一般知識を 上回ります。
• 即興ではなく既知の良いプランの周りに worker の初回ターンを錨で固定します。
• 引用 (参考 KB: …) が出所を監査可能にします。

vault のデフォルト内容と自前のプレイブックの追加方法は ナレッジベース を参照してください。

specialist-compute —— CPU / メモリ / load / プロセス

フロントマターのハイライト：

name: specialist-compute
permission_mode: read-only
max_turns: 15
tools:
  - query_knowledge
  - get_host_load
  - get_host_processes
  - get_edge_summary
  - rank_edges
  - find_outlier_edges
  - query_promql
  - host_bash

coordinator がこれを選ぶとき

• 「node-X で CPU 張り付き、誰が食ってる？」
• 「load が跳ねてるけど CPU はアイドル —— 何がブロックされてる？」
• 「プロセスのメモリ増加 / OOM フォレンジック。」
• 「VM steal time —— noisy neighbor を見てる？」

ペルソナに焼き込まれたレシピ

• load avg 高 + CPU% 低 → D-state プロセスを探す （host_bash "ps -eo stat,pid,cmd | awk '$1 ~ /D/'"）。恐らく IO / ネットワーク待ち —— coordinator に specialist-disk か specialist-network への redispatch を伝える。
• CPU% 高 → top プロセス、user vs system time、vmstat st カラムで steal を見る。
• mem_used_pct 高 → cached / buffers / swap の node_memory_*、OOM ヒットの dmesg | grep -i 'oom-killer'、PID + 名前付きで単一プロセス RSS の外れ値。

拒否（coordinator に redispatch を伝える）

• 「nginx を再起動すべき？」→ specialist-ops（再起動は host_restart_service 経由で reviewer を 通るため）。
• 「ディスクが埋まる」→ specialist-disk。
• 「ネットワークパケットがドロップ」→ specialist-network。

specialist-disk —— ファイルシステム / 容量

フロントマターのハイライト：

name: specialist-disk
permission_mode: read-only
max_turns: 15
tools:
  - query_knowledge
  - host_find_large_files
  - host_du_summary
  - host_stat_file
  - host_bash
  - query_promql
  - get_host_load

4 ステップレシピ

1. マクロ確認：get_host_load で disk_used_pct + query_promql で node_filesystem_* トレンド。
2. レイヤー深掘り：host_du_summary(paths=["/", "/var", "/opt", "/home", "/tmp"], depth=1)。
3. ファイル特定：host_find_large_files(paths=[最大の top-level], top_n=20)。
4. 必要なら inode チェック：host_bash "df -i"。

ペルソナが拒否するアンチパターン

• パスごとの単一パス呼び出し（呼び出しごとに 配列 で 4-8 パスを使う —— はるかに速い）。
• /proc /sys /dev での実行 —— サンドボックスが拒否、ペルソナはそれを 訊かないことを知っている。
• delete / mv / rm —— 読み取り専用。

specialist-network —— パケット / netns / iptables / OVS

フロントマターのハイライト：

name: specialist-network
permission_mode: read-only
max_turns: 15
tools:
  - query_knowledge
  - host_bash
  - host_probe_http
  - host_probe_dns
  - host_probe_tcp
  - host_netns_inspect
  - query_promql
  - get_host_load

レシピ

• トポロジー優先。 ip -j addr show + host_netns_inspect で インターフェイスと namespace のレイアウトを理解。
• リンク状態。 ethtool -i ethX でドライバ + 速度、ss -tnp で 接続。
• NAT / ファイアウォール。 nft list ruleset、iptables -L -n、 conntrack -S。
• OVS。 ovs-vsctl show、ovs-ofctl dump-flows br0。
• eBPF。 bpftool prog show、bpftool net show。
• 接続性プローブ。 host_probe_tcp、host_probe_http、 host_probe_dns。

各 host_bash 呼び出しは cmdpolicy の allowlist を持ちます —— OVS / nft / conntrack / bpftool / ethtool / ip netns の cmdpolicy エントリは Layer-1 ネットワーク調査 を 参照。

出力規律

3 行：现象（症状：パケットドロップ / 高 RTT / NAT テーブル満杯 / フローテーブル空 / ルート誤り）、根因（判断 + 主要証拠）、下一步 （推奨される次のアクション：サービス再起動、ルート更新、ルール追加）。 生の ovs-ofctl ダンプはなし —— coordinator は読みません。

specialist-ops —— サービスと運用

これが 変更を伴う specialist です。フロントマターのハイライト：

name: specialist-ops
permission_mode: read-only
max_turns: 15
tools:
  - query_knowledge
  - host_bash
  - get_host_processes
  - get_host_load
  - host_restart_service   # mutating; gated by ReviewGate
  - query_promql
  - query_logql
  - get_edge_summary

特殊な点

• host_restart_service を持ち、これは Class: "write" です。呼ぶたびに ReviewGate デコレーター が発動：ゲートが reviewer worker を spawn し、承認された判断のみが実際に何かを再起動 します。
• host_bash systemctl restart でゲートを迂回することはできません —— どのエージェントが発行しようと、edge cmdpolicy が変更を伴う systemctl サブコマンドを拒否します。

coordinator がこれを選ぶとき

• サービス固有のステータス / ログ / 再起動（nginx、mysql、自前 プロセス）。
• systemd unit status、journalctl -u のエラー。
• 最近の再起動回数、OOM 相関。
• cron / timer スケジュールチェック。
• パッケージの broken 状態（dpkg / apt / yum）。
• 「リーク解消のため X を再起動すべき？」—— ops が提案するペルソナで、 reviewer がゲート。

拒否

• クラスタトレンド / SLO 判断 → specialist-sre。
• ネットワーク内部 → specialist-network。
• 深いファイルレベルディスク分析 → specialist-disk。

specialist-sre —— ゴールデン 4 シグナル / トリアージ

「システムは健康か」/「どのインシデントが最重要か」用のペルソナ。 フロントマターのハイライト：

name: specialist-sre
permission_mode: read-only
max_turns: 15
tools:
  - query_knowledge
  - correlate_incident
  - get_active_incidents
  - get_incident_detail
  - get_edge_summary
  - query_promql
  - query_logql
  - find_outlier_edges
  - rank_edges
  - get_host_load

ワーキングスタイル

1. インシデントリスト優先。 get_active_incidents —— 現在何が発火 していて、どの重大度か。
2. 単一ホストメトリクスではなくトレンド。 ベースラインに対する 1h / 24h ウィンドウで query_promql。
3. 外れ値ホストを見つける。 PromQL で手書き IQR ではなく find_outlier_edges / rank_edges。
4. ゴールデン 4 シグナルで話す。 latency (p50/p95/p99) / エラー率 / トラフィック / 飽和度 —— 各々を「baseline → 現在 → 逸脱方向」で。
5. 優先度判断。 P0（ユーザー影響、悪化中）、P1（ユーザー影響、安定）、 P2（内部 / トレンド）、P3（ノイズ / 偽陽性）。
6. 下方へ delegate。 ディスク疑い → coordinator に specialist-disk への dispatch を伝える。ネットワーク疑い → specialist-network。 自前で深掘りはしない。

なぜ SRE は RCA をしないのか

完全な根本原因帰属が必要なインシデントには、coordinator は incident-investigator を選び、 specialist-sre ではありません。SRE ペルソナは「payments で本物の P1 飽和問題；incident_id=1234 で incident-investigator の dispatch を推奨」 で止まります。investigator が因果連鎖を歩き、SRE は歩く価値があるかを 判断します。

coordinator の選び方

カタログは buildAgentCatalog が coordinator のシステムプロンプトに描画します。ペルソナごとに以下を 出します：

• name（subagent_type の値）。
• ペルソナの description。
• when_to_use の最初の非空白行。

なのでシステムプロンプトを読む LLM はこういうものを見ます：

## 可用的 specialist 助理（AgentTool 的 subagent_type）

- `specialist-compute` — 计算专家——CPU / 内存 / load / 进程调度…
- `specialist-disk` — 文件系统 / 磁盘容量专家——du / find / stat / inode…
- `specialist-network` — 网络问题专家——OVS / netfilter / netns…
- `specialist-ops` — 运维 / 服务运营专家——服务状态 / 启停重启…
- `specialist-sre` — SRE / 可观测性专家——告警响应 / 黄金四信号 / SLO…
- `incident-investigator` — 告警根因诊断 worker…

reviewer と default は意図的に除外されます —— 前者は ReviewGate の予約、後者は仮想最上位 coordinator ペルソナで、列挙すれば coordinator が自身を再帰的に spawn できてしまいます。

クロスハンドオフパターン

回答が「これは自分のドメインじゃない」のとき：

Specialist	よくあるハンドオフ
compute → disk	IO 待ちの D-state プロセス
compute → net	ネットワーク（ソケット、recv）ブロック中の D-state プロセス
compute → ops	「プロセスがリーク；サービス再起動を推奨」
disk → ops	「ログが膨張；logrotate を厳しくすることを推奨」
net → ops	「iptables ルールがリークを修正；安全のためサービス再起動を推奨」
sre → investigator	「P1 飽和、本物、RCA が必要」
sre → compute	「飽和アラーム —— CPU/mem を深掘り」

ハンドオフは 言葉 です（specialist は返答で「Y のため specialist-X の dispatch を推奨」と言う）、ツール呼び出しではありません。coordinator が 推奨を読んで次の worker を dispatch します。specialist は worker を spawn できません —— エージェント概要 を参照。

specialist ペルソナのチューニング

フォークでよくある編集：

• Tool bag： 自社内の BaseTool（例：query_clickhouse）を該当 ペルソナの tools: リストに追加。worker フィルターはペルソナの ホワイトリストを信頼します。
• max_turns： デフォルト 15 は寛大。コスト感応性の specialist は 10 に引き締めます。
• ペルソナ本文： チーム好みのコマンド優先順位（「このフリートでは journalctl --since '1h ago' より --since '5m ago' を先に」）を追加。
• when_to_use： coordinator にどれくらいの頻度でこのペルソナを 選ばせたいかに応じて引き締めるか広げます。

name を変えないでください —— カタログと AgentTool は正確な name で worker を引きます。カスタムエージェント を 参照。