我把 Claude Code 源码扒了一遍,终于看懂了 AI 编程软件真正的壁垒

真正的问题，不是模型强不强

过去一年，大家谈 AI 编程，最容易陷入一种讨论套路：

• • 谁家的模型更强
• • 谁的上下文窗口更大
• • 谁的 benchmark 更高
• • 谁更像“全自动程序员”

这些当然重要，但问题是:

如果你只盯着模型，很可能会把整件事理解反。

最近我花了一些时间认真读了 Claude Code 的源码。读完之后，我最大的感受不是“这个产品多神奇”，而是：

我终于看明白了，AI 编程软件真正的壁垒，不只是大模型，而是围绕大模型构建的一整套运行时系统。

说得再直接一点，Claude Code 让我意识到，今天 AI 编程产品真正比拼的，已经越来越不是“谁接了更强的模型”，而是你到底有没有能力把模型组织成一个真正可用的系统。

模型当然是底座，但产品的体验并不直接等于模型能力。用户最终感受到的，往往是另一层东西：你的上下文是不是足够准确，你的工具是不是足够稳定，你的规则和技能是不是足够清晰，你的 Agent 调度是不是足够聪明。很多产品看起来都在“接大模型”，但真正拉开差距的，恰恰是这些运行时设计。

这也是为什么我越来越相信一句话：

AI 编程软件拼到最后，拼的不是“模型接口接得多快”，而是“系统做得多深”。

这篇文章，我想把这件事尽量讲透。

大多数人，其实都把 Claude Code 理解浅了

如果从表面看，Claude Code 很像一个“会读代码、会改代码、会跑命令”的 AI 助手。但如果你真的翻进去看源码，你会发现它根本不是一个简单的聊天壳。

它更像一个完整的编程代理运行时。用户输入进来之后，系统不会立刻把一句话原封不动扔给模型，而是先做一整套准备动作：装配系统上下文和用户上下文，按需加载项目规则和技能，准备工具和外部能力，把必要的文件、历史、摘要、状态拼成一个适合推理的环境。然后它才进入多轮循环，让模型决定下一步该说什么、该调什么工具、要不要把任务拆给子 Agent。

所以如果只用一句话描述 Claude Code，我现在会这么说：

Claude Code 不是“给大模型加几个工具”，而是“围绕大模型做了一套编程代理 runtime”。

这句话看起来平平无奇，但它几乎决定了你后面怎么理解 Rules、Skills、Tools、MCP 和 Agent。你一旦把 Claude Code 理解成“运行时”，很多原本混乱的概念就会突然变得顺了。

为什么几乎所有人都会搞混 Rules 和 Skills

这几乎是所有刚开始研究 Claude Code、Cursor、Copilot Agent 的人都会碰到的问题。

因为从形式上看，它们都可能是 markdown：

• • Rules 是 .md
• • Skills 也是 .md

对于底层 LLM 来说，它们最后都会被切成 token，进入上下文窗口。所以很多人会自然地想：

既然最后都是文本，那 Rules 和 Skills 的区别到底是什么？

但源码告诉你，文件格式相似，不代表运行时语义相同。

Rules 根本不是“命令”，而是另一种上下文武器

Claude Code 会加载下面这些 instruction files：

