Specialists

Ongrid liefert fünf Specialist-Personas. Jede besitzt einen schmalen Anteil an Host- / Cluster-Diagnose, hat eine fokussierte Tool-Tasche und lehnt explizit Aufgaben ab, die einem Peer gehören. Der coordinator dispatcht basierend auf der Anfrageform; der when_to_use-Block des Specialists sagt dem LLM des coordinators, wann er die richtige Wahl ist.

Persona	Besitzt	Besitzt nicht
specialist-compute	CPU, Speicher, Last, Prozesse, OOM, Scheduler	Disk, Netzwerk, Dienst-Restart
specialist-disk	Dateisystem, du / find / stat, Inodes	Netzwerk, Prozesse, Geschäftslogs
specialist-network	OVS, netfilter, netns, conntrack, bpf, Routen	Dateisystem, Prozesse
specialist-ops	Dienst Start/Stop/Restart, journalctl, Pakete	Cluster-Trends, Netzwerk-Interna
specialist-sre	Goldene Vier Signale, SLOs, Error Budgets, Triage	Single-Host-bash, tiefes RCA

Warum feinkörnig aufteilen

Engere Tool-Taschen = engerer System-Prompt = tieferes Reasoning pro Token. Ein specialist-network-Worker mit 8 Tools gibt stärkere Antworten zu iptables / nft als ein coordinator mit 60 Tools, der zufällig iptables darunter hat. Die Persona-Wände lassen außerdem jede Domain domänenspezifische KB-Hints in ihrem System-Prompt tragen.

Die KB-First-Konvention

Alle fünf Specialists beginnen mit dem gleichen Schritt 0: rufe query_knowledge einmal mit einer natursprachlichen Beschreibung des Problems auf. Wenn das Top-Ergebnis ≥ 0,6 erreicht, folge dem Playbook und beende die Antwort mit (参考 KB: <title>). Dies wird durch den Persona-Prompt erzwungen, nicht durch die Runtime — aber die Prompts sind direkt genug, dass starke Modelle konsistent folgen.

Warum ein einheitlicher Schritt 0:

• Der Vault trägt teamspezifische Playbooks (bevorzugte Befehle, bekannte Fallen, Eskalationspfade). Sie schlagen das allgemeine Wissen des Modells für Ihre Flotte.
• Es verankert den ersten Turn des Workers um einen bekanntermaßen guten Plan, anstatt ihn improvisieren zu lassen.
• Die Zitierung (参考 KB: …) macht die Herkunft auditierbar.

Siehe Wissensbasis für den Standardinhalt des Vaults und wie Sie eigene Playbooks hinzufügen.

specialist-compute — CPU / Speicher / Last / Prozesse

Frontmatter-Highlights:

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

Wann der Coordinator ihn wählt

• „CPU pegged on node-X, who's eating it?"
• „Load spiking but CPU idle — what's blocked?"
• „Process memory growth / OOM forensics."
• „VM steal time — am I seeing noisy neighbor?"

Die in die Persona eingebackenen Rezepte

• load avg high + CPU% low → suche nach D-State-Prozessen (host_bash "ps -eo stat,pid,cmd | awk '$1 ~ /D/'"). Wahrscheinlich IO / Netzwerk-Wait — sage dem coordinator, specialist-disk oder specialist-network zu dispatchen.
• CPU% high → Top-Prozesse, User vs. System-Zeit, vmstat st-Spalte für Steal.
• mem_used_pct high → node_memory_* für Cached / Buffers / Swap, dmesg | grep -i 'oom-killer' für OOM-Treffer, Single-Process-RSS-Ausreißer mit PID + Name.

Lehnt ab (sagt dem Coordinator, neu zu dispatchen)

• „Should we restart nginx?" → specialist-ops (weil Restart durch host_restart_service und den reviewer geht).
• „Disk filling up" → specialist-disk.
• „Network packets dropping" → specialist-network.

specialist-disk — Dateisystem / Kapazität

Frontmatter-Highlights:

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

Das 4-Schritte-Rezept

1. Makro-Bestätigung: get_host_load für disk_used_pct + query_promql node_filesystem_* Trend.
2. Schicht-Drilldown: host_du_summary(paths=["/", "/var", "/opt", "/home", "/tmp"], depth=1).
3. Datei-Pinpoint: host_find_large_files(paths=[größter Top-Level], top_n=20).
4. Inode-Check bei Bedarf: host_bash "df -i".

Anti-Patterns, die die Persona ablehnt

• Per-Pfad-Single-Pfad-Aufrufe (verwenden Sie ein Array von 4-8 Pfaden pro Aufruf — viel schneller).
• Ausführen auf /proc /sys /dev — die Sandbox lehnt ab, die Persona weiß, nicht zu fragen.
• Jede Delete / mv / rm — Read-Only.

specialist-network — Pakete / netns / iptables / OVS

Frontmatter-Highlights:

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

Die Rezepte

• Topologie zuerst. ip -j addr show + host_netns_inspect, um Interface- und Namespace-Layout zu verstehen.
• Link-Status. ethtool -i ethX Treiber + Geschwindigkeit; ss -tnp für Verbindungen.
• NAT / Firewall. nft list ruleset, iptables -L -n, conntrack -S.
• OVS. ovs-vsctl show, ovs-ofctl dump-flows br0.
• eBPF. bpftool prog show, bpftool net show.
• Probes für Konnektivität. host_probe_tcp, host_probe_http, host_probe_dns.

Jeder host_bash-Aufruf trägt eine cmdpolicy-Allowlist — siehe Layer-1 Netzwerkforschung für die OVS / nft / conntrack / bpftool / ethtool / ip netns cmdpolicy-Einträge.

Ausgabedisziplin

