Specialists

Ongrid trae cinco personas specialist. Cada una posee una rebanada estrecha de diagnóstico de host / cluster, tiene un toolbag enfocado y explícitamente rechaza tareas que pertenecen a un par. El coordinator despacha basado en la forma del request; el bloque when_to_use del specialist le dice al LLM del coordinator cuándo es la opción correcta.

Persona	Posee	No posee
specialist-compute	CPU, memoria, load, procesos, OOM, scheduler	Disco, red, restart de servicio
specialist-disk	Filesystem, du / find / stat, inodes	Red, procesos, logs de negocio
specialist-network	OVS, netfilter, netns, conntrack, bpf, rutas	Filesystem, procesos
specialist-ops	Service start/stop/restart, journalctl, packages	Tendencias de cluster, internals de red
specialist-sre	Golden four signals, SLOs, error budgets, triage	Bash de host individual, RCA profunda

Por qué dividir granular

Toolbags más apretados = system prompt más apretado = razonamiento más profundo por token. Un worker specialist-network con 8 tools da respuestas más fuertes sobre iptables / nft que un coordinator con 60 tools que casualmente tiene iptables entre ellas. Los muros entre personas también dejan que cada dominio lleve hints de KB específicos del dominio en su system prompt.

La convención KB-first

Los cinco specialists empiezan con el mismo paso 0: llamar a query_knowledge una vez con una descripción en lenguaje natural del problema. Si el resultado top puntúa ≥ 0.6, sigue el playbook y termina la respuesta con (参考 KB: <title>). Esto lo refuerza el prompt de la persona, no el runtime — pero los prompts son lo suficientemente directos como para que los modelos fuertes lo sigan consistentemente.

Por qué un paso 0 uniforme:

• El vault lleva playbooks específicos del equipo (comandos preferidos, trampas conocidas, rutas de escalación). Le ganan al conocimiento general del modelo para tu flota.
• Ancla el primer turno del worker alrededor de un plan known-good en vez de dejarlo improvisar.
• La citación (参考 KB: …) hace auditable la proveniencia.

Ver Base de conocimiento para lo que el vault contiene por defecto y cómo añadir tus propios playbooks.

specialist-compute — CPU / memoria / load / procesos

Highlights del 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

Cuándo lo elige el coordinator

• "CPU pegada en node-X, ¿quién se la come?"
• "Load saltando pero CPU idle — ¿qué está bloqueado?"
• "Crecimiento de memoria del proceso / forense de OOM."
• "VM steal time — ¿estoy viendo noisy neighbor?"

Las recetas horneadas en la persona

• load avg high + CPU% low → busca procesos en estado D (host_bash "ps -eo stat,pid,cmd | awk '$1 ~ /D/'"). Probablemente espera IO / red — dile al coordinator que despache specialist-disk o specialist-network.
• CPU% high → top procesos, user vs system time, columna st de vmstat para steal.
• mem_used_pct high → node_memory_* para cached / buffers / swap, dmesg | grep -i 'oom-killer' para hits de OOM, outliers de RSS de un solo proceso con PID + nombre.

Rechaza (le dirá al coordinator que redespache)

• "¿Deberíamos reiniciar nginx?" → specialist-ops (porque restart va por host_restart_service y el reviewer).
• "Disco llenándose" → specialist-disk.
• "Paquetes de red descartándose" → specialist-network.

specialist-disk — filesystem / capacidad

Highlights del 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 receta de 4 pasos

1. Macro confirm: get_host_load para disk_used_pct + query_promql node_filesystem_* trend.
2. Layer drill-down: host_du_summary(paths=["/", "/var", "/opt", "/home", "/tmp"], depth=1).
3. File pinpoint: host_find_large_files(paths=[biggest top-level], top_n=20).
4. Inode check si es necesario: host_bash "df -i".

Anti-patrones que la persona rechaza

• Llamadas single-path por ruta (usa un array de 4-8 paths por llamada — es mucho más rápido).
• Correr en /proc /sys /dev — el sandbox rechaza, la persona sabe no pedir.
• Cualquier delete / mv / rm — read-only.

specialist-network — paquetes / netns / iptables / OVS

Highlights del 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

Las recetas

• Topología primero. ip -j addr show + host_netns_inspect para entender el layout de interfaces y namespaces.
• Estado de enlace. ethtool -i ethX driver + speed; ss -tnp para conexiones.
• 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 conectividad. host_probe_tcp, host_probe_http, host_probe_dns.

Cada llamada host_bash lleva una allowlist de cmdpolicy — ver Layer-1 network research para las entradas cmdpolicy OVS / nft / conntrack / bpftool / ethtool / ip netns.

Disciplina de salida

