Вивчення інженерії агентних ШІ в порядку, якого навчають збої.

Розробники, які переходять до інженерії агентів, часто намагаються оволодіти кожною платформою одночасно, пробуючи LangChain, CrewAI, AutoGen та LangGraph протягом одного тижня, не створюючи при цьому нічого функціонального. Проблема полягає у порядку дій: вони вивчають інструменти, перш ніж зрозуміти проблеми, які ці інструменти призначені усунути. Цей посібник пропонує чотирнадцятикроковий шлях у тому порядку, в якому навички насправді будуються одна на одній, від базового Python до створення агента, який працює без нагляду. Протягом цього процесу ви дізнаєтесь про три основні моди збою, які впливають на кожне проектне рішення, про мінімальний набір інструментів, який покриває більшість завдань у продакшені, а також про структурні шаблони (файли стану, перевірка виконавцем, багатошарова оцінка та визначення прав доступу), які відрізняють демо-версію від системи, якій можна довіряти вже з першої ж ночі.

Частина 1: Ментальна модель

1. Інженерія агентів — це не інженерія запитів з новою назвою

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

Конкретне визначення таке: ви створюєте програмне забезпечення, у якому LLM обирає наступну дію, використовує інструмент для її виконання, перевіряє результат та повторює процес до завершення завдання, без участі людини на кожному кроці. Чат-бот відповідає на повідомлення. Агент обирає дії, виконує їх, перевіряє результати та поступово вдосконалює свою роботу. Саме ця різниця є суттю завдання.

Це створює три обов’язки, які раніше не вимагалися у роботі з запитами:

• Розгляд помилок як ключової проблеми. Агенти постійно зазнають невдач: API досягають тайм-ауту, JSON повертається у неправильній формі, модель вигадує виклики інструментів, а результати роботи інструментів не відповідають їхнім схемам. Код, який припускає успішну роботу, зламається у найгірший можливий момент, зазвичай під час демонстрації.
• Керування станом. Окремий виклик LLM нічого не зберігає. Агент, який виконує десять кроків із викликами інструментів, повторними спробами та підагентами, потребує структурованого, стабільного стану, який зберігатиметься поза межами будь-якого контекстного вікна.
• Інтеграція оцінювання в інфраструктуру. Не існує інтуїтивного способу визначити, чи правий агент. Потрібні автоматизовані механізми, такі як тести, критерії оцінювання чи модель судді, які відхилятимуть погані результати без необхідності перегляду кожного виконання людиною.

Описи посад для цих ролей часто нагадують каталог. Тут згадуються фреймворки оркестрації (LangGraph, LangChain, LlamaIndex), протоколи (MCP, A2A), функції моделей (виклик функцій, структуровані результати, кешування запитів), методи пошуку інформації (RAG, RAGAS, гібридний пошук, переранкінг, моделі ембеддингу, векторні та графові бази даних), а також оперативні навички (виконання в ізольованих середовищах, можливість спостереження, оцінка), причому зазвичай додається вимога до здатності швидко внесення змін. Список може здатися перевантаженим, але більшість пунктів — це кілька основних ідей під різними назвами. Якщо зрозуміти ці ідеї, назви продуктів стане легко розпізнавати.

2. Три способи збою пояснюють більшу частину завдань

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

Лінь агента. Стикаючись із довгим, багатоетапним завданням, модель зупиняється раніше та повідомляє про успіх після часткового виконання. Вона вирішує 20 з 50 залишених завдань та описує решту як виконані. Засобом протидії є чітка умова зупинки, яку перевіряє щось інше, окрім самої робочої моделі.

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

Відхилення від мети. Протягом багатьох кроків, особливо після узагальнення чи стиснення контексту, агент поступово втрачає орієнтацію щодо початкової мети. Таке обмеження, як «не торкатися модуля оплат», може непомітно зникнути вже на 47-му кроці. Захистом є постійний файл специфікацій, який читається щоразу під час виконання та містить обмеження, які інакше були б втрачені моделлю.

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

