«Агент» — это кто?

6 августа 2026 · 15 минут чтения

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

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

Кто-то говорит: «Я создал агента-архитектора». На деле он написал системный prompt — инструкцию, задающую модели роль и правила.

Кто-то говорит: «Наш агент умеет работать с GitHub». На деле приложение разрешает модели вызвать один заранее выбранный API-метод.

Ещё один запускает пять параллельных копий Claude Code без общей задачи и координации и называет это мультиагентной системой.

А кто-то подключает MCP-сервер и считает, что добавил ещё одного агента.

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

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

Короткий ответ

В этой статье я предлагаю различать как минимум семь распространённых употреблений слова «агент»:

1. абстрактного субъекта, который воспринимает среду и действует в ней;
2. систему на основе большой языковой модели (LLM), самостоятельно управляющую циклом работы;
3. конфигурацию модели с инструкциями и инструментами в программном фреймворке;
4. готовый продукт или среду исполнения вроде coding-агента;
5. отдельный запуск, сессию или исполнителя подзадачи;
6. роль или персону, заданную промптом;
7. участника организационной схемы, изображающего специалиста или отдел.

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

Например, разработчик говорит: «У нас есть агент, он подключён к CRM». Слушатель домысливает:

«У нас есть агент, он подключён к CRM»
        ↓ слушатель домысливает
«Значит, программа сама ведёт клиентов и отвечает им»

На деле программа умеет одно: по команде человека найти карточку клиента. Слово «агент» в названии ничего не доказывает про самостоятельность работающей системы. Точно так же промпт «ты senior-разработчик» не создаёт нового независимого исполнителя.

Откуда вообще взялся агент

В обычном смысле агент — тот, кто действует от чьего-то имени: представитель, посредник или исполнитель поручения. В центре этого значения не интеллект, а отношение:

принципал → поручает → агент → действует в среде

Два примера, далёких друг от друга, устроены одинаково.

Агент как шпион. Разведка — принципал: она ставит задачу, задаёт границы и даёт канал связи. Шпион — агент: он действует в чужой стране, то есть в среде, сам решает, с кем говорить и когда рисковать, и докладывает результат. Каждый шаг ему никто не диктует.

Агент как Codex, установленный на вашем компьютере. Вы — принципал: даёте задачу «почини падающий тест». Codex — агент: он действует в вашем репозитории и терминале, то есть в среде, читает файлы, правит код, запускает тесты, смотрит на результат и повторяет, пока тест не пройдёт. Вы задали цель и границы, шаги выбирает он.

В классическом искусственном интеллекте понятие стало техническим. В статье 1995 года Майкл Вулдридж и Николас Дженнингс описывали интеллектуального агента через четыре свойства: автономность, реактивность, проактивность и социальную способность. Агент контролирует хотя бы часть своих действий, реагирует на изменения среды, проявляет инициативу ради цели и способен взаимодействовать с другими участниками. Wooldridge & Jennings, Intelligent Agents: Theory and Practice

Базовая схема выглядела примерно так:

              наблюдение
среда ───────────────────────────▶ агент
  ▲                                  │
  │                                  │  выбор действия
  └──────────────────────────────────┘
               действие

В этой схеме у любого агента есть пять частей. На тех же двух примерах:

• Граница — что считается самим агентом, а что уже нет. У шпиона граница — он сам и его легенда. У Codex — программа на вашем компьютере; репозиторий, терминал и интернет уже снаружи.
• Среда — всё за границей, с чем агент взаимодействует. Для шпиона — чужая страна и люди в ней. Для Codex — файлы, тесты, командная строка, GitHub.
• Наблюдения — что агент получает из среды. Донесения и слухи. Вывод команды, текст ошибки, результат тестов.
• Внутреннее состояние или политика выбора — по каким правилам агент решает, что делать дальше. У термостата это одно правило: холодно — включить. У шпиона — опыт и инструкции. У Codex — языковая модель и накопленный контекст задачи.
• Действия — чем агент может изменить среду. Передать сведения, завербовать человека. Изменить файл, запустить тест, открыть pull request.

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

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

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

Потому что «агент» одновременно стал научным понятием, архитектурным паттерном, названием программной абстракции и маркетинговой категорией.

Даже в документации одного поставщика граница может проходить в разных местах.

