Post #1427
56
Как я сделал так, чтобы агент сам себя допиливал (и не разваливал при этом)
Привет. В прошлом посте я рассказал общую историю, как появился persona-bot (Аня). Сегодня хочу копнуть глубже в самую важную для меня часть — self-improve loop. Это то, ради чего я вообще затеял всё это.
Почему обычного tool use мне было мало?
Большинство агентов на момент, когда я начинал, умели пользоваться инструментами. Пишешь «проверь статус Proxmox» — и он дёргает API или выполняет команды. Это круто, но есть потолок.
Рано или поздно ты упираешься в то, что агент не умеет делать. И тогда либо ты сам идёшь и пишешь новый инструмент/скилл, либо агент начинает страдать и придумывать костыли.
Мне захотелось другого. Я хотел, чтобы Аня могла:
- Увидеть, что ей не хватает возможности
- Сама написать себе новый код (или редачить существующий)
- Протестировать
- Заставить работать в проде
- И при этом не сломать себя насовсем
То есть не просто "использовать инструменты", а изменять свои собственные возможности.
Первая наивная версия
Сначала было просто. Я дал ей инструменты
Она могла в теории править свой код. На практике это быстро привело к трём классическим проблемам:
1. Она ломала критичные файлы
2. Изменения часто были сломанными, и бот просто переставал запускаться.
3. Не было никакого отката. Один неудачный патч — и всё.
Плюс она очень быстро начинала забывать контекст того, что она только что изменила.
Как мы пришли к нормальному циклу
Постепенно выросла целая система. Сейчас цикл выглядит примерно так:
1. Решение, что нужно менять
2. Чтение нужного файла
3. Snapshot — перед изменением делается резервная копия
4. Применение правки через специальный инструмент
5. Валидация:
- Синтаксис (py_compile)
- Импорты (для bot/)
- Behavioural-тесты (если указаны)
6. Если тесты прошли — можно делать
7. Smoke check после рестарта.
8. Откат, если что-то пошло не так.
Важный момент: для правок в
SKILL.md как контракт (не штурм)
Одна из самых важных штук, которая сильно помогла — это формат
Когда она пишет новый скилл, она обязана описать:
- Flow (как рассуждать и в каком порядке действовать)
- Constraints (что нельзя)
- Error Handling (что делать при разных ошибках)
- Behavioural tests
И если она хочет, чтобы правка этого скилла считалась "успешной", то в
Безопасность и ограничения
Я довольно параноидально подошёл к этому:
- Есть жёсткий denylist. Нельзя трогать
- Даже если она хочет править
-
- Есть отдельные флаги
В idle-режиме (когда я не пишу) у неё тоже есть ограничения. Она может анализировать и предлагать, но я могу выключить реальные правки одним флагом.
Что реально получилось
За время проекта она сама написала/сильно доработала скиллы.
Были случаи, когда она находила проблемы в своих же предыдущих правках и их исправляла. Самое приятное — это когда я просто говорю про какую-то боль, а она потом сама:
- создаёт задачу в бэклоге,
- в какой-то момент в свободное время её берёт,
- делает правку,
- прогоняет тесты,
- и потом сообщает мне, что "добавила поддержку X".
Что до сих пор сложно
Память и эволюция до сих пор остаются самыми трудоёмкими частями. Есть анти-дубликаты, но не идеально.
Для меня это интересный инженерный челлендж — научить агента безопасно улучшать самого себя.
Привет. В прошлом посте я рассказал общую историю, как появился persona-bot (Аня). Сегодня хочу копнуть глубже в самую важную для меня часть — self-improve loop. Это то, ради чего я вообще затеял всё это.
Почему обычного tool use мне было мало?
Большинство агентов на момент, когда я начинал, умели пользоваться инструментами. Пишешь «проверь статус Proxmox» — и он дёргает API или выполняет команды. Это круто, но есть потолок.
Рано или поздно ты упираешься в то, что агент не умеет делать. И тогда либо ты сам идёшь и пишешь новый инструмент/скилл, либо агент начинает страдать и придумывать костыли.
Мне захотелось другого. Я хотел, чтобы Аня могла:
- Увидеть, что ей не хватает возможности
- Сама написать себе новый код (или редачить существующий)
- Протестировать
- Заставить работать в проде
- И при этом не сломать себя насовсем
То есть не просто "использовать инструменты", а изменять свои собственные возможности.
Первая наивная версия
Сначала было просто. Я дал ей инструменты
file_read и file_write (позже это стало только через self_improve).Она могла в теории править свой код. На практике это быстро привело к трём классическим проблемам:
1. Она ломала критичные файлы
2. Изменения часто были сломанными, и бот просто переставал запускаться.
3. Не было никакого отката. Один неудачный патч — и всё.
Плюс она очень быстро начинала забывать контекст того, что она только что изменила.
Как мы пришли к нормальному циклу
Постепенно выросла целая система. Сейчас цикл выглядит примерно так:
1. Решение, что нужно менять
2. Чтение нужного файла
3. Snapshot — перед изменением делается резервная копия
4. Применение правки через специальный инструмент
self_improve5. Валидация:
- Синтаксис (py_compile)
- Импорты (для bot/)
- Behavioural-тесты (если указаны)
6. Если тесты прошли — можно делать
bot_restart (для изменений в bot/).7. Smoke check после рестарта.
8. Откат, если что-то пошло не так.
Важный момент: для правок в
anya/skills/ у нас есть авто-ретрай. Если тесты упали — она может попробовать поправить сама (максимум пару раз), прежде чем откатиться.SKILL.md как контракт (не штурм)
Одна из самых важных штук, которая сильно помогла — это формат
SKILL.md.Когда она пишет новый скилл, она обязана описать:
- Flow (как рассуждать и в каком порядке действовать)
- Constraints (что нельзя)
- Error Handling (что делать при разных ошибках)
- Behavioural tests
И если она хочет, чтобы правка этого скилла считалась "успешной", то в
self_improve нужно передать test_cmd, который эти тесты запускает. Без тестов — правка считается рискованной и часто просто не принимается в "прод". Это сильно меняет качество генерируемого кода. Она начинает думать не "как сделать, чтобы сработало сейчас", а "как сделать так, чтобы это можно было потом проверить и не сломать".Безопасность и ограничения
Я довольно параноидально подошёл к этому:
- Есть жёсткий denylist. Нельзя трогать
bot/main.py, config.py, telegram_client.py, openrouter.py, модули проактивности и реакций и т.д.- Даже если она хочет править
bot/, изменения не применяются на лету — только через контролируемый рестарт.-
run_script по умолчанию выключен.- Есть отдельные флаги
ALLOW_SELF_IMPROVE и ALLOW_BOT_RESTART.В idle-режиме (когда я не пишу) у неё тоже есть ограничения. Она может анализировать и предлагать, но я могу выключить реальные правки одним флагом.
Что реально получилось
За время проекта она сама написала/сильно доработала скиллы.
Были случаи, когда она находила проблемы в своих же предыдущих правках и их исправляла. Самое приятное — это когда я просто говорю про какую-то боль, а она потом сама:
- создаёт задачу в бэклоге,
- в какой-то момент в свободное время её берёт,
- делает правку,
- прогоняет тесты,
- и потом сообщает мне, что "добавила поддержку X".
Что до сих пор сложно
Память и эволюция до сих пор остаются самыми трудоёмкими частями. Есть анти-дубликаты, но не идеально.
Для меня это интересный инженерный челлендж — научить агента безопасно улучшать самого себя.
- 👍 6
- 🤔 3
- 👾 1
