Агентные системы больше не удивляют тем, что умеют дёргать инструменты. В 2026 вопрос звучит тише: делают ли они это предсказуемо, оставляют ли понятный след и умеют ли вовремя остановиться.
1. Выбирайте сценарии, пока не доказали, что вам нужен агент
Самый быстрый путь к хрупкой системе — начать с roaming planner просто потому, что это выглядит современно.
Звучит очевидно. Команды всё равно это пропускают.
На практике сценарии дают три преимущества почти бесплатно:
- их проще разбирать и отлаживать
- легче держать задержку и стоимость в рамках
- меньше радиус поражения, если модель неверно поняла задачу
Агент имеет смысл только там, где фиксированная последовательность шагов уже перестала покрывать живые случаи.
2. Работа с инструментами — это API contract, а не черта характера
В текущих Agents guidance у OpenAI инструменты фактически трактуются как поверхности исполнения: поиск, web search, file search, shell, MCP и другие вызываемые интерфейсы. Значит, планка качества здесь такая же, как у любой нормальной интеграции.
Хороший contract для инструмента обычно имеет четыре свойства:
- узкая схема входа
- понятные режимы отказа
- явные права
- детерминированную обработку результата
Инструмент полезен не потому, что LLM умеет его вызвать, а потому, что contract сужает пространство для опасной импровизации.
3. Поиск по базе — это часть контроля, а не просто контекст
Многие сбои агентных систем на деле оказываются сбоями поиска, просто в костюме reasoning.
Рабочий шаблон обычно такой:
- поднимать только то, что нужно текущему шагу
- отсекать шум до генерации
- не терять идентичность документов по дороге
- разрешать системе отказаться от ответа, если опора на источники слабая
В агентном потоке один плохой шаг поиска часто заражает всё, что идёт дальше. Система выглядит занятой, но ошибается уже несколько стадий подряд.
4. Согласование с человеком должно стоять на дорогой границе
Approval gates нужны не везде. Они нужны там, где потом придётся объяснять человеку, почему системе вообще было позволено это сделать.
Типичные места:
- отправка или удаление чего-то наружу
- изменение финансового или юридического состояния
- код или инфраструктура с реальными побочными эффектами
- уверенный ответ в high-stakes domain
Всё остальное лучше автоматизировать, логировать и делать обратимым.
5. Память полезна только если она ограничена и проверяема
Команды часто говорят, что им нужна memory, хотя на деле им нужна непрерывность работы.
Полезная память обычно распадается на три типа:
- состояние текущего запуска — что произошло в этом прогоне
- устойчивые настройки — пользовательские или системные предпочтения
- поднимаемые артефакты — решения, квитанции, summaries, outputs
Чего не хочется: бесформенного куска прошлого текста, который нельзя проверить, почистить по TTL или восстановить из источников.
6. Evals — это операционная система агентного стека
В 2026 evals уже не роскошь. Это слой, который позволяет выпускать систему и не гадать, что она сломает завтра.
Сильный набор evals обычно комбинирует:
- проверку успеха по задаче
- корректность вызовов инструментов
- groundedness или citation checks
- корректные отказы и эскалации
- бюджеты по задержке и стоимости
Агент без evals — это просто сценарий, который вы пока решили не измерять.
7. Телеметрия должна объяснять решения, а не только ошибки
Логов об ошибках у многих уже достаточно. Гораздо реже собирают ответ на более важные вопросы:
- какой инструмент был выбран
- с какими аргументами он был вызван
- какие документы система подняла
- какие policy events сработали
- где включилась ветка с согласованием
- каким был финальный тон ответа
Хороший trace отвечает на вопрос: почему система решила, что ей это можно?
8. Выигрывающая архитектура обычно меньше, чем кажется
Самые живучие агентные системы в 2026 выглядят не как автономные операторы, а как дисциплинированные рабочие контуры с короткими циклами, явной опорой на источники и понятными границами.
Именно это и создаёт доверие: не театральная автономия, а управляемое поведение под ограничениями.