Глава 14. Платформенная команда и продуктовые команды¶

1. Почему агентная платформа почти всегда ломается не на коде, а на модели владения¶

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

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

Проблемы начинаются позже:

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

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

2. Платформенная команда не должна забирать у продуктов все решения¶

Есть плохая крайность: платформенная команда пытается стать единственной точкой принятия любых решений об агентах.

Тогда получается:

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

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

3. И обратная крайность тоже плохая: полный федерализм¶

Иногда компании идут в другую сторону: “пусть каждая команда сама решает, как ей строить агентов”.

Это быстро дает:

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

На короткой дистанции это выглядит как свобода. На длинной это почти всегда зоопарк.

4. Зрелая модель обычно выглядит как разделение платформы и продуктов¶

Хорошая операционная модель обычно делит ответственность примерно так:

платформенная команда отвечает за:

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

продуктовые команды отвечают за:

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

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

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

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

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

Золотой путь обычно включает:

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

То есть хороший платформенный продукт помогает не только “мочь”, но и “делать правильно по умолчанию”.

6. Владение должно быть явным на каждом слое¶

Очень полезно заранее разложить, кто владеет чем:

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

Если владение размыто, почти любой инцидент превращается в длинный организационный пинг-понг.

6.1. Инвентарь платформы тоже должен иметь владельца¶

Полезная мысль из Google здесь в том, что управление не заканчивается каркасом политик. У платформы должен быть еще и явный инвентарь того, чем организация вообще пользуется.¹²

Минимально полезно видеть хотя бы:

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

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

7. Не все отклонения от платформы нужно запрещать, но их нужно делать осознанными¶

Иногда продуктовой команде правда нужен особый случай:

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

Это нормально. Но разница между зрелой платформой и хаосом в том, что отклонение:

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

8. Пример политики управления для агентной платформы¶

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

governance:
  platform_owned:
    - runtime_contracts
    - policy_framework
    - telemetry_schema
    - shared_tool_gateway
  product_owned:
    - workflow_logic
    - domain_prompts
    - task_success_criteria
  requires_platform_review:
    - new_write_capability
    - custom_policy_engine
    - telemetry_schema_change
    - direct_external_tool_access

Такой YAML не решает все организационные проблемы, но он очень хорошо снимает вечный вопрос “а кто вообще это должен решать?”.

8.1. Утвержденный реестр полезен не меньше, чем схема политики¶

Очень часто команды хорошо обсуждают политику, но почти не обсуждают реестр. А именно реестр отвечает на вопрос:

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

Простой пример:

registry:
  approved_runtimes:
    - agent_runtime_v3
    - workflow_runtime_v2
  approved_gateways:
    - shared_tool_gateway
    - approval_gateway
  deprecated_patterns:
    - direct_prod_tool_access
    - local_policy_engine_without_audit

Такой реестр не заменяет управление. Он делает управление исполнимым.

9. Платформа должна измеряться не числом функций, а снижением хаоса¶

Очень важно не попадать в ловушку показных метрик вроде:

• сколько инструментов добавили;
• сколько MCP-серверов подняли;
• сколько продуктовых команд “подключились”.

Сильная платформа должна уменьшать:

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

Иначе ты можешь много строить, но не становиться системно лучше.

9.1. Непрерывные проверки лучше разовых ревью¶

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

Например, система может автоматически проверять:

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

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

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

Обычно проблемы повторяются:

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

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

11. Быстрый тест зрелости для операционной модели платформы¶

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

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

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

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

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

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

• Ясно ли, что именно во владении платформенной команды?
• Ясно ли, что остается за продуктовыми командами?
• Есть ли золотой путь, а не только “набор возможностей”?
• Понятно ли, кто утверждает новые рискованные возможности?
• Есть ли процесс для отклонений от стандартного пути?
• Уменьшает ли платформа реально число локальных реализаций рантайма?

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

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

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

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

• Глава 13. Офлайн-оценки, онлайн-оценки и регрессионные шлюзы
• Глава 15. Золотые пути, общие шлюзы и антизоопарк-подходы
• Часть VI. Организационная модель
• Источники