Архитектура Context Platform: как компании собирать контекст для Coding Agents

Короткий ответ. Context Platform — система, которая для каждой задачи агента отбирает из знаний компании минимально достаточный набор документов, проверяет права, собирает пакет, записывает манифест и учится на ревью и инцидентах. Это не хранилище и не поиск, а конвейер из семи шагов. Ниже — архитектура этого конвейера, уровни зрелости, антипаттерны и место MCP. Статья для архитекторов и платформенных команд; что такое context engineering и зачем он нужен, я разбирал отдельно.

Откуда вопрос: ручной контекст работает, но не масштабируется

В эксперименте к выпуску «От Coding Agent к AI Development Platform» я дал Coding Agent обычную задачу: добавить в синтетический сервис доставки самовывоз из пунктов выдачи партнёра. Условие A — задача и репозиторий. Условие B — то же плюс 8 коротких документов инженерного контекста: описание архитектуры, 2 ADR, контракт API, требования, инженерные правила, политика безопасности и разбор одного инцидента. Всего 522 слова. По 3 прогона на условие, одна модель, проверки писал я — это демонстрация механизма, а не бенчмарк.

Результат по моим статическим проверкам: в условии A — 4–5 из 7, в условии B — 7 из 7 во всех трёх прогонах. Независимая приёмка по требованиям: 2–4 из 10 против 10 из 10. Без контекста агент в трёх прогонах назначил три разные цены — 199, 0 и 150 рублей — при утверждённых 99. Подробно о том, что он придумал, видя только код, — в разборе условия A.

Но главный вывод для архитектора другой. Пакет для условия B собрал я. Руками. Нашёл требования, нашёл контракт, вспомнил про решение о флагах выкатки и про инцидент полуторагодовой давности. Самую ценную работу — отбор — сделал человек, который систему знает. Пусть это полчаса на задачу: для команды из 20 человек с агентами это либо чья-то полная ставка, либо никто этого делать не будет. А если никто — команда возвращается в условие A.

Значит, отбор должна делать система.

Конвейер Context Platform

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

                 TASK  (PROD-2291, user, repo)
                   ↓
 1  SOURCES         код · ADR · архитектура · контракты · требования
                    политики · инциденты · стандарты · трекер
                   ↓
 2  METADATA        статус · владелец · актуальность · компоненты
    & INDEXING
                   ↓
 3  RETRIEVAL       задача → компоненты → документы-кандидаты
                   ↓
 4  AUTHORIZATION   только то, что разрешено пользователю задачи
                   ↓
 5  ASSEMBLY        порядок · бюджет · ссылки вместо копий
                   ↓
 6  MANIFEST        что отдали, какие версии, почему
                   ↓
               CODING AGENT
                   ↓
 7  FEEDBACK        ревью · приёмка · инциденты → правила и документы
                   ↺  обратно в SOURCES

1. Источники

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

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

2. Метаданные и индексация

Здесь решается, будет ли отбор осмысленным. Каждому документу нужны как минимум четыре поля:

status       proposed | accepted | superseded | deprecated
owner        команда или человек, отвечающий за актуальность
reviewed_at  когда последний раз подтверждали, что документ верен
components   к каким частям системы относится

Реальный пример из эксперимента: ADR-011 про выкатку новых способов доставки имеет статус «принято (2025-02)» и прямо относится к компоненту доставки. Если бы через год решение отменили, а документ остался со старым статусом, агент выполнил бы его буквально. Отменённое решение хуже, чем отсутствие решения.

Индексация — вторична. Полнотекстовый или семантический индекс полезен, но без статуса и компонентов он находит документы, релевантные по словам и устаревшие по смыслу.

3. Отбор

Отбор начинается не с поиска, а с вопроса: какие компоненты затрагивает задача. Задача про самовывоз затрагивает модуль доставки и возвраты. Значит, кандидаты — действующие документы с этими метками: требования к фиче, контракт API доставки, ADR о слоях и о выкатке, инцидент с возвратами, общие инженерные правила и политика безопасности. Это ровно те 8 документов, которые я собрал руками.

Anthropic определяет цель context engineering как «наименьший набор высокосигнальных токенов», который максимизирует вероятность нужного результата. Для платформы это означает: отбор должен уметь не только найти, но и отбросить.

