Microsoft написала 968 страниц про ИИ-агентов. Главный совет: не используйте агентов

К концу сентября 2026 года документация фреймворка Microsoft для ИИ-агентов, Agent Framework, разрослась до 968 страниц, и большая часть из них код. Но между строками кода записано, как одна из крупнейших технологических компаний мира на самом деле видит агентов: не как волшебство, а как производство со сменами, журналами и техникой безопасности.

Agent Framework заменил два прежних проекта Microsoft, Semantic Kernel и AutoGen, и его делали те же команды. Один проект давал простые заготовки для агентов, другой корпоративную надёжность. Новый соединил их и добавил главное: явные маршруты работы и память о состоянии, которая переживает перезапуск и умеет ждать человека.

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

Смысл первый: лучший агент тот, который не понадобился#

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

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

Путь разработчика в документации построен как лестница из восьми ступеней:

1. агент с инструкциями;
2. инструменты;
3. навыки;
4. промежуточные слои контроля;
5. память;
6. агенты внутри агентов;
7. связь агентов разных компаний;
8. сценарии с жёстким порядком шагов.

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

Смысл второй: решите, кто выбирает следующий шаг#

Главный вопрос всей документации: кто решает, что происходит дальше, модель или разработчик. Агент с инструментами сам выбирает, что вызвать, кому поручить подзадачу и когда остановиться. Это гибко, но непредсказуемо.

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

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

Это и есть ответ на страх, что ИИ всё сломает. Разумность можно дозировать: на каждом шаге решить, думает ли модель, считает ли код или подписывает человек.

Смысл третий: побеждает не модель, а обвязка#

В документации есть фраза, которая объясняет половину рынка: современные агенты часто упираются не в качество модели, а в накладные расходы на организацию работы. Поэтому Microsoft сделала обвязку (по-английски harness): готовый каркас, который превращает языковую модель в работника для долгих многошаговых задач.

Что входит в обвязку по умолчанию:

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

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

Навыки устроены так же экономно. Агент видит только короткое описание каждого навыка, около 100 токенов, и грузит полную инструкцию, когда она нужна. Токеном называют кусочек слова: в токенах считают и память модели, и цену её работы. Десять навыков стоят примерно 1 000 токенов, а не 50 000.

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

Смысл четвёртый: подпись человека зашита в механику#

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

1. он меняет данные, отправляет письма или тратит деньги;
2. он работает с чувствительными данными: личными, финансовыми, паролями;
3. его действие нельзя отменить, как удаление или отправку письма;
4. он затрагивает сразу много объектов.

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

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

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

Смысл пятый: модели нельзя доверять, и это записано в инструкции#

Самый трезвый раздел документации посвящён безопасности. Его первая мысль: за безопасность агента отвечает тот, кто его строит, а не Microsoft. Фреймворк даёт детали, но проверять входящие данные, защищать их путь и настраивать инструменты должен разработчик.

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

Это не теория. Документ, найденный поиском по базе знаний, может содержать скрытую инструкцию, и модель её выполнит. Документация напоминает, что такую подмену инструкций считают главным риском для языковых моделей, и честно признаёт: защитная фраза в инструкции и самописный список разрешённого гарантии не дают. Они молча ломаются в тот день, когда в письме или задаче появляется строка [SYSTEM OVERRIDE].

Поэтому Microsoft добавляет жёсткие механизмы:

• метки на данных: доверенные или нет, открытые или личные; метки идут вместе с данными через все вызовы, и опасный инструмент не запустится от недоверенных данных (пока эксперимент и только для Python);
• перехватчики, которые выносят вердикт до действия, а в рабочем режиме при сбое блокируют его (пока только для Python);
• встроенная оценка качества: ответы проверяет другая модель-судья, а каждый вопрос можно прогнать несколько раз, чтобы поймать непостоянство.

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

Смысл шестой: модель стала сменной деталью#

Фреймворк Microsoft одинаково работает с моделями самой Microsoft, OpenAI, Anthropic, Google, Amazon, Mistral и с открытыми моделями, которые можно запустить у себя. Документация обещает, что поставщика модели можно поменять, не переписывая приложение. В некоторых случаях модель можно сменить даже посреди разговора без потери контекста.

Вокруг модели Microsoft строит открытые стандарты, а не закрытый забор:

• MCP, общий протокол, через который любые программы дают агентам свои инструменты;
• A2A, протокол, по которому агенты разных команд и компаний находят друг друга и договариваются, на чём бы они ни были написаны; документация называет его аналогом HTTP для агентов;
• навыки по открытой спецификации, которые переносятся между агентами, командами и даже продуктами;
• единый формат журналов и метрик для языковых моделей.

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

Что это значит для бизнеса и людей#

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

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

• без инструментов агент только собеседник, с инструментами он исполнитель, поэтому начинать стоит с одного-двух действительно нужных действий;
• лишние инструменты вредят: каждый съедает память модели, а из десятков вариантов она выбирает хуже, чем из нескольких хорошо описанных;
• когда у одного агента слишком много ролей, его стоит разделить на узких специалистов, а простые задачи отдать маленьким дешёвым моделям;
• лишний контекст не просто стоит денег, он ухудшает ответы;
• считать модель не должна: пусть она напишет код, который посчитает точно, но результат всё равно проверяет человек.

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

Вывод#

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