Claude Code 源码泄露后，我学到了什么？——从 6 个内置 Agent 看工程化设计

Lgated

558人浏览 · 2026-04-24 15:47:37

Lgated · 2026-04-24 15:47:37 发布

大家好哇，最近写毕业论文写得头皮发麻，抽空刷到沉默王二的一篇关于 Claude Code 源码泄露的文章，熬夜跟着过了一遍，发现里面几个 Agent 的设计思路真的挺有意思的。正好我自己在做多租户 AI 客服中台，里面也涉及了不少 Agent 调度和工具隔离的逻辑，就顺手整理一下笔记，算是给自己做个备忘，也分享给大家。

一、源码结构：工具、技能、Agent 三层拆分

Claude Code 的源码目录挺清晰的，主要分三块：

tools/：40 多种工具，Bash 执行、文件读写、代码搜索、MCP 集成、任务调度等等
skills/：17 个内置 Skill，比如 remember、stuck、loop、batch、debug
tools/AgentTool/built-in/：6 个内置 Agent，各有分工

几个核心文件的体积很夸张，main.tsx 803KB，AgentTool.tsx 233KB，说明 Agent 调度这块确实是整个系统的重头戏。

这种分层让我联想到自己做客服中台时的设计：底层是工具层（查订单、查知识库、调大模型），中间是技能层（意图识别、会话摘要），上层是 Agent 编排层。分层的好处是边界清晰，出了问题知道去哪一层排查。

二、六个内置 Agent，各有各的活儿

源码里内置了 6 个 Agent，不是那种"一个万能 Agent 包打天下"的思路，而是每个 Agent 只干自己擅长的事。

1. General Purpose Agent —— 通用兜底

就是个"杂工"，常规任务都归它。代码很短，几十行，什么都能干一点，但遇到复杂任务会被调度给更专业的 Agent。

这种设计很务实。我在客服中台里也留了一个通用 Agent，专门处理那些没命中任何特定意图的闲聊和兜底回复，不然每个意图都要配一个专用 Agent，维护成本太高了。

2. Explore Agent —— 只读探索

这个 Agent 的设计哲学很有意思：只读，严禁修改。

它的系统提示词里明确写了：

This is a READ-ONLY exploration task. You are STRICTLY PROHIBITED from:
- Creating new files
- Modifying existing files
- Deleting files
- Moving or copying files

探索代码和修改代码是完全不同的心智模式。把它拆开，既避免了探索过程中手滑改坏东西，也让 Agent 更专注于"找东西"而不是"改东西"。

我在项目里其实也可以借鉴这个思路：让某个 Agent 专门做知识库检索和上下文召回，另一个 Agent 专门生成回复，检索的 Agent 不允许碰生成逻辑，生成的 Agent 不允许直接改知识库。

3. Plan Agent —— 架构规划

同样是只读模式，但职责是理解需求、分析架构、输出实现方案。

You are a software architect and planning specialist for Claude Code.
Your role is to explore the codebase and design implementation plans.

这让我想到面试里常问的"你怎么设计一个系统"。Plan Agent 的存在说明，在动手写代码之前，先让 Agent 把方案理清楚，比边写边想靠谱得多。

4. Verification Agent —— 我的最爱

这是整篇文章里我最感兴趣的部分。它的定位不是"确认代码能工作"，而是想方设法把代码搞崩。

系统提示词里甚至列出了自己的"黑历史"：

You have two documented failure patterns. 
First, verification avoidance: when faced with a check, you find reasons not to run it.
Second, being seduced by the first 80%: you see a polished UI or a passing test suite 
and feel inclined to pass it, not noticing half the buttons do nothing...

更狠的是它的对抗性探测清单：

- Concurrency: parallel requests to create-if-not-exists paths
- Boundary values: 0, -1, empty string, very long strings, unicode, MAX_INT
- Idempotency: same mutating request twice — duplicate created?
- Orphan operations: delete/reference IDs that don't exist

而且它的输出要求很严格：每个 PASS 必须附带实际执行的命令和输出，只读代码不算验证。

Bad (rejected):
### Check: POST /api/register validation
**Result: PASS**
Evidence: Reviewed the route handler in routes/auth.py...
(No command run. Reading code is not verification.)

这个设计太戳我了。LLM 确实很容易"看起来没问题就给了 PASS"，Verification Agent 用强约束逼它真正去跑测试。我在写客服中台的接口时，也可以考虑加一个类似的"对抗性验证 Agent"，专门挑边界条件和并发场景去压测。

5. Claude Code Guide Agent —— 内置帮助

类似系统的 /help 命令，解答用户怎么使用 Claude Code。看起来简单，但它是人机交互体验的关键一环。

6. Statusline Setup Agent —— 状态栏配置

负责 IDE 状态栏的显示设置，是 Claude Code 和 IDE 集成的桥梁。这种"小但关键"的 Agent 很容易被忽略，但用户体验往往就藏在这些细节里。

三、工具隔离：每个 Agent 都有自己的"黑名单"

每个 Agent 都有一个 disallowedTools 列表，明确禁止调用某些工具。

比如 Explore Agent：

disallowedTools: [
  AGENT_TOOL_NAME,        // 不能再嵌套调用 Agent
  FILE_EDIT_TOOL_NAME,    // 不能编辑文件
  FILE_WRITE_TOOL_NAME,   // 不能写文件
  NOTEBOOK_EDIT_TOOL_NAME,// 不能编辑 Notebook
]

Plan Agent 和 Verification Agent 也有类似的限制。

这种权责分离的设计让我想到 Unix 哲学：一个工具只做一件事，做好它。放在 Java 后端里，其实就是微服务的职责边界划分。我在客服中台里也应该更严格地限制每个 Agent 能调用的工具范围，避免出现"检索 Agent 手滑去改了数据库"这种离谱情况。

四、内部特权：功能开关的灰度思路

源码里有不少这样的判断：

if (process.env.USER_TYPE !== 'ant') {
  return
}

ant 是 Anthropic 内部员工的标识。比如 remember（自动记忆管理）和 stuck（诊断卡死会话）这两个 Skill，只有内部用户才能用。

更有趣的是 Explore Agent 的模型选择：

model: process.env.USER_TYPE === 'ant' ? 'inherit' : 'haiku'

内部员工继承主 Agent 的强模型（Sonnet 级别），外部用户用 Haiku 保证速度。

这个设计其实挺常见的——功能开关 + 灰度发布 + 差异化降级。我在实习做 Exam Service 项目的时候也用过类似的思路，通过配置中心控制新功能对哪些用户开放，只是没想到 AI 产品里也能这么玩。

五、对我做项目的几点启发

看完这些设计，结合自己写多租户 AI 客服中台的经历，记录几个可以落地的地方：

Agent 职责要拆细：不要指望一个 Agent 能干所有事，检索、规划、生成、验证各自独立，通过编排层调度。
工具权限必须隔离：每个 Agent 明确知道自己能调什么、不能调什么，用白名单或黑名单限制。
验证环节要"敌对"：不要只测 happy path，专门设计一个 Agent 去挑刺，边界值、并发、幂等性都要覆盖。
记忆系统可以分层：短期上下文 + 长期向量库 + 关键实体结构化存储，Claude Code 的 remember Skill 虽然内部专属，但思路可以借鉴。