最近，Claude Code 因为 npm 包里的 map 文件泄露，暴露出了大量源码文件。
很多人第一反应是去扒它的 system prompt、工具列表、Agent 提示词。
但真正把源码一路拆下去之后，你会发现，Prompt 根本不是最重要的部分。
Claude Code 真正厉害的地方，不是它写了什么提示词，而是它围绕提示词，搭出了一整套工程系统。
这套系统，把行为规范、工具治理、Agent 分工、上下文管理、生命周期管理全部串成了一个闭环。
换句话说，它不是一个“把大模型接到终端里”的工具，而是一套成熟的 Agent Runtime。
如果你在做 AI Agent、Coding Agent，甚至只是想做一个稍微复杂一点的 AI 产品，Claude Code 里面有很多值得抄的地方。
大多数人对 Claude Code 的理解，只停留在 Prompt 和 Tool
现在网上大部分关于 Claude Code 的分析，主要集中在两个点：
第一，Claude 的 system prompt 到底写了什么。
第二，它到底能调哪些工具。
这些东西当然重要。
但如果你真的照着它的 prompt 抄一遍，再把工具也都接上，你会发现，你做出来的东西和 Claude Code 的体验还是差得很远。
为什么？
因为 Prompt 和 Tool 只是表层。
真正决定体验的，是 Prompt 背后的编排机制、Tool 背后的治理链路、Agent 之间的协作关系，以及系统对上下文和状态的管理能力。
Claude Code 的“稳”，不是因为它有一句神奇 Prompt，而是因为它把“模型容易犯错的地方”几乎都提前设计好了。
Claude Code 不是 CLI，而是一个运行平台
很多开源 Coding Agent 的目录结构都差不多：
- main.ts
- prompt.ts
- tools.ts
- utils.ts
然后再加几个简单命令，就可以跑起来了。
Claude Code 完全不是这个思路。
从源码结构来看，它至少拆成了这些模块：
- EntryPoints
- Tools
- Services
- Commands
- Components
- Coordinator
- Memory
- Plugins
- Hooks
- Bootstrap
- Tasks
这意味着，它不是一个“功能集合”，而是一个完整的运行平台。
它甚至有四个不同入口：
- CLI
- 初始化流程
- MCP 模式
- SDK
也就是说，同一套 Agent Runtime，可以同时服务终端、外部集成、插件生态、SDK 接入。
很多人做 Agent，目标是“能跑”。
Claude Code 的目标，是“能扩展、能治理、能长期运行”。
这就是平台和工具之间的差别。
Prompt 不是一段话，而是一台动态组装机器
Claude Code 最反直觉的一个设计，是它的 system prompt 不是固定文本。
它是动态拼出来的。
整个 prompt 会被拆成两部分：
第一部分是静态内容。
包括：
- 身份定位
- 系统规范
- 做任务的原则
- 风险动作规范
- 工具使用规范
- 语气风格
- 输出效率要求
这一部分像宪法，所有会话都一致。
第二部分是动态内容。
包括：
- 当前 Session Guidance
- Memory
- 环境信息
- 语言偏好
- MCP 指令
- Scratchpad
- Token Budget
- Brief Mode
这一部分像当期政策，会根据当前任务实时变化。
这里最有意思的是，它专门做了一个静态 / 动态边界。
边界之前的 Prompt 尽量保持不变，这样就能让 API 缓存命中。
边界之后才放会变化的内容。
这意味着，Claude Code 在设计 Prompt 时，已经不是在想“怎么写得更聪明”，而是在想“怎么写得更便宜”。
很多人做 Prompt，只关注效果。
真正做产品的人，已经开始关心缓存命中率、上下文复用率、每次请求到底多花了多少 Token。
Claude Code 最厉害的地方，不是聪明，而是克制
你用过很多 Coding Agent 后会发现，它们经常有几个毛病：
你让它改一个 Bug，它顺手帮你重构半个项目。
你让它加一个功能，它给你设计三层抽象。
你让它测试，它说“测试通过了”，但其实根本没跑。
Claude Code 在 Prompt 里，专门把这些行为全部禁止掉。
它会明确告诉模型：
- 不要乱加功能
- 不要过度抽象
- 不要瞎重构
- 不要乱加注释
- 不要搞“未来可能用到”的设计
- 先读代码，再改代码
- 不要轻易创建新文件
- 失败先诊断，再换策略
这其实是在做一件非常重要的事：
把“好行为”写成制度。
不要相信模型会自觉。
如果你希望它先读代码再修改，那你就明确写进去。
如果你不希望它随便加功能，那你也明确写进去。
很多 Agent 的不稳定，不是模型不够强，而是系统没有给它足够的约束。
工具不是接上就行，而是要有治理
Claude Code 对工具的态度也很有意思。
它不是简单告诉模型“你有这些工具可以用”。
它会进一步告诉模型：
- 读文件要用 FileRead
- 改文件要用 FileEdit
- 新建文件要用 FileWrite
- 搜文件要用 Glob
- 搜内容要用 Grep
- Bash 只留给真正需要 Shell 的场景
为什么？
因为很多问题不是模型不会做，而是它会用错工具。
比如，本来应该用结构化编辑工具改代码，它却用 sed 去替换文本。
一个正则写错，整个文件就坏了。
Claude Code 的工具调用并不是“模型说调就调”。
它中间还有一整条治理链：
- 输入校验
- 权限检查
- 风险预判
- Hook 拦截
- Post Hook 处理
- 失败恢复
这种设计背后的逻辑很简单：
默认假设事情会出问题。
只要你把每个容易出问题的环节都提前堵上，系统自然会更稳。
多 Agent 分工，是 Claude Code 体验好的关键
Claude Code 内部至少有六类 Agent：
- General Agent
- Explore Agent
- Plan Agent
- Verification Agent
- Guide Agent
- Setup Agent
最值得学的是 Explore Agent 和 Verification Agent。
Explore Agent 是完全只读的。
它不能改文件，不能创建文件，不能删文件，只能看。
这样做的好处很明显。
探索阶段不会误伤代码。
而 Plan Agent 负责做规划，不负责执行。
它的工作是把需求拆清楚、把实现路径想清楚。
这样，真正写代码的时候，就不会因为边想边写而导致逻辑混乱。
很多人做 Agent，总想让一个模型包打天下。
研究、规划、执行、验证全都让一个 Agent 做。
结果就是每件事都做不好。
Claude Code 的思路是：
把角色拆开。
谁负责看，谁负责想，谁负责做，谁负责验收，全部分清楚。
Verification Agent，可能是整个系统里最值钱的设计
Claude Code 的 Verification Agent 有一个很狠的原则：
不要试图证明它没问题。
要试图证明它有问题。
它会强制要求：
- 跑 Build
- 跑 Test
- 跑 Lint
- 跑 Type Check
- 验证 CLI 输出
- 验证接口响应
- 验证数据库迁移
- 验证 Public API
更重要的是，它要求 Agent 主动去做边界测试。
它不是“看起来没问题就算通过”。
它是“试试看能不能把它搞坏”。
这一点非常重要。
因为很多 Agent 最大的问题，就是太容易“差不多就行”。
写代码的 Agent 往往会天然认为自己写得没问题。
但 Verification Agent 不需要对结果负责，它只需要负责找问题。
实现者和验证者分离，是传统软件工程里非常成熟的经验。
放到 AI Agent 里，同样成立。
Claude Code 最终拼出来的，其实是一套工程闭环
你把 Claude Code 的源码一路拆下来，会发现它并不是靠某一个点特别强。
不是 Prompt 特别强。
不是 Tool 特别多。
也不是模型特别聪明。
它真正厉害的地方，是它把这些东西全部串起来了。
它知道：
- 模型会乱来，所以需要行为规范
- 工具会出问题，所以需要治理链路
- 一个 Agent 做不好所有事，所以需要角色拆分
- 上下文很贵，所以需要缓存和压缩
- 任务会中断，所以需要生命周期管理
- 插件接进来没意义，模型得知道它们存在
这些东西单独看都不惊艳。
但全部加在一起，就会形成一种非常强的“产品感”。
这也是为什么很多开源 Agent Demo 看起来很聪明，但一到复杂场景就崩。
因为它们有 Prompt、有 Tool、有模型，但没有工程闭环。
最后
拆完 Claude Code 后，我最大的感受是：
真正优秀的 Agent 产品，不是靠“更聪明的模型”赢的。
而是靠“更成熟的工程系统”赢的。
Prompt 只是冰山露出水面的一角。
真正决定体验的，是冰山下面那一整套看不见的东西。
一句话总结：
Claude Code 的秘密，不在 Prompt 里，而在它把行为制度、工具治理、Agent 分工、上下文经济学和生命周期管理，做成了一套完整闭环。