Tres líneas: 现象 (síntoma: drop de paquetes / RTT alto / tabla NAT llena / tabla de flow vacía / ruta incorrecta), 根因 (juicio + evidencia clave), 下一步 (próxima acción recomendada: reiniciar servicio, actualizar ruta, añadir regla). Sin dumps crudos de ovs-ofctl — el coordinator no los lee.

specialist-ops — servicios y operaciones

Este es el specialist mutador. Highlights del 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

Qué tiene de especial

• Lleva host_restart_service, que es Class: "write". Cualquier invocación dispara el decorator ReviewGate: el gate lanza al worker reviewer; solo una decisión aprobada realmente reinicia algo.
• No puede saltarse el gate vía host_bash systemctl restart — el cmdpolicy del edge niega subcomandos mutadores de systemctl independientemente de qué agente emitió el comando.

Cuándo lo elige el coordinator

• Status / logs / restart específicos de servicio (nginx, mysql, nuestro propio proceso).
• status de unit de systemd, errores de journalctl -u.
• Conteo reciente de restarts, correlaciones de OOM.
• Verificación de schedule de cron / timer.
• Estado roto de paquetes (dpkg / apt / yum).
• "¿Deberíamos reiniciar X para limpiar el leak?" — ops es la persona que propone; el reviewer es el gate.

Rechaza

• Tendencias de cluster / juicio de SLO → specialist-sre.
• Internals de red → specialist-network.
• Análisis profundo de disco a nivel de archivo → specialist-disk.

specialist-sre — golden four signals / triage

La persona para "¿está sano el sistema?" / "¿qué incidente importa más?". Highlights del 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 trabajo

1. Lista de incidentes primero. get_active_incidents — qué está disparando actualmente y a qué severidad.
2. Tendencias, no métricas de un solo host. query_promql sobre ventanas de 1h / 24h comparado con baseline.
3. Encuentra el host outlier. find_outlier_edges / rank_edges en vez de IQR hecho a mano en PromQL.
4. Habla golden-four-signals. latencia (p50/p95/p99) / tasa de error / tráfico / saturación — cada una como "baseline → actual → dirección de desviación".
5. Decisiones de prioridad. P0 (impacto al usuario, empeorando), P1 (impacto al usuario, estable), P2 (interno / tendencia), P3 (ruido / falso positivo).
6. Delega hacia abajo. Sospecha de disco → dile al coordinator que despache specialist-disk. Sospecha de red → specialist-network. No intenta hacer el deep dive él mismo.

Por qué SRE no hace RCA

Para un incidente que necesita atribución completa de causa raíz, el coordinator elige incident-investigator, no specialist-sre. La persona SRE se detiene en "esto es un P1 real de saturación en payments; recomiendo despachar incident-investigator con incident_id=1234". El investigator recorre la cadena causal; el SRE juzga si vale la pena recorrerla.

Cómo elige el coordinator

El catálogo lo renderiza en el system prompt del coordinator buildAgentCatalog. Para cada persona muestra:

• name (el valor de subagent_type).
• El description de la persona.
• La primera línea no vacía de when_to_use.

Así que un LLM leyendo el system prompt ve 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 y default se excluyen deliberadamente — el primero está reservado para el ReviewGate; el segundo es la persona coordinator virtual top-level y listarlo dejaría que el coordinator se autoinstanciara recursivamente.

Patrones de handoff cruzado

Cuando la respuesta es "este no es mi dominio":

Specialist	Handoff común
compute → disk	Procesos en estado D en espera de IO
compute → net	Procesos en estado D bloqueados en red (sockets, recv)
compute → ops	"El proceso está leakeando; recomiendo reiniciar el servicio"
disk → ops	"Los logs están explotando; recomiendo logrotate más apretado"
net → ops	"Una regla de iptables arregla el leak; recomiendo restart de servicio por seguridad"
sre → investigator	"Saturación P1, real, necesita RCA"
sre → compute	"Alarma de saturación — taladrar CPU/mem"

El handoff es verbal (el specialist dice "建议派 specialist-X porque Y" en su respuesta), no una llamada de tool. El coordinator lee la recomendación y despacha al siguiente worker. Los specialists no pueden lanzar workers — ver Overview de agentes.

Tuning de personas specialist

Ediciones comunes en un fork:

• Toolbag: añade un BaseTool in-house (p. ej. query_clickhouse) a la lista tools: de la persona relevante. El filtro del worker confía en la whitelist de la persona.
• max_turns: el default 15 es generoso; aprieta a 10 para specialists sensibles al costo.
• Cuerpo de persona: añade las preferencias de comando preferidas por tu equipo ("en esta flota, journalctl --since '5m ago' antes que --since '1h ago'").
• when_to_use: aprieta o amplía según con qué frecuencia quieras que el coordinator elija esta persona.

No cambies name — el catálogo y AgentTool buscan workers por nombre exacto. Ver Agentes custom.