Штучний інтелект-агент дорівнює штучному інтелект-моделі плюс кріплення: що робить кріплення та чому.
Агент — це модель плюс кріплення. Дізнайтеся, як кріплення додають інструменти, пам’ять, цикли та захисні механізми, у чому різниця між агентами з відкритим кодом та без нього, і чому важливі оцінки.
Деякий час історію прогресу штучного інтелекту розповідали через випуск нових моделей: щомісяця з’являлися все більші та потужні базові моделі. Однак ця історія є неповною. Модель мови, велика чи мала, забезпечує первинну інтелектуальну потужність, але те, наскільки ця інтелектуальність доходить до користувача, залежить від програмного забезпечення, яке її оточує. Це програмне забезпечення називається інтерфейсом, і все більше досліджень свідчить про те, що воно може бути настільки ж важливим, як і сама модель всередині. Нещодавні дослідження щодо адаптації таких інтерфейсів до менших моделей стверджують, що ретельно налаштований інтерфейс дозволяє компактній моделі досягати значної частини продуктивності передових моделей у бізнес-завданнях за значно нижчу ціну. Детальні цифри можна знайти у оригінальних статтях, але загальний напрямок узгоджується з тим, що спостерігають практики: найпотужніша модель не завжди створює найефективнішу систему.
Отже, змагання все більше стосуються того, хто створить найкращий кріплення, а не лише того, хто створить найбільшу модель.
Чому розумна модель все ще потребує кріплення
Модель мови може надати відповідь. Однак сама по собі вона не може переглядати папки, обирати інструменти, зберігати робочу пам’ять між викликами, перевіряти написане, відновлюватися після помилки чи просуватися до мети. Саме ці прогалини мають заповнити агенти. У агенті кріплення оточує модель та перетворює її інтелект на структуровані, повторювані дії, спрямовані на досягнення мети.
Модель проти агента
Модель приймає вхідні дані та генерує вихідні, після чого її робота завершується. Агент продовжує працювати після першої відповіді. Він читає файли, використовує інструменти, виконує команди, пам’ятає попередні результати, приймає рішення та продовжує виконувати кілька кроків, поки завдання не буде завершене.
Як це можливо, якщо модель створена лише для прогнозування наступного результату? Завдяки інженерній системі, яка оточує модель. Вона вирішує, який контекст потрапляє до моделі, які інструменти є у розпорядженні, як виконуються виклики інструментів, що запам’ятовується, коли модель знову викликається та які дії відхиляються або потребують схвалення.
Інженерна система також створює робочий цикл:
Цикл працює так: модель читає інформацію зі свого контексту, обирає дію, викликає інструмент, переглядає отриманий результат, включає його до свого контексту та починає все знову.
Саме цей цикл відрізняє процес надання відповіді від завершення завдання. Він також може бути прив’язаний до планувальника або зовнішнього тригера, щоб агент почав роботу самостійно у певний час або при виникненні певної події.
Рівняння: агент = модель + інженерна система
Модель — це та частина, яка робить прогнози. Отримавши будь-який контекст, вона генерує найкорисніший наступний результат або дію. «Оплетка» — це програмне забезпечення навколо неї, яке перетворює цю первинну здатність на контрольовану, багатоетапну поведінку.
Подивіться, що відбувається, коли одну й ту саму модель використовують у різних «оплетках»:
- Зі звичайною чат-оплеткою вона є асистентом для спілкування.
- Якщо додати пошук у Інтернеті, отримання інформації, оцінку джерел та перевірку посилань, вона стає дослідницьким агентом.
- Якщо надати їй репозиторій, редактор, термінал та можливість тестування результатів, вона стає агентом для програмування.
- Якщо під’єднати її до даних клієнтів, бізнес-правил, інструментів для обміну повідомленнями, тригерів та кроків схвалення, у вас з’являється агент для операцій.
Модель ніколи не змінювалася. Змінювався лише інструментарій. Це також пояснює, чому два продукти, створені на основі однієї й тієї самої моделі, можуть поводитися дуже по-різному. Один з них знаходить правильні докази, обирає відповідний інструмент, відновлюється після невдалих спроб, підтримує порядок у контексті та перевіряє результат. Інший втрачає ключову інформацію, продовжує використовувати неправильний інструмент або оголошує про перемогу без перевірки. Здатності продукту не можна оцінювати лише за його моделлю: модель визначає, що система може зрозуміти, а інструментарій — що вона може здійснити.
Відмінність між шарами
Люди часто використовують терміни «модель», «агент» та «інструментарій» як синоніми, хоча це окремі шари.
Codex та Claude Code добре ілюструють цю модель серед агентів для програмування. Кожен з них поєднує власні моделі виробника з інструментальною платформою, яка керує контекстом репозиторію, доступом до файлів, інструментами, командами оболонки, пам’яттю, процесом виконання, зворотним зв’язком від тестів та циклами повторення. OpenCode, Goose, Pi, Letta та AutoGPT дотримуються такої ж моделі, як і середовища виконання чи фреймворки, проте відрізняються підтримуваними моделями, наборами інструментів, конструкціями пам’яті та ступенем відкритості.
Агент — це повна система, модель забезпечує інтелект, а інструментальна платформа керує тим, як цей інтелект взаємодіє з зовнішнім світом.
Ваги з відкритим кодом та сам відкритий код — це різні речі
Продукти на кшталт Codex та Claude Code — це готові агенти, у яких модель та інструментарій розробляються та налаштовуються спільно однією компанією. Агент з відкритими вагами, натомість, поєднує завантажувану модель із наявним або індивідуально створеним інструментарієм. Це надає розробникам більше контролю над розгортанням, інструментами, пам’яттю, конфіденційністю, витратами та поведінкою. Ваги можна запускати на власній інфраструктурі, а за умови дозволу ліцензії — їх можна доопрацювати. Типовим поєднанням є Goose із моделлю з відкритими вагами, такою як gpt-oss-120b, або OpenCode із моделями Qwen чи Gemma.
Агент з відкритим кодом — це щось інше: код інструментарію є публічним. Будь-хто може читати та змінювати спосіб, у який він формулює запити до моделі, які інструменти він пропонує, як зберігає пам’ять, як працюють його цикли, з чим він інтегрується та як обробляє дозволи та контекст. OpenCode, Goose та AutoGPT є прикладами відкритих інструментаріїв.
Ці два аспекти є незалежними:
- Інструмент на відкритому коді все одно може викликати пропрієтарну модель через API. OpenCode може керувати моделями GPT чи Claude, тож його інтерфейс, логіка керування та виконання інструментів є відкритими, тоді як сама модель залишається пропрієтарною.
- Модель з відкритими вагами сама по собі не є агентом. Модель на кшталт gpt-oss-20b може прогнозувати та приймати рішення, але вона не може переглядати папки, запускати інструменти, зберігати стан завдання чи завершувати робочий процес, поки її не оточить інструмент на кшталт Goose, OpenCode чи власна фреймворк-структура.
Коротко кажучи: агент на відкритому коді — це інструмент на відкритому коді разом з будь-якою сумісною моделлю, а агент з відкритими вагами — це інструмент разом із завантажуваними вагами моделі.
Чому важливі відкриті екосистеми
Кілька лабораторій зараз випускають доступні за ціною моделі з відкритим кодом разом із інструментами на основі відкритого коду, створюючи гібридні відкриті екосистеми. Такі випуски зробили відкриті рішення серйозними конкурентами пропрієтарних кодувальних агентів у окремих тестах, хоча й не завжди є кращими у всьому. Власні оцінки постачальників часто показують, що пропрієтарні моделі залишаються попереду у кількох тестах на кодування. Важливо не те, що одна модель перевершує всі інші, а те, що доступна за ціною модель з відкритим кодом, поєднана з ретельно спроектованим інструментарієм, може конкурувати з дорогими закритими системами.
Що міститься у хорошому інструментарії
Ефективність залежить від поєднання моделі та інструментарію, а сам інструментарій складається з кількох компонентів:
- Вибір контексту. Вибір того, що буде передано під час кожного виклику моделі, щоб був присутній відповідний файл, запис чи документ, а шум — ні.
Вибір рішень, які формують структуру
Кожен інструментарій приймає рішення, які тихо встановлюють межі того, що може робити агент, і деякі з них вимагають уваги вже на початковому етапі.
Скільки інструментів та як вони описані. Надання моделі двадцяти перекриваючих один одного інструментів зазвичай завдає більше шкоди, ніж п’яти чітко визначених. Назви, описи та формати аргументів фактично є підказками, тому нечіткі визначення інструментів призводять до неправильних викликів.
Скільки потрібно пам’ятати. Довгі історії витісняють корисний контекст. Інструментарії зазвичай скорочують, узагальнюють або зберігають примітки поза межами підказок та використовують їх, коли це необхідно. Те, що зберігається та на який час, сильно впливає на здатність агента залишатися послідовним під час виконання тривалих завдань.
Де розмістити людину. Деякі дії, як-от читання файлу, можна безпечно автоматизувати. Інші, як-от видалення даних чи надсилання грошей, вимагають кроку затвердження. Визначення цих правил — це рішення оператора, а не моделі.
Що вважається завершеним. Цикл потребує правила зупинки, наприклад проходження тестів, перевіреної відповіді чи досягнення ліміту кроків. Без нього агент або завершує роботу раніше, або продовжує її.
Практичний спосіб початку
Якщо ви створюєте агента, почніть з найпростішої структури, яка може виконати одне реальне завдання від початку до кінця: одна модель, два або три інструменти, цикл із обмеженням кількості кроків та письмове визначення успіху. Потім зіберіть від десяти до двадцяти реальних завдань, запустіть їх, проаналізуйте результати та спочатку виправте найпоширеніші проблеми. Заміна моделі відбувається пізніше, коли ви зрозумієте, що сама структура не є обмежуючим фактором. Така послідовність допоможе уникнути звинувачень моделі у проблемах, які насправді полягають у супутніх інструментах.
Як працює доступ до файлів
Модель не може безпосередньо торкатися файлів на комп’ютері. Цей інструментарій надає контрольовані засоби для переліку каталогів, пошуку імен файлів, отримання відповідного контенту, відкриття та редагування файлів, виконання коду та збереження результатів. Модель вибирає, яку інформацію чи дію їй потрібно виконати далі. Інструментарій перевіряє та виконує цей запит, повертає результат та додає його до контексту. Цей процес повторюється, поки модель не вирішить, що завдання завершене:
Модель запитує виконання певної дії, інструментарій її виконує, повертає результат, а модель обирає наступну дію.
Наприклад, якщо моделі просять виправити несправний тест, вона може спочатку запитати перелік каталогів, потім — відкрити файл тесту та модуль, який перевіряється, запропонувати зміни та запросити запуск тесту. На кожному кроці інструментарій вирішує, чи дозволено виконати запит, виконує його та повідомляє про те, що сталося.
Інструментарій оцінки має таке ж важливе значення
Створення інструментарію для агента — це лише половина роботи. Інша половина — це інструментарій оцінки, який показує, чи працює агент належним чином. Він тестує за умовами, схожими на реальні, чи може повна система обирати правильні інструменти, відновлюватися після збоїв, тримати витрати під контролем, дотримуватися правил безпеки та послідовно виконувати завдання. Це більше, ніж просто проходження окремого тесту на продуктивність.
Інструментарій агента складається з багатьох взаємодіючих елементів, і кожен з них може стати причиною регресії: запити, правила контексту, інструменти, політики пам’яті, цикли планування, перевірка, дозволи та механізми відновлення. Без набору для оцінки команда не може зрозуміти, чи зміна одного з цих елементів допомогла чи таємно спричинила нову проблему. Тож ці два інструментарії утворюють цикл зворотного зв’язку:
- Зберіть репрезентативні завдання, включаючи реалістичні процеси роботи, складні випадки та попередні збої.
- Запустіть повну систему разом із поточною моделлю та інструментами.
- Перевірте результати: успіх, сліди діяльності системи, виклики інструментів, помилки, витрати та затримки.
- Змініть один компонент – чи то запит, інструмент, модель, політику керування пам’яттю, цикл чи правило маршрутизації.
- Знову проведіть оцінку на завданнях, які залишилися поза увагою, та у випадках регресії.
- Залиште лише ті зміни, які дійсно покращують бажаний баланс між точністю, надійністю, безпекою, швидкістю та витратами.
Коротко кажучи: створюємо, оцінюємо, знаходимо проблеми, вдосконалюємо інструменти, знову оцінюємо.
Читання сліду діяльності системи
Оцінка є найпростішою, коли можна прочитати, що саме зробив агент. Корисний запис діяльності фіксує кожен виклик моделі, інструмент, який було запитано, аргументи, результат, повернений моделлю, використані токени та час, витрачений на виконання. Коли завдання зазнає невдачі, перегляньте запис на пошук першого неправильного кроку, а не останнього. Часто причина полягає ще на ранній стадії: відсутній файл у контексті, нечіткий опис інструменту чи хибна припущення, яку переймають усі наступні кроки. Виправлення цього одного моменту зазвичай усуває цілу низку проблем, тому аналіз записів є однією з найефективніших практик, яку може запровадити команда.
Чи все ще має значення модель?
Так. Новіші моделі постійно покращують свої навички міркування, програмування, виконання інструкцій, точності використання інструментів, обсягу обробки контексту, швидкості, ефективності за витратами та багатомодальних здібностей, і інтерфейс не може надійно створити ту функціональність, якої бракує моделі. Але модель більше не є повним продуктом.
Коли кілька моделей є достатньо хорошими для виконання завдання, інтерфейс може компенсувати більшу частину різниці між продуктами. Функції пошуку потрібного файлу, інструменти з очевидними діями, система керування станом, яка пам’ятає виконану роботу, перевірка, що виявляє некоректні зміни, дозволи, які запобігають небезпечним діям, та механізми відновлення після збоїв — усе це разом сприяє покращенню продукту.
Це вказує на простий розподіл обов’язків, який також є зручним чек-листом для перевірки будь-якого проекту агента. Запитайте, що модель може реалістично робити, що має додати інструментарій, щоб ця здатність проявлялась надійно, та які докази надають оцінки того, що це справді відбулося.
- Модель визначає зовнішню межу того, що може робити система.
- Інструментарій перетворює цю межу на надійні, повторювані результати.
- Оцінка підтверджує, чи справді готова система виконала поставлені завдання, що є окремим питанням від того, чи є модель розумною.
Саме тому сьогодні стільки уваги приділяється інженерії застосунків, спрямованій на інструментарії та процедури оцінки. Саме в інструментарії команда створює тривалу перевагу завдяки приватному контексту, безпечнішим інструментам, робочим процесам у конкретній галузі, механізмам зберігання даних, відновленню після помилок та покращенню користувацького досвіду.
Відповідь на центральне питання
Чи може модель стати справжнім, функціональним агентом без «опорної системи»? Ні. Сама по собі модель не має середовища для виконання дій, підключення до зовнішніх систем, запам’ятовування виконаних кроків, спостереження за наслідками своїх рішень та продовження роботи над досягненням мети. Модель — це мозок та механізм міркувань. «Опорна система» — це тіло, інструменти, пам’ять, зворотні ланцюги, дозволи та обмеження, які перетворюють прогнози на контрольовані дії.
Або одним реченням: Штучний інтелект-агент — це модель ШІ плюс «опорна система».