Агент работает цепочкой шагов
Модель строит план, вызывает инструмент, читает ответ и решает, что делать дальше.
Новая команда crewai eval показывает, где сломался агент. Почему для бизнеса диагностика агентов важнее новых функций и какие 3 вопроса задать подрядчику.
Команда crewAI выпустила версию 1.15.28 своего Python-фреймворка для многоагентных систем.
Главная новинка - команда `crewai eval`: она показывает, на каком шаге остановилась модель.
Большинство остальных изменений тоже касаются диагностики: команда разработки должна узнать о поломке раньше пользователя.
Для бизнеса здесь проходит граница между пилотом и работающим продуктом. Агент, у которого никто не видит место поломки, до продакшена не доходит.
Модель строит план, вызывает инструмент, читает ответ и решает, что делать дальше.
На сложной задаче таких шагов бывают десятки.
Когда цепочка обрывается, у инженера остаётся лог на сотни строк, и место, где модель потеряла нить, он ищет вручную. `crewai eval` разбирает цепочку сам и выдаёт отчёт с точкой обрыва.
Остальные изменения закрывают другие источники сбоев: - Размер контекстного окна берётся из каталога LiteLLM. LiteLLM - библиотека-прослойка с единым интерфейсом к большинству провайдеров моделей. В её каталоге записаны лимиты каждой модели.
При неверном лимите агент либо обрезает себе историю, либо падает на переполнении контекста.
Теперь фреймворк подтягивает значение из общего каталога, и вручную этот параметр настраивать не нужно. - Flows учитывают правку человека после паузы. Flow - сценарий, в котором агент останавливается и ждёт проверки. В прошлых версиях правка проверяющего после возобновления могла потеряться, а у проверенного вывода ломались типы данных. В 1.15.28 сценарий принимает обратную связь и сохраняет формат. - Предупреждение о нуле инструментов.
Если подключённые приложения не дали агенту ни одного инструмента платформы, фреймворк об этом сообщает.
Без предупреждения такой агент запускается без инструментов и может выдумывать ответы. - Деплой.
Фреймворк теперь показывает причины падения деплоя; разработчики починили удаление и проверку lock-файла.
ZIP-деплой гарантированно получает новый код, локальные JSON-файлы читаются в UTF.
В продакшене он получает кривые данные, медленный API контрагента и черновик, который сотрудник поправил и ушёл на обед.
Обычный сервис в таких случаях возвращает ошибку.
Агент чаще отвечает уверенно и неправильно.
Мы называем это тихим отказом: мониторинг показывает зелёные метрики, хотя результат негодный.
Ценность инструмента мы меряем через TTU (time to use) - время до первого полезного результата.
Время на разбор поломок входит в эту метрику.
Если инженер тратит полдня на поиск причины каждого сбоя, через месяц сопровождение агента съедает больше часов, чем он экономит.
Тогда руководитель закрывает проект и списывает бюджет как эксперимент.
Судя по составу релиза, разработчики crewAI видят ту же проблему и в первую очередь закрывают именно эти дыры.
За фразой «агент просто работает»
Обновление фреймворка не добавляет ни один из них: их строит команда. Трассировка каждого шага.
Вызов модели, вызов инструмента, ответ, решение - у каждого шага есть идентификатор, время и стоимость. `crewai eval` закрывает часть этой задачи внутри одного фреймворка. В компании агентов обычно несколько, на разном стеке, поэтому трассировку выносят в общий контур. Единая точка доступа к моделям.
Наш LLM & Security Gateway стоит между агентами и провайдерами:
Шлюз хранит лимиты моделей, логирует вызовы, маскирует персональные данные и переключает провайдера при сбое.
Проблему контекстных окон, которую crewAI решил каталогом LiteLLM, шлюз решает сразу для всех агентов компании. Инструменты по стандарту.
Инструменты агентов мы подключаем к 1С, PIM и ERP через MCP - открытый протокол, по которому модель получает доступ к внешним системам.
На старте агент проверяет, что все объявленные инструменты на месте, и при пустом списке отказывается работать.
Это та же проверка, что появилась в crewAI, только на уровне инфраструктуры.
По этой схеме мы строим генерацию текстов карточек товаров и сборку таксономии каталога.
Каждый шаг журналируется, а правку редактора система сохраняет как эталон, на котором проверяют следующие прогоны.
Когда вы выбираете подрядчика или фреймворк под агентную систему, задайте три вопроса. По ответам видно, дойдёт ли проект до продакшена.
Где посмотреть, на каком шаге агент сломался, и сколько времени займёт поиск причины?
Что происходит с правкой проверяющего: она пропадает или попадает в следующий прогон?
Что агент делает, если инструмент не подключился или не ответил за отведённые секунды? Если в ответ звучит «посмотрим логи» и «такого не бывает», вы покупаете демо.
В релизе 1.15.28 нет громких функций, и ценность у него именно в этом. Разработчики агентных фреймворков смещают фокус с вопроса «что ещё умеет модель» на вопрос «как быстро мы узнаем, что она ошиблась». Бизнесу нужен ответ на второй. Агент с видимыми поломками команда чинит за часы, и через квартал он двигает метрику. Агент без диагностики через квартал рискует оказаться в списке закрытых пилотов.