Может ли 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 с мелкими фиксами конфигов или доступов выглядело почти невозможной задачей. Результаты были такие, что времени на базовые задачи тратилось сильно больше.

Документация для агентов

Как решение проблемы была придумана репа с базой знаний для агентов.
Мы взяли шаблон, похожий на вот этот (не смог найти оригинальный шаблон, который мы взяли за основу), основанный на паттерне описанном Карпатым. Репа была наполнена из памяти и недавних переписок с нашими локальными агентами и быстрым сканом нашей инфраструктуры.

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

Первые успехи после внедрения базы знаний, которые мы пошарили на внутренней презентации по внедрению LLM:

Ретро для бота

Параллельно с базой знаний я регулярно занимался анализом предыдущих чатов с ботом и корректировал системные промпты OpenClaw с помощью своего локального Claude Code.
Это оказалось утомляющей задачей, и в итоге я придумал цикл самоулучшения для бота, где LLM оценивала работу агента и в постоянном фидбэк-лупе модифицировала промпты и базу знаний.

Суть цикла в том, что каждый день простенькая моделька разбирает лог сообщений бота и кормит в модельку поумнее чаты, в которых у бота возникли проблемы или где он решил делать что-то не то. А также некоторое количество валидных чатов для сэмплинга.
Моделька поумнее пытается понять, почему бот делает что-то не то, и заносит эти данные в файл дейли-ревью. Раз в неделю моделька поумнее разбирает эти данные и замеряет перформанс бота и улучшения/ухудшения от недели к неделе, а также составляет 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 как раз тогда начал грозиться банить аккаунты за использование подписки вне харнесса). Я решил добавить в бота ротацию моделей, чтобы оценить, как разные варианты будут перформить внутри агента. Как итог, мы получали примерно такие замеры:

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

Mediocrity plateau

Сколько бы мы ни пытались модифицировать промпты, пополнять базу знаний и искать идеальную модель – мы не могли достигнуть качества и уровня автономности, которые мы считали достаточными, чтобы пускать агента дальше нашего командного пилотного чата. Если посмотреть на график оценки перформанса бота, то мы достигли плато и болтались около него:

Вдобавок к этому команду раздражала постоянная необходимость указывать боту, что он делает что-то не то, или затыкать его в треде, где он уже не нужен, но все равно отвечает. Ограничения 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 этого не позволял, и мы даже не думали в эту сторону, когда изначально запускали бота.