Specialists

Ongrid 는 다섯 개의 specialist persona 를 출하합니다. 각각은 호스트 / 클러스터 진단의 좁은 슬라이스를 소유하고, 집중된 도구 가방을 가지며, 명시적으로 동료의 작업을 거부합니다. Coordinator 는 요청 형태에 따라 디스패치; specialist 의 when_to_use 블록이 coordinator 의 LLM 에게 언제 적합한지 알려 줍니다.

Persona	Owns	Doesn't own
specialist-compute	CPU, 메모리, load, 프로세스, OOM, 스케줄러	디스크, 네트워크, 서비스 재시작
specialist-disk	파일시스템, du / find / stat, inode	네트워크, 프로세스, 비즈니스 로그
specialist-network	OVS, netfilter, netns, conntrack, bpf, 라우트	파일시스템, 프로세스
specialist-ops	서비스 start/stop/restart, journalctl, 패키지	클러스터 추세, 네트워크 내부
specialist-sre	Golden four signals, SLO, 에러 예산, 분류	단일 호스트 bash, 깊은 RCA

왜 세분화하나

좁은 도구 가방 = 좁은 system prompt = 토큰당 깊은 추론. 8 개 도구의 specialist-network worker 가 60 개 도구 중에 마침 iptables 가 있는 coordinator 보다 iptables / nft 에 대해 더 강한 답을 줍니다. persona 벽은 또한 각 도메인이 자체 system prompt 에 도메인 특화 KB 힌트를 담을 수 있게 합니다.

KB-first 컨벤션

다섯 specialist 모두 같은 step 0 으로 시작: 문제에 대한 자연어 설명으로 query_knowledge 를 한 번 호출. 최상위 결과가 ≥ 0.6 점이면 플레이북을 따르고 답을 (참고 KB: <title>) 로 끝냅니다. 런타임이 아닌 persona prompt 가 강제 — 하지만 prompt 가 충분히 직접적이므로 강한 모델은 일관되게 따릅니다.

균일한 step 0 인 이유:

• vault 가 팀별 플레이북 (선호 명령, 알려진 함정, 에스컬레이션 경로) 을 가집니다. 당신의 함대에는 모델의 일반 지식보다 우월합니다.
• worker 의 첫 턴을 즉흥이 아닌 알려진 좋은 계획에 고정.
• 인용 (참고 KB: …) 가 출처를 감사 가능하게 합니다.

vault 의 기본 내용과 자체 플레이북 추가 방법은 지식 베이스 참고.

specialist-compute — CPU / 메모리 / load / 프로세스

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

Coordinator 가 고르는 때

• "node-X 의 CPU 가 고정, 누가 먹나?"
• "load 가 급증하나 CPU 는 유휴 — 무엇이 블록됐나?"
• "프로세스 메모리 증가 / OOM 포렌식."
• "VM steal time — noisy neighbor 보고 있나?"

Persona 에 구운 레시피

• load avg high + CPU% low → D-state 프로세스 찾기 (host_bash "ps -eo stat,pid,cmd | awk '$1 ~ /D/'"). 가능성 IO / 네트워크 wait — coordinator 에게 specialist-disk 또는 specialist-network 로 재디스패치 권장.
• CPU% high → 상위 프로세스, user vs system 시간, steal 용 vmstat st 컬럼.
• mem_used_pct high → cached / buffers / swap 용 node_memory_*, OOM 히트 용 dmesg | grep -i 'oom-killer', PID + 이름이 있는 단일 프로세스 RSS 아웃라이어.

거부 (coordinator 에게 재디스패치 요청)

• "nginx 를 재시작해야 하나?" → specialist-ops (재시작은 host_restart_service 와 reviewer 를 거침).
• "디스크 차고 있음" → specialist-disk.
• "네트워크 패킷 떨어지고 있음" → specialist-network.

specialist-disk — 파일시스템 / 용량

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

4 단계 레시피

1. 매크로 확인: disk_used_pct 용 get_host_load + query_promql node_filesystem_* 추세.
2. 레이어 drill-down: host_du_summary(paths=["/", "/var", "/opt", "/home", "/tmp"], depth=1).
3. 파일 pinpoint: host_find_large_files(paths=[biggest top-level], top_n=20).
4. 필요시 inode 확인: host_bash "df -i".

Persona 가 거부하는 안티 패턴

• 경로별 단일 호출 (호출당 4-8 경로의 배열 을 사용 — 훨씬 빠름).
• /proc /sys /dev 에서 실행 — sandbox 가 거부, persona 가 묻지 않음을 알고 있음.
• 모든 delete / mv / rm — 읽기 전용.

specialist-network — 패킷 / netns / iptables / OVS

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

레시피

• 토폴로지 먼저. ip -j addr show + host_netns_inspect 로 인터페이스와 네임스페이스 레이아웃 이해.
• 링크 상태. 드라이버 + 속도용 ethtool -i ethX; 연결용 ss -tnp.
• NAT / 방화벽. 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 화이트리스트를 운반 — OVS / nft / conntrack / bpftool / ethtool / ip netns cmdpolicy 엔트리는 Layer-1 네트워크 연구 참고.

출력 규율

