Specialists

Ongrid distribui cinco personas specialist. Cada uma detém uma fatia estreita de diagnóstico de host / cluster, tem uma tool bag focada, e explicitamente recusa tarefas que pertencem a um par. O coordinator despacha baseado no formato da requisição; o bloco when_to_use do specialist diz ao LLM do coordinator quando ele é a escolha certa.

Persona	Detém	Não detém
specialist-compute	CPU, memória, load, processos, OOM, scheduler	Disco, rede, restart de serviço
specialist-disk	Filesystem, du / find / stat, inodes	Rede, processos, logs de negócio
specialist-network	OVS, netfilter, netns, conntrack, bpf, rotas	Filesystem, processos
specialist-ops	Service start/stop/restart, journalctl, pacotes	Tendências de cluster, internos de rede
specialist-sre	Os quatro sinais de ouro, SLOs, error budgets, triagem	Bash em host único, RCA profundo

Por que dividir fino

Tool bags mais apertadas = system prompt mais apertado = raciocínio mais profundo por token. Um worker specialist-network com 8 tools dá respostas mais fortes sobre iptables / nft que um coordinator com 60 tools que por acaso tem iptables entre elas. Os muros de persona também permitem que cada domínio carregue dicas de KB específicas do domínio em seu system prompt.

A convenção KB-first

Todas as cinco specialists começam com o mesmo step 0: chamar query_knowledge uma vez com uma descrição em linguagem natural do problema. Se o melhor resultado pontuar ≥ 0.6, siga o playbook e encerre a resposta com (参考 KB: <title>). Isto é imposto pelo prompt da persona, não pelo runtime — mas os prompts são diretos o suficiente para que modelos fortes sigam consistentemente.

Por que um step 0 uniforme:

• O vault carrega playbooks específicos de equipe (comandos preferidos, armadilhas conhecidas, caminhos de escalação). Eles vencem o conhecimento geral do modelo para sua frota.
• Ancora o primeiro turn do worker em torno de um plano conhecido bom, em vez de deixar improvisar.
• Citação (参考 KB: …) torna a proveniência auditável.

Veja Base de conhecimento para o que o vault contém por padrão e como adicionar seus próprios playbooks.

specialist-compute — CPU / memória / load / processos

Destaques do 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

Quando o coordinator a escolhe

• "CPU travado em node-X, quem está consumindo?"
• "Load subindo mas CPU ocioso — o que está bloqueado?"
• "Crescimento de memória de processo / forense de OOM."
• "VM steal time — estou vendo noisy neighbor?"

As receitas embutidas na persona

• load avg alto + CPU% baixo → procurar processos em D-state (host_bash "ps -eo stat,pid,cmd | awk '$1 ~ /D/'"). Provavelmente espera por IO / rede — diga ao coordinator para despachar specialist-disk ou specialist-network.
• CPU% alto → top processes, tempo de usuário vs sistema, coluna st do vmstat para steal.
• mem_used_pct alto → node_memory_* para cached / buffers / swap, dmesg | grep -i 'oom-killer' para hits de OOM, outliers de RSS de processo único com PID + nome.

Rejeita (vai dizer ao coordinator para redespacha)

• "Devemos reiniciar o nginx?" → specialist-ops (porque restart passa por host_restart_service e o reviewer).
• "Disco enchendo" → specialist-disk.
• "Pacotes de rede caindo" → specialist-network.

specialist-disk — filesystem / capacidade

Destaques do 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

A receita de 4 passos

1. Macro confirma: get_host_load para disk_used_pct + query_promql tendência node_filesystem_*.
2. Drill-down em camadas: host_du_summary(paths=["/", "/var", "/opt", "/home", "/tmp"], depth=1).
3. Pinpoint de arquivo: host_find_large_files(paths=[maior top-level], top_n=20).
4. Check de inode se necessário: host_bash "df -i".

Anti-padrões que a persona recusa

• Chamadas com um único path por vez (use um array de 4-8 paths por chamada — é muito mais rápido).
• Rodar em /proc /sys /dev — o sandbox rejeita, a persona sabe para não pedir.
• Qualquer delete / mv / rm — read-only.

specialist-network — pacotes / netns / iptables / OVS

Destaques do 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

As receitas

• Topologia primeiro. ip -j addr show + host_netns_inspect para entender layout de interface e namespace.
• Estado do link. ethtool -i ethX driver + velocidade; ss -tnp para conexões.
• 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 para conectividade. host_probe_tcp, host_probe_http, host_probe_dns.

Cada chamada host_bash carrega um allowlist da cmdpolicy — veja Pesquisa de rede Layer-1 para as entradas de cmdpolicy OVS / nft / conntrack / bpftool / ethtool / ip netns.

Disciplina de saída

Três linhas: 现象 (sintoma: pacote caindo / RTT alto / tabela NAT cheia / flow table vazia / rota errada), 根因 (julgamento + evidência-chave), 下一步 (próxima ação recomendada: reiniciar serviço, atualizar rota, adicionar regra). Sem dumps brutos de ovs-ofctl — o coordinator não lê.

specialist-ops — serviços e operações

Este é o specialist mutador. Destaques do 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

O que tem de especial

• Carrega host_restart_service, que é Class: "write". Qualquer invocação dispara o decorator ReviewGate: o gate dá spawn no worker reviewer; só uma decisão aprovada realmente reinicia algo.
• Não pode contornar o gate via host_bash systemctl restart — a cmdpolicy do edge nega subcomandos mutadores de systemctl independentemente de qual agent emitiu o comando.

Quando o coordinator a escolhe

• Status / logs / restart específico de serviço (nginx, mysql, nosso próprio processo).
• status de unit systemd, erros journalctl -u.
• Contagem recente de restart, correlações com OOM.
• Verificação de schedule de cron / timer.
• Estado quebrado de pacote (dpkg / apt / yum).
• "Devemos reiniciar X para limpar o leak?" — ops é a persona que propõe; reviewer é o gate.

Rejeita

• Tendências de cluster / julgamento de SLO → specialist-sre.
• Internos de rede → specialist-network.
• Análise profunda de disco a nível de arquivo → specialist-disk.

specialist-sre — quatro sinais de ouro / triagem

A persona para "o sistema está saudável" / "qual incidente importa mais". Destaques do 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

Estilo de trabalho

1. Lista de incidentes primeiro. get_active_incidents — o que está disparando agora e em qual severity.
2. Tendências, não métricas de host único. query_promql sobre janelas de 1h / 24h comparadas a baseline.
3. Achar o host outlier. find_outlier_edges / rank_edges em vez de IQR à mão em PromQL.
4. Falar quatro-sinais-de-ouro. latência (p50/p95/p99) / taxa de erro / tráfego / saturação — cada uma como "baseline → atual → direção do desvio".
5. Decisões de prioridade. P0 (impacto ao usuário, piorando), P1 (impacto ao usuário, estável), P2 (interno / tendência), P3 (ruído / falso positivo).
6. Delegar para baixo. Suspeita de disco → diga ao coordinator para despachar specialist-disk. Suspeita de rede → specialist-network. Não tenta fazer o deep dive ela mesma.

Por que SRE não faz RCA

Para um incidente que precisa de atribuição completa de causa raiz, o coordinator escolhe incident-investigator, não specialist-sre. A persona SRE para em "este é um problema P1 real de saturação em payments; recomendo despachar incident-investigator com incident_id=1234". O investigator percorre a cadeia causal; o SRE julga se vale a pena percorrer.

Como o coordinator escolhe

O catálogo é renderizado no system prompt do coordinator por buildAgentCatalog. Para cada persona ele expõe:

• name (o valor do subagent_type).
• O description da persona.
• A primeira linha não-vazia do when_to_use.

Então um LLM lendo o system prompt vê algo como:

## 可用的 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 e default são deliberadamente excluídos — o primeiro é reservado para o ReviewGate; o segundo é a persona virtual de topo do coordinator e listá-lo deixaria o coordinator dar spawn em si mesmo recursivamente.

Padrões de cross-handoff

Quando a resposta é "isto não é meu domínio":

Specialist	Handoff comum
compute → disk	Processos em D-state em espera de IO
compute → net	Processos em D-state bloqueados em rede (sockets, recv)
compute → ops	"Processo está vazando; recomendo reiniciar serviço"
disk → ops	"Logs estão explodindo; recomendo logrotate mais apertado"
net → ops	"Regra iptables resolve o leak; recomendo restart de serviço por segurança"
sre → investigator	"P1 saturação, real, precisa de RCA"
sre → compute	"Alarme de saturação — investigar CPU/mem"

O handoff é verbal (o specialist diz "建议派 specialist-X because Y" em sua resposta), não uma chamada de tool. O coordinator lê a recomendação e despacha o próximo worker. Specialists não podem dar spawn em workers — veja Visão geral dos agents.

Tunando personas specialist

Edições comuns num fork:

• Tool bag: adicione um BaseTool da casa (ex.: query_clickhouse) ao tools: da persona relevante. O filtro do worker confia na whitelist da persona.
• max_turns: o padrão 15 é generoso; aperte para 10 em specialists sensíveis a custo.
• Corpo da persona: adicione as preferências de comando preferidas da sua equipe ("nesta frota, journalctl --since '5m ago' antes de --since '1h ago'").
• when_to_use: aperte ou alargue conforme a frequência com que você quer que o coordinator escolha essa persona.

Não mude name — o catálogo e AgentTool localizam workers por nome exato. Veja Agents customizados.