Архитектура AI Development Platform: 6 слоёв вокруг Coding Agent

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

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

AI Development Platform — это 6 слоёв вокруг Coding Agent:

MODEL + CONTEXT + TOOLS + POLICIES + QUALITY GATES + OBSERVABILITY

Это авторский синтез, а не стандарт: он собран из эксперимента и опубликованных практик — context engineering Anthropic, правил и песочницы Claude Code и Codex, OWASP и DORA.

Принципы, общие для всех слоёв

4 принципа, без которых слои превращаются в набор инструментов.

1. Задача — сквозной идентификатор. Всё, что происходит на платформе, привязано к задаче: какой контекст получил агент, какие действия запросил, что решила политика, какие проверки прошли, сколько это стоило. Без этой связи нельзя ответить на вопрос «почему самовывоз стоит 99 рублей и кто это разрешил».

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

3. Знание для проверки берётся не из кода. Если проверка смотрит только в код, она подтверждает решения автора, в том числе ошибочные.

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

Общая схема

                         ПОЛЬЗОВАТЕЛЬ
                              │
                          ЗАДАЧА (id)
                              │
         ┌────────────────────┴────────────────────┐
         ▼                                         │
   ┌───────────┐   манифест контекста              │
   │  CONTEXT  │───────────────┐                   │
   └───────────┘               ▼                   │
                         ┌───────────┐             │
                         │   AGENT   │◄── MODEL    │
                         └─────┬─────┘             │
                     запрос действия               │
                               ▼                   │
                         ┌───────────┐             │
                         │ POLICIES  │ ALLOW / ASK / DENY
                         └─────┬─────┘   ASK → человек
                               ▼                   │
                         ┌───────────┐             │
                         │   TOOLS   │ в песочнице │
                         └─────┬─────┘             │
                           diff / PR               │
                               ▼                   │
                     ┌──────────────────┐          │
                     │  QUALITY GATES   │ приёмка · ревью · безопасность
                     └────────┬─────────┘          │
                              ▼                    │
                     ПОСТАВКА → ПРОДАКШЕН          │
                                                   │
   OBSERVABILITY: журнал решений · аудит · стоимость · метрики пути задачи

Слой 1. Model

Ответственность. Рассуждение, планирование, написание кода. Это единственный слой, который «думает», и единственный, которому нельзя поручать гарантии.

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

Что было видно в эксперименте. Во всех 6 прогонах модель была одна — claude-sonnet-5, агент — Claude Code одной версии. Результат при этом различался от 4 до 7 проверок из 7 и от 2 до 10 приёмочных тестов из 10: разницу дала не модель, а контекст. Там, где у модели был образец в коде, 3 прогона без контекста сошлись почти до деталей. Там, где образца не было, она угадывала — цена самовывоза вышла 199, 0 и 150 рублей.

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

Слой 2. Context

Ответственность. Собрать для конкретной задачи минимально достаточный набор знаний и показать, из чего он собран. У Anthropic цель context engineering сформулирована как наименьший набор токенов с высоким сигналом.

Интерфейсы.

ВХОД:   задача (id, текст, затронутые компоненты), пользователь (права)
ИСТОЧНИКИ: код · ADR · архитектура · контракты API · требования ·
           политики · инциденты · стандарты команды · трекер
ВЫХОД:  пакет контекста + манифест (какие документы, в каких версиях)
ОБРАТНО: замечания ревью и инциденты → новые правила и решения

Внутри слоя — конвейер: источники → метаданные и индексация → отбор → авторизация → сборка → манифест → обратная связь. У каждого документа должны быть статус, владелец, дата актуальности и привязка к компонентам. Подробно, с уровнями зрелости и антипаттернами, — в статье архитектура Context Platform.

Что было видно в эксперименте. Пакет из 8 документов на 522 слова поднял результат с 4–5 до 7 из 7 статических проверок и с 2–4 до 10 из 10 независимых приёмочных тестов. Флаг выкатки и правило возврата — 0 из 3 без контекста и 3 из 3 с ним: этих знаний в коде не было вообще. Агент с контекстом ссылался на документы в своих шагах («по ADR-011», «по INC-2025-031») — это прослеживаемость, которую должен сохранять манифест.

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

Типичная ошибка. «Дать всё»: загрузить вики целиком. С ростом длины входа качество модели становится неравномерным — это показали и «Lost in the Middle» 2023 года, и проверка 18 моделей Chroma 2025 года.

Слой 3. Tools

Ответственность. Дать агенту способы действовать: читать и править файлы, запускать команды и тесты, работать с Git, ходить во внешние системы. И ограничить эти способы физически.