В практическом руководстве OpenAI граница проведена так: агент — это система, которая с высокой степенью самостоятельности выполняет задачу от имени пользователя, управляет ходом работы и динамически выбирает инструменты. Простой чат-бот или одиночный вызов модели агентом там не считается. OpenAI, A practical guide to building agents

Но в документации OpenAI Agents SDK, библиотеки для сборки агентов, слово используется шире: Agent — это LLM, сконфигурированная инструкциями, инструментами, проверками (guardrails), передачей управления другому агенту (handoffs) и форматом выхода. Цикл выполнения при этом находится в отдельном объекте Runner, исполнителе. OpenAI Agents SDK, Agents

Anthropic проводит ещё одну границу:

• workflow — рабочий процесс, путь которого заранее определён кодом;
• agent — модель сама динамически определяет процесс и использование инструментов.

При этом оба варианта Anthropic относит к более широкой категории agentic systems. Anthropic, Building effective agents

Здесь нет логического противоречия. Документ о продуктовой архитектуре отвечает на вопрос «какая система ведёт задачу?», а документация SDK — «как называется объект в API?». Ошибка возникает у нас, если мы не уточняем уровень.

Семь значений слова «агент»

1. Агент как абстрактный субъект действия

Это самое широкое и старое техническое значение.

Агент:

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

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

Это значение нужно для теории и архитектуры верхнего уровня. Оно заставляет спросить: где граница субъекта, что считается средой, какие действия ему доступны и кто задаёт цель?

Но оно слишком широкое для продуктового разговора. При желании агентом можно назвать почти любую реагирующую программу. Поэтому фраза «у нас есть агент» ещё ничего не говорит о её интеллекте, универсальности или самостоятельности.

2. Агент как автономный LLM-цикл

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

цель
  ↓
модель решает, что делать дальше
  ↓
вызывает инструмент или отвечает
  ↓
наблюдает результат
  ↓
обновляет план и выбирает следующий шаг
  ↺ до результата, лимита или передачи человеку

Ключевое здесь не наличие промпта и даже не наличие инструментов. Ключевое — кто управляет следующим шагом.

Если порядок действий жёстко записан в коде, перед нами workflow с LLM-компонентами. Если модель после каждого наблюдения решает, что делать дальше, возникает агентный цикл.

В исследовании ReAct авторы предложили чередовать рассуждение и действия, используя результаты действий для обновления плана и следующего шага. Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models

В статье 2025 года о context engineering Anthropic даёт короткую формулу: LLM автономно использует инструменты в цикле. Anthropic, Effective context engineering for AI agents

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

3. Агент как класс в библиотеке для сборки агентов

Агентные приложения редко пишут с нуля. Их собирают на готовой библиотеке, фреймворке: OpenAI Agents SDK, Microsoft AutoGen, LangGraph, Google ADK. В каждой из них есть класс с именем Agent, и его экземпляры разработчики называют агентами. Обычно такой объект — конфигурация, связывающая часть следующих элементов:

Agent = model            языковая модель, которая генерирует ответы
      + instructions     системные инструкции: роль, правила, формат речи
      + tools            инструменты, которые модель может вызывать
      + context/memory   контекст и память: что модель знает о задаче
      + output schema    схема выхода: в каком виде отдать результат
      + handoff rules    правила передачи управления другому агенту
      + guardrails       ограждения: проверки входа и выхода модели

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

Но это термин конкретного API. Один вызов такого объекта без инструментов и без цикла может технически быть Agent, хотя на уровне поведения это обычная генерация ответа.

Разные библиотеки помещают границу по-разному. В OpenAI Agents SDK Agent — конфигурация модели, а цикл исполняет отдельный объект, runner. В AutoGen Core агент — адресуемая сущность, принимающая сообщения, а runtime — среда исполнения — управляет её жизненным циклом и доставкой. Microsoft AutoGen, Agent and Agent Runtime

Поэтому предложение «мы создали три агента» без названия библиотеки и описания среды исполнения почти бессодержательно. Возможно, созданы три независимых исполнителя. Возможно — три объекта с разными system prompts внутри одного последовательного скрипта.

4. Агент как продукт или agent harness

Codex, Claude Code и похожие системы называют coding-агентами. Здесь агентом называют среду исполнения целиком. Она может объединять:

