AI-102, AB-100 или AI-500: сравниваем траектории на практической задаче

Короткий ответ

Многоагентная архитектура встречается во всех трёх траекториях, однако глубина работы с ней различается. AI-102 был широкой инженерной сертификацией по Azure AI. AB-100 проверяет способность связать агентов с бизнес-процессами и экосистемой Microsoft. AI-500 сосредоточен на проектировании, программировании и эксплуатации многоагентных решений.

Если вы поддерживали решения по AI-102, не начинайте обучение заново. Сначала определите, куда направить существующую базу: в архитектуру корпоративных процессов — AB-100, либо в глубокую инженерную реализацию — AI-500.

Что именно различается

Главное различие проходит не по линии «мало кода — много кода». AB-100 требует технической глубины, но применяет её на уровне портфеля платформ, бизнес-ограничений и жизненного цикла решения. AI-500 требует превратить архитектурные решения в работающий, наблюдаемый и защищённый программный контур.

Матрица выбора

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

Правило выбора: AB-100 — если главным артефактом вашей работы является архитектурное решение и план изменения процесса. AI-500 — если главным артефактом является кодовая база и эксплуатационный контур многоагентной системы. Материалы AI-102 полезны как фундамент, но сам экзамен уже недоступен.

Практическая задача: маршрутизация заявки на возврат

Ниже — авторское учебное упражнение Agent Lab Journal. Это не официальный пробный экзамен Microsoft и не воспроизведение экзаменационных вопросов.

Сценарий: интернет-магазин получает заявку на возврат. Оркестратор должен передать её трём детерминированным компонентам:

1. Policy agent проверяет срок возврата и наличие подтверждения покупки.
2. Risk agent вычисляет простую оценку риска по явным правилам.
3. Decision agent объединяет результаты, но не может самостоятельно одобрить возврат дороже заданного лимита.

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

Шаг 1. Подготовьте безопасное локальное окружение

mkdir agent-readiness-lab
cd agent-readiness-lab
python3 -m venv .venv
. .venv/bin/activate
python --version

Команды создают только новый каталог и виртуальное окружение внутри него. Они не устанавливают пакеты и не обращаются к сети. Для упражнения достаточно Python 3.10 или новее.

Шаг 2. Создайте файл app.py

from dataclasses import dataclass, asdict
from datetime import date
from json import dumps
from uuid import uuid4

APPROVAL_LIMIT = 5000
ALLOWED_TOOLS = {"policy_check", "risk_check"}


@dataclass(frozen=True)
class ReturnRequest:
    request_id: str
    purchase_date: date
    amount: int
    has_receipt: bool
    previous_returns: int


def policy_check(item: ReturnRequest, today: date) -> dict:
    age_days = (today - item.purchase_date).days
    return {
        "agent": "policy",
        "eligible": 0 <= age_days <= 30 and item.has_receipt,
        "age_days": age_days,
        "reason": "within_window" if age_days <= 30 else "window_expired",
    }


def risk_check(item: ReturnRequest) -> dict:
    score = min(100, item.previous_returns * 20 + (30 if item.amount > 5000 else 0))
    return {
        "agent": "risk",
        "score": score,
        "level": "high" if score >= 70 else "normal",
    }


def call_tool(name: str, request: ReturnRequest, today: date) -> dict:
    if name not in ALLOWED_TOOLS:
        raise PermissionError(f"tool_not_allowed:{name}")
    if name == "policy_check":
        return policy_check(request, today)
    return risk_check(request)


def decide(request: ReturnRequest, policy: dict, risk: dict) -> dict:
    if not policy["eligible"]:
        return {"status": "rejected", "reason": policy["reason"]}
    if risk["level"] == "high" or request.amount > APPROVAL_LIMIT:
        return {"status": "human_review", "reason": "approval_required"}
    return {"status": "approved", "reason": "rules_passed"}


def run(request: ReturnRequest, today: date) -> dict:
    trace_id = str(uuid4())
    policy = call_tool("policy_check", request, today)
    risk = call_tool("risk_check", request, today)
    decision = decide(request, policy, risk)
    return {
        "trace_id": trace_id,
        "input": asdict(request),
        "steps": [policy, risk],
        "decision": decision,
    }


example = ReturnRequest(
    request_id="example-001",
    purchase_date=date(2026, 7, 10),
    amount=7200,
    has_receipt=True,
    previous_returns=1,
)

print(dumps(run(example, date(2026, 7, 28)), ensure_ascii=False, default=str, indent=2))

