Інженерія кріплень: середовище, яке робить агентів ШІ надійними.

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

Робоча формула — це Агент = Модель + Комплект засобів. Модель забезпечує міркування та прийняття рішень. Усе інше є комплектом засобів: спосіб підключення інструментів, пам’ять, сандбокси, захисні механізми, обробка контексту, каркаси планування та цикли зворотного зв’язку, які забезпечують надійність та безпеку продакшн-агента. Databricks формулює це так: без комплекту засобів модель може відповідати на запитання, але не може надійно виконувати код, викликати API, отримувати доступ до файлів, пам’ятати попередню роботу чи самостійно завершувати багатоетапні завдання.

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

Шість компонентів комплекту засобів

Аналізи в галузі зазвичай виділяють приблизно наступні елементи:

1. Інтеграція інструментів, яка з’єднує модель із зовнішніми API, базами даних, засобами виконання коду та спеціалізованими інструментами через визначені протоколи.
2. Пам’ять та стан, розділені на робочий контекст, стан сесії та довгострокову пам’ять, які зберігаються після закінчення одного вікна контексту.
3. Керування контекстом та запитами, яке динамічно формує те, що відображається під час кожного виклику моделі.
4. Планування та розбирання на етапи, яке допомагає моделі працювати зі структурованими послідовностями замість того, щоб запитувати все одночасно.
5. Перевірка та захисні механізми, які включають перевірки валідності, перевірку формату, фільтри безпеки та цикли самокорекції.
6. Модульність, тобто компоненти, які можна ввімкнути, вимкнути або замінити окремо.

Чому це важливо

Агенти поширюються всюди — від ботів підтримки до асистентів з фінансового аналізу та автономних інструментів для програмування. Більшість з них зазнають невдач у реальних умовах через крихкість, небезпеку чи непередбачуваність інструментальних комплексів, а не через слабкість основних моделей LLM. Чотири причини пояснюють це явище:

• Це переводить роботу від сподівань до інженерних рішень. Замість випадкового програмування та молитов про успіх структуровані обмеження та детермінована зворотна зв’язка роблять результати прогнозованими та повторюваними.
• Це зменшує навантаження на перевірку. Хороший інструментальний комплекс підвищує шанси на правильну спробу з першого разу та також забезпечує механізм, який виправляє якомога більше проблем ще до того, як їх побачить людина.
• Це дозволяє справжню автономію. Без неї агент — це лише вдосконалений чат-бот. З нею він може виконувати код, викликати API, читати файли, пам’ятати попередню роботу та завершувати багатоетапні процеси.
• Це робить агентів придатними для роботи в продакшені. Біргітта Бьокелер у своїй статті на сайті Мартіна Фаулера описує два типи керування: посібники, які є передніми керуваннями, що направляють агента перед його дією, та датчики, які є зворотними керуваннями, що допомагають йому виправити помилки після дії. Саме це поєднання відрізняє демонстраційні агенти від агентів, які використовуються в продакшені.

Цикл у центрі

Більшість агентів працюють за циклом „причина – дія – спостереження“:

1. Причина: модель аналізує все в контексті (завдання, пам’ять, попередні результати) та обирає наступну дію.
2. Дія: інструментарій виконує цю дію, наприклад, викликаючи інструмент, запускаючи код у ізольованому середовищі, звертаючись до API чи зберігаючи щось у сховищі.
3. Спостереження: інструментарій фіксує результат та повертає його моделі як новий контекст.
4. Цикл повторюється, причому модель використовує цей результат для нового вибору.

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

Походження терміна

Історія його виникнення коротка.

• З 2022 по 2024 рік тривала ера запитів. Розробники витрачали безліч годин на формулювання, структуру та приклади, щоб отримати кращий результат.
• У середині 2025 року увага звернулась до контексту. Те, що бачить модель, має таке ж значення, як і спосіб постановки запиту, тому пошук інформації, її стиснення та керування вікном контексту опинилися у центрі уваги.

5 лютого 2026 року Мітчелл Хашімото, співзасновник HashiCorp та творець Terraform, опублікував пост, у якому описав свою звичку: щоразу, коли агент робив помилку, він створював постійне рішення в його середовищі, щоб саме ця помилка стала структурно неможливою. Він назвав це «інженерією упряжі», сформулювавши це приблизно так: щоразу, коли агент робить помилку, знайдіть час, щоб розробити рішення, яке не дозволить йому робити таку помилку знову.

