farm: перетворення AI-агентів на інфраструктуру з локального контексту

Як ми побудували farm як орієнтований на AI рантайм: чергове, ізольоване, аудитоване виконання з синхронним та асинхронним режимами, session worktrees та інтеграцією інструментів через MCP.

Вступ

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

Ми побудували farm з одним ключовим підходом: якщо агенти торкаються реального коду й інфраструктури, виконання має виглядати як сервіс — з можливістю ставити в чергу, ізольований, з повторними спробами, аудитований та інтегровний.

Постановка проблеми (контекст і виклик)

Нам був потрібен повторюваний і контрольований спосіб запускати AI-агентів на віддалених хостах, де справді існують облікові дані, мережевий доступ і обчислювальні ресурси. Паралелізм не міг пошкоджувати стан, а багатоходові робочі процеси вимагали стійкої безперервності сесії.

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

Перший крок: рішення з проєктування, виходячи з операційності та надійності

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

Сесії стали абстракцією збереження стану: вони можуть відображатися на git worktrees для робочих процесів з кодом або на шари контексту на основі сховища для процесів без коду.

Проста схема

Клієнтські запити надходять до API-сервісу через MCP чи REST, стан зберігається в Postgres, асинхронні завдання проходять через NATS JetStream, воркери виконуються в ізольованих session worktrees, а результати зберігаються й доставляються через колбеки.

Фаза 1 — обгортання агента (контракт виконання)

Перша фаза полягала в тому, щоб зробити виклик передбачуваним через контракт-обгортку: контроль життєвого циклу, обробка таймаутів та стандартизоване захоплення виводу (stdout, stderr, структуровані результуючі payload'и).

Цей фундамент перетворює виклик інструменту на поведінку рантайму, яку операційна команда може аналізувати.

Фаза 2 — асинхронний пайплайн (черга, воркери, повторні спроби)

API зберігає запити на виконання, асинхронний режим публікує завдання в NATS JetStream, а пул воркерів обробляє їх з контрольованим паралелізмом. Статус та історія спроб відстежуються протягом усіх станів життєвого циклу виконання.

Колбеки можуть доставляти payload'и завершення з політиками повторних спроб та backoff для надійності на боці отримувача.

Фаза 3 — репозиторії та контекст (кеш + worktrees)

Агентам потрібні спільні репозиторії без спільного змінюваного робочого простору. Ми розділили це на два шари: стабільний кеш репозиторію та ізольований worktree для кожної сесії.

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

Фаза 4 — MCP всюди (інструменти для агента й клієнта)

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

На цьому етапі farm — вже не просто API-ендпоінт; це стає поверхнею платформи.

Фаза 5 — безпека та ізоляція

Оскільки farm працює на віддалених хостах і торкається активів, суміжних з продакшном, базова безпека обов'язкова: обмежений JWT-доступ, шифрування чутливих полів у стані спокою, підписи цілісності колбеків та ізоляція робочого простору за задумом.

Мета — не ідеальний імунітет. Мета — обмежений радіус ураження та аудитовані режими збоїв.

Дилема синхронного виконання

Синхронне виконання — це насамперед функція користувацького досвіду для короткочасних завдань. Асинхронне виконання — стандарт надійності для серйозних навантажень, де важливі черги, повторні спроби й контроль пропускної здатності.

Явне розмежування обох режимів дозволяє командам одночасно оптимізувати швидкий зворотний зв'язок і стійку доставку.

Вплив і результат

farm перетворив виконання агентів на можливість рантайму, яку можна планувати і якою можна керувати.

Технологічний стек

Fastify API, Node.js і TypeScript, Postgres, NATS JetStream, Docker, git worktrees, JWT-автентифікація, шаблони шифрування у стилі AES-256-GCM для збережених секретів, колбеки з HMAC-підписом та транспорти MCP.

Поточне впровадження

farm вже використовується для реальних навантажень: заплановані продуктові завдання, потоки автоматизації AI SDLC, ізольовані копілот-сесії для технічних команд та спрощені шляхи доступу для нетехнічних користувачів.

Тривалі виконання агентів також використовуються для безперервного аналізу та операційних пайплайнів спостережуваності.

Підсумок

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

Читайте також

Послуги Evergreen