Specialists

Ongrid livre cinq personas specialist. Chacune possède une tranche étroite de diagnostic host / cluster, a un sac d'outils focalisé, et refuse explicitement les tâches qui reviennent à un pair. Le coordinator dispatche en fonction de la forme de la requête ; le bloc when_to_use du specialist dit au LLM du coordinator quand c'est la bonne adéquation.

Persona	Possède	Ne possède pas
specialist-compute	CPU, mémoire, load, processus, OOM, scheduler	Disque, réseau, redémarrage de service
specialist-disk	Filesystem, du / find / stat, inodes	Réseau, processus, logs métier
specialist-network	OVS, netfilter, netns, conntrack, bpf, routes	Filesystem, processus
specialist-ops	Démarrage/arrêt/redémarrage de service, journalctl, packages	Tendances cluster, internes réseau
specialist-sre	Golden four signals, SLOs, budgets d'erreur, triage	Bash mono-host, RCA profond

Pourquoi découper finement

Sacs d'outils plus serrés = system prompt plus serré = raisonnement plus profond par token. Un worker specialist-network avec 8 outils donne des réponses plus fortes sur iptables / nft qu'un coordinator avec 60 outils qui se trouve avoir iptables parmi eux. Les murs de persona laissent aussi chaque domaine porter des hints KB spécifiques au domaine dans son system prompt.

La convention KB-first

Les cinq specialists commencent par la même étape 0 : appeler query_knowledge une fois avec une description en langage naturel du problème. Si le top résultat score ≥ 0.6, suivre le playbook et terminer la réponse par (参考 KB: <title>). Ceci est imposé par le prompt de la persona, pas par le runtime — mais les prompts sont assez directs pour que les modèles forts suivent de façon cohérente.

Pourquoi une étape 0 uniforme :

• Le vault porte des playbooks spécifiques à l'équipe (commandes préférées, pièges connus, chemins d'escalade). Ils battent la connaissance générale du modèle pour votre flotte.
• Cela ancre le premier tour du worker autour d'un plan connu-bon plutôt que de le laisser improviser.
• La citation (参考 KB: …) rend la provenance auditable.

Voir Base de connaissances pour ce que le vault contient par défaut et comment ajouter vos propres playbooks.

specialist-compute — CPU / mémoire / load / processus

Points forts du frontmatter :

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

Quand le coordinator le choisit

• « CPU bloqué à fond sur node-X, qui le bouffe ? »
• « Load qui pique mais CPU idle — qu'est-ce qui est bloqué ? »
• « Croissance de mémoire de processus / forensics OOM. »
• « Steal time de VM — est-ce que je vois un voisin bruyant ? »

Les recettes cuites dans la persona

• load avg élevé + CPU% bas → chercher des processus en D-state (host_bash "ps -eo stat,pid,cmd | awk '$1 ~ /D/'"). Probable attente IO / réseau — dire au coordinator de dispatcher specialist-disk ou specialist-network.
• CPU% élevé → top processus, temps user vs system, colonne st de vmstat pour steal.
• mem_used_pct élevé → node_memory_* pour cached / buffers / swap, dmesg | grep -i 'oom-killer' pour les hits OOM, outliers RSS sur un seul processus avec PID + nom.

Rejets (dira au coordinator de redispatcher)

• « Devrions-nous redémarrer nginx ? » → specialist-ops (parce que le redémarrage passe par host_restart_service et le reviewer).
• « Disque qui se remplit » → specialist-disk.
• « Paquets réseau qui tombent » → specialist-network.

specialist-disk — filesystem / capacité

Points forts du frontmatter :

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

La recette en 4 étapes

1. Confirmation macro : get_host_load pour disk_used_pct + tendance query_promql node_filesystem_*.
2. Drill-down par couche : host_du_summary(paths=["/", "/var", "/opt", "/home", "/tmp"], depth=1).
3. Pinpoint fichier : host_find_large_files(paths=[plus gros top-level], top_n=20).
4. Vérif inode si nécessaire : host_bash "df -i".

Anti-patterns que la persona refuse