4. Авторизация

Контекст не должен давать агенту больше, чем разрешено человеку, от имени которого он работает. OWASP в списке рисков LLM-приложений 2025 года (LLM06, Excessive Agency) среди мер называет выполнение действий в контексте прав пользователя и авторизацию на стороне бэкенда, а не решением модели. Для контекста это правило работает так же.

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

5. Сборка

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

• бюджет — пакет в условии B занимал меньше двух страниц; это ориентир порядка величины, а не норма;
• порядок — задача и жёсткие правила в начале; «Lost in the Middle» (2023) показал, что модели хуже используют середину длинного контекста, и хотя современные модели чувствительны к этому меньше, проблема длинного контекста остаётся;
• ссылки вместо копий — крупные документы лучше давать путём, чтобы агент прочитал нужное в момент, когда оно понадобилось;
• формат — короткие документы с одной мыслью на строку; требования в эксперименте — 6 бизнес-правил по строке на каждое.

6. Манифест

Для каждой задачи платформа сохраняет список: какие документы, в каких версиях и почему попали в контекст. Пример формата (ревизии, статусы и имя команды условные):

context-manifest   PROD-2291   on behalf of: dev-delivery-team
  requirements/PRD-pickup.md             rev 3   approved     component: delivery
  contracts/delivery-options.openapi     v3.4    agreed       component: delivery-api
  adr/ADR-011-delivery-rollout.md        rev 1   accepted     rule: new delivery method
  adr/ADR-003-layering.md                rev 1   accepted     rule: domain change
  history/INC-2025-031.md                rev 1   closed       component: refunds
  engineering-rules.md · security-policy.md · architecture.md   always
assembled_at  2026-09-28T12:00Z   size ≈ 520 words

Манифест — это прослеживаемость. В прогоне B ревьюер на вопрос «почему самовывоз стоит 99 рублей?» отвечает ссылкой на требования. В прогоне A ответа нет: цена взялась из ниоткуда.

7. Обратная связь

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

В эксперименте это видно на одном документе. INC-2025-031 — разбор инцидента: запустили экспресс-доставку, забыли правило возврата, возвраты падали двое суток. Последняя строка разбора: «у каждого нового способа доставки должно быть правило возврата и тест на возврат». Это и есть обратная связь, превращённая в правило. Агент в условии B процитировал его в своём ходе работы: добавляю правило возврата — обязательно по INC-2025-031, а шестой пункт требований говорит, что доставка не возвращается. В условии A правило возврата было неверным во всех трёх прогонах.

MCP — транспорт, а не платформа

Model Context Protocol — открытый стандарт подключения ИИ-ассистентов к системам, где живут данные. Anthropic представила его в ноябре 2024 года, в декабре 2025-го протокол передан в Agentic AI Foundation под Linux Foundation.

В схеме выше MCP — хороший способ реализовать шаг 1 и частично шаг 5: подключить трекер, базу ADR, реестр контрактов единым образом. Но протокол — это провод. Он отвечает на вопрос «как подключить». Он не отвечает на вопросы «что из этого нужно задаче», «действует ли ещё этот документ» и «можно ли его показывать этому пользователю». Подключить агенту 15 MCP-серверов без отбора — это та же «вся вики в контексте», только через стандартный интерфейс.

Где место CLAUDE.md

Файл инструкций проекта — CLAUDE.md или AGENTS.md — полезный и правильный первый шаг: правила сборки, структура, соглашения нужны агенту в каждой задаче. По документации Claude Code уровней у него несколько (от политики организации до локального файла), подключать другие файлы можно через @path с глубиной до четырёх уровней. Но это контекст, а не принудительная конфигурация, и он статичен: один и тот же для всех задач. Платформа собирает контекст под задачу. Подробнее о том, чем CLAUDE.md хорош и где он заканчивается, — в отдельной статье.

Уровни зрелости 0–4

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

0  REPOSITORY ONLY      агент видит только репозиторий           ← условие A
1  PROJECT RULES        CLAUDE.md / AGENTS.md: сборка, соглашения
2  DOCS NEXT TO CODE    ADR и контракты рядом с кодом, агент их находит
3  TASK CONTEXT         контекст собирается под задачу из источников ← условие B,
                                                                     но автоматически
