Claude Code 的工作原理 - Jared Zoneraich，PromptLayer

本文对 PromptLayer 创始人兼首席执行官 Jared Zoneraich 所介绍的 Claude Code 架构和实现进行了深入分析。文章追溯了编程智能体的演变历程，并强调了当前一种趋势，即倾向于依赖强大基础模型和 Bash 等基本工具的极简架构。本次演讲涵盖了 Claude Code 的内部机制，包括其核心的“While 循环”结构、上下文管理策略，以及子智能体和技能的使用。Zoneraich 还将 Claude Code 与 Cursor 和 CodeAct 等其他领先智能体进行了比较，讨论了评估智能体性能的方法，并探讨了 AI 工程的未来方向。主要启示包括信任模型、优先考虑简单设计、Bash 的多功能性以及上下文管理的关键作用。

---

内容概要

PromptLayer 创始人兼 CEO Jared Zoneraich 深入剖析了 Claude Code 的架构与实现。他探讨了编程智能体的演变，强调了向依赖强大模型和基础工具（如 Bash）的极简架构转变的趋势。讲座涵盖了 Claude Code 的内部机制，包括其核心的“ While 循环” 结构、上下文管理策略，以及子智能体和技能的使用。Jared 还将 Claude Code 与 Cursor、CodeAct 等其他前沿智能体进行了横向对比，讨论了如何评估智能体性能，并回答了关于 AI 工程未来发展方向的听众提问。

目录

• 介绍与欢迎辞

• Claude Code 与 PromptLayer 简介

• 编程智能体的演变

• Claude Code 的极简架构

• 核心工具与设计哲学

• 待办事项清单与可控性

• 上下文管理与子智能体

• 技能与统一差异比较

• 未来趋势与竞品对比

• 评估与无头 SDK

• 问答环节：DAG 与循环的对比及 API 的未来

介绍与欢迎辞

主持人： 欢迎来到最后一场研讨会。恭喜大家坚持到了最后。在 800 多人中，你们是坚持到最后的“幸存者”，是非常专注的工程师。这讲座有点特别。因为标题的原因，我其实惹了 Anthropic 一点麻烦。我把标题发给他们看，问要不要改，他们说：“不用，就这样吧，挺有趣的。”

所以，本次讲座并非 Anthropic 官方背书，但我们是极客，对吧？Jared 非常专注，他还是 PromptLayer 的创始人。我很喜欢推介纽约本地的 AI 从业者。Jared，舞台交给你。

Claude Code 与 PromptLayer 简介

Jared Zoneraich： 非常感谢。这是一场精彩的会议，虽然很遗憾即将结束，但希望我们可以画上一个圆满的句号。我是 Jared，这次演讲的主题是 Claude Code 是如何工作的。重申一下，我与 Anthropic 没有关联，他们没给我钱（虽然如果给的话我会收）。

我们要讨论包括 Claude Code 在内的几种编程智能体。我个人的高层目标是探讨这些智能体为何突然爆发。作为一名开发者，我很好奇到底发生了什么变化，让编程智能体终于变得好用了。

简单介绍一下我自己，我是 Jared，正在构建 AI 工程的工作台。我的公司叫 PromptLayer，总部位于纽约。我们三年前推出了产品，这在 AI 领域算很久了，但在其他领域还很年轻。

我们的核心理念是信奉严谨的提示词工程和严谨的智能体开发。我们认为产品团队、工程团队都应参与其中。如果你在构建 AI 律师，你就应该让律师和工程师一起参与。我们的平台每天处理数百万次大语言模型请求。本次演讲中的许多见解都来自于我们与客户关于如何构建编程智能体的对话。

我花了很多时间在“吃自己的狗粮”，也就是使用我们自己的产品来构建智能体。我是 Claude Code 的超级粉丝。我们甚至围绕 Claude Code 重组了我们的工程组织。构建平台很难，很容易陷入无数个边缘情况的泥潭。所以我们定了一条规则：如果某件事可以用 Claude Code 在一小时内完成，那就直接做，不要排优先级。作为一个小团队，这极大地帮助了我们。

编程智能体的演变

让我们回顾一下历史，看看我们要如何走到今天。大家都记得，最初的工作流是把代码复制粘贴到 ChatGPT，这在当时是革命性的。

第二步是 Cursor 的出现。如果大家还记得，Cursor 刚出来时软件体验并不好，只是一个带有 Command-K 功能的 VS Code 分支，但我们都很喜欢。然后有了 Cursor Assistant，接着是 Claude Code。

甚至在我制作这张幻灯片的几天里，可能又有新版本发布了。Claude Code 带来了一种全新的无头（Headless）工作流，甚至不需要直接接触代码。要做到这一点，它必须非常强大。

