Вы начали с одного MCP-сервера. Доступ к файлам, чтобы ваш агент Claude Code мог читать и писать проект. Разумно.

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

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

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

Проблема накопления

MCP-серверы мощные. Model Context Protocol дает Claude Code доступ к внешним системам, и каждая интеграция действительно решает проблему. Доступ к файлам позволяет агенту читать кодовую базу. Веб-поиск позволяет искать документацию. Интеграция с GitHub позволяет проверять статус PR.

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

Агенту нужно проверить схему базы данных? Добавить Postgres MCP. Агенту нужно прочитать страницу Confluence? Добавить Confluence MCP. Агенту нужно опубликовать сообщение в Slack? Добавить Slack MCP. Каждый по отдельности обоснован. Вместе они создают проблему, которую трудно заметить, пока качество результатов не упадет.

Каждый MCP-сервер регистрирует свои инструменты в контексте разговора. MCP доступа к файлам может зарегистрировать 5-10 инструментов. MCP базы данных регистрирует еще несколько. GitHub MCP добавляет еще. Когда у вас шесть MCP-серверов, агент несет десятки определений инструментов в своем окне контекста, прежде чем прочитает хоть одну строку вашего кода.

Эти определения инструментов не бесплатны. Они потребляют токены. И что важнее, они конкурируют за внимание агента. Когда у агента 40 доступных инструментов, каждая точка принятия решения становится ветвящимся вопросом: использовать файловый инструмент, поисковый, базу данных или GitHub? Агент тратит когнитивный бюджет на решение как получить информацию, вместо того чтобы использовать информацию для решения вашей задачи.

Контекст конечен. Внимание еще более дефицитно.

Окно контекста Claude Code большое. Это создает опасную иллюзию: что можно продолжать добавлять информацию без последствий.

На практике производительность агента деградирует задолго до заполнения окна контекста. Проблема не в емкости. В соотношении сигнал-шум. Агент с окном контекста в 200K токенов работает лучше с 50K токенов сфокусированной, релевантной информации, чем со 150K токенов, где нужные части разбросаны среди схем инструментов, ответов API и посторонних файлов.

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

Для агентов это проявляется как:

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

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

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

Ограниченный контекст: альтернатива разрастанию инструментов

Рефлекторная реакция на «моему агенту нужна информация X» — дать агенту инструмент, который извлекает X. Но есть другой подход: поместить X в задачу.

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

Разница структурная. При разрастании MCP рабочий процесс агента выглядит так:

Прочитать задачу
Выяснить, какая информация отсутствует
Использовать различные инструменты для сбора этой информации
Синтезировать информацию
Выполнить фактическую работу

При ограниченном контексте:

Прочитать задачу (которая содержит весь необходимый контекст)
Выполнить фактическую работу

Шаги 2-4 в первом рабочем процессе — это не просто накладные расходы. Именно там все идет не так. Агент собирает слишком много информации, или неправильную информацию, или отвлекается на интересные, но нерелевантные данные. Каждый вызов инструмента — потенциальный крюк.

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

Структурирование задач как контейнеров контекста

Задача, работающая как контейнер контекста, выглядит иначе, чем типичный тикет Jira или GitHub issue. Она самодостаточна. Агент, прочитавший ее, должен иметь все необходимое для начала работы без обращения к внешним системам за фоновой информацией.

Вот как это выглядит на практике:

Title: Add rate limiting to /api/search endpoint

Description:
The /api/search endpoint currently has no rate limiting.
Add a token bucket rate limiter at 100 requests/minute per IP.

Files to modify:
- server/middleware/rate-limit.ts (create new)
- server/routes/search.ts (apply middleware)
- server/config.ts (add RATE_LIMIT_RPM env var)

Acceptance criteria:
- Requests beyond 100/min from same IP return 429
- Rate limit resets after 60 seconds
- Config value overridable via environment variable
- Existing tests still pass

Context:
- We use Express middleware pattern (see server/middleware/auth.ts for example)
- The config module uses dotenv (see server/config.ts lines 1-15)
- No Redis available; use in-memory store. This is a single-instance app.

Dependencies: None. This can run independently.

Обратите внимание, что встроено в задачу. Агент знает, какие файлы трогать, какому паттерну следовать, какие ограничения существуют (нет Redis), и как именно выглядит «готово». Ему не нужен MCP базы данных для проверки схемы. Не нужен инструмент wiki для поиска паттерна middleware. Не нужно искать по кодовой базе, чтобы понять подход к конфигурации. Все в задаче.

Написание задач таким образом требует больше усилий заранее. Типичный тикет может сказать «Добавить rate limiting к search endpoint» и оставить остальное агенту. Но этот процесс выяснения — именно то, откуда берется разрастание MCP: агенту нужна информация, поэтому вы даете ему инструменты, а инструменты поедают контекст.

CLAUDE.md как граница контекста

Задача сообщает агенту, что строить. Файл CLAUDE.md сообщает ему, в каком мире он живет.

