拆开 Claude Code 的源码我们发现了一个 Agent 操作系统

你以为 Claude Code 只是一个”能帮你写代码的 AI 终端”？

当你真正把它的源码拆开看——所有的 prompt 文件、工具链、Agent 调度逻辑、权限系统、插件生态——你会发现一个令人震撼的事实：

这篇文章基于 Xiao Tan 发布的 26 页源码深度研究报告，我们把其中最核心的发现提炼出来，给你看看 Anthropic 到底是怎么把一个 coding agent 做到”工业级”的。

一、它不是 CLI 包装器，是一个平台

很多人对 Claude Code 的印象停留在”一个 CLI 工具”。但从源码结构看，它的复杂度远超一个命令行程序。

它的入口层就暴露了平台化设计思维——同一个 Agent Runtime 可以服务于本地 CLI、初始化流程、MCP 模式和 SDK 消费者。命令系统更是暴露出 /mcp、/memory、/permissions、/hooks、/skills、/agents 等大量系统级命令，这不是锦上添花，而是用户与运行时交互的重要控制面。

二、System Prompt 不是一段文本，是一个编排架构

如果你以为 Claude Code 的秘密就是那段 system prompt，那你可能只看到了冰山一角。

源码中最关键的文件 prompts.ts 暴露了一个惊人的设计：system prompt 是被”组装”出来的，不是被”写”出来的。

关键点在于那条 cache boundary。源码中明确定义了 SYSTEM_PROMPT_DYNAMIC_BOUNDARY——边界之上是可缓存的静态段，边界之下是每次会话特有的动态段。这说明 Anthropic 不只是在写 prompt，而是在做 prompt assembly with cache economics。

换句话说，连 system prompt 的 token 成本和缓存命中率，他们都做了工程化优化。

三、九大 Prompt 模块：AI 工程师的行为宪法

拆开 getSystemPrompt()，里面至少有九个关键 section，每个都在解决一个具体问题：

其中任务哲学这一节堪称精华。它把很多 coding agent “行为发散”的问题直接用制度解决了：

很多 agent 不稳定，不是不会写代码，而是行为发散。这一段就是为了从制度层面解决行为漂移。

四、Agent 分工：不是全能选手，而是专业团队

从源码中可以确认至少有 6 个内建 Agent，而且每个都有严格的职责边界：

VerificationAgent：最值钱的设计

在所有内建 Agent 里，VerificationAgent 是最让人拍案叫绝的。它的 prompt 开头就直接点出两类失败模式：

1Verification avoidance：只看代码、不跑检查、写 PASS 就走

2被前 80% 迷惑：UI 看起来还行、测试也过了，就忽略最后 20% 的问题

然后强制要求：必须 build，必须跑测试，必须 linter/type-check，frontend 要跑浏览器自动化，backend 要 curl 实测响应，CLI 要看 stdout/stderr/exit code，必须做 adversarial probes，每个 check 必须带 command 和 output observed，最后输出 VERDICT: PASS / FAIL / PARTIAL。

这不是”再跑一次测试”，而是一个 adversarial validator。它把 LLM 常见的”差不多就算了”直接用 prompt 反制掉了。

五、Fork 机制：复杂子任务的优雅解法

多 Agent 系统里有一个核心难题：怎么让复杂子任务并行运行，但不污染主上下文？Claude Code 的答案是 fork 语义。当 fork 开启时：

fork path 会尽量继承父线程的 system prompt 和 tool definitions，以保持 API request prefix byte-identical，从而提高 prompt cache 命中。普通人只想”子任务能跑”，Claude Code 想的是”子任务能跑，而且尽量复用主线程 cache，不白烧 token”。

六、工具执行不是直连，是一条 14 步 Pipeline

Claude Code 的工具执行远不是”模型决定 → 直接跑函数”这么简单。实际链路是：

注意第 6 步的 PreToolUse hooks。Hook 不仅仅能”记日志”，它还能返回 message、blocking error、updated input、permission behavior、prevent continuation……这意味着 Hook 是一个 runtime policy layer，真正参与控制流。

而且，Hook 的权限语义是被严格嵌进总权限模型里的——hook allow 不一定绕过 settings 的 deny 规则。Hook 强，但没有绕开核心安全模型。

七、生态层：Skill、Plugin、Hook、MCP 四重奏

Claude Code 的扩展能力不是”装个插件就完事”，而是四层机制协同工作：

最妙的是，这些扩展不是暗箱操作——它们通过 skills 列表、agent 列表、MCP instructions、session-specific guidance 等方式，让模型”知道自己的扩展能力是什么”。

很多系统也有插件也有工具，但模型本身不知道有哪些扩展、什么时候该用、怎么用。Claude Code 让生态对模型可感知，这才是生态真正能发挥作用的关键。

八、Claude Code 的真正护城河

很多人复刻 coding agent 时只拿走：一段 system prompt、一个文件编辑工具、一个 bash 工具、一个 CLI 壳。

但 Claude Code 真实的护城河是这些能力的系统性叠加：

少哪一个都行，但会显著掉”手感”。

它把”好行为”制度化了

Claude Code 最大的优势之一，不是模型更聪明，而是——它不把”好习惯”交给模型即兴发挥，而是写进 prompt 和 runtime 规则里。

不乱加功能、不过度抽象、不瞎重试被拒绝的工具、不未验证就说成功、不让 fork 输出污染主上下文、匹配 skill 时必须执行 skill、verification 不能只看代码必须跑命令……

这种制度化，会极大提高系统一致性。

它特别懂”上下文是稀缺资源”

源码中大量设计都在围绕上下文做优化：system prompt 动静边界、prompt cache boundary、fork path 共享 cache、skill 按需注入、MCP instructions 按连接状态注入、function result clearing、summarize tool results、compact / transcript / resume……

他们不是把 token 当免费空气，而是当 runtime 预算来管理。

九、写在最后

这份研究报告让我们看到了一个事实：当下最强的 coding agent 之间的差距，已经不在”模型能力”这一层了。

差距在于工程。

谁能把 prompt 当架构来设计、把工具调用当 pipeline 来治理、把 agent 当专业角色来分工、把权限当安全模型来建设、把生态当运行时来集成——谁就能做出更稳定、更可控、更有”产品感”的 AI 系统。