Drei Zeilen: 现象 (Symptom: Paketverlust / hohe RTT / NAT-Tabelle voll / leere Flow-Tabelle / falsche Route), 根因 (Urteil + Schlüsselbelege), 下一步 (empfohlene nächste Aktion: Dienst neu starten, Route aktualisieren, Regel hinzufügen). Keine rohen ovs-ofctl-Dumps — der coordinator liest sie nicht.

specialist-ops — Dienste und Operations

Dies ist der mutierende Specialist. Frontmatter-Highlights:

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

Was speziell ist

• Er trägt host_restart_service, das Class: "write" ist. Jeder Aufruf löst den ReviewGate-Decorator aus: das Gate spawnt den reviewer-Worker; nur eine genehmigte Entscheidung startet tatsächlich etwas neu.
• Er kann das Gate nicht via host_bash systemctl restart umgehen — die Edge-cmdpolicy verweigert mutierende systemctl-Subbefehle unabhängig davon, welcher Agent den Befehl ausgegeben hat.

Wann der Coordinator ihn wählt

• Dienstspezifischer Status / Logs / Restart (nginx, mysql, eigener Prozess).
• systemd-Unit status, journalctl -u-Fehler.
• Kürzlicher Restart-Count, OOM-Korrelationen.
• cron / Timer-Schedule-Check.
• Paket-Broken-Zustand (dpkg / apt / yum).
• „Should we restart X to clear the leak?" — ops ist die Persona, die vorschlägt; der reviewer ist das Gate.

Lehnt ab

• Cluster-Trends / SLO-Urteil → specialist-sre.
• Netzwerk-Interna → specialist-network.
• Tiefe File-Level-Disk-Analyse → specialist-disk.

specialist-sre — Goldene Vier Signale / Triage

Die Persona für „ist das System gesund" / „welcher Incident zählt am meisten". Frontmatter-Highlights:

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

Arbeitsweise

1. Incident-Liste zuerst. get_active_incidents — was feuert derzeit und in welcher Severity.
2. Trends, nicht Single-Host-Metriken. query_promql über 1h / 24h Fenster verglichen mit Baseline.
3. Den Ausreißer-Host finden. find_outlier_edges / rank_edges statt handgerollter IQR in PromQL.
4. Goldene Vier Signale sprechen. Latenz (p50/p95/p99) / Fehlerrate / Traffic / Sättigung — jedes als „Baseline → aktuell → Abweichungsrichtung".
5. Prioritätsentscheidungen. P0 (Benutzerimpact, wird schlimmer), P1 (Benutzerimpact, stabil), P2 (intern / Trend), P3 (Rauschen / Fehlalarm).
6. Nach unten delegieren. Verdacht Disk → sage coordinator, specialist-disk zu dispatchen. Verdacht Netzwerk → specialist-network. Versucht nicht, das Deep-Dive selbst zu tun.

Warum SRE kein RCA macht

Für einen Incident, der vollständige Grundursachen-Attribution braucht, wählt der coordinator incident-investigator, nicht specialist-sre. Die SRE-Persona stoppt bei „das ist ein echtes P1-Sättigungsproblem auf payments; empfehle Dispatchen des incident-investigators mit incident_id=1234". Der investigator verfolgt die Kausalkette; der SRE beurteilt, ob es das Verfolgen wert ist.

Wie der Coordinator wählt

Der Katalog wird durch buildAgentCatalog in den System-Prompt des coordinators gerendert. Für jede Persona zeigt er:

• name (den subagent_type-Wert).
• Die description der Persona.
• Die erste nicht-leere Zeile von when_to_use.

Ein LLM, das den System-Prompt liest, sieht also etwas wie:

## 可用的 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 und default sind absichtlich ausgeschlossen — der erste ist dem ReviewGate vorbehalten; der zweite ist die virtuelle Top-Level-Coordinator-Persona und ihn aufzulisten würde dem coordinator erlauben, sich selbst rekursiv zu spawnen.

Cross-Handoff-Muster

Wenn die Antwort „das ist nicht meine Domain" lautet:

Specialist	Häufiger Handoff
compute → disk	D-State-Prozesse auf IO-Wait
compute → net	D-State-Prozesse blockiert auf Netzwerk (Sockets, recv)
compute → ops	„Prozess leakt; empfehle Dienst-Restart"
disk → ops	„Logs blasen sich auf; empfehle strengeren logrotate"
net → ops	„iptables-Regel behebt den Leak; empfehle Dienst-Restart zur Sicherheit"
sre → investigator	„P1-Sättigung, real, braucht RCA"
sre → compute	„Sättigungsalarm — CPU/mem drillen"

Der Handoff ist verbal (der Specialist sagt „建议派 specialist-X because Y" in seiner Antwort), kein Tool-Aufruf. Der coordinator liest die Empfehlung und dispatcht den nächsten Worker. Specialists können keine Workers spawnen — siehe Agents-Übersicht.

Specialist-Personas tunen

Häufige Edits in einem Fork:

• Tool-Tasche: fügen Sie ein hauseigenes BaseTool (z. B. query_clickhouse) der tools:-Liste der relevanten Persona hinzu. Der Worker-Filter vertraut der Persona-Whitelist.
• max_turns: der Default von 15 ist großzügig; verschärfen Sie auf 10 für kostensensitive Specialists.
• Persona-Body: fügen Sie die bevorzugten Befehlspräferenzen Ihres Teams hinzu („auf dieser Flotte, journalctl --since '5m ago' vor --since '1h ago'").
• when_to_use: verschärfen oder erweitern, wie oft der coordinator diese Persona wählen soll.

Ändern Sie nicht name — der Katalog und AgentTool schlagen Workers nach exaktem Namen nach. Siehe Benutzerdefinierte Agenten.