Claude Code 的 40 个工具：完整参考

一个 AI 编程助手的能力上限，取决于它能用多少工具。Claude Code 内置了大约 40 个工具——每个都是独立的模块，让 LLM 能跟外部世界交互。读文件、跑命令、搜索代码、启动子智能体、抓网页、对接 MCP 服务器。工具覆盖的广度很重要，因为模型只能做你给了它的事情。

这篇文章覆盖了所有工具分类，更重要的是——那个让 40 个工具保持一致的工厂模式。

buildTool 模式

每个工具都用同一个工厂函数定义，模式贯穿所有 40 个模块：

export const MyTool = buildTool({
  name: 'MyTool',
  aliases: ['my_tool'],
  description: '这个工具做什么',
  inputSchema: z.object({
    param: z.string(),
  }),
  async call(args, context, canUseTool, parentMessage, onProgress) {
    // 执行并返回 { data: result, newMessages?: [...] }
  },
  async checkPermissions(input, context) { /* 权限检查 */ },
  isConcurrencySafe(input) { /* 能否并行执行？ */ },
  isReadOnly(input) { /* 是否只读？ */ },
  prompt(options) { /* 注入到系统提示词 */ },
  renderToolUseMessage(input, options) { /* 终端 UI：调用时 */ },
  renderToolResultMessage(content, progressMessages, options) { /* 终端 UI：结果 */ },
})

这是合约式的设计：你只需要实现几个方法，工厂会为其余部分填充合理的默认值。大部分工具只需要 name、inputSchema、call 和 prompt——其他都是可选的。

目录结构

每个工具在自己的目录里，布局标准化：

src/tools/MyTool/
├── MyTool.ts        # 核心实现（buildTool 调用）
├── UI.tsx           # Ink 终端渲染组件
├── prompt.ts        # 系统提示词中的工具描述
└── utils.ts         # 工具辅助函数

这种自包含的结构意味着添加一个新工具只需要创建一个目录，然后在 src/tools.ts 注册。prompt() 的输出会自动注入到系统提示词中。工具运行时 UI 组件会自动渲染。

文件系统工具

这是最常用的一组工具，处理所有文件交互：

FileReadTool 值得特别提一下：它支持纯文本、图片（多模态）、PDF 和 Jupyter 笔记本。行范围参数（offset/limit）让模型只读取需要的内容，而不是拉取整个文件。

FileEditTool 使用精确字符串替换——在文件中找到一段文字，替换成新的内容。这比只改几行就重写整个文件安全得多。

Shell 和执行工具

BashTool 是主力工具。它运行命令、捕获 stdout/stderr、返回退出码。权限系统对 Bash 特别关注——像 rm -rf / 这样的危险命令模式默认被拦截，用户可以配置像 Bash(git *) 这样的细粒度规则来允许 git 命令无需确认。

Agent 和编排工具

这些工具让 Agent 能启动其他 Agent，形成独立工作者的树状结构：

AgentTool 是这里面最有趣的。它让 LLM 可以说"我需要并行研究这个问题"，然后启动一个完全独立的 Agent 实例。子智能体有自己的工具集和自己的对话上下文，完成后流式返回结果。这就是 Claude Code 执行"在整个代码库中搜索 Bug"这种任务却不阻塞主对话的方式。

TeamCreateTool 更进一步——它创建一个协调的智能体组，可以同时处理问题的不同部分。主智能体充当协调者，收集结果并综合最终回答。

任务管理工具

这些工具在 Agent 内部实现了一个持久化任务系统：

这是一个内建在 Agent 中的轻量级任务系统。任务用于后台工作——启动长时间运行的分析、跟踪多步骤操作的进度、或推迟不需要立即结果的工作。只读/可写的分离与文件工具的套路一致。

网络工具

这两个工具给了 Agent 互联网访问能力。WebSearchTool 执行搜索查询并返回结果。WebFetchTool 抓取特定 URL 并提取内容。两者都是只读的，这意味着它们会绕过许多权限检查——模型可以自由搜索和阅读网络内容而无需用户确认。

MCP 工具

MCP 工具让 Claude Code 能连接外部服务：

MCPTool 是个动态包装器——它没有固定实现。当你连接一个 MCP 服务器时，这个工具会自适应地暴露该服务器提供的任何工具。mcp__${serverName}__${toolName} 的命名约定防止了来自不同服务器的工具之间发生名称冲突。

集成工具

LSPTool 对代码理解特别有用。Agent 不需要猜测函数做什么，而是可以直接询问 LSP 服务器：找到定义、找到所有引用、获取悬停文档。这让模型拥有了和你 IDE 一样的代码分析能力。

调度和触发器工具

这些启用了主动和事件驱动的行为。Agent 可以设置定期任务或响应外部触发器——对监控、定期检查或 CI/CD 集成很有用。

工具类工具

AskUserQuestionTool 是安全阀。当 Agent 遇到歧义时——编辑哪个文件、采用哪种方法、是否继续执行风险操作——它可以直接问用户。这在自主执行和用户控制之间架起了一座桥梁。

权限模型

每次工具调用都会经过多层权限检查：

权限规则使用通配符模式，表达能力出人意料地强：

Bash(git *)           # 允许所有 git 命令，无需确认
FileEdit(/src/*)      # 允许编辑 src/ 中的任何内容
FileRead(*)           # 允许读取任何文件

这些规则可以在多个层级配置：企业策略（MDM）、用户设置（~/.claude/settings.json）、项目设置（.claude/settings.json）或会话级别。最具体的规则获胜。

每个工具还实现了自己的 checkPermissions() 方法用于工具特定的逻辑。比如 BashTool 会在询问用户之前先检查命令是否匹配已知的危险模式。

工具预设

工具并不总是以扁平列表注册。它们被分组为不同上下文的预设：

• 只读预设：FileReadTool、GlobTool、GrepTool、WebSearchTool 等——用于代码审查或探索模式
• 完整工具集：所有工具——用于活跃开发
• 规划模式：仅 AskUserQuestionTool 和只读工具——用于规划阶段

这种上下文相关的工具选择很重要，因为它塑造了模型的行为。只给只读工具，它会分析。给完整工具集，它会动手构建。

一些观察

工具系统揭示了很多关于 Claude Code 如何看待能力边界的思路。只读 vs 破坏性操作是一个一等公民的概念——它直接映射到权限系统的默认行为。并发安全标志是另一个工具设计者需要明确考虑的维度。

最让我印象深刻的是这种一致性。40 个工具，全部用同一个工厂构建，全部遵循同样的约定。新的贡献者读一个就能理解所有工具。这是精心设计的抽象的标志。

对任何正在构建自己 Agent 的人，我的建议是：尽早投资你的工具抽象层。模型的行为是由你给它的工具塑造的，一个干净、一致的工具 API 决定了 Agent 是可预测的还是混乱的。