很多人以为Claude Code的能耐来自AI有多聪明。

这个理解偏了一半。

把Claude Code的工具全部拿掉，剩下的是什么？是一个能说会道但什么都干不了的语言模型——你问它"帮我修这个Bug"，它能说"这里可能是第47行类型判断有问题"，但改不了，测不了，提交不了。说得再准，活还是得你自己做。

工具才是Claude Code能干活的原因。不是AI有多聪明，是工具让AI的"想法"有了触碰现实的手。

Agent Loop每一回合都在做一件事：选一个工具，调用它，拿结果。工具是Loop从"思考"变成"行动"的唯一通道。工具集合有多大，Claude Code能做的事就有多大。

理解工具，是真正用好Claude Code最关键的一步。

一、二十多个工具，日常用的就这几个

Claude Code内置了二十多个工具，听起来很多，但按频率来分，日常真正高频使用的只有七个：Read、Glob、Grep、Edit、Write、Bash、Task。

其他的——NotebookRead是给Jupyter用的，LSP是语言服务器集成，WebSearch和WebFetch是网络工具——在对应场景下有用，平时不常见。

抓住这七个，理解了它们，Claude Code的行为就没有黑盒了。

二、读族三件套：Read、Glob、Grep

这三个工具都是"读"，但读的东西不一样，替换不了。

Read：读文件内容。

给它一个绝对路径，它返回完整的文件内容，并且附上行号。行号不是装饰。后面讲到Edit的时候，你会看到行号至关重要——Edit需要知道从第几行到第几行，才能精确替换。这也是为什么官方系统提示明确要求Claude用Read读文件，而不是用Bash跑cat：cat只给你内容，没有行号，Edit用不了。

它还能读图片、PDF、Jupyter Notebook，不只是文本文件。

Glob：找文件名。

给它一个模式，它返回匹配的文件路径列表。**/*.py找所有Python文件，src/**/*.tsx找src目录下所有React组件，**/test_*.py找所有测试文件。结果按最近修改时间排序——这个排序不是随意设计的，调试的时候你最关心的往往是最近改动过的文件，这个顺序刚好对。

Glob找的是文件名，不看文件内容。

Grep：找内容。

给它一个正则表达式，它在所有文件里搜符合模式的行，返回匹配的文件路径和行内容。底层用的是ripgrep，比系统自带的grep快很多，支持完整正则语法。Grep找的是文件内容，不关心文件名叫什么。

三个工具各司其职：Glob是找文件，Grep是找内容，Read是读内容。"在哪里"、"有没有"、"是什么"，三个不同的问题，三个不同的工具。搞混了，Claude就会走弯路——Glob找不到内容，Grep找不到不知道名字的文件，用Bash跑cat读文件会丢行号。

这三个工具，是Claude Code"看"代码库的三双眼睛，缺一不可。

三、改文件：Edit和Write，差一个字，差在要不要命

改文件有两个工具，很多人分不清，但区别非常重要。

Edit：精确替换。

给它文件路径、要替换的旧字符串、替换成什么新字符串，它只改那一处，其他地方原封不动。Edit是手术刀——切除目标组织，周围的东西不碰。

使用Edit有一个强制前提：Claude必须先用Read读过这个文件，才能用Edit改它。这不是建议，是系统层面的限制。Read给了行号，Edit靠行号定位要改哪里，没读过的文件没有这个坐标，Edit无法精确操作。

Write：整体写入。

给它文件路径和完整内容，它把文件整个覆盖掉。Write是推土机——不管原来有什么，全部抹平，换成你给的内容。

Write用于创建新文件，或者需要完全重写一个文件的时候。用Write改一个已经存在的大文件，是危险操作——一旦生成内容出了问题，原来的内容就没了。

一句话区分：Edit是改，Write是覆盖。改找得回来，覆盖找不回来。

还有一个MultiEdit，是Edit的批量版，可以在一次工具调用里对同一个文件做多处修改，效率更高。Claude Code处理大范围重构的时候，通常会用MultiEdit而不是多次单独的Edit。

改文件用Edit，创建文件用Write，这是最不该搞混的两件事。

四、Bash：万能钥匙，也是最需要小心的工具

Bash是Claude Code里权力最大的工具，没有之一。

它能跑任何终端命令。pytest tests/，跑了。git commit -m "fix auth bug"，提交了。docker-compose up -d，服务起来了。npm run build，构建了。只要是你在终端里能做的事，Bash都能做。

正因为如此，Bash也是权限管控最严的工具。在默认模式下，Claude调用Bash之前会向你请求确认，你看到命令，决定是否允许。只有你明确批准了，它才跑。

有几个Bash的使用细节值得知道。

