Введение в агентов

От предсказательного ИИ к автономным агентам

Искусственный интеллект меняется. На протяжении многих лет основное внимание уделялось моделям, которые отлично справляются с отдельными пассивными задачами — ответить на вопрос, перевести текст или создать изображение по заданному промпту. И этот процесс требует постоянного человеческого участия на каждом шаге.

Сегодня происходит смена парадигмы — от ИИ, который только предсказывает или генерирует контент, к новому классу программ, способных самостоятельно решать задачи и выполнять действия.

Эта новая область строится вокруг агентов ИИ.
Агент — это не просто модель в статическом конвейере, а полноценное приложение, которое умеет планировать и действовать для достижения целей.
Он объединяет способность языковой модели (LM) рассуждать с практической возможностью действовать, позволяя выполнять сложные многошаговые задачи без непрерывных подсказок человека.

Агенты — это естественная эволюция языковых моделей, которая делает их полезными в реальном ПО.

Введение в ИИ-агентов

В самом простом виде ИИ-агент — это комбинация четырёх элементов:

Модель («мозг») — языковая или фундаментальная модель, которая выполняет рассуждения и принятие решений. Тип модели (универсальная, дообученная, мультимодальная) определяет когнитивные возможности агента.
Инструменты («руки») — механизмы, связывающие мозг агента с внешним миром (АПИ, функции кода, базы данных, векторные хранилища). Они дают доступ к реальным данным и действиям.
Оркестрационный уровень («нервная система») — процесс, который управляет циклом работы агента (планирование, память, стратегия рассуждений). Использует техники вроде Chain-of-Thought или ReAct для разбиения целей на шаги и решения, когда думать, а когда действовать.
Развёртывание («тело и ноги») — помещает агента в рабочую среду на сервере, делает его доступным пользователям или другим агентам через API.

Разработка агентов — это новая форма программирования.
Обычный разработчик детально прописывает всю логику, а создатель агента скорее режиссёр: он ставит сцену (инструкции и промпты), выбирает актёров (инструменты и АПИ) и задаёт контекст (данные).

Главная задача — направлять автономного «исполнителя», чтобы тот достиг желаемого результата.

Агентный процесс решения задач

Агент работает в цикле «Думай – Действуй – Наблюдай».
Процесс состоит из пяти шагов:

Получить миссию. Агент получает цель (от пользователя или автоматического триггера).
Оценить сцену. Он собирает контекст: что уже известно, какие инструменты доступны, что говорит память.
Продумать план. Сопоставляет цель и контекст, строит цепочку рассуждений и решает, какие действия нужны.
Выполнить действие. Вызывает нужный инструмент или АПИ, выполняет код.
Наблюдать и повторять. Сохраняет результат, анализирует и переходит к следующему шагу.

Пример: пользователь спрашивает «Где мой заказ #12345?» Агент сначала планирует: найти заказ в БД → взять номер отслеживания → запросить статус доставки → ответить пользователю. Затем поочерёдно вызывает инструменты (find_order, get_shipping_status) и в конце генерирует итог «Ваш заказ в пути».

Таксономия агентных систем

Понимание пятишагового цикла — первый этап. Далее важно осознать, что сложность агентов можно масштабировать.

Уровень 0 – Базовая система рассуждений.
Это сама модель (например, LLM), работающая без инструментов и памяти. Она умеет объяснять понятия, но не знает о реальных событиях.

Уровень 1 – Подключённый решатель проблем.
Модель получает доступ к внешним источникам через инструменты (поиск, API, БД). Теперь она может отвечать на вопросы о текущих данных — например, узнать счёт последней игры «Янкиз».

Уровень 2 – Стратегический решатель проблем.
Агент умеет планировать многошаговые действия и сам составлять релевантный контекст («context engineering»).
Пример: «Найди кофейню на полпути между Mountain View и San Francisco». Он вычислит точку (Милбрэ), а затем подберёт кофейни с оценкой 4+.

Уровень 3 – Многоагентная система.
Вместо одного сверх-агента работает команда специализированных агентов (как в организации): менеджер → исследователь → копирайтер → разработчик. Агенты взаимодействуют через механизмы вроде A2A (Agent-to-Agent).

Уровень 4 – Саморазвивающаяся система.
Агент может создавать новые инструменты и агентов для расширения своих возможностей.
Пример: проектный агент понимает, что нужен мониторинг соцсетей, и сам создаёт SentimentAnalysisAgent, который встраивается в команду.

Архитектура агента: модель, инструменты и оркестрация

Мы уже знаем, что делает агент и как он масштабируется. Теперь — как именно его построить. Три основных компонента: Модель, Инструменты и Оркестрация.