4  PLATFORM             отбор · свежесть · права · манифест · обратная связь

Большинство команд, с которыми я разговариваю, находятся между нулём и единицей. Переход 1 → 2 — организационный, а не технический: решения и контракты должны перестать жить только в чатах и головах. Переход 3 → 4 — уже инженерная работа платформенной команды.

В модели DORA AI Capabilities (2025) из семи возможностей, которые усиливают эффект ИИ, две прямо про это: здоровая экосистема данных и внутренние данные, доступные для ИИ. Ещё одна — качественные внутренние платформы. Как всё это складывается в общую архитектуру, я разбираю в статье про архитектуру AI Development Platform.

Антипаттерны

Вся вики в поиск. Загрузить всё в индекс и назвать это платформой. Результат — документы, релевантные по словам и устаревшие по смыслу. Без статуса отменённый ADR ранжируется так же, как действующий.

Один файл правил на 2000 строк. Агент читает его в каждой задаче и тратит внимание на всё, кроме нужного. Anthropic описывает это как бюджет внимания модели: каждый лишний токен его расходует.

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

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

Контекст без манифеста. Агент принял решение, а на чём оно основано — неизвестно. Ревьюер видит догадку, а не ссылку.

Протокол вместо платформы. Подключены все источники через MCP, отбора нет. Агент получает не контекст, а доступ ко всему.

Ограничения

Схема и уровни — авторские, из практики, а не из исследований. Эксперимент, на который я опираюсь, маленький: 6 прогонов, один синтетический репозиторий, одна модель (claude-sonnet-5), проверки писал я. Он показывает механизм — «чего нет в контексте, агент придумает, уверенно и правдоподобно», — но не даёт цифр для экстраполяции на ваши системы.

Контекст не делает агента быстрее и дешевле. В эксперименте прогоны B заняли от 4,6 до 9,1 минуты и стоили от 1,03 до 1,85 доллара, прогоны A — от 4,4 до 7,2 минуты и от 0,80 до 1,13 доллара. Самый долгий прогон B споткнулся о правила доступа — эту историю я разбираю в статье про права Coding Agent.

И главное ограничение: платформа отдаёт агенту то, что записано. Если в требованиях ошибка, агент в условии B реализует её идеально. Узкое место переезжает в качество требований и решений — и это уже работа людей.

Что делать

1. Инвентаризация. Выпишите, где живут ADR, контракты, требования, разборы инцидентов и стандарты. Для каждого источника — владелец.
2. Метаданные у ключевых документов. Статус, владелец, дата подтверждения, компоненты. Начните с действующих ADR и контрактов.
3. Ручные пакеты для трёх частых типов задач. Как я сделал для самовывоза. Это уровень 3 без кода и готовое техническое задание для автоматизации.
4. Связь задачи с компонентами. Метка компонента в трекере или правило «какие каталоги затрагивает задача».
5. Манифест с первого дня. Даже если пакет собран руками, записывайте, что отдали агенту.
6. Петля обратной связи. Каждое замечание ревью, которое повторяется, и каждый инцидент — в документ или правило.
7. Только потом — автоматический отбор и MCP-коннекторы.

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

Источники

• Effective context engineering for AI agents — Anthropic (Engineering blog), 2025.
• Lost in the Middle: How Language Models Use Long Contexts — Liu et al. (Stanford, UC Berkeley, Samaya AI), 2023; TACL 2024.
• Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma, 2025.
• How Claude remembers your project — Claude Code Docs, Anthropic, 2026 (проверено 28.09.2026).
• Introducing the Model Context Protocol — Anthropic, 2024; Linux Foundation Announces the Formation of the Agentic AI Foundation — Linux Foundation, 2025.
• LLM06:2025 Excessive Agency — OWASP Top 10 for LLM Applications 2025, OWASP GenAI Security Project.
• Introducing DORA's inaugural AI Capabilities Model — Google Cloud / DORA, 2025.
• Эксперимент выпуска «От Coding Agent к AI Development Platform»: 6 прогонов Claude Code 2.1.283 с моделью claude-sonnet-5, синтетический репозиторий, 2026.