Как мы построили свой AI-стек: 20 млн запросов, 241 млрд токенов и один мощный инструмент

За последние 30 дней 93% исследовательского подразделения Cloudflare использовали инструменты ИИ для написания кода, работающие на инфраструктуре, которую мы построили на нашей собственной платформе.

Одиннадцать месяцев назад мы начали крупный проект: по-настоящему интегрировать ИИ в наш инженерный стек. Нам нужно было построить внутренние MCP-серверы, слой доступа и инструменты ИИ, необходимые для того, чтобы агенты стали полезными в Cloudflare. Мы собрали инженеров со всей компании, чтобы сформировать специальную группу iMARS (Internal MCP Agent/Server Rollout Squad). Последующая работа перешла к команде Dev Productivity, которая также отвечает за многие наши внутренние инструменты, включая CI/CD, системы сборки и автоматизацию.

Вот некоторые цифры, отражающие наше собственное использование агентного ИИ за последние 30 дней:

• 3 683 внутренних пользователя активно используют инструменты ИИ для написания кода (60% по всей компании, 93% в R&D) при общем числе сотрудников около 6 100 человек

• 47,95 миллиона запросов к ИИ

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

• 20,18 миллиона запросов в месяц через AI Gateway

• 241,37 миллиарда токенов, направленных через AI Gateway

• 51,83 миллиарда токенов обработано на Workers AI

Влияние на внутреннюю скорость разработки очевидно: мы никогда не видели такого квартального роста количества запросов на слияние (merge requests).

По мере роста внедрения инструментов ИИ скользящее среднее за 4 недели выросло с ~5 600/неделю до более чем 8 700. На неделе 23 марта был достигнут показатель в 10 952, что почти вдвое превышает базовый уровень четвертого квартала.

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

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

Слой инструментов для инженеров (OpenCode, Windsurf и другие MCP-совместимые клиенты) включает как инструменты с открытым исходным кодом, так и сторонние ассистенты для написания кода.

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

Ни одна из этих систем не является исключительно внутренней инфраструктурой. Все перечисленное выше (кроме Backstage) — это поставляемые продукты, и многие из них получили существенные обновления во время Недели агентов.

Мы пройдемся по этому в трех актах:

1. Платформенный слой — как работают аутентификация, маршрутизация и инференс (AI Gateway, Workers AI, MCP Portal, Code Mode)

2. Слой знаний — как агенты понимают наши системы (Backstage, AGENTS.md)

3. Слой контроля — как мы поддерживаем высокое качество в масштабе (AI Code Reviewer, Engineering Codex)

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

Все начинается с Cloudflare Access, который обрабатывает всю аутентификацию и применение политик нулевого доверия. После аутентификации каждый запрос к LLM маршрутизируется через AI Gateway. Это дает нам единое место для управления ключами провайдеров, отслеживания затрат и политиками хранения данных.

^{Обзор AI Gateway для OpenCode: 688,46 тыс. запросов в день, 10,57 млрд токенов в день, маршрутизация к четырем провайдерам через одну конечную точку.}

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

Передовые (frontier) модели пока обрабатывают основную часть сложной агентной работы по написанию кода, но Workers AI уже составляет значительную часть и обрабатывает растущую долю наших агентных инженерных нагрузок.

Workers AI — это бессерверная платформа для инференса ИИ от Cloudflare, которая запускает модели с открытым исходным кодом на GPU в нашей глобальной сети. Помимо значительного снижения затрат по сравнению с передовыми моделями, ключевое преимущество заключается в том, что инференс остается в той же сети, что и ваши Workers, Durable Objects и хранилища. Нет необходимости иметь дело с переходами между облаками, которые вызывают большую задержку, нестабильность сети и дополнительные настройки сети.

^{Использование Workers AI за последний месяц: 51,47 млрд входных токенов, 361,12 млн выходных токенов.}

Kimi K2.5, запущенная на Workers AI в марте 2026 года, — это модель с открытым исходным кодом уровня frontier с контекстным окном 256k, вызовом инструментов и структурированными выводами. Как мы описывали в посте о запуске Kimi K2.5, у нас есть security-агент, который обрабатывает более 7 миллиардов токенов в день на Kimi. Это стоило бы примерно 2,4 млн долларов в год на модели среднего уровня от коммерческого провайдера. Но на Workers AI это на 77% дешевле.

