Azure AI Foundry Threads: как подготовить ИИ к работе в компании

Когда компания внедряет ИИ-агента, главный вопрос звучит не «умная ли модель», а «можно ли проверить, что она сделала и почему». Azure AI Foundry отвечает на него структурой: агент работает в управляемой среде, где каждое сообщение, вызов инструмента и шаг выполнения фиксируется.

В статье разберём, из чего состоит агент Azure AI, как потоки (threads), запуски (runs) и шаги запуска создают документальный след и почему инструменты с корпоративной безопасностью отличают рабочую систему от демо-версии.

Агент Azure AI: модель, инструкции и инструменты

Агент в Foundry — это не окно чата и не автозаполнение, а исполнитель, который работает по чёткому плану. План строится на трёх компонентах:

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

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

Чем это отличается от обычных чат-API

В большинстве чат-API есть только модель и промпт. Как только диалог начался, формального порядка и управления инструментами нет. Сервис агентов Foundry гарантирует наличие всех трёх уровней.

Кроме того, вы не привязаны к одной модели. В каталоге Foundry можно выбрать GPT-4 для сложных стратегий, более компактную модель для лёгких задач или, например, Mistral и DeepSeek. Модели меняются свободно, но всегда в рамках структуры, которая обеспечивает подотчётность.

Что происходит без структуры: риски для бизнеса

Если этих уровней нет, возникают типичные проблемы:

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

Для предприятия это не мелкая неприятность, а реальный риск, который мешает доверию и внедрению. Поэтому в Foundry ограничители (guardrails) встроены в агента. Инструкции работают как свод правил, набор инструментов можно жёстко ограничить или расширить под сценарий, а расширение возможно через корпоративные коннекторы и пользовательские API.

Threads в Azure AI Foundry: журнал всех взаимодействий

Поток (thread) — это не обычное окно чата, которое исчезает при закрытии, а сессия постоянного диалога. Каждый обмен информацией сохраняется в потоке: сообщения пользователя, ответы агента и даже реплики другого агента в мультиагентной системе. Историю можно открыть спустя долгое время после завершения чата.

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

Из чего состоят записи

Записи строятся из сообщений, и сообщение — это не только текст. Это может быть изображение, файл электронной таблицы или блок сгенерированного кода. У каждого сообщения есть метка времени и роль: пользователь или помощник. Открыв поток, вы видите, что было сказано, кто это сказал, когда и какой тип контента использовался.

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

Зачем нужна эта запись

• Аудит и комплаенс. Регуляторы или внутренний аудит видят всю последовательность: запрос, ответ, задействованные инструменты и время событий.
• Разработка. Если агент выдал неверный фрагмент кода, можно прокрутить поток до запроса и понять, как получился результат.
• Работа нескольких агентов. Если агенты общаются между собой, распределяя задачи, их переписка тоже логируется.

Аналогия из настольных ролевых игр: поток похож на записи мастера игры в Dungeons & Dragons, где отмечено, какие города посещены и какая добыча получена. Благодаря ему споры о забытых деталях не возникают. Без истории диалогов приходится опираться на скриншоты и туманные воспоминания, а это не работает, когда комплаенс требует доказательств. Нет записи — нет доказательств, нет следов — нет исправлений.

Запуски и шаги запуска: как агент действует и что фиксируется

Поток хранит историю, контекст и задачи, но сам ничего не выполняет. Потоки помнят, запуски действуют. Запуск (run) — это триггер, который активирует агента: он берёт контекст потока и начинает выполнение. Представьте кнопку «Пуск»: в потоке может лежать просьба «Проанализируй CSV-файл» или «Нарисуй линейный график», а запуск — момент, когда агент обрабатывает её с помощью инструкций, модели и инструментов. Он может запросить дополнительные данные, провести вычисления или вызвать интерпретатор кода для создания артефакта.

Статусы запуска

Запуск — не чёрный ящик, а контролируемое исполнение с отслеживанием статуса. Обычно встречаются состояния «В очереди», «В процессе», «Требует действий», «Завершено» и «Сбой». Примеры SDK часто опрашивают эти состояния в цикле, так что видно не только что сделано, но и когда.

Шаги запуска: подробный протокол

Одного статуса мало. Ответ может выглядеть нормально, но непонятно, обращался ли агент к внешнему API, писал ли код или просто импровизировал с текстом. В корпоративной среде такая непрозрачность опасна.