那么，它为什么这么好用？突破点在哪里？这是我的个人观点，我认为关键在于：简单的架构。

当然还有更好的模型。这听起来有点枯燥，但 Anthropic 发布了一个更适合工具调用的模型确实是关键。而简单的架构正是建立在这个基础之上的。

Claude Code 的极简架构

一句话概括目前的架构就是：给它工具，然后别挡路。

如果你在 LLM 基础上开发有一段时间了，你会知道这并不总是真理。工具调用这种 JSON 格式的抽象并不总是存在。但现在的原则是：给它工具，别干预。

模型正被训练得越来越擅长工具调用。尽管包括我在内的工程师都喜欢过度优化，比如想设计复杂的提示词链来防止幻觉，但现在的建议是：不要那样做。只需要一个简单的循环，去掉脚手架。少即是多，把舞台留给模型。

看看本周的排行榜，模型正变得越来越强。我们可以争论进步是否在放缓，但这不重要。重要的是它们在工具调用和自主运行方面越来越好。Anthropic 把这称为“AGI 药丸”（AGI pill）：不要试图过度工程化来弥补当前模型的缺陷，因为模型很快就会进步，你现在的修补工作会变成时间浪费。

这就是我认为 Claude Code 的哲学：忽略嵌入（Embeddings）、忽略分类器、忽略解析匹配。 它是反 RAG 的。虽然 Cursor 还在使用本地向量数据库来理解代码库，但 Claude Code 的天才之处在于他们摒弃了这些，说：“我们不需要这些花哨的范式来掩盖模型的不足，我们就做一个更好的模型，让它自己发挥。”

它依赖简化的工具调用，比如用 grep 替代 RAG。这是一种经过高度优化的工具调用模型。

如果你熟悉 Python 之禅，你会发现这与 Claude Code 的构建哲学非常契合：简单胜于复杂，扁平胜于嵌套。这基本上就是本次演讲的核心：回归工程原则，简单的设计就是更好的设计。

现在，我要拆解这个编程智能体的具体组成部分。

首先是宪法（Constitution），即 CLAUDE.md 文件。CodeAct 或其他工具可能使用 AGENTS.md。有趣的是，这代表团队在说：“我们不需要过度设计一个系统让模型先去研究代码库。” Cursor 1.0 会在本地建立向量数据库来研究代码库，而 Claude Code 只是说：“放一个 Markdown 文件在那，让用户和智能体在需要时修改它。”非常简单。

这回归到了提示词工程。一切最终都是提示词工程或上下文工程。如何让通用模型适应你的用途？最简单的答案往往是最好的。

核心循环（The Core Loop）： 这就是系统的核心，一个简单的主循环。这与我们过去构建智能体的方式相比是革命性的。现在所有的编程智能体 —— Claude Code、CodeAct、新版 Cursor、AMP —— 本质上都是一个带工具调用的 While 循环。

它的逻辑大概只有四行代码：

1. 当有工具调用时；

2. 运行工具；

3. 将工具结果返回给模型；

4. 重复，直到没有工具调用，然后询问用户。

第一次使用工具调用时，你会惊讶于模型竟然如此擅长判断何时继续调用工具，何时修复错误。LLM 非常擅长自我修正和灵活应变。你越是依赖模型去探索和解决问题，你的系统在面对未来更强大的模型时就越稳健。

核心工具与设计哲学

目前的 Claude Code 核心工具主要有以下几个（这可能会随时变化）：

• Read（读取）： 虽然可以用 cat，但为了应对 Token 限制，他们构建了 Read 工具。如果文件太大，它会提示。

• Grep / Glob（搜索）： 这很有趣，它违背了使用 RAG 和向量的传统智慧。但在通用智能体中，grep 非常好用，而且这正是人类开发者的操作方式。我们在模仿人类在终端解决问题的行为。

• Edit（编辑）： 注意，它使用的是差异（Diffs）而不是重写文件。这更快，消耗的上下文更少，出错也更少。就像我在你的论文上划线修改比让你重写整篇论文更容易一样。

• Bash（命令行）： 这是核心。哪怕去掉其他所有工具，只保留 Bash 也可以。Claude Code 能创建一个 Python 文件，运行它，然后删除它，这就是 Bash 的魅力。

• WebSearch / WebFetch（网络搜索与获取）： 这通常会转移到一个更便宜、更快的模型上运行。

• To-Dos（待办事项）： 保持模型在轨道上，增加可控性。

• Tasks（任务）： 用于上下文管理。如何在不污染上下文的情况下运行一个漫长的流程？

