内置工具集

这一课你将能做到

1. 说出 Claude Code 内置工具的分工：Read/Edit/Write 管文件、Glob/Grep 管搜索、Bash 管命令、WebFetch/WebSearch 管网络、Task/TodoWrite 管编排
2. 理解「Edit 前必先 Read」等安全设计，以及权限系统与 Hooks 如何作用在每个工具上
3. 通过精准提示影响工具选择与效率，避免上下文浪费和重复失败

为什么要学

Claude Code 的一切能力最终都落到工具调用上。你看不懂它的工具，就看不懂它在干什么、为什么慢、为什么失败；你调不动工具权限，就管不住它的行为边界。这一课把引擎盖掀开：工具是「它的手」，权限是「闸门」，Hooks 是「卡口」，前面学的机制在这里串成一张网。理解工具集也是面试高频题——「agent 是怎么执行动作的」本质上就是在问工具调用机制。

人话：把 Claude Code 想成一个新员工，工具就是他的工位设备——眼睛（Read）、笔（Edit/Write）、放大镜（Grep）、通讯录（Glob）、终端（Bash）、浏览器（WebFetch）、外派名额（Task）。你不需要替他操作设备，但要懂每台设备能干什么、什么时候会卡壳。

先建立图像

┌─ 感知 ──────────────────────────────────────┐
│ Read      读文件（文本/图片/PDF/笔记本）      │
│ Glob      按文件名模式找文件  **/*.java       │
│ Grep      按内容正则搜代码（基于 ripgrep）    │
├─ 行动 ──────────────────────────────────────┤
│ Edit      精确替换文件片段（改前必须先读）    │
│ Write     新建/整体覆盖文件                  │
│ Bash      执行 shell 命令（构建/测试/git…）   │
│ WebFetch  抓取指定 URL 转 markdown           │
│ WebSearch 搜索引擎查询（按环境可用性）        │
├─ 编排 ──────────────────────────────────────┤
│ Task      启动子代理干专项活                  │
│ TodoWrite 维护任务清单，拆步骤防遗漏          │
└──────────────────────────────────────────────┘
每一步都经过：权限闸门（allow/ask/deny）→ Hooks 卡口

跟着做

步骤 1：观察搜索策略（Glob vs Grep）

找出项目里所有名为 *Controller.java 的文件，并列出其中定义的接口路径

观察过程：它先 Glob 按文件名定位，再 Grep 按内容搜 @RequestMapping。记住这条经验：知道文件名找文件用 Glob，知道内容找位置用 Grep。

步骤 2：观察「读后改」约束

把 OrderService 里所有的 System.out.println 换成 log.info

注意它的动作序列：Read（整读目标文件）→ Edit（逐处替换）。让它改一个它没读过的文件是低效且易错的——Edit 要求基于已读内容做精确匹配，这是防止盲改的安全设计。

步骤 3：给它「看图」的能力

（在输入框直接粘贴一张报错截图）
这个异常栈指向的问题在哪？

Read 支持读取图片，多模态让它能直接看截图、设计稿、PDF。对前端像素级还原、后端异常排查都是杀手级场景。

步骤 4：用 @ 引用减少它的摸索

@src/main/java/com/demo/order/OrderService.java 第 88 行附近为什么会 NPE？

带路径 + 行号的提示，让它一步 Read 到位，省掉数轮 Glob/Grep 探索。你每提供一条精确线索，就省它三轮工具调用。

步骤 5：限制它的工具箱

# 启动时禁用某工具
claude --disallowedTools "WebSearch"

或在 settings.json 的 deny 中写 WebFetch。让审查类任务在无网络环境下跑，结果更聚焦也更安全。

步骤 6：让它自己管任务清单

先把这个需求拆成 TODO 清单再逐项实现

观察 TodoWrite 的清单出现与勾选——多步任务时它是防遗漏的骨架，你也能随时看到进度。

讲清楚要点

1. Edit/Write 与 Bash 的边界：结构性代码修改走 Edit/Write（有 diff 展示、可权限控制）；批量文件操作、构建测试走 Bash。你也可以明确要求（「用 sed 批量替换」）来指定路径。
2. 大文件是上下文杀手：Read 有长度上限，超长文件被截断。引导它「读 200-300 行」「先 Grep 定位再 Read 区间」，比「把整个文件读了」高效得多。
3. 搜索不到的三种原因：路径不对（用绝对/相对路径校准）、被忽略规则挡住（默认尊重 .gitignore）、关键词错了（先让它列出实际内容再定词）。
4. 工具失败是常态不是异常：命令报错、路径不存在都会作为结果返回，模型会自行换路重试。你看到「失败—调整—再试」是 agent 工作流的正常节拍，别急着打断。
5. 工具层是权限与 Hooks 的作用点：每类工具对应权限规则（Bash(npm run test:*)）、Hook 事件（PreToolUse matcher: Edit）。管行为就是管工具。

你可能会懵的地方

• 它什么时候用 Bash 什么时候用专用工具？ 模型按成本与可靠性权衡：专用工具结构化、权限粒度细、有防呆（如 Edit 前置 Read）；Bash 万能但风险面大。实践上不用替它操心，只在你不希望它走某条路时用规则限制。

• 为什么它 Edit 总是先 Read 一遍？ 安全约束：编辑必须基于真实的文件当前内容做匹配替换，防止基于过时假设盲改。也提示你：改文件前若有未保存的外部变更，先同步。

• Grep 输出太多把上下文塞满了？ 引导收敛：「只搜 src/main 目录」「只看前 20 条」「带上下文 3 行」。Grep 支持按路径、模式、行数收敛，明确范围即省 token。

• 它能联网查资料吗？ 能，WebSearch 搜索 + WebFetch 抓取指定页面（转 markdown 后阅读），两者都受权限规则管控（如 WebFetch(domain:docs.spring.io)）。内网/离线环境可用 deny 关闭。

• 我能给它加新工具吗？ 内置工具不可增删，但扩展有两条正路：MCP 服务器（连接外部系统能力）与 Hooks（给现有工具加前后逻辑）。能力扩展用 MCP，行为管控用 Hooks。

错法对照

错法	问题	正解
指令只说「优化一下性能」	它到处乱翻，效率极低	给出类名/方法名/日志等精确线索
让它「把整个项目都读一遍」	上下文爆炸，费用与延迟齐飞	按任务指明相关模块与文件
用 Bash cat/echo 让它改文件	绕过 diff 展示与编辑权限管控	文件修改走 Edit/Write
看到一次失败就打断重试	打乱它正常的换路机制	观察两三轮，确有死循环再干预
研究类任务不关联网工具	无关信息混入，耗时且失焦	--disallowedTools 或 deny 收紧

卡点急救

1. 总是找不到文件：核对工作目录（启动位置）；用 @ 直接给路径；确认文件没被 .gitignore 忽略。
2. 编辑老是匹配失败：多为文件在会话外被改动过，让它重新 Read 再 Edit；检查行尾符/编码差异。
3. 工具调用反复失败不收敛：Esc 打断，总结已有信息（贴报错、给线索），重设目标再继续；连续失败说明任务拆分不合理。

面试常问

• 描述 agent 的工具调用机制。 模型输出结构化的工具调用请求（名称+参数）→ 运行时执行（经过权限检查与 Hook 卡口）→ 结果回传上下文 → 模型基于结果继续推理，形成「思考-行动-观察」循环。工具集决定了 agent 的能力边界。

• 为什么 Edit 设计成「先读后改」？ 基于内容精确匹配的替换天然要求最新快照，防止盲改与并发覆盖；同时强制读取保证模型对上下文有真实感知，是「最小惊讶原则」在工具层的落实。

• 如何为一个 agent 项目设计工具集？ 原则：高内聚（一个工具一件事）、结构化输入输出、失败信息可行动（错误要能指导下一步）、权限粒度可配置、数量克制（工具越多选择错误率越高）。类比 API 设计，工具就是模型的 API。

自测三问

1. Glob 和 Grep 的分工是什么？各举一个使用场景。
2. Edit 前必须 Read 的设计解决了什么问题？
3. 有哪两条正路可以扩展 Claude Code 的工具能力？

小结一句话

内置工具是模型的手脚：感知靠 Read/Glob/Grep，行动靠 Edit/Write/Bash，编排靠 Task/TodoWrite；懂工具分工，才能既让它跑得快，又用权限和 Hooks 管得住。

延伸

• 常见工作流官方文档
• 下一课：综合练习——用一个真实项目把 12 节课的技能串成完整工作流，完成从学习到实战的闭环。