Claude Code内置工具与技能完整清单揭秘

在上一篇文章中，我们深入剖析了Claude Code的System Prompt架构与提示词工程。今天，我们把目光转向它的“能力体系”——一个由40多个内置工具、5个专用Agent以及一套完整的斜杠命令构成的强大工具箱。所有洞察，均源自对源码的深度分析。

一、工具全景：40+ 个内置工具

Claude Code的工具系统（tools/目录）堪称其核心引擎，包含了超过40个功能各异的工具。为了清晰理解，我们可以将其分为以下几大类。

1. 文件操作类（核心 5 件套）

这里的设计理念非常明确：构建一个“专用工具优先”的体系。System Prompt中有一条硬性规定，禁止模型使用cat、grep、find等原生Bash命令来替代这些专用工具。为什么？因为专用工具能让用户的每一步操作都变得透明、可审查。

2. 命令执行类

以BashTool为例，它远不止于执行命令那么简单，还具备一些特殊能力：

• run_in_background: true：允许命令在后台运行，完成后会收到系统通知。
• dangerouslyDisableSandbox: true：可以绕过沙箱限制，但这需要用户明确确认。
• timeout参数：为命令执行设置最长10分钟的超时限制。
• description字段：提供一个人类可读的命令说明，主要用于向用户展示权限请求。

3. 代码智能类（LSP）

这是Claude Code区别于普通“文本操作AI”的关键。通过集成Language Server Protocol（LSP），它实现了IDE级别的代码理解和导航能力。

LSP 工具 - 接入 Language Server Protocol：
- goToDefinition：跳转到定义
- findReferences：查找所有引用
- hover：获取悬停信息（类型、文档）
- documentSymbol：列出文件内所有符号
- workspaceSymbol：全项目符号搜索
- goToImplementation：查找接口实现
- prepareCallHierarchy：调用层级分析
- incomingCalls / outgoingCalls：调用链分析

4. 多 Agent 协作类

多Agent协作不是简单的聊天，而是一套严谨的工作流：

1. TeamCreate → 创建团队 + 任务列表目录
2. TaskCreate → 创建任务
3. Agent（with team_name + name）→ 召唤队友
4. TaskUpdate（owner=队友名）→ 分配任务
5. SendMessage（to=队友名）→ 协调工作
6. SendMessage（shutdown_request）→ 解散队伍

5. 任务管理类

这里设计了两套系统：TodoWriteTool是轻量版，适合单Agent会话中的简单待办事项；而Task*系列则是重量级工具，支持多Agent协作、任务所有权分配甚至依赖关系管理。

6. 定时任务类（Cron）

定时任务工具包括：

CronCreate  - 创建定时任务（支持标准 5 字段 cron 表达式）
CronDelete  - 取消定时任务
CronList    - 列出所有定时任务

其设计亮点颇多：

• 会话与持久化：默认是Session-only（会话内有效），但也支持Durable模式，可将任务持久化到.claude/scheduled_tasks.json文件。
• 避开整点：系统会刻意避免设置整点（如:00或:30）触发。原因很实际：如果全球用户都选择整点执行，可能会对API服务器造成请求风暴。
• 生命周期管理：支持一次性任务（触发后自动删除）和周期性任务。周期性任务还设有自动过期机制，最多运行N天后便会停止。

7. 自主模式专用工具

自主模式下，Sleep工具的设计尤为巧妙：

• 每次唤醒都需要消耗一次API调用，这构成了成本约束。
• Prompt Cache有5分钟的过期时间，这自然成为了Sleep时长的上限。
• 心跳机制：系统会周期性发送心跳信号，模型收到后需要决定是继续“睡眠”还是开始“工作”。

8. 交互式工具

9. Web 类工具

10. MCP 相关工具

11. 其他工具

二、内置 Agent：5 个专用子 Agent

除了通用能力，Claude Code还内置了5个高度特化的子Agent，每个都有独立的System Prompt、工具权限和模型配置策略。

1. general-purpose（通用 Agent）

这是全能型的子Agent。

