← назад к разделу

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

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

агент поддержки MCPMCP сервер заказов сервер платежей A2A логистика трасса прогона: шаги модели и вызовы инструментов

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

Два протокола: инструменты и соседиспросят на собеседовании

Агенту нужно разговаривать с двумя видами собеседников. Первый это инструменты: функции с понятным входом и выходом, «найти заказ», «оформить возврат». Второй это другие агенты: у них своя модель, свои инструменты, и задача у них может идти минутами, с уточняющими вопросами. Для первого сложился стандарт MCP, для второго A2A. Путать их не стоит: инструмент вызывают и ждут ответ, агенту отдают задачу и следят за её статусом.

MCP: инструменты по стандартуспросят на собеседовании

Model Context Protocol описывает, как приложение с моделью получает список инструментов, их описания и схемы аргументов, и как их вызывает. Команда заказов один раз поднимает MCP-сервер со своими операциями, и к нему подключается любой агент: свой, внутренний ассистент, редактор кода. Без стандарта каждая пара «агент и сервис» писала бы свою обвязку.

Для продакшена важны три вещи. Сервер это обычный сервис со своей аутентификацией: агент приходит к нему со своей учёткой, как описано в статье про безопасность агентов. Описания инструментов это часть промпта, и их меняют так же осторожно, как промпт: новая формулировка меняет поведение агента. И список инструментов агенту отдают не весь, а нужный под задачу, иначе модель выбирает хуже.

A2A: агент разговаривает с агентомспросят на собеседовании

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

{
  "name": "logistics-agent",
  "description": "Переносит доставку, меняет пункт выдачи, отвечает о статусе посылки",
  "skills": ["reschedule_delivery", "change_pickup_point"],
  "url": "https://logistics.internal/a2a"
}

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

Как выкатывать агентаспросят на собеседовании

Агент это сервис, и выкатывается как сервис: контейнер, конфигурация снаружи, проверки готовности. Особенностей три.

Первая: версия агента это не только код. Это ещё модель, инструкция и описания инструментов. Их фиксируют вместе и выкатывают как одну версию, иначе невозможно понять, что изменило поведение. Вторая: прогон агента бывает долгим, минуты и часы, если он ждёт человека. Его состояние хранят во внешнем хранилище, чтобы рестарт пода продолжил задачу, а не начал заново или бросил. Третья: выкат новой версии сначала проходит оценку на наборе примеров, а в прод идёт постепенно, на часть трафика, как любой рискованный релиз.

Трассировка прогонаспросят на собеседовании

Логи по строкам не объясняют, почему агент решил так. Нужна трасса: один корневой span на запрос пользователя, внутри дочерние span на каждый шаг модели и каждый вызов инструмента. У шага модели в атрибутах номер шага, модель, число токенов и выбранный инструмент; у вызова инструмента его имя, длительность и статус.

Тексты промптов и ответов в трассу кладут осторожно: там персональные данные. Обычно хранят их отдельно, с коротким сроком и доступом по запросу, а в трассе оставляют ссылку. Сквозной идентификатор трассы передают и в MCP-серверы, и в A2A-задачи, иначе прогон рвётся на границе и разбор инцидента превращается в сверку часов по журналам.

Лимиты и остановкаспросят на собеседовании

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

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

Коротко

  • Инструменты подключаются по MCP: функция с описанием и схемой, вызов и ответ.
  • Другие агенты вызываются по A2A: карточка умений, задача со статусами, исполнение у владельца.
  • Описания инструментов это часть промпта: меняются осторожно, агенту отдаются по задаче.
  • Версия агента это код, модель, инструкция и описания вместе; выкат после оценки и постепенно.
  • Состояние долгого прогона хранится вне процесса; рестарт продолжает задачу.
  • Трасса: корневой span на запрос, дочерние на шаги модели и вызовы; идентификатор идёт через MCP и A2A.
  • Лимиты на прогон: шаги, токены, рубли, время; при срабатывании задача уходит человеку.

Что почитать дальше