Claude Code: анализ архитектуры и будущие направления (Часть 5 из 5)

Часть 5 из 5 · Серия «Архитектура Claude Code» → /claude-code-series

10. Сравнительный анализ: Claude Code и OpenClaw

Предыдущие разделы задокументировали ответы Claude Code на повторяющиеся вопросы о loop-архитектуре, безопасности, расширяемости, управлении контекстом, делегировании и устойчивости. Чтобы откалибровать выводы, этот раздел сравнивает Claude Code с OpenClaw — независимой open-source системой ИИ-агентов, которая отвечает на многие из тех же вопросов проектирования из принципиально иной стартовой точки. OpenClaw — local-first WebSocket-gateway, соединяющий примерно два десятка messaging-поверхностей (WhatsApp, Telegram, Slack, Discord, Signal и другие) со встроенным agent-runtime, с companion-apps на macOS, iOS и Android (Steinberger and OpenClaw Contributors, 2026). Там, где Claude Code — CLI-coding-harness, привязанный к одной репозиторной сессии, OpenClaw — persistent control plane для мультиканального персонального ассистирования. Две системы занимают разные регионы пространства проектирования агентов. Ценность сравнения — показать, как одни и те же повторяющиеся вопросы дают разные архитектурные ответы при смене контекста развёртывания.

Table 3. Архитектурное сравнение: Claude Code vs. OpenClaw по шести измерениям

Table 3 Architectural comparison: Claude Code vs. OpenClaw across six design dimensions. Each row captures a recurring design question and the different answers the two systems provide.

10.1. Шесть измерений сравнения

Table 3 сводит сравнение по шести измерениям. Каждое соответствует вопросу проектирования, на который обе системы должны ответить.

System scope and deployment model. Claude Code работает как ephemeral CLI-процесс, привязанный к одному репозиторию. Каждая сессия начинается и заканчивается вместе с терминалом. OpenClaw работает как persistent-демон (default-порт 18789, loopback-only), владеющий всеми соединениями messaging-поверхностей и координирующий клиентов, инструменты и device-узлы через типизированный WebSocket-протокол. Это различие в system scope — самое фундаментальное архитектурное расхождение: оно определяет, как формулируется каждый другой вопрос проектирования. Существует и composition-relationship: OpenClaw может host Claude Code, OpenAI Codex и Gemini CLI как внешние coding-harness через ACP-интеграцию (Agent Client Protocol), делая эти две системы stackable, а не чисто альтернативными.

Trust model and security architecture. Системы адресуют разные threat-модели. Claude Code предполагает untrusted-модель, работающую внутри trusted-машины разработчика: permission-система deny-first (Section 5) оценивает каждый вызов инструмента, ML-классификатор даёт автоматизированную safety-оценку, а семь permission-модов создают градуированный autonomy-спектр. OpenClaw предполагает единого trusted-оператора на экземпляр шлюза. Архитектура безопасности начинается с identity и access control (DM pairing codes, sender allowlists, gateway authentication), а не с per-action safety-классификации. Tool-policy использует настраиваемые allow/deny-списки на агента, а не централизованный классификатор. Sandboxing доступен как opt-in-фича с несколькими бэкендами (Docker, SSH или OpenShell) и настраиваемым scope (per-agent, per-session или shared); non-main-режим может sandbox-ить все не-main-сессии при включении, хотя sandboxing не активен по умолчанию. Документация безопасности OpenClaw явно констатирует: hostile multi-tenant isolation на общем шлюзе не является поддерживаемой safety-границей. Это различие отражает выбор о том, где находится trust-граница: Claude Code помещает её между моделью и средой исполнения; OpenClaw — на периметре шлюза.

Agent runtime and tool orchestration. Обе системы реализуют агентные циклы, но эти циклы занимают разные позиции в своих архитектурах. В Claude Code async-генератор queryLoop() (Section 4) — центр системы: все интерфейсы кормят его, и он прямо управляет сборкой контекста, tool-dispatch и восстановлением. В OpenClaw agent-runtime (embedded Pi-agent-core) сидит внутри большего gateway-dispatch-слоя. agent-RPC шлюза валидирует параметры, разрешает сессии и немедленно возвращается; embedded-runner затем исполняет агентный цикл, излучая lifecycle- и stream-события обратно через gateway-протокол. Прогоны сериализуются через per-session-очереди и опциональный global-lane, не давая tool- и session-гонкам на мультиканальной поверхности. Обе системы следуют ReAct-паттерну (Yao et al., 2022), но цикл OpenClaw — компонент внутри control plane, а не сам control plane.

Extension architecture. Четыре механизма расширения Claude Code (MCP, plugins, skills, hooks) организованы по контекстной цене (Section 6): хуки потребляют ноль контекста, skills — низкий, MCP-серверы — высокий. Все четыре расширяют контекстное окно и tool-surface одного агента. OpenClaw использует manifest-first plugin-систему с четырьмя архитектурными слоями (discovery, enablement, runtime loading, surface consumption) и двенадцатью типами capability: text inference, speech, media understanding, image/music/video generation, web search, messaging channels. Плагины регистрируют capabilities в центральном реестре; шлюз читает реестр, чтобы выставить tools, channels, provider setup, hooks, HTTP routes, CLI-команды и services. OpenClaw имеет отдельный skills-слой с несколькими источниками (workspace, project-specific, personal, managed, bundled, extra), причём workspace-skills имеют наивысший приоритет, плюс public-реестр (ClawHub) и поддержку MCP через встроенные openclaw mcp-команды (server- и outbound-client-реестры). Ключевое архитектурное отличие: расширения Claude Code модифицируют action-surface одного агента, тогда как плагины OpenClaw расширяют capability-surface шлюза для всех агентов.

Memory, context, and knowledge management. Обе системы используют прозрачную файловую память, а не непрозрачные БД. Claude Code загружает четырёхуровневую иерархию CLAUDE.md и управляет давлением контекста через пятислойный compaction-конвейер (Section 7). Retrieval памяти использует LLM-скан заголовков файлов. OpenClaw инжектирует workspace-bootstrap-файлы в system prompt при старте сессии: пять ядровых файлов (AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md) плюс условно BOOTSTRAP.md, HEARTBEAT.md и MEMORY.md, с truncation больших файлов. Отдельно memory-система управляет тремя типами файлов: MEMORY.md для долговременных устойчивых фактов, date-stamped daily notes (memory/YYYY-MM-DD.md) и опциональный DREAMS.md для dreaming-sweep-сводок. Когда настроен embedding-provider, memory-search использует hybrid-retrieval, комбинируя vector-similarity с keyword-matching. Экспериментальная dreaming-система выполняет фоновую консолидацию, оценивает кандидатов и продвигает только qualified items из short-term-recall в long-term-memory. Перед compaction OpenClaw автоматически напоминает агенту сохранить важные заметки в memory-файлы, предотвращая потерю контекста. Обе системы разделяют design-commitment к user-visible, editable-памяти. OpenClaw больше вкладывается в структурированное продвижение long-term-памяти (dreaming, daily notes, memory-search), а Claude Code — в градуированное сжатие контекста (пять слоёв с cache-awareness). OpenClaw также поддерживает pluggable-compaction-providers и session-pruning, но её compaction-конвейер менее градуирован, чем пятислойная система Claude Code.

Multi-agent architecture and routing. Это измерение открывает самое резкое архитектурное различие. Мультиагентная модель Claude Code — task-delegation: родитель создаёт субагентов (Explore, Plan, general-purpose и кастомные типы), работающих в изолированных контекстных окнах с ограниченными наборами инструментов и возвращающих summary-only-результаты (Section 8). Worktree-изоляция даёт filesystem-level-отделение. OpenClaw разделяет две разные задачи. Первая — multi-agent routing: один шлюз может host нескольких полностью изолированных агентов, каждый со своей рабочей областью, authentication-профилями, session-store и конфигурацией модели, маршрутизируемых на определённые каналы или отправителей через детерминистские binding-rules. Вторая — sub-agent delegation: внутри одного агента можно запустить background-прогоны с настраиваемой nesting-depth (максимум 5, default 1, рекомендация 2), thread-bound-сессиями на поддерживаемых каналах и настраиваемой tool-policy по глубине. Проект OpenClaw явно отвергает agent-hierarchy-фреймворки как архитектуру по умолчанию. Различие важно, потому что субагенты Claude Code — подчинённые воркеры внутри кодовой сессии одного пользователя, а multi-agent routing OpenClaw создаёт genuinely independent agent-instances, обслуживающие разных пользователей или цели через разные каналы.

10.2. Что раскрывает сравнение

Сравнение выявляет три наблюдения о пространстве проектирования систем ИИ-агентов.

Во-первых, повторяющиеся вопросы проектирования, выделенные в Section 3.1 (где живут рассуждения, какую позицию по безопасности занять, как управлять контекстом, как структурировать расширяемость), применимы за пределами coding-agents. OpenClaw отвечает на каждый из этих вопросов, но из принципиально другой стартовой точки — мультиканального персонального ассистента, а не привязанного к репозиторию инструмента программирования. Вопросы стабильны; ответы варьируются с контекстом развёртывания.

Во-вторых, системы делают противоположные ставки по нескольким измерениям. Claude Code вкладывается в градуированную per-action-оценку безопасности; OpenClaw — в perimeter-level identity и access control. Claude Code трактует агентный цикл как архитектурный центр; OpenClaw — gateway control plane как центр и встраивает агентный цикл как один компонент. Расширения Claude Code модифицируют одно контекстное окно; плагины OpenClaw расширяют общую gateway-поверхность. Эти инверсии не произвольны: они вытекают из разных trust-моделей и deployment-топологий.

В-третьих, composition-relationship между двумя системами архитектурно значим. OpenClaw может host Claude Code как внешний coding-harness через ACP, то есть системы компонуемы, а не взаимоисключающи. Это подсказывает, что пространство проектирования ИИ-агентов — не плоская таксономия, а слоистая, где gateway-level-системы и task-level-harnesses могут компоноваться.

11. Обсуждение

Анализ предыдущих разделов задокументировал, как Claude Code отвечает на повторяющиеся вопросы проектирования о loop-архитектуре, позиции безопасности, расширяемости, управлении контекстом, делегировании и устойчивости. Каждый ответ отражает позицию в пространстве проектирования с реальными альтернативами и измеримыми компромиссами. Этот раздел исследует, что эти ответы вместе раскрывают: design-philosophy (Section 11.1), value-tensions (Section 11.2), архитектурные компромиссы (Section 11.3), эмпирические предсказания (Section 11.4) и сквозные обязательства, повторяющиеся через подсистемы (Section 11.7). Five-value framework из Section 2.1 служит организующей оптикой.

11.1. Design philosophy

Ценности и принципы, введённые в Section 2, предсказывают архитектуру, вкладывающуюся в операционную инфраструктуру, а не в decision-scaffolding. Реализация это подтверждает: архитектура, задокументированная в Sections 3–9, в подавляющей части — детерминистская инфраструктура (permission-gates, tool-routing, context-management, recovery-logic), а LLM вызывается как stateless completion endpoint. Оценочные 1.6% кодовой базы — decision logic; остальные 98.4% — операционный harness. Это соотношение не случайно.

Принципы проектирования, задокументированные в Section 2.2, подкрепляют этот подход: harness создаёт условия, в которых модель может решать хорошо, а не ограничивает её выбор.

Этот дизайн идёт против доминирующего паттерна в agent-engineering, где фреймворки вроде LangGraph маршрутизируют вывод модели через явные графовые узлы с типизированными рёбрами, а системы вроде Devin сочетают многошаговых планировщиков с тяжёлой операционной инфраструктурой. Claude Code, наоборот, даёт модели максимальную широту решений внутри богатого операционного harness. Инженерная сложность существует не чтобы ограничить решения модели, а чтобы их enable. Эта слоистая архитектура, где модель рассуждает, а harness энфорсит, поднимает вопрос: сходятся ли agent-инструменты программирования к операционно-системоподобным абстракциям, в которых core-loop служит kernel-ом, а всё остальное — ОС.

Design дополнительно приобретает значение по мере того как frontier-модели сходятся в практической способности для coding-задач: качество окружающего операционного harness становится главным differentiator, валидируя архитектуру, вкладывающуюся в инфраструктуру, а не в decision-scaffolding. Для agent-разработчиков следствие: вложения в детерминистскую инфраструктуру — context-management, safety-layering и recovery-механизмы — могут дать больше gains в надёжности, чем добавление planning-scaffolding вокруг всё более способных моделей.

Взятые вместе, предыдущие разделы показывают, что промышленные агенты программирования сталкиваются с повторяющимися выборами: где живут рассуждения относительно harness, как структурирован итерационный цикл, какую позицию безопасности принять по умолчанию, как разделена extension-surface, как собирается и сжимается контекст, как делегируются и оркестрируются субагенты, как сессии сохраняются через границы. Ответы Claude Code на эти вопросы образуют связную design-точку, привилегирующую model autonomy внутри богатого операционного harness.

Эта философия предполагает, что богатая детерминистская инфраструктура может адекватно поддержать неограниченное model judgment. Следующие подразделы исследуют, где это допущение проверяется.

11.2. Напряжения ценностей

Пять ценностей из Section 2.1 порождают напряжения, где преследование одной ограничивает другую (Table 4). Эти напряжения — не design failures; они структурные следствия одновременного преследования нескольких ценностей. Мы сообщаем напряжения с самым сильным подкрепляющим доказательством, а не полный комбинаторный набор.

