这篇 arXiv 的《Dive into Claude Code》，感觉最有用的地方是讲清楚了，其实Claude Code这种系统一旦进入真实环境，工程重点立刻就变的很现实。
Claude Code当然是个 coding agent，会跑 shell、会改文件、会调外部服务。 模型循环本身并不复杂。
文中直接写了Claude Code的核心就是反复调用模型、执行工具、再根据结果继续往下走。
论文里整理得出，真正占分量的是围在外面的那一圈系统设计:
权限控制、审批模式、上下文压缩、插件和 skill 的扩展面、subagent 的委派、会话持久化。
分析结论：
今天决定agent 产品成败的，是“怎么在真实世界里动手”，而非“会不会想”，
很多人谈 agent，还停留在 prompt、loop、planning 这些表层词汇。
Claude Code 这类产品越来越在意的一点却是一旦真的要进项目、进终端、进文件系统，马上就碰到很现实的问题。
文件能不能碰。
命令能不能跑。
风险怎么分级。
用户什么时候该介入。
上下文太长了怎么办。
会话断了怎么接回去。
这些问题不花哨，但恰恰这些才是生产系统的骨架。
文章给 Claude Code 提炼了五个出发点，
-人始终保留决策权，
-系统要守住安全和隐私，
-执行要稳定，
-人的能力得要真的放大，
-还得慢慢适应不同用户的项目环境和信任关系。
Claude Code 的设计品味清楚得很。就是没有把大量精力放在“用显式状态机把模型一步步管死”这种方向上。
更像是在给一个越来越强的模型准备工作现场，让它有护栏，有工具，有恢复机制也有边界。
还有就是把 context 当成主约束来看。
很多人总觉得上下文管理只是优化项，模型更大一点就好了。
但这篇分析的判断却是：context 根本就是成本、稳定性和任务质量的交叉点。如果带着错的上下文开工，后面会越跑越偏。
所以压缩、筛选、延迟加载也是主工程，不是边角料。
跟OpenClaw对比这一段也挺有意思。
同样一组问题，放在不同产品形态里，答案会完全不同。没有什么谁比谁更先进，
CLI 里的 coding agent和一个多通道的 assistant gateway，天然就不会长成一样。
权限边界不同，扩展方式不同，运行时位置不同，整套架构的重心也会变。
所以这篇文章帮助你更确定了一件事，那就是agent architecture 说到底是在设计一套运行秩序。
模型就像发动机。能不能上路，靠的是刹车、方向盘、仪表盘和路权规则。
虽然基于公开源码和公开资料，这篇第三方分析终归不是 Anthropic 自己写的官方架构说明。
拿来理解设计思路，很有价值。
但不能拿来把所有细节都当定论。
Claude Code 这种系统，已经很会替人把事情往前推了。 短期能力放大，这点没什么好怀疑的。
最后留下的问题在于，系统做得越多，人有没有因此理解得更深，沉淀出一些经验，代码库有没有变得更清楚，
随着工具在变强，人是不是也在一起变强，
这些现在离被彻底解决还尚早。