3. Невелика основна стек-структура та чотири речі, які варто відкласти

Списки вимог є довгими, але основна робота продакшн-агента зосереджується на чотирьох шарах, які найкраще опановувати в такому порядку:

Core stack (learn these, in this order):
1. Python + async    : the bedrock; everything else builds on it
2. LLM APIs          : Anthropic, OpenAI; understand tokens, context, costs
3. Tool use / MCP    : function calling; how models act on the world
4. LangGraph         : stateful orchestration for multi-step, multi-agent work

Відкладіть наступне до того, як ви випустите принаймні одного справжнього агента:

• Доопрацювання. Ранні проекти майже ніколи не потребують цього. Здатна базова модель із добре спроєктованими запитами зазвичай краща за доопрацьовану модель із поганими запитами.
• Надмірне зосередження на базах даних векторів. Щось на кшталт Chroma підходить для локального використання, а сервіс типу Pinecone — для продакшну. Відкладіть вибір до того часу, поки отримання даних справді не стане проблемою у вашому проекті.
• Зміна фреймворків. Виберіть один фреймворк оркестрації (LangGraph є гарним стандартним вибором), завершіть проект, а лише потім починайте експериментувати. Зміна інструментів щотижня через обіцянку простоти не гарантує завершення жодного проекту.
• Агенти голосу та браузера. Це спеціалізовані рішення, створені на основі тих самих принципів. Спочатку опануйте текстових агентів — їхні патерни можна застосувати й тут.

Частина 2: Основні елементи

4. Python та асинхронний код

Вам не потрібна досконала впевненість у Python, але достатньо знань для виправлення помилок, адже агенти часто зазнають невдач. Зосередьтесь на:

• Класи та моделі даних. Агенти передають структуровані дані з кроку в крок, тому їх потрібно моделювати. Схема Pydantic виступає як контракт між викликами інструментів та логікою агента; сприймайте її як обов’язкову, а не факультативну.
• Асинхронність з asyncio. Агенти проводять багато часу у очікуванні виконання інструментів: запиту до бази даних, HTTP-запиту чи підпроцесу. Синхронний код блокується під час кожного очікування, тоді як асинхронний код може виконувати інші завдання. Повільний код агента часто є синхронним кодом, який очікує по черзі.

HTTP та REST. Без API агент може лише міркувати, але не діяти. Навчіться читати документацію API, дотримуватися обмежень швидкості, інтерпретувати відповіді на помилки та розумно повторювати спроби. Інструмент, який зупиняється при коді HTTP 429, — це інструмент, на який агент не може покладатися.

Обробка помилок. Огорніть кожне викликання інструменту блоком try/except. Агенти працюють без нагляду, і некерована виняткова ситуація, яка виводить стек-трейс та завершує роботу, нікому не допоможе посеред ночі.

Практичний критерій: якщо ви можете доручити завдання молодшому інженеру разом із чек-листом та покластися на набір тестів для виявлення його помилок, це означає, що ви знаєте достатньо Python, щоб почати. Більше можна дізнатися пізніше.

5. Основи LLM: токени, контекст та витрати

Моделі на кшталт Claude, GPT та Gemini є потужними, але потребують керівництва, а ви не можете керувати тим, чого не розумієте.

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

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

Інференція, а не навчання. Ви майже ніколи не будете навчати модель. Ви викликаєте інференцію на чужій моделі та платите за кожен токен. Витрати складаються з кількості вхідних токенів помноженої на їхню ціну плюс кількість вихідних токенів помножена на їхню ціну, тому цикл із 50 викликами у контексті з 20 000 токенів призводить до значних витрат.

Формулювання запитів для агентів. Запити до агентів відрізняються від запитів у чаті. Найважливішими є три підходи: chain-of-thought, коли модель чітко обмірковує ситуацію перед дією; ReAct — цикл обмірковування, дії та спостереження; та reflection, коли модель критикує власний проект перед тим, як його надати. Більшість інших технік формулювання запитів є варіаціями цих підходів. Щоб детальніше дізнатися про цикл ReAct, перегляньте як агенти ReAct поєднують обмірковування з діями у реальному світі.

6. Використання інструментів та MCP перетворюють чат-бота на агента

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

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

Більшість практичних інструментів агента належать до чотирьох категорій. Наведені нижче приклади ілюструють їх: інструменти для читання (спостереження за світом), інструменти для запису (зміна стану), інструменти для виконання коду та інструменти для перевірки роботи:

# Category 1: Read  (agent observes the world)
def search_codebase(query: str, path: str) -> list[str]: ...
def fetch_url(url: str) -> str: ...
def read_file(path: str) -> str: ...

# Category 2: Write (agent changes state)
def create_file(path: str, content: str) -> None: ...
def open_pull_request(title: str, body: str, branch: str) -> str: ...
def send_slack_message(channel: str, text: str) -> None: ...

# Category 3: Execute (agent runs code)
def run_tests(test_path: str) -> dict: ...
def execute_sql(query: str, db: str) -> list[dict]: ...

# Category 4: Verify (agent checks its own work)
def lint_code(file_path: str) -> list[str]: ...
def run_type_checker(path: str) -> bool: ...

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

Протокол контексту моделі (MCP) — це новий стандарт, який замінює індивідуальний код інтеграції на протокол. Поширеною аналогією є USB-C у сфері штучного інтелекту: замість того, щоб щоразу писати спеціальний адаптер, коли агенту потрібен GitHub, Slack чи база даних, достатньо під’єднати існуючий сервер MCP, і програма-хост виявляє можливості цього сервера та використовує їх без додаткового коду.

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

7. Отримання інформації, оскільки обсяг контексту має межі

Генерація з підтримкою отримання інформації надає агенту знання, які не вміщуються в його контекст. Це реакція на сувору обмеженість, а не модна тенденція: вікно контексту є обмеженим, тоді як ваш кодовий базис та документація — ні.

Система отримання інформації складається з чотирьох основних частин:

• Чанкінг — це те, де початківці найчастіше роблять помилки. Занадто великі чанки містять забагато нерелевантного матеріалу; занадто маленькі чанки втрачають сенс. Оптимальний розмір залежить від контенту, і кодові джерела зазвичай потребують інших меж (наприклад, цілих функцій) порівняно з прозовою документацією.
• Ембеддинги — це технології, які уможливлюють пошук схожостей. Модель ембеддингів перетворює текст на числовий вектор, так що схожі уривки створюють вектори, розташовані поруч.
• Пошук — це процес, який знаходить збережені вектори, найближчі до введеної запиту, та повертає їхні чанки.

Оцінка — це критерій, який визначає систему, що справді працює, та таку, яка лише виглядає працюючою. Ключовими показниками є точність пошуку (чи було отримане матеріал дійсно релевантним?), вірність (чи залишалась відповідь у межах знайденого матеріалу?) та релевантність відповіді (чи вона відповідає на запитання?). Інструменти на кшталт RAGAS або моделей-суддів можуть оцінювати їх. Без вимірювань покращення є лише припущенням.

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

8. Оркестрація з підтримкою стану за допомогою LangGraph

Одне викликання LLM не є агентом. Агент виконує кілька кроків, зберігає стан між ними, приймає рішення на основі спостережень та відновлюється після збоїв. LangGraph надає структуру саме для цього.

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

Наведений нижче скетч визначає стан із завданням, планом, результатами, помилками та флагом завершення, а потім реєструє чотири вузли: планувальника, який ділить роботу, виконавця, який виконує один крок, перевірювача, який перевіряє результат, та обробника помилок, який повторює спроби або піднімає проблему вище. Умовний ребро після перевірювача є серцем циклу: завершити роботу, коли стан вказує на завершення, направити сигнал до обробника при наявності помилок, а в іншому випадку виконати наступний крок. Зауважте, що це лише фрагмент; для запуску графа також потрібна точка входу, решта ребер та виклик функції compile().

from langgraph.graph import StateGraph, END
from typing import TypedDict

