Глосарій

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

Велика ідея

Агент (Agent)

AI-асистент для одного магазину. Технічно це просто дані — конфіг + пам’ять + історія — що зберігаються як рядок у базі. «Оживає» лише поки обробляє запит. Див. Що таке Agentfy.ai 2.0?

Ephemeral (ефемерний)

«Існує лише мить». Рантайм нашого агента ефемерний: працює під час одного ходу чи задачі, потім зникає. Протилежність always-on.

Always-on

Сервіс, що працює безперервно, робить він щось чи ні (і весь цей час коштує грошей). Модель 1.x тримала по одному always-on серверу на агента; 2.0 уникає цього для агентів.

Scale-to-zero

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

Хід (Turn)

Один цикл запит → відповідь агента: надходить повідомлення, мозок його обробляє, виходить відповідь.

Рухомі частини

Мозок (Brain)

Частина, що думає й відповідає. Це сервіс api, запущений на один хід — окремого «сервера агента» немає. Див. Як це працює.

Руки (Hands)

Частина, що робить роботу на справжньому комп’ютері (скрипти, файли, браузер, довгі задачі). Її дає воркер.

Воркер (Worker)

Пісочниця на вимогу, що і є руки. Контейнер зі справжньою ОС (bash + Chromium), який виконує одну задачу й завершується — створюється під задачу як Kubernetes Job. Див. Worker.

Задача (Task)

Одиниця роботи, яку мозок передає воркеру (наприклад, «спарсити цю сторінку», «згенерувати цей файл»).

Тип агента

Чим агент є — standard (те, що створює власник) або concierge (системний агент команди). Одна декларація каже, що дозволено кожному типу, і її читають і сервер, і інтерфейс. Тип призначає лише сервер. Див. Склад.

Консьєрж (Concierge)

Власний системний агент команди — один на команду, персона приходить з коду. Відповідає в чаті команди і вміє діяти на агентах команди. Його не можна перейменувати, видалити та експортувати. Він рядок Agent такий самий, як усі інші — один на команду, його id виводиться з id команди, — тому його листування зберігається, потрапляє у списки, читається звичайними агентськими шляхами і переживає перезавантаження сторінки.

Те, що він каже про вміння продукту, іде з однієї декларації можливостей, а не з прози в персоні. Усе, чого декларація не покриває, він трактує як «не берусь стверджувати», а не як «Agentfy цього не вміє».

Автозапуск (heartbeat)

Агент сам будить себе за інтервалом і виконує повноцінний хід без чийогось повідомлення. Кому час, вирішує єдиний глобальний обхідник; зайнятий агент пропускається, а тіку, якому нема чого сказати, нема чого й зберігати. Див. Автозапуск.

Блокування ходу (turn lock)

Те, що змушує агента виконувати один хід за раз, — і те, що автозапуск перевіряє перед тіком. Див. Модель рантайму.

Профіль виконання

Чи дозволені агентові руки взагалі і скільки машини він під них отримує — none · light · browser · heavy · warm. Це колонка в агента, за замовчуванням none, тому жоден реліз не видає руки агентові, який їх не мав. Агент з none не чіпає ні черги, ні кластера. Див. Склад.

Грант інструментів

Які з інструментів воркера можуть дістатися сесіям цього агента. Підмножина тих десяти імен, які поділ інструментів віддає рукам; за замовчуванням порожньо — тобто воркер без інструментів, а не воркер з усіма.

Історія роботи

Власний короткий запис агента про те, що він робив — відповів, зробив, відмовив — по одному читаному рядку, з «було → стало» на всьому, що він змінював. Відмови — такі самі рядки, як усе інше. Див. Історія роботи.

Адміністратор платформи

Обліковий запис, якому видно всі команди, а не лише свою. Це не те саме, що адміністратор усередині команди, і видається воно навмисно непросто. Див. Роль платформи.

Знання (Knowledge)

Те, що агент знає про магазин — його каталог і документи — зберігається в окремому сервісі й запитується на вимогу. Побудовано на LightRAG.

Пам’ять (Memory)

Пам’ять агента: короткочасна (поточний діалог) і довготривала (факти між діалогами). Див. Чат → Пам’ять.

Як це деплоїться

api

Головний деплой: Core (центр керування) і ефемерний мозок — один образ. Див. З чого складається.

app / admin

Два Nuxt-застосунки: app — кабінет клієнта, admin — адмін-панель.

Control plane / data plane

Спосіб ділити систему за життєвим циклом: control plane працює постійно (api Core, вебзастосунки); data plane — це ефемерний мозок + руки, що працюють лише на вимогу. Це не дроблення за фічами.

Docker-образ (Container image)

Запакована, запускна збірка однієї частини (api / app / admin / worker). Кожна частина постачає свій Dockerfile. Див. Docker-образи.

Як організований код

CleanSlice

Архітектурний фреймворк, на якому зроблені ці застосунки — full-stack NestJS + Nuxt, організований у вертикальні слайси. (Доки CleanSlice.) Див. Як ми це будуємо.

Слайс (Slice)

Самодостатній модуль-фіча, що володіє всім потрібним: своїми роутами, логікою, доступом до даних і (на фронті) компонентами та сторінками. Іменується в однині (user, не users).

Шар / група (Layer / group)

Слайси згруповані в накладені шари (infra → setup → system → user → admin → runtime → agent → billing). Залежності йдуть лише вниз — верхній шар може використовувати нижні, але не навпаки. Див. Шари-слайси.

Gateway

Патерн доступу до даних: абстрактний контракт (IXxxGateway) живе в domain/, конкретна реалізація — у data/. Prisma і є репозиторій — класів *Repository немає.

Конектори та дані

MCP (Model Context Protocol)

Стандартна «розетка», через яку інструменти, дані та знання підключаються до агента. Приєднав MCP-сервер — агент отримав ці дії/джерела, не змінюючи мозок.

Інструмент (Tool)

Дія, яку агент може здійснити, виставлена через MCP — наприклад, API OpenCart для товарів і замовлень.

LightRAG

Open-source бібліотека graph-RAG, яку ми запускаємо як сервіс знань, з окремим воркспейсом на кожну базу знань. Див. Знання.

RLM (Recursive Language Models)

Шлях витягу без індексу: мозок рекурсивно переглядає сирі дані (peek/grep/slice у worker'і, виклики суб-LLM на шматках) замість запиту до заздалегідь збудованого індексу. Нуль інгестії, оплата в момент запиту. Див. RLM.

Postgres / Redis / об’єктне сховище

Де живе стан, щоб ефемерний рантайм лишався stateless: Postgres (агенти, сесії, задачі, повідомлення, білінг), Redis (черга, події, локи), об’єктне сховище (файли/артефакти).

Продукт і ринок

OpenCart

Перша e-commerce платформа, на яку ми цілимося — велика база self-hosted магазинів із розширюваним API. Далі: WooCommerce, PrestaShop, Magento, Shopify. Див. Місія та ринок.

Greenfield

Побудовано з нуля, не портовано. 2.0 — greenfield-перебудова; 1.x лише референс того, що продукт робить. Див. Довідку з міграції.