Помимо безопасности, мы используем Workers AI для ревью документации в нашем CI-конвейере, для генерации контекстных файлов AGENTS.md в тысячах репозиториев и для легковесных задач инференса, где задержка в пределах одной сети важнее, чем пиковые возможности модели.

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

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

Вся настройка начинается с одной команды:

opencode auth login https://opencode.internal.domain

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

Шаг 1: Обнаружение требований аутентификации. OpenCode получает конфигурацию по URL, например https://opencode.internal.domain/.well-known/opencode.

Эта конечная точка обнаружения обслуживается Worker'ом, и её ответ содержит блок auth, который сообщает OpenCode, как проходить аутентификацию, а также блок config с провайдерами, MCP-серверами, агентами, командами и правами доступа по умолчанию:

{
  "auth": {
    "command": ["cloudflared", "access", "login", "..."],
    "env": "TOKEN"
  },
  "config": {
    "provider": { "..." },
    "mcp": { "..." },
    "agent": { "..." },
    "command": { "..." },
    "permission": { "..." }
  }
}

Шаг 2: Аутентификация через Cloudflare Access. OpenCode выполняет команду аутентификации, и пользователь проходит аутентификацию через тот же SSO, который он использует для всего остального в Cloudflare. cloudflared возвращает подписанный JWT. OpenCode сохраняет его локально и автоматически добавляет к каждому последующему запросу к провайдеру.

Шаг 3: Конфигурация объединяется с OpenCode. Предоставленная конфигурация является общими настройками по умолчанию для всей организации, но локальные конфигурации всегда имеют приоритет. Пользователи могут переопределить модель по умолчанию, добавить своих агентов или настроить разрешения на уровне проекта и пользователя, не затрагивая остальных.

Внутри прокси-воркера. Worker — это простое приложение Hono, которое выполняет три задачи:

1. Обслуживает общую конфигурацию. Конфигурация компилируется во время развёртывания из структурированных исходных файлов и содержит значения-заполнители, такие как {baseURL} для источника Worker'а. Во время запроса Worker заменяет их, поэтому все запросы к провайдерам маршрутизируются через Worker, а не напрямую к провайдерам моделей. Каждый провайдер получает префикс пути (/anthropic, /openai, /google-ai-studio/v1beta, /compat для Workers AI), который Worker перенаправляет на соответствующий маршрут AI Gateway.

2. Проксирует запросы к AI Gateway. Когда OpenCode отправляет запрос, например POST /anthropic/v1/messages, Worker проверяет JWT Cloudflare Access, затем переписывает заголовки перед перенаправлением:

   Удалены:   authorization, cf-access-token, host
   Добавлены: cf-aig-authorization: Bearer <API_KEY>
               cf-aig-metadata: {"userId": "<anonymous-uuid>"}
   

   Запрос отправляется в AI Gateway, который маршрутизирует его соответствующему провайдеру. Ответ проходит напрямую без буферизации. Поле apiKey в клиентской конфигурации пустое, потому что Worker внедряет настоящий ключ на стороне сервера. На машинах пользователей нет API-ключей.

3. Поддерживает каталог моделей в актуальном состоянии. Ежечасный триггер cron получает текущий список моделей OpenAI с models.dev, кэширует его в Workers KV и добавляет store: false для каждой модели, чтобы обеспечить Zero Data Retention. Новые модели автоматически получают ZDR без переразвёртывания конфигурации.

Анонимный учёт пользователей. После проверки JWT Worker сопоставляет email пользователя с UUID, используя D1 для постоянного хранения и KV для кэша чтения. AI Gateway видит только анонимный UUID в cf-aig-metadata, но никогда email. Это позволяет нам отслеживать затраты на пользователя и анализировать использование, не раскрывая личность провайдерам моделей или логам Gateway.

Конфигурация как код. Агенты и команды создаются как файлы Markdown с YAML-преамбулой. Скрипт сборки компилирует их в единый JSON-конфиг, который проверяется по JSON-схеме OpenCode. Каждая новая сессия автоматически получает последнюю версию.

Общая архитектура проста и её легко развернуть на нашей платформе для разработчиков: прокси-воркер, Cloudflare Access, AI Gateway и конечная точка обнаружения, доступная клиенту, которая автоматически всё настраивает. Пользователи выполняют одну команду, и всё готово. Им не нужно ничего настраивать вручную, нет API-ключей на ноутбуках или подключений к MCP-серверам, которые нужно устанавливать вручную. Внесение изменений в наши агентские инструменты и обновление того, что получают 3000+ человек в своей среде разработки, — это всего лишь wrangler deploy.

Мы описали наш полный подход к управлению MCP в масштабе предприятия в отдельном посте, включая то, как мы используем Порталы MCP-серверов, Cloudflare Access и Code Mode вместе. Вот краткая версия того, что мы построили внутри компании.

Наш внутренний портал объединяет 13 рабочих MCP-серверов, предоставляющих доступ к 182+ инструментам в Backstage, GitLab, Jira, Sentry, Elasticsearch, Prometheus, Google Workspace, нашем внутреннем Release Manager и других. Это унифицирует доступ и упрощает всё, давая нам одну конечную точку и один поток Cloudflare Access, управляющий доступом к каждому инструменту.

Каждый MCP-сервер построен на одной основе: McpAgent из Agents SDK, workers-oauth-provider для OAuth и Cloudflare Access для идентификации. Всё это находится в едином монорепозитории с общей инфраструктурой аутентификации, сборкой Bazel, CI/CD-пайплайнами и catalog-info.yaml для регистрации в Backstage. Добавление нового сервера в основном сводится к копированию существующего и изменению API, который он оборачивает. Подробнее о том, как это работает, и о лежащей в основе архитектуре безопасности читайте в нашей эталонной архитектуре MCP для предприятий.

MCP — это правильный протокол для подключения AI-агентов к инструментам, но у него есть практическая проблема: каждое определение инструмента потребляет токены контекстного окна ещё до того, как модель начнёт работу. По мере роста числа MCP-серверов и инструментов растёт и служебная нагрузка на токены, что в масштабе становится реальной стоимостью. Code Mode — это emerging-решение: вместо того чтобы загружать все схемы инструментов заранее, модель обнаруживает и вызывает инструменты через код.

Наш MCP-сервер для GitLab изначально предоставлял 34 отдельных инструмента (get_merge_request, list_pipelines, get_file_content и так далее). Эти 34 схемы инструментов потребляли примерно 15 000 токенов контекстного окна на запрос. Для окна в 200K токенов это 7,5% бюджета, потраченные ещё до задания вопроса. Умножьте это на каждый запрос, каждого инженера, каждый день — сумма накапливается.

Порталы MCP-серверов теперь поддерживают проксирование Code Mode, что позволяет нам решить эту проблему централизованно, а не на каждом сервере по отдельности. Вместо того чтобы предоставлять клиенту все определения инструментов из вышестоящих источников, портал сводит их к двум инструментам на уровне портала: portal_codemode_search и portal_codemode_execute.

Приятно то, что реализация этого на уровне портала масштабируется чисто. Без Code Mode каждый новый MCP-сервер добавляет служебных данных схемы к каждому запросу. С Code Mode на уровне портала клиент по-прежнему видит только два инструмента, даже когда мы подключаем за порталом больше серверов. Это означает меньше раздувания контекста, меньшую стоимость токенов и в целом более чистую архитектуру.

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

Мы используем Backstage, портал для внутренних разработчиков с открытым исходным кодом, изначально созданный Spotify, в качестве нашего каталога сервисов. Он размещается самостоятельно (не на продуктах Cloudflare, для ясности) и отслеживает такие вещи, как:

• 2055 сервисов, 167 библиотек и 122 пакета

• 228 API с определениями схем

• 544 системы (продукта) в 45 доменах

• 1302 базы данных, 277 таблиц ClickHouse, 173 кластера

• 375 команд и 6389 пользователей с сопоставлением владения

• Графы зависимостей, связывающие сервисы с базами данных, топиками Kafka и облачными ресурсами, от которых они зависят