세 줄: 现象 (증상: 패킷 드롭 / 높은 RTT / NAT 테이블 가득 / 빈 flow 테이블 / 잘못된 라우트), 根因 (판단 + 핵심 증거), 下一步 (권장 다음 액션: 서비스 재시작, 라우트 업데이트, 규칙 추가). 원시 ovs-ofctl 덤프 없음 — coordinator 가 읽지 않습니다.

specialist-ops — 서비스와 운영

이것이 mutating specialist 입니다. 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

특별한 점

• Class: "write" 인 host_restart_service 를 운반. 모든 호출은 ReviewGate 데코레이터 를 트리거: 게이트가 reviewer worker 를 스폰; 승인된 결정만이 실제로 무언가를 재시작.
• host_bash systemctl restart 를 통해 게이트를 우회할 수 없음 — edge cmdpolicy 가 어느 에이전트가 명령을 발행했든 mutating systemctl 서브커맨드를 거부.

Coordinator 가 고르는 때

• 서비스별 상태 / 로그 / 재시작 (nginx, mysql, 자체 프로세스).
• systemd unit status, journalctl -u 에러.
• 최근 재시작 횟수, OOM 상관관계.
• cron / 타이머 스케줄 확인.
• 패키지 파손 상태 (dpkg / apt / yum).
• "누수 해결을 위해 X 를 재시작해야 하나?" — ops 가 제안하는 persona; reviewer 가 게이트.

거부

• 클러스터 추세 / SLO 판단 → specialist-sre.
• 네트워크 내부 → specialist-network.
• 깊은 파일 레벨 디스크 분석 → specialist-disk.

specialist-sre — golden four signals / 분류

"시스템이 건강한가" / "어느 incident 가 가장 중요한가" 용 persona. 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

작업 스타일

1. Incident 리스트 먼저. get_active_incidents — 현재 발화 중인 것과 심각도.
2. 추세, 단일 호스트 메트릭 아님. 기준선 대비 1h / 24h 윈도우의 query_promql.
3. 아웃라이어 호스트 찾기. 손수 만든 PromQL IQR 보다 find_outlier_edges / rank_edges.
4. Golden four signals 말하기. 지연 (p50/p95/p99) / 에러율 / 트래픽 / 포화 — 각각 "기준선 → 현재 → 편차 방향" 으로.
5. 우선순위 결정. P0 (사용자 영향, 악화), P1 (사용자 영향, 안정), P2 (내부 / 추세), P3 (노이즈 / 거짓 양성).
6. 아래로 위임. 디스크 의심 → coordinator 에게 specialist-disk 디스패치 권유. 네트워크 의심 → specialist-network. 깊은 분석을 자체로 시도하지 않음.

SRE 가 RCA 를 하지 않는 이유

전체 근본 원인 attribution 이 필요한 incident 의 경우 coordinator 는 incident-investigator 를 고름, specialist-sre 가 아님. SRE persona 는 "이것은 payments 의 실제 P1 포화 이슈; incident_id=1234 로 incident-investigator 디스패치 권장" 에서 멈춥니다. investigator 가 인과 사슬을 따라가고, SRE 가 따라갈 가치가 있는지 판단합니다.

Coordinator 가 어떻게 고르나

카탈로그는 buildAgentCatalog 에 의해 coordinator 의 system prompt 로 렌더링. 각 persona 에 대해 표면화:

• name (subagent_type 값).
• persona 의 description.
• when_to_use 의 첫 비어 있지 않은 줄.

system prompt 를 읽는 LLM 은 다음과 같은 것을 봅니다:

## 可用的 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 persona 이며 나열하면 coordinator 가 자신을 재귀 스폰하게 됩니다.

크로스 핸드오프 패턴

답이 "이건 내 도메인이 아니야" 일 때:

Specialist	일반적 핸드오프
compute → disk	IO wait 의 D-state 프로세스
compute → net	네트워크 (소켓, recv) 에 블록된 D-state 프로세스
compute → ops	"프로세스 누수 중; 서비스 재시작 권장"
disk → ops	"로그가 폭주 중; 더 엄격한 logrotate 권장"
net → ops	"iptables 규칙이 누수를 고침; 안전을 위해 서비스 재시작 권장"
sre → investigator	"P1 포화, 실제, RCA 필요"
sre → compute	"포화 알람 — CPU/mem 드릴"

핸드오프는 언어적 입니다 (specialist 가 답변에 "建议派 specialist-X because Y" 라고 말함), 도구 호출이 아닙니다. coordinator 가 권장을 읽고 다음 worker 를 디스패치. Specialist 는 worker 를 스폰할 수 없음 — Agents overview 참고.

Specialist persona 튜닝

포크에서 흔한 편집:

• 도구 가방: 관련 persona 의 tools: 리스트에 사내 BaseTool (예: query_clickhouse) 추가. worker 필터는 persona 화이트리스트를 신뢰합니다.
• max_turns: 기본 15 는 관대; 비용 민감 specialist 는 10 으로 조임.
• Persona body: 팀의 선호 명령 추가 ("이 함대에서는 journalctl --since '1h ago' 보다 --since '5m ago' 가 우선").
• when_to_use: coordinator 가 이 persona 를 얼마나 자주 고를지에 맞춰 조이거나 넓힘.

name 은 바꾸지 마세요 — 카탈로그와 AgentTool 이 정확한 이름으로 worker 를 조회. 커스텀 에이전트 참고.