Лучшая база данных для кодинг-агента: PostgreSQL для хранения состояния, гибкий поиск для восстановления информации.

Выбирайте базу данных для агента-программиста, исходя из того, что он делает в течение дня, а не из метки ИИ. Агент, который запускает команды в изолированной среде, вызывает инструменты, передаёт логи, создаёт файлы, пытается снова выполнить неудачные шаги и возобновляет работу после прерываний, в основном занимается учётом операций с побочными эффектами. Для такого учёта стандартным надёжным решением является PostgreSQL. Хранилище векторов, такое как Weaviate, находит своё применение позже, в качестве отдельного слоя, когда продукту необходимо находить по смыслу похожие прошлые сбои и решения.

Начните с одного вызова инструмента

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

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

Данные имеют реляционную структуру

Основные сущности агента выполнения не являются таинственными, и они связаны между собой:

• Запуски хранят информацию о состоянии жизненного цикла, владельце, рабочем пространстве, модели, временных метках, бюджете и окончательном результате.
• Шаги — это запланированные или завершённые единицы работы с взаимозависимостями между ними.
• Вызовы инструментов хранят входные данные, выходные данные, статус, задержку, количество попыток и ключи идемпотентности.
• Выполнения в песочнице описывают среду, метаданные команды, код выхода, использование ресурсов и причины завершения.
• События формируют историю, доступную только для добавления новых записей, для отладки, стриминга и воспроизведения.
• Артефакты указывают на патчи, отчёты, сгенерированные файлы или местоположения в хранилище объектов.
• Точки контроля хранят информацию, необходимую для возобновления рабочего процесса.

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

Храните поля, необходимые для координации, в структурированных колонках с соответствующими индексами: статус, арендатор, идентификатор задачи, временные метки, номер попытки и ключ идемпотентности. Они обеспечивают возможности планирования, фильтрации, хранения данных и формирования дашбордов. Скрытие их внутри одного большого неструктурированного JSON-документа существенно затрудняет соблюдение этих правил.

Где должен использоваться jsonb

Инструменты быстро меняются. Одни возвращают диагностическую информацию компилятора, другие генерируют события браузера, а третьи сообщают метаданные репозитория. Фиксированная колонка для каждого возможного поля была бы неэффективной, в то время как jsonb подходит для тех элементов, которые меняются: аргументов инструментов, ответов поставщиков, настроек сандбокса и метаданных моделей. PostgreSQL позволяет выполнять запросы к JSON с использованием операторов и выражений пути, а также индексировать ключи и значения с помощью GIN; соответствующие компромиссы описаны в официальном руководстве.

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

Подбор хранилища в соответствии с схемой доступа

Не всё должно храниться в основной базе данных. Краткие выдержки из файла stderr, нормализованные подробности ошибок, коды выхода и поисковые резюме могут находиться рядом с записью об исполнении. Большие потоки консоли, архивы репозиториев, бинарные файлы, скриншоты и результаты сборки обычно сохраняются в объектном хранилище, где PostgreSQL обращается к ним через надёжные метаданные и хэш-суммы.

Такое разделение позволяет сохранять небольшой размер строк при одновременном сохранении информации о происхождении данных. База данных остаётся источником истины относительно того, существует ли тот или иной артефакт, какая процедура его создала, где он находится и как применяется правило хранения, в то время как объектное хранилище позволяет более экономично хранить крупные неизменяемые данные. Одно предупреждение: никогда не считайте, что загрузка прошла успешно, пока у рабочего процесса нет плана восстановления в случае частичной неудачи.

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

Протокол записи имеет такое же значение, как и движок

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

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

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

Сохраняйте неизменными исходные события там, где важен аудит, и при необходимости воссоздавайте на их основе прогнозы.

Храните времена истечения сроков и случаи «неизвестного результата» отдельно от подтверждённых сбоев.

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

Когда слой поиска оправдывает себя

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

В таком поиске по-прежнему важны точные токены: имена исключений, версии пакетов, коды компилятора, флаги, имена файлов и хэши. Однако пользователи описывают одну и ту же проблему по-разному. Чистый поиск по ключевым словам упускает концептуальные связи, в то время как чистое сравнение векторов может недооценить буквальные строки, на которые опираются инженеры. Гибридный поиск учитывает оба подхода. Weaviate — это один из движков, который одновременно выполняет векторный поиск и поиск по ключевым словам с алгоритмом BM25, объединяя полученные оценки в единый рейтинг, так что буквальный код вроде ERR_MODULE_NOT_FOUND вносит вклад в оценку на основе ключевых слов, а фраза «во время выполнения невозможно разрешить импортированный пакет» — в оценку на основе семантики.

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

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

Пятичастная структура справочника

1. Официальное состояние в PostgreSQL. Операции выполнения, шаги, вызовы инструментов, результаты работы в среде тестирования, метаданные объектов, точки контроля и отношения доступа.
2. Большие объемы данных в хранилище объектов. PostgreSQL хранит информацию о местоположении, хэшах, типах контента, владельцах и сроках хранения.
3. Папка для сохранения подтвержденных изменений. Рабочие процессы передают обновления интерфейса, планируют последующие действия и создают запросы к базе данных, не взаимодействуя с неподтвержденными данными.
4. Получение документов из векторного или гибридного индекса по мере необходимости. В результате возвращаются краткое описание, нормализованные сообщения об ошибках, команды, выбранные фрагменты журнала, описания исправлений и метаданные с возможностью фильтрации.
5. Обработка результатов поиска с использованием PostgreSQL. Индекс находит подходящие кандидаты, а база данных остается источником информации о текущем состоянии и правах доступа.

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

Чего следует избегать на раннем этапе

• Использование векторной базы данных только потому, что имеется нейросеть типа LLM. На начальном этапе операционные вопросы в основном имеют структурированный характер: запросы о выполнении операций для определенного пользователя в заданном статусе, шагах, которые недавно завершились с ошибкой, медленных вызовах инструментов или выполнениях, связанных с конкретным коммитом. Для их решения достаточно обычных индексов.
• Использование одного JSON-блока для хранения всего состояния агента. Это приводит к краткосрочной удобству в ущерб слабым ограничениям, сложным процедурам одновременных обновлений и затрудненным запросам к жизненному циклу данных. Гибкие метаданные — это хорошо, но неструктурированная система хранения записей — нет.

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

Чек-лист

Выбирайте PostgreSQL в первую очередь, если вам нужно:

• многозаписные транзакции ACID для хранения записей выполнения,
• обеспечение связей между запусками, шагами, вызовами, пользователями и результатами работы,
• безопасные попытки повтора и контроль конкурентности,
• простой фильтр по статусу, времени, владельцу, стоимости или итогу,
• метаданные в формате jsonb, которые можно продолжать запросать,
• надежные записи для восстановления данных и аудита.

Добавьте гибридный механизм поиска, если вам также необходимо:

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

Краткие ответы

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

Достаточно ли jsonb для метаданных агентов? Часто да, особенно при изменчивости данных инструментов и деталей, специфичных для поставщика, при условии, что типизированные столбцы содержат идентификаторы и поля жизненного цикла. Он дополняет схему, но не заменяет её.

Почему использовать гибридный поиск для логов? Инженерные данные сочетают в себе точные токены и естественный язык. Алгоритм BM25 выделяет точные коды, названия пакетов и имена файлов, в то время как векторный поиск связывает описания одной ошибки, сформулированные по-разному.

Лучший подход — это разделение труда, а не соперничество между реляционными и векторными системами. PostgreSQL обеспечивает основу для транзакций: запуск процессов, ведение журналов, хранение истории вызовов инструментов, метаданных, точек контроля и промежуточных результатов. Когда история выполнения превращается в ценный источник знаний, гибкий слой поиска добавляет возможность быстрого восстановления информации. Postgres отвечает за управление состоянием, а индекс поиска — за быстрое нахождение данных.

Связанные статьи

• Семь AI-агентов для программирования, которые стоит сравнить до конца 2026 года — сравнение Claude Code, Cursor, Copilot, Codex, OpenCode, Devin и Antigravity CLI: что каждый из них делает лучше всего, каковы их цены по состоянию на август 2026 года и как их можно комбинировать.

Практические заметки: Qwen 3.8 наконец выпущен, агентный кодирование уровня Opus с локальным использованием — Подробное руководство по Практическим заметкам: Qwen 3.8 наконец выпущен, агентный кодирование уровня Opus с локальным использованием: контракты, проверки и готовые блоки кода для команд, внедряющих эту модель.