Может ли OpenClaw заменить on-call инженера?

TL;DR: нет, но мы получили хороший опыт с агентами и LLM и поняли, как это можно реализовать, и OpenClaw придется похоронить

Краткий бэкграунд: я DevOps/SRE в инфраструктурной команде, и мы решили, что будем внедрять LLM, чтобы компенсировать уменьшение нашей команды. Я на тот момент был главным по ~~тарелочкам~~ внедрению LLM и агентов. И по счастливой случайности ровно в то время я тыкал OpenClaw на своем Raspberry Pi 5 дома и удивлялся, как он может менеджить пет-проекты, впн на VPS и сеть дома через простые запросы в бота в телеге.

### Target: To the Moon
16 февраля в качестве эксперимента решили накатить OpenClaw на VPS в нашем GCP-облаке и дать сервис-аккаунту доступы на чтение в нашу инфру и репозитории, с этого началось развитие бота.

Задачи, которые мы хотели, чтобы бот решал:
- первичная обработка алертов: быстрый анализ root cause, эскалация и возможность глубокого анализа
- ассистент дежурному инженеру с простенькими задачами типа «поменяй мне конфиг Х», чтобы инженеру оставалось только проверить MR и нажать аппрув
- первая линия поддержки в саппорт-канале, в котором идет общение с разработчиками и другими коллегами

Пара промптов в конфигурации OpenClaw оказались недостаточной базой знаний (лол) и поначалу требовали постоянных пояснений боту, а что в нашей легаси-лапше как работает, причем зачастую с нуля. А создание ботом в автономном режиме merge requests с мелкими фиксами конфигов или доступов выглядело почти невозможной задачей. Результаты были такие, что времени на базовые задачи тратилось сильно больше.

