Проектування інструментарію для агентів: політика, сандбоксинг, пам’ять та перевірка.
Дізнайтеся, які шари робочого середовища перетворюють ШІ, який виконує запити інструментів, на надійного агента: політика виконання, сандбоксинг ОС, постійний стан, перевірка, контроль контексту та витрати.
Джерела: Agent Harness Engineering: The Missing Layer Between an LLM and a Real AI Agent
Команди, які прагнуть створити AI-агента, зазвичай починають із порівняння моделей: розмірів вікна контексту, результатів тестування, якості міркувань, ціни за токен. Після вибору моделі підключається кілька інструментів, і результат називається агентом. Насправді на цьому етапі існує лише модель, яка може викликати функції, а прогалину між нею та готовим агентом заповнює шар виконання, який сьогодні зазвичай називається agent harness. Цей посібник розглядає складові цього шару, від чого кожна з них захищає, та як поступово розвивати його, не потопаючи у абстракціях фреймворку.
Модель, яка викликає інструменти, ще не є агентом
Типовий початковий набір складається з короткого списку можливостей, які доступні для використання моделлю.
search()
read_file()
write_file()
run_command()
За допомогою цих чотирьох функцій модель може шукати, читати, записувати та виконувати команди. Це схоже на автономію, але в цій системі ніщо не визначає, що моделі дозволено обробляти, які операції потребують підтвердження людини, яка інформація зберігається після збою чи перезавантаження, як перевіряється результат чи наскільки результат кожного інструменту використовується у подальших запитах. Усі ці обов’язки належать інфраструктурі.
Інфраструктура також є змінною, яку можна виміряти. На момент написання цього тексту дослідження 2026 року, яке порівнювало інфраструктури для кодувальних агентів, показало різницю у кількості використаних токенів на вирішену задачу до 40 разів, тоді як розбіжності у показниках успішності між однаковими інфраструктурами були значно меншими. Висновок полягає не в тому, що розумна система виконання робить слабку модель блискучою, а в тому, що саме ця система сильно впливає на те, наскільки ефективно, безпечно та передбачувано здатна модель виконує свою роботу.
Цикл у центрі та запитання навколо нього
Якщо спростити до суті, агент — це цикл: запитуємо модель, що робити, виконуємо запрошений інструмент, додаємо результат до контексту та повторюємо, поки модель не скаже, що все готово.
while True:
response = model(context)
if response.is_final:
break
result = execute_tool(response.tool_call)
context.append(result)
Багато реальних агентів мають у своїй основі щось дуже схоже на це. Модель приймає рішення, система його виконує, надходять дані спостережень, і модель обирає наступний крок. Сам цикл є простим; основні технічні зусилля полягають у всьому, що його оточує. Корисний інструментарій має відповідати на довгий список операційних запитань щоразу під час виконання завдань.
Can the agent execute this command?
Can it access this directory?
Does it need human approval?
What happens if the command fails?
What information should return to the model?
What should survive the session?
Should another agent review the result?
How much context should we send?
How much will this turn cost?
What happens if the model loops forever?
Разом ці елементи утворюють „обладнання“ для роботи з мовним моделлю. Один із нещодавніх концептуальних досліджень описує його як середовище виконання, яке з’єднує мовну модель із зовнішнім світом за допомогою інструментів, механізмів керування контекстом, систем безпеки, оркестрації та точок розширення. Зручно уявляти цей механізм як дві частини.
AI Agent
│
┌────────┴────────┐
│ │
Model Harness
│ │
reasoning ┌──────┼───────┐
planning │ │ │
generation Tools Memory Safety
│ │ │
Sandbox Context Verification
З одного боку модель забезпечує міркування, планування та генерацію контенту. З іншого боку „обладнання“ надає інструменти, пам’ять та механізми безпеки, підтримувані сандбоксом, обробкою контексту та перевіркою. Модель забезпечує інтелект; „обладнання“ керує тим, як цей інтелект впливає на реальні системи.
Чому запит не може бути вашим механізмом безпеки
Припустимо, що системний запит містить чітке правило:
Ніколи не видаляйте файл у продакшн-середовищі без попереднього запиту до мене.
У цьому реченні немає нічого неоднозначного, проте воно залишається запитом. Модель може неправильно його зрозуміти, втратити контекст під час тривалої сесії, порівняти його з суперечливими інструкціями в контексті, переконати себе, що поточний випадок є винятком, або досягти такого ж шкідливого результату за допомогою іншого інструменту, який не був чітко передбачений правилом. Запит до агента уникнути чогось принципово відрізняється від зроблення цього неможливим без дозволу. Підказка виражає бажання:
Please don't do X.
Конструкція «харнес» може виражати правило, яке оцінюється в коді:
if dangerous_action and not approved:
deny()
Друга версія працює незалежно від того, чи пам’ятає модель інструкцію. Це відповідає першому принципу інженерії керування: коли правило є детермінованим, реалізуйте його у детермінованому коді. Claude Code також дотримується цього принципа у своїй архітектурі. Хуки виконуються під час подій життєвого циклу та викликів інструментів, і можуть, наприклад, відхилити виклик інструменту перед його виконанням, тоді як файли на кшталт CLAUDE.md надають вказівки, які модель сприймає як контекст. Якщо ви створюєте такий файл, зберігайте його як посібник та перемістіть функції контролю до хуків; наш посібник щодо ефективного створення файлу CLAUDE.md описує, що має там бути.
Шар 1: межа виконання між запитом та дією
Перше питання, яке має бути вирішене, — це які дії агент може виконувати. Розглянемо інструмент, який видаляє файл.
def delete_file(path):
os.remove(path)
Модель може викликати його з будь-яким аргументом на свій розсуд.
delete_file("important.md")
Якщо цей виклик відбувається негайно, модель має необмежені повноваження щодо всього, до чого може дістатися функція. Рішенням є направлення кожного виклику через контролер, який перевіряє політику перед виконанням.
def execute(call):
if call.name == "delete_file":
if not call.args.get("human_approved"):
return "DENIED: human approval required"
return dispatch(call)
Тепер модель все ще може запитати про видалення, але запит вже не означає виконання дії. Процес стає рішенням згідно з політикою, яке має два результати.
Model decision
↓
Policy check
↓
Permission?
↙ ↘
No Yes
↓ ↓
Deny Execute
Це відображає традиційний підхід до проектування систем безпеки: модель пропонує, а час виконання реалізує. Однією деталлю, яку варто уточнити у реальному коді, є джерело схвалення. У наведеному вище прикладі флаг схвалення зчитується з власних аргументів виклику, які генерує модель. У продакшн-системі схвалення має надходити окремо, через крок людської підтвердження або підписаний токен, який модель не може створити, інакше модель зможе просто сама встановити цей флаг.
Чому перевірки на рівні інструменту призводять до проблем
Політики інструменту є необхідними, але недостатніми. Уявіть собі, що система відхиляє цей виклик:
delete_file("secrets/api_key")
Це здається захистом, поки агент не виконає замість цього відповідну команду шеллу:
rm secrets/api_key
Політика delete_file ніколи не бачить цієї операції. Або ж система блокує читання секретного шляху:
read("secrets/api_key")
Але відносний шлях потрапляє всередину, тому що ніхто його не нормалізував:
read("../secrets/api_key")
Символічні посилання, допоміжні програми, які відкривають файли від імені агента, та інтерпретатори, які приймають довільний код, усі створюють подібні „бічні двері“. Політика, сформульована за допомогою назв інструментів та рядкових аргументів, не може перелічити всі шляхи до ресурсу, тому це не є повноцінним механізмом безпеки. Рекомендації OpenAI щодо роботи з кодувальними агентами передбачають використання сандбоксінгу, політик схвалення, обмеженої експекутації, контролю мережі та телеметрії замість покладання на запити. Принцип, який потрібно дотримуватися: інструменти забезпечують дотримання політики, а операційна система — остаточний бар’єр безпеки.
Рівень 2: сандбоксінг того, до чого агент може фізично достатися
Політика визначає, що агент може робити; сандбокс — до чого він може отримати доступ спочатку. Слабкий підхід — це список заборон, який намагається вказати кожне чутливе місце.
Don't access:
- /etc
- ~/.ssh
- secrets/
- production/
- credentials/
- ...
Такі списки ніколи не бувають повними. Сильніший підхід — це зміна стандартної практики: спочатку не надавати майже нічого, а потім додати саме те, що потрібно для виконання завдання, наприклад одне робоче простір проєкту.
Agent workspace:
/workspace
├── src/
├── tests/
├── pyproject.toml
└── README.md
Агент отримує /workspace та нічого більше на хості. У форматі політики це є список дозволів.
Allowed:
/workspace
Everything else:
unavailable
Оскільки решта файлової системи з точки зору агента просто не існує, трюки з шляхами, символічні посилання та допоміжні процеси втрачають більшу частину своєї ефективності. Контейнери, спеціалізовані віртуальні машини та обмежені облікові записи користувачів є поширеними способами реалізації цього. SDK Agents від OpenAI додав нативну реалізацію сандбоксу саме з цією метою, щоб агенти могли встановлювати залежності, редагувати файли та виконувати команди в контрольованому середовищі.
Обмеження мережі та ресурсів мають бути в сандбоксі
Ізоляція файлової системи — це ще не все. Агент, який може виконувати такі прості дії, має зовсім інший профіль загроз:
curl https://example.com
З можливістю зовнішнього доступу до мережі агент може:
- завантажувати та виконувати довільне програмне забезпечення
- виводити дані на зовнішній хост
- викликати API сторонніх сервісів
Тому справжній пісочничний середовище охоплює кілька аспектів, а не лише файли.
Filesystem
Network
Processes
Environment variables
Secrets
CPU
Memory
Time
Процеси тихо успадковують змінні середовища та конфіденційну інформацію, а обмеження на CPU, пам’ять та час запобігають неконтрольованому виконанню. Саме через цю повноту сучасні середовища виконання проектують пісочничне середовище як повноцінне середовище виконання, а не просто тонкий обгорток.
Рівень 3: постійний стан, який зберігається після завершення сеансу
При довготривалих завданнях виникають інші проблеми. Агент може годину досліджувати репозиторій та з’ясовувати важливі архітектурні правила.
The authentication service must never directly access the database.
All database operations go through Repository classes.
Тоді вікно контексту заповнюється, сесія перезапускається, і ці знання зникають. Наступна сесія не розуміє, чому дизайн виглядає саме так, і може без проблем його порушити. Історія розмов — не найкраще місце для такого типу інформації. Корисна система організації розділяє принаймні три категорії інформації з різною тривалістю існування.
Conversation state
↓
temporary
Project state
↓
persistent
Harness configuration
↓
persistent + globally enforced
Конкретні приклади кожної з них:
Conversation:
"Let's investigate the login bug."
Project:
"Authentication uses OAuth."
Harness:
"Never modify generated migrations."
Елемент розмови може безпечно зникнути після завершення завдання. Інформація про проект має зберігатися між сеансами, наприклад у файлі нотаток з версіонуванням або в пам’яті. Правило керування має застосовуватися під час кожного запуску, незалежно від того, що наразі пам’ятає модель, що зазвичай означає його розміщення у коді конфігурації та контролю, а не у тексті. Чим довшими стають сеанси, тим важливішою є ця сепарація. Наприклад, API Agents від OpenAI містить функції керування контекстом, призначені для агентів з тривалим функціонуванням, серед яких автоматичне стиснення контексту під час наближення сеансу до його ліміту. Саме під час стиснення втрачається інформація про проект, яка не була зазначена, тому варто свідомо зберігати її до цього моменту. Для більш детального розгляду рівнів пам’яті дивіться чотирирівневу пам’ять агента з використанням LangGraph та Amazon Bedrock.
LangGraph та Bedrock.Рівень 4: перевірка того, що агент не володіє
Агенти можуть помилятися з абсолютною впевненістю, тому агент, який здійснив зміну, не повинен бути остаточним авторитетом щодо її правильності. Розгляньмо такий результат:
def calculate_total(items):
return sum(item.price for item in items) + 1
Випадкове + 1 може здаватися намірним для моделі, яка його написала. Незалежний крок перевірки дозволяє оцінити зміну за кількома показниками.
Code
Tests
Type checking
Linting
Security rules
Expected behavior
Цінність цього підходу полягає у розділенні процесів створення та оцінки.
Agent
│
↓
Changes
│
↓
Verification
↙ ↘
PASS FAIL
↓ ↓
Continue Investigate
Успішна перевірка дозволяє циклу продовжуватися; невдача змушує агента повернутися для дослідження. Одне уточнення легко проігнорувати: перевіряючий має повідомляти про проблеми, а не тихо їх виправляти. Якщо перевіряючий мовчки виправляє помилку, ви втрачаєте сигнал про те, що початковий агент зазнав невдачі, і ваші показники успіху стають неправдивими.
Тестування в режимі «сухий запуск» як стандарт для ризикованих змін
Для операцій із вищим рівнем ризику стандартною практикою є попереднє переглядання поведінки. Замість функції застосування, яка діє негайно:
apply_change()
необхідно використовувати варіант із безпечним стандартним режимом «сухий запуск»:
apply_change(dry_run=True)
Агент спочатку отримує опис наслідків дії.
Would modify:
src/auth.py
tests/test_auth.py
Лише через окремий, явний крок, бажано такий, що вимагає схвалення, можна перейти від попереднього перегляду до виконання. Це дає як перевіряючому, так і будь-якому людському рецензенту конкретний об’єкт для аналізу перед будь-якими змінами.
Рівень 5: інженерія контексту
Кожен токен, який додається до контексту, коштує грошей, конкурує за увагу моделі та під час довгих завдань має тенденцію накопичуватися швидше, ніж зникає. Припустимо, агенту потрібна одна функція з файлу обсягом 5 000 рядків. Примітивний підхід передає весь файл, потім повний результат наступного пошуку, потім результат наступного інструменту тощо. Незабаром контекст міститиме все це:
Task
+ entire repository
+ previous searches
+ tool output
+ logs
+ previous reasoning
+ repeated instructions
Модель технічно може бачити кожен токен, але наявність у полі зору не означає розуміння. Кращий підхід — розглядати контекст як конвеєр, який стискає інформацію перед тим, як вона потрапить до основного агента.
Main Agent
│
├── Search Agent
│ │
│ └── 50,000 tokens
│
│ ↓
│
└── 1,000-token summary
Тут агент-шукач може витратити 50 000 токенів на дослідження, але основна сесія отримує лише короткий огляд довжиною 1 000 токенів з найважливішою інформацією. Це сильний аргумент на користь підагентів. Наприклад, Claude Code описує підагентів як елементи, що працюють у власних ізольованих вікнах контексту та повертають до основного діалогу лише свої кінцеві результати, що запобігає перевантаженню основного контексту об’ємними додатковими дослідженнями. Однак такий підхід має недолік: у огляді можуть бути пропущені деталі, які згодом знадобляться основному агенту, тому огляди мають містити посилання (шляхи до файлів, діапазони рядків), які дозволять агенту отримати необхідну інформацію за потреби.
Економіка: ціна за токен — це не вартість завдання
Управління контекстом також є питанням бюджету. Згадайте дослідження, яке виявило різницю у кількості токенів на виконану задачу у 40 разів між різними інструментами, при цьому різниця у показниках успішності була значно меншою. Це змінює питання, яке варто поставити. Замість „яка модель найдешевша?“ запитайте, скільки токенів потрібно всій системі агента для виконання завдання. Порівняйте два варіанти налаштувань.
Агент А: дешевша модель, некоефіцієнтний інструментарій
Model:
$X / million tokens
Task:
500k tokens
Агент Б: дорожча модель, ефективний інструментарій
Model:
2X / million tokens
Task:
100k tokens
Агент B платить вдвічі більше за кожен токен, але використовує лише п’яту частину токенів, тож кожне виконане завдання коштує приблизно 40 відсотків від того, скільки витрачає агент A, ще до урахування різниці в рівні успішності. Ціна моделі є вхідним параметром; економіка агентів визначається кількістю роботи, яку інструментарій змушує модель виконувати. Наша модель витрат, заснована на архітектурі, для агентних ШІ детальніше розглядає це питання.
Бездіяльні ходи та політики завершення
Частина витрат залишається непомітною у показниках за кожен запит. Уявіть собі агента, який постійно оголошує про свої наміри, не вживаючи жодних дій:
I should inspect the repository.
і знову на наступному ходу:
I should inspect the repository.
і ще раз:
I should inspect the repository.
Нічого не змінюється, проте кожен етап використовує токени, час відгуку, обчислювальні ресурси, простір контексту та, можливо, гроші. Дослідження цього інструментарію описує такі додаткові витрати як податок на очікування за кожне завдання, а не просто податок на токени: користувачі чекають на етапи, які нічого не досягають. Інструментарію потрібні правила завершення, і найпростішим з них є жорсткий ліміт кількості етапів.
MAX_TURNS = 30
if agent.turns >= MAX_TURNS:
stop()
Ліміт є запобіжним заходом, а не стратегією. Більш корисні інструменти виявляють сигнали, які свідчать про затримку виконання.
No progress
Repeated tool calls
Repeated identical observations
No state change
Test suite unchanged
Agent oscillation
Budget exhausted
Повторні однакові виклики інструментів, незмінні результати спостережень, відсутні зміни у файловій системі, тестовий набір, який постійно провалюється однаково, коливання між двома станами чи вичерпаний бюджет — усе це означає, що продовження роботи навряд чи допоможе. У такій ситуації система має зупинитися, підсумувати ситуацію та передати її на вищий рівень. Наш посібник щодо обмежених агентних циклів у TypeScript демонструє ці шаблони в коді.
Дизайн інструментів для програмування поступово стає окремою дисципліною. Нещодавнє дослідження коду одинадцяти систем-агентів для програмування виявило серед них поширені архітектурні шаблони: виконання інструментів, керування контекстом, механізми безпеки, оркестрація та можливості розширення. Автори дослідження роблять висновок, що інструменти для програмування еволюціонували від простих засобів до повноцінних платформ. Ранні агенти виглядали так:
LLM + tools
Сучасні системи нагадують стек.
LLM
↓
Agent loop
↓
Tool router
↓
Policy engine
↓
Sandbox
↓
Context manager
↓
Memory
↓
Verification
↓
Observability
↓
Orchestration
Модель все ще залишається ядром, але середовище її виконання — від маршрутизатора інструментів та двигуна політик до сандбоксу, менеджера контексту, пам’яті, механізмів перевірки, можливостей спостереження та оркестрації — стало самостійним продуктом.
Шаблон структури для агента програмування
Розумна початкова архітектура для агента-кодувальника передбачає розміщення циклу агента безпосередньо під моделлю та розділення його на три компоненти: маршрутизатор інструментів, менеджер контексту та пам’ять. Виклики інструментів проходять через двигун політик до сандбоксу, результати проходять перевірку, а все фіксується системою спостереження.
┌──────────────┐
│ Model │
└──────┬───────┘
│
↓
┌─────────────────┐
│ Agent Loop │
└────────┬────────┘
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Tool Router Context Memory
│ Manager │
↓ │ ↓
Policy Engine │ Persistent State
│ │
↓ ↓
Sandbox ←────── Tools
│
↓
Verification
│
↓
Observability
Зробіть кожен компонент незалежно тестованим: проводьте юніт-тести для двигуна політик за допомогою синтетичних викликів, перевіряйте обробку шляхів та оцінюйте працездатність верифікатора на відомих несправних даних, усе це без використання моделі.
Розвивайте інфраструктуру на основі невдач, а не фреймворку
Вам не потрібен величезний фреймворк агентів, щоб отримати ці переваги. Цикл у центрі може залишатися невеликим навіть після додавання двигуна політик, сандбоксингу та перевірки.
while turns < MAX_TURNS:
action = model.next_action(context)
if action.is_final:
return action.answer
if not policy.allows(action):
context.append("Action denied")
continue
result = sandbox.execute(action)
verification = verifier.check(result)
context.append(
summarize(result, verification)
)
Зверніть увагу на порядок виконання: перевірка політики відбувається перед виконанням, дія, яка була відхилена, повертається до моделі замість того, щоб призвести до зупинки циклу; виконання завжди проходить через сандбокс, а те, що повертається в контекст, — це узагальнення результату та його перевірка, а не первинний вихідний даний. Додавати складність слід лише у відповідь на спостережувану несправність.
Agent deleted something?
→ add execution policy
Agent accessed the wrong file?
→ strengthen sandbox
Agent forgets architecture?
→ add persistent project memory
Agent produces bad code?
→ add verification
Agent becomes expensive?
→ optimize context
Agent loops?
→ add termination detection
Кожен симптом відповідає саме одному шару. Це набагато краще, ніж вводити п’ятдесят абстракцій, перш ніж зрозуміти, яка саме проблема існує. Для більш детального обговорення того, чи варто створювати цей цикл самостійно чи використовувати готовий, дивіться runtime harnesses vs composed frameworks.
Репозиторій як база знань агента
У розробці з використанням агентів репозиторій — це більше, ніж просто вихідний код. Він може містити все, що потрібно агенту для роботи над проектом: рішення щодо архітектури, команди для розробки та тестування, термінологію сфери діяльності, схеми, плани, посібники з експлуатації та інструкції, специфічні для агента; усе це версіонується разом із кодом, який воно описує. Власні матеріали OpenAI про інженерію керування агентами підкреслюють цей момент, розглядаючи версіоновані об’єкти, що знаходяться у репозиторії, як основу інформації про те, що агент повинен знати для розуміння та зміни проекту, і пропонують використовувати карту, яка вказує на конкретні документи, а не один величезний файл із інструкціями. Висновок простий: рішення щодо дизайну, яке існує лише в голові когось чи у чат-розмові, не існує для агента. Забезпечення доступності знань стало частиною архітектури програмного забезпечення.
Hooks: поведінка, яку моделі не потрібно пам’ятати
Гачки належать до найкорисніших примітивів харчування. Гачок дозволяє часу виконання реагувати на подію життєвого циклу за допомогою детермінованого коду. Найбільш очевидним прикладом є контроль викликів інструментів.
Before tool call
↓
Check policy
↓
Allow / deny
Інший гачок забезпечує стабільність якості коду після кожної зміни.
After file edit
↓
Run formatter
↓
Run type checker
Третій гачок захищає інформацію до того, як контекст буде стиснутий.
Before context compaction
↓
Persist important state
Четвертий гачок створює історію аудиту.
After task completion
↓
Generate audit record
Claude Code описує гачки як команди, що запускаються під час подій життєвого циклу, які працюють детерміновано та можуть, серед іншого, заблокувати виклик інструменту перед його виконанням. Їхня сила полягає у тому, що вони повністю виводять поведінку за межі логіки моделі. Замість того, щоб писати у запиті „будь ласка, не забудьте запустити форматувальник“ та сподіватися, час виконання просто запускає форматувальник щоразу.
Ніколи не дозволяйте моделі контролювати межі
Моделі є ймовірнісними; межі безпеки — ні. Цей антишаблон делегує прийняття рішень моделі:
if model_says_safe:
execute()
Цей шаблон делегує його інфраструктурі, яка не може змінити свою відповідь:
if operating_system_allows:
execute()
Використовуйте моделі для рішень, які виграють від оцінки ситуації, та детерміновану інфраструктуру для рішень, які потребують гарантій. На практиці кожен шар відповідає на свої власні запитання.
Model:
Should I modify this file?
Harness:
Is this file inside the workspace?
OS:
Can this process write to the file?
Human:
Should this high-risk action proceed?
Модель вирішує, чи є зміна хорошою ідеєю, інструмент перевіряє, чи знаходиться ціль у робочому просторі, операційна система вирішує, чи може процес записати файл, а людина вирішує, чи слід продовжити дію з високим ризиком. Такі багатошарові рішення набагато надійніші, ніж очікування від одного компонента, що все зробить правильно.
Інструменти посилюють моделі; вони не замінюють їх
Хочеться дійти висновку, що кріплення мають більше значення, ніж моделі. Однак докази цього не підтверджують. У досліджуваній схемі вибір кріплення суттєво впливав на ефективність використання ресурсів, але значно менше — на успішність виконання завдань, і жодна кількість оптимізацій часу виконання не може перетворити слабку модель на сильного інженера програмного забезпечення. Чіткий спосіб розділити ці два аспекти:
Model capability
=
What the agent can reason about
Harness quality
=
How effectively that capability is deployed
Блискуча модель у поєднанні з поганим середовищем виконання марнує величезні обсяги ресурсів та грошей. Ретельно оптимізоване середовище виконання навколо слабкої моделі все одно призводить до слабких рішень, просто безпечно та ефективно. Вам потрібні обидва елементи.
П’ять запитань, які потрібно поставити перед розгортанням будь-якого агента
1. Що він може робити?
Перелічте всі інструменти та позначте кожну небезпечну операцію.
read
write
delete
execute
network
deploy
send_message
2. До чого він може дістатися?
Описи інструментів розкривають лише частину картини. Перевірте, до чого насправді може отримати доступ процес:
filesystem
network
environment
secrets
processes
credentials
3. Що залишається після перезапуску?
Перезапустіть агента та дізнайтеся:
What does it remember?
What does it forget?
Where is important state stored?
4. Хто перевіряє результат?
Для операцій із наслідками двокроковий процес недостатній:
generate → approve
Введіть незалежні перевірки між генерацією та схваленням:
generate
↓
test
↓
review
↓
approve
5. Скільки насправді коштує кожне завдання?
Кількість токенів на запит сама по собі є оманливою:
tokens per request
Краще вимірювати результати:
tokens per successful task
latency per successful task
tool calls per task
retries per task
human interventions
Кількість токенів, затримки, викликів інструментів, спроб повторного виконання та людських втручань за кожне успішне завдання — це показники, які визначають, чи варто запускати систему.
Функціональне визначення продакшн-агента
Об’єднання всіх елементів дає більш точне визначення.
Agent =
Model
+ Tools
+ Execution Environment
+ Policy
+ Memory
+ Context Management
+ Verification
+ Observability
Кожен елемент займає своє місце. Без моделі немає інтелекту; без інструментів — немає дій; без середовища виконання та політики агент може бути небезпечним; без пам’яті довготривалі завдання стають крихкими; без управління контекстом витрати зростають експоненційно; без перевірки помилки поширюються непоміченими; а без можливості спостереження неможливо відновити те, що сталось, коли щось пішло не так.
Підсумок
Дискусії в галузі починають зміщуватися від того, яка модель досягає найкращих результатів у тестах, до того, який середовище виконання дозволяє моделі надійно виконувати корисну роботу. Виробники об’єднуються навколо однакових основних елементів: OpenAI тепер продає інфраструктуру керованих агентів, яка включає сандбокси, обробку контексту, пошук інструментів, виклики інструментів з коду та довготривале виконання, тоді як Anthropic надає постійні інструкції, навички, підагентів та детерміністичні механізми. Дослідження починають розглядати ці елементи як експериментальні змінні, а не модель як цілісну систему. Ці функції розвиваються швидко, тому перевіряйте актуальну документацію.
Простий підхід до створення агента є таким:
Pick LLM
+
Add tools
=
Agent
Реалістичний підхід виглядає ось так:
Model
↓
Agent Runtime
↓
┌─────────┼─────────┐
↓ ↓ ↓
Policy Context Memory
↓ ↓ ↓
Sandbox Tools Persistence
└─────────┼─────────┘
↓
Verification
↓
Observability
Модель приймає рішення; інструментарій визначає умови, за яких ці рішення перетворюються на дії. Перед вибором фреймворку запитайте себе, що станеться, якщо модель помилиться, та побудуйте інструментарій на основі цієї відповіді.
- Застосовуйте детерміністичні правила в коді та хуках, а не у запитах користувача.
- Вважайте політики інструментів першою лінією захисту, а сандбокс операційної системи, включаючи обмеження мережі та ресурсів, справжньою межею.
- Розділяйте стани розмови, проекту та інструментарію за періодом їх існування та зберігайте дані проекту перед їх стисненням.
- Зберігайте незалежність перевірок та нехай рецензенти повідомляють про проблеми, а не виправляють їх.
- Оптимізуйте кількість токенів на успішне завдання та зупиняйте виконання, яке більше не приносить прогресу.
Метою є не агент, який ніколи не помиляється, а система, в якій помилка моделі не автоматично перетворюється на інцидент у продакшені.