一篇不谈跑分的 Agent 论文
关于 AI Agent 的讨论过去很长一段时间都围绕模型能力展开：谁更会写代码，谁在 benchmark 上得分更高，谁在自动化任务中表现更稳定。但一篇题为 Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems 的新论文，试图把讨论重心从模型本身转向系统架构。
这篇论文做的不是性能测试，也不是新算法发布，而是直接分析 Claude Code 的公开 TypeScript 源码，并将其与 OpenClaw 这一开源 AI Agent 系统进行对照，试图回答一个更底层的问题：一个真正可用的生产级 Agent，到底是靠什么运转起来的。
论文作者的结论相当明确：Claude Code 的核心 agent loop 本身并不复杂，真正复杂、也真正决定产品质量的，是围绕这个 loop 搭建起来的一整套操作系统式基础设施，包括权限系统、上下文压缩、扩展机制、子代理隔离与会话持久化。
Read more: arXiv
Claude Code 的核心 loop 并不神秘
论文给出的一个关键判断是，Claude Code 的底层运行机制其实非常朴素。它本质上是一个持续迭代的查询循环：组装上下文、调用模型、接收 tool use 请求、执行工具、把结果再喂回模型，然后继续下一轮，直到模型不再请求工具。
这种架构并不意味着简单粗暴。相反，作者认为正因为核心 loop 足够简单，工程复杂度才被有意放到了 loop 外部。论文引用的估算认为，Claude Code 代码库中真正负责 AI 决策逻辑的部分只占很小比例，而绝大部分都是运行支撑基础设施。
换句话说，这类 Agent 的竞争，越来越不像“谁的脑子更大”，而更像“谁的运行时系统更成熟”。
真正关键的是外围系统，而不是单次模型调用
论文把 Claude Code 的复杂性拆成了几个核心外围系统。
第一是权限与安全控制。作者指出，Claude Code 并不是简单靠“每次都弹窗询问用户”来保证安全，而是采用 deny-first 的权限逻辑，再叠加规则引擎、模式切换、自动分类器、shell sandbox、hook 拦截等多层机制。论文特别强调，用户对权限弹窗会出现明显的批准疲劳，因此真正可靠的安全设计不能只依赖用户每次认真审核。
第二是上下文管理。随着 Agent 会话变长、工具输出变多，context window 会迅速成为硬约束。论文认为 Claude Code 对这一问题的回答，不是单一压缩策略，而是一条多层 compaction pipeline：从结果裁剪，到轻量历史压缩，再到更激进的 collapse 和自动摘要压缩。作者的观点是，没有任何一种上下文压缩手段足以独立处理所有情形，因此需要一个递进式的体系。
第三是扩展能力。Claude Code 并没有把扩展统一成单一接口，而是保留了 MCP、plugins、skills、hooks 四种机制。论文的解释是，这并不是重复造轮子，而是在按不同的上下文成本与能力边界分层设计：有些扩展几乎不消耗上下文，有些则提供更强的外部能力，但代价也更高。
第四是 subagent 机制。论文指出，Claude Code 的子代理并不是简单复制父会话，而是通过隔离上下文、独立工作、最后只向父代理返回摘要的方式，避免子任务把主会话的上下文和状态彻底撑爆。这也是它处理多步骤任务时保持可扩展性的关键设计之一。
第五是持久化与恢复。Claude Code 将会话过程主要记录为 append-oriented 的 transcript，并支持 resume、fork 和 rewind 等操作。论文认为，生产级 Agent 不只是“这次任务做完”，还要能在中断、恢复、分支和回滚场景下维持可审计性与可恢复性。
论文最有意思的地方，是拿 OpenClaw 做对照
全文中最值得注意的一部分，是作者没有把 Claude Code 当成孤例，而是专门把它和 OpenClaw 放在一起比较。
论文给出的判断是，两者回答的是同一类架构问题，但起点完全不同。Claude Code 是一个偏 CLI 与 IDE 场景的 coding harness，更像围绕单个仓库和单条任务流运行的 agent。OpenClaw 则是一个多渠道、长期在线的 personal assistant gateway，更像一个带控制平面的常驻系统。
正因为起点不同，它们在架构上的答案也明显不同。
在信任模型上，Claude Code 的边界主要在模型与执行环境之间，因此它特别强调对每一个动作进行权限判断和安全分层。OpenClaw 的边界则更多在 gateway perimeter，也就是先处理身份、接入、配对和允许谁进入系统，再去管理后续能力调用。
在运行时结构上，Claude Code 的 query loop 本身就是系统中心；而在 OpenClaw 中，agent loop 只是更大网关控制平面中的一个部件。前者更像“任务级 harness”，后者更像“系统级 agent runtime”。
在扩展方式上，Claude Code 的扩展是在修改单个 agent 的 action surface，而 OpenClaw 的插件和技能体系扩展的是整个 gateway 的 capability surface。一个强调单任务工作流，另一个强调全局能力注册与多渠道复用。
论文还指出，这种差异并不意味着二者互斥。恰恰相反，它们可以组合：OpenClaw 完全可以把 Claude Code 当成外部 coding harness 纳入自己的体系中。这一点也让作者得出一个更大的判断：AI Agent 的设计空间不是扁平的，不同层级的系统可以叠加，而不是非此即彼。
这篇论文真正抬高了 Agent 讨论的层次
从全文看，这篇论文最重要的贡献不是“发现了 Claude Code 的什么隐藏技巧”，而是把 AI Agent 的讨论从“模型会不会”抬升到“系统怎么组织”。
作者给出的中心思想可以概括为一句话：当模型能力逐步趋同之后，真正拉开差距的将不再只是模型本身，而是围绕模型搭建的 deterministic infrastructure。谁能把权限、安全、上下文、恢复、扩展与长期记忆组织得更稳，谁就更可能做出真正可用的 Agent 产品。
这也是为什么论文会把大量篇幅放在 permission、compaction、hooks、subagents 和 persistence 上，而不是单独讨论 prompting 技巧。对生产级 Agent 来说，问题已经不只是“怎么让模型想对”，而是“怎么让系统长期、可控、可恢复地运转”。
但论文也没有回避一个更尖锐的问题
值得注意的是，作者并没有把 Claude Code 这样的架构当成最终答案。论文在讨论与未来方向部分提出了一个更难的问题：这些系统虽然显著放大了人的短期能力，却未必有足够机制来保护人的长期能力。
作者担心的不是短期效率，而是更深层的后果：开发者是否会越来越依赖 Agent 以至于难以监督它，代码库是否会因为大量自动化修改而逐渐失去整体一致性，新人培养是否会因为持续的 AI 代劳而受到影响。
在这一点上，这篇论文比很多“Agent 万能论”式文章更冷静。它承认系统架构的重要性，也承认架构仍然没有解决长期人类能力保留的问题。
结语
如果把这篇论文压缩成一个判断，它要说的并不是“Claude Code 为什么比别人更聪明”，而是“生产级 AI Agent 的竞争，正在从模型能力转向系统架构能力”。
Claude Code 的案例说明，一个 Agent 能否稳定工作，越来越取决于它的权限边界、上下文压缩、扩展方式、子代理设计与持久化能力；而 OpenClaw 的对照则进一步说明，同样的问题在不同部署场景下会得到完全不同的架构答案。
对于正在构建下一代 AI Agent 产品的人来说，这篇论文真正有价值的地方，或许不是它拆解了 Claude Code，而是它提醒行业：模型只是起点，系统设计才是分水岭。