Специалисты

Ongrid поставляет пять specialist-персон. Каждая владеет узким срезом host / cluster диагностики, имеет сфокусированный набор инструментов и явно отказывается от задач, которые принадлежат соседу. Coordinator диспетчирует на основе формы запроса; блок when_to_use specialist говорит LLM coordinator, когда он подходит.

Персона	Владеет	Не владеет
`specialist-compute`	CPU, память, load, процессы, OOM, планировщик	Диск, сеть, перезапуск сервисов
`specialist-disk`	Файловая система, du / find / stat, inodes	Сеть, процессы, бизнес-логи
`specialist-network`	OVS, netfilter, netns, conntrack, bpf, маршруты	Файловая система, процессы
`specialist-ops`	Запуск/останов/перезапуск сервисов, journalctl, пакеты	Кластерные тренды, сетевые внутренности
`specialist-sre`	Золотые четыре сигнала, SLO, error budgets, триаж	Single-host bash, глубокий RCA

Зачем дробить тонко

Более узкие наборы инструментов = более узкий системный промпт = более глубокое рассуждение на токен. Воркер specialist-network с 8 инструментами даёт более сильные ответы про iptables / nft, чем coordinator с 60 инструментами, среди которых оказывается iptables. Стены персон также позволяют каждому домену нести доменно-специфичные KB-подсказки в своём системном промпте.

Конвенция KB-first

Все пять specialist начинают с одного и того же шага 0: вызвать query_knowledge один раз с natural-language описанием проблемы. Если топ-результат набирает ≥ 0.6, следовать playbook и завершить ответ (参考 KB: <title>). Это форсируется промптом персоны, а не рантаймом — но промпты достаточно прямые, что сильные модели следуют последовательно.

Зачем единый шаг 0:

Vault несёт team-specific playbooks (предпочтительные команды, известные ловушки, эскалационные пути). Они побеждают общие знания модели для вашего флота.
Это заякоривает первый ход воркера вокруг известного-хорошего плана, а не оставляет ему импровизировать.
Цитирование (参考 KB: …) делает provenance аудируемым.

См. База знаний, что vault содержит по умолчанию и как добавлять собственные playbook.

`specialist-compute` — CPU / память / load / процессы

Хайлайты frontmatter:

yaml

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 его выбирает

«CPU прижат на node-X, кто его съедает?»
«Load растёт, но CPU idle — что блокировано?»
«Рост памяти процесса / OOM forensics.»
«VM steal time — я вижу шумного соседа?»

Рецепты, запечённые в персоне

load avg high + CPU% low → искать процессы в D-state (host_bash "ps -eo stat,pid,cmd | awk '$1 ~ /D/'"). Вероятно, IO / network wait — скажите coordinator диспетчировать specialist-disk или specialist-network.
CPU% high → top-процессы, user vs system time, vmstat колонка st для steal.
mem_used_pct high → node_memory_* для cached / buffers / swap, dmesg | grep -i 'oom-killer' для OOM-хитов, выбросы RSS отдельных процессов с PID + именем.

Отвергает (скажет coordinator перенаправить)

«Стоит ли перезапустить nginx?» → specialist-ops (потому что перезапуск идёт через host_restart_service и reviewer).
«Диск заполняется» → specialist-disk.
«Сетевые пакеты теряются» → specialist-network.

`specialist-disk` — файловая система / ёмкость

Хайлайты frontmatter:

yaml

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-шаговый рецепт

Макро-подтверждение: get_host_load для disk_used_pct + query_promql node_filesystem_* тренд.
Послойное углубление: host_du_summary(paths=["/", "/var", "/opt", "/home", "/tmp"], depth=1).
Точная локализация файла: host_find_large_files(paths=[biggest top-level], top_n=20).
Проверка inode, если нужно: host_bash "df -i".

Анти-паттерны, которые персона отвергает

Per-path вызовы с одним путём (используйте массив из 4-8 путей за вызов — это значительно быстрее).
Запуск на /proc /sys /dev — sandbox отвергает, персона знает не спрашивать.
Любые delete / mv / rm — read-only.

`specialist-network` — пакеты / netns / iptables / OVS

Хайлайты frontmatter:

yaml

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 / 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.
Пробы для проверки связности. host_probe_tcp, host_probe_http, host_probe_dns.

Каждый вызов host_bash несёт cmdpolicy allowlist — см. Layer-1 network research для записей cmdpolicy OVS / nft / conntrack / bpftool / ethtool / ip netns.

Дисциплина вывода

Три строки: 现象 (симптом: потеря пакетов / высокий RTT / NAT-таблица полна / пустая flow-таблица / неверный маршрут), 根因 (вердикт + ключевое доказательство), 下一步 (рекомендуемое следующее действие: перезапуск сервиса, обновление маршрута, добавление правила). Никаких сырых ovs-ofctl дампов — coordinator их не читает.

`specialist-ops` — сервисы и операции

Это мутирующий specialist. Хайлайты frontmatter:

yaml

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; только одобренное решение действительно что-либо перезапускает.
Он не может обойти гейт через host_bash systemctl restart — edge cmdpolicy отказывает мутирующим подкомандам systemctl независимо от того, какой агент выдал команду.

Когда coordinator его выбирает

