Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems解读
原文：Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems
arXiv: 2604.14228
这是一篇偏“架构解剖”和“设计空间梳理”的论文，不是在提出一个全新的 agent 框架，而是在借 Claude Code 这个具体样本，总结今天 AI Agent System 到底在解决哪些核心工程问题。
一句话结论
如果只用一句话概括这篇文章，那就是：
现代 AI Agent 的难点，早就不只是模型本身，而是如何把模型包进一个可控、可扩展、可恢复、可长期使用的系统里。
Claude Code 在论文中被当作一个非常典型的案例：它的核心 loop 很简单，但真正让它成为“产品级 agent”的，是围绕 loop 建起来的一整套运行环境。
这篇文章到底在做什么
作者采用的是一种很直接的方法：
- 研究 Claude Code 的公开 TypeScript 源码
- 从源码中抽象出它的系统设计逻辑
- 再把这些设计选择和 OpenClaw 进行对比
- 最后给出对“未来 agent 系统”的一些开放问题
也就是说，这篇文章不是在回答“Claude Code 好不好用”，而是在回答：
Claude Code 这样的 agent 产品，背后的工程设计空间到底长什么样？
这也是本文最有价值的地方。它没有停留在“这是个会改代码、会跑命令的智能体”这种表面描述，而是继续往下拆：
- agent 的决策循环是什么
- 权限控制怎么做
- 上下文为什么必须压缩
- 扩展能力怎么分层
- 子代理怎么隔离
- 状态和会话为什么要可恢复、可审计
换句话说，这篇文章真正讨论的是：
一个 agent demo 如何变成一个 agent system。
Claude Code 的核心，其实没有那么神秘
论文里有一个非常重要、但也非常容易被忽略的判断：
Claude Code 的核心 loop 其实很简单，就是一个不断重复的循环：调用模型 → 执行工具 → 读取结果 → 再调用模型。
这个结论本身不新，但它的意义很大。
因为现在很多人谈 agent 时，容易把重点放在“是不是用了 planner”“有没有复杂工作流图”“是不是多智能体协作”。而这篇文章提醒我们：
真正让 agent 难做的，并不是那个推理循环本身，而是推理循环周围的系统工程。
也就是说，一个能跑起来的 agent 可能并不难做，但一个：
- 不容易误操作
- 能跨多轮任务继续工作
- 能管理好上下文
- 能接入外部工具
- 能处理失败和恢复
- 能让人类保留控制权
的 agent，才是“产品级”的 agent。
Claude Code 在这篇文章中被描述成这样一个系统：它的中心很朴素，但外围基础设施很重。
论文提出的核心视角：五个价值
作者认为，Claude Code 的架构不是随机长出来的，而是被五类“人类价值/设计目标”牵引出来的。
这五个价值是：
-
Human decision authority（人类决策权）
人类必须保持最终决定权，系统不能在关键问题上完全自作主张。 -
Safety, security, and privacy（安全、安全性与隐私）
既要避免误操作，也要避免系统、代码、数据、环境受到伤害。 -
Reliable execution（可靠执行）
agent 不能只是在 demo 里看上去聪明，而要在真实任务中稳定推进。 -
Capability amplification（能力放大）
这个系统存在的意义，是让人能做更多、更复杂的事，而不只是节省几次点击。 -
Contextual adaptability（情境适应）
它要能适应不同项目、不同任务、不同环境，而不是只适合一种固定工作流。
这五个价值听起来像“理念层”的东西，但论文的重点在于：它把这些理念继续往下落，变成架构层面的设计原则。
从价值到系统：13 条设计原则
作者进一步总结出 13 条设计原则。严格逐条展开会比较学术，这里用更白话的方式整理几个最关键的。
1）默认谨慎，不默认乱放权
论文强调了一种典型思路：deny-first。
也就是系统默认不把危险能力完全放开，而是在需要时逐步升级权限。这个思想的底层逻辑很现实：用户一开始可能会认真看弹窗，但时间长了，审批很容易变成肌肉记忆。
因此，真正成熟的 agent 安全设计，不该只是“每步都问你一下”，而应该是：
- 先划定安全边界
- 在边界内允许 agent 高效行动
- 超出边界时再交还给人判断
这比密集弹确认框更合理。
2）信任不是开或关，而是分层递进
论文把这种思路称为 graduated trust spectrum。简单说，agent 的权限不该只有“完全自动”和“完全手动”两档，而应该随着任务类型、环境、工具类别、操作风险，逐步放开。
这背后其实是很典型的产品思想：
用户真正需要的不是绝对自动化，而是“在我能接受的风险范围内自动化”。
3）上下文是一种稀缺资源
这是全文非常关键的一点。作者明确把 context management 当成主问题，而不是附属问题。
原因也很简单：agent 一旦进入多步任务，它的上下文会迅速膨胀。历史操作、工具输出、文件内容、错误日志、用户反馈，都会不断堆积。
如果没有分层管理机制，模型很快就会：
- 看不全
- 记不住
- 抓不到重点
- 在后续步骤里越来越偏
因此，Claude Code 被论文描述为拥有“五层压缩管线”的系统。你不一定需要记住每一层叫什么，但要记住它传达的工程判断：
大上下文并不等于好 agent，真正重要的是能否筛选、压缩、重组、恢复有用上下文。
4）状态应该尽量可追加、可追溯、可恢复
论文提到 append-oriented session storage，这背后的思想也很重要。
对 agent 来说，状态不是为了“记住聊天”这么简单，而是为了：
- 出错时能回看
- 中断后能继续
- 审计时能追踪
- 长任务里能保持一致性
这让 agent 更像一个可恢复系统，而不是一次性的对话工具。
5）尽量少硬编码决策图，尽量把系统能力做扎实
作者认为 Claude Code 走的是一种“轻脚手架、重运行环境”的路线。换句话说，它并不特别依赖显式状态图或者固定流程，而是把重点放在：
- 工具系统
- 权限系统
- 上下文系统
- 扩展机制
- 会话持久化
- 子代理协作
也就是说，它更相信：
不要替模型规定过多路径，而是给模型一个受控但强大的操作环境。
这是一种非常有代表性的 agent 产品哲学。
这篇文章最重要的一层：它讲的是“设计空间”
我觉得，本文最大的价值不是“解读了 Claude Code”，而是提出了一个更通用的框架：
任何现代 agent 系统，都会反复遇到几类相似问题。
比如：
- 推理到底靠模型自己，还是靠外部工作流编排
- 风险控制到底按动作做，还是按边界做
- 扩展能力到底做成一个统一接口，还是多层机制并存
- 子代理到底共享上下文，还是隔离执行
- 任务历史到底怎么留存，才能支持恢复与审计
这些问题不是 Claude Code 独有的，而是所有 agent 产品迟早都得面对的。
所以这篇文章的真正贡献可以理解为：
它试图把“agent engineering”从经验活，整理成一套可以讨论、比较、复用的设计问题集合。
这是很有价值的。
为什么要拿 OpenClaw 来对比
论文没有满足于只研究 Claude Code，而是把 OpenClaw 拉进来做镜像对照。这个设计很聪明，因为它能说明一件事：
同样的问题，在不同部署场景下，答案会完全不同。
这是理解 agent system 非常关键的一点。
Claude Code 更接近：
- 单用户或开发者主导场景
- 强调 coding workflow
- 工具链主要围绕本地项目与执行环境
- 一个中心化 agent loop 驱动任务
而 OpenClaw 更接近：
- 多渠道、多会话、多来源输入
- 带有网关和控制平面的系统
- 需要调度、后台任务、跨会话能力管理
- 更像一个长期运行的 assistant runtime
所以同一个问题，两者答案不同就很自然。
例如在安全方面：
- Claude Code 更偏向按动作做判断
- OpenClaw 更偏向先管住边界和能力入口
例如在架构方面：
- Claude Code 更像一个 CLI 驱动的 agent 回路
- OpenClaw 更像嵌入网关中的运行时
例如在扩展方面：
- Claude Code 把 MCP、插件、skills、hooks 等作为多层能力入口
- OpenClaw 更强调网关级工具、任务调度、跨通道运行
这个对比最重要的启发，不是谁更好，而是：
agent 架构并不存在放之四海皆准的最优解。架构答案总是被部署环境、产品目标和安全边界共同塑形。
这也是本文少有的成熟之处。
论文最值得重视的现实判断：不要把安全理解成“多问几次”
文中有一个很值得注意的点：作者引用了 Anthropic 的观察，用户会批准绝大多数 permission prompt。
这意味着，如果安全机制只是不断弹确认框，最终效果很可能并不好。因为人会麻木，会跳过，会默认“继续”。
因此更好的路线不是“把审批做得更多”，而是：
- 在低风险边界内自动化
- 在高风险边界外要求确认
- 用环境隔离、权限分层、可恢复机制共同降低风险
这其实也是现代 agent 产品必须接受的现实：
人类监督是必要的，但不能把全部安全责任都外包给用户临时点按钮。
这个判断，我认为是整篇文章里最贴近产品现实的一部分。
另一个重要问题：上下文管理其实比“推理技巧”更决定上限
如果你只看互联网上很多 agent 讨论，会觉得大家都在拼：
- prompt 写法
- planner 结构
- memory 设计
- tool use 策略
但这篇文章给出的一个强信号是：
上下文管理的工程质量，可能比单次推理技巧更决定 agent 的长期可用性。
原因很直接：
一个 agent 只要连续跑上十几轮，真正拖垮它的，往往不是“不会思考”，而是：
- 历史太多，重点丢失
- 工具输出太长，噪声过高
- 关键状态没有显式保留
- 旧结论没有被稳定总结
- 新任务覆盖旧任务，导致漂移
所以论文把 compaction、state、session、append history 这些内容放在中心位置，并不是偶然。
它其实在提醒一件非常现实的事：
agent 的上限不只取决于模型有多聪明，也取决于系统有没有能力把“有限上下文”用在刀刃上。
这篇文章里，我最喜欢的部分：它提出了一个不舒服但重要的问题
论文最后有个很值得记住的开放问题：
Claude Code 这种系统虽然显著放大了短期生产力，但对长期人类能力的保存和增强，支持其实很有限。
这个判断不只是“哲学担忧”，而是很现实的工程与认知问题。
因为当 agent 越来越会做事，人很可能会出现几种变化：
- 任务完成得更快，但自己理解更浅
- 能修复问题，但说不清问题为什么发生
- 能交付结果，但对代码库整体结构掌握下降
- 监督 agent 的能力，反而随着依赖提升而退化
作者把它称作一种 evaluative lens，也就是一种评估视角。它不是 Claude Code 的核心设计目标，但它应该成为我们评估 agent 系统时必须额外加上的一层镜头。
这点我非常认同。
因为短期来看，agent 当然会提高效率；但从更长时间看，一个优秀的系统不该只帮助人“做完”，还应该帮助人“更懂”。
而目前大多数 agent 产品，在这方面都还没做得很好。
这篇文章强在哪里
从“纯解读”的角度看，这篇文章有三个明显优点。
第一，它抓住了 agent 的真正工程重心
它没有把注意力只放在模型推理本身，而是放到权限、上下文、扩展、持久化、恢复这些真正决定产品体验的系统层问题上。
第二，它把零散经验整理成了一套设计空间
看完以后你会意识到，这不只是 Claude Code 的解剖报告，也是一张理解现代 agent 系统的地图。以后你看别的 agent 工具，也可以用这套框架去分析。
第三，它没有停在能力崇拜上
文章最后不仅谈 capability amplification，也谈治理、审计、长期能力退化等问题。这使它不像一篇单纯吹捧 agent 的文章，而更像一篇成熟的架构讨论。
这篇文章的局限也很明显
当然，它也不是没有问题。
1）它本质上还是“源码分析论文”
这意味着它看到的是公开实现和外部文档，而不是 Anthropic 内部真实的全部设计过程。作者总结出来的价值观和原则，很大程度上属于“从结果反推动机”。
这种方法并非无效，但要知道：
它更像高质量归纳，不等于官方架构白皮书。
2）它强在结构分析，弱在实证比较
这篇文章很擅长回答“它为什么长这样”，但不太擅长严格证明“这样做一定更优”。
比如它能很好地解释为什么需要权限系统、上下文压缩、子代理隔离，但并没有做大量对照实验去证明 Claude Code 的这些设计比其他架构更有效。
3）它有一定“事后整齐化”的倾向
当复杂系统被总结成 5 个价值、13 条原则时，阅读体验会很好，但现实中的工程决策往往没有这么整齐。很多设计是在兼顾历史包袱、上线节奏、用户反馈、安全要求之后逐步长出来的。
所以这套框架很适合作为理解工具，但不适合被当成“唯一正确模板”。
如果把这篇文章放回 2026 年的语境里看
放在今天看，这篇文章其实很有代表性。
过去大家讨论 AI coding，更多是：
- 模型代码能力行不行
- benchmark 上分数高不高
- 能不能过 LeetCode / SWE-Bench
但现在更现实的问题已经变成：
- 它能不能在真实项目里连续工作
- 它会不会因为上下文过载而失控
- 它如何接入工具和外部系统
- 它能不能安全地获得执行权限
- 它是否支持团队级、长期级协作
从这个角度看，这篇论文其实是在替整个行业补一门课：
agent 不只是模型问题，更是系统设计问题。
而且随着 agent 从“会建议”走向“会执行”，这门课只会越来越重要。
我的最终看法
如果把这篇文章理解成一篇“纯解读对象”，那我给它的定位是：
它不是一篇告诉你怎么把 prompt 写得更强的文章，而是一篇帮助你理解“现代 agent 产品为什么会长成这样”的文章。
Claude Code 在这里更像一个切片样本。真正的主角不是 Claude Code 本身，而是：
- 现代 agent 的系统边界
- 设计权衡如何展开
- 不同部署环境如何塑造不同架构答案
- 短期能力放大与长期人类能力之间的张力
如果你关心的是“agent 为什么越来越像一个操作系统层产品，而不只是聊天模型加几个工具”，这篇文章是值得认真读的。
如果再进一步压缩成一句判断，那就是：
这篇文章最重要的贡献，不是赞美 Claude Code，而是把 AI Agent System 的设计空间描述得足够清楚，让后续讨论终于有了比较像样的坐标系。
参考信息
- 论文标题：Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems
- arXiv：https://arxiv.org/abs/2604.14228
- GitHub：https://github.com/VILA-Lab/Dive-into-Claude-Code