夜雨聆风51 万行源码拆开之后，Claude Code 现了原形
2026 年 4 月，一篇 arXiv 论文把 Claude Code 的 TypeScript 源码啃了一遍
没看 Anthropic 的文档，没翻官方博客直接读源码，51.2 万行，1,884 个文件，一行一行拆
论文来自 VILA Lab（MBZUAI），标题 Dive into Claude Code它干了一件只有学术界才会干的事：把 Anthropic 这个最主流的 AI 编程工具拆成零件状态，然后告诉你每一块为什么长这样5 大人类价值，13 条设计原则，7 组件高层结构，5 层子系统分解，外加跟开源系统 OpenClaw 的横向对比GitHub 仓库已经 1,500+ star
但读完全文，真正让我停下来想了好几次的，是几个反直觉的判断
1.6%
Claude Code 的源码里，只有 1.6% 是「决策逻辑」剩下 98.4%，是权限引擎、沙箱、会话持久化、上下文压缩流水线、子代理管理、hook 拦截、MCP 集成
这些东西跟 AI 没关系它们是老派的软件工程
论文用了一句话概括这个设计哲学：Minimal scaffolding, maximal operational harness别给模型搭复杂的 planner 和 state graph，把力气花在执行环境上，让它足够厚、足够可靠然后模型在里面自由推理就行了
这跟 LangGraph 走的是两条路LangGraph 显式建图、显式管状态，赌的是模型还不够可靠，需要框架来约束Claude Code 赌的是模型会越来越强，你只需要给它一个够好的环境，它会自己找到路
两边没有绝对对错但 1.6% 这个数字很诚实Anthropic 把宝全押在了 harness 上
上下文是真正的瓶颈
Claude Code 的整个架构被一个东西捆住了：上下文窗口
算力？不是Working memory？不是是 context window
所以才有 5 层渐进压缩 pipeline最便宜的 budget reduction 只管单次工具结果的大小，一路升级到 auto-compact，让模型自己写总结，属于最后的不得已手段前三层对用户完全透明，后两层也是能拖就拖，尽量不碰原始历史
所以子代理才有独立上下文窗口，而且只给父代理返回浓缩后的文本论文管这叫 context bottleneck 原则每个子代理写独立的 sidechain transcript，但父代理永远不会看到完整版
所以 CLAUDE.md 才分了 4 级（Managed → User → Project → Local），而且是反向加载的越靠近具体项目的指令越后加载，优先级越高。CLAUDE.md 也是以 user message 的形式注入的，不走 system prompt。论文咬住这点不放：这意味着 CLAUDE.md 里的指令对模型来说是概率性遵守，真要确定性执行，只能靠 permission rules。
这些设计拆开看都很合理，连起来看，是一套围绕同一个稀缺资源的生存策略。
93% 的批准率，才是最危险的东西
论文里有一个数字我看了好久：用户 approve rate，93%
第一反应当然是好事工具好用，不需要老盯着但反过来想：你一天点几百次 approve，对那剩下 7% 的操作，还剩多少判断力？
所以 Claude Code 的安全假设从一开始就定了调：人类会走神。
7 层独立安全，每层都能单独拦截。组装工具池的时候就已经把 blanket-denied 的工具踢出去了，根本不给模型看到。Deny-first 规则引擎：拒绝永远优先于允许，哪怕你的 allow 规则写得更具体。Auto-mode ML classifier 分两阶段跑，fast-filter 过一道再加 CoT。Shell sandboxing 独立于 permission 体系，文件系统和网络隔离额外再拦一层。
最狠的一条：resume 和 fork 会话的时候，session-scoped permissions 不恢复。信任是 per-session 建立的，换个会话就重新来。
这背后的判断很冷：人类 vigilance 靠不住，跟人本身没关系。一天几百次 approve，谁都做不到保持判断力。
四种扩展，一张账本
Claude Code 的扩展体系不是乱堆的按上下文成本梯度排得很清楚：
Hooks：零成本只管生命周期拦截，block、rewrite、annotate，不占任何 tokenSkills：低成本只有 frontmatter 描述进上下文，领域指令按需才加载Plugins：中成本打包分发，最多带 10 种组件类型MCP servers：高成本tool schemas 全量进入上下文
这是一套 token 经济学便宜的你随便用，贵的只留给真正需要新工具表面的场景单一机制覆盖不了全谱，该分级就分级
同一道题，两个答案
论文第 10 章把 Claude Code 和 OpenClaw 放进同一个分析框架里比，这是全文最有启发的一章
问同样的问题，答案完全不同：
「推理放在哪？」Claude Code 放模型里，harness 只管执行OpenClaw 放 gateway RPC dispatch 里，agent 嵌在里面跑「信任模型怎么建？」Claude Code 说 per-action deny-first 加渐进自主OpenClaw 说 perimeter-level identity 加 DM pairing 加 allowlists「记忆怎么管？」Claude Code 说 CLAUDE.md 四级加 5 层压缩OpenClaw 说多 bootstrap 文件加独立 memory 系统加 hybrid search，甚至有个叫 dreaming 的机制
每个维度的答案都不一样不是因为谁聪明谁蠢Claude Code 是 ephemeral CLI harness，会话结束就散了OpenClaw 是 persistent gateway daemon，7x24 在跑部署场景不同，架构自然不同
而且 OpenClaw 可以通过 ACP 把 Claude Code 当 external coding harness 托管两者能组合，不互斥
这一章值得单独写一篇展开它提供的东西比任何单系统分析都值钱：一个通用的设计空间，让你能看懂任何一个 agent 系统在做什么取舍
你变强了，还是变废了
论文在 2.4 节提了一个 evaluative lens：长期人类能力保存
然后后续分析基本都在说同一件事：当前架构在这一点上，做得不够
短期放大能力很强Anthropic 内部调研，27% 的任务「没有工具根本不会去尝试」这当然厉害
但反过来想：这 27% 是你不想做的无聊活，还是你需要练才能保持住的能力？
论文的实证预测很直白：bounded context 加 subagent isolation，很可能导致代码复杂度上升、重复实现、技术债务积累已经有 Cursor 和 AI commit 审计的研究在支持这个方向
你让 Claude Code 写了一个 feature写得不错但你真的看懂了那段代码没有？下次要改的时候，是打开编辑器自己看，还是继续让 AI 上？如果继续让 AI 上，它会不会因为 context 不够又造一遍轮子？代码库的连贯性，到底归谁管？
这些跟 Claude Code 好不好用没关系。它很好用。问题是你用了一年以后，你的技能曲线是往上走的还是往下滑的。
论文把这件事列成了开放设计方向之一，而且很老实地说：目前这只是一个评价镜头，不是一个有机制支撑的设计目标。
还有五个问题没人能答
沉默错误模型做错了，但没人知道它做错了这是当前最主要的失败模式靠更好的模型解决不了，需要 generator-evaluator separation、sprint contracts 这类 scaffolding
跨会话记忆CLAUDE.md 是静态指令，transcripts 是单次会话中间缺了一层会累积的东西你需要一个「同事关系」，而不是每次打开都像刚认识
治理EU AI Act、GPAI Code of Practice 都在逼近Harness 现在几乎什么都没暴露
从单 session 扩展到 weeks-scale 的科学项目时，当前的 context pipeline 加 summary return 还撑不撑得住
每个问题都很大论文给了方向，没给答案
最后说一句
这篇论文最值钱的不是拆了多少技术细节是把一个你每天都在用的东西，放进了一个更大的框架里看
它让一件事变得很具体：你用的 AI 程序员，只有 1.6% 的代码在做决策剩下全是地面上的基建，是软件工程做了几十年的老本行
它也戳到了一个尴尬的事实：整个品类都在拼命放大你的短期能力几乎没有人在设计「让你长期变得更好」这件事
论文：github.com/VILA-Lab/Dive-into-Claude-Code
