В 2025 году AI агенты перестали быть сюжетом для конференций и перешли в инженерную практику. OpenAI выпустила Responses API и Agents SDK, LangGraph закрепил графовый подход, Anthropic опубликовала паттерны разделения workflows и agents. Но главное изменение не в том, что модели стали «умнее». Главное — команды начали проектировать агентные системы как управляемые контуры: с ограниченным набором инструментов, явным состоянием, трассировкой и точкой остановки.
Для практиков это означает смену вопроса. Вместо «какая модель лучше» нужно спросить: где агент действительно сокращает ручной труд, где его заменяет обычный скрипт, и где опасно давать доступ к почте, платежам, репозиторию или CRM без промежуточного контроля.
Что изменилось в инфраструктуре агентов
Термин «агент» остаётся размытым. В одном проекте им называют чат-бота с поиском, в другом — цепочку промптов, в третьем — систему, которая сама выбирает инструменты и планирует шаги. Для рабочих задач полезно такое определение: агент — это модель, которая получает цель, вызывает внешние инструменты, хранит или получает состояние и принимает промежуточные решения до завершения задачи.
Именно здесь произошли инфраструктурные сдвиги.
OpenAI в марте 2025 года представила Responses API и Agents SDK. Responses API — это не просто endpoint для генерации текста. Это интерфейс, в котором ответы модели, вызовы инструментов и состояние диалога объединены в единый цикл. Документация Responses API показывает, что разработчик получает структуру, где каждый tool call логируется, а модель может повторять шаги на основе результатов.
Agents SDK — это слой оркестрации. В репозитории на GitHub выделены четыре ключевых понятия: agents (агент с инструкцией и инструментами), handoffs (передача задачи другому агенту), guardrails (защитные проверки на входе и выходе) и tracing (журнал всех действий). Даже если команда не использует этот SDK напрямую, сама терминология полезна: агенту нужны границы, маршруты передачи, защитные условия и полный журнал.
LangGraph предлагает другой угол. Вместо линейных цепочек — граф состояний, где узлы отвечают за шаги, инструменты и проверки. Это ближе к инженерной реальности, чем образ «одного всемогущего ассистента». Для задач вроде анализа тикетов, подготовки изменений кода, обработки входящих писем или RAG-поиска важно не только «ответить», но и помнить, какой шаг уже сделан, что было проверено, какой источник использован и где нужен человек.
Что говорят источники: три ключевых материала
Практические рекомендации от разработчиков крупных моделей сходятся в одном: надёжные агентные системы строятся не вокруг максимальной автономности, а вокруг ограниченного контура действий.
Anthropic: Building effective agents. В этом материале авторы разделяют workflows и agents. Workflows — это заранее заданные маршруты, где модель выполняет отдельные шаги. Agents — более гибкие системы, где модель сама планирует и выбирает действия. Практический вывод: начинать стоит с workflow, а не с полностью свободного агента. Чем выше цена ошибки, тем жёстче должен быть маршрут. Anthropic рекомендует использовать агентов только там, где задачи требуют гибкости, а цена ошибки низкая.
OpenAI: New tools for building agents. В официальном анонсе OpenAI описывает Responses API, Agents SDK и новый интерфейс для компьютерного управления. Ключевая фраза: «агенты — это строительные блоки, а не готовое решение». Компания подчёркивает, что трассировка и guardrails — обязательные компоненты, а не опциональные украшения.
LangGraph: State graphs for agent applications. Документация LangGraph показывает, как описывать агентные приложения как графы с состояниями, узлами и рёбрами. Это даёт возможность явно задавать маршруты, проверять промежуточные результаты и возвращать управление человеку.
| Компонент | Практический смысл | Где смотреть |
|---|---|---|
| Responses API | Единый цикл ответа модели и вызова инструментов | https://platform.openai.com/docs/api-reference/responses |
| Agents SDK | Оркестрация агентов, handoffs, guardrails, tracing | https://github.com/openai/openai-agents-python |
| LangGraph | Графы состояний для агентных приложений | https://langchain-ai.github.io/langgraph/ |
| Инженерные паттерны | Разделение workflows и agents, осторожность с автономностью | https://www.anthropic.com/engineering/building-effective-agents |
Как спроектировать рабочий контур: пять шагов
Хороший агентный проект начинается не с выбора модели, а с описания повторяемой задачи. Например: «разобрать входящий запрос клиента, найти релевантные документы, предложить ответ, отметить уровень уверенности и передать человеку». Это агентная задача, потому что в ней есть поиск, промежуточные решения и внешний контекст. Но финальная отправка ответа остаётся за человеком.
Минимальный рабочий контур строится из пяти шагов.
Первый шаг: описать вход и выход. Не «помогать саппорту», а «классифицировать тикет, найти три релевантных фрагмента документации, подготовить черновик ответа». Чёткие границы снижают риск бесконечных циклов.
Второй шаг: ограничить инструменты. Если нужен только поиск по базе знаний, агенту не нужен доступ к CRM на запись. Каждый лишний инструмент — это дополнительная поверхность для ошибок.
Третий шаг: ввести состояние. Сохранять использованные источники, выбранную категорию, промежуточные решения и причину остановки. Без состояния агент не может объяснить, почему он сделал тот или иной шаг.
Четвёртый шаг: добавить проверки. Например, запрет ответа без ссылок на внутреннюю документацию или требование человеческого подтверждения при низкой уверенности. Guardrails должны быть на входе (проверка запроса) и на выходе (проверка ответа).
Пятый шаг: включить трассировку. Без журнала tool calls и промежуточных решений невозможно разбирать ошибки и улучшать промпты. Трассировка — это не опция, а основа для итеративного улучшения.
Такой подход особенно полезен для команд, которые уже используют LLM в ручном режиме: копируют тикеты в чат, просят написать SQL, резюмируют документы, готовят черновики писем. Агентный слой не должен сразу заменять процесс. Он должен сначала убрать повторяемые переходы между системами.
Ограничения и контраргументы
Главный риск агентного подхода — иллюзия надёжности. Если модель уверенно вызывает инструменты и пишет связный текст, это ещё не значит, что она правильно поняла цель, выбрала верный источник или остановилась вовремя. В тестах LangGraph и Agents SDK разработчики фиксируют случаи, когда модель вызывала один и тот же инструмент три раза подряд без изменения результата.
Есть и экономический аргумент. Агентные циклы могут быть дороже обычного запроса: модель планирует, вызывает инструменты, читает результаты, делает повторные шаги. Без лимитов на количество итераций и без оценки ценности автоматизации команда может получить красивый, но невыгодный процесс. OpenAI в документации Agents SDK рекомендует устанавливать явные лимиты на количество шагов и общую стоимость.
Вторая проблема — безопасность действий. Чтение документации и подготовка черновика обычно терпимы к ошибкам. Запись в базу, отправка писем, изменение кода, деплой или финансовые операции требуют другого уровня контроля. Здесь guardrails — не украшение, а обязательная часть архитектуры. Anthropic в своём материале подчёркивает: если цена ошибки высока, используйте workflow, а не агента.
Третья проблема — тестирование. Для обычного API можно написать набор ожидаемых ответов. Для агента нужно проверять маршрут: какие инструменты он вызвал, какие данные прочитал, где остановился, не сделал ли лишний шаг. Поэтому трассировка и воспроизводимые сценарии важнее, чем единичные удачные демо. LangGraph предоставляет встроенные средства для тестирования графов, но это требует дополнительных усилий от команды.
Что проверить перед прототипом
Если вы оцениваете AI агенты для продукта или внутренней автоматизации, начните с небольшого сценария, где цена ошибки ограничена, а польза легко измеряется. Подойдут классификация обращений, сбор контекста по документам, подготовка черновиков, ревью простых изменений или обновление задач в трекере через подтверждение.
Полезный чек-лист перед прототипом:
- есть ли понятный критерий завершения задачи;
- можно ли ограничить инструменты только чтением на первом этапе;
- сохраняются ли источники и промежуточные действия;
- есть ли лимит итераций и расходов;
- предусмотрен ли человек на шаге с высокой ценой ошибки;
- можно ли сравнить результат с текущим ручным процессом.
Из источников стоит начать с официального анонса OpenAI о новых инструментах для агентов, затем посмотреть документацию Responses API и репозиторий Agents SDK. Для архитектурной трезвости полезно прочитать Anthropic Engineering о разнице между workflows и agents, а для графового подхода — документацию LangGraph.
Практическая ставка здесь простая: не пытаться построить «автономного сотрудника». Сначала собрать узкий процесс, где модель делает ограниченный выбор, инструменты имеют минимальные права, а человек видит трассу решений. Если такой прототип не даёт выигрыша на малой задаче, масштабирование автономности почти наверняка только усилит проблемы.