1. Модель — «мозг» агента

Языковая модель (LM) — ядро рассуждений. Выбор модели определяет интеллект, стоимость и скорость агента.

Ошибка многих команд — выбирать модель по академическим метрикам, а не по практическим задачам.

Успех в продакшене зависит от:

способности рассуждать поэтапно,
надёжности в использовании инструментов,
устойчивости при работе с реальными данными.

Выбирайте модель, исходя из бизнес-целей, а не бенчмарков:

- если агент пишет код — тестируйте на вашем коде;

- если он анализирует страховые заявления — проверяйте на ваших документах.

Баланс между качеством, скоростью и ценой важнее самого «мощного» LLM.

Многие архитектуры используют «команду моделей»: например, Gemini 2.5 Pro решает сложные задачи, а Gemini 2.5 Flash быстро обрабатывает простые запросы (классификация, суммаризация). Это снижает расходы без потери качества.

2. Инструменты — «руки» агента

Инструменты соединяют рассуждения с реальностью. Они позволяют получать актуальные данные и выполнять действия.

Типы инструментов:

RAG (Retrieval-Augmented Generation) — доступ к актуальной информации (векторные базы, базы знаний, Google Search).
NL2SQL — перевод естественного языка в SQL-запросы для аналитики («Какие товары продавались лучше всего в прошлом квартале?»).
API-действия — отправка писем, планирование встреч, обновление CRM-записей.
Исполнение кода — генерация и запуск Python-скриптов, SQL-запросов в изолированной песочнице.
HITL (Human in the Loop) — инструменты для привлечения человека: подтверждение, ввод данных, уточнение решения.

3. Оркестрационный уровень — «нервная система» агента

Оркестрация соединяет мозг и руки, управляя циклом «думай → действуй → наблюдай».

Она решает, когда рассуждать, какой инструмент вызвать, и как интерпретировать результат.

Основные архитектурные решения:

Степень автономии.

Минимум: фиксированные сценарии с вкраплениями LLM.
Максимум: LLM сам планирует и действует, адаптируясь к целям.

Метод реализации.

No-code-платформы — быстрое создание простых агентов.
Code-first-фреймворки (например, ADK) — полная кастомизация, контроль и интеграции для инженеров.

Открытость и наблюдаемость. Фреймворк должен позволять подключать любые модели и инструменты, иметь жёсткие правила и логи. Трейсы и логи показывают: что модель «думала», какой инструмент вызвала, с какими параметрами и что получила.

Инструктаж и контекст

Инструктаж (persona + domain knowledge) задаёт характер и знания агента. Это его «конституция» — набор системных промптов с ролью, стилем, ограничениями и примерами.

Контекст и память обеспечивают индивидуальность и последовательность.

Краткосрочная память — история текущей сессии.
Долгосрочная память — векторная база или поиск по прошлым сессиям.
Агент может «вспоминать» предпочтения пользователя или итоги старых задач.

Многоагентные системы и шаблоны проектирования

Создание одного «супер-агента» неэффективно. Лучше строить команду специализированных агентов, каждый из которых решает свой тип подзадач.

Развёртывание и сервисы

После создания локального агента его нужно разместить на сервере, чтобы он работал постоянно и был доступен пользователям или другим агентам.

Ключевые задачи:

управление сессиями и памятью,
логирование, безопасность, соответствие регуляциям.

Варианты:

готовые платформы вроде Vertex AI Agent Engine — всё-в-одном;
контейнеризация (Docker) и деплой на Cloud Run или GKE для полного контроля.

Даже простые фреймворки позволяют командой deploy развернуть агента; но для продакшена нужны CI/CD, автотесты и политика безопасности.

Agent Ops — операционная дисциплина для непредсказуемых сценариев

Обычные тесты “assert output == expected” не работают для стохастических LLM-систем. Ответ может быть корректным в разной форме. Поэтому появляется новая практика — Agent Ops, наследник DevOps и MLOps.

Ключевые принципы:

Измеряйте то, что важно.
Определите метрики успеха как в A/B-тестах:

процент завершённых целей,
удовлетворённость пользователей,
время отклика,
стоимость на одно взаимодействие,
влияние на бизнес (доход, конверсии, удержание).