Интерфейсы. Каждый инструмент — явный вызов с параметрами (команда, путь, адрес): по ним принимает решение политика и пишет журнал аудит. Исполнение — внутри песочницы. В Claude Code песочница даёт 2 изоляции — файловую систему и сеть, и применяет их средствами ОС ко всем дочерним процессам: на macOS — Seatbelt, на Linux — bubblewrap. У Codex 3 режима песочницы: только чтение, запись в рабочую папку и полный доступ; в режиме записи сеть по умолчанию выключена.

Что было видно в эксперименте. В самом репозитории был пример этого слоя на уровне кода: единственный шлюз во внешнюю сеть со списком разрешённых адресов — все 6 прогонов его соблюли. А разрешённые агенту команды были заданы списком, и он оказался слишком узким: разрешён python -m pytest, а агент запускал python3 и pytest. Результат — 16 отказов, самый долгий и дорогой прогон из 6: 9 минут и 1,85 $.

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

Слой 4. Policies

Ответственность. Для каждого запроса на действие решить: ALLOW, ASK или DENY.

Интерфейсы.

ВХОД:   USER + TASK + ACTION + RESOURCE + ENVIRONMENT
ВЫХОД:  ALLOW | ASK | DENY  (+ причина, + запись в журнал)
ASK →   человек подтверждает конкретное действие целиком

Пример: go test в рабочей копии — ALLOW, выкатка на стенд — ASK, чтение секрета продакшена — DENY, кто бы ни просил. В Claude Code простейшая реализация — 3 списка правил в settings.json, проверяемые в порядке deny → ask → allow; разрешение не может перебить запрет. Режимов разрешений там 6, и полностью отключать проверки документация советует только в изолированной среде — контейнере или виртуальной машине.

Рядом с политикой — идентичность агента: свои короткоживущие учётные данные под задачу с минимальными правами, а не личные токены разработчика. OWASP в списке рисков LLM-приложений 2025 года выделяет excessive agency — лишние функции, лишние права, лишнюю автономию — и среди мер называет минимальные привилегии и подтверждение человеком действий с высоким воздействием.

Что было видно в эксперименте. Команда с rm -rf, которой агент хотел убрать кэш, не прошла. Запрос «покажи .env.production» — агент попробовал 2 способа, оба заблокированы. «Закоммить и отправь ветку» — агент подготовил коммит и остановился в ASK.

Типичная ошибка. ASK на всё. Если агент спрашивает 20 раз в час, человек начинает нажимать «да», не читая. ASK должен срабатывать редко: там, где действие выходит за рабочую копию и его нельзя легко отменить. Подробно про policy engine и 4 механизма — sandbox, policy, approval, audit — в статье безопасность Coding Agent: Allow / Ask / Deny. Готовые списки правил — в бесплатном чек-листе прав Coding Agent.

Слой 5. Quality gates

Ответственность. Доказать, что результат решает задачу, а не только проходит собственные тесты автора.

Интерфейсы.

ВХОД:   diff / PR + требования + контракты + ADR (не код автора как источник истины)
ПРОВЕРКИ:
  приёмка     тесты из требований, пишутся независимо от автора
  ревью       другой агент или человек со свежим контекстом, без права менять код
  безопасность поиск секретов · новые зависимости · статический анализ
  архитектура правила компании: слои, сеть только через шлюз
ВЫХОД:  pass / fail по каждой проверке + вердикт «можно мержить»

Что было видно в эксперименте. Собственные тесты агента были зелёными во всех 6 прогонах; в одном тест прямо закреплял придуманную агентом бесплатную доставку. Независимый валидатор, получивший только требования, контракт и ADR о выкатке, дал 2–4 из 10 без контекста и 10 из 10 с ним. Ревьюер нашёл в том же прогоне 3 блокера и заметил, что ошибка в правиле возврата замаскирована нулевой ценой. Стоимость: валидатор — от 0,43 до 0,68 $, ревью — 0,25 $ и 81 секунда. И урок про отчёт: агент, которому не дали запустить тесты, написал, что проверил код вручную. Отчёт агента — не доказательство; доказательство — результат проверки, которую запустила система.

Безопасность — обязательная часть слоя. Veracode в 2025 году прогнал больше 100 моделей на 80 задачах с выбором безопасной или небезопасной реализации; в 45% случаев код не прошёл проверки. Задачи подобраны специально, это не доля уязвимого кода в продакшене, но вывод один: шлюз безопасности — в конвейере, а не в надежде на модель. Подробно — в статье AI написал код и тесты, всё зелёное — почему задача не решена.

Типичная ошибка. Проверки, которые не выдерживают объёма. По отчёту Faros AI (вендор, корреляция), в командах с активным использованием ИИ ревью идёт на 91% дольше, а pull request'ы на 154% крупнее. Слой должен автоматизировать всё, что не требует человека, и отдавать человеку только отмеченное политикой как рискованное.

Слой 6. Observability

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

Интерфейсы.

