夜雨聆风
深度拆解Claude Code泄漏源码:顶级AI Agent的架构秘密,全在这里
Claude Code 这次最值得行业研究的，不是“泄了多少行代码”，而是它把一个事实提前摊开在了所有人面前：
顶级 AI Coding Agent 的竞争，已经不只是模型能力的竞争，而是系统工程能力的竞争。
很多人以为，做一个 AI 编程产品，无非是接一个强模型、配几个工具、写一套提示词、再包一层界面。
但真正把 Claude Code 的整体结构梳理完之后，会发现它根本不是这么回事。
它更像一套完整的Agent 运行时系统：
-
有多入口的平台化设计 -
有长任务驱动的主循环 -
有可治理的工具系统 -
有角色分工明确的多 Agent 协作 -
有彼此制衡的安全层 -
有让模型真正“感知能力”的扩展生态
还有一整套围绕上下文成本、后台任务、状态恢复和遥测构建起来的产品化基础设施
Claude Code 最值得借鉴的地方，不是某个功能，而是它已经把“AI 工程师”做成了一套可运行、可扩展、可治理、可长期工作的系统。
一、第一层值得借鉴的设计：系统化、平台化设计
很多 AI 产品最开始的思路都是：
-
先做一个 CLI，能跑起来再说； -
先做一个插件，功能够用再补； -
先有一个对话框，后面慢慢加能力。
Claude Code 不是。
它从架构层面就表现出很强的平台化意识：同一套运行时，同时服务终端、协议接入、SDK 调用、IDE 集成，甚至后台常驻和远程控制。
更关键的是，它没有把所有调用路径都粗暴塞进一个完整启动流程，而是针对不同场景做了明显的“快速路径”分流，
不需要完整运行时的命令，不走完整初始化；
需要后台会话管理的，走独立路径；需要远程控制的，也不走普通交互链路。
如果一开始只是当成一个单点工具来做，后面就一定会被性能、耦合和扩展性反噬。
Claude Code 最聪明的地方，就是它在一开始就默认：这不是一个功能产品，而是一个运行时平台。
二、第二层值得借鉴的设计：它的核心不是“回答”，而是“持续执行”
Claude Code 的整个运行方式，有一个非常重要的特点：它不是“一问一答”式工作的，而是靠一个持续运转的主循环，把任务不断推进下去。
每一次迭代都不是简单回复文本，而是按固定顺序处理上下文、拼装规则、调用模型、执行工具、处理异常，再决定要不要继续下一轮。
这个设计特别关键，因为它代表了一种根本性的抽象变化：
传统聊天产品的基本单位是“消息”，而 Claude Code 的基本单位是“任务回路”。
这带来什么好处？
第一，它天然更适合长任务。
系统不会把一次复杂工作拆成很多彼此割裂的对话回合，而是始终把它看成同一个持续推进中的任务。
第二，它天然更适合工具调用。
工具执行完，不是结束，而是把结果重新喂回系统，进入下一轮判断和执行。
第三，它天然更适合异常恢复。
上下文过长、输出超限、模型中断、需要继续执行，这些都不是“意外”，而是状态流转的一部分。
这一层最值得借鉴的经验是：
想做真正能干活的 Agent，就不要把系统设计成“会聊天的工具”，而要把它设计成“会持续推进任务的执行器”。
这是 Claude Code 和很多“聪明但不耐用”的产品之间最大的差别之一。
三、第三层值得借鉴的设计：它没有迷信 Prompt，而是把 Prompt 做成基础设施
很多人对 Prompt 的理解还停留在“写一段提示词”。
Claude Code 更进一步。
它不是写一个超长提示词，而是把系统规则拆成了静态部分和动态部分：稳定不变的内容尽量固定下来，按会话变化的内容再动态注入；静态部分尽量保持一致，以提高缓存命中率；动态部分则按实际状态决定是否加入。
这个设计为什么厉害？
因为它解决了两个经常被忽略的问题。
一个是成本问题。
系统提示越长、变化越频繁，缓存效率越差，调用成本越高。Claude Code 明显不是“能跑就行”，而是在系统层面认真优化前缀缓存。
另一个是组织问题。
当一个 Agent 系统越来越复杂时，提示词就不再只是“写给模型看的自然语言”，而是一种运行时资源。它需要分层、复用、缓存、按状态拼装，而不是一次性硬塞。
这背后最值得借鉴的，不是某段提示词写得多漂亮，而是这个认知：
Prompt 不该只是文本，而应该是系统配置的一部分。
真正成熟的 Agent 系统，拼的是 prompt infrastructure，不是单次 prompt 灵感。
四、第四层值得借鉴的设计：它不相信模型会“自觉守规矩”
Claude Code 的一个非常成熟的地方，是它并不假设模型天然会克制、会诚实、会遵守工程纪律，它明确把很多“好习惯”写成制度：
-
先读代码再改代码 -
不要擅自增加用户没要求的功能 -
不要过度抽象 -
不要乱加注释和文档 -
不要盲目重试 -
没验证过的结果不要说成已经验证过
这个思路特别值得借鉴。
因为很多人做 Agent 时，默认假设模型足够强之后，这些行为问题会自然改善。
但现实刚好相反：能力越强，越容易“多做”、“乱做”、“自作主张”。
Claude Code 给出的答案非常朴素：
不要赌模型会临场发挥出正确工程习惯，而要把工程习惯写进系统。
这件事听起来简单，但其实非常重要。
因为 AI 系统真正难落地的地方，往往不是“不会做”，而是“做得太多”“做偏了”“做得不受控”。
所以，Claude Code 第一条最值得借鉴的设计原则，其实不是技术，而是工程哲学：
好行为不能靠模型悟出来，只能靠制度约束出来。
五、第五层得借鉴的设计：工具不是外挂，而是必须被治理的执行接口
Claude Code 当然有很多工具能力，但真正厉害的不是工具多，而是工具怎么被系统接纳和管理。
它不是模型一说“我要调用工具”，工具就直接执行。
相反，每一次工具调用都要经过一整套治理流程：先做输入校验，再做更细粒度检查，再做风险预判，再执行前置策略，再做权限决策，再执行，再做成功或失败后的收尾处理。
甚至对于高风险操作，系统还会提前启动风险分类，在权限决策前就开始分析，尽量减少等待时间。
这一层特别值得所有做 Agent 的团队借鉴。
因为工具真正难的，从来不是“能不能接进去”，而是：
-
参数能不能乱传 -
风险能不能提前识别 -
高危操作会不会绕过审批 -
失败后系统怎么恢复 -
大量工具同时调用时，系统会不会失控
Claude Code 的答案非常明确：
工具不是“能力清单”，而是“必须纳入治理体系的执行接口”。
如果没有这层治理，模型越强，风险越大。
因为模型会越来越主动地调用工具，而不是越来越克制。
这也是为什么 Claude Code 的工具系统看起来更像一条“治理流水线”，而不是简单的“工具箱”。
六、第六层值得借鉴的设计：多 Agent 的关键不是多，而是分工和隔离
Claude Code 的多 Agent 设计，最有价值的地方不在于“有好几个 Agent”，而在于它明确做了角色拆分。
它不是把探索、规划、实现、验证都塞给同一个智能体，而是把这些职责拆开，让不同角色承担不同任务。
尤其重要的是，它不是只在提示词里说“你现在扮演验证者”，而是在工具权限、行为边界和任务目标上都做了明确限制。
这件事为什么这么重要？
因为如果一个 Agent 既负责写，又负责验，它天然会高估自己的成果。
而 Claude Code 通过角色分离，解决了这个问题：
-
探索角色只负责看，不负责改 -
规划角色只负责想，不负责执行 -
实现角色负责交付 -
验证角色的唯一目标是找问题，而不是替实现者证明正确
尤其是验证这件事，Claude Code 的设计非常值得借鉴。
它不是让验证者“看看像不像对”，而是强迫验证者去主动找失败点、跑真实检查、给出实际结果，而不是凭感觉判断。
这背后最值得借鉴的原则非常简单：
多 Agent 的价值，不是把一个模型复制几份，而是把职责拆开，把偏见拆开，把权限拆开。
如果没有这三层拆分，多 Agent 大概率只是多开几个窗口。
而 Claude Code 显然不是这么做的。
七、第七层值得借鉴的设计：它把“子任务”做成了有成本意识的调度系统
Claude Code 在子任务调度上有一个很值得学习的细节：它不仅考虑“子任务能不能独立运行”，还考虑“子任务如何尽可能复用已有上下文和缓存”。
这说明它的调度思路不是“开个分支让它去跑”，而是：
-
能继承的状态尽量继承 -
能复用的上下文尽量复用 -
能共享的缓存尽量共享 -
不为了形式上的独立而牺牲系统效率
这个设计非常成熟。
很多系统一做多 Agent，就会迅速出现一个问题：
每个子任务都像重启了一次世界，重复加载、重复拼装、重复消耗 token。
Claude Code 的做法明显更工程化，它在调度层就开始思考成本，而不是等成本炸了再补救。
这一点的启发很大：
真正好的多 Agent 系统，不只是会分工，还要会节流。
子任务调度不是单纯的并发问题，而是上下文复用、缓存复用和执行成本问题。
八、第八层值得借鉴的设计：安全层不是“一个开关”，而是互不绕过的三层防护
Claude Code 在安全上的成熟度，非常值得行业重视。
它不是只有一个权限系统，也不是只有一个 hook 机制，而是把风险预判、运行时策略和最终权限决策拆成三层，而且这三层彼此配合，但互不绕过。
这背后最有价值的点在于：
-
预判层负责尽早判断风险 -
策略层负责动态调整和阻断 -
最终权限层负责拍板
更重要的是，即便中间某一层说“可以”，也不代表它能跳过核心安全规则。
这意味着即使某个扩展机制出了问题，或者某个策略组件被误用，整个系统也不会因为单点失效而直接失控。
这个思路特别值得借鉴。
很多产品也会说自己有“安全设计”，但真正的难点从来不是“有没有安全层”，而是：
安全层之间会不会互相穿透。
Claude Code 给出的答案是：
-
可以分层，但不能串权； -
可以协同，但不能越级； -
可以动态调整，但不能把底线让出去。
这就是成熟系统和实验性系统之间的差别。
九、第九层值得借鉴的设计：扩展体系最关键的，不是插件多，而是模型自己知道能做什么
Claude Code 有技能、有插件、有协议扩展，但它最关键的一步不是“接入能力”，而是让模型感知能力。
这听起来像一句废话，但实际上很多产品恰恰卡死在这里。
很多平台当然也能接十个插件、几十个工具，但问题是模型根本不知道当前有哪些能力可用，也不知道什么场景该调用哪个。那这些扩展对模型来说就像不存在。
Claude Code 做得更进一步：
扩展能力不是藏在系统后台，而是通过能力清单、会话指引、动态说明和按需注入机制，明确让模型“知道自己现在能做什么”。而且扩展能力不只是提供新工具，还能附带使用说明，让模型不仅知道“有”，还知道“怎么用、何时用”。
这一点特别值得借鉴。
因为 Agent 生态真正难的，从来不是技术接入，而是认知接入。
系统接进去了，不代表模型会用。
模型会用，生态才真正活起来。
所以，Claude Code 在扩展体系上最值得学习的一条原则是：
扩展的终点，不是注册成功，而是被模型真正感知和调用。
十、第十层值得借鉴的设计：它非常清楚“上下文就是预算”
Claude Code 对上下文的态度，非常像成熟操作系统对内存的态度。
它不是等上下文爆了再救火，而是一开始就按预算来管理：
历史消息太长先轻量裁剪，再做细粒度压缩，再对不活跃内容做折叠，必要时再触发更重的压缩，如果还不够，再做应急压缩。
对于大结果，不直接塞回上下文，而是落盘后只保留摘要。
技能和外部说明也都按需注入，不做一股脑预装。
这件事特别重要，因为它揭示了一个现实：
在 Agent 系统里，token 从来不是“附属消耗”，而是第一性约束。
谁对上下文没有预算意识，谁就不可能把 Agent 真正做大。
因为一旦任务变长、工具变多、角色变多、扩展变多，如果没有上下文经济学，系统迟早会失控。
Claude Code 这一层最值得借鉴的，不是具体压缩策略，而是这个认知：
上下文不是无限资源，必须像预算一样精打细算。
十一、第十一层值得借鉴的设计：它从一开始就在解决“系统如何长期稳定运行”
十二、Claude Code 最值得借鉴的是一整套系统方法
如果一定要把 Claude Code 这套架构设计压缩成 10 条最值得借鉴的原则，我会总结成下面这些。它们不是零散技巧，而是一整套把 AI Agent 做成真正可用系统的方法。