角色：全能型子 Agent
工具权限：所有工具（*）
模型：默认子 Agent 模型
触发时机：需要跨多文件研究、探索复杂架构、执行多步任务
System Prompt 核心：
  “完整完成任务——不镀金，但不能半途而废。
   完成后返回简洁报告，包括做了什么和关键发现。”

2. Explore（探索 Agent）

顾名思义，这是专为快速代码搜索而生的专家。

角色：快速代码搜索专家
工具权限：只读（禁用 Agent/FileEdit/FileWrite/NotebookEdit）
模型：外部用户用 Haiku（速度优先），内部用继承
触发时机：
  - 按文件名模式搜索（“找所有 *.tsx 组件”）
  - 按关键词搜索（“API 端点在哪里定义”）
  - 回答代码库问题（“认证流程怎么运作”）
特殊配置：omitClaudeMd = true（不加载 CLAUDE.md，节省 Token）

它的提示词里明确要求“尽可能并行调用工具”，一切设计都围绕着吞吐量和速度优化。

3. Plan（规划 Agent）

这位是纯粹的软件架构师，只动脑，不动手。

角色：软件架构师，只做规划不写代码
工具权限：只读（与 Explore 相同）
模型：inherit（继承父 Agent 模型）
触发时机：在实施前设计方案
输出要求：必须以 “Critical Files for Implementation” 结尾
           列出 3-5 个实施关键文件
System Prompt 核心：
  “你只能探索和规划。你不能也不应该写入、编辑或修改任何文件。”

它的工作流程非常清晰：

1. 理解需求
2. 探索代码库（只读）
3. 理解现有架构和模式
4. 设计方案
5. 输出分步实施策略 + 关键文件列表

4. verification-agent（验证 Agent）

这是整个体系中最有趣、也最“犀利”的Agent。它扮演着对抗性验证专家的角色，专门负责“挑刺”和找漏洞。

角色：对抗性验证专家，专门找漏洞
工具权限：所有工具，但严禁修改项目文件
触发时机：非平凡实现完成后自动触发（3+ 文件改动/后端变更/基础设施变更）
模型：主模型（全力验证）

其System Prompt中包含了一段极为深刻的“自我反思”和警告，直指LLM在自我验证时的常见偏差：

你有两个已记录的失败模式：
1. 验证逃避：面对检查时，你找借口不运行它——
   你读代码，叙述你“会测试什么”，然后写上 PASS 就结束了。
2. 被前 80% 迷惑：你看到漂亮的 UI 或通过的测试套件，
   就倾向于给 PASS，没注意到一半按钮什么都不做，
   刷新后状态消失，后端在错误输入时崩溃。
   前 80% 是简单的部分。你的全部价值在于找到最后 20%。

你会感受到跳过检查的冲动。这些是你会用到的借口——认出它们，做相反的事：
- “代码看起来是对的” → 读代码不是验证。运行它。
- “实现者的测试已经通过” → 实现者也是个 LLM。独立验证。
- “这应该没问题” → 应该没问题不是已验证。运行它。
- “我没有浏览器” → 你真的检查过 mcp__playwright__* 吗？

Verification Agent拥有一套明确的裁决体系：

• PASS：通过。但调用者通常会抽查2-3个命令进行二次验证。
• FAIL：失败。实现者需要修复问题，然后再次提交验证，直到通过。
• PARTIAL：部分通过。必须详细报告哪些部分通过了，哪些无法验证。

关键在于，只有Verification Agent有权分配这些裁决，实现者不能自我赋予PARTIAL状态。

5. claude-code-guide（文档 Agent）

可以把它看作是Claude Code内置的“用户手册”和实时问答助手。

角色：Claude Code 的“用户手册”和问答助手
工具权限：Read/Glob/Grep/WebFetch/WebSearch
模型：Haiku（轻量快速）
触发时机：用户提问 Claude Code 的功能、配置、API 使用方法
数据源：
  - Claude Code 最新文档（https://code.claude.com/docs/）
  - Claude API 文档（https://platform.claude.com/llms.txt）
特殊配置：permissionMode = 'dontAsk'（不询问权限直接执行）

更智能的是，这个Agent具备动态上下文感知能力。它的System Prompt会实时注入用户当前的配置状态，包括：