Два дополнительных напряжения всплывают через оценочную оптику долгосрочного сохранения capability (Section 2.4). Рандомизированное контролируемое исследование 16 опытных разработчиков на 246 задачах (Becker et al., 2025) обнаружило, что AI-инструменты делают разработчиков на 19% медленнее, несмотря на воспринимаемое улучшение на 20%. Причинно-следственный анализ принятия Cursor на 807 репозиториях (He et al., 2025) нашёл, что code complexity выросла на 40.7%. EEG-исследование 54 участников (Kosmyna et al., 2025) обнаружило, что LLM-пользователи показывали ослабленную нейронную связность, сохранявшуюся после удаления AI. Исследователи предложили протоколы измерения когнитивной разгрузки в AI-assisted программировании, мотивированные опасениями, что студенты с AI производят приложения без понимания нижележащей логики (Aiersilan, 2026). Эти находки вместе с 25%-падением найма entry-level tech в 2023–2024 (Rak, 2025) подсказывают, что напряжение между capability-amplification и long-term sustainability выходит за рамки индивидуальной продуктивности на более широкий developer-pipeline. Это свидетельство мотивирует оценочную оптику, но не нацелено на архитектуру Claude Code конкретно; оно применяется к любой agent-системе с ограниченным контекстом и tool-use-циклами.

Table 4. Напряжения между ценностями с подкрепляющими свидетельствами

Table 4 Tensions between values, with supporting evidence. Each tension demonstrates that the two values capture genuinely distinct concerns.

11.3. Архитектурные компромиссы

Напряжения в Table 4 проявляются как конкретные архитектурные компромиссы в четырёх областях. Long-term sustainability-соображения, задокументированные в параграфе об оценочной оптике выше, всплывают в эмпирических предсказаниях Section 11.4.

Безопасность против автономии. Permission-режимы (пять всегда присутствуют плюс auto при активном feature flag классификатора и внутренний режим bubble) создают градиент от plan (пользователь одобряет все планы) через default, acceptEdits, auto (ML-классификатор), dontAsk до bypassPermissions (пропускает большинство prompt-ов, но safety-critical-проверки остаются). Прогрессия представляет монотонно снижающийся safety-градиент с ростом автономии. Невосстановление разрешений на resume отражает намеренный выбор в пользу безопасности: security-состояние не сохраняется неявно через границы сессии.

Safety-autonomy-градиент формируется не только архитектурным дизайном, но и поведением пользователей. Анализ авто-режима Anthropic (Hughes, 2026) нашёл, что пользователи одобряют примерно 93% permission prompt-ов — approval fatigue делает интерактивное подтверждение поведенчески ненадёжным. Лонгитюдные usage data (McCain et al., 2026) показывают, что auto-approve-rates растут с примерно 20% при менее чем 50 сессиях до более 40% к 750 сессиям, с существенным ростом длительности сессии. Эти паттерны подсказывают, что по градиенту движутся не через намеренный выбор режима, а через постепенное привыкание. Sandboxing снизил частоту permission prompt-ов примерно на 84% (Dworken and Weller-Davies, 2025), переформулировав проблему как human-factors-заботу: архитектурный ответ на ненадёжное человеческое одобрение — сократить число решений, которые людям приходится принимать.

Более фундаментально, defense-in-depth-архитектура из Section 5 стоит на допущении независимости: если один safety-слой падает, другие ловят нарушение. Но safety-слои Claude Code разделяют общие ограничения производительности и экономики. Классификатор авто-режима — отдельный LLM-вызов с прямой token-стоимостью. Модуль bashSecurity.ts делает последовательные AST-based-проверки с parsing-latency. Deny-first rule evaluation работает на структуре команды. Когда performance pressure давит на сокращение этих стоимостей, слои могут деградировать одновременно. Исследователи безопасности (Adversa.ai, 2026) задокументировали, что команды с более чем 50 подкомандами скатываются к одному generic-approval-prompt вместо per-subcommand deny-rule-проверок, потому что per-subcommand-парсинг вызывал UI-зависания, — демонстрируя, что defense-in-depth падает, когда нарушается допущение независимости.

Это напряжение структурное. Любая LLM-based agent-система, использующая саму модель для safety-оценки, сталкивается с ним. Релевантный критерий оценки — не может ли быть обойдён отдельный слой, а сколько независимых слоёв должно упасть одновременно и разделяют ли они режимы отказа.

Permission model в adversarial-условиях. Независимое security-исследование даёт эмпирическую валидацию permission-архитектуры, конкретно раскрывая temporal-ordering-свойство, не захваченное в Figure 4. Две независимо верифицированные уязвимости разделяют root cause в pre-trust initialization ordering: код, исполняющийся во время инициализации проекта (hooks, MCP server connections, settings file resolution), работает до того, как интерактивный trust-диалог показан пользователю³. Это pre-trust-окно исполнения лежит вне deny-first-evaluation-pipeline (permissions.ts), создавая структурно привилегированную фазу, где safety-гарантии, задокументированные в Section 5, не применяются.

Этот паттерн раскрывает, что permission-конвейер изображает пространственное упорядочение safety-проверок, но не захватывает временное измерение: а именно, когда каждый механизм становится активен во время инициализации сессии. Последовательность инициализации (extension loading, затем trust dialog, затем permission enforcement) создаёт окно, где extensibility-архитектура (Section 6) работает до того, как safety-архитектура (Section 5) полностью задействована. Это открытие уточняет extensibility-vs-simplicity-напряжение, добавляя security-измерение: расширяемость создаёт attack surface не только через комбинаторную сложность, но и через initialization ordering.

³ Две pre-trust-ordering-уязвимости — CVE-2025-59536 (CVSS 8.7) и CVE-2026-21852 (CVSS 5.3) (Donenfeld and Vanunu, 2026), обнаруженные Check Point Research. CVE-2025-54794 и CVE-2025-54795 (Beber, 2025) эксплуатируют path validation и command parsing flaws в permission-конвейере отдельно. Все четыре были пропатчены в течение недель после раскрытия.

