Agent Framework 1.21: контроль встроен в цикл агента

Что нового в Agent Framework python-1.21.0: Purview по полному буферу, правила для результатов инструментов и три вопроса перед продом.

  • Что вошло в релиз
  • Потоковый ответ и политика: где ломается проверка
  • Результат инструмента как вход в модель
  • Максимальное усилие рассуждения как статья бюджета

Что вошло в релиз

Microsoft выпустила python-1.21.0 для Agent Framework. Модель в релизе умнее не стала. Зато в нём есть проверка политик на потоковом ответе, правила для результатов инструментов, видимость подставленных аргументов и режим максимального рассуждения с явным выбором.

С этими рычагами директор по IT может ответить на вопрос «что агент сделал и почему ему это позволили».

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

В релизе: - в `agent-framework-core` и `agent-framework-purview` добавлены «standing guidance» для результатов инструментов, раскрытие переписанных аргументов при подстановке переменных и оценка политик Purview по полному буферу для потоковых ответов (PR #8784, #8506, #8702); - в `agent-framework-openai` появился режим рассуждения с максимальным усилием (#8857); - в `agent-framework-oracle` добавлен коннектор векторного хранилища Oracle, помеченный как alpha (#8676); - в примерах

показаны фильтрация ответов в групповом чате и расширенная последовательность get-started (#9005, #9133).

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

Потоковый ответ и политика: где ломается проверка

  1. Потоковая выдача нужна, чтобы пользователь видел текст сразу и не ждал ответа целиком. Проверка политик (утечка персональных данных, запрещённые темы, корпоративные ограничения) на таком потоке упирается в простую проблему: по обрывку фразы вердикт вынести трудно.

  2. Номер карты, разбитый на два куска, не распознаётся ни в одном из них. «Оценка по полному буферу»

  3. для Purview означает, что политика смотрит на ответ целиком.

  4. Как именно релиз решает компромисс, из заметок не видно.

  5. Моя гипотеза: либо текст задерживается до вердикта, либо проверка идёт параллельно и может отозвать уже показанное. У обоих вариантов своя цена, и её нужно измерить на своих сценариях до запуска.

  6. Для заказчика отсюда следует: фраза «у нас есть DLP» ничего не говорит про агента, пока не названо, на каком отрезке потока он работает.

Результат инструмента как вход в модель

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

  2. Если в письме или документе спрятана инструкция, модель может принять её за указание.

  3. Это классическая инъекция через данные, и она возникает в самом безобидном месте цикла.

  4. Добавленная в 1.21.0 «standing guidance» для результатов инструментов, судя по названию, даёт фреймворку постоянное правило обращения с такими результатами.

  5. Детали реализации в заметках не раскрыты, поэтому оценивать её силу пока рано.

  6. Направление верное: правило обработки данных инструмента задаётся один раз на уровне платформы, и промпты агентов остаются короче.

  7. Рядом лежит второй пункт: раскрытие переписанных аргументов при подстановке переменных.

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

  9. Шаблон для расследования бесполезен. Разница для инцидента такая: «агент запросил отчёт»

  10. или «агент запросил отчёт по клиенту, которого не должен был видеть».

Максимальное усилие рассуждения как статья бюджета

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

Больше рассуждений обычно стоит дольше по времени и дороже по токенам.

Конкретные цифры релиз не приводит, и подставлять чужие я не буду

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

Классификация входящих заявок и разбор спорного договора требуют разного бюджета.

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

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

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

Oracle и граница alpha

Коннектор векторного хранилища Oracle помечен как alpha. Для корпоративного заказчика это сигнал в обе стороны. Хорошо, что фреймворк идёт к данным там, где они уже лежат: во многих компаниях ядро учёта сидит на Oracle, и вынос его копии в отдельное векторное хранилище означает ещё одну систему со своими правами доступа. Плохо, что alpha означает отсутствие гарантий по API и поведению. Для RAG на таких данных разумно строить пилот и откладывать продуктивный контур до стабилизации коннектора.

Что из этого взять руководителю

  1. Перед переводом агента из пилота в эксплуатацию достаточно трёх вопросов к команде:

  2. Где в цикле агента проверяется вывод и на каком объёме текста: по фрагменту потока или по целому ответу?

  3. Что записано в журнале: шаблон вызова инструмента или аргументы, которые реально ушли?

  4. Кто и по какому правилу решает, какое усилие рассуждения оплачивать за какую задачу? Если на любой из них отвечают «посмотрим по ситуации», у вас демонстрация. Ответы нужны до первого дня работы с реальными данными клиентов.

Где это решается технически

  1. Фреймворк Microsoft даёт точки подключения, но политику компании за вас он не напишет. В нашей практике единый слой между агентами и моделями (LLM & Security Gateway) собирает проверки, журналы и лимиты в одном месте.

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

  3. Такой слой позволяет менять модель или фреймворк без переделки правил: сегодня это Agent Framework на Python, завтра другая библиотека.

  4. Пользователь видит чат, а под ним работает цепочка проверок, которую кто-то должен спроектировать и сопровождать.

  5. Простой внешний вид стоит сложной инженерии.

Вердикт

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

Источник

Релиз python-1.21.0, репозиторий microsoft/agent-framework, автор: Microsoft. Условия лицензии указаны в самом репозитории: https://github.com/microsoft/agent-framework/releases/tag/python-1.21.0

Обсудить статью: Agent Framework 1.21: контроль встроен в…

Укажите email или телефон, чтобы мы могли вам ответить.

Отправить через: