Проблема ненадёжного кода агентов ведёт к созданию TEMPUR — формальной среды для проверяемых спецификаций

Проблема ненадёжного кода агентов ведёт к созданию TEMPUR — формальной среды для проверяемых спецификаций

Связка 1

Начальное состояние: Код, создаваемый ИИ-агентами для критически важных систем (например, баз данных), ненадёжен, размыт и неструктурирован; каждый агент импровизирует разрозненные инструменты под локальные задачи, что не позволяет масштабировать производство надёжного ПО.
Преобразование: Создание TEMPUR — формальной среды, в которой агент не генерирует произвольный код, а создаёт точные декларативные спецификации (чертежи) намерения и предметной области: состояния, переходы, эффекты, инварианты и политики; эти спецификации компилируются вне LLM (Templar) в формальную таблицу переходов, которая проверяется многоуровневым верификатором (алгебра автоматизации, достижимость графа состояний, property-based тесты), после чего загружается в рантайм.
Конечное состояние: Созданный код становится повторяемым, проверяемым и многократно используемым; операционная модель (конечный автомат) становится явной, а не неявно размазанной по коду; агенты могут динамически и безопасно изменять спецификации без прохождения полного CI/CD, что позволяет строить «тёмные фабрики» (программные фабрики, работающие без человека) для критически важной инфраструктуры, как в примере с Helix, снижая затраты в 2–5 раз и обеспечивая надёжность, сопоставимую с авиационными и финансовыми стандартами.

---

И вы начинаете видеть эту размытость. Вот где я почувствовал, что нам нужно что-то более структурное. Если агенты будут строить и эксплуатировать большие части наших систем баз данных, которые являются критически важными, им нужен эквивалент этой концепции станка, которую я пытаюсь внедрить. Итак, TEMPUR — это станок.

Идея в том, что вместо того, чтобы агент изобретал разрозненные инструменты для каждой локальной потребности, он создает точные спецификации намерения и предметной области. Это станок в том же смысле, что и кондуктор или станок с ЧПУ. Вы видели такие? Компьютеризированные горячие станки, где вы задаете спецификации того, какой должна быть резьба винта, что должно быть. Это чрезвычайно повторяемо.

Вы можете запускать их и строить самолеты и тому подобное. В данном случае агент не импровизирует конечный механизм каждый раз. Он создает точное описание и итеративно работает с Tempur или механизмом, подобным TEMPUR, чтобы сначала заставить что-то работать, а затем превратить это в нечто повторяемое, проверяемое и многократно используемое, чтобы вы могли построить программную фабрику вокруг вашей кодовой базы. Такова концепция темной фабрики.

Саймон Уилсон из simonwillison.net — довольно удивительный блог. Я думаю, он один из самых влиятельных голосов в области ИИ сейчас, обучающий работе с агентами и созданию программного обеспечения. Он популяризирует фразу «темная фабрика». Я думаю, это довольно хорошее описание программного процесса, где агенты продолжают работать без людей на виртуальном заводском полу. Можно выключить свет. Теперь роль человека заключается в проектировании фабрики, ограничений, результатов и цикла верификации, чтобы эта штука могла работать часами, днями и неделями, производя то, что вы хотели. Так что нечто вроде Tempur может заполнить эту роль станка для строительства таких фабрик.

Давайте конкретно рассмотрим тёмную фабрику на примере Helix. Я рассказывал о Helix — это стриминговая служба, похожая на Kafka. Вероятно, это один из пяти самых дорогих сервисов, которые мы запускаем в Datadog, как Kafka. Поэтому мы зеркалировали наши производственные нагрузки с помощью Helix.

В некоторых случаях мы действительно считаем, что он может быть значительно дешевле нашего текущего производственного решения. Можете в это поверить? Мы потратили около недели на его создание, начали зеркалирование и увидели возможности снижения затрат в два-пять раз. Но чтобы перейти от этого многообещающего состояния к промышленной эксплуатации, системе ещё предстоит пройти долгий путь — она должна доказать, что может работать, и что с ней могут работать несколько человек, а не только тот, кто её создал. Поэтому мы создали набор синтетических нагрузок, моделирующих наши производственные профили, и построили фабрику.

Итак, программная фабрика для Helix использует Tempur тремя различными способами. Во-первых, как плоскость управления агентами для облачных управляемых агентов, где сессии, роли, очереди задач и операционный жизненный цикл управляются более точно. Во-вторых, как способ для агентов создавать свои собственные инструменты с помощью небольших приложений Tempur, связывая инструменты STLC, такие как Git CI и развёртывание. И в-третьих, как управляющий API Helix — интерфейс и поверхность жизненного цикла вокруг плоскости данных Helix для выполнения этой нагрузки. Это стало для меня сюрпризом.