11 лютого OpenAI оприлюднила серйозний звіт про інженерні аспекти створення та випуску продукту без ручного написання коду, що підтвердило цю концепцію.

У березні Anthropic опублікувала доповнення, у якому описала повну архітектуру упряжі з трьома агентами, а Thoughtworks, Databricks, Red Hat, LangChain та інші видали детальні посібники. Цей термін вже набув поширення.

Принципи, які залишаються актуальними

1. Модель пропонує, а механізм виконання реалізує. Ніколи не дозволяйте ШІ безпосередньо викликати інструменти. Саме це розділення є основою безпечного проектування агентів.
2. Кожен виклик інструменту дає результат, навіть у разі невдачі. Як успіх, так і відмова у дозволі чи тайм-аут мають надходити до агента у вигляді структурованих даних. Мовчазна невдача є ворогом автономії.
3. Ризик змінює процес. Використовуйте принаймні три рівні: операції лише для читання, які виконуються автономно, чернетки, що імітують роботу без зовнішніх наслідків, та зовнішні записи, які потребують схвалення.
4. Збирайте контекст, але не викидайте його всього за один раз. Замість того, щоб передавати всю розмову в кожному кроці, структуруйте його: політики на рівні системи, інструкції, специфічні для кожного завдання, та підказки, отримані саме в потрібний момент. Позначайте ненадійні дані як такі.

Встановлюйте бюджети для складних завдань. Кожен цикл має мати обмеження щодо кількості кроків, часу виконання, кількості токенів (за хід та в сукупності) та витрат у доларах.

Перетворюйте постійні помилки на функції інструментарію. Якщо інструмент постійно повертає некоректні відповіді, зміна запиту — це неправильне рішення. Напишіть валідатор у цьому інструментарії, де й місце постійним виправленням.

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

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

Почніть з простого. Рада Філліпа Шміда — уникати складних ланцюгів керування та натомість надавати надійні атомарні інструменти, дозволяти моделі створювати план та додавати механізми контролю, повторних спроб та перевірки. Болісний урок полягає у тому, що пайплайни, які у 2024 році вимагали ретельної ручної налаштування, у 2026 році часто обробляються за допомогою одного лише запиту, тому інструменти слід створювати так, щоб вчорашня розумна логіка можна було легко видалити, як тільки модель наздожене їх.

Три основи

Деякі фахівці організовують роботу навколо трьох основ, а не шести компонентів:

• Інженерія контексту: забезпечення агента правильною інформацією у правильний момент, поєднання статичних документів із актуальними даними для спостереження.
• Архітектурні обмеження: забезпечення якісного коду за допомогою машини через шарові залежності, інструменти перевірки коду, структурні тести та скрипти перед збереженням.
• Управління ентропією: планове очищення, щоб кодові бази, створені ШІ, не деградували.

Дешевий трюк із великим ефектом

LangChain повідомив, що лише зміна на рівні інструментарію підвищила його результати в Terminal Bench 2.0 з 52,8% до 66,5%, що дозволило перейти зі списку поза топ-30 у топ-5. Ця зміна полягала у послідовності кроків: високі зусилля для планування та перевірки та середні зусилля для реалізації. Сама модель залишилася незмінною, що демонструє, наскільки сильний може бути вплив лише змін у інструментарії. Глибина цього інструментарію сильно варіюється серед найкращих сучасних кодувальних агентів.

Висновок

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

Пов’язана література

• Prompt, Context, Harness, Loop: Four Layers of Engineering an AI Agent — Чотири вкладені шари визначають поведінку агента. Дізнайтеся, що контролює кожен з них, подивіться приклад використання на GitHub та зрозумійте, чому спочатку варто створити інструментарій та цикл.

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

D3.js у React: прив’язка даних, SVG та правило власності useEffect — Дізнайтеся, що насправді є D3, як працює прив’язка на вхід/обновлення/вихід, чому підходить SVG, та як розділити контроль DOM, щоб D3 та React співпрацювали у стовпчастій діаграмі.