Папка и есть агент

Инженер запустил 44 AI-агента на нескольких проектах, и каждый из них — это просто модель, направленная на папку с контекстом. Автор рассказывает, как отказ от сложных «роёв» агентов в пользу простого подхода «папка = агент» позволил кардинально масштабировать работу.

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Папка и есть агент

The Folder Is the Agent Автор: Kieran Klaassen Оригинальный текст:

В пятницу, 17 апреля, генеральный менеджер [Cora](https://cora.computer/) [Киран Клаассен](https://every.to/@kieran_1355) проведёт кэмп для платных подписчиков Every, посвящённый compound engineering — AI-нативной инженерной философии, которую он разработал и которая собрала больше 14 000 звёзд на GitHub. Со времён прошлого кэмпа Киран вместе с продуктовым лидером Тревином Чоу выстроили продуктовые workflow, чтобы методология приносила столько же пользы продакт-менеджерам и основателям, сколько и инженерам. В этом кэмпе они расскажут, что нового, глубже разберут этапы brainstorm и ideate и поделятся примерами применения compound engineering за пределами инженерной работы. [Прочитайте полное руководство по compound engineering](https://every.to/guides/compound-engineering?source=post_button), [установите плагин](https://github.com/EveryInc/compound-engineering-plugin) и [присоединяйтесь к нам на кэмпе](https://every.to/events/compound-engineering-camp-2). — [Кейт Ли](https://every.to/@kate_1767)

Я потратил три месяца, пытаясь заставить рои агентов работать.

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

Я перепробовал всё — команды Claude Code, агентов, делегирующих задачи другим агентам, оркестрационные схемы, где ведущий агент управлял пулом работников. Много итераций, много сожжённых токенов.

Но большее количество агентов не делало меня быстрее. Я запускаю параллельные сессии Claude Code уже несколько месяцев — это работает, когда у каждого агента есть чёткая задача, а я направляю работу. Эксперимент с роем был другим: агенты координировались между собой, сами решали, над чем работать, и выдавали результат, который я не формировал. Когда 10 из них заканчивали одновременно, у меня оказывалось 10 результатов для оценки без достаточного контекста, чтобы понять, каким из них можно доверять. У AI-агентов нет ограничения скорости, но у человека, который ими управляет, оно есть.

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

Это было то, что у меня уже было, — папка.

Папка проекта с файлом CLAUDE.md/AGENT.md (файл, который говорит AI, как работать в вашем проекте), несколькими определениями skills и контекстом, накопленным за месяцы compound engineering, — вот это и есть агент. Контекст, который папка даёт AI-модели, превращает универсальную модель в специалиста в любой задаче или области, в которой вы хотите, чтобы она блистала.

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

Агенты, прячущиеся на вашем жёстком диске

Люди слышат «агент» и представляют себе машину Руба Голдберга — десятки комично сложных движущихся частей, каждая запускает следующую. Но агент намного проще: это модель с достаточным контекстом, чтобы вам не приходилось заново объяснять всё каждый раз, когда вы открываете чат.

Вот пример: весь код Cora лежит в папке проекта в организации Every на GitHub. Когда я открываю эту папку в Claude, Claude видит код и структуру. Но он не знает моего стиля работы и того, что мне важно, — поэтому в папке также есть файл CLAUDE.md. Этот файл рассказывает Claude, как я называю сущности и как структурирую тесты. Это и есть агент — не вычурный, но всё же агент. Просто направив модель на эту папку, в которой содержится часть моей личности, знаний и вкуса, можно сделать модель специалистом по моей кодовой базе.

Claude Skills — файлы, дающие модели конкретные возможности, — это пример такой структуры «папка как агент». Задолго до того, как это стали называть «skills», люди уже писали markdown-файлы, полные инструкций, и складывали их в директории проектов.

Моя папка ~/cora/ идёт ещё дальше:

• Соглашения и стандарты: CLAUDE.md покрывает соглашения Rails, workflow деплоев и паттерны работы с базой данных.
• Институциональные знания: директория docs/developer-docs/ хранит накопленные знания, которые любой новый агент наследует автоматически — архитектурные отчёты, email processing pipeline и дизайн ассистента.
• Операционная память: docs/runbooks/ и docs/investigations/ фиксируют операционные паттерны, выстроенные на реальных инцидентах.
• Специализированные агенты: .claude/agents/ содержит специалистов, которых я оттачивал месяцами: ревьюеров, планировщиков и assistant-component-creator.

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

Порядок чтения, который я даю каждому новому агенту, взаимодействующему с Cora, такой: сначала читай CLAUDE.md, затем архитектурный документ, затем отчёт о системе ассистента, затем промпт ассистента, а потом агента component creator.

Мой репозиторий Cora служит живой системой памяти: соглашения, runbook'и и специализированные агенты уложены слоями так, что любая новая модель мгновенно наследует, как Cora думает и работает. (Все изображения предоставлены Кираном Клаассеном.)

~/cora-agent/, другая папка, — это совершенно иной агент, хотя работает на той же модели. (Я в основном использую Opus 4.6, но также мне нравятся GPT 5.4 и Gemini Pro 3.1.)

Там, где ~/cora/ строит фичи, ~/cora-agent/ обслуживает эксплуатацию. В ней нет кода приложения, поэтому она не может случайно изменить продакшн-код во время эксплуатационных работ. Вместо этого у неё есть skills для:

• Опроса AppSignal для проверки ошибок и проблем с производительностью в живой системе Cora
• Слежения за логами Render в реальном времени, чтобы ловить проблемы по мере их возникновения
• Извлечения данных из read replica Postgres (копии базы данных Cora), чтобы запрашивать пользовательские данные, не трогая боевую версию
• Чтения тикетов Intercom, чтобы связывать жалобы клиентов с техническими проблемами
• Корреляции деплоев GitHub с продакшн-инцидентами, прослеживая поломку к конкретному изменению кода, которое её вызвало

Директория .claude/skills/ — это cockpit, единое место, где агент может видеть каждую систему, от которой зависит Cora, и взаимодействовать с ней. У каждой внешней системы, с которой Cora соприкасается, есть справочный файл, который точно говорит агенту, как с ней общаться. В директории bin/ крутятся непрерывно работающие Ruby-демоны (фоновые процессы): планировщик, обработчик входящих, который автоматически сортирует поступающие issues, и монитор здоровья, перезапускающий зависшие процессы. Три постмортема лежат в docs/postmortems/. Плотный журнал деплоев покрывает каждый pull request Cora с марта по апрель.

Просто меняя папку, а не модель, я получаю другого агента. Направь Opus на ~/cora/ — и это Rails-инженер. Направь его на ~/cora-agent/ — и это ops-инженер, который знает нашу историю инцидентов, нашу сервисную топологию и точно знает, в какой Slack-канал нужно написать.

Утро с 44 агентами

Когда осознаёшь, что папка и есть агент, их можно запускать сколько угодно. У меня есть горстка специализированных папок, но в любой момент параллельно крутится 44 агента: несколько работают внутри ~/cora/ одновременно над разными задачами, другие мониторят продакшн из ~/cora-agent/, третьи занимаются оркестрацией. Те же самые папки, просто разные задачи происходят параллельно.

Очевидный вопрос: а кто же управляет этими 44?

Несколько месяцев ответ был такой: я, вручную. Я открывал вкладку терминала, переходил в папку проекта, запускал сессию Claude Code, давал ей задачу, открывал другую вкладку и делал то же самое. Я был диспетчерским слоем — отслеживал, какой агент над чем работает, какие задачи закончены, а какие застряли. Это работало, когда у меня было пять агентов. На десяти я начал забывать, что где запущено. На 44 это стало невозможным. Баги, которые, я знал, легко починить, висели нетронутыми днями, а ревью pull request'ов скапливались.

Поэтому я построил диспетчерский слой: систему, которая сидит над папками и маршрутизирует работу между ними. Есть Ruby-демон, который следит за директорией на предмет запросов на spawn. Когда я прошу его оркестрировать задачу, он создаёт lead-агента, лид разбивает задачу на подзадачи и записывает каждую как файл, а демон подхватывает эти файлы и спавнит worker-агентов в нужных папках. Воркеры отчитываются, записывая файлы. Демон проверяет статус каждые 60 секунд. Никакой кастомной сети или протокола «агент к агенту» не нужно.

В результате я перешёл от ручного жонглирования вкладками терминала к управлению всей моей инженерной поверхностью из одного места. Я взаимодействую с диспетчерским слоем через slash-команды в Claude Code. Две из них делают основную работу:

Две команды, которые заменяют 20 вкладок терминала

• Утренний брифинг: я набираю /hey в Claude Code и получаю отчёт о статусе. По каждому проекту система проверяет, что было завершено, что выдало ошибку, что заблокировано, и какие появились новые высокоприоритетные issues. Одна команда выдаёт полную картину того, что требует моего внимания в основной кодовой базе Cora, в ops-среде и в оркестрационной системе.
• Запуск задачи: я набираю /orchestrate, чтобы запустить задачу, например, /orchestrate «Исправь GitHub issue #1765». Система создаёт lead-агента, который разбивает задачу и спавнит воркеров в нужных папках. Каждый воркер наследует полный контекст этой папки — её CLAUDE.md, агентов и накопленные знания. Воркеры выполняют работу. Появляется pull request, и я его ревьюю.

С помощью команды /orchestrate lead-агент делегирует работу специализированным воркерам в разных контекстах, и вы наблюдаете, как вся система думает параллельно.

Каждый агент получает панель, которую я могу смотреть вживую в tmux (терминальный инструмент для запуска нескольких сессий одновременно). Дашборд показывает мне живую карту под названием agent tree, где видно каждого агента и его статус — работает, ждёт, готов или ошибка. Pull request'ы и комментарии к GitHub issues приходят для асинхронного ревью. Я обрабатываю результаты, когда готов, а не когда агенты заканчивают свои задачи.

Всё это крутится на Ruby-демоне с файловой передачей сообщений. Диспетчерский слой — это не какая-то изощрённая инфраструктура. Изощрённость лежит в папках под ним — каждая из них специалист, построенный через месяцы обучения на работе.

Собственное исследование Anthropic подтверждает, почему этот паттерн работает: lead-агент Opus с суб-агентами Sonnet превосходил одиночного Opus-агента на 90 процентов в исследовательских задачах. Но они также обнаружили, что мульти-агентные системы сжигают в 15 раз больше токенов, чем одно-агентные, и что у большинства кодовых задач меньше параллелизуемых шагов, чем у исследовательских, — это затрудняет их разбиение между агентами. Диспетчерский слой не заменяет меня — он берёт на себя трекинг, так что я по-прежнему решаю, какую работу делать и куда её направлять.

Что ломается на масштабе (и почему нельзя vibe orchestrate)

Из этой утренней прогулки всё звучит гладко, но так бывает не всегда.

Баг с кодировкой был моей любимой катастрофой. Неделями агенты случайным образом падали посреди задачи, а сообщение об ошибке ничего толком не объясняло. Я перелопачивал логи, проверял API-ответы, тестировал сетевые конфигурации. Виновниками оказались длинные тире и «умные» кавычки — символы из текста, который я копировал-вставлял в промпты. Мой демон работал на кодировке US-ASCII, которая распознаёт только простые английские буквы, так что эти специальные символы его крашили. Фронтир AI-ассистированной разработки полон таких проблем: откровенно глупых и шокирующе трудных для поиска.

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

У этой схемы есть и подлый изъян — зависания агентов. Агент делает слишком много API-вызовов слишком быстро или застревает в ожидании ввода, и его статус остаётся «работает» бесконечно. Вы не заметите, пока не проверите, а когда управляете 44 агентами, проверяете не всегда.

Эти провалы указывают на главный урок, который я усвоил: нельзя vibe orchestrate.

Так же, как нельзя vibe code — вам нужны планы до того, как вы начнёте строить, — и нельзя vibe fix, когда что-то ломается в продакшне, нельзя отдать папку диспетчерскому слою и надеяться на лучшее. Когда я начинаю новый проект, я не отдаю его диспетчерскому слою сразу. Я настраиваю папку, строю агента, устанавливаю потоки — петлю compound engineering — и использую их сам, пока они не станут предсказуемыми. Только когда я доверяю потоку, я передаю его диспетчерскому слою и перестаю наблюдать. Если пропустить этот шаг, у вас появятся агенты, которые открывают pull request'ы для уже сделанной работы, и создают дубликаты issues. Порядок работы критичен: построй, используй, доверься, а потом оркестрируй.

Ваша папка уже агент

Я начинал весь этот эксперимент, пытаясь построить рой. Закончил с 44 папками, в каждой из которых — специализированный контекст, выстроенный через месяцы работы, связанные диспетчерским слоем.

Это не то, чего я ожидал, но это работает. У вас тоже есть строительные блоки, чтобы создать то же самое.

Если в вашем проекте есть CLAUDE.md и какие-то файлы в .claude/ — у вас уже есть агент. Вы просто не относились к нему как к агенту.

Вот эксперимент для вас: посмотрите на папку своего проекта. Это универсальная настройка или специалист? Если универсальная — если ваш CLAUDE.md это boilerplate, скопированный из чьего-то блог-поста, — потратьте 30 минут, чтобы сделать его своим. Добавьте свои соглашения, свои паттерны, свои мнения о том, как надо писать код. Потом попробуйте запустить двух агентов в отдельных git worktree (отдельные копии кодовой базы, чтобы они не мешали друг другу) и заметьте, где вы сами тормозите процесс. Именно туда должен встать диспетчерский слой.

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

Следующий шаг уже приближается. Anthropic только что запустила Claude Managed Agents — хостед-сервис, который берёт на себя песочницу, управление состоянием и выполнение инструментов, чтобы разработчики могли сосредоточиться на том, что делают их агенты, а не на том, как поддерживать их работу. Паттерн «папка как агент» делает возможной такую управляемую автономность: доверенная, специализированная среда, внутри которой модель может работать без вашего постоянного присмотра.

Индустрия тратит много энергии на автономные рои. Я тоже провёл там три месяца и обнаружил, что пока ответ — просто папка.

--- Идти дальше

• Прочитать исчерпывающий гайд Кирана по compound engineering
• Установить плагин compound engineering
• Посмотреть запись с прошлого кэмпа Кирана по compound engineering

Благодарность [Кэти Парротт](https://every.to/@katie.parrott12) за редакторскую поддержку.

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot