Глава 15. Золотые пути, общие шлюзы и антизоопарк-подходы¶

1. Почему даже хорошая орг-модель без инженерных шаблонов быстро расползается¶

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

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

Если ответа нет, происходит знакомый сценарий:

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

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

2. Золотой путь это не “документ с набором советов”, а рабочий путь по умолчанию¶

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

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

Обычно он включает:

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

То есть золотой путь хорош тогда, когда команде выгодно оставаться на нем.

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

2.1. Практикум: минимальный золотой путь для пишущего агента¶

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

golden_path:
  name: support_write_agent
  runtime:
    template: governed_workflow_agent
    required_trace_schema: standard_trace_schema_v1
    required_session_model: session_id_per_user_workflow
  tool_gateway:
    required:
      - capability_contract
      - idempotency_key
      - tool_policy_decision
      - high_risk_approval_path
  observability:
    required_events:
      - run_start
      - policy_precheck
      - tool_policy_decision
      - approval_requested
      - tool_execution
      - verification_result
      - run_complete
  evals:
    required_gates:
      - duplicate_ticket_after_timeout
      - missing_idempotency_key
      - unsafe_direct_tool_access
  rollout:
    default_mode: staged_canary
    expansion_requires:
      - offline_eval_passed
      - online_slo_within_budget
      - no_open_side_effect_unknown_incidents

Важная деталь: это не пример “идеальной платформы”. Это минимальный contract surface, который не дает продуктовой команде случайно обойти самые дорогие решения из предыдущих глав.

У хорошего золотого пути есть три свойства:

1. Он исполняемый. В нем есть шаблон рантайма, gateway hooks, eval hooks и rollout defaults, а не только текстовые рекомендации.
2. Он ограничивает риск по умолчанию. Пишущая capability не может появиться без idempotency, policy decision и трассы.
3. Он остается расширяемым. Продукт может менять workflow logic и task success criteria, но не переписывает общий слой доказательств.

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

3. Общие шлюзы нужны, чтобы не размножать критичные ошибки по всей организации¶

Есть несколько слоев, которые особенно опасно оставлять на локальную импровизацию:

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

Если каждая команда реализует их сама, организация почти гарантированно размножит одни и те же ошибки в пяти версиях.

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

3.1. Commercial control-plane convergence¶

Коммерческие платформы в 2026 году сходятся к одному и тому же паттерну: shared AI gateway перестает быть только proxy к моделям и становится рабочей поверхностью control plane. AWS AgentCore AgentOps делает видимыми traces, latency, token and cost accounting, PII redaction и governance signals; Cloudflare AI Gateway for coding agents добавляет единый путь для client routing, caching, limits и provider mediation; Microsoft Foundry observability связывает agent traces, quality signals и operational views.¹²³

Для антизоопарк-стратегии вывод прямой: model/provider routing, cache policy, rate limits, DLP/redaction, retry/fallback policy и cost attribution должны жить в общей платформенной поверхности, а не в локальной обвязке каждого агента. Иначе организация получает новый зоопарк: одни команды используют gateway как billing proxy, другие как observability hook, третьи как policy point, и ни один контур не видит полный risk/cost path.

flowchart LR
    A["Продуктовая команда A"] --> D["Общий шлюз и платформенные примитивы"]
    B["Продуктовая команда B"] --> D
    C["Продуктовая команда C"] --> D
    D --> E["Политики, трассировка, подтверждения, доступ к возможностям"]

4. Переиспользуемый шаблон должен задавать позицию, а не быть абстрактным¶

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

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

Хороший шаблон обычно задает явную позицию:

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

Да, это менее “универсально”. Но это гораздо полезнее для реальной организации.

5. Не нужно пытаться сделать один золотой путь для всех типов агентов¶

Здесь тоже важна зрелость. Один путь редко одинаково хорош для:

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

Поэтому практический подход обычно такой:

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

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

6. Антизоопарк-подход начинается с ограничения свободы в правильных местах¶

Полезно также явно разделять уровни сложности в реестре: direct_model_call, single_agent_with_tools, multiagent_orchestration. Такой реестр не дает команде начинать с многоагентной схемы просто потому, что это выглядит современнее. Для каждого утвержденного шаблона среды исполнения стоит хранить не только пример кода, но и причину допуска: профиль задержки, лимит стоимости, границу безопасности, требования к трассировке, покрытие оценками и владельца. Если команда хочет sequential, concurrent, group_chat, handoff или magentic orchestration, это уже не просто “вариант реализации”, а проверяемый выбор контроля среды исполнения.

Термин “зоопарк платформ” обычно означает одно и то же:

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

Уменьшать этот зоопарк полезно не через запреты на все подряд, а через ясные ограничения:

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

6.1. Реестр утвержденных шаблонов нужен не только для контроля, но и для скорости¶

Когда у платформы есть живой список утвержденных шаблонов, продуктовым командам проще отвечать на два самых частых вопроса:

1. Что можно брать без отдельного согласования?
2. Что уже считается рискованным отклонением?

В хороший реестр обычно входят:

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

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

7. Пример политики платформенных настроек по умолчанию¶

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

platform_defaults:
  required:
    - shared_tool_gateway
    - standard_trace_schema
    - policy_hooks
    - eval_gate_in_ci
  supported_templates:
    - direct_model_call
    - single_agent_with_tools
    - workflow_agent
    - approval_agent
  approved_orchestration_patterns:
    - sequential
    - concurrent
    - controlled_handoff
  deviations_require_review:
    - custom_runtime
    - direct_tool_access
    - group_chat_orchestration
    - magentic_orchestration
    - custom_telemetry_schema
    - bypass_of_policy_layer

Такая политика не убивает скорость. Она убирает неявность.

7.1. Реестр и политика вывода из эксплуатации должны жить вместе¶

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

Гораздо взрослее работает связка:

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

Именно она не дает антизоопарк-работе превратиться в бесконечную просьбу “ну пожалуйста, используйте стандартный путь”.

8. Общие шлюзы хороши не только для безопасности, но и для скорости эволюции¶

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

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

То есть общий шлюз — это не только контроль. Это еще и масштабируемость инженерных улучшений.

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

Здесь тоже много типовых ошибок:

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

Тогда организация формально говорит о стандартизации, а фактически просто производит новые варианты старого хаоса.

10. Что стоит измерять, если ты правда борешься с зоопарком¶

Полезные операционные метрики здесь такие:

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

Это намного полезнее, чем просто считать “сколько команд используют платформу”.

10.1. Дрейф инвентаря сам по себе полезно считать¶

Отдельно полезно смотреть на дрейф в инвентаре платформы:

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

Если эти числа растут, антизоопарк-стратегия формально существует, но на практике уже проигрывает.

11. Быстрый тест зрелости для золотых путей и антизоопарк-подходов¶

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

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

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

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

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

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

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

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

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

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

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

• Глава 14. Платформенная команда и продуктовые команды
• Глава 16. Базовая схема среды исполнения
• Часть VI. Организационная модель
• Источники