Від мети до контрольованих дій: цикли, перевірка та дозволи в штучних інтелектуальних агентах
Дізнайтеся, як штучні інтелектуальні агенти перетворюють мету на виклики інструментів за допомогою циклу планування-дії-спостереження, та чому саме перевірка, рівні автономії та шари дозволів визначають їхню безпеку.
Більшість людей вперше познайомилися з моделями мови як з пристроями для відповідей на запитання: вводимо запит, отримуємо відповідь — і все. Системи агентів порушують цю схему. Маючи мету, вони планують дії, використовують інструменти, перевіряють результати та продовжують роботу, доки завдання не буде виконане. У цьому огляді розглядаються цикли, інструменти, пам’ять та багатоагентні конфігурації, а потім акцентується увага на найважливішому у практичному використанні: перевірці роботи агента та обмеженні його повноважень.
Відповідання проти роботи над метою
Класичний чат-бот виконує дію один раз: надходить запит, модель формує відповідь, і більше нічого не відбувається.
User
↓
Question
↓
AI
↓
Answer
Якщо запитати його «Що таке машинне навчання?», ви отримаєте пояснення, і більше нічого. Агент організований навколо мети, якої досягають через послідовність дій із зворотним зв’язком між ними.
User
↓
Goal
↓
AI Agent
↓
Plan
↓
Use Tools
↓
Observe Results
↓
Take More Actions
↓
Complete Goal
Запит на кшталт „Проаналізуйте цей набір даних та створіть звіт“ потрібно розділити на конкретні етапи:
Read dataset
↓
Understand columns
↓
Clean data
↓
Analyze statistics
↓
Create graphs
↓
Find patterns
↓
Write report
Коротко кажучи, чат-бот відповідає, тоді як агент виконує роботу та коригує її протягом виконання.
Що робить систему агентом
Не існує єдиної узгодженої визначення. Практичне: агент бере на себе завдання, приймає рішення, використовує наявні інструменти, оцінює результати та обирає подальші дії до досягнення мети. Визначальною рисою є гілка внизу, яка повертає керування назад.
USER GOAL
↓
AI AGENT
↓
PLAN
↓
SELECT ACTION
↓
USE TOOL
↓
OBSERVE
↓
EVALUATE
↓
NEXT ACTION?
↙ ↘
YES NO
↓ ↓
Continue Finish
Без цього циклу у вас є конвеєр, який працює лише один раз. З ним система може відновитися після несподіванок, що є як її силою, так і причиною необхідності нагляду.
Цикл „мислення, дія, спостереження“
Найпростішою ментальною моделлю для цього циклу є «думати, діяти, спостерігати». Уявіть собі, що ви просите агента знайти найкращий ноутбук у межах вашого бюджету та порівняти трьох кандидатів. Внутрішньо він може діяти ось так:
Goal
↓
Understand requirements
↓
Search for products
↓
Read results
↓
Compare specifications
↓
Check prices
↓
Evaluate options
↓
Generate recommendation
Агент не запам’ятовує інформацію про ноутбуки з пам’яті тренування. Він шукає дані у реальних джерелах та ґрунтує свої рекомендації на знайденому, і саме цей зв’язок із зовнішнім світом відрізняє його від простої генерації тексту.
Три компоненти: модель, інструменти та стан
Базового агента можна описати за допомогою трьох елементів.
Модель як приймач рішень
Зазвичай це велика мовна модель, яка інтерпретує інструкції та вирішує, що робити далі.
Інструменти як можливості
Інструменти — це зовнішні здібності, які може використовувати агент, наприклад:
Search
Python
Calculator
Database
API
File system
Computer
Vision model
Стан як поточний запис
Стан — це те, що агент знає про завдання на даний момент. Він відповідає на такі запитання:
What did I search?
What did I find?
What have I already done?
What remains?
Разом ці три компоненти впливають на дії, які виконує агент:
AI AGENT
│
┌──────────┼──────────┐
↓ ↓ ↓
Model Tools Memory
│ │ │
└──────────┼──────────┘
↓
Actions
Щоб дізнатися більше про ці основні елементи, перегляньте наш посібник про цілі, інструменти, пам’ять та цикл агента.
Чому інструменти мають таке велике значення
Якщо попросити модель помножити 938472 на 827391, вона може отримати правильний результат, але прогнозує цифри замість того, щоб обчислювати їх, тому калькулятор чи Python є надійнішими. Агент може передати цю роботу іншому:
User
↓
LLM
↓
"I need exact arithmetic."
↓
Calculator
↓
Result
↓
LLM
↓
Answer
Моделі не обов’язково робити все самостійно. Вона делегує завдання.
Вибір правильного інструменту для вхідних даних
Як агент обирає серед своїх інструментів? Припустимо, він може користуватися усіма ними:
Python
SQL
Search
Calculator
Vision Model
File Reader
Email API
Calendar
Якщо поставлена задача звучить як „Подивіться на цю таблицю з продажами та поясніть, чому знизилися доходи“, система на основі типу вхідних даних, їхньої структури та завдання обирає відповідний інструмент:
Input = Spreadsheet
↓
Data = Tabular
↓
Task = Analysis
↓
Tool = Python/pandas
Після цього обраний інструмент виконує основну роботу та передає отримані результати:
pandas
↓
Analyze sales
↓
Find patterns
↓
Return results
Потім агент інтерпретує ці результати. На практиці вибір інструменту сильно залежить від чітких назв та описів інструментів, адже саме це бачить модель.
Об’єднання кількох інструментів у один робочий процес
Розгляньмо завдання „Проаналізувати наші дані про продажі, створити графік та надіслати звіт моєму керівнику“, яке включає аналіз, візуалізацію, написання та доставку:
Sales Dataset
↓
Python / pandas
↓
Statistical Analysis
↓
Matplotlib
↓
Create Charts
↓
LLM
↓
Write Report
↓
Email Tool
↓
Send Report
Тепер система координує робочий процес, де кожен результат слугує вхідними даними для наступного кроку, тож помилка на ранній стадії може вплинути на всю процедуру, включаючи надсилання електронного листа.
Планування через розбирання завдань
„Створити веб-сайт для мого проєкту“ — це занадто велике завдання для одного кроку. Компетентний агент розділяє його на послідовні частини:
Goal
↓
Understand requirements
↓
Create project structure
↓
Build frontend
↓
Build backend
↓
Connect database
↓
Run application
↓
Test
↓
Fix errors
↓
Deploy
Це є розбивкою завдання: мета перетворюється на низку менших дій, кожну з яких можна виконати та перевірити.
Реагування на невдачу замість її повідомлення
Цикл виявляється корисним, коли щось ламається. Припустімо, агент виконує певний код:
Write code
↓
Run code
↓
ERROR
Чат-бот може лише повідомити про помилку. Агент може її прочитати, виправити код та спробувати знову:
Write code
↓
Run code
↓
ERROR
↓
Read error
↓
Identify problem
↓
Modify code
↓
Run again
↓
SUCCESS
У загальному вигляді це є циклом агента, де оцінка слугує основою для нового плану:
┌──────────────┐
│ PLAN │
└──────┬───────┘
↓
┌──────────────┐
│ ACT │
└──────┬───────┘
↓
┌──────────────┐
│ OBSERVE │
└──────┬───────┘
↓
┌──────────────┐
│ EVALUATE │
└──────┬───────┘
│
└──────→ PLAN AGAIN
Цикл, який може повторювати спроби, також може робити це без кінця, тому справжні системи обмежують кількість ітерацій.
Пам’ять та послідовність між кроками
Без пам’яті кожне завдання починається з нуля:
Task 1
↓
Forget
↓
Task 2
↓
Forget
За наявності переданого стану кожен крок ґрунтується на попередньому:
Task 1
↓
Save result
↓
Task 2
↓
Use previous result
↓
Task 3
Пам’ять існує у кількох сферах дії:
- Короткостроковий стан зберігає інформацію від поточного завдання.
- Довгострокова пам’ять зберігається протягом кількох взаємодій, де це підтримується системою.
- Зовнішня пам’ять знаходиться поза моделлю — у базах даних, документах, сховищах векторів чи файлах.
Агент може звертатися до проєктних документів та попередніх результатів перед виконанням поточного кроку:
Agent
↓
Memory
↓
Project documents
↓
Previous results
↓
Current task
Поєднання отримання інформації з виконанням дій
Метод генерації з підсиленням через отримання інформації (RAG) природно поєднується з агентами. Щоб відповісти на запитання за допомогою внутрішніх корпоративних документів, агент шукає їх, читає відповідні уривки та аналізує їх:
Question
↓
Search company documents
↓
Retrieve relevant information
↓
Read context
↓
Reason about it
↓
Answer
Якщо додати відповідні інструменти, агент також зможе діяти на знайдену інформацію:
AI AGENT
│
┌───────────┼───────────┐
↓ ↓ ↓
RAG Python APIs
↓ ↓ ↓
Documents Analysis Actions
Розподіл роботи між кількома агентами
Коли одного агента недостатньо, кілька спеціалізованих агентів можуть працювати під керуванням координатора:
MAIN AGENT
│
┌────────────┼────────────┐
↓ ↓ ↓
Research Agent Coding Agent Data Agent
│ │ │
Search Code Analysis
Агенти з досліджень, програмування та обробки даних кожен виконує свою функцію, тоді як головний агент координує роботу між ними. Це багатоагентна система.
Аналогія з командою та її обмеження
Ця структура нагадує програмну компанію з чітко визначеними ролями:
Manager
↓
Developer
↓
Tester
↓
Designer
↓
Deployment
Система ШІ може відтворити такий розподіл праці:
Coordinator Agent
↓
Research Agent
↓
Coding Agent
↓
Testing Agent
↓
Deployment Agent
Це порівняння є приблизним, але воно вказує напрямок: координація спеціалізованих моделей та інструментів замість покладання на одну модель. Кожен додатковий агент також збільшує витрати та затримки, тому спеціалізація має бути справжньою.
Як агенти роблять помилки
Автономність не означає надійності. Агент може:
- вибрати неправильний інструмент
- неправильно зрозуміти завдання
- створити несправний код
- отримати нерелевантні дані
Помилки посилюються на кожному наступному етапі:
User Goal
↓
Wrong interpretation
↓
Wrong tool
↓
Wrong result
↓
Wrong action
Чим більше свободи має агент, тим частіше потрібно перевіряти його роботу.
Вбудовування перевірки у цикл
Антипатерном є агент, який діє та просто припускає, що дія виконана успішно:
Act → Assume success
Кращим патерном є виконання явної перевірки перед подальшими діями:
Act
↓
Observe
↓
Verify
↓
Continue
Для коду перевіркою є тестове виконання з чітким розгалуженням залежно від результату:
Write Code
↓
Run Tests
↓
Tests Pass?
├── NO → Fix
└── YES → Continue
Для даних це перевірка коректності результату перед тим, як хтось буде на нього покладатися:
Database Query
↓
Check Result
↓
Is result reasonable?
├── NO → Investigate
└── YES → Continue
Перевірка замість припущень — це те, що насправді відрізняє адаптивного агента від простого скрипту. Краще використовувати детерміністичні перевірки, такі як тести чи верифікація схеми, замість того, щоб просити модель оцінювати себе саму.
Автономія — це регулятор, а не вимикач
Агентам не потрібна повна свобода. Уявіть собі шкалу, яка починається з системи, яка відповідає лише на запитання:
Level 1
AI only answers
Вищі рівні додають пропоновані дії, потім виклики інструментів, потім багатоетапне планування, а нарешті робочі процеси, які виконуються з обмежним наглядом:
Level 2
AI suggests actionsLevel 3
AI calls toolsLevel 4
AI plans multiple actionsLevel 5
AI executes workflows with limited supervision
Кожен крок вгору по шкалі підвищує вимоги до агента:
Permissions
Safety
Monitoring
Verification
Human oversight
Найнижчий рівень, який дозволяє вирішити проблему, зазвичай є найбезпечнішим вибором.
Визначення того, до чого може доторкнутися агент
Уявіть собі агента, підключеного до всього наступного:
Email
Banking
Files
Database
Cloud infrastructure
Production servers
Нерегульований доступ був би безрозсудним. Безпечніший підхід передбачає обробку дій через шар дозволів:
AI Agent
↓
Permission Layer
↓
Allowed Tools
↓
Action
Потім дозволи встановлюються для кожної окремої дії: читання файлу може бути дозволеним, тоді як видалення, надсилання електронних листів, розгортання чи доступ до бази даних залежать від контексту:
Read file ✓
Delete file ?
Send email ?
Deploy software ?
Access database ?
Принцип полягає у найменших привілеях.
Обмеження та людське схвалення
Продуктивні агенти також потребують суворих обмежень щодо способу своєї роботи:
Allowed tools
Maximum actions
Time limits
Budget limits
File permissions
Network permissions
Human approval
Для дій із високим впливом агент підготовлює їх та чекає на схвалення людини:
Agent
↓
Prepare Action
↓
Human Approval
↓
Execute
Це є підходом із участю людини. Питання обмежених циклів розглядається у нашій статті про обмежені агентські цикли в TypeScript.
Де застосовуються агенти
Такий же підхід використовується у багатьох галузях.
Розробка програмного забезпечення
Requirement
↓
Coding Agent
↓
Code
↓
Testing
↓
Bug Fixing
Аналіз даних
Dataset
↓
Data Agent
↓
Cleaning
↓
Analysis
↓
Visualization
↓
Report
Підтримка клієнтів
Зверніть увагу на крок «дозволені дії»: агенти підтримки працюють у межах вузького, заздалегідь схваленого набору операцій.
Customer Question
↓
Retrieve Account Information
↓
Understand Problem
↓
Take Permitted Action
↓
Respond
Дослідження
Research Question
↓
Search
↓
Read Papers
↓
Extract Information
↓
Compare Findings
↓
Generate Report
Особиста продуктивність
Goal
↓
Calendar
↓
Email
↓
Documents
↓
Tasks
↓
Summary
Інший тип інтерфейсу
Традиційне програмне забезпечення відображає зв’язок між елементом керування, функцією та результатом:
Button
↓
Function
↓
Result
Агент перетворює поставлену мету на план, виклики інструментів та дії:
Goal
↓
Planning
↓
Tools
↓
Actions
↓
Result
Замість того, щоб вивчати, які кнопки натискати, користувач описує бажаний результат. Це змінює спосіб взаємодії людини з комп’ютером та робить видимість дій агента вимогою до проектування.
Примітка щодо слова «мислення»
Коли ми кажемо, що агент „думає“, ми зазвичай маємо на увазі обчислювальні кроки: інтерпретацію вхідних даних, планування, вибір дій, оцінку результатів та оновлення стану. Це не свідчить про наявність свідомості. Точніше кажучи, агенти виконують ітеративні цикли міркувань та вибору дій для досягнення мети; термін „агент“ описує поведінку та архітектуру, а не досвід.
Повна картина в одному циклі
Усі елементи разом утворюють таку архітектуру: планування, виконання дій за допомогою інструменту, спостереження, перевірка, а потім продовження чи зупинка.
USER
│
▼
┌─────────┐
│ GOAL │
└────┬────┘
↓
┌─────────────┐
│ AI / LLM │
└──────┬──────┘
↓
PLAN
↓
SELECT ACTION
↓
┌─────────────┼─────────────┐
↓ ↓ ↓
Search Python SQL
↓ ↓ ↓
└─────────────┼─────────────┘
↓
RESULT
↓
OBSERVE
↓
VERIFY
↓
Continue or Finish
Цей цикл знаходиться в центрі більшості агентських систем.
Куди це приводить
Уявіть, що ви просите свій комп’ютер підготувати ваш тижневий звіт про дослідження, а агент керує всіма цими процесами:
Open research sources
↓
Collect information
↓
Read documents
↓
Analyze data
↓
Create charts
↓
Write report
↓
Check errors
↓
Prepare final document
Комп’ютер тоді координує додатки, а не просто їх розміщує. У довгостроковій перспективі процес виглядає так:
Rule-Based Software
↓
Machine Learning
↓
Chatbots
↓
LLMs
↓
Tool-Using LLMs
↓
AI Agents
↓
Multi-Agent Systems
Зміна стосується не лише більших моделей, а й моделей, які все частіше взаємодіють із зовнішніми системами.
Ключові висновки
Чат-бот може підказати, як аналізувати набір даних. Система, орієнтована на агентів, може знайти ці дані, завантажити їх, проаналізувати, створити графіки, виявити проблеми, скласти звіт, отримати схвалення та доставити його:
Find the dataset
↓
Load it
↓
Analyze it
↓
Create visualizations
↓
Detect problems
↓
Write a report
↓
Ask for approval
↓
Deliver the result
Прогрес відбувається через відповіді, планування, дії, спостереження та перевірку. Кілька порад щодо розробки будь-якого агента:
- Саме цикл, а не модель, робить систему агентом; обмежте його ітераціями, часовими та бюджетними рамками.
- Доручайте точні завдання, такі як арифметичні операції, запити та виконання коду, інструментам та чітко описуйте ці інструменти.
- Перевіряйте кожен наступний крок за допомогою контролів, які не залежать від оцінки самої моделі.
Агенти — це не стільки машини, які думають як люди, скільки системи, що перетворюють мету на конкретні дії. Ключове питання полягає не в тому, наскільки здатний модель, а в тому, що ви готові дозволити йому робити.
Пов’язана література
- Agentic AI Explained: From Language Models to Autonomous Agents — структурований огляд того, як LLM перетворюються на агентські системи за допомогою інструментів, пам’яті, планування, архітектур багатьох агентів та інтеграції MCP.
- Перевірка дій штучних інтелектуальних агентів: дозволи, бар’єри схвалення та рівні ризику — Дізнайтеся, чому агентам потрібен підхід до перевірки, та як принцип мінімальних прав, людське схвалення та автономія, заснована на оцінці ризиків, допомагають обмежувати їхні помилки.
- Статистичні водяні знаки тексту проти сертифікатів C2PA у результатах роботи Claude — Дізнайтеся, як функціонують водяні знаки тексту на основі SynthID у Claude та сертифікати файлів C2PA, що можуть підтвердити детектори, та як оцінювати інструменти, які стверджують, що можуть їх видалити.
- Створення AI-агентів на основі ваших існуючих .NET-сервісів та API — як команди, що працюють з C#, можуть перетворити існуючі сервіси та API на керовані інструменти агентів із правилами контексту, безпеки та спостережливості, які забезпечують їхню безпеку.
- Уроки з проекту Bun, де використовується AI для перенесення коду з Zig у Rust: верифікація — це справжня робота — що можна дізнатися з процесу перенесення коду з Zig у Rust за допомогою агентів Bun щодо тестових наборів як контрактів, посібників з портування, небезпечного коду та чому саме верифікація зараз обмежує можливості AI у програмуванні.