Качество вместо Pass/Fail.
Используйте «LLM-судью» — модель, которая оценивает ответы агента по рубрике: точность, фактологичность, следование инструкциям. Для этого создают «золотой датасет» типичных сценариев и эталонных ответов.
Разработка, управляемая метриками.
Автоматические оценки позволяют сравнивать версии агента. Новый релиз должен показать лучшие метрики по качеству, латентности и стоимости. Для безопасности используют A/B-развёртывания и постепенный rollout.
Отладка через трассировки (OpenTelemetry). Трейс показывает весь путь исполнения: промпт, внутренние рассуждения, вызов инструмента, параметры, результат. Это аналог «шага отладки» для агента и помогает находить корень ошибки.

Цените обратную связь от людей.
Жалобы и клики “thumbs down” — лучший источник данных.
Повторяющиеся проблемы превращайте в новые тест-кейсы, чтобы система не повторяла те же ошибки.

Взаимодействие агентов

Когда агенты становятся зрелыми, важно наладить их связи — с людьми, другими агентами и внешними системами.

Агент и человек

Самый распространённый интерфейс — чат.
Более продвинутые агенты возвращают структурированные данные (JSON) для интерфейсов.
Сценарии HITL включают уточнение намерений, подтверждения и запросы разъяснений.

Расширенные взаимодействия:

Computer Use. Агент сам управляет пользовательским интерфейсом (навигация, заполнение форм).
MCP UI / AG UI / A2UI. Инструменты для динамического управления UI или генерации интерфейсов под задачу.
Live Mode. Реальное общение голосом и видео — агент слышит, видит и говорит почти как человек (напр. Gemini Live API).

Агент и агент

По мере роста числа агентов без стандарта интеграция превращается в хаос.
Решение — Agent-to-Agent Protocol (A2A), открытый стандарт для взаимодействия агентов.

Каждый агент публикует Agent Card — JSON-файл с описанием возможностей, эндпоинта и прав доступа. Таким образом, агенты могут находить и вызывать друг друга без кастомных API.

A2A использует асинхронные «задачи» вместо простых запросов-ответов:
один агент отправляет задачу, другой даёт промежуточные обновления и результат. Так строятся кооперативные системы уровня 3.

Агент и деньги

По мере того как агенты совершают покупки и сделки, появляется вопрос доверия: кто несёт ответственность, если агент нажал «купить»?

Для этого формируются новые протоколы:

Agent Payments Protocol (AP2) — добавляет криптографические «мандаты» (доказательство согласия пользователя).
x402 — интернет-протокол микроплатежей (статус HTTP 402 Payment Required), позволяющий агентам платить за API или контент без аккаунтов и подписок.

Эти стандарты формируют основу агентской экономики — безопасного взаимодействия и транзакций между автономными системами.

Безопасность, масштабирование и управление агентами

Когда мы переходим от единичных агентов к системам корпоративного уровня, вопросы доверия, контроля и защиты данных становятся критическими.

Защита одного агента: баланс доверия

Каждый агент, по сути, обладает властью действовать от имени пользователя или организации. Значит, у него есть доступ, а доступ требует ограничений.

Доверие к агенту можно рассматривать как компромисс между удобством и безопасностью: чем больше возможностей имеет агент, тем выше риск злоупотреблений. Нужно уметь точно задавать границы разрешённых действий — например, «может читать Google Docs, но не удалять».

Основные уровни защиты:

Изоляция среды исполнения. Агент работает в песочнице (sandbox), где ограничены сетевые вызовы и файловые операции.
Явные разрешения. Перед использованием API агент запрашивает одобрение или использует токены с конкретными правами.
Аудит. Все действия записываются для проверки и отката.

Идентичность агента — новый класс субъектов

Если раньше “идентичность” имели пользователи и сервисы, то теперь её получают и агенты.
Каждому агенту присваивается уникальный идентификатор и криптографический ключ, по которым можно отследить, кто и что сделал.

Таким образом, агент становится юридическим субъектом в цифровой среде:
у него есть права доступа, история действий и даже «репутация».
Со временем такие идентичности могут участвовать в финансовых и контрактных отношениях — например, агент подписывает сделку от имени компании.

Политики доступа и ограничения

Чтобы избежать “сползания полномочий”, нужны чёткие правила.
MCP (Model Context Protocol) и ADK (Agent Development Kit) уже включают возможности ограничения доступа:

разрешённые API и файловые пути,
белые и чёрные списки инструментов,
лимиты на размер контекста и длительность сессии.

Для особо чувствительных данных вводят “человеческий барьер”: агент должен запросить подтверждение оператора перед выполнением критичных действий (например, перед списанием денег).

Безопасность ADK-агентов

Anthropic подчёркивает важность безопасной инфраструктуры. Любой агент, работающий с кодом, должен исполняться в изолированной песочнице, как это реализовано в Claude Code Sandbox:

