01
2026年3月31日，Anthropic 因为一个 .js.map 文件的失误，意外把 Claude Code 的完整源码送给了全世界。
51.2万行 TypeScript。1900个文件。44个 feature flag。
我知道你们在想什么——就是那个"你们不让看，我偏要看"的本能反应。
所以我把这两天所有的技术分析全扒了一遍，帮你从前端视角梳理出最有价值的部分：
Anthropic 是怎么用 TypeScript 搭一个工业级 AI Agent 的？
这不只是一次泄露事件。对想搞 AI Agent 的前端工程师来说，这是一份价值连城的参考架构。
02
先讲清楚泄露的背景，10秒版本：
Claude Code v2.1.88 发布时，打包脚本里忘了过滤 source map 文件。一个 59.8MB 的 .js.map 静静躺在 npm 包里，完整映射了所有 TypeScript 源码。
这个问题可以直接写进"前端工程化避坑手册"第一条：
# .npmignore 里必须有这一行
*.js.map
或者在 tsconfig.json 里控制：
{
"compilerOptions": {
"sourceMap": false,
"inlineSourceMap": false
}
}
生产构建，source map 默认关掉，这不是可选项。
好，教训讲完了。下面说正题。
03
Agent Loop 设计：三层结构，流式优先
Claude Code 的核心架构是一个三层 Agent 系统：
用户输入
↓
Input Parser（解析指令 + 上下文压缩）
↓
Planner Agent（制定多步计划）
↓
Executor Agent（并发调用工具）
↓
[FileReadTool] [TerminalTool] [SearchTool] [CodeGenTool] ...
↓
Validator（结果校验）
↓
Response Formatter（输出）
单看这个图，和很多开源 Agent 框架差不多。但有几个关键设计，是它跑得快的原因：
流式优先（Streaming First）
不是等模型把整段输出全生成完再执行工具，而是边流边解析，一看到工具调用指令就立刻执行。
前端同学应该能感受到这个好处有多明显：用户看到的是实时反馈，而不是等一个 Loading。延迟感至少减少一半。
并行 I/O
多个工具调用如果不存在依赖关系，会并发触发。FileReadTool 读文件和 SearchTool 搜索可以同时跑，不用排队。
懒加载上下文
不是一开始就把所有文件内容都塞进 context，而是按需加载。这个对 Token 成本的影响非常大，特别是在处理大型代码库时。
04
工具系统设计：统一接口 + 无状态
Claude Code 内置了 20+ 个工具，每个工具都实现了统一接口。用 TypeScript 表达大概是这样的：
interface Tool<TInput, TOutput> {
name: string
description: string
inputSchema: z.ZodSchema<TInput>
execute(input: TInput, context: AgentContext): Promise<TOutput>
validate?(input: TInput): ValidationResult
}
几个设计要点值得学：
1. 无状态工具（Stateless Tools）
工具本身不持有状态。所有状态（当前打开的文件、执行历史、中间变量）都由 Agent 的上层管理层维护。
好处很明显：工具可以任意组合，单个工具可以单独测试，换掉一个工具不影响整体。
2. 链式组合
工具之间不直接调用，全部通过 Agent 层中转。这意味着你可以在不改工具代码的前提下，改变编排逻辑。
比如"重构函数并写测试"这个任务，实际执行链是：
FileReadTool → CodeAnalysisTool → CodeGenerateTool → TerminalTool → [loop until tests pass]
这个 loop 逻辑完全在 Planner 层处理，工具本身不知道自己在一个循环里。
3. Zod schema 做输入校验
每个工具的输入用 Zod 定义，模型生成的工具调用参数会先经过 schema 校验。这一层拦截了大量的幻觉错误。
05
System Prompt 是动态拼装的
很多人以为 Claude Code 有一个固定的超长 System Prompt。源码告诉我们：不是。
它的 System Prompt 是运行时动态拼装的，根据当前任务上下文、项目语言类型、用户配置，组合出不同的提示片段。
大概结构是这样：
function buildSystemPrompt(context: ProjectContext): string {
const sections = [
BASE_INSTRUCTIONS,
context.projectType ? LANGUAGE_SPECIFIC_INSTRUCTIONS[context.projectType] : '',
context.hasTests ? TEST_GUIDELINES : '',
context.securityLevel > 1 ? SECURITY_CONSTRAINTS : '',
// ... 更多动态片段
]
return sections.filter(Boolean).join('\n\n')
}
这个设计的好处是：
- 减少无关 Token 消耗（不相关的指令不发送）
- 可以根据项目类型精准控制模型行为
- Prompt 的各个模块可以独立迭代，不用每次改全量
对于在做 AI 应用的前端同学，这个思路直接可以复用到自己的项目里。
06
Prompt Cache 优化：省钱的正确姿势
源码里有大量关于 Prompt Cache 的处理逻辑，这块是 Token 成本优化的核心战场。
Claude 支持 Cache Breakpoint，用 cache_control 参数标记哪些内容可以缓存。Claude Code 的做法是：
const messages = [
{
role: 'user',
content: [
{
type: 'text',
text: projectContext, // 项目级上下文，变化少，适合缓存
cache_control: { type: 'ephemeral' }
},
{
type: 'text',
text: currentInstruction // 当前指令，每次不同，不缓存
}
]
}
]
把稳定的内容（项目描述、代码库概览）标记为可缓存，把动态内容（用户当前指令）不缓存，可以把 Cache Hit Rate 提升到 60-80%。
在高频调用场景下，这个优化能把 API 成本砍到一半以下。
07
那 44 个 Feature Flag 说明了什么？
除了那个争议最大的 enable_undercover_mode（AI 伪装人类代码风格），还有几个对前端开发者很有参考价值的：
-
enable_multi_agent：多 Agent 协作，已在小范围灰度。多个 sub-agent 分工执行，主 agent 协调。这是 Claude Code 下一阶段的核心方向。 -
enable_project_graph：项目级代码图谱分析。不只是单文件理解，而是整个项目的依赖关系图。这个功能一旦上线，对大型 monorepo 的支持会有质的提升。 -
enable_capybara_models：专门针对编程任务优化的轻量模型族，低延迟、高性价比，推测是用来处理简单代码任务的快速通道。
这些 feature flag 的存在，告诉我们 Anthropic 接下来要做什么——往更大、更复杂的工程场景走。
08
看完这些，我有一个很真实的感受：
Claude Code 的架构，没有什么魔法。
它的每一个设计——流式优先、无状态工具、动态 Prompt 拼装、Prompt Cache 优化——都是工程常识的叠加，不是什么神秘黑盒。
但叠加得很精准，每个细节都在解决一个真实的成本或性能问题。
这才是工业级 AI Agent 和玩具 Demo 的区别：不是谁用了更厉害的算法，而是谁在工程层面抠得更细、想得更清楚。
如果你现在在做 AI Agent 相关的前端开发，这份源码是当前最好的参考案例之一。
不是因为它泄露了，而是因为它展示了一家顶级 AI 公司，在真实生产环境里，是怎么解决工程问题的。
你现在在做 AI Agent 相关的项目吗？有什么想聊的架构问题，评论区见。
