9 октября 2026 г.

0 реакций

Главный Developer Advocate

Руководство для практиков по работе с агентами (AX Practitioner Playbook) — это наш метод оценки того, как ИИ-агенты для написания кода взаимодействуют с вашими технологиями, диагностики причин ошибок и их устранения у источника. Мы собрали в одном месте всё, чему научились за сотни сессий с агентами. Скачайте его по ссылке aka.ms/ax-playbook.

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

Разработчики все чаще позволяют агентам выбирать SDK, версию и шаблоны, а затем судят о вашей технологии по результату. Ожидание того, что модели станут лучше, — это не стратегия: дата отсечки знаний мало что говорит о том, что модель знает о вашем продукте. Что вы можете изменить, так это источники, на которые полагаются агенты: документацию, инструменты MCP, навыки, плагины, инструкции, CLI и API. Самое сложное — понять, какое именно изменение поможет.

От серии статей к единому методу

С осени 2025 года мы в DevRel в Microsoft измеряем, как агенты работают с Azure, Cosmos DB, SharePoint Framework (SPFx) и расширениями Microsoft 365 Copilot, используя те же типы промптов, что и реальные разработчики. Мы делились своими знаниями по частям в серии Agent Experience. Каждая статья охватывает одну часть метода. Руководство объединяет эти части в единый процесс, чтобы вы могли применить его к своим технологиям.

Что вы получите

Руководство описывает процесс оценки от настройки до внедрения исправлений.

Результаты, которые можно обосновать

Оценка может убедительно лгать. Мы видели идеальные баллы за код, который никогда не компилировался, и проверку «использована ли Platform X», которая проходила независимо от того, использовал агент Platform X или нет. Модель оценки в руководстве определяет, что необходимо для того, чтобы результату можно было доверять: от критериев, оценивающих смысл, до проверок, подтверждающих работоспособность кода.

Критерии, которые измеряют важное

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

Более короткий путь от симптома к причине

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

Исправления, которые работают

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

Примеры из реальных оценок

Каждый шаг в руководстве основан на сценариях, которые мы запускали для Cosmos DB, SPFx и других технологий. Эти оценки привели к десяткам исправлений в документации и расширениях агентов, включая 46 improvements to the Azure Cosmos DB Agent Kit. Проект обновления SPFx проходит в руководстве от начала до конца: от сценария до внедренных исправлений. Когда вы будете готовы провести собственную оценку, контрольный список качества поможет вам предварительно проверить её.

Для кого это

Руководство предназначено для всех, кто создает технологии или расширения, используемые ИИ-агентами для написания кода. Если вы создаете SDK, API, сервис, CLI, MCP-сервер, навык, плагин, набор инструкций или пишете документацию для них, вы контролируете то, что агенты обнаруживают и применяют. Если вы продвигаете технологию, а не владеете ею, вы привносите знания о сценариях для её оценки и доказательства, помогающие ответственной команде решить, что изменить.

Метод не зависит от конкретной системы оценки. Вы можете использовать ту, которую создала ваша команда, или существующую, а руководство содержит список возможностей, которые стоит проверить.

Изучайте интерактивно с навыком AX Practitioner

Вместе с PDF мы выпускаем навык AX Practitioner, чтобы вы могли изучать метод в процессе его применения. Установите его в свой агент для написания кода и задавайте вопросы во время работы над собственной оценкой, например, как сформулировать критерий или почему агент проигнорировал ваше расширение. Он также может проверить ваши сценарии и критерии на соответствие стандартам руководства.

Навык отвечает только на основе руководства. Если вопрос выходит за его рамки, навык сообщает об этом и запрашивает разрешение, прежде чем использовать любой другой источник. Из 330 вопросов его ответы получили в среднем 95% совпадения с тем, что сказано в руководстве.

Начните оценку

Скачайте руководство AX Practitioner Playbook и проведите свою первую оценку. Чтобы учиться в процессе, установите навык AX Practitioner и держите его под рукой во время работы.

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

Автор

Главный Developer Advocate

Вальдек — главный Developer Advocate в Microsoft, специализирующийся на ИИ-агентах для написания кода. Он исследует ИИ-агентов, а также оценивает и улучшает опыт взаимодействия с агентами (Agent Experience) для продуктов и сервисов Microsoft.