class AgentState(TypedDict):
    task: str
    plan: list[str]
    results: list[str]
    errors: list[str]
    done: bool

graph = StateGraph(AgentState)

graph.add_node("planner", plan_task)       # breaks work into steps
graph.add_node("executor", execute_step)   # runs one step
graph.add_node("verifier", verify_output)  # checks the result
graph.add_node("handler", handle_error)    # retries or escalates

graph.add_conditional_edges(
    "verifier",
    lambda state: END if state["done"] else
                  "handler" if state["errors"] else
                  "executor"
)

Порівняно з вручну написаним циклом у Python, ця фреймворк-структура додає три можливості:

• Пункти перевірки. Під час компіляції графа з використанням механізму перевірки стан зберігається після кожного кроку, тому перерваний процес (завислий ноутбук, перезапущена сесія) може продовжитися з того місця, де зупинився, замість того щоб починатися знову.
• Паузи з участю людини. Встановлення значення interrupt_before для вузла з високою значимістю змушує граф зупинитися, показати запропоновану дію та чекати схвалення перед продовженням. Це є важливою складовою, яка відрізняє демонстраційний агента від агента у продакшені.
• Паралельні гілки. Незалежні кроки можуть виконуватися одночасно, поки фреймворк об’єднує їхні результати у загальний стан, тож вам достатньо описати структуру, замість того щоб писати код синхронізації.

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

Частина 3: Правильне створення

9. П’ять проектів по черзі

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

1. Агент із одним інструментом. Виберіть один API, наприклад GitHub або сервіс прогнозу погоди, та напишіть агента, який вирішує, чи потрібен цей API, викликає його та інтегрує отриману відповідь у свою відповідь. Використовуйте сирий API Anthropic або OpenAI без жодних фреймворків, щоб бачити цикл використання інструментів без будь-яких абстракцій, які б його приховували.
2. Агент ReAct із трьома інструментами. Додайте пошук у Інтернеті, калькулятор та виконувач коду, та самостійно створіть цикл „розуміння – дія – спостереження“. Саме тут зазвичай вперше можна побачити, як агент помічає та виправляє власну помилку.
3. Отримання інформації з відомої вам бази коду. Створіть індекс справжнього репозиторію, реалізуйте механізм отримання інформації з нього та ставте запитання, які вимагають розуміння кількох файлів. Вимірюйте якість отримання інформації та виправляйте ті частини, які не працюють належним чином. Цей проєкт демонструє, чому розділення на частини має величезне значення.

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

Запланований автономний цикл. Запуск проекту чотири за графіком cron без спостереження. Надайте йому файл стану, щоб він продовжував роботу замість того, щоб перезапускатися, жорсткий бюджет витрат, щоб він не підвищував вартість API, та журнал аудиту, який фіксує виконані дії. Саме тут «функціонує в демо-версії» перетворюється на «функціонує без нагляду».

10. Файл стану: агенти забувають, файли — ні

Це звучить занадто просто, щоб мати значення, але саме це є основою кожного надійного автономного агента: файл у форматі Markdown, документ JSON чи рядок у базі даних, які знаходяться поза межами розмови та фіксують, що було зроблено та що буде далі.

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

// STATE.md: what every working autonomous agent needs
{
  "last_run": "2026-07-01 03:00 UTC",
  "items_processed": 47,
  "items_remaining": 12,
  "in_progress": [
    "fix/auth-token-refresh: tests passing, awaiting CI"
  ],
  "completed": [
    "fix/null-check-in-billing: merged, CI green"
  ],
  "escalated_to_human": [
    "src/payments/refund.ts: root cause unclear after 3 theories"
  ],
  "lessons": [
    "2026-06-30: E2E tests require Stripe webhook secret in env. Skip if missing.",
    "2026-06-29: Windows runner has TLS 1.2 issue. Use bash, not PowerShell."
  ]
}