Сюрприз заключался в том, что это начало казаться более общим, чем просто инфраструктура агентов.

Много программного обеспечения, если присмотреться, — это просто логика управления вокруг баз данных, API вокруг состояния, политики вокруг мутаций, переходы жизненного цикла, интеграции с внешними системами. Так что Tempur может быть универсальным в том смысле, что его можно применить к любому ПО, имеющему описанную мной форму.

Прежде чем я углублюсь в то, как работает Tempur, вы, возможно, задаётесь вопросом: чем это отличается от просьбы к Cloud Code создать CRUD-приложение, например на TypeScript или Python? Cloud справляется с этим очень хорошо.

Мы видели много PR и много кода. Однако в обычных CRUD-приложениях логика управления разбросана по маршрутам, ограничениям базы данных, сервисному коду, фоновым задачам и документации. Всё это может иметь хорошие тесты и покрытие, но операционная модель, которая обычно имеет форму конечного автомата, в основном неявна в кодовой базе.

Идея в том, что TEMPUR делает этот конечный автомат явным. Это не особенно ново. У нас были такие среды выполнения, как Erlang, Erlang OTP на протяжении десятилетий, среды выполнения акторов, а в последнее время — движки рабочих процессов и среды выполнения с долговечным исполнением, такие как Temporal. Все они популяризировали эту точную среду выполнения, позволяющую запускать неуязвимые приложения.

Итак, давайте посмотрим на некоторые внутренности Tempur, чтобы понять. На этапе сборки Tempur запрашивает эту операционную область, которую я описываю, — модель того, что вы хотите, в виде чертежа. Например, какие состояния? Какие переходы допустимы? Кто может их запрашивать? Какие эффекты разрешены? Какие инварианты должны соблюдаться? Что произойдёт, если вызов инструмента завершится неудачей? Агент часто будет итеративно приходить к этому чертежу за несколько шагов.

Представьте, что это работает в режиме плана, чтобы прийти не к markdown-файлу какого-то описания, а к этим точным декларативным артефактам. И тогда у вас есть аналог компилятора, такой как Templar, который проверяет это и может развернуть в рантайм. Есть и другие рантаймы, которые это делают, например, Arlang Beam, если вы о нём слышали. Кто-нибудь слышал об Arlang Beam? Вот именно.

Таким образом, путь выполнения ощущается так же, как и любой другой API в стиле CRUD. Вы не заметите разницы. Важно отметить, что агент не генерирует произвольный код приложения напрямую. Мы подняли уровень абстракции. Он генерирует структурированное описание, которое компилируется в форму рантайма.

Этап компиляции находится вне LLM. Это то же самое, что написать код на Rust и передать его компилятору Rust. Итак, Tempo превращает этот чертёж в нечто, называемое формальными переходами состояний. Это очень распространено в функциональном программировании и акторных рантаймах, если вы ими пользовались. Это самая важная техническая деталь.

«Формальный» здесь не означает, что доказано каждое возможное свойство. Это не теоретически. Это означает, что базовая форма приложения представлена как точная система переходов. И когда у вас это есть, это гораздо лучшая основа для рассуждений как для людей, так и для агентов, чем произвольный код. Прошу прощения за совершенно бруталистский дизайн этого слайда без подсветки синтаксиса, но это спецификация, созданная агентом.

Для развертывания Helix эта спецификация выглядит так: состояния, действия и триггеры. Сегодня утром, когда я увидел анонс облачных управляемых триггеров, мне пришла в голову идея. Возможно, это может быть просто транзитным механизмом. Вы можете объявить триггер здесь, а затем облако будет их выполнять. Но идея в том, что вы определяете действия и триггеры вашего состояния.

Или это делает агент. Облако делает это. И в данном случае описание развертывания «начать раскатку» допустимо только в состоянии «запланировано», или сущность переходит в состояние «раскатка», и это запускает побочный эффект, например, обновление stateful-набора Kubernetes, что не является идемпотентным. А затем приходит обратный вызов, который сообщает, отмечать ли прогресс или завершить ошибкой. Что делает Templar — этот артефакт становится декларативным.