Bash 就是你所需的一切。 Bash 对编程智能体有两大优势：

1. 简单且无所不能，非常稳健。

2. 拥有海量的训练数据，因为这也是人类使用的工具。

这就是为什么模型在 Rust 等较小众语言上表现不如 Python，因为数据量不同。Bash 是通用适配器。我经常用 Claude Code 来搭建本地环境，它非常擅长弄清楚那些复杂的命令。

关于工具使用的系统提示词（System Prompt），有一些有趣的细节。比如，系统会强制模型在编辑前先读取文件（甚至强制使用 Grep 而不是 Bash 的 grep），这可能是出于安全沙箱或 Token 限制的考虑，也为了鼓励并行操作。还有一些像“处理带空格的路径时要加引号”这种琐碎的提示，这显然是 Anthropic 团队自己在“吃狗粮”时发现并修补的边缘情况。

待办事项清单（To-Do Lists）与可控性

待办事项清单现在很常见，但这以前并不是标准配置。有趣的是，这些清单是结构化的，但在代码层面并没有强制执行结构。

规则很简单：一次做一个任务，标记完成，遇到阻碍时继续处理，将任务分解。最妙的是，这一切都不是确定性代码强制的，完全基于提示词。这在两年前是行不通的，但现在模型遵循指令的能力非常强。

实际上，这只是一个函数调用。它会导出一个包含 ID、标题的 To-Do 块，甚至可以注入“证据”，即任意的数据块，供后续引用。

这给我们带来了四个好处：

1. 强制模型进行规划。

2. 崩溃后可以恢复（断点续传）。

3. 用户体验：用户知道发生了什么，而不是干等 40 分钟。

4. 可控性。

上下文管理与子智能体

在底层还有两个重要部分：

1. 异步缓冲区（Async Buffer / H2A）： 解耦 I/O 过程和推理过程。避免把终端里看到的所有东西都塞回模型里，因为上下文过多会让模型变笨。它会进行压缩和摘要，丢弃中间部分，保留头尾。

2. 长期存储： 配合沙箱（Sandbox），模型可以保存 Markdown 文件作为长期记忆。我预测未来所有的 ChatGPT 或 Claude 窗口都会自带沙箱。

子智能体（Sub-Agents）： 这是我最兴奋的部分。我们不再需要复杂的有向无环图（DAGs）。过去几年，我们在 PromptLayer 看到用户构建了极其复杂的 DAG，几百个节点用来路由用户请求。这样做的唯一好处是保证确定性，防止幻觉。

但现在，有了更强大的模型，我们不需要这种工程噩梦了。只需依赖模型去探索。

Claude Code 采用了触发阶段（Trigger Phases）：Think（思考）、Think Harder（深思）、Ultra Think（极度深思）。这是把推理 Token 预算作为一个可调节的参数。

关于沙箱和权限：这部分有点枯燥。老实说，我经常在“YOLO 模式”（大胆冒险模式）下运行它，甚至搞挂过本地数据库。对于企业级应用，确实需要防范提示词注入和网络攻击。Claude Code 在这方面做得比较严，会把不安全的 URL 放到子智能体中处理。

子智能体解决上下文问题： 子智能体拥有自己的上下文，只把结果反馈给主流程。比如文档阅读器、测试运行器。

在 Claude Code 中，Task 就是一个子智能体。它接收两个参数：描述（给用户看）和提示词。这就很有趣了：编程智能体在为自己的子智能体编写提示词。如果任务报错，它可以把更多信息塞进这个提示词字符串里，让模型去解决。

从泄露的系统提示词中，我们可以看到一些原则：

• 输出要简洁。

• 多用工具，少写文本解释。

• 大量并行运行命令。

• 匹配现有代码风格。

技能（Skills）与统一差异比较（Unified Diffing）

技能（Skills）： 我最近才被这个功能折服。可以把它看作可扩展的系统提示词。为了不让上下文变得混乱，我们给 Claude Code 一些选项，让它在需要时调取更多信息。

例如，我有用于更新文档的 Skill（告诉它我的写作风格），还有用于深度研究（Deep Research）的 Skill。我甚至让它把 GitHub 上关于 Deep Research 的文章重构成一个 Claude Code Skill，效果惊人。

统一差异比较（Unified Diffing）： 这值得单独强调。它非常显而易见，但让一切变得更好：Token 更少、速度更快、错误更少。如果你在构建智能体，强烈建议使用 Diffing。

未来趋势与竞品对比

接下来是我的观点。未来会怎样？

• 工具数量： 有人认为会有数百个工具调用。我持相反观点，我认为应该减少工具，回归 Bash，甚至是一个超级工具调用（One Mega Tool Call）。

