Alex Chernysh
AI-системы / поиск / evals / архитектура
Обсудить систему
СистемыСтатьиАссистент
Назад к статьям

Статья

Как строить агентные AI-системы, которые держатся в проде

Практический разбор: контракты инструментов, работа с контекстом, точки согласования, evals и телеметрия.

2 марта 2026 г.5 мин чтенияАвтор Alex Chernysh
Agents
К разделу
1. Выбирайте сценарии, пока не доказали, что вам нужен агент2. Работа с инструментами — это API-контракт, а не черта характера3. Поиск по базе — это часть контроля, а не просто контекст4. Согласование с человеком должно стоять на дорогой границе5. Работа с контекстом полезнее, чем сентиментальная память6. Evals — это операционная система агентного стека7. Телеметрия должна объяснять решения, а не только ошибки8. Выигрывающая архитектура обычно меньше, чем кажетсяЧто ещё почитатьИсточники и ссылки

Нужен сначала короткий проход?

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

Главный ориентир

Начинайте с самого узкого контура, который действительно решает задачу. Разделение Anthropic по-прежнему полезно: сценарий — там, где шаги в целом известны заранее, агент — там, где системе и правда приходится подстраиваться по ходу выполнения.

Базовая позиция для продакшена

Стройте самый узкий цикл, который сохраняет источники, точки согласования и покрытие evals. Больше автономии имеет смысл только после того, как более строгая версия уже стала узким местом.

Что обычно держится в проде

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

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

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

Если у задачи в целом понятная последовательность шагов, сценарий почти бесплатно даёт три вещи:

  • более простой разбор сбоев
  • более понятные затраты и задержку
  • меньший масштаб поломки, если модель неверно поняла задачу

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

2. Работа с инструментами — это API-контракт, а не черта характера

Текущие Agents docs у OpenAI полезны именно тем, что не мистифицируют инструменты. Web search, file search, connectors, shell или computer use — это обычные точки исполнения. Значит, и относиться к ним надо как к обычным интеграциям.

Хороший контракт инструмента обычно имеет четыре свойства:

  1. узкую входную схему
  2. понятные режимы отказа
  3. явные права
  4. детерминированную обработку результата

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

3. Поиск по базе — это часть контроля, а не просто контекст

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

Нормальный рабочий шаблон такой:

  • поднимать только то, что нужно текущему шагу
  • отсекать шум до генерации
  • не терять идентичность документов по дороге
  • разрешать системе отказаться, если опора на источники слаба

В агентном цикле один плохой шаг поиска легко заражает всё, что идёт следом.

4. Согласование с человеком должно стоять на дорогой границе

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

Типичные места:

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

Всё остальное лучше автоматизировать, логировать и, где можно, делать обратимым.

5. Работа с контекстом полезнее, чем сентиментальная память

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

Нормальная связность обычно складывается из трёх вещей:

  • состояния текущего запуска
  • устойчивых настроек, которые правда стоит переиспользовать
  • поднимаемых артефактов: квитанций, кратких сводок, прошлых результатов

Недавние тексты Anthropic про context engineering здесь особенно уместны. Главная задача — не накопить больше текста, а решить:

  • какой контекст должен жить в контуре постоянно
  • что лучше поднимать по запросу
  • что должно истекать по TTL
  • что обязано оставаться проверяемым

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

6. Evals — это операционная система агентного стека

Текущие материалы OpenAI по evals и статьи Anthropic про evals для агентных систем сходятся в одной практической мысли: если система живёт в несколько шагов, трогает инструменты и ветвится под неопределённостью, evals перестают быть роскошью и становятся обязательным слоем управления.

Сильный набор evals обычно комбинирует:

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

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

7. Телеметрия должна объяснять решения, а не только ошибки

Логов об ошибках у многих уже достаточно. Гораздо реже собирают ответ на более важный вопрос: почему система вообще решила, что ей это можно.

Минимальная трасса должна включать:

  • какой инструмент был выбран
  • с какими аргументами он вызвался
  • какие документы были подняты
  • какие правила сработали
  • где включилась ветка согласования
  • какой получился финальный формат ответа и степень уверенности

Без этого разбор инцидента быстро превращается в догадки с логами по краям.

8. Выигрывающая архитектура обычно меньше, чем кажется

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

Именно это и создаёт доверие: не театральная автономия, а управляемое поведение под ограничениями.

Что бы я правил завтра утром

  • сузил контракты инструментов, прежде чем трогать планировщик
  • поставил точки согласования там, где риск или стоимость становятся долговременными
  • добавил квитанции для каждого внешнего действия
  • сделал загрузку контекста явной, а не надеялся на фоновую память
  • собрал маленький набор evals вокруг реальных сценариев поломки
По теме

Что ещё почитать

  • Как устроить evals для LLM-систем в проде
  • Безопасность LLM-продукта без театра
Источники

Источники и ссылки

  • OpenAI: Agents guide
  • OpenAI: Agent evals
  • OpenAI: Trace grading
  • Anthropic: Building effective agents
  • Anthropic: Effective context engineering for agents

Что ещё почитать

Часть публичных заметок про AI-системы с опорой на источники, поиск, evals и поставку под реальными ограничениями.

Как строить юридические QA-системы, которым можно доверятьКакие преобразования запроса действительно помогают в RAGSpec-Driven Development: подход, которым я реально пользуюсь
На странице
1. Выбирайте сценарии, пока не доказали, что вам нужен агент2. Работа с инструментами — это API-контракт, а не черта характера3. Поиск по базе — это часть контроля, а не просто контекст4. Согласование с человеком должно стоять на дорогой границе5. Работа с контекстом полезнее, чем сентиментальная память6. Evals — это операционная система агентного стека7. Телеметрия должна объяснять решения, а не только ошибки8. Выигрывающая архитектура обычно меньше, чем кажетсяЧто ещё почитатьИсточники и ссылки