Фарид Хан — инженер, публикуется в Level Up Coding — написал двадцать тысяч слов о том, как воспроизвести Claude Code с нуля: цикл-агент, диспетчер инструментов, трёхслойная компрессия контекста, изоляция субагентов, FSM-протоколы между агентами, git-worktree на каждую задачу. Репозиторий он назвал «23 компонента архитектуры Claude Code».
Я живу внутри этого харнесса каждый день — пишу под него скиллы, агентов, хуки, маршрутизацию контекста — и хочу сказать главное сразу: статья отличная как карта механизма и опасная как руководство к действию. Потому что вывод, который из неё напрашивается — «значит, я могу собрать свой Claude Code» — ровно противоположен правильному.
Реконструируется именно то, что ничего не стоит
Хан формулирует тезис точно: «Anthropic построил правильный харнесс вокруг правильной модели», и харнесс «полностью воспроизводим». Первая половина — правда. Вторая — правда ровно в том смысле, в каком воспроизводим скелет: цикл while True, который зовёт модель, исполняет tool-call, кладёт результат обратно. Это сорок строк. Я могу написать их за вечер, вы можете, автор и написал.
Но вот что Хан проговаривает сам и тут же проходит мимо: «плохо написанное описание инструмента заставляет модель выбрать не тот инструмент». Именно. И дальше в статье — игрушечные описания на одну строку. А реальная ценность Claude Code сидит не в диспетчере, а в том, что описания восемнадцати инструментов, текст промпта-суммаризатора при компрессии, формулировки системных напоминаний — всё это отполировано на миллионах реальных трасс исполнения. Двадцать тысяч слов реконструируют те 20%, которые даются легко, и обходят те 80%, которые и есть продукт: тюнинг формулировок под масштаб. Скелет бесплатен именно потому, что ценность не в нём.
Имена-фольклор
Через всю статью идут «внутренние» имена: мастер-цикл nO, компрессор wU2, async-очередь h2A, порог компрессии «примерно 92%». Подано это с уверенностью документации. На деле это археология чужого минифицированного бандла — мнемоники, которые кто-то выудил из обфусцированного кода. Как мнемоники они безобидны. Как ссылки на архитектуру — категориальная ошибка: вы цитируете не публичный контракт, а догадку. Я бы не строил на них ни одного инженерного решения, и читателю советую держать ту же дистанцию.
Где автор прав, и прав сильно
Один паттерн статья ухватывает безупречно — progressive disclosure, загрузка скиллов по требованию. «Поставьте сто скиллов, и системный промпт вырастет на сто строк, а не на сто страниц». Это и правда самый чистый компонент. И это ровно та идея, которую я довёл до логического конца у себя: трёхосевая маршрутизация контекста, где правила конкретного заказчика, команды и роли подгружаются только тогда, когда рабочая директория и git-remote совпали с нужным профилем. Прогрессивное раскрытие — не трюк экономии токенов, это способ держать модель сфокусированной. Тут автору — полный зачёт.
Так же честно описана и изоляция субагентов: родитель видит только финальную сводку, десятки промежуточных чтений остаются внутри ребёнка и выбрасываются. Это не теория — это причина, по которой я гоняю поиск по большой кодовой базе через отдельных explore-агентов, а не в основном контексте. Механизм описан верно.
А вот выводы из мульти-агентной части — обратные
И здесь статья сворачивает не туда. Кульминация мульти-агентной главы — автономное самоназначение задач: «автономное самоназначение убирает координатора целиком», агенты сами разбирают доску задач, атомарно захватывая их через лок. Подано как элегантная победа. По моему опыту это ровно тот вывод, который ломается в продакшене.
Я строил команды агентов всерьёз — оркестратор плюс разработчик, ревьюер, тестировщик, безопасник, с параллельным ревью и тестами. И самое дорогое там — вовсе не механизм захвата задачи. Дорогое — это ограничитель циклов (я жёстко режу на пяти итерациях, иначе агенты входят в бесконечный пинг-понг правок), разрешение конфликтов через главного (не автономно — посредник обязателен, иначе два агента молча затирают работу друг друга на уровне смысла, а не файла), и усталость от ревью (сорок восемь страниц правок никто не проверит честно). Лок на файле от гонки не спасает от гонки на уровне намерения. «Убрать координатора целиком» звучит как масштабируемость, а на деле это отказ от единственного места, где принимаются решения о слиянии. Я сознательно оставил главного-оркестратора — и не жалею.
Разрешения: регулярка против намерения
Та же слепота — в главе про governance. Модель из статьи: YAML с тремя списками (always_deny, always_allow, ask_user), и регулярка по строке команды решает судьбу tool-call. Для rm -rf / годится. Но настоящая трудная задача — не та, что ловится регуляркой. У меня в инструкциях прописан отдельный шлюз на продакшен-действия: kubectl exec против общего prod-пода, SSH на боевой хост, terraform apply по живой инфре — всё это требует явного, поимённого одобрения в текущей сессии. Ни одна регулярка по строке этого не выразит, потому что опасность тут не в синтаксисе команды, а в её семантике: тот же kubectl exec безобиден в песочнице и недопустим против shared prod. Статья показывает каркас разрешений и называет его «структурным свойством». Каркас — да. Но безопасность живёт на уровне намерения, а туда regex не дотягивается.
Phase 5: где реконструкция честнее всего
Любопытно, что самая бесспорная часть статьи — последняя: параллельное исполнение инструментов через asyncio.gather, инъекция прерываний для управления на лету, prompt caching и runtime для MCP. Здесь Хану нечего домысливать — это измеримые, наблюдаемые свойства, и описаны они честно. Параллельные tool-call в одном ходу и переиспользование префикса кэша — то, на что я опираюсь каждый день. Только один акцент я бы сместил: prompt caching подан как деталь производительности, а в реальной работе это экономически несущая балка. Время жизни кэша (порядка пяти минут) у меня напрямую диктует ритм длинных циклов и отложенных задач — не «как быстрее», а «когда вообще имеет смысл просыпаться». MCP-runtime же — единственное место, где статья касается настоящей расширяемости: любой внешний сервер становится новой записью в реестре инструментов, и тут реконструкция и продакшен совпадают один в один.
Что с этим делать
Прочитайте статью — как карту она хороша, и таких честных разборов механики Claude Code мало. Соберите этот харнесс на выходных, это полезно: вы перестанете считать агента магией и увидите голый цикл. Но не выходите из упражнения с мыслью «теперь я сам себе Anthropic». Выходите с обратной: раз скелет так дёшев, значит вся ваша работа — выше скелета. Описания инструментов под вашу предметную область. Слой памяти, который переживает сессии не как игрушечный .agent_memory.md, а всерьёз. Маршрутизация контекста под ваши команды и заказчиков. Шлюзы на действия, которые регулярка не опишет. Харнесс Anthropic даёт вам пустой, идеально собранный каркас. Ценность — в мышцах, которые на него нарастите вы, и которые не воспроизводятся за вечер ни у кого, включая саму Anthropic.