Microsoft объяснила, как context engineering снижает стоимость AI-агентов

Контекст превращается в повторяющийся счёт

Microsoft определяет context engineering как непрерывный выбор того, что именно модель увидит на каждом ходе агента. В context window заново попадают инструкции, описания инструментов, найденные документы и история разговора; после завершения хода этот набор исчезает и при следующем вызове формируется снова. Для многошаговой системы лишний фрагмент поэтому оплачивается не один раз, а повторно на каждом этапе работы.

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

Foundry IQ сужает retrieval до подтверждающих фрагментов

Первый уровень системы — Foundry IQ. Knowledge base может соединять Work IQ, Fabric IQ, Web IQ, Azure Blob Storage, SharePoint, OneLake и Azure SQL. При запросе сервис раскладывает его на подзапросы, параллельно ищет по подключённым источникам, выполняет semantic reranking и возвращает grounding passages вместе с citations. В модель поступает не весь доступный документальный массив, а отобранные свидетельства с возможностью проследить происхождение.

Одну базу знаний разрешено использовать нескольким агентам. Индексируемые источники могут обновляться инкрементально по расписанию, а удалённые — запрашиваться по требованию. Для контроля доступа Foundry IQ способен работать под Microsoft Entra identity вызывающего пользователя, синхронизировать ACL поддерживаемых источников и учитывать sensitivity labels Microsoft Purview. Таким образом, общий retrieval-слой не должен превращаться в способ обойти уже действующие ограничения корпоративных данных.

Во внутренних оценках Microsoft knowledge bases Foundry IQ повысили evidence recall до 54% на BrowseComp-Plus и одновременно уменьшили стоимость retrieval tokens на 34%. Компания связывает результат с agentic retrieval, semantic reranking, улучшенным синтезом ответа и более экономным использованием токенов. Это данные самого поставщика, а не независимый production-бенчмарк, поэтому переносить проценты на любой workload без собственного canary нельзя.

Toolbox скрывает большую библиотеку за поиском

Описание каждого доступного инструмента обычно находится в prompt даже тогда, когда инструмент не нужен. Toolboxes in Foundry заменяют такой полный каталог единым управляемым MCP endpoint. В нём можно объединить встроенные web search, code interpreter и file search, собственные MCP servers, OpenAPI 3.0 и 3.1 APIs и A2A agents, а централизованный слой берёт на себя authentication, access policies и versions.

Tool search передаёт модели компактный интерфейс: агент описывает требуемую возможность обычным языком и получает подходящие инструменты. Полный перечень не занимает context window на каждом ходе. Microsoft сообщает, что во внутреннем сравнении на публичном open-source dataset этот подход сократил среднее потребление input tokens примерно на 97% для больших библиотек. Foundry также поднимает чаще используемые tools ближе к основному пути, чтобы со временем ускорять повторяющиеся операции.

Цифра 97% относится именно к расходу входных токенов на представление большой библиотеки, а не к полной цене агента. В реальном процессе останутся токены задачи, retrieved evidence, ответы инструментов и история. Поэтому корректная метрика внедрения — стоимость завершённого проверенного outcome, дополненная долей неправильных tool calls и количеством восстановительных ходов, а не только длина исходного списка tools.

Skills загружают процедуру только при необходимости

Корпоративные инструкции часто содержат длинные регламенты: порядок эскалации, checklist code review или правила обработки заявки. Если копировать их в каждого агента и каждый запрос, организация платит за один и тот же текст независимо от актуальности. Foundry хранит skill как именованную централизованную процедуру и делает её доступной через toolbox; новая проверенная версия может стать default без изменения кода и повторного deploy подключённых агентов.

Сначала модель видит только имя skill и короткое описание. Полная инструкция загружается, когда процедура действительно подходит к задаче. Такой progressive disclosure позволяет держать большую библиотеку подробных правил, не перегружая каждый вызов. Но централизованное обновление требует контроля версий: команда должна знать, какой вариант процедуры исполнил конкретный workflow, и уметь проверить результат после смены default.

Memory разделена на текущую, пользовательскую и процедурную

Memory in Foundry Agent Service поддерживает три класса данных. Session memory сохраняет контекст текущего разговора, user memory — устойчивые предпочтения и факты между сессиями, procedural memory — выученные способы выполнения задач. Microsoft противопоставляет это постоянной пересылке полной истории, где давно неактуальные детали продолжают занимать окно и увеличивать стоимость.

По внутренним evaluation компании включение procedural memory дало около 5% улучшения на STATE-Bench и Tau-Bench. Для организаций предусмотрены user-level isolation, retention settings и time-to-live policies. Эти параметры важны не меньше качества recall: память агента должна иметь определённого владельца, срок жизни и способ удаления, иначе экономия токенов создаст менее заметный риск накопления устаревших или избыточных данных.

Agent optimizer замыкает цикл улучшения

Microsoft связывает knowledge, tools, skills и memory в одну управляемую систему. Knowledge bases обновляются вместе с источниками, skills — с процедурами, tool search адаптируется к реально востребованным возможностям, а память удерживает полезную непрерывность. Agent optimizer in Foundry Agent Service анализирует поведение агента и предлагает улучшенные instructions, skills, descriptions инструментов и model configurations.

Это делает context engineering эксплуатационным процессом, а не разовой чисткой prompt. Практичный rollout начинается с инвентаризации того, что отправляется на каждом ходе, затем измеряет contribution каждого слоя и проверяет права доступа. Автоматически предложенная оптимизация не должна обходить review: уменьшение контекста полезно только тогда, когда сохраняются подтверждённые факты, обязательные ограничения и воспроизводимость результата.

Главный тезис публикации состоит не в выборе более дешёвой модели. Microsoft предлагает снижать повторный расход через более точную подачу знаний, динамический поиск tools, загрузку процедур по требованию и структурированную память. Для production-команды это проверяемая гипотеза: сравнивать следует полную стоимость успешной задачи, качество evidence, число ходов, latency и частоту вмешательства человека до и после изменения контекста.