• модель;
• системные инструкции;
• цикл вызовов;
• управление контекстом — доступной модели информацией;
• инструменты для файлов, shell, Git и браузера;
• разрешения и изолированную среду (sandbox);
• обработку ошибок;
• сохранение состояния;
• интерфейс взаимодействия с человеком;
• трассировку и ограничения.

Anthropic называет такую обвязку agent harness, буквально «упряжь» для модели, или scaffold, «строительные леса». Это программа вокруг модели: она держит цикл, показывает модели доступные инструменты, исполняет её вызовы и возвращает ей результаты. Без harness модель умеет только выдавать текст. Поэтому при оценке «агента» фактически оценивается связка модели и harness, а не модель сама по себе. Anthropic, Demystifying evals for AI agents

Фраза «модель умеет редактировать репозиторий» обычно неточна. Модель умеет генерировать решение о вызове инструмента. Репозиторий читает и изменяет окружающая программа.

5. Агент как запущенный экземпляр, сессия или worker (исполнитель)

В повседневной работе мы говорим: «запусти ещё одного агента», «агент сейчас исследует API», «два агента работают параллельно».

Здесь речь о конкретном экземпляре выполнения:

• отдельный процесс;
• отдельная сессия;
• отдельная ветка контекста;
• worker, получивший подзадачу;
• иногда отдельный контейнер или рабочая среда.

Это похоже на различие между классом и объектом:

конфигурация агента  →  запуск 1
                     →  запуск 2
                     →  запуск 3

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

Стоит различать:

• agent definition — чем исполнитель сконфигурирован;
• agent runtime — что исполняет цикл;
• run/session — конкретная попытка выполнить задачу;
• trajectory/trace — записанная последовательность решений и действий;
• outcome — фактическое состояние среды после выполнения.

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

6. Агент как роль, персона или набор инструкций

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

роль = какой взгляд и правила применить
агентный цикл = кто выбирает и выполняет следующие действия

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

Роль имеет смысл, когда она меняет проверяемое поведение: доступные инструменты, критерии оценки, контекст, права или формат выхода. Если меняется только имя и биография — это чаще театральная декорация.

Подробнее эта ловушка разобрана в соседнем материале: «Не нанимайте AI-агентов на человеческие должности».

7. Агент как цифровой сотрудник или участник организации

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

Человеческая должность неявно включает пять вещей, которых у программного агента может не быть:

1. Память. Помнит ли система прошлую сессию или каждый запуск начинается заново?
2. Полномочия. Может ли она только предложить изменение или реально выполнить его?
3. Ответственность. Кто отвечает за ошибочный платёж, удаление данных или плохой merge?
4. Компетенцию. Роль «юрист» не превращает модель в лицензированного и ответственного специалиста.
5. Время. Может ли система возобновить работу завтра или существует только до закрытия процесса?

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

Система классифицирует обращение, ищет сведения в базе знаний, предлагает ответ, а возвраты свыше заданной суммы передаёт человеку.

Так сразу видны границы задачи, полномочия и контроль. Чем серьёзнее последствия, тем меньше пользы от образа цифрового сотрудника и тем больше — от такого описания.

Главные путаницы

Агент и чат-бот

Чат — это интерфейс, а агентность — способ управления действиями. Они находятся на разных осях.

• чат-бот может просто отвечать текстом и не быть агентом;
• агент может общаться через чат;
• агент может работать в фоне вообще без диалога;
• чат может быть лишь панелью управления детерминированным workflow.

Агент и copilot

В рамках этой статьи copilot, «второго пилота», удобно описывать как режим отношений с человеком: система предлагает, человек ведёт процесс и подтверждает действия.

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

Но это продуктовые названия, а не строгие классы: один продукт может переключаться между режимами, поэтому вопрос о делегированных решениях точнее вопроса «copilot или agent?».

Агент и инструмент

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

инструмент: «создать issue с такими полями»
агент: «нужно ли создавать issue, какие поля заполнить и что делать после ответа API»

Но граница рекурсивна: за инструментом может скрываться другой агент. OpenAI Agents SDK прямо поддерживает паттерн agents as tools: управляющий агент вызывает специализированного агента как функцию и затем продолжает держать контроль. При handoff, напротив, управление разговором переходит другому агенту. OpenAI Agents SDK, Agent orchestration

Следовательно, «инструмент» — это роль компонента относительно вызывающей стороны, а не описание его внутреннего устройства.

MCP-сервер и агент

MCP (Model Context Protocol) — протокол, по которому приложение с моделью подключает внешние инструменты и данные. MCP-сервер обычно не агент. Это программа, которая по этому протоколу предоставляет приложению-хосту, то есть тому, где работает модель, инструменты, ресурсы и prompts. Сам MCP не определяет, как приложение использует LLM и управляет контекстом. Model Context Protocol, Architecture overview

агентное приложение / MCP host
          │
          ├─ MCP client ─ MCP server GitHub
          ├─ MCP client ─ MCP server database
          └─ MCP client ─ MCP server calendar

MCP-сервер может внутри себя запускать модель или даже отдельного агента, но из самого факта подключения MCP это не следует. Для взаимодействия независимых удалённых агентов существует другая категория протоколов, например A2A (Agent-to-Agent). В нём удалённый агент публикует визитную карточку Agent Card с описанием возможностей, а задача может иметь собственный жизненный цикл. A2A Protocol, Core concepts

Multi-agent и несколько голосов одной модели

В рамках этой статьи будем называть multi-agent system, многоагентной системой, систему, в которой есть несколько адресуемых исполнителей и механизм координации. Под это рабочее определение попадают разные механизмы:

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

Последний вариант разумнее называть ensemble или parallel sampling, ансамблем или параллельной выборкой ответов: несколько ответов одной модели ещё не образуют команду.

Anthropic, например, отдельно описывает схему orchestrator-workers, «дирижёр и исполнители», как workflow: центральная LLM динамически формирует подзадачи, модели-исполнители выполняют их, а дирижёр собирает результат. Топология похожа на multi-agent, но архитектурная классификация зависит от того, какие участники имеют собственный цикл и контроль. Anthropic, Building effective agents

Агентный, разумный и надёжный

Это три разные характеристики, которые не следует подменять друг другом.

• агентность говорит о способе выбора и выполнения действий;
• интеллект — о качестве решений;
• надёжность — о вероятности корректного результата в заданных условиях.

Очень агентная система может быть глупой и ненадёжной. Детерминированный workflow может быть гораздо полезнее и безопаснее. Поэтому слово agentic не является знаком качества.

Практическое правило проектирования

Собирая всё вместе, я предлагаю считать агентом в прикладном инженерном разговоре второе значение, записанное как контракт:

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

Три слова здесь несут основную нагрузку. «Система» отделяет агента от модели: действует связка модели и harness. «Существенную часть» допускает гибридные схемы, где часть шагов выбирает код или человек. «Выполняет» отделяет агента от советчика. Это рабочий контракт для проектирования, а не стандарт.

Насколько существенную часть решений отдали системе, удобно описывать шкалой делегирования. Шкала рабочая и неофициальная:

Уровни 0 и 1 — ещё workflow с LLM-компонентом: следующий шаг выбирает код. Под определение выше система попадает с уровня 2, когда выбор переходит к модели. Высший уровень не всегда лучше: с ростом свободы выбора нужно заново оценить риски и усилить наблюдаемость, проверки и ограничения, а перед действиями с серьёзными последствиями поставить human gate — обязательное решение человека.

Главный вывод

Слово «агент» имеет смысл только вместе с указанием уровня и границ. Один продукт может сочетать модель, объекты SDK, агентный цикл, harness, несколько запусков и роли, и спор начинается, когда собеседники называют агентом разные его части.

Поэтому вместо «это настоящий агент?» стоит задать три вопроса: что именно здесь названо агентом, кто управляет следующим шагом и какие решения и действия ему реально делегированы.

Основные источники

• Michael Wooldridge, Nicholas R. Jennings — Intelligent Agents: Theory and Practice
• Shunyu Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models
• Anthropic — Building effective agents
• Anthropic — Effective context engineering for AI agents
• Anthropic — Demystifying evals for AI agents
• OpenAI — A practical guide to building agents
• OpenAI Agents SDK — Agents
• OpenAI Agents SDK — Agent orchestration
• Microsoft AutoGen — Agent and Agent Runtime
• Model Context Protocol — Architecture overview
• A2A Protocol — Core concepts

Автор: Данил Письменный · Дата: 6 августа 2026