Context efficiency против прозрачности. Пятислойный compaction-конвейер обеспечивает эффективное управление контекстом, но сжатие в основном невидимо пользователю. Когда budget reduction заменяет длинный tool-output ссылкой, когда context collapse замещает сообщения сводкой (описываемой в исходнике как «read-time projection over the REPL's full history»), или когда snip обрезает старую историю — у пользователя нет простого способа инспектировать, что потеряно. Cache-aware-поведение microcompact добавляет непрозрачности, поскольку решения о сжатии зависят от prompt-кэширования способами, невидимыми пользователю.

Простота против расширяемости. Четыре механизма расширения обеспечивают богатую кастомизацию, но создают комбинаторные взаимодействия. Плагин вкладывает хук PreToolUse, модифицирующий входы инструментов. Классификатор авто-режима читает кэшированный контент CLAUDE.md. Path-scoped-правила загружаются лениво при чтении новых директорий, потенциально меняя поведение классификатора посреди диалога. Четыре ветки permission-handler взаимодействуют с hook-конвейером в нескольких точках. Эти сквозные заботы создают emergent-поведения, которые сложно предсказать по любому одному конфигурационному файлу.

11.4. Эмпирические предсказания и ранние сигналы

Архитектурные свойства, задокументированные в этой статье, порождают проверяемые предсказания об исходах качества кода, не выводимых из одного исходника. Ограниченное контекстное окно (Section 7) не даёт агенту одновременной осведомлённости о всей кодовой базе: пятислойный compaction-конвейер сохраняет полезную информацию, но вводит lossy-сжатие на каждом шаге. Это делает архитектурно предсказуемым, что код, сгенерированный агентом, будет показывать более высокие уровни pattern-duplication и convention-violation, чем код с полной видимостью кодовой базы. Subagent-isolation (Section 8), где каждый субагент работает в своём контекстном окне с независимо собранным пулом инструментов, усугубляет эффект: параллельные агенты могут независимо переизобретать решения, уже существующие в другом месте. Design philosophy из Section 11.1 доверяет модели принимать хорошие локальные решения, но хорошие локальные решения могут давать плохие глобальные исходы, когда модели недостаёт глобального контекста.

Опубликованная эмпирическая работа по архитектурно похожим инструментам даёт данные, согласующиеся с этими предсказаниями. Причинный анализ принятия Cursor по 807 репозиториям (He et al., 2025) нашёл статистически значимый рост code complexity с начальным velocity-всплеском, рассосавшимся до базового уровня к третьему месяцу; растущая сложность была ассоциирована с пропорциональным снижением будущей velocity разработки, подсказывая, что gains self-cancelling⁴. Крупномасштабный аудит 304 000 AI-authored-коммитов по 6275 репозиториям (Liu et al., 2026) нашёл измеримый технический долг, примерно четверть AI-introduced-issues сохранялась до последнего ревижена, а security-related-issues сохранялись с существенно большей скоростью. Хотя эти исследования целятся в соседние системы, архитектурные параллели (bounded context, tool-use loops, single-pass generation) подсказывают, что находки релевантны разобранному здесь дизайну.

⁴ Complexity +40.7% (p < 0.001); velocity-всплеск +281% в первый месяц, baseline к третьему.

Context-management-конвейер Claude Code специально спроектирован, чтобы смягчить эти эффекты: градуированное сжатие сохраняет самый свежий и самый релевантный контекст, cache-aware-compaction избегает инвалидации prompt-кэшей при сжатии, read-time-projection поддерживает полную историю для реконструкции, предоставляя модели сжатый вид, а subagent-summary-isolation не даёт exploratory-шуму накапливаться в родительском контексте. Достаточны ли эти механизмы, чтобы преодолеть структурные ограничения ограниченного контекста — прямо измеримый эмпирический вопрос, который source-level-анализ в этой статье решить не может.

11.5. Ограничения

Помимо методологических ограничений в Section B.3, применяются несколько аналитических ограничений. Мемоизированные context-assembly-функции (getSystemContext() и getUserContext()) обе используют lodash memoize в context.ts, то есть git-статус и контент CLAUDE.md кэшируются, а не пересчитываются на каждом ходе. Динамические изменения в ходе диалога могут не отражаться мгновенно, хотя compaction может очистить кэши, и lazy-loaded path-scoped rules дают частичный counter-механизм.

Feature flags создают build-time-вариативность. В сборке, где TRANSCRIPT_CLASSIFIER false, весь auto-mode-модуль классификатора устраняется. Feature-gated-модули используют динамический require(), а не статический import (например, query.ts для context collapse), потому что feature() работает только в if/ternary-условиях из-за ограничения bun:bundle tree-shaking. Разные build-targets могут производить функционально разные приложения.

11.6. Emerging Directions

Несколько аспектов реализации относятся к более широким вопросам проектирования. Более длинные контекстные окна сократили бы давление compaction, потенциально упрощая градуированный конвейер. Multi-modal inputs (screenshots, diagrams, UI-previews) расширят tool-поверхность и создадут новые context-вызовы. Формальная верификация permission-properties (например, доказательство, что deny-правила всегда имеют приоритет, что sandboxed-команды не могут сбежать из изоляции или что resumed-сессии не могут унаследовать устаревшие разрешения) дала бы более сильные safety-гарантии.

Architectural decoupling. Плотно связанная локальная архитектура, разобранная здесь, — одна точка на уже эволюционирующем спектре. Собственная работа Anthropic по Managed Agents (Martin et al., 2026) описывает виртуализацию компонентов агента (session, harness, sandbox), так что «каждая стала интерфейсом, делающим мало допущений об остальных, и каждая могла упасть или быть заменена независимо», проводя явную аналогию с тем, как ОС виртуализируют аппаратуру в процессы и файлы. Эссе Harness Design (Rajasekaran, 2026) делает похожую точку с другого ракурса, замечая, что «пространство интересных harness-combinations не сокращается по мере улучшения моделей»; скорее, «оно движется». Архитектуру, задокументированную в этой статье, стоит поэтому читать как снимок соэволюционирующей системы, а не фиксированного оптимума.

Память как first-class подсистема. Обзор памяти (Hu et al., 2025) утверждает, что agent-память становится отдельным когнитивным субстратом, а не побочным эффектом управления контекстным окном, и называет автоматизированное управление памятью, RL-driven memory и trustworthy memory (privacy, explainability, hallucination robustness) открытыми рубежами. Claude Code сегодня выставляет factual tier (CLAUDE.md, auto memory) и working tier (conversation window); experiential tier (накопленные, автоматически курируемые playbooks стратегий, выученных в прошлых сессиях) — естественный следующий шаг, и context-engineering-литература (Zhang et al., 2025a) начала давать механизмы для этого накопления.

Observability и silent failure. Отраслевые обзоры подсказывают, что доминирующий режим отказа развёрнутых агентов — не крэши, а silent mistakes. Инфраструктурный отчёт Bessemer 2026 (Wade et al., 2026) оценивает, что «78% AI-failures невидимы», а исследование 1340 респондентов state-of-agent-engineering от LangChain (LangChain, 2026) называет quality, а не cost, главным барьером к production use и находит широкий разрыв между observability (почти 89% adoption) и offline evaluation (52.4%). Разобранная здесь архитектура даёт операторам видимость вызовов инструментов, хуков и session-транскриптов; закрытие evaluation-разрыва, вероятно, потребует дополнительного scaffolding (generator-evaluator-separation, sprint-contracts, post-hoc-checks, разобранные в Rajasekaran (2026)), а не только улучшений модели.

Governance. Более широкие governance-тренды ограничат пространство проектирования по мере роста автономии агентов. International AI Safety Report (Bengio et al., 2026) предупреждает, что «AI-agents несут повышенные риски, потому что действуют автономно, затрудняя людям вмешаться до вреда», а MIT AI Agent Index (Staufer et al., 2026) находит, что лишь 13.3% индексированных agent-систем публикуют agent-specific safety cards. Зарождающиеся регуляторные фреймворки, в особенности EU AI Act (полная применимость — август 2026) и эволюционирующая copyright-юриспруденция вокруг AI-generated кода, могут наложить внешние ограничения на logging, transparency и human-oversight, формирующие эволюцию архитектур coding-agents.

Proactive архитектуры. Feature-gated KAIROS-система иллюстрирует, как эта архитектура может эволюционировать за пределы реактивного tool-use. KAIROS реализует persistent background-агента с tick-based heartbeats: когда нет ожидающих пользовательских сообщений, система инжектирует периодические <tick>-prompt-ы, и модель решает действовать или спать. Дизайн прямо адресует задокументированное напряжение: proactive AI-ассистенты повышают task completion на 12–18%, но снижают user preference на высоких частотах (Chen et al., 2025). KAIROS решает это через terminal-focus-awareness (максимизация автономного действия, когда пользователя нет, предпочтение коллаборации при присутствии) и economic throttling (каждый wake-up стоит API-вызова; prompt-кэш истекает через пять минут неактивности, делая sleep/wake явной cost-оптимизацией). Такая привязка проактивности к user presence и token economics редко встречается среди production agent-систем, хотя KAIROS не подтверждён как активный в production builds.

11.7. Повторяющиеся проектные решения

Чтение шести анализов подсистем вместе раскрывает три сквозных design-обязательства, повторяющихся через независимые компоненты.

Градуированное наслоение вместо монолитных механизмов. Safety, context-management и extensibility — все используют градуированные стеки независимых механизмов, а не единые интегрированные решения. Permission-архитектура наслаивает семь стадий от tool-pre-filtering через deny-first-rules, permission-modes, auto-mode-классификатор, shell-sandboxing, non-restoration on resume до hook-interception. Context-management наслаивает пять compaction-стадий, lazy-loaded CLAUDE.md-файлы, deferred tool-schemas и summary-only subagent-returns. Extensibility-слоит четыре механизма (MCP-серверы, плагины, навыки, хуки) с разной контекстной ценой (Section 6). В каждом случае design меняет простоту и debuggability на defense in depth, принимая, что взаимодействие между слоями может порождать emergent-поведения, сложные для предсказания по любой одной конфигурации.

Append-only designs, предпочитающие auditability вместо query power. Session-транскрипты — append-only JSONL-файлы с read-time chain-patching; разрешения не восстанавливаются через границы сессии; context compaction применяет read-time-проекции поверх полной истории, а не деструктивные правки. Это обязательство повторяется потому, что сохраняет возможность resume, fork и аудита сессий без модификации ранее записанного состояния. Цена в том, что более богатые структурированные запросы («покажи все tool-вызовы, модифицировавшие файл X в сессиях») требуют post-hoc-реконструкции, а не прямого поиска.

Model judgment внутри детерминистского harness. По всем подсистемам архитектура доверяет суждению модели внутри богатого детерминистского harness, а не ограничивает её выбор. Оценочные 1.6% decision-logic захватывают это количественно: harness создаёт условия (tool routing, permission enforcement, context assembly, recovery logic), при которых модель может решать хорошо. Hierarchical permissions сохраняют safety-инварианты через agent-границы, а assembleToolPool() сливает built-in- и MCP-инструменты в единый унифицированный интерфейс, но модель сохраняет полную широту того, какие инструменты вызывать и в каком порядке. Компромисс: хорошие локальные решения могут давать плохие глобальные исходы, когда ограниченный контекст мешает глобальной осведомлённости, как документируют эмпирические предсказания Section 11.4.

12. Будущие направления

Section 11 прочитал архитектуру, задокументированную в Sections 3–9, как связную design-точку и всплыл напряжения, компромиссы и near-horizon-направления, которые эта design-точка подразумевает. Этот раздел выходит за пределы самой архитектуры, чтобы зафиксировать шесть открытых вопросов, которые Section 11.6 частично называет и которые растущая внешняя литература заострила настолько, чтобы их можно было сформулировать конкретно. Шесть охватывают пятивекторный фреймворк статьи (Section 2.1) и её оценочную оптику (Section 2.4): внешние governance-ограничения на Authority-иерархию (Section 12.5); observability–evaluation-разрыв на Safety-стороне (Section 12.1); cross-session persistence состояния и отношений на Reliability-стороне (Section 12.2); четыре расширения Capability-фронтира (Section 12.3); horizon-scaling как отдельная ось Reliable Execution за пределами cross-session-continuity (Section 12.4); и оценочную оптику Section 2.4, переформулированную как design-вопрос, а не диагностический (Section 12.6). Согласно формулировке Section 11.6, каждый вопрос поставлен в форме whether / how / which; конкретные механизмы называются, когда цитируемые источники их называют, и оставляются открытыми в остальных случаях.

12.1. Silent failure и observability–evaluation-разрыв

Отражает ли observability–evaluation-adoption-разрыв, сообщённый в Section 11.6, отсутствующий tooling-слой, отсутствующий evaluation-интерфейс внутри harness или capability-ceiling модели — цитируемые источники не решают. Как silent-mistake-failure-mode, отмеченный в том параграфе, должен всплывать — архитектурный вопрос к harness, а не capability-вопрос к модели. Недавняя эмпирика характеризует разрыв на нескольких разрешениях. Cemri et al. (2025) каталогизируют четырнадцать failure-модов, охватывающих system-design-issues, inter-agent misalignment и task-verification; Pathak et al. (2025) строят бенчмарк agent-траекторий специально для anomaly-detection в трейсах; Yao et al. (2024) раскрывают consistency-gaps через pass^k-метрику (вероятность, что все k независимых trials успешны); Kapoor et al. (2024) утверждают, что нынешние agent-бенчмарки отсутствуют holdouts и cost-controls, ограничивая, что observability может действительно диагностировать.

Против permission-pipeline и tool-orchestration-слоёв, разобранных в Sections 4 и 5, остаются два архитектурных вопроса. Первый: принадлежит ли scaffolding, которое статья цитирует из Rajasekaran (2026) (generator–evaluator separation, sprint contracts, post-hoc checks, построенное на self-refine-паттерне Madaan et al. (2023)) внутри harness (например, как дополнительные hook-события рядом с 27 задокументированными в Section 6) или вне как отдельный evaluation-слой — цитируемые источники не решают. Второй: может ли существующий hook-конвейер Section 6 host такое scaffolding внутри текущей context-cost-envelope — дальнейший открытый вопрос. Наблюдение, что закрытие разрыва «likely requires additional scaffolding... rather than model improvements alone» (Section 11.6), помещает открытую работу на harness-слой.

12.2. Устойчивость: память и лонгитюдные коллегиальные отношения

Должно ли agent-state и рабочие отношения человек-агент сохраняться через сессии, и в какой форме — сегодня в статье рассматриваются как два отдельных вопроса. Section 7 документирует четырёхуровневую иерархию CLAUDE.md и auto memory; Section 9 документирует преимущественно append-only JSONL-транскрипты (с явными cleanup-rewrites как исключением), чьи session-scoped-разрешения resume не восстанавливает. Что принадлежит между этими двумя слоями (durable state, не являющееся ни статической инструкцией, ни транскриптом одной сессии) — открытый design-вопрос. Hu et al. (2025) и Zhang et al. (2025a), уже цитированные в Section 11.6, мотивируют накапливающий слой. Packer et al. (2023) переформулируют LLM как операционную систему с paged-памятью; Chhikara et al. (2025) строят production-oriented memory-store, переживающий restarts; Xu et al. (2025) предлагает research agentic-memory-дизайн; Wang et al. (2024c) захватывают accumulating procedural traces; Shinn et al. (2023) накапливают self-reflection-traces через verbal reinforcement; обзоры Zhang et al. (2025b) и Huang et al. (2026) картографируют candidate-механизмы.

Тот же persistence-вопрос повторяется на human-стороне. Section 11.6 уже цитирует лонгитюдные свидетельства автономии (Huang et al., 2025; McCain et al., 2026); field experiment Dell'Acqua et al. (2025) с 776 Procter & Gamble-профессионалами вместе с лонгитюдными и организационными исследованиями Copilot-rollouts (Stray et al., 2025) и AI-teamwork-траекториями (Xiao et al., 2025) сообщают сдвиги в human-AI рабочей динамике по мере накопления collaboration. Wang et al. (2023) иллюстрирует embodied-агента, накапливающего skill-library через задачи; Mollick (2024) формулирует человеко-AI рабочие отношения как co-intelligence.

Может ли единый substrate нести и personal instruction hierarchy пользователя, и shared organizational context, сохранив file-based transparency CLAUDE.md, которую документирует Section 7 — открытый архитектурный вопрос. Как session-scoped-разрешения взаимодействуют с таким substrate без повторного введения resume-restoration-концерна, который Section 9 закрывает как намеренный safety-выбор — дальнейший открытый вопрос.

12.3. Эволюция harness-boundary: Где, когда, что и с кем действует агент

Section 11.6 цитирует наблюдение Rajasekaran (2026): «пространство интересных harness combinations не сокращается по мере улучшения моделей; оно движется». Будет ли это движение наиболее выражено в где harness работает, когда он действует, что он координирует или с кем — source-level-анализ в Sections 3–9 не решает. Каждый из четырёх имеет активную research-литературу, которой статья касается лишь мимоходом.

Where. Managed Agents Martin et al. (2026) виртуализирует session, harness и sandbox в независимо заменимые интерфейсы, расширяя virtual-memory-аналогию, применяемую Packer et al. (2023) к управлению контекстным окном и популяризированную Karpathy (2023) шире; Khattab et al. (2023) трактует сам harness как compile-target.

When. Section 11.6 уже вводит KAIROS как feature-gated иллюстрацию, мотивированную +12–18% task-pass-gain, сообщённым Chen et al. (2025), и резким preference-penalty (47% vs 80–90%), ограниченным высокочастотным вариантом Persistent Suggest. Liu et al. (2025), Pu et al. (2025) и Lee et al. (2025) расширяют proactivity design space через programming и ambient-interface-settings; Pasternak et al. (2025) и Sun et al. (2025) вводят бенчмарки и training-regimes, нацеленные на её заточку, а Deng et al. (2025) обозревает более широкий ландшафт.

What. Vision-language-action-работы расширяют harness за пределы textual tool-returns: Brohan et al. (2024) и Black et al. (2024) обучают VLA-policies, исполняющие физические действия, и Ahn et al. (2022) заземляет планы в robot-affordances; industry-системы вроде Figure AI (2025) и Bjorck et al. (2025) толкают похожие идеи в humanoid-контроль. Эти системы сталкиваются с reversibility-weighted risk-принципом (Table 1) при cost-asymmetry, которую принцип называет, но не квантифицирует для non-textual-действий.

With whom. Role-differentiated multi-agent-системы (Hong et al., 2023; Li et al., 2023; Chen et al., 2023; Qian et al., 2024) компонуют агентов с различающимися обязанностями; multi-agent debate (Du et al., 2024; Liang et al., 2024) и graph-structured workflows (Zhuge et al., 2024) исследуют альтернативы parent/subagent-паттерну из Section 8; Guo et al. (2024) обозревает это пространство.

Может ли одна harness-архитектура охватить все четыре расширения, или «harness combinations», описанные Rajasekaran (2026), фрагментируются в специализированные стеки — открытый design-вопрос. When-расширение прямо картографируется на Capability-vs-Adaptability-напряжение в Table 4. With-whom-расширение частично картографируется на Capability-vs-Reliability, но поднимает cross-agent-consistency-концерны, которые Table 4 сама не покрывает. Where- и what-расширения поднимают дальнейшие вопросы: какие governance-обязательства привязываются к harness-компонентам, ставшим hosted services (Section 12.5), и как reversibility-weighted risk (Table 1) масштабируется на физические, а не текстовые эффекты. Как эти расширения компонуются по осям, а не внутри какой-то одной — не то, что single-subsystem-анализы статьи могут решить.

12.4. Horizon scaling: От сессии к научной программе

Section 2.1 определяет Reliable Execution как охватывающее «и корректность одного хода, и long-horizon dependability». Продолжит ли архитектура, задокументированная в Sections 3, 4 и 7–9 (чьи основные единицы — ход, сессия и субагент), поддерживать long-horizon dependability по мере того как автономная работа расширяется за одну сессию на multi-session-программы — открытый вопрос. Растущая литература целит этот режим. Lu et al. (2024) представляет end-to-end autonomous-research-конвейер, производящий черновики манускриптов; Beel et al. (2025) даёт независимую SIGIR Forum-оценку того конвейера, характеризуя, где «autonomous-research» сегодня даёт и где он недотягивает. Gottweis et al. (2025) разрабатывает multi-agent hypothesis-generation-систему, идущую днями, а не ходами, а Novikov et al. (2025) преследует алгоритмическое открытие в timescale-ах, ранее требовавших человеческих экспертов недели. METR-исследование Kwa et al. измеряет task-duration, при которой frontier-агенты успешны с фиксированной надёжностью (50%-time horizon) и как этот horizon эволюционировал через поколения моделей, давая эмпирический фрейм для этого scaling-вопроса.

Против анализа статьи, long-horizon-развёртывание проверяет, останутся ли context-management-конвейер Section 7, last-assistant-text-return-policy Section 8 и append-only-persistence Section 9 достаточны, когда сессии компонуются в multi-session-программы. Section 11.4 уже формулирует это как «прямо измеримый эмпирический вопрос», который source-level-анализ решить не может. Horizon scaling переформулирует этот вопрос на масштабе недель: закрывает ли harness-слой разрыв один, нужен ли cross-session memory-substrate (Section 12.2), или horizon-scale-работа требует coordination-примитивов за пределами session, sub-agent и memory — не то, что session-scoped-анализы статьи могут уладить.

12.5. Governance и oversight в масштабе

Зарождающееся AI-регулирование добавляет внешнее ограничение на архитектуры, реализующие Authority-иерархию Anthropic, операторов и пользователей, задокументированную в Section 2.1. Какие logging-, transparency- и human-oversight-affordances coding-agent-архитектуры должны выставить под этим внешним ограничением — открытый design-вопрос. GPAI Code of Practice Европейской комиссии (European Commission, 2025a) и implementation guidelines (European Commission, 2025b) детализируют general-purpose AI-обязательства, сопровождающие полную применимость EU AI Act в августе 2026; MIT AI Agent Index (Staufer et al., 2026) и International AI Safety Report (Bengio et al., 2026), уже цитированные в Section 11.6, мотивируют disclosure- и oversight-сторону этого ограничения. Дело Bartz v. Anthropic (bar, 2025) добавляет input-side-ограничение на training-data-sourcing (lawful acquisition copyrighted works) отдельно от output-side-copyright-вопросов о AI-generated коде, которые эмерджентные дела адресуют отдельно. Отчёт OECD по AI-governance (OECD, 2025) и ранний анализ compliance-обязательств для agent-providers Nannini et al. (2026) обрисовывают, как regulator-facing-интерфейсы могли бы выглядеть без прописывания specifics.

Прочитав против permission-pipeline, разобранного в Section 5, два свойства нынешней архитектуры открыты под этим ограничением. Первое: deny-first evaluation, разбираемое в статье, внутренне auditable через session-транскрипты (Section 9), но ещё не externally auditable в формах, которые эмерджентные фреймворки вроде GPAI Code of Practice (European Commission, 2025a) рассматривают. Второе: допускает ли values-over-rules-принцип, который статья сочетает с детерминистскими ограждениями, вид явной rule-articulation, который compliance-review может потребовать — дальнейший открытый вопрос. Оба свойства лежат внутри harness, а не модели; именно там будущие архитектуры могут потребовать выставить новые интерфейсы.

12.6. Оценочная оптика, пересмотренная: Долгосрочная человеческая capability

Section 2.4 вводит long-term human-capability preservation как аналитическую оптику, а не co-equal design value; Sections 11.2 и 11.4 расширяют оптику внешними свидетельствами (perceived-vs-measured productivity, comprehension loss, complexity accrual, technical-debt persistence, neural-connectivity persistence, early-career hiring decline), а Section 14 разворачивает: «Future systems could treat that sustainability gap as a first-class design problem, not a downstream evaluation metric.» Возможен ли этот разворот, и какие архитектурные механизмы first-class-трактовка потребовала бы — последний из открытых вопросов, которые этот раздел фиксирует.

Два sub-вопроса отделяют measurement-gap от design-gap. Первый: измеримы ли эмпирические claims, мотивирующие оптику, на session-granularity. Существующие ссылки работают на session- до multi-month-масштабах (16-dev-RCT Becker et al. (2025), comprehension-test сравнение Shen and Tamkin (2026), EEG-исследование Kosmyna et al. (2025), 807-репозиторный causal-анализ He et al. (2025), Liu et al. (2026), hiring-серия Rak (2025)), но harness, задокументированный в Sections 3, 4 и 7, не выставляет per-session-сигнала для comprehension- или convention-drift. Связанная работа по programmer-interaction-modes (Barke et al., 2023) и AI-induced code-security-regressions (Perry et al., 2023) обрисовывает session-granularity measurement, а Aiersilan (2026) предлагает протокол для session-level cognitive-offloading-probes. Второй: может ли архитектура реагировать на такие измерения, раз они существуют (аналог generator-evaluator-separation (Rajasekaran, 2026), применённый к human loop, поверхности, сохраняющие comprehension, или механизмы, ещё не названные), — design-gap-вопрос, который ставит Section 14. Статья не занимает позицию о том, какой класс механизмов подходит, и является ли задокументированный здесь harness вообще правильным локусом для этого действия (в противоположность IDE, организации или human-development-loop), — вопрос, который архитектурный анализ не может отсудить; related work, обозреваемая в Section 13, и sustainability-pivot Section 14 маркируют, где статья оставляет вопрос.

13. Связанные работы

13.1. Таксономия инструментов программирования

AI-инструменты программирования можно организовать по степени автономного действия, которое они поддерживают (Table 5). Inline-completion-инструменты вроде GitHub Copilot (Chen et al., 2021) предлагают фрагменты кода в редакторе без автономного действия. Chat-integrated-продукты — Cursor, Windsurf и Cody — добавляют диалоговое взаимодействие и multi-file-правки, но остаются привязаны к IDE-среде. Agentic-CLI-инструменты, включая Claude Code, OpenAI Codex CLI и Aider (Gauthier, 2024), работают из командной строки и могут автономно исполнять shell-команды, читать и писать файлы, итерироваться по результатам в одном запросе. Полностью автономные системы вроде Devin, SWE-Agent (Yang et al., 2024) и OpenHands (Wang et al., 2024b) целят минимальный человеческий надзор, часто в sandboxed cloud-средах.

Table 5. Категории AI-инструментов программирования по степени автономного действия

Table 5 AI coding tool categories by degree of autonomous action.

Claude Code разделяет фичи с higher-autonomy-агентами (auto-mode-классификатор, background-agent-исполнение, remote-среды), но сохраняет интерактивное одобрение по умолчанию. Evaluation-бенчмарки вроде SWE-Bench (Jimenez et al., 2023) и HumanEval (Chen et al., 2021) вели большую часть академического фокуса на coding-agents. Эта статья рассматривает внутреннюю архитектуру Claude Code из исходного кода.

13.2. Паттерны архитектуры агентов

Core loop Claude Code следует ReAct-паттерну (Yao et al., 2022): модель порождает рассуждение и tool-invocations, harness исполняет действия, результаты кормят следующую итерацию. Toolformer (Schick et al., 2023) показал, что языковые модели могут учиться использовать инструменты; Claude Code использует до 54 встроенных инструментов и слоистую permission-систему. Более широкое design space картографировали несколько обзоров. Weng (2023) предложил теперь-стандартную декомпозицию на planning, memory и tool use, а Wang et al. (2024a) каталогизировал раннюю autonomous-agent-работу. Xu (2026) формулирует поле вокруг трёх повторяющихся компромиссов (autonomy vs. controllability, latency vs. accuracy, capability vs. reliability), повторяющихся через наш анализ, а Hu et al. (2024) представляет agent-design как search-проблему по компонентам, алгоритмам и evaluation-функциям. Эта статья характеризует одну конкретную точку в этом пространстве.

Multi-agent orchestration-фреймворки вроде AutoGen (Wu et al., 2024), LangChain и CrewAI предоставляют conversation-based agent-coordination. Subagent-делегирование Claude Code (Section 8) включает permission-override-прецеденты, two-level permission-scoping и отдельные transcript-файлы на каждого субагента. LATS (Zhou et al., 2023) унифицирует reasoning, acting и planning в tree-search-фреймворк; plan-permission-режим Claude Code реализует более простой plan-then-execute-подход.

Practitioner-writing сошлось на горстке повторяющихся паттернов, которые инстанцирует архитектура Claude Code. Собственная «Building Effective Agents» Anthropic (Schluntz and Zhang, 2024) различает агентов от workflows и выступает за простые композиционные паттерны вместо тяжёлых фреймворков. Martin (2026) синтезирует семь паттернов, наблюдаемых в production-системах, включая предоставление general-purpose-инструменту filesystem- и shell-доступа как action-слоя и открытие действий по требованию, а не загрузку каждой tool-schema заранее. Chase (2025) замечает, что planning-инструмент Claude Code «по сути no-op», чья ценность в удержании агента на треке, а не исполнении внешних вычислений. Wang (2025) утверждает, что authority — элемент, чаще всего пропускаемый академическими фреймворками, называя trust «самым недооценённым элементом» в production agent-design — разрыв, который permission-анализ в Section 5 пытается закрыть. Huyen (2025) делает compound-error-concern конкретной: при 95% per-step-accuracy 100-шаговая задача успешна лишь в 0.6% случаев, что мотивирует per-step-verification-паттерны, которые мы трассируем в Sections 4 и 5.

Context management. Table 6 представляет design-space-таксономию подходов управления контекстом. Пятислойный compaction-конвейер Claude Code применяет несколько стратегий на разных granularities до эскалации, с cache-aware-compression и virtual-view-on-read-семантикой. Zhang et al. (2025a) характеризует два failure-мода, которые этот design смягчает (summarization, роняющая domain-details, и detail loss от итеративного context-rewriting), и вместо этого предлагает трактовать контекст как «evolving playbook», накапливающий стратегии со временем. Подход Claude Code согласуется с этой формулировкой, поскольку иерархия CLAUDE.md накапливает структурированные инструкции, а не многократно их суммирует. Hu et al. (2025) различает context engineering от agent memory: context engineering управляет transient-сборкой, а memory покрывает persistent factual-knowledge и experiential traces. Архитектура Claude Code разделяет эти два так же, связывая compaction-конвейер с file-based memory-hierarchy.

Table 6. Пространство проектирования подходов управления контекстом в LLM-based-инструментах

Table 6 Design space of context management approaches in LLM-based tools.

Safety и permissions. Промышленные агенты программирования принимают safety-архитектуры, варьирующиеся по трём осям: approval model (per-action prompting, classifier-mediated automation или no prompting with post-hoc review), isolation boundary (OS-level container, filesystem sandbox, permission-scoped tool pool или none) и recovery mechanism (version-control rollback, session-scoped permission reset или checkpoint-based rewind). SWE-Agent и OpenHands (Yang et al., 2024; Wang et al., 2024b) опираются прежде всего на Docker-container-isolation, давая environment-level sandboxing, ограничивающий все agent-действия. Codex CLI поддерживает sandbox-режимы и approval-политики для shell-команд. Aider (Gauthier, 2024) использует Git как primary safety-mechanism, делая все изменения обратимыми через контроль версий. Claude Code сочетает per-action deny-first-rules, ML-based-классификатор для автоматизированного одобрения, опциональную shell-sandbox и session-scoped permission non-restoration, наслаивая несколько механизмов вместо опоры на один isolation-boundary.

Protocols и extensibility. Model Context Protocol, который Claude Code использует как primary external tool integration, стал фактическим стандартом с существенной экосистемой и соответствующей attack-surface. Hou et al. (2025) каталогизирует тысячи community-developed MCP-серверов по 26 major categories и организует MCP-specific threats в четыре attacker-категории и шестнадцать сценариев, включая tool poisoning, rug pulls и cross-server shadowing. Permission- и deny-rule-machinery, разобранную в Section 5, и pre-filtering-шаг в Section 6.2 можно читать как runtime-сторону mitigations, к которым призывает этот обзор.

Software architecture. Layered architecture-patterns (Garlan et al., 1993) информируют нашу пятислойную декомпозицию. Role-based access control-модели (Sandhu et al., 2002) дают теорию для permission-mode-системы. Browser-sandboxing (Reis and Gribble, 2009) — похожий per-process isolation-подход. Multi-agent system theory (Wooldridge, 2009) помогает объяснить делегирование субагентам.

Позиционирование. Прежняя работа по coding-agents фокусировалась на бенчмарках (как хорошо агенты решают задачи), фреймворках (как компоновать агентов) и продуктах (что пользователи могут делать). Эта статья вкладывается source-grounded design-space-анализом промышленного coding-agent, используя source-level-анализ и архитектурное сравнение, чтобы всплыть design-choices и компромиссы. Она опирается на software-architecture case-study-традицию (Garlan et al., 1993), но применяет её к LLM-based-агенту, систематически выявляя design-вопросы, картографируя альтернативы и противопоставляя выбор Claude Code выбору OpenClaw — независимой AI-agent-системы, работающей из другого контекста развёртывания.

14. Заключение

Эта статья показывает, что промышленные coding-agents можно понять как ответы на повторяющийся набор design-вопросов: где сидят рассуждения относительно harness, как организованы исполнение, безопасность, расширяемость, контекст, делегирование и устойчивость, и какие компромиссы эти выборы кодируют. Claude Code занимает в этом пространстве ясную design-точку. Он даёт модели широкую локальную автономию, окружая её плотным детерминистским harness для разрешений, tool-routing, context-compaction и session-recovery. Прочитано через пять ценностей и тринадцать принципов проектирования, выявленных в Section 2, эти выборы связны, а не ad hoc: система последовательно приоритизирует human decision authority, safety, reliable execution, capability amplification и contextual adaptability.

Сравнение с OpenClaw заостряет главное архитектурное открытие, показывая, что те же design-вопросы повторяются в разных agent-системах, но производят разные ответы. Там где Claude Code вкладывается в per-action safety-классификацию и градуированное context-compaction внутри CLI-harness, OpenClaw вкладывается в perimeter-level access-control и структурированную long-term-память внутри multi-channel-шлюза. Две системы могут даже компоноваться: OpenClaw host Claude Code как внешний harness через ACP. Для agent-разработчиков самый последовательный открытый вопрос — поэтому не как добавить больше автономии, а как сохранить человеческую capability со временем. Как задокументировано оценочной оптикой в Section 2.4, анализом в Section 11 и открытыми вопросами, обозрёнными в Section 12, архитектура даёт ограниченные механизмы, которые явно сохраняют long-term human understanding, codebase coherence или developer pipeline. Будущие системы могли бы трактовать этот sustainability-разрыв как first-class design-проблему, а не downstream evaluation-metric.

Полный список источников — в оригинальной работе: arxiv.org/abs/2604.14228

← Часть 4 — Контекст и память | Вся серия: /claude-code-series