Команда инженеров представила сетевой уровень с принципом fail-closed, который позволяет автономным ИИ-агентам работать в различных облачных средах без потери согласованности. Прототип выдержал 82 намеренно вызванных цикла хаоса, продемонстрировав 100% успех при событиях с одним эффектом и исключив дублирующие обновления даже при отключении питания.

Почему новая модель координации важна

Развертывание агентов на базе языковых моделей в нескольких облаках выявило уязвимое место: стандартные RPC-вызовы обрываются при разделении сети или достижении сервисом квоты. В такие моменты агент может действовать на основе непроверенного предположения, что приводит к повреждению общего состояния. Новая архитектура требует, чтобы каждое действие сопровождалось криптографическим доказательством, прежде чем любой компонент сможет его принять, превращая принцип «доверие по умолчанию» в «доверие только при наличии доказательств».

Пять правил управления для синхронизации агентов

  1. Транзакционная загрузка — оборачивайте все изменения состояния в одну транзакцию PostgreSQL для обеспечения атомарности.
  2. Канонический конверт — используйте фиксированный 10-кортежный формат для каждого сообщения, что делает парсинг и валидацию детерминированными.
  3. Разделение полномочий — храните прикладной код в Git, а миграции базы данных версионируйте отдельно, чтобы предотвратить случайное перекрестное загрязнение.
  4. Временные блокировки — позволяйте правам на задачу истекать автоматически, чтобы зависший агент не блокировал весь конвейер.
  5. Принцип fail-closed по умолчанию — помечайте любое требование (claim), не имеющее проверяемого доказательства, статусом HOLD, заставляя последующих агентов ждать, а не действовать наугад.

Вместе эти правила создают контракт с нулевым доверием (zero-trust): если вы не можете криптографически доказать, что действие произошло, система откажется его выполнять.

10-кортежный конверт, содержащий доказательство

Каждая передача данных на внутренней шине включает:

  • event_id — уникальный идентификатор исходного события
  • effect_id — идентификатор запрашиваемого изменения состояния
  • log_id — ссылка на запись в журнале аудита
  • producer_id — идентификатор агента-источника
  • schema_version — версия используемой схемы сообщения
  • session_epoch — логический час для упорядочивания внутри сессии
  • destination — целевой агент или сервис
  • route_status — текущее состояние маршрутизации (например, pending, held)
  • issued_at — временная метка создания
  • payload_digest — запечатанный с помощью HMAC хеш полезной нагрузки

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

Как система показала себя под нагрузкой

Инженеры провели 82 цикла хаоса. Результаты были следующими:

  • 100% успеха для событий, вызывающих один эффект; транзакция либо полностью фиксировалась, либо корректно откатывалась.
  • Ноль дублирующих изменений во время перебоев в электропитании, что подтверждает: транзакционная граница предотвращает частичную запись.
  • Быстрое восстановление блокировок благодаря автономным агентам очистки, которые сканировали истекшие права и освобождали их без участия человека.

Практические советы для архитекторов

  • Замените неаутентифицированные вебхуки логами, защищенными с помощью HMAC; эта защита служит криптографическим доказательством, необходимым для соблюдения правила fail-closed.
  • Храните секретные ключи в хранилище (vault), которое не смонтировано внутри любого контейнера или образа виртуальной машины.
  • Развертывайте легковесных агентов, единственная задача которых — очистка истекших блокировок; это предотвратит остановку системы при сбое основного агента.

На что обратить внимание в будущем

Подход во многом зависит от секретности ключей HMAC; храните свои секретные ключи за пределами папок облачных рабочих пространств.

Если сообщество сможет решить эти две задачи, автономные сети с принципом fail-closed могут стать стандартом для любого мультиагентного развертывания, где недопустима даже единая точка несогласованности.