Если вы запускаете несколько агентов Claude Code, каждый должен иметь CLAUDE.md, определяющий его область, а не только инструкции. Думайте об этом как о контекстном заборе: все внутри забора — ответственность агента, а все снаружи — чья-то другая проблема.

## Identity
Frontend engineer for ProjectX. You own components/, hooks/,
and app/pages/. You write React components with TypeScript.

## What you do NOT own
- server/ (backend engineer handles this)
- database/ (DBA handles schema changes)
- infrastructure/ (ops handles deployment configs)

## How to get information you need
- API contracts are in docs/api-spec.md
- Design specs are linked in the task description
- If you need backend changes, create a task for the backend agent

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

Раздел «how to get information» критически важен. Вместо того чтобы давать агенту инструмент для поиска API-контрактов, вы говорите ему, где контракты находятся. Вместо того чтобы давать ему доступ к Slack для вопросов backend-команде, вы говорите ему создать задачу. Информационный поток явный, а не эмерджентный.

Это тот же принцип, что и при управлении задачами для агентов Claude Code: агенты работают лучше с четкими границами, чем с неограниченным доступом. Каждая граница, которую вы определяете, — это MCP-сервер, который вам не нужен.

Когда MCP все еще нужны

Ограниченный контекст не устраняет MCP полностью. Некоторые инструменты действительно необходимы:

Доступ к файловой системе не обсуждается. Агентам нужно читать и писать код. Это не разрастание; это основа.

Инструменты контроля версий (операции git) — часть основного рабочего процесса агента. Коммиты, ветвление и diff — это действия реализации, а не информационные крюки.

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

Различие между инструментами реализации (то, что агент использует для выполнения работы) и инструментами сбора информации (то, что агент использует, чтобы выяснить, какая работа). Инструменты реализации принадлежат конфигурации MCP агента. Инструменты сбора информации — сигнал, что вашим описаниям задач нужно больше контекста.

Если вы обнаруживаете, что добавляете MCP, потому что «агенту нужно найти X», спросите, может ли X быть в задаче. Если да, поместите его туда. Если нет (потому что X часто меняется, слишком велик или требует данных в реальном времени), MCP обоснован. Но этот вопрос стоит задавать каждый раз.

Beads: задачи как ограниченный контекст

Это паттерн, который мы используем для координации 13 агентов Claude Code на одной кодовой базе. Каждый агент получает задачу, содержащую его полную область, и CLAUDE.md, определяющий его границы. Эта комбинация означает, что агентам редко нужны инструменты помимо доступа к файлам и git.

Трекер задач, который делает это возможным, — beads, open-source локальный CLI. Каждый «bead» — самодостаточная единица работы: заголовок, описание, критерии приемки и тред комментариев, где агенты публикуют планы и отчеты о завершении.

Создание задачи со встроенным контекстом:

bd create --title "Add rate limiting to /api/search" \
  --description "Token bucket at 100 req/min per IP. \
    Files: server/middleware/rate-limit.ts (new), \
    server/routes/search.ts, server/config.ts. \
    Pattern: see server/middleware/auth.ts. \
    Constraint: in-memory store, no Redis." \
  --priority p2

Агент забирает задачу и читает ее:

bd update bb-r3k2 --claim --actor eng1
bd show bb-r3k2

Все, что нужно агенту, в bead. Описание включает файлы, паттерны и ограничения. Агенту не нужен Wiki MCP для поиска паттерна middleware, потому что задача говорит "see server/middleware/auth.ts". Не нужен MCP базы данных, потому что задача говорит "no Redis, use in-memory store".

Перед написанием кода агент публикует свой план реализации:

bd comments add bb-r3k2 --author eng1 "PLAN:
1. Create server/middleware/rate-limit.ts with token bucket
2. Wire into search route in server/routes/search.ts
3. Add RATE_LIMIT_RPM to server/config.ts with default 100
4. Add tests for 429 response and reset behavior"

После реализации агент публикует, что сделал и как проверить:

bd comments add bb-r3k2 --author eng1 "DONE: Rate limiting added.
Commit: abc123

Verification:
- curl /api/search 101 times in 60s, 101st returns 429
- Set RATE_LIMIT_RPM=5, verify limit changes
- pnpm test passes (3 new tests added)"

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

Видеть границы контекста по всему флоту

Когда вы запускаете несколько агентов с ограниченным контекстом, возникает новый вопрос: чья задача ссылается на чьи файлы? Где границы контекста пересекаются? Какой агент работает над API-слоем, и могу ли я безопасно назначить frontend-работу параллельно?

Здесь CLI в одиночку становится ограниченным. bd list показывает задачи и статусы. Он не показывает отношения между ними и не позволяет заметить, когда области двух агентов сместились на одну территорию.

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

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

Если вы строите такие рабочие процессы, поставьте звезду Beadbox на GitHub.

Управление контекстом агентов Claude Code без разрастания MCP