• 自适应预算： 将推理模型视为一种工具。我们可以根据任务难度，在快速模型和昂贵的推理模型（如 o1 或 Claude Opus）之间做权衡。

• 新范式： 像 To-Do Lists 和 Skills 这样的“一等公民”范式会更多。

前沿智能体的不同流派： 这就像“AI 治疗师问题”：没有绝对最好的治疗师，只有不同流派（冥想、认知行为疗法等）。同样，没有绝对最好的编程智能体，只有不同的设计哲学。

• Claude Code： 赢在用户友好和简洁。适合需要人类介入的复杂操作（如 Git 管理）。

• CodeAct： 擅长上下文管理，感觉很强大。它是开源的，核心基于 Rust。

• Cursor IDE (Composer)： 赢在速度和 UI。它是模型无关的，而且 Composer 模型经过了蒸馏，速度极快。

• AMP (Sourcegraph)： 有趣的免费层，通过广告盈利。没有模型选择器（他们替你选），专注于构建“智能体友好”的环境（如密封的测试环境）。

• Devin (Cognition)： 端到端自主性。

详细对比 CodeAct： CodeAct 和 Claude Code 类似，也是主循环结构。它的不同在于更偏向事件驱动（Event Driven），并发线程处理做得更好。它的沙箱是基于内核的（Linux Landlock）。

详细对比 AMP： AMP 引入了 Handoff（交接）概念，类似于游戏中“切换武器比换弹夹快”。当上下文太长时，直接开启一个新线程并交接关键信息，而不是做耗时的压缩。他们还有 Fast/Smart/Oracle 三种模型档位。

详细对比 Cursor： Cursor 是 UI 优先，而不是命令行优先。他们的 Composer 模型证明了微调（Fine-tuning）依然可以建立护城河。

评估与无头 SDK（Headless SDK）

基准测试（Benchmarks）基本没用。 现在所有模型都能在基准测试上拿高分。

我们需要的是评估（Evals）。

1. 端到端测试： 比如“搜索最新模型并返回名称”，看它能否完成。

2. 回测（Backtest）： 捕获历史数据并重跑。

3. 智能体味道（Agent Smell）： 这是一个新概念。监控它调用了多少次工具？重试了多少次？耗时多久？这些表面指标能反映很多问题。

对于你构建的工具，要进行严谨的测试。把确定性下放到工具层面。如果我对输出格式有极高要求（比如特定格式的邮件），我会构建一个专门的工具并对其进行严格测试，而不是依赖模型的探索。

无头 SDK（Headless SDK）： 密切关注 Claude Code 的无头 SDK。它只是你管道中的另一个部分。我用它做了一个 GitHub Action：每天自动读取提交记录，运行 Claude Code 更新文档并创建 PR。这可能会开启一个新时代：我们在更高层抽象上构建智能体，而把编排工作交给 Claude Code。

问答环节：DAG 与循环的对比及 API 的未来

问：你提到要摆脱 DAG（有向无环图），但有些流程（如客户服务）需要按顺序执行（先问名字再问邮箱）。如果没有 DAG，如何强制顺序？

Jared： 这取决于问题类型。通用编程智能体没有固定步骤，所以依赖模型探索更好。如果是旅行行程规划或客服流程，确定的步骤更重要。这种情况下，你可以把 DAG 作为一个工具调用，或者在系统提示词中强制要求。但对于通用目标，我建议更多依赖循环。

问：未来我们是否会不再通过代码调用 API，而是通过触发 Claude Code 这种无头智能体来完成工作？

Jared： 有利有弊。好处是开发更容易，依赖前沿模型的能力。就像推理模型本质上是在 OpenAI 服务器上运行的循环一样，Claude Code SDK 也是包含更多功能的循环。所以我完全能预见很多开发者只接触这些智能体端点。但对于某些任务，你可能需要更底层的控制。

问：关于测试驱动开发（TDD）在 AI 中的应用？

Jared： 存疑时，回归工程原则。如果你信奉 TDD，那就用它。Factory 和 Sourcegraph 认为如果你能编写好的测试，智能体就能工作得更好。我自己会在规划阶段依赖规范驱动开发，但简单编辑就跳过。

问：关于系统提示词泄露，是在本地机器上找到的吗？

Jared： 似乎是的。虽然厂商试图隐藏，但在本地机器上通常能找到，或者网上有人发布了。

总结：

1. 信任模型。

2. 简单的设计胜出。

3. Bash 就是你所需的一切。

4. 上下文管理至关重要。

5. 不同的智能体视角/哲学都很重要。

感谢聆听。如果你在寻找 AI 工程相关的工作，PromptLayer 正在招聘。