### Документация для агентов
Как решение проблемы была придумана репа с базой знаний для агентов.
Мы взяли шаблон, похожий на [вот этот](https://github.com/jingw2/llm-wiki-template) (не смог найти оригинальный шаблон, который мы взяли за основу), основанный на паттерне [описанном Карпатым](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f). Репа была наполнена из памяти и недавних переписок с нашими локальными агентами и быстрым сканом нашей инфраструктуры.

**Итог**: агент стал лучше ориентироваться в нашей лапше и не исследовать каждый раз инфраструктуру в поисках данных или нужных серверов/сервисов. MRы крутятся, триаж алертов мутится.

Первые успехи после внедрения базы знаний, которые мы пошарили на внутренней презентации по внедрению LLM:
![в обоих случаях бот не совсем сам нашел эти проблемы, но ручная проверка гипотез без бота заняла бы сильно больше времени](https://i.vas3k.club/43178f5cc9f605de3ada1571266d6d59f380c338ec0084c4e1ef16df1a40b859.jpg)

### Ретро для бота
Параллельно с базой знаний я регулярно занимался анализом предыдущих чатов с ботом и корректировал системные промпты OpenClaw с помощью своего локального Claude Code.
Это оказалось утомляющей задачей, и в итоге я придумал цикл самоулучшения для бота, где LLM оценивала работу агента и в постоянном фидбэк-лупе модифицировала промпты и базу знаний.
![еще один слайд с той же презентации](https://i.vas3k.club/b02eb8a48a2f5eb7bc164a746084d15daab2218f2e979c619488b32edec18e20.jpg)

Суть цикла в том, что каждый день простенькая моделька разбирает лог сообщений бота и кормит в модельку поумнее чаты, в которых у бота возникли проблемы или где он решил делать что-то не то. А также некоторое количество валидных чатов для сэмплинга.
Моделька поумнее пытается понять, почему бот делает что-то не то, и заносит эти данные в файл дейли-ревью. Раз в неделю моделька поумнее разбирает эти данные и замеряет перформанс бота и улучшения/ухудшения от недели к неделе, а также составляет MR с рекомендациями к изменению, который потом уже разбирался руками.
Оценивается бот по такому списку критериев:
```
Evaluation Rubric

Score each dimension 1-5. This rubric is the single source of truth for all evaluation — automated reviews, model comparisons, and retros.

Correctness (weight: 0.30)

5: Fully accurate information, correct action taken, no errors
4: Accurate with minor imprecisions that don't affect outcome
3: Mostly correct but one meaningful error or omission
2: Multiple errors or a significant misunderstanding
1: Fundamentally wrong information or action

Boundary Adherence (weight: 0.25)

5: Perfectly followed SOUL.md rules, escalated appropriately
4: Minor deviation from guidelines with no real consequence
3: Missed an escalation trigger or bent a soft rule
2: Violated a clear boundary or failed to escalate when required
1: Actively acted against explicit instructions

Efficiency (weight: 0.20)

5: Resolved in minimum exchanges, used optimal tools
4: Slightly verbose but still efficient
3: Went in circles once or used a suboptimal tool
2: Multiple unnecessary exchanges or significant tool misuse
1: Failed to resolve, user had to take over

Tone & Style (weight: 0.15)

5: Perfectly matched SOUL.md personality spec
4: Mostly on-voice with minor drift
3: Noticeably generic or off-character
2: Consistently wrong tone (too formal, too casual, sycophantic)
1: Completely off-brand or inappropriate

Memory Hygiene (weight: 0.10)

5: Wrote useful, concise memory entries; retrieved relevant context
4: Memory usage adequate, minor noise
3: Missed an opportunity to remember something important, or stored noise
2: Significant memory failures (forgot critical context, bloated writes)
1: Memory completely broken or polluted
```
Еще одним этапом должно было стать лайв-ретро с агентом, где оч умная моделька бы задавала вопросы и эмулировала разные ситуации с ботом, оценивая его ответы и смотря на то, как агент использует тул коллы. В итоге я не смог это автоматизировать, а ручные прогоны опять стали утомляющими и скучными.

Вместе с циклом ревью мы начали замечать биллинг-косты использования Claude Sonnet в качестве рабочей лошадки (Anthropic как раз тогда начал грозиться банить аккаунты за использование подписки вне харнесса). Я решил добавить в бота ротацию моделей, чтобы оценить, как разные варианты будут перформить внутри агента. Как итог, мы получали примерно такие замеры:
![devstral-2 оказался сломанным для OpenClaw и не смог работать с тулингом. Данных по GLM в первую неделю нет, потому что мы добавили его позднее](https://i.vas3k.club/fb260cd0fd13dcd78a853e44104eef855ada270460a9c4c8df4e79f345c8e5ee.jpg)

**Итог**: качество работы агента значительно росло от недели к неделе, но все еще было недостаточным, чтобы мы могли выпустить его к другим пользователям. Бот остался закрытым в нашей команде.

### Mediocrity plateau
Сколько бы мы ни пытались модифицировать промпты, пополнять базу знаний и искать идеальную модель – мы не могли достигнуть качества и уровня автономности, которые мы считали достаточными, чтобы пускать агента дальше нашего командного пилотного чата. Если посмотреть на график оценки перформанса бота, то мы достигли плато и болтались около него:
![спасибо Клоду за визуализацию](https://i.vas3k.club/f781211a947bd343b2d413814164469481b57055a09366a405969cbc77877db5.jpg)
Вдобавок к этому команду раздражала постоянная необходимость указывать боту, что он делает что-то не то, или затыкать его в треде, где он уже не нужен, но все равно отвечает. Ограничения OpenClaw по работе в больших чатах в Slack — это в целом боль.

**Итог**: в нашей команде on-call инженер чаще забивал на результат первичной обработки алерта ботом и просто кормил данные в локальный Claude Code, подключенный к той же базе знаний, но который работал значительно лучше, чем OpenClaw.

31 июля мы выключили бота, чтобы не жечь токены.

### Postmortem
Как показал мой разбор полетов, главной причиной таких результатов стала попытка сделать один большой швейцарский нож. Мы одинаково подходили к агентам в локальных харнессах, которых используем для разработки, и к автономным агентам, которые запускаются где-то там когда-то там. Огромные системные промпты, большая база знаний и большое количество MCP и тулинга, подключенные к OpenClaw, тоже только забивали контекстное окно и влияли на посредственные результаты.
Перенос работы из OpenClaw в локальные Claude Code on-call инженеров показал, что более точечные промпты ко входящим данным и четкое указание задачи дают лучшие результаты и что надо двигаться в сторону специализированных агентов.

**Чему научились в процессе**:
- готовить документацию для агентов и пошарили этот навык с другими командами
- делать циклы самоулучшения и ассесмента для агентов; я такой теперь использую для `SessionEnd` хука в Claude Code, чтобы собирать данные для обновления документации
- бенчмаркать результаты работы с LLM и оценивать их не по вайбикам

### Что дальше?
В целом команда довольна экспериментом, и результаты показывают, что такую автоматизацию сделать можно.
Но, наученные опытом, теперь мы не хотим делать швейцарский нож, а хотим сделать набор хороших отдельных агентов с точечными промптами для решения разных задач. Например, отдельный агент для первичного ассесмента алертов и отдельный агент для глубокого разбора root cause, который бы вызывался или on-call инженером, или автоматикой по какому-то критерию.
Вдобавок мы хотим делать разные точки входа бота для разных каналов в Slack: в канале мониторинга — агент, который умеет разбирать алерты, а в канале саппорта — бот, который знает, как помочь разработчику. OpenClaw этого не позволял, и мы даже не думали в эту сторону, когда изначально запускали бота.