• Appels mono-chemin par chemin (utilisez un tableau de 4-8 chemins par appel — c'est beaucoup plus rapide).
• Tourner sur /proc /sys /dev — le sandbox rejette, la persona sait ne pas demander.
• Tout delete / mv / rm — lecture seule.

specialist-network — paquets / netns / iptables / OVS

Points forts du frontmatter :

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

Les recettes

• Topologie d'abord. ip -j addr show + host_netns_inspect pour comprendre le layout d'interface et de namespace.
• État de lien. Pilote + vitesse via ethtool -i ethX ; ss -tnp pour les connexions.
• 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.
• Sondes pour la connectivité. host_probe_tcp, host_probe_http, host_probe_dns.

Chaque appel host_bash porte une allowlist cmdpolicy — voir Recherche réseau Layer-1 pour les entrées cmdpolicy OVS / nft / conntrack / bpftool / ethtool / ip netns.

Discipline de sortie

Trois lignes : 现象 (symptôme : packet drop / RTT élevé / table NAT pleine / table de flow vide / mauvaise route), 根因 (jugement + preuve clé), 下一步 (prochaine action recommandée : redémarrer service, mettre à jour route, ajouter règle). Pas de dumps bruts ovs-ofctl — le coordinator ne les lit pas.

specialist-ops — services et opérations

C'est le specialist mutant. Points forts du frontmatter :

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

Ce qui est spécial

• Il porte host_restart_service, qui est Class: "write". Toute invocation déclenche le décorateur ReviewGate : le gate spawne le worker reviewer ; seule une décision approuvée redémarre réellement quoi que ce soit.
• Il ne peut pas contourner le gate via host_bash systemctl restart — la cmdpolicy de l'edge refuse les sous-commandes systemctl mutantes peu importe quel agent a émis la commande.

Quand le coordinator le choisit

• Statut / logs / redémarrage spécifique à un service (nginx, mysql, notre propre processus).
• status d'unit systemd, erreurs journalctl -u.
• Nombre récent de redémarrages, corrélations OOM.
• Vérif de planning cron / timer.
• État cassé de package (dpkg / apt / yum).
• « Devrions-nous redémarrer X pour purger la fuite ? » — ops est la persona qui propose ; reviewer est le gate.

Rejets

• Tendances cluster / jugement SLO → specialist-sre.
• Internes réseau → specialist-network.
• Analyse disque au niveau fichier en profondeur → specialist-disk.

specialist-sre — golden four signals / triage

La persona pour « le système est-il sain » / « quel incident importe le plus ». Points forts du frontmatter :

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

Style de travail

1. Incident-list d'abord. get_active_incidents — ce qui part actuellement et à quelle sévérité.
2. Tendances, pas métriques mono-host. query_promql sur des fenêtres 1h / 24h comparées à la baseline.
3. Trouver l'host outlier. find_outlier_edges / rank_edges plutôt que IQR fait main en PromQL.
4. Parler golden-four-signals. latence (p50/p95/p99) / taux d'erreur / trafic / saturation — chacun comme « baseline → courant → direction de déviation ».
5. Décisions de priorité. P0 (impact utilisateur, ça empire), P1 (impact utilisateur, stable), P2 (interne / tendance), P3 (bruit / faux positif).
6. Déléguer vers le bas. Suspecte disque → dire au coordinator de dispatcher specialist-disk. Suspecte réseau → specialist-network. N'essaye pas de faire la plongée profonde elle-même.

Pourquoi SRE ne fait pas de RCA

Pour un incident qui nécessite une attribution complète de cause racine, le coordinator choisit incident-investigator, pas specialist-sre. La persona SRE s'arrête à « c'est un vrai problème P1 de saturation sur payments ; recommande de dispatcher incident-investigator avec incident_id=1234 ». L'investigator remonte la chaîne causale ; le SRE juge si ça vaut le coup de la remonter.

Comment le coordinator choisit

Le catalogue est rendu dans le system prompt du coordinator par buildAgentCatalog. Pour chaque persona il fait apparaître :

• name (la valeur subagent_type).
• La description de la persona.
• La première ligne non vide de when_to_use.

Donc un LLM lisant le system prompt voit quelque chose comme :

## 可用的 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 et default sont délibérément exclus — le premier est réservé au ReviewGate ; le second est la persona coordinator racine virtuelle et le lister laisserait le coordinator se spawner récursivement lui-même.

Patterns de handoff croisés

Quand la réponse est « ce n'est pas mon domaine » :

Specialist	Handoff courant
compute → disk	Processus en D-state sur attente IO
compute → net	Processus en D-state bloqués sur réseau (sockets, recv)
compute → ops	« Le processus fuit ; recommande de redémarrer le service »
disk → ops	« Les logs explosent ; recommande logrotate plus serré »
net → ops	« La règle iptables corrige la fuite ; recommande redémarrage de service par sécurité »
sre → investigator	« Saturation P1, réel, nécessite RCA »
sre → compute	« Alarme de saturation — drill CPU/mem »

Le handoff est verbal (le specialist dit « 建议派 specialist-X parce que Y » dans sa réponse), pas un appel d'outil. Le coordinator lit la recommandation et dispatche le worker suivant. Les specialists ne peuvent pas spawner de workers — voir Aperçu des agents.

Tuner les personas specialist

Éditions courantes dans un fork :

• Sac d'outils : ajouter un BaseTool maison (par ex. query_clickhouse) à la liste tools: de la persona pertinente. Le filtre du worker fait confiance à la whitelist de la persona.
• max_turns : le défaut de 15 est généreux ; resserrer à 10 pour les specialists sensibles au coût.
• Corps de persona : ajouter les préférences de commande favorites de votre équipe (« sur cette flotte, journalctl --since '5m ago' avant --since '1h ago' »).
• when_to_use : resserrer ou élargir pour ajuster la fréquence à laquelle vous voulez que le coordinator choisisse cette persona.

Ne changez pas name — le catalogue et AgentTool cherchent les workers par nom exact. Voir Agents personnalisés.