• 当前已配置的自定义 Skills
• 当前已配置的自定义 Agents
• 当前已连接的 MCP 服务器
• 用户的 settings.json 内容

三、内置 Slash Commands（技能）

除了工具和Agent，Claude Code还提供了一套丰富的斜杠命令（commands/目录），用户可以通过输入/命令名来快速调用。

代码与 Git 类

项目配置类

会话管理类

规划与任务类

工具与诊断类

特色高级命令

四、一张图看懂 Claude Code 的能力架构

为了更直观地理解这套复杂体系，我们可以将其概括为三层架构：

Claude Code 能力体系
│
├── ? 工具层（40+ 个）
│   ├── 文件操作：Read / FileEdit / FileWrite / Glob / Grep
│   ├── 命令执行：Bash / PowerShell / REPL
│   ├── 代码智能：LSP（10 种操作）
│   ├── 多 Agent：Agent / SendMessage / Team*
│   ├── 任务管理：Task* / TodoWriteTool
│   ├── 定时任务：CronCreate / CronDelete / CronList
│   ├── 自主模式：Sleep / Brief / RemoteTrigger
│   ├── 交互：AskUserQuestion / EnterPlanMode / ExitPlanMode
│   └── Web：WebFetch / WebSearch
│
├── ? 内置 Agent 层（5 个）
│   ├── general-purpose → 通用全能（所有工具）
│   ├── Explore → 快速只读探索（Haiku 模型）
│   ├── Plan → 软件架构规划（只读）
│   ├── verification-agent → 对抗性验证（找漏洞专用）
│   └── claude-code-guide → 文档问答（Haiku + 实时文档）
│
└── ⌨️ Slash 命令层（50+ 个）
    ├── 代码与 Git：/commit /review /security-review...
    ├── 项目配置：/init /hooks /mcp /sandbox...
    ├── 会话管理：/compact /clear /memory /cost...
    ├── 规划任务：/plan /ultraplan /tasks /agents...
    └── 高级特色：/ultraplan /ultrareview /insights...

五、最值得关注的设计细节

在深入源码后，有几个设计细节尤其值得开发者品味和借鉴。

1. Explore Agent 用 Haiku，Plan Agent 用 inherit

这体现了精细化的成本与效能权衡。探索（Explore）通常是“量大速快”的任务，对响应速度要求高，但对深度推理要求相对较低，因此选用更经济、更快的Haiku模型。而规划（Plan）则需要深度理解代码结构和架构，因此继承主Agent的模型（可能是能力更强的Sonnet或Opus）。模型按任务特性分配，而非一刀切。

2. Verification Agent 的“不信任实现者”原则

其提示词中那句“实现者也是个 LLM。独立验证。”堪称点睛之笔。这直接矫正了AI自我核验时可能存在的偏差。当LLM写的代码再由同一个（或同类）LLM核验时，容易形成一个“自我确认”的闭环。Verification Agent的设计就是为了显式打破这个闭环，引入独立的、对抗性的视角。

3. CronCreate 的“避开整点”设计

这是一个将运维意识嵌入到产品设计中的典型案例。系统会建议用户将“每天早上9点”的任务设置为57 8 * * *（8点57分），而不是0 9 * * *（9点整）。目的就是为了避免全球用户在同一时刻触发任务，形成对API服务器的请求风暴。

4. AskUserQuestion 的 preview 字段

这个设计提升了命令行交互的体验天花板。它允许在选项旁边渲染Markdown或HTML预览面板。这意味着，当向用户展示“方案A的代码”和“方案B的代码”时，可以进行可视化的对比，把CLI的交互能力做到了接近GUI的水平。

5. ultraplan 的“双端协作”架构

这实现了一个真正的人在回路（Human-in-the-loop, HITL）设计：

1. 本地Claude Code：负责发起规划任务，并轮询结果。
2. 远程CCR（Claude Code on the Web）：在云端使用Opus模型进行深度规划。
3. 用户在浏览器端：可以实时看到整个规划过程，并拥有修改、批准的权力。

批准后的方案才会返回本地执行。对于大规模、复杂的规划任务，人类的最终批准权是至关重要的一环。