Как только агент получает право вызывать инструменты, архитектура перестает быть просто цепочкой запросов и превращается в систему с разрешениями, состоянием и бюджетами.
Глава показывает, как проектировать цикл планирования, реестр инструментов, этапы согласования, повторы и условия остановки так, чтобы агент приносил пользу, а не создавал неконтролируемую операционную сложность.
На интервью она помогает обсуждать не абстрактного агента, а конкретный рабочий контур: кто что может вызвать, как проверяются аргументы и как система безопасно деградирует при ошибках.
Практическая польза главы
Архитектура цикла
Переводите понимание агентного цикла и вызова инструментов в архитектурные решения о правах, состоянии, бюджетах и путях безопасного отказа.
Контроль автономии
Оценивайте систему через надежность вызова инструментов, управляемость автономии, задержки, стоимость и операционные риски.
Материал для интервью
Структурируйте ответ вокруг цикла агента, реестра инструментов, согласований и условий остановки, показывая, где возникают ограничения и как вы ими управляете.
Компромиссы системы
Явно фиксируйте компромиссы в агентном цикле и вызове инструментов: скорость экспериментов, качество, объяснимость, бюджет ресурсов и сложность поддержки.
Как только агент получает право на , чтение внешних данных и влияние на состояние системы, перед нами появляется уже не “умный запрос”, а маленькая среда выполнения со своими правами, бюджетами, состоянием и путями безопасного отказа.
Полезно обсуждать такую систему через границы возможностей, семантику восстановления, согласования и : именно они определяют, останется ли агент управляемым под нагрузкой, при сбоях и в контуре записи.
Границы возможностей
Главный вопрос не только в том, какую модель выбрать, а в том, какие действия агент вообще может видеть, планировать и вызывать.
Семантика восстановления
Нужно заранее определить, как рабочая цепочка продолжится после тайм-аута, ошибки инструмента или частично выполненного шага.
Ручной перехват
Контур записи, дорогие действия и внешние побочные эффекты должны иметь понятный путь согласования и явный переход к человеку.
Ключевые слои среды выполнения
Удобнее всего разбирать агентную систему по слоям: кто принимает решение о следующем шаге, кто проверяет доступ, кто исполняет действие и кто отвечает за восстановление после ошибки. Обычно разговор начинается с и заканчивается , которая не дает модели напрямую добраться до реального побочного эффекта.
Планировщик и оркестратор
В центре цикла стоит оркестратор: он получает запрос, текущее состояние выполнения и бюджет, а затем выбирает только следующий шаг вместо попытки предсказать всю цепочку заранее.
Ключевой контракт: На входе: задача, история, набор доступных действий и контекст риска. На выходе: один следующий шаг с кодом причины и ограничением по бюджету.
На что смотреть: Длина цикла, скорость расходования бюджета, среднее число перепланирований и доля сценариев, дошедших до условия остановки без ручного вмешательства.
Реестр инструментов и контракты
Реестр инструментов задает для модели ограниченную и типизированную поверхность: названия действий, схемы входа и выхода, область доступа и класс риска.
Ключевой контракт: У каждого инструмента должны быть схема аргументов, контракт ответа, список разрешенных действий и явное описание побочного эффекта.
На что смотреть: Нарушения схемы, отклоненные вызовы инструментов, устаревшие версии контрактов и доля вызовов, не давших полезного результата.
Исполнение и изолированная среда
Слой исполнения превращает решение оркестратора в конкретный вызов команды, API или внутреннего сервиса, не выпуская модель в неограниченную среду выполнения.
Ключевой контракт: Каждый вызов проходит через изолированную среду с тайм-аутом, политикой повторов, ожиданием идемпотентности и журналом фактических побочных эффектов.
На что смотреть: Задержка инструментов, доля тайм-аутов, повторные вызовы одного и того же шага, успешность побочных эффектов и доля ручных откатов после выполнения.
Политики и согласования
Этот слой отделяет сценарии только для чтения от действий, которые стоят денег, меняют данные или запускают внешнюю операцию.
Ключевой контракт: Для каждого действия определяются уровень риска, требование согласования, путь отказа и причина безопасного запрета, понятная и пользователю, и оператору.
На что смотреть: Доля согласованных действий, число отказов, ложные блокировки, время ожидания ручной проверки и количество контуров записи, завершенных без нужного согласования.
Состояние и память
Краткоживущий контекст, состояние контрольной точки и долговременную память нельзя смешивать: у них разный жизненный цикл и разные задачи.
Ключевой контракт: Краткоживущий контекст хранит данные текущего запроса, состояние выполнения хранит прогресс шага, а долговременная память хранит факты и результаты прошлых сценариев.
На что смотреть: Успешность возобновления, обращения к устаревшей памяти, размер контрольной точки и расхождение между текущим состоянием мира и сохраненной памятью.
Наблюдаемость и оценивание
Агентную среду выполнения нужно наблюдать как распределенную систему: шаги модели, вызовы инструментов, согласования, ошибки и итог решения должны собираться в единую трассу.
Ключевой контракт: Один идентификатор трассы связывает запрос, вызовы инструментов, согласования, резервный сценарий и итог, а контур оценивания на исторических прогонах проверяет регрессии перед выпуском новых правил.
На что смотреть: Завершенность задач, доля откатов, доля ответов с опорой на источники, регрессии на исторических прогонах и цена успешного сценария на единицу пользы, а не на один вызов модели.
Референсная архитектура агентной среды выполнения
Оркестратор не должен быть всем сразу
Он выбирает следующий шаг и бюджет, а фактическое исполнение и side effects живут за отдельной границей.
Реестр и policy layer режут surface area
Агент видит только типизированные capabilities, а опасные действия проходят через approval path.
State и traces - отдельные системы
Без checkpoint-состояния и audit trail агентный цикл плохо восстанавливается и почти не поддается разбору.
Путь выполнения: от запроса к безопасному действию
Ниже полезно смотреть не на всю цепочку сразу, а на последовательность шагов с проверками, бюджетами и , которые позволяют безопасно продолжить сценарий после сбоя или паузы.
1. Классификация запроса и выбор бюджета
~20-80 msНа старте система решает, какой набор действий вообще доступен, какой бюджет допустим и какие правила остановки включаются для этого сценария.
Контрольная точка: Определить режим: только чтение, изменения после согласования или ручной разбор.
2. Восстановление контекста и состояния выполнения
~20-120 msЕсли сценарий продолжается после сбоя или паузы, среда выполнения должна восстановить только релевантное состояние и не смешать его с устаревшей памятью.
Контрольная точка: Поднять контекст сессии, контрольную точку и нужные факты из памяти.
3. Планирование одного следующего шага
~100-500 msХороший оркестратор формулирует следующую проверяемую единицу действия: какой инструмент нужен, какие входные данные ожидаются и как понять, что шаг завершен успешно.
Контрольная точка: Выбрать следующее действие, а не пытаться описать всю цепочку целиком.
4. Проверка аргументов, прав доступа и кода риска
~10-70 msПеред реальным вызовом инструмента проверяются схема аргументов, допустимость доступа, стоимость действия и необходимость ручного согласования.
Контрольная точка: Остановить опасный вызов до запуска, а не после него.
5. Исполнение в изолированной среде и разбор результата
~50 ms - secondsПосле вызова система анализирует ответ инструмента, качество результата, наличие побочного эффекта и решает: продолжать, перепланировать или переключиться на резервный сценарий.
Контрольная точка: Зафиксировать результат, побочные эффекты и ошибки с кодом причины.
6. Сохранение трассы, остановка или повтор цикла
~10-50 msДаже успешный шаг должен записать трассу, обновить контрольную точку и пройти через условие остановки, чтобы цикл не продолжался по инерции.
Контрольная точка: Сохранить контрольную точку и закончить сценарий детерминированно.
Цикл исполнения и точки принятия решений
Validation должна быть отдельным шагом
Проверка схемы, ACL и risk code до исполнения уменьшает число дорогих и небезопасных tool calls.
Decision node нужен после каждого результата
Агент не должен автоматически считать любой output достаточным основанием для следующего side effect.
Повтор - это не blind retry
Хороший retry меняет scope, аргументы или инструмент, а не просто повторяет тот же вызов.
Примеры агентных рабочих цепочек
Два типовых сценария ниже показывают разницу между контуром с приоритетом и агентом, который может готовить изменения и переходить к записи только после отдельного согласования.
Ассистент с опорой на извлечение контекста
Сценарий для корпоративного ассистента или внутреннего помощника по знаниям: главная задача здесь - собрать ответ с опорой на источники и справочные инструменты, не выполняя действия на запись по умолчанию.
Агент с правом на изменения
Сценарий для агента, работающего с кодом, внутренней автоматизации или управляемого устранения проблем: агент может подготовить изменение, но путь до побочного эффекта отделен от планирования и защищен этапами согласования.
Инструментальные роли и примеры решений
Ниже не “обязательный стек”, а карта типовых слоев: сначала зачем нужен слой, затем какие инструменты и подходы там обычно встречаются и какой компромисс они приносят.
| Слой | Зачем нужен | Примеры | Когда подходит | Главный компромисс |
|---|---|---|---|---|
| Оркестрация | Координирует жизненный цикл шага, бюджеты, повторы, паузу/возобновление и условия остановки. | конечный автомат, LangGraph, Temporal | Подходит, когда рабочая цепочка многошаговая, восстанавливаемая и должна жить дольше одного вызова модели. | Чем мощнее система оркестрации, тем выше цена схем, миграций и операционного владения самой средой выполнения. |
| Контракты и реестр инструментов | Описывает доступные действия как типизированные операции со схемой, областью доступа и метаданными риска. | Model Context Protocol, OpenAPI/JSON Schema, внутренний реестр возможностей | Подходит, когда число инструментов быстро растет и их нужно показывать модели как ограниченный и объяснимый набор возможностей. | Чем формальнее контракт, тем меньше хаоса, но тем дороже быстрое развитие разовых инструментов. |
| Изолированное исполнение | Изолирует фактический запуск команд, кода или внешних API от цикла модели. | изолированный исполнитель, Docker, Firecracker microVM | Нужно всегда, когда агент умеет запускать код, команды оболочки, операции с файловой системой или дорогие интеграции. | Сильная изоляция уменьшает радиус поражения, но добавляет задержки, стоимость инфраструктуры и сложность отладки. |
| Состояние и память | Хранит контекст сессии, состояние контрольной точки, долговременную память и курсор восстановления. | Redis, Postgres, хранилище истории цепочки, векторная база данных | Нужно, когда сценарий приходится восстанавливать после паузы, растягивать на несколько шагов или переиспользовать факты. | Больший объем памяти улучшает непрерывность сценария, но повышает риск устаревшего контекста, несогласованного извлечения и долга по управлению данными. |
| Наблюдаемость и оценивание | Связывает вызовы модели, шаги инструментов, согласования и результаты в единую трассу и контур проверки регрессий. | OpenTelemetry, Langfuse, Phoenix, собственный контур исторического прогона | Подходит для рабочей среды выполнения, где важно не только видеть успешность, но и разбирать конкретные падения. | Чем детальнее трассировка, тем выше стоимость хранения, требования к редактированию данных и нагрузка на аналитический контур. |
| Политики и согласования | Превращает решения о риске в отдельный архитектурный слой, а не в текст внутри запроса к модели. | Open Policy Agent, Cedar, очередь согласований, сервис ручной проверки | Нужно там, где действия на запись, деньги, персональные данные, границы арендатора или рабочее состояние системы нельзя полностью доверять модели. | Сильные защитные ограничения уменьшают риск, но могут замедлять пользовательский сценарий и снижать ощущение автономии, если правила сделаны слишком грубо. |
Состояние, управляющий контур и резервный сценарий
Именно здесь проявляются различия между краткоживущим контекстом, долговременной памятью и : без такого разделения система быстро накапливает устаревшие данные и плохо переживает сбои.
Transient context - не durable state
Контекст текущего запроса можно отбросить, а run state нужен для resume после сбоя и повторяемого расследования.
Policy gates проверяют право на действие
Guardrails полезны не как текст в prompt, а как отдельная проверка с кодом решения и понятной причиной отказа.
Fallback должен быть предсказуемым
При высоком риске система обязана завершиться в deterministic path: human handoff, rollback или read-only answer.
Сбои, пути согласования и безопасная деградация
Хорошая агентная архитектура оценивается не количеством автономных шагов, а качеством контролируемой деградации: умеет ли система остановиться, объяснить причину, передать контекст человеку и завершить сценарий без скрытого побочного эффекта. Отдельно полезно проверять это на , а не только на единичных демо-сценариях.
Нарушение схемы и невалидный ответ инструмента
Симптом: Модель выбирает правильный класс действия, но ошибается в аргументах или получает частично сломанный ответ.
Архитектурный ответ: Сделайте проверку и нормализацию отдельным шагом, а перепланирование - обязательным после невалидного ответа вместо слепого повтора.
Дрейф цикла и выгорание бюджета
Симптом: Агент много раз вызывает похожие инструменты, но не приближается к завершению задачи.
Архитектурный ответ: Ограничьте число шагов, введите сигналы о слишком быстром расходовании бюджета и правила остановки, которые переводят сценарий в ручной разбор или детерминированный резервный сценарий.
Устаревшая память и неверное восстановление состояния
Симптом: Сценарий продолжает работу из устаревшей контрольной точки или использует факты, которые уже не соответствуют текущему миру.
Архитектурный ответ: Версионируйте контрольные точки и записи памяти, фиксируйте свежесть источника и требуйте повторного поднятия контекста перед рискованным действием.
Опасный побочный эффект до согласования
Симптом: Действие на запись запускается до того, как человек увидел краткое описание последствий, список изменений или стоимость ошибки.
Архитектурный ответ: Разведите пробный прогон и реальное исполнение архитектурно: согласование должно открывать отдельную возможность записи, а не подтверждать уже запущенный вызов.
Отказ нижележащего инструмента или провайдера
Симптом: Нужный инструмент недоступен, зависает или возвращает непредсказуемый результат на критическом шаге.
Архитектурный ответ: Подготовьте резервный путь заранее: альтернативный инструмент, ответ только для чтения, отложенное выполнение или эскалация на оператора.
Антипаттерны
Практические рекомендации
Связанные материалы
- Model Context Protocol - Практический стандарт для описания инструментов и ресурсов как типизированного контракта для среды выполнения модели.
- Temporal Workflows - Референс по устойчивым долгоживущим рабочим цепочкам, историческому прогону и семантике восстановления.
- Open Policy Agent - Подход policy-as-code для решений о доступных действиях, логики согласования и отказов с понятными кодами причин.
- OpenTelemetry - База для трасс и метрик по вызовам модели, шагам инструментов, согласованиям и итоговому результату.
- OWASP GenAI Security Project - Материалы по внедрению инструкций в запрос, злоупотреблению инструментами и моделированию угроз для LLM- и агентных систем.
Связанные главы
- Prompt Engineering for LLMs (short summary) - Почему проектирование запросов быстро превращается в проектирование контекста, а затем и всей среды выполнения.
- An Illustrated Guide to AI Agents (short summary) - Книжное дополнение про память, циклы планирования, рефлексию и организацию вызова инструментов.
- GenAI/RAG System Architecture - Соседний кейс, где извлечение контекста, защитные ограничения и наблюдаемость уже работают как полноценная рабочая система.
- Защитные ограничения LLM, внедрение инструкций в запрос и паттерны безопасности - Как превращать безопасность и границы доверия в отдельный архитектурный слой, а не в одно правило внутри запроса.
- AI Coding Agent Platform - Практический кейс про изоляцию среды, разрешения на инструменты, согласования и управляемый контур записи для агентов, работающих с кодом.