Статья представляет собой глубокий технический анализ исходного кода Claude Code (v2.1.88), утекшего 31 марта 2026 года, рассматривая его как ценный пример архитектуры инженерии передовых AI-агентов.

Автор статьи, источник: Max

Сегодня (31 марта 2026 года) Anthropic снова из-за грубой ошибки в процессе упаковки обнажила полный фронтенд и исходный код клиента своей последней версии Claude Code (v2.1.88) в репозитории npm.

Пользователь опубликовал файл cli.js.map, который не был удален, что позволило напрямую восстановить около 1900 файлов и более 510 000 строк исходного кода на TypeScript.

Для Anthropic это еще одно серьезное нарушение операционной безопасности после утечки документации по модели Mythos несколько дней назад.

Однако для разработчиков и исследователей отрасли, работающих на уровне приложений крупных моделей, этот исходный код представляет собой бескомпромиссный и чрезвычайно ценный технический документ по архитектуре передовых AI Agent.

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

Если рассматривать это не как сплетню, а как пример архитектуры производственного ИИ-ассистента для программирования, в нем содержится множество инженерных решений, выходящих за рамки традиционного мышления.

Ниже приведен подробный технический разбор архитектуры, механизма планирования, системы памяти и стратегий безопасности Claude Code с объективной точки зрения.

Статья достаточно длинная и подходит для специалистов, занимающихся AI Infra, разработкой агентов и интересующихся архитектурой прикладного уровня крупных моделей.

ЧАСТЬ 01. Это не просто CLI-инструмент

Из структуры каталога (около 40 первоуровневых модулей в папке src) видно, что сложность Claude Code значительно превышает сложность текущих открытых однородных агентов на рынке.

Его выбор технологического стека очень практичный и ориентированный на опыт взаимодействия с конечным пользователем:

Язык — TypeScript, среда выполнения — более агрессивный по производительности Bun, фреймворк CLI — Commander, а слой рендеринга в терминале неожиданно использует React + Ink.

Зачем командной строке нужен React?

Ответ содержится в файле screens/REPL.tsx в исходном коде (более 5005 строк).

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

Использование декларативного React в сочетании с минимальным пользовательским хранилищем в стиле Zustand (state/store.ts) — это наилучшая инженерная практика для обработки частых локальных обновлений.

В режиме работы система строго разделена на два вида:

Интерактивный режим REPL: передовая терминальная UI, основанная на Ink, в первую очередь для человеческих разработчиков.

Безголовый/SDK-режим (класс QueryEngine): полное отделение интерфейса, поддержка потокового вывода в формате JSON. Это закладывает основу для последующего внедрения в качестве базового движка в IDE (например, в стиле Cursor) или в процессы CI/CD.

Процесс запуска системы также был максимально оптимизирован для параллельной обработки.

В main.tsx I/O-интенсивные операции, такие как чтение конфигурации (MDM Settings) и предварительная выборка ключей Keychain, выполняются в дочерних процессах параллельно с загрузкой основного модуля, занимающей около 135 мс. Такая требовательность к миллисекундам при уменьшении задержки запуска пронизывает всю кодовую базу.

ЧАСТЬ 02. Инженерия кэша подсказок

Это самая технически сложная часть исходного кода и основное барьерное отличие между Claude Code и обычными приложениями с оболочкой.

В настоящее время инструменты Agent при обработке длинного контекста часто просто и грубо объединяют системный промпт и историю диалога.

В то же время в файле services/api/claude.ts сервиса Claude Code (ядро взаимодействия, состоящее из 3419 строк) сборка промптов выполнена с точностью до байта.

Как известно, механизм кэширования запросов Anthropic использует сопоставление по префиксу (Prefix Matching).

Для максимизации коэффициента попаданий в кэш Claude Code использует тщательно спроектированную архитектуру сегментированного кэша:

Статический раздел (глобально кэшируемый): генерируется через systemPromptSection(), содержит введение личности модели ("You are Claude Code..."), системные правила безопасности, ограничения стиля кода, базовые руководства по использованию инструментов и т.д. Эта часть практически не изменяется в течение всего срока сессии.

Динамическая граница: в исходном коде жестко закодирована специальная метка SYSTEM_PROMPT_DYNAMIC_BOUNDARY.

Динамический сегмент (кэширование на уровне сессии/без кэширования): содержит часто изменяющиеся данные, такие как информация о текущей рабочей директории (CWD), статус Git, инструкции MCP (Model Context Protocol) и пользовательские настройки.

А также для предотвращения проникновения кэша из-за незначительных изменений в запросе система выполнила множество кажущихся громоздкими резервных мер:

Определённая сортировка: описания инструментов, передаваемые крупной языковой модели, строго сортируются по алфавиту по принципу встроенного префикса инструмента + суффикса MCP.
Хеширование пути: путь к профилю не использует случайный UUID, а основан на хеше содержимого, чтобы избежать сбоя кэша из-за изменения пути при каждом вводе.
Внешнее состояние: даже список текущих доступных агентов был удален из описания инструментов и перемещен в вложения сообщения. Согласно комментариям в исходном коде, одно только это изменение сократило потребление токенов создания кэша примерно на 10,2%.

Всё это говорит о текущем состоянии отрасли: на данном этапе качественная разработка приложений ИИ по сути представляет собой жадное и тонкое извлечение ценности из кэширующих систем API.

ЧАСТЬ 03 Инструменты и потоковое параллельное выполнение

Claude Code встроен более чем 40 инструментами (включая чтение и запись файлов, выполнение Bash, веб-скрапинг и т.д.), а архитектура его инструментальной системы использует высоко модульный паттерн фабрики (Factory Pattern).

Каждый инструмент наследует базовый интерфейс Tool и должен реализовывать методы, такие как checkPermissions(), validateInput() и isConcurrencySafe() (безопасен ли для многопоточности).

Механизм ToolSearch с динамической загрузкой: когда количество инструментов превышает определенный порог, включение описаний всех инструментов в Prompt приведет к неприемлемым затратам на токены.

В исходном коде представлена элегантная стратегия под названием ToolSearch: неключевые инструменты (например, некоторые специализированные аналитические плагины) помечаются как defer_loading: true.

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

StreamingToolExecutor (потоковый исполнитель инструментов): для повышения эффективности выполнения система поддерживает параллельный вызов инструментов.

Координатор (toolOrchestration.ts) разделяет запросы на вызов инструментов, возвращенные крупной моделью, на параллельные и последовательные пакеты.

Инструменты, безопасные при параллельном выполнении (например, одновременное чтение нескольких независимых файлов, параллельный запуск веб-поиска), будут запущены параллельно, тогда как инструменты, не безопасные при параллельном выполнении (например, последовательное изменение одного и того же файла кода), будут строго выполнены последовательно.

Инструменты для работы с большими наборами результатов (например, полный поиск по Grep) имеют лимит maxResultSizeChars; содержимое, превышающее этот лимит, обрезается и сохраняется локально во временный файл, а LLM получает только предварительный обзор, чтобы избежать переполнения окна контекста.

Часть 04. Механизм форка для устранения загрязнения контекста

Текущий монолитный агент имеет смертельный недостаток:

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

Claude Code вводит сложные механизмы координаторного режима (Coordinator Mode) и форк-субагентов (Fork Subagent) для решения этой проблемы.

После включения режима координатора в переменных среды система будет перестроена в архитектуру Coordinator-Workers:

Координатор: лишен прямого доступа к файлам, сохранены только инструменты Agent, SendMessage и TaskStop. Его единственная задача — планирование рабочего процесса (Исследование → Синтез → Реализация → Проверка).
Работники (исполнители): создаются с конкретным описанием инструментов.

