Один агент, багато спеціалістів: чому персональний AI має координувати роботу, а не робити все сам.
Особистий AI-асистент краще функціонує як оркестратор: він направляє завдання до агентів для кодування, моделей та звичайних скриптів, надаючи їм поступово зростаючі права доступу.
Джерела: I Stopped Trying to Build One AI Agent That Does Everything
Qwen, Nemotron, Gemma, DeepSeek. Локальні обчислення, AWS Bedrock, Azure. Різні середовища виконання, різний розмір, різні ціни, різний рівень розчарування. Довга серія експериментів із Hermes, Codex, OpenCode, локальними моделями та API хмари зазвичай починається з переконання, що існує одна правильна модель, яку потрібно знайти. Рано чи пізно виявляється, що це неправильна проблема. За нею ховається ще одне припущення, і воно є цікавішим: чому сам особистий агент має робити все?
Мрія про Jarvis
Перша архітектура настільки проста, що це навіть соромно: людина, потім один агент, а потім усе інше.
Повідомлення для цього агента можуть звучати так: перевірити проекти, виправити проблему в одному з репозиторіїв, скласти календар на завтра, повідомити, чи працює сервер Linux належним чином, дослідити певну тему та надати важливі частини інформації. Агент має обробляти все це.
Це звучить чудово, але саме тут починаються проблеми, адже все це становить величезну поверхню API.
Для деяких завдань вже існують кращі інструменти
Найяскравішим прикладом є програмування. Codex та OpenCode — це не просто вікна чату, приєднані до моделі; вони працюють у середовищі програмування. Вони розуміють структуру репозиторіїв, читають та шукають файли, редагують кілька файлів одночасно, виконують команди, перевіряють помилки, запускають тести, аналізують відмінності та вносять корективи. Це справді потужні спеціалізовані інструменти.
Тепер уявімо, що персональному агенту доручають реалізувати певну функцію в проекті. Існують два можливі підходи.
Підхід А. Надайте агенту дуже потужну модель, доступ до файлової системи та доступ до шелу. Навчіть його операціям з репозиторіями. Створіть механізми керування контекстом, обробки відмінностей, виконання команд, циклів тестування та відновлення після помилок. Продовжуйте вдосконалювати процес програмування. Вітаємо: агент для програмування створюється з нуля.
Підхід Б. Агент розпізнає завдання з програмування та передає його Codex чи OpenCode. Це, безумовно, розумніше.
Асистент не обов’язково має бути найкращим у всьому
Це справжня зміна мислення. Особистий асистент не мусить бути найкращим програмістом, дослідником, інженером DevOps, планувальником чи системою знань у світі. Він має знати, хто має виконувати роботу. Це інша відповідальність, і, можливо, навіть важливіша.
Людські організації працюють так само. Генеральний директор не пише кожну функцію бекенду, не налаштовує кожен кластер Kubernetes, не досліджує кожен ринок, не створює кожну таблицю, не бронює кожну зустріч та не відповідає на кожен запит підтримки. Їхня цінність частково полягає у розумінні того, що має відбутися, хто має цим займатися та чи є результат прийнятним. Особистого оркестратора на основі ШІ можна розглядати саме в цьому контексті. Він не виконує кожне завдання, але достатньо добре розуміє наміри, щоб правильно спрямовувати роботу.
Інша форма системи
Замініть ланцюжок людина, агент, одна величезна модель та все інше на щось на кшталт цього:
┌──────────────┐
│ Me │
└──────┬───────┘
│
▼
┌─────────────────┐
│ Google Chat │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Hermes │
│ Orchestrator │
└────────┬────────┘
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Coding Agents AI Models Tools
Codex/OpenCode Local / Cloud APIs / Servers
│ │ │
└─────────────────┼──────────────────┘
│
▼
Final Result
Завдання агента стає набагато зрозумілішим. Він розуміє людину, розуміє наявні можливості, обирає правильний варіант, надає необхідний контекст, стежить за результатом та доповідає. Ось такий асистент справді вартий уваги.
Чат як єдиний вхід
Додаток чату, такий як Google Chat, набуває сенсу в такій архітектурі. Він не повинен розкривати приховану складність. З боку користувача існує одна розмова. Повідомлення на кшталт «Перевірте, чи сталося щось важливе з проектом X сьогодні» може змусити агента звернутися до системи завдань, переглянути GitHub, перевірити стан сервера, прочитати відповідні матеріали, можливо, попросити інший модель проаналізувати щось, а потім підсумувати результати. Користувач не повинен знати про все це чи відкривати п’ять додатків. Інтерфейс — це намір, а все інше — це реалізація.
Кодування як приклад моделі
Зображення, на якому людина далеко від комп’ютера. У повідомленні по телефону йдеться про проблему у процесі автентифікації проекту X та просить усунути її, якщо це можливо просто. У принципі ланцюжок виконання завдань виглядає так: агент визначає, про який проект йдеться, збирає достатньо інформації, щоб знайти репозиторій, розуміє, що код потрібно змінити, та передає завдання агенту з програмування. Codex чи OpenCode відкриває репозиторій, досліджує його, редагує відповідні файли, запускає тести, перевіряє зміни та повертає результат. Оркестратор отримує цей результат та повідомляє щось на кшталт: під час перевірки токена оновлення використовувалась неправильна умова терміну дії, агент з програмування її виправив, відповідні тести пройшли, і ось що було змінено.
Майже не має значення, яка модель створила той чи інший токен на кожному етапі. Важливо те, що завдання було виконано правильно.
Моделі перетворюються на інфраструктуру
Коли агент є шаром оркестрації, питання про те, чи використовувати Qwen, DeepSeek, локальну модель, Bedrock чи Azure, більше не виключають одне одного. Відповідь може бути просто «так» — з різною рівнем інтелектуальних здібностей для різних завдань. Невелика локальна модель відповідає за просте маршрутизування. Дешева хмарна модель створює резюме. Більш потужна модель для міркувань приймає складні рішення. Агент для програмування керує репозиторіями. Інший спеціаліст виконує інші завдання. Моделі стають інфраструктурою, а інфраструктура має бути замінною.
Уникнення залежності від одного постачальника
Моделі змінюються з абсурдною швидкістю. Те, що сьогодні здається очевидним вибором, через шість місяців може виглядати посередньо. Ціни змінюються, постачальники змінюються, відкриті моделі вдосконалюються, вікна контексту збільшуються, функції виклику інструментів покращуються, а з’являються нові архітектури інференсу. Якщо вся особиста налаштованість ґрунтується на припущенні, що модель X робить усе, зміна є проблематичною. Кращим підходом є:
Task
↓
Router
↓
Best available capability
Сьогодні останнім кроком може бути один постачальник, а завтра — інший, і робочий процес не повинен цим перейматися.
Роутер може бути важливішим за модель
Багато часу витрачається на порівняння моделей: модель А має оцінку 74, модель B — 78, модель C обробляє мільйон токенів контексту, модель D коштує на 60 відсотків дешевше. Ця інформація корисна. Тепер уявіть систему, яка знає, що модель A найкраща для певної завдання з міркувань у сфері програмування, модель B швидка та дешева для класифікації, модель C зайва, оскільки запит можна обробити локально, інший запит зовсім не потребує LLM, достатньо лише виклику API, один запит має йти безпосередньо до Codex, а ще один потребує запитання до користувача перед тим, як щось відбудеться.
Тут частина інтелекту знаходиться у самій системі, яка вирішує, як використовувати цей інтелект, що є набагато цікавішим, ніж ще один табель лідерів.
Не кожному кроку потрібен LLM
Агенти роблять це настільки простим, що легко забути про це. Коли запитують, чи сервер у мережі, агенту не потрібна модель міркувань із 200 мільярдів параметрів, щоб з’ясувати, чи існує сервер. Він виконує перевірку стану, інтерпретує результат та відповідає. Коли запитують, скільки залишилося місця на диску, він виконує:
df -h
Потім він аналізує результат та відповідає. Використання дорогого моделювання міркувань на кожному кроці — це не інтелект. Іноді це просто погана інженерія.
Дозволи
Як тільки агент може делегувати дії, виникає складніша проблема: що він може робити? Читання календаря відрізняється від надсилання електронного листа. Читання репозиторію відрізняється від об’єднання запиту на зміни. Перевірка сервера суттєво відрізняється від видалення файлів. Тому корисний особистий агент потребує моделі дозволів разом із своїми інструментами, приблизно такої:
- Читання відбувається без запиту.
- Підготовка чернеток та планів відбувається без запиту.
- Дії з низьким ризиком можуть виконуватися самостійно.
- Будь-які значущі дії вимагають схвалення людини.
Коли агента просять з’ясувати причину зупинки послуги, він може одразу приступити до роботи. Якщо він вирішує, що база даних пошкоджена, та планує її видалити та створити заново, спочатку має надійти підтвердження. Автономія не повинна бути бінарною — її слід регулювати залежно від рівня ризику.
Пам’ять та контекст
Ще однією причиною проти перетворення кожного спеціалізованого інструменту на особистого асистента є контекст. Codex має розуміти репозиторій, але не всю життєву ситуацію користувача. Інструмент інфраструктури має знати про сервери, але не про кожну проведену розмову. Календар відстежує зустрічі, а менеджер завдань — завдання. Оркестратор може стати шаром, який розуміє, як ці системи взаємопов’язані.
Розгляньмо питання про те, що відбувається з певним проектом. Жоден окремий запит до бази даних не може на нього відповісти. Хороша відповідь ґрунтується на нещодавній роботі над розробкою, активності в GitHub, завданнях, попередніх рішеннях, статусі розгортання та тому, що користувач планував робити далі. Саме в цьому міжсистемному контексті особистий шар оркестрації стає справді цінним.
Пастка надмірної інженерії
Небезпека очевидна. Такий підхід ускладнює створення подібної діаграми:
User
↓
Intent Classifier
↓
Planning Agent
↓
Model Router
↓
Memory Agent
↓
Permission Agent
↓
Coding Agent
↓
Validation Agent
↓
Reflection Agent
↓
Supervisor Agent
↓
Another Agent Watching the Other Agents
А потім витрачати три місяці на створення організації з ШІ, щоб можна було запитати, що заплановано сьогодні. Це нікому не допомагає. Урок усього експерименту полягає у тому, що складність має заслужити своє місце. Дванадцять агентів лише тому, що діаграма архітектури виглядає круто, — це погана причина. Здатності, які постійно економлять час, — це хороша причина.
Делегування перед автономією
Повністю автономні агенти привертають багато уваги: даєте їм завдання, залишаєте їх працювати годинами, дозволяєте агентам спілкуватися та приймати рішення між собою, а потім повертаєтесь, коли все завершено. Це цікаво, але це не найкращий початок для особистої системи. Надзвичайно надійне делегування має йти перед максимальною автономією. Мета — сказати «зробіть X», щоб система надійно обирала правильний інструмент чи агента та повідомляла про те, що сталося. Коли це буде працювати надзвичайно добре, автономію можна поступово збільшувати.
Більше спеціалізованих інструментів, а не менше
Спочатку метою здається консолідація: занадто багато інструментів ШІ, тож потрібно створити один ШІ, який їх замінить. Але це виявляється неправильним. Кінцевий стан, ймовірно, передбачатиме більше спеціалізованих систем ШІ, причому вони більше не потребуватимуть окремого керування, що саме і вирішує шар оркестрації. Майбутнє може полягати не стільки у одному ШІ, який керуватиме всіма, скільки у одному інтерфейсі для їх координації. Різниця є тонкою, але значною.
Для чого потрібен агент
Після роботи з такою системою, пошкодження елементів, налаштування інтерфейсу чату, тестування моделей та глибоких роздумів щодо спеціалізованих агентів для програмування, стає очевидною роль особистого агента. Він не обов’язково має бути найрозумнішим ШІ в усій системі. Він має бути тим, хто знає людину та її системи. Він повинен розуміти, про що йдеться, який контекст має значення, які можливості підходять, що він може зробити, коли потрібна підтвердження та як повернути результат. Цього достатньо, а все інше можна делегувати.
Архітектура, яку варто бажати
Кінцева структура виглядає приблизно так:
ME
│
▼
GOOGLE CHAT
│
▼
┌─────────────────┐
│ HERMES │
│ │
│ Intent │
│ Context │
│ Memory │
│ Permissions │
│ Orchestration │
└────────┬────────┘
│
┌──────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
AI MODELS CODING AGENTS TOOLS
│ │ │
Local / Cloud Codex/OpenCode GitHub/APIs
Fast / Strong Servers/Tasks
│ │ │
└──────────────────┼───────────────────┘
│
▼
HERMES
│
▼
ME
Суть не в окремій скриньці. Усе, що знаходиться під керуванням оркеструвальника, має з часом бути замінним. З’являється кращий агент для кодування — його просто замінюють. З’являється краща локальна модель — її також замінюють. Обробка даних у хмарі стає дешевшою — туди направляють більше завдань. Постачальник стає ненадійним — обходять його. Переробляти спосіб використання асистента щоразу, коли змінюється індустрія ШІ, не повинно бути необхідністю.
Персональний ШІ, можливо, у зворотному напрямку
Більшість продуктів ШІ конкурують за те, наскільки розумним є їхній модель, що є зрозумілим. Однак у міру вдосконалення моделей зростає ще один важливий аспект – координація. Це означає розуміння того, що має на увазі людина, її контексту, які системи є важливими, які інструменти існують, яка модель підходить, які дії є безпечними, коли потрібно запитати та коли взагалі не варто використовувати ШІ. Асистент, який варто бажати, не обов’язково є тим, хто має найвищий показник у тестах. Це той, хто робить усю інтелектуальну потужність та програмне забезпечення навколо людини схожими на єдину систему.
Короткий варіант висновку
Вихідною точкою є бажання мати особистого штучного інтелектуального агента. Впровадження такого агента показує, що постійний асистент насправді є проблемою інфраструктури. Пошук ідеальної моделі свідчить про те, що вибір моделі насправді є проблемою маршрутизації. Вирішення питання про те, що має робити агент, показує, що особистий асистент по суті може бути проблемою оркестрації. Архітектура змінюється від пошуку найрозумнішої моделі та надання їй усіх інструментів до системи, яка розуміє намір користувача та направляє завдання у відповідне місце. Це значно менш „магічний“ опис Джарвіса, але набагато ближчий до того, що можна справді створити та використовувати щодня.
Пов’язана література
- Створення агента планування в LangGraph: планування, виконання, перепланування, звітування — агент планування з чотирма вузлами в LangGraph для фінансових досліджень: структуровані плани, реєстр інструментів із урахуванням простору імен, обмеження на перепланування та приклад виконання зі слідкуванням.
- MiniCPM5-2B проти конкурентів 4B: чому агентський підхід дає інші результати — модель обсягом 2,5 мільярда параметрів, яка перевершує конкурентів 4B за показниками одноразових тестів, відстає у два-три рази у сценаріях використання агентського підходу. Причини — плутанина версій індексу, локальна продуктивність та умови її застосування.