Наш MCP-сервер для Backstage (13 инструментов) доступен через наш MCP-портал, и агент может узнать, кто владеет сервисом, проверить его зависимости, найти связанные спецификации API и получить оценки Tech Insights, не выходя из сессии кодирования.

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

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

Мы построили систему, которая генерирует файлы AGENTS.md во всем нашем экземпляре GitLab. Поскольку эти файлы находятся прямо в контекстном окне модели, мы хотели, чтобы они оставались короткими и информативными. Типичный файл выглядит так:

# AGENTS.md

## Репозиторий
- Среда выполнения: Cloudflare Workers
- Команда для тестов: `pnpm test`
- Команда для линтинга: `pnpm lint`

## Навигация по кодовой базе
- Все Cloudflare Workers находятся в src/workers/, по одному файлу на воркер
- Определения MCP-серверов находятся в src/mcp/, каждый инструмент в отдельном файле
- Тесты зеркалируют исходный код: src/foo.ts -> tests/foo.test.ts

## Соглашения
- Тестирование: используем Vitest с `@cloudflare/vitest-pool-workers` (Codex: RFC 021, RFC 042)
- Паттерны API: следуем внутренним REST-соглашениям (Codex: API-REST-01)

## Границы
- Не редактировать сгенерированные файлы в `gen/`
- Не вводить новые фоновые задачи без обновления `config/`

## Зависимости
- Зависит от: auth-service, config-service
- Используется в: api-gateway, dashboard

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

Конвейер генератора извлекает метаданные сущностей из нашего сервисного каталога Backstage (владелец, зависимости, системные взаимосвязи), анализирует структуру репозитория, чтобы определить язык, систему сборки, фреймворк тестирования и расположение каталогов, а затем сопоставляет обнаруженный стек с соответствующими стандартами Engineering Codex. Затем мощная модель генерирует структурированный документ, и система открывает запрос на слияние (merge request), чтобы команда-владелец могла его проверить и доработать.

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

Начальный запрос на слияние решил проблему начальной настройки, но поддержание актуальности этих файлов было не менее важно. Устаревший AGENTS.md может быть хуже, чем полное его отсутствие. Мы замкнули этот цикл с помощью AI Code Reviewer (ИИ-ревьювера кода), который может отмечать, когда изменения в репозитории предполагают, что AGENTS.md следует обновить.

Каждый запрос на слияние (merge request) в Cloudflare проходит проверку кодом с помощью ИИ. Интеграция проста: команды добавляют один CI-компонент в свой конвейер, и с этого момента каждый MR проверяется автоматически.

Мы используем локальное решение GitLab в качестве нашей CI/CD-платформы. Ревьювер реализован как компонент GitLab CI, который команды включают в свой конвейер. Когда MR создается или обновляется, CI-задание запускает OpenCode с мультиагентным координатором проверки. Координатор классифицирует MR по уровню риска (тривиальный, лёгкий или полный) и делегирует задачи специализированным агентам проверки: качество кода, безопасность, соответствие Codex, документация, производительность и влияние на релиз. Каждый агент подключается к AI Gateway для доступа к моделям, извлекает правила Engineering Codex из центрального репозитория и читает AGENTS.md репозитория для получения контекста кодовой базы. Результаты публикуются в виде структурированных комментариев к MR.

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

Мы потратили время на отладку правильного формата вывода. Отзывы разбиты по категориям (Безопасность, Качество кода, Производительность), чтобы инженеры могли просматривать заголовки, а не читать сплошной текст. Каждая находка имеет уровень серьёзности (Критичный, Важный, Предложение или Мелкие замечания), что сразу даёт понять, на что нужно обратить внимание, а что носит информационный характер.

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

Workers AI обрабатывает около 15% трафика ревьювера, в основном для задач проверки документации, где Kimi K2.5 показывает хорошие результаты при гораздо меньшей стоимости по сравнению с передовыми моделями. Такие модели, как Opus 4.6 и GPT 5.4, справляются с проверками, чувствительными к безопасности и архитектурно сложными, где наиболее важны рассуждения.

За последние 30 дней:

• 100% охват AI code reviewer во всех репозиториях в нашем стандартном CI-конвейере.

• 5.47 млн запросов к AI Gateway

