一句话概括： 这篇文章来自一份对 Claude Code 源代码的深度逆向分析报告，研究者读完 51.2 万行 TypeScript 代码后发现，这个工具的核心逻辑只占代码量的 1.6%，其余 98.4% 全是"让模型能好好工作的基础设施"。
理解这个比例，就理解了现代 AI 智能体的设计哲学。
背景：这份分析是怎么来的
2026 年 4 月，来自阿联酋穆罕默德·本·扎耶德人工智能大学（MBZUAI）的四位研究者，把 Claude Code 的公开 npm 包（版本 v2.1.88）解包，拿到了约 1884 个文件、51.2 万行 TypeScript 源代码，然后逐文件读了一遍。
Figure 9：Claude Code 源码包结构与运行时职责：论文附录把解包后的 TypeScript 目录映射到运行时职责，能看出 main.tsx、query.ts、Tool.ts、MCP、compact、AgentTool 等模块各自负责什么。
他们写出的报告有两个核心贡献：
第一，系统梳理了 Claude Code 的完整架构。
第二，把它和另一个开源 AI 智能体系统 OpenClaw 做了横向对比，用来说明"同样的设计问题，在不同场景下会产生多么不同的答案"。
这篇文章是对那份报告的完整提炼。
为什么 Claude Code 和 Copilot 不是一类东西
AI 编程工具的演化有三个阶段：
第一阶段是 GitHub Copilot 这类补全工具，在编辑器里给你建议代码片段，你接受或拒绝，它不会主动做任何事。
第二阶段是 Cursor 这类IDE 集成助手，可以多文件编辑，有对话能力，但仍然依附在 IDE 环境里。
第三阶段是 Claude Code 这类完全自主的智能体（Agent），它能自己规划多步操作、执行 shell（命令行）命令、读写文件、调用外部服务、看到执行结果后自我修正，一直循环直到任务完成。
这个跃迁带来了全新的工程挑战。一个只给建议的工具，出错了顶多是建议不好；一个能自主执行命令的工具，出错了可能真的删掉了你的文件、提交了错误的代码、或者把 API 密钥发到了外网。
所以 Claude Code 的架构，本质上是在回答一个问题：怎么让一个强大但不完美的 AI 模型，在真实的生产环境里安全地自主行动？
一个数字说明一切：1.6% vs 98.4%
研究者在分析代码后估算，整个 Claude Code 代码库里，AI 决策逻辑（即"让模型想清楚下一步做什么"的部分）只占约 1.6%，剩下 98.4% 是运营基础设施：权限检查、工具路由、上下文管理、错误恢复、会话持久化……
这个比例和大多数人的直觉相反。很多人以为 AI 工具的核心是模型本身，但在 Claude Code 里，模型只是一个被精心伺候的"决策者"，真正的工程量在于围绕它构建的那套确定性基础设施。
Anthropic 自己的说法是：把 Claude Code 理解为一个 Unix 工具，而不是一个传统产品。它由最小的、有用的、可理解的、可扩展的构建块组成。
五个价值观，十三条原则，一套架构
研究者认为，Claude Code 的所有架构决策都可以追溯到五个核心价值观。理解这五个价值观，就能理解为什么每个设计选择是这样而不是那样。
价值观一：人类决策权威
人类始终保有最终决定权。系统通过三层主体层级来落实：Anthropic（制造商）、运营者（企业客户）、用户（最终使用者）。
有一个有趣的数据：Anthropic 发现用户批准了 93% 的权限提示。这个数字看起来很高，但它其实说明了一个问题：当批准率接近 100% 时，用户已经在不假思索地点"确认"了，逐次确认作为安全机制已经失效。
Anthropic 的应对方式不是加更多警告，而是重新定义问题：与其让用户对每个动作确认，不如在明确的边界内让智能体自由行动，只在真正需要时才打扰人类。
价值观二：安全与隐私
这和"决策权威"是两件不同的事。决策权威是"人类有权选择"，安全是"即使人类没在看，系统也有义务保护他们"。
Anthropic 明确列出了自动模式下的四类风险：过度积极的行为、诚实的错误、提示注入攻击（Prompt Injection，指恶意内容试图操控 AI 执行有害指令）、模型对齐失败。
价值观三：可靠执行
智能体要做人类真正想要的事，不只是单次对话，还要跨越上下文窗口边界、会话恢复、多智能体委托后依然保持一致。
价值观四：能力放大
让人类用更少的精力完成更多的事，尤其是那些原本根本不会尝试的任务。Anthropic 内部调查显示，约 27% 的 Claude Code 辅助任务，是没有这个工具就根本不会被尝试的工作。
价值观五：情境适应性
系统要适配用户的具体项目、工具和习惯，并随时间改善。纵向数据显示，用户的自动批准率从前 50 次会话的约 20% 增长到 750 次会话后的超过 40%，会话时长也显著增加。这不是用户变懒了，而是信任在逐渐建立。
基于这五个价值观，研究者梳理出十三条设计原则，每条原则都回答一个具体的工程问题（见 Table 1：十三条设计原则与对应价值观、设计问题的完整映射）。
Table 1：十三条设计原则与对应价值观、设计问题
| 设计原则 | 服务的价值 | 回答的问题 |
|---|---|---|
| 拒绝优先 + 人类升级 | 权威、安全 | 未识别动作应默认允许、阻止，还是升级给人？ |
| 分级信任光谱 | 权威、适应性 | 权限是固定档位，还是随使用关系逐步变化？ |
| 多层防御机制 | 安全、权威、可靠性 | 靠单一安全边界，还是多种机制叠加？ |
| 外部化可编程策略 | 安全、权威、适应性 | 策略写死在代码里，还是放到配置和生命周期钩子里？ |
| 上下文是稀缺资源 | 可靠性、能力 | 用一次性截断，还是渐进式管线管理上下文？ |
| 追加式持久状态 | 可靠性、权威 | 用可变状态、快照，还是追加日志？ |
| 极简脚手架 + 最大运营 harness | 能力、可靠性 | 让框架替模型推理，还是把工程环境做好，让模型自由推理？ |
| 价值优先于规则 | 能力、权威 | 靠僵硬规则，还是用确定性护栏支持情境判断？ |
| 多机制可组合扩展 | 能力、适应性 | 用统一扩展 API，还是按上下文成本分层？ |
| 按可逆性加权风险 | 能力、安全 | 所有动作同等监管，还是可逆/只读动作更轻？ |
| 透明文件式配置和记忆 | 适应性、权威 | 用黑盒数据库/向量检索，还是用户可读可版本控制的文件？ |
| 隔离的子智能体边界 | 可靠性、安全、能力 | 子智能体共享父上下文和权限，还是隔离运行？ |
| 优雅恢复和韧性 | 可靠性、能力 | 遇错直接失败，还是自动恢复，把人的注意力留给不可恢复问题？ |
架构长什么样：七个组件，五层结构
七个功能组件
Claude Code 的整体结构可以分解为七个功能组件（见 Figure 1：Claude Code 高层系统结构图）：
用户：提交提示词、批准权限、查看输出
接口层：交互式终端、无头 CLI（命令行接口，不带图形界面）、Agent SDK（软件开发工具包）、IDE/桌面/浏览器——所有入口汇入同一个循环
智能体循环：模型调用、工具分发、结果收集的迭代循环
权限系统：拒绝优先的规则评估、ML（机器学习）分类器、钩子拦截
工具集：最多 54 个内置工具，加上 MCP（模型上下文协议，一种让 AI 连接外部工具的标准协议）提供的外部工具
状态与持久化：会话记录、全局提示历史、子智能体侧链文件
执行环境：shell 命令执行、文件系统操作、网络请求、MCP 服务器连接
Figure 1：Claude Code 高层系统结构图：七个功能组件从用户入口一路汇入同一个 Agent Loop，再经过权限、工具、状态与执行环境。
一个关键设计选择：所有接口共用同一个核心循环。无论你是在终端交互、还是通过 SDK 调用、还是在 IDE 里使用，底层走的是同一套 queryLoop() 代码。只有渲染和用户交互层不同。
五层子系统
更细粒度的视角把架构分成五层（见 Figure 3：五层子系统架构展开图）：
表面层：各种入口和渲染
核心层：智能体循环 + 五层压缩管道
安全/行动层：权限系统、钩子管道、工具集、沙箱、子智能体
状态层：上下文组装、运行时状态、会话持久化、CLAUDE.md 记忆
后端层：执行后端和外部资源
Figure 3：Claude Code 五层子系统架构：把高层组件继续拆成表面层、核心层、安全/行动层、状态层和后端层，更容易看清 98.4% 基础设施到底在哪里。
核心循环：一个 while 循环的艺术
Claude Code 的核心是一个 queryLoop() 异步生成器函数，逻辑很简单（见 Figure 2：单次智能体轮次的端到端执行流程图）：
组装上下文（设置、历史记录）
调用模型，获取响应
如果响应包含工具调用请求，走权限检查
权限通过，执行工具，把结果加入对话
如果响应只有文本（没有工具调用），本轮结束
否则继续循环
Figure 2：单次智能体轮次执行流程：一次用户请求会经历上下文组装、模型调用、权限检查、工具执行、结果回灌和必要时的上下文压缩。
这个模式在学术上叫 ReAct（推理-行动交替，一种让 AI 边思考边执行的框架）。模型生成推理和工具调用，harness（执行框架）执行动作，结果反馈给下一轮迭代。
循环有五个终止条件：没有工具调用（正常结束）、达到最大轮次限制、上下文溢出、钩子干预、显式中止信号。
工具执行：并行读，串行写
当模型响应包含多个工具调用时，系统区分两类操作：
只读操作（如读文件、搜索）：可以并行执行
状态修改操作（如执行 shell 命令）：必须串行执行
并行执行有两个协调机制：兄弟中止控制器（任何一个 Bash 工具报错，立即终止其他正在运行的子进程）和进度信号（有新输出时唤醒结果收集器）。结果按工具调用顺序输出，即使并行运行也保持顺序一致，因为模型期望结果和请求顺序对应。
五层预模型上下文处理
每次调用模型之前，系统会依次执行五个上下文处理步骤（见 Figure 6：上下文构建与记忆层次图）：
第一层：预算削减（始终激活）。对每个工具结果强制执行大小限制，超出的内容用引用替代。
第二层：Snip（功能标志控制）。轻量级裁剪旧历史片段。有一个技术细节：主 token 计数器从最近一条助手消息的 usage 字段获取上下文大小，而这条消息在 Snip 后依然保留着 Snip 前的 input_tokens 值，所以节省的 token 对计数器不可见，必须显式传递。
第三层：微压缩（功能标志控制）。细粒度的缓存感知压缩，可以等到 API 响应后再用实际的缓存删除 token 数，而不是估算值。
第四层：上下文折叠（功能标志控制）。这一层不修改存储的历史，而是在读取时生成一个虚拟投影，模型看到的是折叠后的版本，完整历史依然保留用于重建。
第五层：自动压缩（默认启用，可关闭）。前四层都不够用时，调用模型本身生成一个语义摘要，彻底压缩上下文。
五层按成本从低到高依次执行，前面的层次失效才触发后面的。这是一种"懒降级"策略，代价是复杂性：五层相互作用，部分由功能标志控制，产生的行为很难完全预测。
权限系统：七种模式，拒绝永远优先
权限系统是整个架构里最精密的部分（见 Figure 4：权限门概览与设计原则图）。
Figure 4：权限门与设计原则：权限系统不是一个开关，而是一组拒绝优先、可分层叠加、可被钩子和沙箱共同约束的安全门。
七种权限模式
从最严格到最宽松：
plan：执行前必须用户批准计划
default：标准交互模式，大多数操作需要用户批准
acceptEdits：工作目录内的编辑和特定文件系统命令（mkdir、rm、mv 等）自动批准，其他 shell 命令仍需批准
auto：ML 分类器评估请求（需要功能标志激活）
dontAsk：不提示，但拒绝规则仍然生效
bypassPermissions：跳过大多数提示，但安全关键检查依然存在
bubble：内部专用，用于子智能体向父智能体上报权限请求
拒绝规则永远优先于允许规则，即使允许规则更具体也不例外。一个宽泛的"拒绝所有 shell 命令"规则，无法被一个具体的"允许 npm test"规则覆盖。
七层独立防御
权限管道有七个独立层次，任意一层都可以阻止请求：
工具预过滤：在模型看到工具列表之前，就把被禁止的工具从列表中移除
拒绝优先规则评估
权限模式约束
自动模式 ML 分类器
Shell 沙箱（独立于应用层权限模型运行）
恢复时不还原权限（会话级权限不跨会话持久化）
钩子拦截
这七层的设计假设是相互独立：一层失效，其他层补上。但研究者指出了一个结构性问题：这些层共享性能约束。安全研究人员（Adversa.ai）记录了一个案例：当 shell 命令包含超过 50 个子命令时，系统会退化为一个通用批准提示，而不是逐个子命令检查，原因是逐个解析导致 UI 卡顿。这说明当防御层共享失败模式时，深度防御会降级。
一个重要的安全漏洞模式
研究者引用了 Check Point Research 发现的两个漏洞（CVE-2025-59536，CVSS 评分 8.7；CVE-2026-21852，CVSS 评分 5.3），两者共享同一个根本原因：初始化时序问题。
钩子、MCP 服务器连接、设置文件解析，在用户看到信任对话框之前就已经执行了。这意味着权限管道描述的是空间顺序（哪些检查存在），而不是时间顺序（这些检查什么时候生效）。扩展性架构在安全架构完全激活之前就已经运行，形成了一个特权初始化窗口。
这四个漏洞均在披露后数周内被修补。
四种扩展机制：按上下文成本分层
Claude Code 提供四种扩展机制，而非统一的单一 API（见 Table 2：四种扩展机制的能力、上下文成本与注入点对比）。
Figure 5：扩展机制插入 Agent Loop 的三个位置：MCP、插件、技能和钩子并不是同一种扩展，它们分别影响模型看到什么、能调用什么、以及动作能否真正执行。
Table 2：四种扩展机制的能力、上下文成本与注入点
| 机制 | 独特能力 | 上下文成本 | 插入点 |
|---|---|---|---|
| MCP servers | 外部服务集成，多传输协议 | 高，工具 schema 占上下文 | model() 的工具池 |
| Plugins | 多组件打包和分发 | 中，取决于组件 | 三个位置都可能影响 |
| Skills | 领域指令和 meta-tool 调用 | 低，默认只暴露描述 | assemble() 的上下文注入 |
| Hooks | 生命周期拦截和事件自动化 | 默认零上下文 | execute() 的前后置拦截 |
MCP 服务器：主要的外部工具集成路径。MCP 是一个开放协议，允许 AI 连接外部服务。每个连接的服务器贡献工具定义，模型可以调用这些工具。上下文成本高（工具模式会占用大量上下文窗口）。
插件：打包和分发机制。一个插件可以同时包含命令、技能、钩子、MCP 服务器、LSP（语言服务器协议）服务器、输出样式等十种组件类型，是第三方扩展的主要分发渠道。
技能（Skills）：每个技能由一个 SKILL.md 文件定义，包含 YAML 前置元数据（名称、描述、允许的工具、模型覆盖等 15 个以上字段）。技能注入的是指令，而不是工具本身，上下文成本低（只有描述信息留在提示中）。
钩子（Hooks）：生命周期拦截机制。源代码定义了 27 种钩子事件，覆盖工具授权、会话生命周期、用户交互、子智能体协调、上下文管理等。默认不消耗上下文。
为什么是四种而不是一种？因为不同的扩展需求对上下文窗口的消耗差异巨大。钩子不消耗上下文，可以大量使用；MCP 服务器消耗高，应该谨慎引入。强行统一会迫使扩展作者在不必要的场景下付出高昂的上下文成本（见 Figure 5：四种扩展机制在智能体循环中的注入点示意图）。
工具池组装
assembleToolPool() 函数是"组合内置工具与 MCP 工具的唯一真相来源"，按五步流程执行：
枚举基础工具（最多 54 个，19 个始终包含，35 个根据功能标志和用户类型条件包含）
模式过滤（简单模式下只有 Bash、Read、Edit 三个工具）
拒绝规则预过滤（从模型视图中移除被禁止的工具）
合并 MCP 工具
去重（内置工具优先于 MCP 工具）
上下文与记忆：文件比数据库更透明
上下文窗口的组装顺序
上下文窗口从多个来源组装，按加载时机分层（见 Figure 6：上下文构建与记忆层次图）：
启动时加载：系统提示、环境信息（git 状态等）、CLAUDE.md 层次结构
每轮累积：对话历史、子智能体摘要
执行时添加：读取的文件、命令输出、工具结果
按需懒加载：延迟加载的工具定义（通过 ToolSearch 触发）
Figure 6：上下文构建与记忆层次：Claude Code 把系统提示、环境信息、CLAUDE.md、工具结果、子智能体摘要和压缩摘要等来源按成本分层装入上下文。
CLAUDE.md：透明的文件式记忆
Claude Code 的记忆系统选择了一个有趣的设计：纯文本 Markdown 文件，而非数据库或向量索引。
四级层次结构：
系统级（/etc/claude-code/CLAUDE.md）：OS 层面对所有用户的策略
用户级（~/.claude/CLAUDE.md）：私有全局指令
项目级（项目根目录的 CLAUDE.md 等）：随代码库提交的指令
本地级（.claude.local.md，被 gitignore 忽略）：私有的项目特定指令
文件从当前目录向上遍历到根目录，越靠近当前目录的文件优先级越高（后加载，模型注意力更多）。
这个选择的核心含义：用户可以读取、编辑、版本控制、删除智能体看到的任何指令。代价是灵活性，无法像向量检索那样精确定位单条记忆。
内存检索不使用向量相似度索引，而是用 LLM（大语言模型）扫描记忆文件头部，按需选择最多五个相关文件。
一个重要的架构细节：CLAUDE.md 内容作为对话上下文（用户消息）传递，而不是系统提示。这意味着模型对这些指令的遵从是概率性的，而非确定性的。确定性执行由权限规则负责，两者刻意分离：CLAUDE.md 是指导（概率性），权限规则是执行（确定性）。
子智能体：隔离边界是关键
当任务需要委托时，Claude Code 通过 AgentTool 派生子智能体（见 Figure 7：子智能体隔离与委托架构图）。
Figure 7：子智能体隔离与委托架构：AgentTool 可以派生 Explore、Plan、通用型等子智能体，并通过权限重建、工具集隔离、工作树/远程/进程内隔离来控制边界。
六种内置子智能体类型
根据功能标志和入口点，最多有六种：
Explore：主要用于只读/搜索型探索，写入和编辑工具在其拒绝列表中
Plan：创建结构化计划，执行通过标准权限模型进行
通用型：广泛能力，明确请求时使用
Claude Code Guide：入门和文档辅助，有自己的权限模式覆盖
Verification：运行验证检查（测试套件、代码检查）
Statusline-setup：专门用于终端状态行配置
用户还可以通过 .claude/agents/*.md 文件定义自定义子智能体，YAML 前置元数据指定工具允许列表、禁止列表、模型、权限模式、钩子、最大轮次、记忆范围等配置。
三种隔离模式
工作树（Worktree）隔离：创建临时 git 工作树，子智能体有自己的仓库副本，不影响父智能体的工作目录
远程隔离（仅内部用户）：在远程 Claude Code 环境中运行，始终在后台执行
进程内隔离（默认）：共享文件系统，但在独立的对话上下文中运行
关键的上下文节约设计
子智能体只把最终响应文本和元数据返回给父智能体，完整的子智能体对话历史永远不进入父智能体的上下文窗口。每个子智能体的对话存储在独立的 .jsonl 侧链文件中，不会膨胀父会话文件。
这个设计的成本数据值得关注：在计划模式下，智能体团队消耗的 token 约是标准会话的 7 倍。摘要式返回在这种情况下尤为关键。
多实例协调使用文件锁而非消息代理或分布式协调服务。任务通过锁文件互斥声明，锁文件存储在可预测的文件系统路径。这换来两个属性：零依赖部署（不需要外部基础设施）和完全可调试性（任何智能体的状态都可以通过读取纯文本 JSON 文件检查）。
会话持久化：追加优先，恢复时不还原权限
三个独立的持久化通道
会话记录：以项目为范围的 JSONL 文件，每个会话一个文件，包含用户/助手/附件/系统消息，以及压缩标记和其他元数据事件
全局提示历史：仅存储用户提示，保存在 Claude 配置目录的 history.jsonl，支持上箭头和 Ctrl+R 导航
子智能体侧链：每个子智能体独立的 .jsonl + .meta.json 文件
追加优先的 JSONL 格式是刻意的选择：每个事件都是人类可读的，可以版本控制，无需专用工具重建。代价是无法做结构化查询。
恢复时不还原权限
--resume 标志通过重放记录重建对话，但不还原会话级权限，用户必须在新会话中重新授权。
Figure 8：会话持久化与上下文压缩：图中区分了实时上下文窗口、压缩摘要、会话 transcript、全局 history、子智能体侧链和 checkpoint；恢复会话会恢复消息，但不会恢复会话级权限。
这是刻意的安全保守设计：会话被视为独立的信任域。还原之前授予的权限会带来便利，但风险是把过期的信任决策带入已经改变的上下文。架构选择了重新授权而非隐式持久化，以用户摩擦换取安全不变量。
与 OpenClaw 的对比：相同问题，不同答案
OpenClaw 是一个开源的本地优先 WebSocket 网关，连接约二十个消息平台（WhatsApp、Telegram、Slack、Discord、Signal 等）到一个嵌入式智能体运行时，有 macOS、iOS、Android 配套应用。
Claude Code 是一个临时进程，绑定到单个代码仓库会话。OpenClaw 是一个持久守护进程，是多渠道个人助手的控制平面。
两者的对比揭示了一个核心结论：设计问题是稳定的，答案随部署场景变化（见 Table 3：Claude Code 与 OpenClaw 六个设计维度的架构对比）。
Table 3：Claude Code 与 OpenClaw 的六个架构维度对比
| 维度 | Claude Code | OpenClaw |
|---|---|---|
| 系统范围 | CLI/IDE 编程 harness，按会话临时运行 | 持久 WebSocket 网关守护进程，多渠道控制平面 |
| 信任模型 | 每次动作拒绝优先评估，配合钩子、可选 ML 分类器和 7 种权限模式 | 单个受信操作员、DM 配对和入口 allowlist，沙箱按配置开启 |
| Agent 运行时 | queryLoop() 异步生成器是系统中心 |
Pi-agent runner 嵌入网关 RPC 分发和会话队列 |
| 扩展架构 | MCP、插件、技能、钩子四种机制，按上下文成本分层 | Manifest-first 插件系统，12 类能力 + 中央注册表 + MCP 能力 |
| 记忆与上下文 | 四级 CLAUDE.md，五层压缩管线，LLM 扫描记忆 | AGENTS/SOUL/TOOLS/IDENTITY/USER 等启动文件，独立记忆系统和可选混合检索 |
| 多智能体与路由 | 任务委托型子智能体、工作树隔离、摘要返回父智能体 | 多智能体路由与子智能体委托分离，支持嵌套深度和线程绑定会话 |
六个维度的对比
系统范围：Claude Code 是每次会话的临时 CLI 进程。OpenClaw 是持久守护进程（默认端口 18789，仅回环地址），拥有所有消息平面连接。
信任模型：Claude Code 假设不受信任的模型在受信任的开发者机器上运行，逐动作评估；OpenClaw 假设每个网关实例有一个受信任的运营者，安全架构从身份和访问控制开始（DM 配对码、发送者允许列表），而不是逐动作安全分类。OpenClaw 的安全文档明确说明，敌对多租户隔离不是支持的安全边界。
智能体运行时：Claude Code 的 queryLoop() 是系统中心，所有接口都汇入它。OpenClaw 的智能体运行时（嵌入式 Pi-agent 核心）位于更大的网关分发层内部，网关的智能体 RPC 验证参数、解析会话后立即返回，嵌入式运行器再执行智能体循环。
扩展架构：Claude Code 的四种扩展机制按上下文成本分层，修改单个智能体的行动面。OpenClaw 使用清单优先的插件系统，有四个架构层（发现、启用、运行时加载、表面消费）和十二种能力类型，插件扩展的是跨所有智能体的网关能力面。
记忆与上下文：两者都使用透明的文件式记忆。Claude Code 投入更多在渐进式上下文压缩（五层管道）；OpenClaw 投入更多在结构化长期记忆，包括每日笔记（memory/YYYY-MM-DD.md）、可选的梦境整合系统（后台整合，评分后只把合格的条目从短期记忆提升到长期记忆）、混合检索（向量相似度 + 关键词匹配，需要配置嵌入提供者）。
多智能体架构：Claude Code 是任务委托模型，子智能体是下属工作者，返回摘要给父智能体。OpenClaw 分离两个关注点：多智能体路由（一个网关可以托管多个完全独立的智能体，各有自己的工作空间、认证配置、会话存储）和子智能体委托（可配置嵌套深度，最大 5 层，默认 1 层，推荐 2 层）。OpenClaw 的项目愿景明确拒绝将智能体层级框架作为默认架构。
一个有趣的组合关系：OpenClaw 可以通过 ACP（智能体客户端协议）将 Claude Code 作为外部编程工具托管。两者不是纯粹的替代关系，而是可以叠加的。这说明 AI 智能体的设计空间是分层的，而非扁平的。
架构权衡：五组真实的张力
研究者整理了五组有实证支撑的价值观张力（见 Table 4：价值观张力与支撑证据）。
Table 4：价值观张力与支撑证据
| 价值对 | 张力 | 证据 |
|---|---|---|
| 权威 × 安全 | 批准疲劳 vs 保护 | 93% 批准率削弱人类警觉，安全必须由分类器和沙箱补位。 |
| 安全 × 能力 | 性能 vs 防御深度 | 超过 50 个子命令时会跳过逐子命令拒绝检查，因为解析开销会拖慢 UI。 |
| 适应性 × 安全 | 扩展性 vs 攻击面 | 多个 CVE 利用了 hooks 和 MCP servers 的预信任初始化窗口。 |
| 能力 × 适应性 | 主动性 vs 打扰 | 主动助手可多完成 12% 到 18% 任务，但高频触发会显著降低偏好。 |
| 能力 × 可靠性 | 速度 vs 连贯性 | 上下文边界、子智能体隔离和复杂度增长都会削弱长期一致性。 |
权威 × 安全：93% 的批准率说明人类监督已经不可靠，安全必须独立于人类的注意力运作。
安全 × 能力：超过 50 个子命令的 shell 命令会跳过逐子命令的拒绝规则检查，因为逐个解析导致 UI 卡顿。性能压力让安全层降级。
适应性 × 安全：多个 CVE 漏洞利用了钩子和 MCP 服务器的预信任初始化，扩展性创造了攻击面。
能力 × 适应性：主动式 AI 助手让任务完成率提高 12% 到 18%，但在高频率下用户偏好显著下降（47% vs 80-90%）。
能力 × 可靠性：有界的上下文窗口阻止智能体同时感知完整代码库；子智能体隔离限制了跨智能体的一致性。对 807 个代码库的因果分析发现，Cursor 使用后代码复杂度增加了 40.7%，初始速度提升（第一个月 +281%）到第三个月消退回基线，上升的复杂度与未来开发速度的下降成比例。
一个被架构忽视的问题：长期人类能力
研究者把"长期人类能力保存"作为一个评估视角，而不是设计价值观，因为它在架构中几乎没有对应的设计机制。
相关数据令人不安：
一项对 16 名有经验的开发者进行的随机对照试验（246 个任务）发现，AI 工具让开发者慢了 19%，尽管他们自我感觉提升了 20%
对 807 个代码库的因果分析：代码复杂度增加 40.7%
一项 EEG（脑电图）研究（54 名参与者）发现，LLM 用户的神经连接减弱，在移除 AI 后依然持续
一项对 AI 辅助编程的理解力测试：AI 辅助条件下开发者得分低 17%
2023 年到 2024 年间，初级技术岗位招聘下降 25%
Anthropic 自己的研究记录了"监督悖论"：过度依赖 AI 可能削弱监督它所需的技能。
研究者的结论是：未来的系统应该把这个可持续性差距作为一等设计问题，而不是事后的评估指标。
六个开放的设计问题
研究者最后提出了六个尚未解决的方向：
沉默失败与可观测性差距。行业调查估计 78% 的 AI 失败是不可见的。LangChain 对 1340 名受访者的调查发现，可观测性采用率接近 89%，但离线评估只有 52.4%。关闭这个差距可能需要在 harness 层增加生成器-评估器分离等机制。
跨会话持久化。当前架构在静态指令（CLAUDE.md）和单次会话记录之间缺少一层：既不是静态指令，也不是单次会话的记录，而是从过去会话中积累的可复用策略。
harness 边界演化。随着模型能力提升，harness 的有趣组合不会减少，只会移动。未来的演化可能在四个维度展开：在哪里运行、什么时候行动（主动式 AI）、作用于什么（文本之外的物理动作）、与谁协作（多智能体）。
长视野扩展。当前架构的基本单元是轮次、会话和子智能体。当自主工作延伸到多个会话甚至数周时（如自主科研系统），现有机制是否还够用？
治理与监管。EU AI Act（欧盟人工智能法案）将于 2026 年 8 月全面适用。MIT AI 智能体指数发现，只有 13.3% 的已索引智能体系统发布了智能体特定的安全说明。当前的拒绝优先评估在内部可审计，但尚未达到新兴监管框架要求的外部可审计形式。
长期人类能力保存的设计化。这是最难的问题：如果我们有了衡量认知卸载和理解力退化的会话级信号，架构应该如何响应？这不只是测量问题，而是设计问题。
对智能体构建者的实际启示
这份分析最核心的结论是：随着前沿模型在编程任务上的实际能力趋于收敛，周围的运营 harness 质量成为主要差异化因素。
在确定性基础设施上的投入，比在模型周围叠加规划脚手架，可能带来更大的可靠性收益。
具体来说：
上下文管理、安全分层和恢复机制比显式规划图更值得投入
拒绝优先的默认安全姿态，加上多层独立防御，比单一隔离边界更稳健，但要警惕防御层共享失败模式的问题
文件式透明记忆在可审计性上有独特优势，但需要配合渐进式压缩来管理上下文压力
四种扩展机制按上下文成本分层，是一个值得借鉴的设计模式
追加优先的持久化设计，以查询能力换取可审计性和简单性，是一个合理的权衡
最后一个问题留给每个在构建或使用这类工具的人：当工具让你完成了更多工作，你自己理解了多少？
原文标题：Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems
作者：Jiacheng Liu, Xiaohan Zhao, Xinyi Shang, Zhiqiang Shen（MBZUAI / UCL）