Шаг 3. Запустите сценарий

python app.py

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

Проверка результата

Идентификатор trace_id будет новым при каждом запуске. Остальная существенная часть результата должна соответствовать следующему примеру:

{
  "steps": [
    {
      "agent": "policy",
      "eligible": true,
      "age_days": 18,
      "reason": "within_window"
    },
    {
      "agent": "risk",
      "score": 50,
      "level": "normal"
    }
  ],
  "decision": {
    "status": "human_review",
    "reason": "approval_required"
  }
}

Решение human_review обязательно: сумма 7200 превышает лимит 5000. Автоматическое approved здесь означает ошибку в границе автономности.

Затем проведите три ручные проверки:

1. Установите amount=3000. Ожидается approved.
2. Установите purchase_date=date(2026, 6, 1). Ожидается rejected с причиной window_expired.
3. Временно вызовите call_tool("issue_refund", example, date(2026, 7, 28)). Ожидается исключение PermissionError.

Последняя проверка важнее красивого ответа: компонент не получает инструмент только потому, что «решил» его вызвать.

Как задача проявляет различия траекторий

Взгляд AI-102

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

Взгляд AB-100

Архитектор начнёт раньше: кому принадлежит процесс возврата, где лежат данные, можно ли расширить существующий Copilot, нужен ли Copilot Studio или custom agent, как измеряется ROI и как решение проходит ALM. Он также определит, где требуется одобрение сотрудника и какие системы Microsoft должны участвовать в процессе.

Взгляд AI-500

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

Самооценка готовности к AI-500

Упражнение показывает базовую готовность, если вы можете без подсказки расширить его следующими свойствами:

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

Если вы уверенно проектируете бизнес-владельцев, каналы, KPI и выбор платформы, но реализация пунктов выше требует команды разработчиков, ваш текущий профиль ближе к AB-100. Если легко интегрируете отдельный AI-сервис, но не проектировали оркестрацию и эксплуатационные ограничения, начните с пробелов между прежней AI-102 и AI-500.

Типовые ошибки

«Три промпта означают три агента»

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

Оркестратор знает и делает всё

Такой компонент быстро превращается в монолит. Оставьте ему маршрутизацию и правила переходов, а доменные проверки сделайте отдельными контрактами.

Текст модели считается доверенным результатом инструмента

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

Секреты помещают в код или промпт

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

Human-in-the-loop добавляют после инцидента

Граница автономности должна быть частью исходной архитектуры, особенно для финансовых, юридических и необратимых действий.

Выбирают экзамен по номеру

Большее число не означает линейно более высокий уровень. AB-100 и AI-500 проверяют разные профессиональные результаты.

Ограничения упражнения

Локальный пример проверяет декомпозицию, маршрутизацию, разрешения, трассировку и ручное одобрение. Он не доказывает готовность системы к production и не заменяет практику с Microsoft Foundry.

• Функции выполняются последовательно, без параллелизма и распределённого состояния.
• Нет реальной модели, RAG, MCP-сервера или A2A-взаимодействия.
• Нет аутентификации, сетевых границ, RBAC и хранилища секретов.
• Нет оценки недетерминированных ответов, дрейфа качества и расхода токенов.
• Нет очереди, идемпотентного хранилища, retry/backoff и восстановления после сбоя.
• Пример не моделирует правила реального магазина и не должен использоваться для обработки настоящих возвратов.

Следующий разумный этап — заменить один детерминированный компонент моделью, сохранив прежний контракт. После этого добавить структурированную валидацию ответа, тайм-аут, ограничение числа попыток и трассировку. Более общие схемы реализации собраны в разделе гайдов Agent Lab Journal.

Итог

AI-102 описывает полезную широкую базу Azure AI Engineer, но экзамен уже закрыт. AB-100 выбирайте для архитектуры AI-first бизнес-процессов в экосистеме Microsoft, включая ROI, Copilot Studio, Dynamics 365, Power Platform, ALM и governance. AI-500 выбирайте, когда ваша работа — программировать и эксплуатировать защищённые многоагентные системы с памятью, инструментами, трассировкой и контролируемым выпуском.

Практический критерий прост: если вы можете объяснить, зачем бизнесу нужен агент и где он встроен в процесс, — это сигнал в сторону AB-100. Если можете доказать, почему агент не выйдет за границы полномочий и как восстановить его работу после сбоя, — это сигнал в сторону AI-500.