Найкраща база даних для агента-кодувальника: PostgreSQL для зберігання стану, гібридний пошук для отримання результатів.

Вибирайте базу даних для агента-кодувальника, орієнтуючись на те, що він робить протягом дня, а не на позначку ШІ. Агент, який запускає команди в ізольованому середовищі, викликає інструменти, передає логи, створює файли, повторює невдалі кроки та продовжує роботу після перерв, переважно займається обліком із побічними ефектами. Для такого обліку стандартним вибором є PostgreSQL. Сховище векторів, таке як Weaviate, знаходить своє місце пізніше як окремий шар, коли продукту потрібно знаходити схожі минулі помилки та їхні рішення за змістом.

Почніть з одного виклику інструменту

Слідкуйте за одним викликом інструменту в межах системи. Перед його виконанням платформа позначає виклик як розпочатий, пов’язує його з процесом виконання, резервує ключ ідемпотентності, вказує, яке ізольоване середовище використовується, та відправляє на чергу подальші дії. Після завершення вона фіксує статус, метадані вихідних даних та результати, оновлює загальні показники використання та просуває основний процес виконання далі.

Ці записи є одним логічним переходом. Завдяки транзакціям вони або виконуються разом, або зовсім не виконуються, і інші сесії ніколи не бачать напівзавершеного стану. Тепер розглянемо ситуації збоїв. Процес зупиняється між станами „Інструмент завершено“ та „Виконання на рівні advanced“, і процес відновлення має бути детермінованим. Спроба виконання надходить двічі, і умова унікальності має відхилити дублікат. Артефакт вказує на виконання, якого не існує, і іноземний ключ має відхилити відповідний рядок. Тут немає нічого екзотичного. Це звичайні завдання баз даних, на які постійно покладається кодувальний агент, тому вони мають більшу цінність, ніж будь-який „спеціалізований“ маркетинг.

Дані є взаємопов’язаними

Основні елементи агента виконання не є загадковими, і вони пов’язані між собою:

• Виконання містять інформацію про стан життєвого циклу, власника, робоче простір, модель, часові мітки, бюджет та кінцевий результат.
• Кроки — це сплановані або виконані одиниці роботи з взаємозалежностями між ними.
• Виклики інструментів зберігають вхідні дані, вихідні дані, статус, затримку, кількість спроб та ключі ідемпотентності.
• Виконання в пісочниці описують середовище, метадані команди, код вихіду, використання ресурсів та причини завершення.
• Події створюють історію, яку можна лише додавати, для дебаггінгу, стрімінгу та повторного відтворення.
• Артефакти вказують на патчі, звіти, створені файли чи місця зберігання об’єктів.
• Точки контролю зберігають інформацію, необхідну для продовження роботи потоку завдань.

Кожен елемент потребує стабільної ідентичності та чітких посилань на інші елементи. Первинні ключі, унікальні обмеження, контрольні обмеження та іноземні ключі ускладнюють створення недійсних станів, а іноземні ключі зокрема гарантують, що кожен виклик інструменту належить до реального запуску, а кожен артефакт можна простежити до його творця.

Зберігайте поля, які забезпечують координацію, у типованих колонках із належними індексами: статус, користувач, ідентифікатор запуску, часові мітки, номер спроби та ключ ідемпотентності. Вони забезпечують можливості планування, фільтрації, зберігання даних та створення панелей керування. Приховування їх у одному великому, неструктурованому 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 з локальним використанням: контракти, перевірки та слоти для коду для команд, які впроваджують цю модель.