От цели к контролируемым действиям: циклы, проверка и разрешения в ИИ-агентах
Узнайте, как ИИ-агенты преобразуют цель в вызовы инструментов с помощью цикла планирование-действие-наблюдение, и почему проверка, уровни автономии и слои разрешений определяют их безопасность.
Большинство людей впервые столкнулись с языковыми моделями как с устройствами для ответов на вопросы: вводим запрос, получаем ответ — и всё. Системы агентов нарушают эту схему. Получив цель, они планируют действия, вызывают инструменты, проверяют результаты и продолжают работу до завершения задачи. В этом обзоре рассматриваются циклы действий, инструменты, память и многопроцессные конфигурации агентов, после чего акцентируется внимание на самом важном в практическом применении: проверке работы агента и ограничении его полномочий.
Ответы против действий ради достижения цели
Классический чат-бот выполняет действие один раз: вводится вопрос, модель генерирует ответ, и больше ничего не происходит.
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
Эволюция происходит от ответов к планированию, действиям, наблюдению и проверке. Несколько моментов, которые следует учитывать при создании любого агента:
- Именно цикл, а не модель, делает систему агентом; необходимо ограничить его количеством итераций, временем и бюджетом.
- Поручайте точные задачи, такие как арифметические вычисления, запросы и выполнение кода, инструментам, четко описав эти инструменты.
- Проверяйте каждый следующий шаг с помощью критериев, которые не зависят от самой оценки модели.
Агенты — это не столько машины, мыслящие как люди, сколько системы, преобразующие цели в конкретные действия. Ключевой вопрос заключается не в том, насколько способен модель, а в том, что вы готовы ему разрешить делать.
Связанные материалы
- Объяснение агентных ИИ: от языковых моделей к автономным агентам — структурированный обзор того, как большие языковые модели превращаются в агентные системы с помощью инструментов, памяти, планирования, архитектур многих агентов и интеграции MCP.
- Проверка действий ИИ-агентов: разрешения, системы утверждения и уровни риска — Узнайте, почему агентам необходим подход проверки, и как принцип минимальных прав, утверждение человеком и автономия на основе оценки рисков помогают сдерживать их ошибки.
- Статистические водяные знаки текста против учетных данных C2PA в выводах Claude — Узнайте, как функционируют водяные знаки текста на основе SynthID и учетные данные файлов C2PA в Claude, что могут подтвердить детекторы и как оценить инструменты, заявляющие об их удалении.
- Создание ИИ-агентов на основе существующих .NET-сервисов и API — Как команды, использующие C#, могут превратить существующие сервисы и API в управляемые инструменты для агентов с правилами контекста, безопасности и наблюдаемости, обеспечивающими их безопасность.
- Уроки переноса с Zig на Rust с использованием ИИ в Bun: проверка — это самая важная часть работы — Чему учит переход с Zig на Rust при помощи агентов в Bun относительно тестовых наборов как контрактов, руководств по портированию, небезопасного кода и почему сейчас проверка ограничивает использование ИИ в программировании.