• Обработано 24.77 млрд токенов

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

Engineering Codex — это новая внутренняя система стандартов Cloudflare, где живут наши основные инженерные стандарты. У нас есть многоэтапный процесс дистилляции с помощью ИИ, который выдаёт набор правил Codex ("Если вам нужно X, используйте Y. Вы должны делать X, если вы делаете Y или Z.") вместе с навыком агента, использующим прогрессивное раскрытие информации, вложенные иерархические информационные каталоги и ссылки между markdown-файлами.

Этот навык доступен инженерам для локального использования при разработке с помощью промптов типа «как я должен обрабатывать ошибки в моем Rust-сервисе?» или «проверь этот TypeScript-код на соответствие». Наша команда Network Firewall провела аудит rampartd с использованием процесса многоагентного консенсуса, где каждое требование оценивалось как СООТВЕТСТВУЕТ, ЧАСТИЧНО СООТВЕТСТВУЕТ или НЕ СООТВЕТСТВУЕТ с указанием конкретных деталей нарушений и шагов по исправлению, сократив то, что раньше требовало недель ручной работы, до структурированного, повторяемого процесса.

Во время проверки AI Code Reviewer ссылается на конкретные правила Codex в своих комментариях.

 ^{AI Code Review: показаны категоризированные находки (в данном случае соответствие Codex) с указанием нарушения RFC кодекса.}

Ни один из этих элементов по отдельности не является особенно новым. Многие компании используют сервисные каталоги, запускают ботов-ревьюверов или публикуют инженерные стандарты. Разница — в связях. Когда агент может получить контекст из Backstage, прочитать AGENTS.md для репозитория, который он редактирует, и быть проверенным на соответствие правилам Codex тем же набором инструментов, первый черновик обычно оказывается достаточно хорош для отправки в работу. Этого нельзя было сказать полгода назад.

От запуска этой инициативы до 93% внедрения в R&D прошло меньше года.

Внедрение по всей компании (5 февраля – 15 апреля 2026 г.):

AI Gateway (последние 30 дней, совокупно):

Workers AI (последние 30 дней):

Следующая эволюция нашего внутреннего инженерного стека будет включать фоновых агентов: агентов, которых можно запускать по требованию с теми же инструментами, что доступны локально (MCP portal, git, тестовые раннеры), но работающих полностью в облаке. Архитектура использует Durable Objects и Agents SDK для оркестрации, делегируя задачи контейнерам Sandbox, когда задание требует полной среды разработки, такой как клонирование репозитория, установка зависимостей или запуск тестов. Sandbox SDK стал общедоступным во время Agents Week.

Долгоживущие агенты, встроенные нативно в Agents SDK во время Agents Week, решают проблему долговременных сессий, которая раньше требовала обходных путей. Теперь SDK поддерживает сессии, которые работают в течение длительных периодов без прерывания, что достаточно для того, чтобы агент мог клонировать большой репозиторий, запустить полный набор тестов, итеративно исправлять ошибки и открывать MR в одной сессии.

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

Неделя Agents Week только что выпустила всё необходимое. Платформа уже здесь.

npx create-cloudflare@latest --template cloudflare/agents-starter

Этот стартовый набор для агентов поможет вам начать работу. Нижеприведенная диаграмма показывает полную архитектуру на тот случай, когда вы будете готовы её развивать: ваши инструменты располагаются сверху (чат-бот, веб-интерфейс, CLI, расширение для браузера), Agents SDK, управляющий состоянием сессии и оркестрацией, — в середине, а сервисы Cloudflare, которые вы вызываете, — внизу.

Документация: Agents SDK · Sandbox SDK · AI Gateway · Workers AI · Workflows · Code Mode · MCP на Cloudflare

Репозитории: cloudflare/agents · cloudflare/sandbox-sdk · cloudflare/mcp-server-cloudflare · cloudflare/skills

Чтобы узнать больше о том, как мы используем ИИ в Cloudflare, прочитайте публикацию о нашем процессе проверки кода с помощью ИИ. А также ознакомьтесь с всем, что мы выпустили в течение Недели Agents Week.

Мы будем рады узнать, что вы создадите. Найдите нас в Discord, X и Bluesky.