Самым достойным восхищения является его механизм наследования форка.

При необходимости проведения масштабного исследования кода Coordinator создает Explore Agent.

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

После завершения исследования подагенту необходимо передать извлеченные ключевые выводы (Synthesis) в главный контекст координатора только через специальный XML-формат .

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

ЧАСТЬ 05. Прорыв в параллельном механизме агентного роя

Помимо последовательного механизма Fork, используемого для решения проблемы загрязнения контекста, исходный код демонстрирует более амбициозную архитектуру параллельных агентов — кластер Swarm (Teammate).

Эта логика в основном скрыта в каталогах utils/swarm/ и tasks/.

Система поддерживает тип задачи под названием in_process_teammate.

В такой архитектуре основной процесс может одновременно пробуждать несколько агентов (называемых Teammate), чтобы они выполняли разные задачи.

Однако в среде терминала CLI одновременная работа нескольких агентов сталкивается с двумя критическими инженерными проблемами: конфликты всплывающих окон разрешений и путаница в отображении интерфейса.

Решение Anthropic чрезвычайно изящно:

Права лидера (permissionSync.ts): все дочерние процессы Teammate не могут напрямую запрашивать разрешения у пользователя. Они перенаправляют запросы разрешений через внутренний канал «мосту» агенту лидера главного процесса, который единым образом осуществляет безопасную блокировку и подтверждение пользователя в основном терминале.
Автоматизация макета терминала: чтобы пользователи могли четко отслеживать состояние работы нескольких параллельных агентов, исходный код напрямую интегрирует команды AppleScript для iTerm2 и Terminal.app. При создании нового Teammate система автоматически разделяет панели терминала (Split Pane), выделяя отдельное окно вывода для каждого подагентов.

Это означает, что ИИ официально переходит от «одиночного мышления» к «кластерной параллельной координации».

ЧАСТЬ 06 Dream (Сон) архитектура памяти

Сегодня, когда RAG (检索增强生成) широко распространён, почти все AI-продукты интегрируют векторные базы данных (Vector DB).

Однако удивительно, что система памяти Claude Code (memdir/ модуль) чрезвычайно ретро и практична: она полностью основана на локальной файловой системе.

Его архитектура состоит из центрального файла MEMORY.md (в качестве высокого уровня индекса, ограниченного максимум 200 строками/25 КБ) и нескольких тематических файлов в формате Frontmatter.

Память точно разделена на четыре категории: User, Feedback, Project, Reference.

Еще интереснее скрытый в исходном коде режим помощника KAIROS.

Это режим фоновой работы (Daemon), который еще не был официально выпущен.

В режиме KAIROS система памяти больше не является простым обновлением индексов, а использует режим добавления, аналогичный человеческому журналу (запись в logs/YYYY/MM/YYYY-MM-DD.md).

В ночное время или во время простоя фоновый процесс запускает офлайн-задачу под названием Dream.

Задача этого агента — резюмировать и фильтровать дневные журналы транзакций, а затем извлекать и фиксировать их в структурированные долгосрочные тематические файлы.

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

ЧАСТЬ 07. Сужение прав и безопасность

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

Частые всплывающие окна, требующие подтверждения от пользователя, полностью разрушают автоматизированный опыт, тогда как автоматическое выполнение без ограничений может привести к сбою системы (например, при случайном выполнении rm -rf).

Claude Code использует многоуровневую архитектуру сжатия прав доступа:

От файловой/сетевой песочницы на базе @anthropic-ai/sandbox-runtime до жестко закодированных блокировок специфических опасных операций (например, git push --force) и проверок на уровне инструментов.

Но самым примечательным является его компонент под названием Auto Mode Classifier (yoloClassifier.ts).

Когда пользователь включает автоматический режим, система не использует жесткие регулярные выражения для оценки опасности команд, а применяет механизм бокового запроса (Side Query).

