#ai

Патч базы сессий: урок надёжности для AI-агентов

Патч-релиз Hermes Agent чинит гонки блокировок в SQLite. Разбор: почему хранилище сессий, а не модель, решает судьбу AI-агента в проде.

  • Повод: патч, который чинит блокировки state.db
  • Когда агент забывает, что делал
  • TTU считает не скорость ответа, а время до рабочего состояния
  • Механика: почему SQLite ломается именно под конкурентной записью

Повод: патч, который чинит блокировки state.db

Hermes Agent 11 сентября выпустил патч v0.21.2 - закрыл баг, из-за которого state.db у части инсталляций терял устойчивость: второй писатель гасил чужую блокировку, здоровая база помечалась повреждённой, одна битая строка обрушивала список сессий. Релиз собрал 947 коммитов за четыре дня после v0.21.1. Повод рядовой - патч-версия. Мысль не рядовая: устойчивость хранилища сессий к параллельной записи решает судьбу агента сильнее, чем качество модели внутри него.

Когда агент забывает, что делал

  1. У сессии агента есть слой диалога с моделью и слой состояния: какие инструменты вызваны, что осталось незавершённым, какой контекст живёт между запусками. Hermes хранит это в SQLite (state.db).

  2. Когда два процесса пишут одновременно, а блокировки настроены неаккуратно, один писатель снимает лок другого раньше времени.

  3. Файл на диске цел, но читатель получает ошибку целостности и репортит рабочую базу как битую.

  4. Дальше - цепная реакция: одна строка с некорректными данными валит выдачу всего списка сессий, а не только своей записи.

TTU считает не скорость ответа, а время до рабочего состояния

Time to use - метрика, которую в KT.Team держат как главный критерий пользы инструмента: сколько времени проходит от запуска до результата, которому можно доверять. Быстрая модель с ломким хранилищем состояния даёт TTU, стремящийся к бесконечности в момент первого сбоя: пользователь получает полную потерю истории и необходимость чинить базу руками.

Для агентов, которые работают в фоне (cron-джобы, делегирование задач, multi-agent сценарии из последних релизов Hermes), эта цена растёт кратно - сбой одной сессии не локализован, он тянет за собой очередь.

Механика: почему SQLite ломается именно под конкурентной записью

SQLite по умолчанию - single-writer: один процесс пишет, остальные ждут или получают `SQLITE_BUSY`. WAL-режим (write-ahead log) снимает часть этого ограничения, разрешая параллельное чтение во время записи, но не отменяет дисциплину блокировок на уровне приложения. Если код рассчитывает соединения по одному на воркер вместо общего пула с явным таймаутом и ретраем на `SQLITE_BUSY`, второй писатель начинает конкурировать за лок-файл напрямую, а не через СУБД.

Именно так один сбойный поток может снять блокировку, которую держит другой, и превратить целую базу в подозрительную для последующих читателей.

Оценить, где ИИ даст эффект в вашем процессе

Почта clients@kt.team Telegram @kt_team_it

Простое выглядит простым, потому что кто-то сделал сложную работу

  1. Пользователь Hermes видит одну строку в changelog: «state.db patch release».

  2. За ней - переписанный слой connection handling, который в v0.21.0 сначала ускорил старт и файловые операции, а затем вскрыл именно этот класс гонок. 947 коммитов за четыре дня - нормальная цена за то, чтобы внешне ничего не поменялось, кроме одного: база больше не падает под нагрузкой.

  3. Это и есть тезис «простое не значит лёгкое»

  4. : чем незаметнее для пользователя инфраструктурный слой, тем дороже он стоил инженерной команде.

Что это значит для интеграторов и заказчиков

Релизы Hermes наращивают число vendor-hosted MCP-серверов - в v0.20.6 их уже больше 50, и агент подключает каждый как внешний источник состояния и инструментов.

Каждый такой сервер - ещё один писатель в общий контур.

Для компаний, которые строят AI-native процессы поверх нескольких агентов и MCP-интеграций, это означает: вопрос надёжности хранилища состояния и разграничения доступа между сервисами нельзя откладывать на потом, когда система работает с одним пользователем в dev-контуре.

В проектах KT.Team этот слой закрывают явно - через LLM & Security Gateway, который контролирует, какой агент и MCP-сервер имеет право писать в общий стейт и с каким приоритетом, вместо того чтобы полагаться на то, что база сама разрулит конкурентные записи.

Для Python- и Node.js-стеков это конкретно: пул соединений с ограниченным числом одновременных писателей, явный retry с backoff на `SQLITE_BUSY` или переход на PostgreSQL, если параллельная нагрузка растёт быстрее, чем позволяет однопроцессная модель SQLite.

Результат или увольнение

  1. Заказчик не разбирает, где именно агент подвёл - в модели, в оркестрации или в файле на диске.

  2. Он видит одно: инструмент, на который заложили бюджет, положил сессии в проде. AI-платформа, которая теряет состояние под нагрузкой, становится непригодной как продукт - независимо от того, насколько хороша модель внутри.

  3. Красивая демонстрация возможностей агента ничего не стоит без скучной инженерии под капотом. Патч, который чинит SQLite-блокировки, не выглядит эффектно в презентации для инвесторов.

  4. Он решает, доживёт ли агент до следующего квартала в чьей-то продуктивной инфраструктуре.

Источник

Hermes Agent v0.21.2 (v2026.9.11) - release notes, NousResearch

Обсудить статью: Патч базы сессий: урок надёжности для…

Укажите email или телефон, чтобы мы могли вам ответить.

Отправить через:

Нажимая кнопку, вы принимаете оферту и предоставляете согласие на обработку персональных данных.

Похожие кейсы

Все кейсы

Связанные решения

Все решения
ИИ‑мониторинг — автоматический контроль процессов и событийИИ-ассистент по Росреестру: выписки ЕГРН, проверка и мониторингGEO-оптимизация сайта: продвижение в нейросетях и ИИ-поискеАвтоматизация бухгалтерских процессов с ИИ: 13 сценариев

Статьи по теме

Подборка про ИИ в бизнесе

Видео по теме

Все видео
Shorts Какой “KPI” Amazon определила разработчикам в эпоху ИИ? AIКоманды и наймУправление
Shorts Не успеваешь за ИИ? Развивай коммуникацию и ответственность AI
Shorts ИИ не усиливает слабых! AI

Новости по теме

Все новости