ограниченное время выполнения,
доступ только к нужным библиотекам,
чёткое разделение памяти,
аудит всех вызовов.

Такое окружение предотвращает утечки данных и блокирует возможность запуска произвольного кода.

Масштабирование: от одного агента к целому флоту

Когда компания создаёт десятки агентов — для маркетинга, аналитики, поддержки, продаж, R&D — их нужно координировать. Возникает понятие Agent Fleet (флот агентов).

Чтобы управлять таким флотом, нужна система вроде Agent Control Plane — единая панель, где можно:

централизованно обновлять навыки,
управлять политиками безопасности,
собирать логи и метрики,
ставить квоты и приоритеты,
включать или выключать агентов.

Такой подход аналогичен Kubernetes для микросервисов — только здесь вместо контейнеров живут агенты.

Безопасность и приватность: укрепление «агентного фронтира»

По мере расширения прав агентов важно исключить утечку данных через контекст.
LLM может «запомнить» конфиденциальные данные и непреднамеренно раскрыть их при следующем вызове.

Методы защиты:

Контроль контекста.
MCP-клиент автоматически заменяет личные данные токенами (PII Tokenization) — имена, почты, телефоны не попадают в модель.
Data Provenance.
Каждый фрагмент данных имеет источник и уровень доверия. Агент знает, что цитирует надёжную базу, а не случайный сайт.
Шифрование и изоляция.
Передача данных между агентами проходит по зашифрованным каналам с авторизацией по токену агента.

Управление агентами: контроль вместо хаоса

Когда агентов становится много, нельзя позволить им работать без надзора.
Возникает Agent Governance Layer — “плоскость управления”.

Он включает:

регистрацию и аттестацию агентов (какие существуют, кем созданы, что умеют);
политику ответственности (кто отвечает за ошибку или вредное действие);
журналирование (какие решения и на каком основании были приняты).

Этот слой превращает хаотичный набор агентов в управляемую экосистему.

Как агенты учатся и эволюционируют

Современные агенты уже могут самообучаться на основе опыта.
Это не “дообучение модели” в классическом ML-смысле, а обучение на уровне поведения.

Примеры подходов:

Reflexive memory: агент анализирует свои ошибки и добавляет правила в память («в следующий раз не пиши SQL без LIMIT»).
Auto-tuning: корректирует свои системные промпты для повышения эффективности.
Skill accumulation: сохраняет полезные функции и сценарии в виде кода или SKILL.md-файлов — формируя библиотеку навыков.

Эта эволюция делает агентов более точными и адаптивными с каждым циклом.

Симуляции и “Agent Gym” — следующая граница

Чтобы агенты могли учиться безопасно, их помещают в симулированные среды — аналоги «тренажёров».
Там они взаимодействуют с виртуальным миром, экспериментируют, совершают ошибки — без риска для реальных систем.

Это называют Agent Gym — как OpenAI Gym для RL.
Здесь агенты тестируют гипотезы, учатся коммуникации и координации.

Например, команда маркетинговых агентов может «разыграть» кампанию и оценить, какие стратегии дадут лучший результат, прежде чем применить их в реальности.

Примеры продвинутых агентов

Google Co-Scientist

Исследовательская система, созданная для помощи в научных открытиях.
Co-Scientist умеет читать статьи, анализировать результаты экспериментов, формулировать гипотезы и предлагать новые эксперименты.
Он работает в связке с базами данных PubMed и ArXiv и может вызывать лабораторные симуляции.

Главная идея: автоматизация научного метода — от постановки вопроса до проверки результата.
Co-Scientist уже показал способность находить нетривиальные корреляции, которые ускользали от людей.

AlphaEvolve Agent

Эта система исследует направление самоэволюции агентов.
AlphaEvolve может создавать, оценивать и улучшать других агентов.
Он действует как «мета-агент» — среда, где новые агенты рождаются, тестируются и отбираются.

По сути, это естественный отбор в цифровой среде:
успешные агенты сохраняются и реплицируются, неэффективные — отбраковываются.
Такое «агентное дарвиновское» развитие может ускорить инновации, создавая поколения всё более приспособленных систем.

Заключение

Агенты — это не просто надстройка над LLM, а новая парадигма программного обеспечения.
Они объединяют рассуждение, действие, память и взаимодействие, превращая модели из пассивных предсказателей в активных участников процессов.

Мы стоим на пороге эры, где:

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

Как когда-то микросервисы заменили монолиты, агенты заменят традиционные приложения — более гибкие, адаптивные и умные.

Оригинал: https://drive.google.com/file/d/1C-HvqgxM7dj4G2kCQLnuMXi1fTpXRdpx/view