第一，Bash和读族工具不要混用。官方系统提示明确说：能用Read就不用cat，能用Grep就不用shell的grep，能用Glob就不用find。原因是：专用工具有优化的权限控制和更好的输出格式，Bash里的同类命令绕开了这些机制，可能带来意外风险。

第二，独立的Bash命令可以并行。如果Claude需要同时知道git status的结果和npm test的结果，它可以在一次回合里同时发起这两个Bash调用，而不是顺序等待。这让并行操作成为可能，速度快得多。

第三，每个Bash命令在独立进程里跑。cd换了目录，下一个Bash命令不会自动保留在那个目录，除非那个目录在项目目录之内。这是Bash持久性的一个细节，不了解可能会碰到奇怪的路径问题。

Bash是Claude Code触碰外部世界最直接的通道——也是最可能搞出大事的地方。理解它有多强，也就知道为什么权限控制那么重要。

五、Task：派出去的分身

Task工具让Claude Code能够派出子Agent去完成任务。

调用Task，相当于启动一个全新的Agent Loop，这个子Agent有自己独立的上下文，有自己的工具集，跑完之后把结果返回给主Agent。

为什么要用子Agent而不是直接在主线程里做？两个原因。

第一，上下文隔离。复杂的探索任务会产生大量中间数据，全塞进主线程的上下文里，主线程的精力就被分散了。派子Agent去探索，探索过程中的噪音留在子Agent那里，主线程只接收最终的干净结果。

第二，并行加速。需要同时分析三个模块的代码，可以同时派出三个子Agent，各跑各的，结果同步回来。顺序执行变并行执行，时间缩短。

子Agent的工具集可以限制。如果你只想让它读代码不让它改，可以在调用Task时只给它Read、Glob、Grep，把Bash和Edit从它的工具列表里排除掉。这在安全敏感的场景里很有用。

六、一次工具调用，背后发生了什么

Claude决定调用一个工具，到结果返回，中间经过了好几层：

第一步，参数验证。Claude生成工具调用的名称和参数，系统检查参数格式是否正确，路径是否合法，必填字段是否都有。

第二步，权限判断。这个工具的这次调用，属于哪个权限级别？Read、Glob、Grep是只读操作，自动放行，不用问你。Bash和Write是变更操作，在默认模式下需要你确认。

第三步，Pre-hook触发。如果你配置了PreToolUse钩子，在这一步触发。钩子可以记录日志、拒绝调用、修改参数。这就是上一篇说的"铁律"的执行点。

第四步，工具执行。真正的操作发生：文件被读，代码被改，命令被跑。

第五步，Post-hook触发。PostToolUse钩子在这里触发。比如，每次Edit之后自动跑linter检查格式。

第六步，结果返回。工具的执行结果注入回上下文，Claude看到结果，进入下一轮"想"。

这个流程解释了很多事情：为什么某些操作会弹权限确认，为什么Hooks能在不改变AI行为的情况下强制执行规则，为什么工具调用链能被观察、被拦截、被扩展。

工具不只是命令，工具调用是一个有完整生命周期的事件。

七、实战：亲眼看一次工具链

打开一个你的项目，进入Claude Code，给它这个任务：

在这个项目里，找出所有定义了API路由的文件，统计每个文件里有几个路由，汇总成一张表格，写入 API_INVENTORY.md。

然后退后，只是看。

你会看到它先用Glob找所有Python或TypeScript文件，然后用Grep在这些文件里搜索路由定义的关键词（@app.route、router.get、@Get()之类），接着用Read逐个读出匹配的文件，计数路由数量，最后用Write把汇总表格写入新文件。

整个过程可能六七次工具调用，可能更多。你在终端里可以看到每次调用的工具名、参数和结果，一条一条列出来。没有黑盒，没有神秘，就是工具一个接一个地被调用，结果一条接一条地被处理。

理解了这个过程，你就知道为什么有些任务能完成——它有对应的工具。也知道为什么有些任务它会卡住——没有对应的工具，或者没有权限用。

Claude Code能干什么，取决于工具集合能覆盖什么。边界在工具那里，不在AI那里。

这一篇到这里

工具讲完了，但工具的边界，就是Claude Code内置能力的边界。

内置工具能做的，是文件系统和终端命令。数据库里的数据、第三方API、团队内部系统——这些东西，内置工具够不着。

够着它们的，是MCP协议。下一篇讲MCP——给Claude Code插上"外设"，让它连接内置工具之外的一切。

工具完整参考文档：docs.anthropic.com/claude-code/tools-reference。工具的权限配置方法在 settings.json 的 permissions 字段，使用 /permissions 命令可以查看当前会话的权限状态。