• • CLAUDE.md
• • .claude/CLAUDE.md
• • .claude/rules/*.md
• • CLAUDE.local.md

它们统一进入一条 memory / instruction loading 管线。

这意味着 Rules 的作用不是“被执行”，而是默默待在上下文里，持续约束模型接下来怎么判断、怎么行动。它会告诉模型应该遵守什么，也会告诉模型在当前目录、当前文件路径下，到底哪些约束是真正生效的。

我后来觉得，Rules 最准确的理解其实很像：

项目级配置 + 行为约束 + prompt 时代的 policy 文件。

尤其 .claude/rules/*.md 这套设计非常有意思。它不是把所有规则一股脑塞给模型，而是支持按路径条件加载。

也就是说，Claude Code 其实在做一件很“工程”的事：

把正确的规则，在正确的时机，送进正确的上下文。

这已经不是简单的 prompt 拼接，而是很典型的 context engineering。

Skills 也不是“说明文档”，它本质上是可调用工作流

Skills 和 Rules 最大的区别在于，它不是被动生效，而是主动参与执行流程。

从源码上看，Claude Code 会把 skill markdown 解析成一种 PromptCommand，里面不只是正文文本，还可能带很多元数据：

• • allowed-tools
• • model
• • user-invocable
• • hooks
• • context: fork
• • agent
• • effort

这一点非常关键。

因为它说明 Skill 不是普通说明文档，而是一个：

带执行语义的工作流模板。

所以如果非要用一句话区分，我现在会说：Rules 解决的是“应该怎么约束”，Skills 解决的是“这类任务通常该怎么做”。

它们看起来都像 markdown，但在系统里的地位完全不同。Rules 更像配置和边界，Skills 更像套路和流程。前者是在告诉模型“什么不能越界，什么必须遵守”，后者是在告诉模型“遇到这类问题时，通常应该怎么组织动作”。文件格式只是表面，运行时语义才是关键。

Claude Code 真正厉害的，不是 Tool Calling，而是 Context Engineering

过去大家谈 AI 编程软件时，很容易把“会调工具”当成最强能力。

这当然是一个重要阶段。因为没有工具，模型就只能说，不能真正做。

但读完 Claude Code 的源码之后，我反而觉得，它最厉害的地方不只是 Tool Calling，而是：

它把 Context Engineering 做成了一个系统。

什么意思？

它不是一次性把所有信息塞进 prompt，而是在运行中不断做重建。系统会先加载基础的系统上下文和项目级 instruction files，然后再根据当前触达的文件、最近的动作、会话状态和历史长度，选择性补充 conditional rules、attachments、memory 和 relevant files；当上下文太长时，还会做 compact 和 summary，把旧历史压缩成模型还能继续利用的结构。

也就是说，Claude Code 并不是“先有一个完整 prompt，再去问模型”。它更像是在运行中不断重建、补充、裁剪 prompt。

所以我现在特别喜欢一句话：

Claude Code 不是在写 prompt，而是在做 prompt runtime。

这句话我觉得几乎一下子就把问题讲透了。

Tools 和 MCP，其实是两层不同的问题

如果说 Context Engineering 解决的是“让模型在正确前提下思考”，那 Tools 和 MCP 解决的就是“让模型真正能动手”。不过这两者并不是一回事。

Tool 解决的是动作抽象。Claude Code 会把“读文件”“改文件”“搜索”“跑 shell”“调起 Agent”“调用 Skill”这类能力统一包装成 Tool。模型在推理过程中输出的，不只是文本，还可能是结构化的 tool_use；运行时执行对应动作，再把 tool_result 回给模型继续推理。从工程感觉上，这非常像一层专门为模型准备的系统调用接口。

MCP 解决的则是接入问题。它关注的不是“动作本身如何抽象”，而是“外部能力如何标准化进入 Claude Code”。所以 MCP 更像一套统一扩展协议，负责把 IDE、外部服务、远程资源接进当前运行时，再暴露为 tools、resources 或 commands。

换句话说，Tool 是“统一动作接口”，MCP 是“统一外部接入协议”。一个偏执行抽象，一个偏能力接入。把这两层分开理解之后，Claude Code 的设计会清晰很多。

真正让我改观的，是 Agent 这一层

如果继续顺着前面的逻辑往下走，你会发现一个很自然的结论：如果 Rules 代表约束，Skills 代表套路，Tools 代表动作，那 Agent 代表的就是：

执行单元。

而且不是一个轻飘飘的概念，而是一个非常具体的运行时对象。

在 Claude Code 的实现语义里，一个 Agent 往往有自己独立的 system prompt、独立的上下文历史、独立的工具集、独立的技能集，甚至还会有独立的 MCP 配置、权限模式、token / turn / cost budget，极端一点还会带独立 worktree。你看到这里就会明白，它根本不是“把 prompt 多发一次”那么简单，它更像一个被裁剪出来的小型执行环境。

所以 Claude Code 的多 Agent 机制，真正有价值的地方也不只是“并发”两个字。更重要的是，它能隔离上下文、降低噪声、提高专用任务的处理质量，还能把复杂问题拆开之后再重新汇总。这种感觉已经非常接近经典软件工程里的“主进程 + 子进程 + 任务分发”了。

换句话说，主 Agent 像调度器，Subagent 像 worker。

这已经很接近经典软件工程里“主进程 + 子进程 + 任务分发”的设计感觉了。

读到这里，我突然意识到：Agent 很像操作系统

这可能是我读完源码后最强的一个直觉。

我越来越觉得，所谓 Agent 系统，其实非常像经典软件工程概念在 LLM 时代的重新映射。

我现在很喜欢这样类比：Main Agent 像主进程，Subagent 像子进程或者 worker，Context Window 像工作内存，Rules 像配置与策略，Skills 像脚本模板或高阶函数，Tools 像系统调用，MCP 像外部总线，Compaction 像 checkpoint 或内存压缩，而 Token Budget 则像资源配额。

当然，这个类比不是严格一一映射。

因为 Agent 和传统进程仍然有明显差别：

• • 它是概率性的，不完全确定
• • 它没有真正的随机访问内存
• • 它的状态更新依赖 prompt 重组，而不是变量赋值

但从工程结构上看，这个类比极其有帮助。

它让人突然意识到：

Agent 不是什么脱离软件工程的新神秘物种，它只是把软件工程重新搬到了 LLM 时代。

这就是我说的“返璞归真”。

如果从产品视角看，Claude Code 到底是什么

看到这里，我觉得还可以再往前退一步，不从源码看，而是从产品看。

从产品维度理解，Claude Code 本质上是一个“软件领域的 AI 产品”。它服务的是非常具体、非常成熟、也非常数字化的工作流：读代码、改代码、搜索工程、运行命令、理解目录、调用开发工具。这一点非常重要，因为这意味着它天然拥有几类适合被 LLM 接管的对象：文本、代码、命令、文件、日志、diff、配置、目录结构。换句话说，软件工程是一个非常适合做 Agent 化的场景。

也正因为如此，Claude Code 才会在产品层创造出一整套新的概念体系，例如 Rules、Skills、Agent、Subagent、Tool、MCP。严格说，这些概念并不是大模型底层算法的原生概念，而是产品在“把 LLM 变成可用软件”过程中发明出来的运行时抽象。它们是产品语言，也是工程语言。

这件事放到更大的范围里看也很有意思。Claude Code 的成功，并不自动意味着其他行业也能无缝复制这一套。软件领域有几个天然优势：几乎一切对象都已经数字化、文本化、结构化，验证结果也相对明确，工具链成熟，反馈闭环快。而其他领域，比如教育、医疗、制造、法律、咨询，虽然都在谈 Agent，但它们能否像软件工程这样自然地沉淀出 Rules、Skills、Tools、Subagent 这些抽象，其实还远远没有被验证。

所以我现在更愿意把 Claude Code 看成一个很强的样本，而不是一个已经被普遍证明的终局。它告诉我们，基于 LLM 大模型做产品，真正要解决的不是“怎么把模型接进来”，而是“怎么围绕一个具体行业，把输入、规则、动作、验证、协作和反馈组织成一个闭环系统”。在软件领域，这件事成立了，而且非常有说服力；在其他领域，它仍然在路上。

AI 编程软件，已经悄悄进入下半场了

如果让我总结这一类产品的演进路线，我现在会这样概括：

Prompt Engineering    ->Function / Tool Calling    ->Context Engineering    ->Agent Orchestration

第一阶段是 Prompt Engineering，核心是让模型更会回答。第二阶段是 Function / Tool Calling，核心是让模型开始具备行动能力。第三阶段是 Context Engineering，核心是让模型在正确上下文里做正确的事。第四阶段则是 Agent Orchestration，也就是让系统开始学会拆任务、分配任务、回收结果，再把多个执行单元重新组织起来。

如果把 Claude Code 放到这条线里，它显然已经不只是第二阶段的 Tool Calling 产品，而是明显进入了第三阶段，甚至在往第四阶段走。

这也是我觉得今天很多人讨论 AI 编程时，最容易忽略的一点：

真正拉开差距的，已经越来越不是“会不会调工具”，而是“会不会组织上下文和执行”。

所以，Claude Code 真正的壁垒到底是什么

读完源码之后，我现在对这个问题的答案非常明确。

Claude Code 的壁垒，不只是模型强，而是它把几件看上去分散的事情组织成了一个统一系统：高质量的 Context Engineering、稳定的 Tool Runtime、可复用的 Rules / Skills 体系，以及可拆分复杂任务的 Agent Runtime。

更有意思的是，这些能力背后其实都还是非常传统的工程问题，比如分层、调度、抽象、协议、隔离、状态管理、错误恢复和资源控制。也就是说，Claude Code 真正厉害的地方，不只是“智能”，而是“工程化”。

这也是它最打动我的地方。

最后说一句：AI 时代没有消灭软件工程

如果你问我，读 Claude Code 的源码之后，我最大的感受是什么。

我会说：

AI 时代并没有消灭软件工程，反而让软件工程重新成为核心竞争力。

未来 AI 编程软件继续往前走，真正能拉开差距的，依然不会只是模型大小，而是：

谁能把“模型 + 上下文 + 工具 + 规则 + 技能 + Agent”做成一个真正可持续演进的系统。

从这个意义上说，Claude Code 值得学习的，不只是它用了什么模型，而是它展示了一种非常成熟的 AI 软件架构观。