Список уроків заслуговує на увагу. Саме він допомагає циклу перестати повторювати одні й ті самі помилки, а також є постійною специфікацією, яка запобігає відхиленню від поставлених цілей. Існують два поширені формати. Файл у форматі Markdown, який зберігається у репозиторії, контролюється за версіями, його легко порівнювати, і він простий у використанні, що підходить для окремих осіб та невеликих команд. Для циклів у продакшені, які мають спостерігати кілька людей, краще підходить зовнішня система, така як інструмент для відстеження проблем типу Linear або база даних. Принцип простий: агент забуває, репозиторій пам’ятає, тому все важливе має знаходитися поза межами контекстного вікна.

11. Maker-checker: розділення автора та рецензента

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

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

Різниця в підходах до коду: неправильна версія просить одного агента виправити баг та підтвердити своє виправлення. Правильна версія запускає інструмент виправлення на одній моделі, а потім передає лише отриманий код та конкретну шкалу оцінювання рецензентові, давши йому вказівку ігнорувати авторство та наміри та повертати результат із обґрунтуванням або відмову з посиланнями на конкретні рядки. Рецензент використовує більш потужну модель, оскільки оцінка є складнішим завданням:

# Wrong: one agent does both
result = await agent("Fix the auth bug and verify your fix is correct")

# Right: maker and checker are separate agents, separate contexts
fix = await agent(
    "Fix the auth bug in src/auth/middleware.ts",
    model="sonnet"
)

review = await agent(
    f"""Review this fix against the rubric below.
    Do not consider who wrote it or their intent.

    Fix:
    {fix.code}

    Rubric:
    - Does it handle the null case on line 47?
    - Does it preserve the existing token expiry logic?
    - Does the test cover the regression case?

    Return: PASS with reasoning, or FAIL with specific line references.""",
    model="opus"   # harder model for the harder judgment task
)

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

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

12. Оцінка: бар’єр, який робить цикл надійним

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

• Детерміністичні перевірки. Тести, лінтери, перевірювачі типів та процеси компіляції дають бінарний результат без будь-яких суджень. Це перший та найдешевший бар’єр; щоразу, коли детерміністична перевірка може відхилити поганий результат, використовуйте її.

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

Людське схвалення. Незворотні дії, такі як розгортання в продакшен, код оплати, примусові оновлення та зміни архітектури, потребують схвалення людини перед тим, як агент зможе їх виконати. У LangGraph функція interrupt_before забезпечує цю паузу. Використовуйте її лише для дій, виправлення яких є складним, а не для блокування всіх операцій.

Щоб дізнатися, чи ефективно працює процес оцінки, відстежуйте кількість прийнятих змін. Якщо агент, створений для виправлення невдалих тестів, вирішує 70% своїх проблем за допомогою змін, які проходять перевірку CI та людський огляд, його показник становить 70%. При рівні нижче приблизно 50% люди витрачають час на завершення роботи, яку почав агент, і цей цикл коштує більше, ніж економить.

13. Безпека: агент без нагляду — це поверхня для атак без нагляду

Будь-який автономний агент, який впливає на реальну інфраструктуру, є джерелом вразливостей у сфері безпеки, що працює без нагляду. Ризик є конкретним: за допомогою непрямої ін’єкції команд агент, який читає зловмисний електронний лист чи веб-сторінку, може бути спрямований на виконання команди атакувальника. Основні загрози:

• Введення коду через результати роботи інструментів. Веб-сторінки, запити до GitHub та заявки на підтримку можуть приховувати інструкції всередині звичайного контенту — наприклад, рядок, який наказує агенту ігнорувати попередні інструкції та видаляти тестові файли. Карантин є засобом захисту: будь-який агент, який має доступ до ненадійного контенту, отримує лише право на читання. Треба тримати агентів, які лише читають, та агентів, які виконують дії, окремо.
• Поступове розширення прав. Агент, схвалений із правом лише на читання, отримує ще одне право на запис „для зручності“, і ніхто більше це не перевіряє. Регулярно (раз на місяць є розумним темпом) перевіряйте права та надавайте лише мінімум, необхідний для виконання завдання.
• Конфіденційна інформація в журналах. Детальне формування журналів у довготривалих циклах розсіює облікові дані в результатах роботи, які ніхто не контролює. Вимикайте детальне формування журналів у продакшн-циклах та очищуйте те, що залишилося.

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

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

