Что выносить в обвязку агента, а что оставлять модели

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

· 2 мин чтения

Продовые агенты ломаются не там, где все ждут. Хуже галлюцинации или плохого ответа другое: система отвечает пользователю, выглядит здоровой, а в долговременной памяти дыра. Следующий ход модель может отработать уверенно, но рассуждать по неполной реальности. Винод Говиндараджан из OpenAI на QCon AI разобрал именно этот класс сбоев и предложил контракт, по которому стоит строить обвязку (harness, систему вокруг модели).

Главная мысль доклада: модель — это двигатель, обвязка — это руль, тормоза и чёрный ящик. Мощный мотор без тормозов — это не автономность, а угроза с хорошим разгоном. Производственный контракт звучит так: модель предлагает, обвязка коммитит, чек (receipt) подтверждает.

Четыре границы, которые решают всё

  1. Один владелец факта и один путь воспроизведения. Если агент использует факт в следующем ходе, у этого факта должен быть владелец. Им выступает системная граница, чья постоянная запись становится источником правды. Календарь живёт у календарной системы, статус тикета — у тикетинга, текст хода — у лога транскрипта. В OpenClaw Telegram-доставка прошла, а ход не попал в ожидаемую сессию. Пользователь видит ответ, будущий контекст получает дыру.
  2. Порядок мутаций. Если два писателя касаются одного изменяемого слоя, порядок задаёт обвязка. «Последний пишущий выиграл» — это не модель согласованности, а классический сбой распределённых систем.
  3. Область полномочий и ограничители выполнения. События приходят из разных мест: вебхук, таймер, чат, внешняя система. Управляющий слой (control plane) маппит их в ключ сессии, ключ определяет границу состояния, сессионная очередь (session lane) даёт одного писателя на путь коммита, глобальный дроссель защищает всю систему.
  4. Подтверждение действия на видимом пользователю крае. Транскрипт говорит, что агент сказал, а не что система реально сделала. Чек — это запись, которая переживает прогон: что разбудило систему, какое состояние она унаследовала, что предложила модель, что оценила политика, что выполнилось, что подтвердил видимый край.

Почему это ломается именно у агентов

Сбои знакомые: идемпотентность, ретраи, блокировки, порядок, границы состояния. С распределёнными системами инженеры живут давно. У агентов добавляются свои усилители.

  • Модель выбирает инструменты динамически, и они сидят вокруг вероятностного планировщика.
  • Контекст для каждого хода собирается заново. Если загрузка тихо падает, ответ будет связным и неверным.
  • События приходят одновременно от пользователя, таймеров, вебхуков, субагентов и результатов вызовов инструментов.
  • Система действует на большем числе поверхностей: сообщения, базы, команды, рабочие процессы.

Что проверить у себя

  1. Зафиксируйте сессионную очередь. Один ключ сессии — это один писатель на путь коммита. Глобальный дроссель держите отдельно.
  2. Разделите внутренние сигналы и видимую работу. Хартбит — это сигнал живости, а не задача для доставки. Иначе внутренний токен пересечёт не ту границу и закроет окно скипа.
  3. Чек обязателен. Что предложено, что одобрено (approval), что закоммичено на видимом крае. Транскрипт чека не заменяет.
  4. Перед релизом проверьте два сценария: доставка прошла, а запись в сессию нет; два валидных события приходят одновременно и пишут в один слой.