Service-specific status / логи / перезапуск (nginx, mysql, наш собственный процесс).
systemd unit status, journalctl -u ошибки.
Недавнее число перезапусков, OOM-корреляции.
Проверка cron / timer расписания.
Сломанное состояние пакета (dpkg / apt / yum).
«Стоит ли перезапустить X, чтобы очистить утечку?» — ops — это персона, которая предлагает; reviewer — это гейт.

Отвергает

Кластерные тренды / SLO-вердикт → specialist-sre.
Сетевые внутренности → specialist-network.
Глубокий анализ диска на уровне файлов → specialist-disk.

`specialist-sre` — золотые четыре сигнала / триаж

Персона для «здорова ли система» / «какой инцидент важнее всего». Хайлайты frontmatter:

yaml

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

Стиль работы

Список инцидентов сначала. get_active_incidents — что сейчас срабатывает и с какой severity.
Тренды, а не single-host метрики. query_promql за окна 1ч / 24ч в сравнении с baseline.
Найти выбивающийся хост. find_outlier_edges / rank_edges, а не самописный IQR в PromQL.
Говорить языком золотых четырёх сигналов. Латентность (p50/p95/p99) / error rate / трафик / saturation — каждый как «baseline → current → направление отклонения».
Решения по приоритету. P0 (impact на пользователя, ухудшается), P1 (impact на пользователя, стабильно), P2 (внутреннее / тренд), P3 (шум / false positive).
Делегировать вниз. Подозревает диск → скажет coordinator диспетчировать specialist-disk. Подозревает сеть → specialist-network. Не пытается сделать глубокое погружение сам.

Почему SRE не делает RCA

Для инцидента, который требует полной атрибуции корневой причины, coordinator выбирает incident-investigator, а не specialist-sre. Персона SRE останавливается на «это реальный P1 saturation issue на payments; рекомендую диспетчировать incident-investigator с incident_id=1234». Investigator идёт по причинной цепочке; SRE судит, стоит ли идти.

Как coordinator выбирает

Каталог отрендерен в системный промпт coordinator buildAgentCatalog. Для каждой персоны он выдаёт:

name (значение subagent_type).
description персоны.
Первую непустую строку when_to_use.

Так что LLM, читая системный промпт, видит что-то вроде:

text

## 可用的 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 рекурсивно породить самого себя.

Паттерны кросс-передачи

Когда ответ — «это не мой домен»:

Specialist	Частая передача
compute → disk	Процессы в D-state на IO wait
compute → net	Процессы в D-state, заблокированные на сети (sockets, recv)
compute → ops	«Процесс течёт; рекомендую перезапустить сервис»
disk → ops	«Логи взрываются; рекомендую более жёсткий logrotate»
net → ops	«Правило iptables чинит утечку; рекомендую перезапуск сервиса для безопасности»
sre → investigator	«P1 saturation, реально, нужен RCA»
sre → compute	«Saturation alarm — углубитесь в CPU/mem»

Передача вербальная (specialist говорит «建议派 specialist-X because Y» в своём ответе), а не вызов инструмента. Coordinator читает рекомендацию и диспетчирует следующего воркера. Specialist не могут порождать воркеров — см. Обзор агентов.

Тюнинг персон specialist

Частые правки в форке:

Набор инструментов: добавьте in-house BaseTool (например, query_clickhouse) в список tools: релевантной персоны. Фильтр воркера доверяет whitelist персоны.
max_turns: дефолт 15 щедр; затяните до 10 для стоимостно-чувствительных specialist.
Тело персоны: добавьте предпочтения команд вашей команды («на этом флоте journalctl --since '5m ago' перед --since '1h ago'»).
when_to_use: затяните или расширьте под то, как часто вы хотите, чтобы coordinator выбирал эту персону.

Не меняйте name — каталог и AgentTool ищут воркеров по точному имени. См. Кастомные агенты.

Специалисты ​

Конвенция KB-first ​

specialist-compute — CPU / память / load / процессы ​

Когда coordinator его выбирает ​

Рецепты, запечённые в персоне ​

Отвергает (скажет coordinator перенаправить) ​

specialist-disk — файловая система / ёмкость ​

4-шаговый рецепт ​

Анти-паттерны, которые персона отвергает ​

specialist-network — пакеты / netns / iptables / OVS ​

Рецепты ​

Дисциплина вывода ​

specialist-ops — сервисы и операции ​

Что особенного ​

Когда coordinator его выбирает ​

Отвергает ​

specialist-sre — золотые четыре сигнала / триаж ​

Стиль работы ​

Почему SRE не делает RCA ​

Как coordinator выбирает ​

Паттерны кросс-передачи ​

Тюнинг персон specialist ​

Специалисты

Конвенция KB-first

`specialist-compute` — CPU / память / load / процессы

Когда coordinator его выбирает

Рецепты, запечённые в персоне

Отвергает (скажет coordinator перенаправить)

`specialist-disk` — файловая система / ёмкость

4-шаговый рецепт

Анти-паттерны, которые персона отвергает

`specialist-network` — пакеты / netns / iptables / OVS

Рецепты

Дисциплина вывода

`specialist-ops` — сервисы и операции

Что особенного

Когда coordinator его выбирает

Отвергает

`specialist-sre` — золотые четыре сигнала / триаж

Стиль работы

Почему SRE не делает RCA

Как coordinator выбирает

Паттерны кросс-передачи

Тюнинг персон specialist