Агент в проде: скучные коммиты важнее демо

Релиз без громких функций

В релизе dotnet-1.24.0 Microsoft Agent Framework почти нет громких функций: сохранение null в состоянии сессии, проверка идентификаторов, валидация возможностей для исполнения кода. В тот же период команда Foundry выпустила разбор того, как выбирать между Azure Document Intelligence и Azure Content Understanding. Оба материала показывают, из чего инженеры собирают результат внедрения ИИ: из деталей, которых нет в демо и от которых зависит, доживёт ли проект до второго квартала.

Что лежит в релизе dotnet-1.24.0

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

Часть пунктов: - сохранение явного null в состоянии сессии при передаче туда и обратно (#9012); - учёт отключённой памяти недавнего поиска (#9013); - сохранение лениво создаваемых сообщений запроса при вызове агента (#9017); - отклонение чувствительных идентификаторов в декларативных описаниях (#9071); - усиление проверки возможностей в LocalCodeAct (#9057); - стабилизация пакета для агентов на Anthropic (#9111); - восстановление фильтра решения для source-only релиза (#9140). По отдельности это мелочи.

Вместе они отделяют прототип от системы, которую можно принять в эксплуатацию.

Почему null в сессии стоит отдельного коммита

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

Если данные клиентов лежат в 1С или в ЭДО, служба безопасности такое решение не пропустит.

Оценить, где ИИ даст эффект в вашем процессе

Почта clients@kt.team Telegram @kt_team_it

Безопасность живёт в валидации

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

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

Конфигурация агента в YAML или JSON тоже входной интерфейс, и проверять её нужно так же, как пользовательский ввод.

Поэтому вокруг агентов мы строим слой контроля

LLM & Security Gateway стоит между моделью и корпоративными системами, фильтрует данные и фиксирует, что именно агент запрашивал.

Фреймворк закрывает часть рисков изнутри, а периметр остаётся задачей интегратора.

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

В материале Microsoft Foundry сказано, что обработка документов выглядит простой, пока все входные файлы имеют предсказуемый формат. В реальности счета приходят в разных макетах, существенные условия договоров спрятаны в прозе, а один бизнес-процесс может объединять PDF, документы Office, изображения, аудио и видео.
Авторы называют критерии выбора между Azure Document Intelligence и Azure Content Understanding: - качество извлечения; - трудоёмкость разметки; - задержка и стоимость; - варианты развёртывания; - рассуждение и привязка к источнику; - объём кода пайплайна, который придётся поддерживать.
Оба сервиса опираются на общие базовые возможности извлечения содержимого.
Различие в том, сколько работы остаётся вашей команде: размечать образцы, дописывать обвязку, объяснять результат аудитору. ###
Как применить это к решению о закупке
Мы советуем считать время до первого полезного результата (TTU, time to use) и стоимость поддержки через год.
Пайплайн из сотен строк обвязки вокруг сервиса распознавания дёшев в первый месяц и дорог на третий, когда у крупного поставщика меняется формат счёта.
Это наша оценка по проектам интеграции, а не вывод из статьи Microsoft: цифр по стоимости владения в тексте нет.

Где два сюжета сходятся

В релизе агентного фреймворка и в разборе документных сервисов главный вопрос один: сколько инженерной работы стоит за простым результатом.
Чтобы интерфейс выглядел просто, разработчики должны сохранить состояние, проверить права, нормализовать форматы и обеспечить показ источника ответа.
Поэтому AI-native интеграцию мы начинаем с контрактов, границ доверия и измеримого результата, а модель выбираем после них. Агент, который читает документы через RAG или ходит в системы через MCP-серверы, получает слабости обоих слоёв: теряет состояние, получает лишнее право или неверно извлекает поле из договора.
Ошибка на любом этапе попадает в бизнес-метрику.

Вердикт

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

Агент в проде: скучные коммиты важнее демо

Релиз без громких функций

Что лежит в релизе dotnet-1.24.0

Почему null в сессии стоит отдельного коммита

Оценить, где ИИ даст эффект в вашем процессе

Безопасность живёт в валидации

Поэтому вокруг агентов мы строим слой контроля

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

Где два сюжета сходятся

Вердикт

Обсудить статью: Агент в проде: скучные коммиты важнее демо

Продолжить по теме

Связанные решения

Статьи по теме

Видео по теме

Новости по теме