Claude Code 的工具层不等于一张工具名称清单。对使用者更有价值的问题是：一次任务如何从“理解代码”走到“验证结果”，哪些能力由 Claude Code 内置，哪些来自外部扩展，权限又在哪一层生效。
本文不逐项复述工具参数，而是建立一套选择模型。内置工具和命令会随版本、平台、套餐及配置变化，当前会话的实际能力应以 /context、/permissions、/mcp 和官方工具参考为准。
一、先把四个层次分开
Claude Code 周围有四类经常被统称为“工具”的能力：
| 层次 | 谁在使用 | 作用 | 例子 |
|---|---|---|---|
| 交互入口 | 使用者 | 启动或控制会话 | CLI 参数、/compact、/diff |
| 内置工具 | Claude | 读取、搜索、编辑和执行 | Read、Grep、Edit、Bash |
| 编排能力 | Claude 或使用者 | 拆分、隔离和跟踪任务 | 子 Agent、Task、后台会话 |
| 扩展能力 | Claude、外部系统 | 增加知识、工具或事件来源 | Skill、MCP、Hook、插件、Channel |
CLI 参数和 / 命令不是模型工具。它们控制会话本身；Read、Edit、Bash 等工具才是 Claude 在推理循环中选择调用的执行接口。
Skill 和 MCP 也不能混为一谈。Skill 提供指令、知识和工作流，通常仍然使用现有工具；MCP 服务器会暴露新的工具、资源或提示，让 Claude 能访问外部系统。插件则是分发容器，可以同时携带 Skill、子 Agent、Hook、MCP 和其他组件。
这张图的关键不是工具数量，而是闭环：每次工具调用都应产生新的证据，Claude 再据此决定下一步，直到满足验收条件。
二、内置工具围绕一个基本循环工作
多数编码任务都可以还原为四步：定位、理解、修改、验证。
| 阶段 | 常见工具 | 需要回答的问题 |
|---|---|---|
| 定位 | Glob、Grep、代码智能工具 | 相关文件和符号在哪里 |
| 理解 | Read、LSP、只读 Shell 命令 | 当前行为、调用关系和约束是什么 |
| 修改 | Edit、Write、NotebookEdit | 如何用最小改动实现目标 |
| 验证 | Bash、Read、诊断工具 | 测试是否通过，差异是否符合预期 |
这些工具通常由 Claude 自动选择。使用者不必写“先 Grep，再 Read，再 Edit”，更有效的提示是“只修改认证模块，先说明根因，完成后运行指定测试并展示差异”。前者把决策锁死在操作步骤，后者给出目标和边界，同时保留 Claude 调整路径的空间。
2.1 读取和搜索的选择
文件名或目录模式明确时使用文件匹配；需要定位字符串、错误码或配置项时使用文本搜索；已经知道目标文件时直接读取。大型强类型仓库如果启用了代码智能，可以通过定义、引用和诊断理解符号关系，减少纯文本搜索的误命中。
读取本身不会修改文件，但读到的内容不一定可信。仓库、网页、Issue 和 MCP 返回值都可能包含看似指令的文本。它们应该被当作待分析的数据，不能自动覆盖用户目标和项目规则。
2.2 Edit、Write 和 Bash 的边界
Edit 适合局部修改，Write 适合新建文件或明确的整体重写。Shell 当然也能通过脚本改文件，但这会让差异更难审查，并可能绕过文件工具的针对性权限规则。常规代码修改优先使用编辑工具，批量机械变换才考虑仓库已有的格式化器、代码生成器或迁移脚本。
Bash 的能力边界接近当前用户的终端能力，可以运行测试，也可以删除文件、读取凭据或访问网络。因此“允许 Shell”不是一个足够精细的授权，应进一步限制命令模式，并配合沙箱和外部运行环境控制影响范围。
2.3 验证不是最后一句话
工具调用成功只表示命令执行完成，不表示任务正确。验证至少包含三类证据：
- 静态证据：差异只落在约定范围，生成物和依赖锁文件没有意外变化；
- 动态证据：相关测试、类型检查或构建实际运行并成功退出；
- 语义证据：实现满足用户场景，而不只是通过现有测试。
如果无法运行某项检查，最终说明必须明确写出原因和剩余风险。
三、工具可见、允许执行和环境隔离是三件事
Claude 能否完成一次操作，取决于三个独立问题：
- 工具是否可见：会话、子 Agent 或插件有没有提供该工具。
- 调用是否获准：权限规则和当前模式是否允许这次参数组合。
- 环境是否允许：操作系统权限、沙箱、网络策略和凭据是否放行。
--tools 可以限制会话可见的内置工具。permissions.allow、ask、deny 决定调用是否需要批准，其中拒绝规则优先。沙箱和容器则在更外层限制文件系统与网络，即使模型获得调用权限，也不应越过环境边界。
以下设置用于预批准只读 Git 命令，同时拒绝敏感文件和外发网络请求：
{ "permissions": { "allow": [ "Bash(git status)", "Bash(git diff *)" ], "deny": [ "Read(./.env)", "Bash(curl *)" ] }}规则应匹配真实命令形态，并通过 /permissions 检查最终来源。团队规则适合放在项目设置中，个人路径和临时例外留在本地设置。
3.1 权限模式解决什么
权限模式控制“遇到需要批准的动作时怎么办”：
| 模式 | 核心行为 | 常见用途 |
|---|---|---|
default | 按标准流程询问 | 日常交互 |
acceptEdits | 自动接受工作区内的文件编辑 | 范围明确的本地开发 |
plan | 只探索和规划 | 大改动或方案未定 |
auto | 用安全分类器评估操作是否符合请求 | 支持该模式的交互环境 |
dontAsk | 未预批准的调用直接拒绝 | 无人值守、失败关闭 |
bypassPermissions | 跳过权限确认 | 外部已充分隔离的临时环境 |
bypassPermissions 不是“更高效的 acceptEdits”，而是撤掉一层确认。它不能替代容器、虚拟机、网络白名单和最小凭据。
四、长任务需要状态管理，不只需要更多工具
简单任务可以在一个上下文里完成。任务变长后，真正的瓶颈通常是状态：哪些步骤已经完成、什么在等待、哪些工作可以并行、失败后从哪里恢复。
Claude Code 的任务工具用于记录标题、状态和依赖，/tasks 则提供面向使用者的查看入口。任务工具的可用性可能受模型、提供商和会话配置影响，因此项目文档不宜依赖某个内部工具名；把验收条件和阶段产物写进任务描述，才是可迁移的做法。
对于延迟发生的事情，先区分三种需求：
| 需求 | 合适的机制 | 例子 |
|---|---|---|
| 等一次命令结束 | 后台 Shell 或后台会话 | 构建、完整测试套件 |
| 持续关注输出或事件 | Monitor、Hook 或外部监控 | 日志异常、文件变化 |
| 在当前会话内定时触发提示 | Scheduled tasks | 一小时后再次检查部署状态 |
当前会话的定时任务不是生产调度系统。它适合辅助交互，不应替代 cron 服务、CI 调度器或具备持久化、重试和告警能力的工作流平台。
五、子 Agent 解决上下文隔离
子 Agent 通过 Agent 工具在独立上下文中完成旁支任务，父会话通常只接收最终结果。它的主要价值不是角色扮演，而是隔离大量中间信息：搜索日志、文档摘录和独立审查不必全部进入主上下文。
适合委派的任务通常满足至少一个条件：
- 工作可以独立完成，输入和交付物清楚；
- 中间材料很多，但主会话只需要结论与证据；
- 需要与实现者分离的测试、审查或事实核查；
- 多个任务互不修改同一批文件，可以并行推进。
强依赖、共享状态多或会同时修改同一文件的工作，不适合直接并行。子 Agent 也不会自动解决合并冲突；涉及写入时，应明确文件所有权，必要时使用独立 worktree。
5.1 四种并行方式的区别
| 方式 | 谁负责协调 | 上下文关系 | 适用场景 |
|---|---|---|---|
| 子 Agent | 主会话中的 Claude | 独立上下文，返回总结 | 一次旁支研究或独立实现 |
| Agent View | 使用者 | 多个独立后台会话 | 几个互不依赖的任务 |
| Agent Teams | 负责人 Agent | 多会话共享任务并通信 | 需要协作的复杂项目，仍属实验能力 |
| 动态 Workflow | 脚本控制流 | 批量启动并汇总子 Agent | 大规模审计、迁移或研究 |
并行的成本包括更多 token、重复读取、协调开销和冲突风险。拆分之前先问：每个任务能否用一句话定义输入、输出和文件边界？不能的话，先串行探索通常更快。
六、Skill、MCP、Hook、插件和 Channel 各管一层
6.1 Skill：复用“怎么做”
Skill 是按需加载的 Markdown 指令和配套资源，适合固化重复工作流、领域知识和检查清单。它不一定增加新工具，也不等于脚本；如果流程要求每次都确定执行某个检查，应由 Hook 或 CI 兜底，而不是只依赖模型记得调用 Skill。
6.2 MCP：连接“原本够不到的系统”
MCP 服务器可以提供工具、资源和提示，例如查询数据库、读取工单或操作浏览器。MCP 工具名由服务器定义，像 codegraph_* 这样的工具只会在安装了相应服务器时出现，不属于 Claude Code 的通用内置能力。
接入 MCP 时应检查四件事：服务器来源、运行位置、可访问的数据、每个工具的权限。项目级 .mcp.json 可以共享服务器定义，但不应包含密钥；凭据应通过安全存储或环境配置注入。
以下命令用于查看已配置的 MCP 服务器，重点是先确认来源和状态，再授权具体工具：
claude mcp listclaude mcp get <server-name>连接后可在会话中使用 /mcp 查看状态和完成 OAuth 认证。MCP 输出同样是不可信输入，不能把服务器返回的文本当成高优先级指令。
6.3 Hook：让事件必然触发动作
Hook 在工具调用、通知、会话结束等生命周期事件上运行脚本、请求或其他处理。它适合格式化、审计和策略阻断，因为触发条件比自然语言约定更确定。
Hook 也处在本机信任边界内。安装第三方 Hook 前要阅读实际命令，确认它不会读取敏感文件、静默上传数据或对整个仓库执行破坏性操作。
6.4 插件：把扩展打包分发
插件可以同时携带 Skill、Agent、Hook、MCP、LSP 等组件。它解决的是安装、版本和团队分发，不是新的执行层。
安装插件前，应先看清组件清单和权限需求。marketplace 提供发现和分发渠道，不代表其中每个组件都经过完整安全审计。项目级安装适合团队共享，但更需要固定来源并审查升级差异。
6.5 Channel：让外部事件进入会话
Channel 通过 MCP 服务器把聊天消息或其他事件推送到活跃会话。它解决的是事件入口，不负责定义具体业务工具。Channel 当前属于研究预览能力，适合需要长期运行、外部触发的会话；普通编码任务无需引入这层复杂度。
七、按问题选择能力
| 问题 | 优先选择 | 不要先做什么 |
|---|---|---|
| 找到代码位置 | Glob、Grep、代码智能 | 让多个 Agent 重复扫描同一仓库 |
| 修改少量文件 | Edit + 针对性测试 | 用 Shell 拼接文本覆盖文件 |
| 大改动先定方案 | 计划模式 | 先放开所有写权限 |
| 旁支研究会挤满上下文 | 子 Agent | 把全部搜索结果塞回主会话 |
| 复用一套做事方法 | Skill | 为每条知识开发 MCP 工具 |
| 连接外部系统 | MCP | 把访问令牌写入仓库配置 |
| 每次编辑后必须检查 | Hook 或 CI | 只在 CLAUDE.md 写“记得检查” |
| 分发一组扩展 | 插件 | 让每个人手动复制多个目录 |
| 外部消息触发会话 | Channel | 把 Channel 当作普通工具调用 |
这张表反映了一个原则：先选解决当前约束的最小机制。能用项目规则解决的，不必上插件；能用现有工具完成的，不必接 MCP；不能独立定义边界的任务，不适合靠更多 Agent 硬拆。
八、工具层的三个工程边界
8.1 Git 提供历史，不提供原子事务
Claude Code 的检查点、分支和 worktree 能降低恢复成本，但多文件修改并不是数据库事务。没有提交、备份或独立工作树时，外部进程造成的变更也未必能被完整回退。重要任务应在干净工作区开始，并用 Git 差异作为审查入口。
8.2 工具结果是证据，不是结论
一次搜索可能漏掉动态调用，一次测试可能没有覆盖真实场景，一个 MCP 查询也可能返回过期数据。Claude 的判断应回连到文件、命令输出和外部来源；证据不足时，结论必须保留条件。
8.3 最小权限应与可验证性交叉设计
权限太紧会让任务停在半途，权限太宽会放大误操作。更实用的做法是按阶段授权：探索阶段只读，实施阶段开放目标目录的编辑和必要命令，发布阶段继续由人工或 CI 控制。每次扩大权限，都要对应一个明确的任务需求和可观察结果。
九、总结
Claude Code 的工具层可以压缩成一句话：内置工具完成读、搜、改、验，编排能力管理上下文和并行，扩展能力补充知识、外部操作与事件入口，权限和环境隔离共同限制影响范围。
理解这些边界后，工具名称反而变得次要。面对新能力时，只需要判断它属于哪一层、解决什么约束、需要信任谁、结果如何验证，就能决定是否值得引入。
参考资料
- Claude Code 工具参考 - 内置工具、权限要求与可用性
- Claude Code 权限配置 - 规则、模式和目录范围
- Claude Code 扩展能力概览 - Skill、MCP、Hook、子 Agent 与插件的定位
- Claude Code 并行 Agent - 多种并行方式的选择
- Claude Code MCP 文档 - 服务器作用域、工具搜索与安全边界
- Claude Code 插件参考 - 插件组件与安装管理
- Claude Code Channels 参考 - 外部事件接入与研究预览限制
支持与分享
如果这篇文章对你有帮助，欢迎支持作者或分享给更多人
部分信息可能已经过时