Система в фоновом режиме вызывает более мелкую и менее дорогую LLM, передавая ей сокращенную транскрипцию текущего диалога и предстоящую команду Bash, чтобы этот побочный модельный модуль выдал решение Allow или Deny.

Кроме того, в системе существует пороговый механизм отслеживания отказов: при частых отказах автоматических инструментов система плавно переходит в режим запроса подсказок для привлечения человека.

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

ЧАСТЬ 08 Несколько небольших сюрпризов

Наконец, наличие множества флагов функций (таких как VOICE_MODE, SSH_REMOTE) и проверок переменных окружения process.env.USER_TYPE === 'ant' в исходном коде демонстрирует двойные стандарты крупных компаний при внутреннем тестировании и внешнем выпуске.

Для внутренних сотрудников Anthropic (только Ant): требования к коду, встроенные в систему, чрезвычайно строги, даже параноидальны:

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

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

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

Стоит отметить, что в коде содержатся два интересных модуля.

Режим под прикрытием (Undercover Mode):

Это функция, вызывающая споры в сообществе безопасности.

В сценарии, когда сотрудники работают с открытыми или общедоступными репозиториями, эта функция включена по умолчанию и не может быть принудительно отключена. В этом режиме в запросе явно указывается модели: «Do not blow your cover» (не раскрывайте свою личность), а также принудительно удаляются все дисклеймеры или следы, сгенерированные ИИ.

С точки зрения общественных отношений это может казаться недостаточно прозрачным, но косвенно подтверждает абсолютный контроль производителя над ролевым поведением модели и ее выводами.

Секретная функция Buddy System (электронное домашнее животное):

Исходный код содержит скрытую систему виртуального питомца (генерация уток, сов и т.д.).

Для обеспечения случайности и определенности генерации питомцев инженеры использовали ID пользователя в сочетании с алгоритмом псевдослучайной генерации Mulberry32.

typescript

18 видов: утка, гусь, blob, кошка, дракон, осьминог, сова, пингвин, ...

5 степеней редкости: common (60%), uncommon (25%), rare (10%), epic (4%), legendary (1%)

// Атрибуты: ОТЛАДКА, ТЕРПЕНИЕ, ХАОС, МУДРОСТЬ, САРКАЗМ

// Аксессуары: корона, цилиндр, пропеллер, ореол, волшебник, шапочка, крошечная утка

// Особое: 1% вероятность shiny

Самый смешной деталь заключается в том, что английское название одного из животных совпадает с крайне секретным внутренним кодовым именем модели Anthropic (возможно, это недавно утекшая самая мощная Claude-капибара).

Чтобы обойти проверку запрещенных слов сканером кода соответствия, инженеры использовали String.fromCharCode() для динамической сборки этого слова.

Этот юмористический подход гиков в крайне серьезном коде инфраструктуры выглядит по-своему уникально.

Часть 09. Что мы можем узнать?

За короткий промежуток времени произошло утечка как технической документации по ключевой модели, так и исходного кода ключевого приложения; Anthropic действительно должна провести глубокий анализ своих внутренних процессов управления. Однако технология ни в чем не виновата — этот код объемом в 510 000 строк является отличным учебным материалом для отрасли.

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

Настоящие барьеры созданы за счёт крайней экономии на стоимости токенов (оптимизация Prompt Cache), потокового планирования взаимодействия нескольких состояний (механизмы Coordinator и Fork), баланса между терпимостью к намерениям пользователя и безопасностью (YOLO Classifier), а также глубокой интеграции с файловыми потоками хост-операционной системы.

В настоящее время репозитории, форкнувшие этот исходный код на GitHub, находятся под угрозой немедленного удаления по запросу DMCA.

Однако, независимо от всего прочего, уровень инженерной реализации, продемонстрированный Claude Code, задал новый технологический стандарт для продуктов AI-ассистентов к 2026 году.

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