Глава 17. Слой политик и каталог возможностей¶

1. Почему без слоя политик эталонная среда исполнения остается слишком наивной¶

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

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

В нашем сквозном сценарии разбора обращений поддержки это проявляется сразу после главы 16. Среда исполнения уже умеет принять запрос, собрать контекст, вызвать модель и дойти до шлюза. Но в момент, когда агент собирается открыть срочный тикет, записать сводку в память или запросить еще один внешний шаг, системе нужен не просто цикл, а явное решение о допустимости и риске.

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

Поэтому следующий обязательный слой эталонной реализации — слой политик.

Его задача не в том, чтобы “тормозить систему”. Его задача в том, чтобы решения про доступ, риск и допустимость не были размазаны по случайным if в коде.

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

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

2. Слой политик должен отвечать на маленькие и понятные вопросы¶

Слабый слой политик пытается быть “умным мозгом системы”. Сильный слой политик делает наоборот: он решает ограниченный набор ясных вопросов.

Например:

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

Когда эти вопросы оформлены явно, среда исполнения становится объяснимее, а изменения в ограничителях перестают быть хаотичными.

3. Каталог возможностей нужен не как реестр имен, а как контрактный слой¶

Очень легко скатиться к каталогу, который просто хранит список доступных инструментов. Но хороший каталог делает больше:

• описывает контракт возможности;
• хранит профиль риска;
• указывает транспорт и режим исполнения;
• задает ожидания по идемпотентности;
• фиксирует владельца и состояние жизненного цикла.

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

flowchart LR
    A["Запрос запуска"] --> B["Оркестратор среды исполнения"]
    B --> C["Слой политик"]
    B --> D["Каталог возможностей"]
    C --> E["Разрешить / запретить / запросить подтверждение"]
    D --> F["Контракт возможности"]
    E --> G["Слой исполнения"]
    F --> G

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

4. Поверхность инструментов это не то же самое, что управляемая поверхность возможностей¶

Свежие материалы OpenAI по инструментам полезны тем, что проводят различие, которое на практике размывают многие команды: модель может видеть инструменты, серверы MCP, размещенные возможности или локальные функции, но рантайм все равно должен решать, к какой поверхности управления все это относится.²

Это различие важно.

Слабая реализация говорит так:

• вот список инструментов, которые модель может вызывать.

Более сильная реализация говорит так:

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

Именно поэтому каталог возможностей должен стоять выше сырых определений инструментов. Он не дает рантайму перепутать:

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

5. Что полезно хранить в каталоге возможностей¶

Как только платформа начинает работать с MCP-подобными возможностями с состоянием, каталог уже должен описывать не только транспорт и риск, но и то, является ли возможность бессессионной, привязанной к сессии, прерываемой или возобновляемой через несколько ходов.

Из-за этого зрелый каталог часто полезно дополнить такими полями:

• режим сессии возможности: stateless / stateful;
• допускаются ли промежуточные запросы данных;
• испускаются ли события хода выполнения;
• как ведет себя истечение сессии;
• требует ли продолжение нового подтверждения или может идти под уже выданным решением;
• можно ли возможность автоматически повторно инициализировать удаленную сессию.

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

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

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

Например, контракт политики может требовать явного ответа на то, что возможность:

• безопасна внутри prompt chaining, но не внутри неограниченного цикла;
• допустима в routing только для некоторых классов запросов;
• может использоваться в parallelization только если ветки работают только на чтение;
• доступна делегированным рабочим агентам в orchestrator-workers или остается только у родительского рантайма.

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

Практически полезный набор полей обычно такой:

• имя возможности;
• владелец;
• mode: read / write / high_risk;
• transport: mcp / gateway / sandboxed_exec;
• exposure: direct / brokered / restricted;
• входная схема;
• формат выхода;
• требования к подтверждению;
• требования к идемпотентности;
• значения timeout и retry по умолчанию.

С таким контрактом рантайм уже может вести себя предсказуемо, а не подстраиваться под каждую возможность на ходу.

6. Подтверждение должно выглядеть как прерываемый путь выполнения в среде исполнения, а не как разговор в стороне¶

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

Именно такая форма нужна и системам агентов с сильным слоем политик.

Когда высокорисковая возможность доходит до границы подтверждения, рантайм должен уметь:

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

Это намного сильнее, чем просто отправить сообщение оператору и надеяться, что окружающий код все еще помнит, на чем остановился.

Полезно сразу различать две схемы подтверждения:

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

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

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

7. Решение политики должно быть объектом, а не просто логическим значением¶

Очень полезная инженерная привычка: решение политики не должно сводиться к True/False.

Чаще полезнее возвращать что-то вроде:

• allow
• deny
• approval_required
• sanitize_and_continue
• escalate

И дополнительно:

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

Это резко повышает объяснимость и делает телеметрию намного полезнее.

8. Пример контракта политики¶

Ниже очень простой, но практичный шаблон:

policy:
  run_precheck:
    require_tenant: true
    deny_if_principal_missing: true
  capabilities:
    search_docs:
      decision: allow
    create_ticket:
      decision: approval_required
      approver: manager
    run_shell:
      decision: deny
  memory_write:
    allow_kinds:
      - validated_fact
      - session_summary

Его сила не в полноте, а в явности. Ты можешь спорить с конкретным правилом и понимать, где оно применяется.

По мере того как управление с учетом проверяющего становится частью промышленной модели, такая же явность нужна и для доверия к проверяющему. Высокорисковые пути не должны зависеть от «любого доступного проверяющего». Слой политик должен уметь сказать, какие контракты проверяющего считаются доверенными, когда они обязательны и что происходит, если в путь выпуска попадает недоверенный контракт проверяющего.

9. Пример контракта каталога возможностей¶

Каталог полезно мыслить примерно так:

capabilities:
  search_docs:
    owner: knowledge_platform
    mode: read
    transport: mcp
    exposure: direct
    timeout_seconds: 5
    approval: none
  create_ticket:
    owner: support_platform
    mode: write
    transport: gateway
    exposure: brokered
    timeout_seconds: 15
    approval: manager
    idempotency_key_required: true
  run_shell:
    owner: platform_runtime
    mode: high_risk
    transport: sandboxed_exec
    exposure: restricted
    timeout_seconds: 10
    approval: always

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

10. Структурированные ответы важны потому, что контракты должны переживать встречу с кодом¶

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

Именно поэтому артефакты политик все чаще стоит делать структурно явными по таким полям, как:

• capability_session_id;
• capability_session_mode;
• resume_policy;
• on_session_expiry;
• progress_event_policy;
• elicitation_policy.

Эти поля помогают держать контроль подтверждений и контроль сессий возможностей в одной модели, а не давать им расползаться в две разные неявные системы.

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

• approval_mode
• approval_delegate
• classifier_verdict
• escalate_to_human_if
• subagent_handoff_policy

Такие поля помогают делать путь делегированного подтверждения явным, а не прятать его в продуктовую логику или поведение интерфейса.

Та же дисциплина нужна и для делегированных рабочих агентов. Если рантайм поддерживает путь orchestrator-workers, слой политик должен уметь явно сказать:

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

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

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

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

Эталонный рантайм теперь несет эти предположения прямо в артефактах исполнения: run_start, approval_requested, tool_execution, run_complete, записи подтверждений и экспорт сессии могут сохранять один и тот же контекст делегированной авторизации. Это важно, потому что поэтапный выпуск и расследование не должны восстанавливать делегированную идентичность по побочным следам.

Свежий материал OpenAI по структурированным ответам полезен и для слоя политик.⁴

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

Поэтому системам с сильным слоем политик полезно делать структурно явными такие артефакты:

• решения политик;
• запросы подтверждения;
• результаты подтверждений;
• входы и выходы возможностей.

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

11. Простой кодовый каркас решения политики¶

Ниже каркас, который показывает, что рантайм получает не просто разрешение, а структурированное решение.

from dataclasses import dataclass


@dataclass
class PolicyDecision:
    action: str
    reason: str
    policy_id: str
    approval_mode: str = "human"
    escalate_to_human: bool = False
    requires_approval: bool = False


def evaluate_capability(name: str) -> PolicyDecision:
    if name == "search_docs":
        return PolicyDecision(action="allow", reason="low_risk_read", policy_id="cap_001")
    if name == "create_ticket":
        return PolicyDecision(action="approval_required", reason="write_action", policy_id="cap_014", requires_approval=True)
    return PolicyDecision(action="deny", reason="unsupported_capability", policy_id="cap_999")

Даже такой простой код уже задает правильную форму для телеметрии, потоков подтверждения в интерфейсе и расследований.

12. Простой кодовый каркас поиска возможности¶

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

from dataclasses import dataclass


@dataclass
class CapabilitySpec:
    name: str
    mode: str
    transport: str
    exposure: str
    timeout_seconds: int


def get_capability(name: str) -> CapabilitySpec | None:
    registry = {
        "search_docs": CapabilitySpec("search_docs", "read", "mcp", "direct", 5),
        "create_ticket": CapabilitySpec("create_ticket", "write", "gateway", "brokered", 15),
    }
    return registry.get(name)

Это скучный слой. И это хорошо. Слой каталога как раз и должен быть стабильным и обозримым.

13. Частые ошибки¶

Проблемы здесь очень типовые:

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

Когда это происходит, эталонная реализация перестает быть опорой и снова превращается в связку договоренностей.

14. Быстрый тест зрелости для слоя политик и каталога возможностей¶

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

Более сильная планка такая:

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

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

15. Что сделать сразу¶

Сначала пройди по короткому списку и отдельно отметь все ответы «нет»:

• Есть ли у тебя отдельный слой политик, а не набор if по коду?
• Возвращает ли политика структурированное решение?
• Есть ли единый каталог возможностей?
• Есть ли у возможностей владелец, транспорт, экспозиция и семантика риска?
• Использует ли рантайм каталог, а не прямые вызовы?
• Может ли подтверждение явно поставить запуск на паузу и продолжить его?
• Видны ли решения политик в телеметрии?

Если на несколько вопросов подряд ответ “нет”, каркас у тебя уже есть, но контрактное ядро пока еще не собрано.

16. Что делать дальше¶

Сначала сделай решения политик и контракты возможностей явными, а потом проверь, готова ли эта же система к первому поэтапному выпуску.

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

• Глава 16. Базовая схема среды исполнения
• Глава 18. Чеклист промышленного запуска
• Часть VII. Эталонная реализация
• Источники

17. Полезные справочные страницы¶

• Схема набора политик и контракта подтверждения
• Схема артефактов жизненного цикла
• Эталонный пакет

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

• Глава 16. Базовая схема среды исполнения
• Глава 18. Чеклист промышленного запуска
• Часть VII. Эталонная реализация
• Источники