НАБЛЮДАЕМОСТЬ   активные задачи агентов, ход выполнения, отказы политики
АУДИТ           кто · задача · агент и модель · инструмент · ресурс · действие ·
                среда · решение политики · кто подтвердил · результат · время
СТОИМОСТЬ       по задаче: токены, время, деньги, число отказов
МЕТРИКИ         путь задачи: время до продакшена, частота выкаток,
                доля неудачных изменений, время восстановления, возвраты с ревью

Что было видно в эксперименте. Всё, что рассказано выше, известно из журналов прогонов. Именно журнал показал 16 отказов и попытку получить другие права через субагента — без него остался бы только отчёт агента «проверил вручную». Разброс стоимости — от 0,80 до 1,85 $ за прогон — тоже виден только в учёте по задаче.

Типичная ошибка. Мерить активность агентов вместо пути задачи: строки кода, токены, число промптов. Google весной 2026 года сообщил, что 75% нового кода у них генерирует ИИ и одобряют инженеры, — это метрика написания кода, и о скорости поставки она ничего не говорит. Какие метрики брать вместо — в статье чем измерять AI-разработку.

Соответствие модели возможностей DORA

DORA в 2025 году опубликовала модель возможностей для команд с ИИ — 7 возможностей, которые усиливают или открывают эффект от ИИ. Ни одна не про выбор модели. Сопоставление со слоями ниже — моя интерпретация, не часть модели DORA.

Там же DORA сообщает, что 90% организаций внедрили хотя бы одну внутреннюю платформу, а качество платформы связано со способностью получить пользу от ИИ. Это корреляция, но она согласуется с главным выводом DORA 2025 года: ИИ — усилитель, сильную систему поставки он делает сильнее, слабую — проблемнее.

Дорожная карта: 6 шагов

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

1. ИЗМЕРИТЬ        путь задачи до продакшена сейчас            → Observability (метрики)
2. КОНТЕКСТ        пакеты для 3 самых частых типов задач       → Context (уровень 2–3)
3. ПРАВА           Allow / Ask / Deny + песочница,             → Policies + Tools
                   секреты продакшена — Deny с первого дня
4. ПРИЁМКА         тесты из требований хотя бы для 1 сервиса   → Quality gates
5. АУДИТ И ЦЕНА    журнал решений и стоимость по задаче        → Observability (аудит)
6. МАСШТАБ         автоматический сбор контекста, расширение   → все слои
                   политики, новые агенты — только после 1–5

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

Ограничения

Схема выведена из 6 прогонов на одном синтетическом репозитории, с одной моделью и проверками, которые я написал сам до прогонов. Это демонстрация механизма, а не бенчмарк, и цифры эксперимента нельзя переносить на ваши системы как ожидаемый эффект. Интерфейсы слоёв — авторская схема; у готовых продуктов границы проходят иначе, и это нормально, если ответственность каждого слоя закреплена. Данные DORA и Faros — корреляционные.

Что сделать на этой неделе

• Нарисовать свою схему из 6 слоёв и честно отметить, какого слоя нет.
• Проверить, привязаны ли действия агентов к задаче: без этой связи остальные слои не работают.
• Проверить, откуда ваши проверки берут знание. Если только из кода автора — добавить хотя бы одну приёмку из требований.

Референсную схему AI во всём цикле разработки — AI SDLC Blueprint — я готовлю. Если нужна оценка того, какие слои у вас уже есть и с какого шага начинать, — это задача для оценки AI-разработки.

Источники

• Effective context engineering for AI agents. Anthropic, 2025.
• How Claude remembers your project (документация Claude Code). Anthropic, 2026.
• Configure permissions (документация Claude Code). Anthropic, 2026.
• Configure the sandboxed Bash tool (документация Claude Code). Anthropic, 2026.
• Codex docs: Sandboxing; Agent approvals & security. OpenAI, 2026.
• Introducing the Model Context Protocol. Anthropic, 2024.
• Liu et al. Lost in the Middle: How Language Models Use Long Contexts. Stanford, UC Berkeley, Samaya AI, 2023.
• Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma, 2025.
• LLM06:2025 Excessive Agency — OWASP Top 10 for LLM Applications 2025. OWASP GenAI Security Project, 2024.
• 2025 GenAI Code Security Report. Veracode, 2025.
• The AI Productivity Paradox Report 2025. Faros AI, 2025.
• Announcing the 2024 DORA report. Google Cloud / DORA, 2024.
• Announcing the 2025 DORA Report: State of AI-assisted Software Development. Google Cloud / DORA, 2025.
• Introducing DORA's inaugural AI Capabilities Model. Google Cloud / DORA, 2025.
• Sundar Pichai shares news from Google Cloud Next 2026. Google, 2026.
• Эксперимент автора: 6 прогонов Claude Code (claude-sonnet-5) на синтетическом репозитории shipline, сентябрь 2026.