Шаги запуска снимают эти догадки. Каждый запуск записывается пошагово: какие выходные данные модель сгенерировала, какие инструменты вызвала, какие вычисления провела, какие сообщения создала. Это похоже на шахматную запись партии, только здесь, например, фиксируется получение файла в 10:02, выполнение блока кода в 10:03 и возврат графика в 10:04.

• Для разработчиков: можно прокрутить временную шкалу, найти конкретный сбой (неверный поисковый запрос, математическая ошибка) и исправить его. Отладка перестаёт быть гаданием и становится криминалистикой.
• Для комплаенса: на вопрос аудиторов, как создано резюме, есть доказательства: вызов инструмента, шаг интерпретатора, сформированный ответ, всё с отметками времени.
• Для повседневных операций: шаги создают воспроизводимые шаблоны. Рабочий процесс можно запустить повторно в той же последовательности, а оспариваемый результат — воспроизвести.

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

Инструменты агента: встроенные, OpenAPI и MCP

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

1. Встроенные инструменты

К ним относятся интерпретатор кода, поиск Bing, коннекторы SharePoint и Microsoft Fabric, а также Azure AI Search. С их помощью агент анализирует данные, извлекает файлы, ищет корпоративный контент и создаёт графики или отчёты без дополнительной настройки.

2. Собственные инструменты

Можно регистрировать свои инструменты через спецификации OpenAPI или Model Context Protocol (MCP). MCP называют аналогом USB-C для ИИ-инструментов: вместо ручных оболочек для каждого подключения к удалённым серверам MCP система берёт на себя обнаружение, версионирование и вызов инструментов. Это снижает накладные расходы на интеграцию, особенно если нужно объединить десятки систем.

3. Наблюдаемость вызовов

Каждый вызов инструмента регистрируется на уровне шагов: с идентификатором, входными и выходными данными и временными метками. Работа агента перестаёт быть «чёрной магией» и становится реестром: видно, что именно вызвано, можно подтвердить соблюдение прав доступа и хранить записи для требований соответствия.

Пример: от CSV-файла до графика

Вы загружаете CSV-файл как сообщение в поток. Агент вызывает интерпретатор кода в шагах выполнения, обрабатывает файл и строит график. Артефакт возвращается как прикреплённое изображение прямо в журнале потока. Вы не писали ни парсер, ни визуализатор: дали инструкцию, а агент выбрал инструмент и выполнил работу. Это задокументированное поведение в примерах SDK.

Корпоративная интеграция и безопасность

Инструменты можно связать с логическими приложениями. Это открывает агенту доступ к более чем 1400 готовых коннекторов. Вместо переписывания адаптеров для CRM, ERP или ITSM-платформ вы настраиваете коннекторы, которые бизнес уже использует. Один агент может работать в широком ландшафте систем без хрупких API-мостов.

Безопасность заложена в основу. Когда инструменты подключаются к SharePoint или Fabric, они используют аутентификацию от имени пользователя средствами Microsoft. Если у вас не было доступа к файлу вчера, агент не обойдёт это ограничение сегодня: личность и права доступа сохраняются, и без этого комплаенс-отделы вряд ли одобрят решение. Кроме того, отслеживается, кто вызвал инструмент, что было отправлено и что получено.

Практические выводы

• Стройте агента на триаде «модель, инструкции, инструменты»: без неё нет воспроизводимости и подотчётности.
• Выбирайте модель под задачу: GPT-4 для сложных сценариев, компактную для лёгких, при необходимости Mistral или DeepSeek.
• Используйте потоки как долговечный журнал: он нужен и аудиторам, и разработчикам, и в мультиагентных сценариях.
• Следите за статусами запусков: «В очереди», «В процессе», «Требует действий», «Завершено», «Сбой».
• Для отладки и проверки опирайтесь на шаги запуска: они показывают вызовы инструментов, вычисления и сообщения с отметками времени.
• Начинайте со встроенных инструментов, а для остального регистрируйте свои через OpenAPI или MCP.
• Подключайте корпоративные системы через уже используемые коннекторы и проверяйте, что права доступа пользователя сохраняются.
• Следующий шаг: создайте тестовый проект, настройте базового агента, запустите поток и проверьте шаги выполнения в SDK или на портале, чтобы убедиться, что логи отражают реальную картину.

Вывод

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