Итак, что делает Templar: он берет это и генерирует из этой спецификации таблицу переходов — концепцию, в которой критическая управляющая логика является данными. Это не просто спагетти-код, императивно закодированный. Это просто данные, которые взаимозаменяемы, проверяемы и не скрыты в какой-либо импровизированной цепочке методов сервисов. Агентам с этим проще работать, и они могут динамически изменять это с безопасностью. В этом и заключается обещание.

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

Так что в этом случае, если развертыванию нужно новое состояние или путь отката, агент может внести целевое изменение спецификации и горячо перезагрузить его. Таким образом, скорость итерации становится еще выше. Не нужно проходить через CI, а затем деплоить и все такое.

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

И у нас есть политические шлюзы. Поскольку таблица переходов похожа на данные, Temporal оценивает переходы состояний и политические решения вместе, например, кто может изменять развертывание, какие действия может выполнять агент-оператор — например, команда агентов, работающих на темной фабрике. Вы можете сказать, что эти агенты-операторы могут делать только определенные вещи, или что эти действия запрещены для агента-строителя. И вы можете независимо указать как человек: можно ли повторно выполнить завершенное развертывание? Или может ли неудачный результат инструмента продолжить свой путь развертывания? И так далее.

А затем у нас есть побочные эффекты, система эффектов — также очень популярная в типизированных средах выполнения, таких как TypeScript. FX — это намеренно маленькие, типизированные операции в Templar.

Сохранение их маленькими предотвращает превращение конечного автомата в черный ход для произвольного поведения приложения. Но если вам нужно произвольное поведение приложения, вы можете упаковать его как модули Wasm. Знакомы с Wasm? Никто? Ладно, несколько рук.

Так что это место, где может жить произвольный код, сгенерированный LLM. Это очень узкое место. Это означает, что отладка становится проще. И последний строительный блок Templar — верификатор. Верификация — это сейчас узкое место практически для всего.

Мы видели так много анонсов и обсуждений на эту тему. Поэтому в Templar верификатор — это шлюз перед загрузкой таблицы переходов в среду выполнения. Это позволяет ему сказать: «Это безопасно, вы можете загрузить это в работающую систему». И он многоуровневый, как швейцарский сыр. Не все уровни должны находить все исчерпывающе.

Агент Claude в целом очень хорошо принимает решения: «Нужно ли мне запускать все уровни или только некоторые?» Что, похоже, использует вывод компилятора. Уровень один проверяет алгебру автоматизации. Уровень два проверяет модель достижимого графа состояний: может ли какой-либо путь достичь плохого состояния?

А уровень три запускает расписания, внедряет сбои: выживают ли инварианты в условиях временных сбоев и так далее. И уровень четыре использует property-based тесты, которые я настоятельно рекомендую — мы должны начать изучать этот механизм рандомизированного тестирования с последовательностями действий. Все это не является исчерпывающим с первого дня. Каждый пробел в обнаружении дополняет верификатор. Я также слышал, как Борис упоминал эффект накопления: вы находите тесты, а затем продолжаете исправлять пробелы.

Отсутствующее условие, обнаруженное в продакшене или симуляции, может быть добавлено в модель или набор тестов. И это накапливается. Так куда все это идет? Я не знаю. То есть, я не могу много предсказать о том, куда это может привести.

Но идея в том, что каждый артефакт приложения Tempur или бандла краток — очень мало строк, помещается в голове.

Я много времени занимался эксплуатацией критически важной инфраструктуры для Datadog, меня будили по ночам тысячи раз за последние три-четыре года. Вы не сможете удерживать в голове сложную критически важную логику, когда вам нужно её эксплуатировать.

Для сложной бизнес-области, например банковской или финансовой системы, вы всё равно должны иметь возможность кодировать свою бизнес-логику таким образом — чтобы человек мог её прочитать. Если сгенерированный артефакт — это тысячи строк запутанного кода, мы возвращаемся к тому, с чего начали. И я пока не уверен, что LLM может полностью проверить и подписать такой код.

Если это несколько небольших артефактов с явными ролями, где и люди, и агенты могут модифицировать систему, не нарушая всё вокруг, — я всё равно считаю, что это просто хорошая системная инженерия. Высоконадёжное ПО, например в авиации и финансах, строилось так десятилетиями. Однако стоимость такой строгости с людьми была слишком высока для обычного ПО — до сих пор. Агенты меняют эту расстановку.

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

И моё утверждение: для ПО, создаваемого агентами, нам нужна такая строгость, чтобы масштабироваться дальше, если мы действительно хотим строить базы данных и запускать их в production.