# Safe agent permission model
permissions = {
    "auto_approve": [
        "Read(*)",           # read anything
        "Bash(npm test)",    # run tests
        "Bash(git status)",  # observe state
        "Bash(git diff*)",   # observe diffs
    ],
    "require_human": [
        "Bash(git push*)",   # never push without approval
        "Edit(.env*)",       # never touch secrets
        "Edit(src/payments/*)",  # never touch payments code
        "Bash(*--force*)",   # never force anything
    ]
}

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

14. Перетворення навичок на кар’єру

Шлях навчання має вести кудись. Ось реалістичний погляд на те, де можна застосувати ці навички.

Що показувати. Уникайте копій навчальних туторіалів. Три справжні проекти, які вирішили реальні проблеми, мають набагато більшу цінність:

• Агент, який працює за графіком, результати роботи якого ви використовуєте на практиці, як-от цикл, створений на кроці 9.
• Система з кількома агентами, у якій принаймні два агенти виконують різні функції, що структурно запобігає тому, щоб один екземпляр моделі виконував обидві функції, як у патерні «створювач-перевірячий» з кроку 11.
• Система пошуку з задокументованими показниками оцінки, яка демонструє результати до та після виправлення проблем у процесі пошуку, а не лише те, що вона працює.

Скільки часу це займає. Як приблизна оцінка, людина, яка вже добре володіє Python та присвячує 10–15 годин на тиждень навчанню, може очікувати, що цей шлях займе близько восьми місяців. Вважайте це плановою цифрою, а не обіцянкою.

З чого почати. Ролі сильно відрізняються за ступенем доступності для початківців:

• Інженер з автоматизації за допомогою ШІ у компанії, чия основна діяльність не пов’язана з ШІ. Тут потрібна людина, яка може створити, наприклад, цикл для автоматичного виправлення тестів протягом ночі. Достатньо знань LangGraph, MCP та основ CI; десятки фреймворків не потрібні.
• Інженер з ШІ у стартапі, продуктом якого є агент. Це вимагає повного набору навичок у сферах отримання даних, оцінки, проектування багатоагентних систем та їх розгортання, з вищими вимогами та можливостями.

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

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

Підсумок

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

• Вивчайте концепції перед фреймворками та оцінюйте кожний інструмент за тим, який спосіб невдачі він запобігає: лінощам, самоперевагам чи відхиленням.
• Зберігайте стан поза межами моделі, у файлі чи базі даних, яку агент перечитує під час кожного запуску.
• Ніколи не дозволяйте автору змін бути її рецензентом; надавайте рецензенту лише результат та конкретну шкалу оцінювання.
• Створіть ієрархію оцінки від детермінованих перевірок до оцінювачів та схвалення людиною, а також вимірюйте частку прийнятих змін.

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

Для цього не потрібен науковий досвід чи спеціалізовані навички налаштувань. Потрібні міцні знання Python, чітке розуміння причин помилок ШІ та звичка встановлювати механізми перевірки ще до початку виконання циклу. Створіть першого агента, дозвольте йому працювати всю ніч, а вранці перегляньте отримані зміни.

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

• Від однокомірного чат-бота до агента, підтримуваного MCP, у LangGraph — Створюйте додаток LangGraph шар за шаром: стани та функції їх зміни, краї, цикли використання інструментів, потоки з можливістю збереження стану, три режими потокової обробки даних та інструменти, які надаються через MCP.
• Проектування чотирирівневої пам’яті агента з використанням LangGraph та Amazon Bedrock — Дізнайтеся, як надати агентам на основі LLM функції епізодичної, семантичної та процедурної пам’яті на платформах Bedrock та LangGraph, а також як захистити її від отруєння даними, витоку конфіденційної інформації та несанкціонованого доступу.