Tool Selection Guide

AI Agent往往难以针对给定任务选择最优工具，进而导致工作流程效率低下。常见的反模式包括：

• 当Edit工具更为适用时却选用Write
• 为简单探索任务启动子Agent
• 代码变更后跳过构建验证
• 当并行探索速度更快时，仍采用串行方式执行

这些低效问题会在长会话中不断累积，最终造成Token浪费、任务完成延迟以及用户需进行更多修正。

我们基于对88个真实Claude对话会话的分析，归纳出了数据驱动的工具选择模式。通过将任务类型与最优工具匹配，Agent可以遵循经过验证的工作流。

基于实际使用数据的工具偏好模式：

| 任务类型 | 推荐工具 | 依据 | |----------------|------------------------|----------------------------------------| | 代码库探索 | Read → Grep → Glob | 所有项目中均存在一致模式 | | 代码修改 | Edit（而非Write） | nibzard-web中Edit与Write的使用比例为3.4:1 | | 新文件创建 | Write | 符合工具适用场景 | | 构建验证 | Bash | 在nibzard-web中使用324次，在patterns中使用276次 | | 研究任务委派 | Task（需明确主题） | 跨会话调用48次 |

核心选择标准：

1. 探索类任务（发现代码结构、查找模式）：

   • 先用Glob发现文件
   • 用Grep进行内容搜索（支持语法感知时启用该特性）
   • 用Read针对性检查目标文件

2. 代码修改类任务（修改已有代码）：

   • 优先使用Edit而非Write——保留现有上下文和注释
   • 仅在创建全新文件或完全重写时使用Write（需获得许可）
   • 编辑前必须先Read文件

3. 验证类任务（测试、构建、检查）：

   • 用Bash执行构建命令、测试运行和代码检查
   • 每次执行Edit/Write操作之后都要进行验证
   • 继续下一步前先检查是否存在错误/警告

4. 委派类任务（并行探索）：

   • 使用Task工具委派给子Agent
   • 必须提供明确的任务主题（不能为空字符串）
   • 独立探索任务优先采用并行而非串行方式

flowchart TD
    A[任务类型？] --> B[探索类]
    A --> C[修改类]
    A --> D[验证类]
    A --> E[委派类]

    B --> B1[用Glob检索文件]
    B1 --> B2[用Grep检索内容]
    B2 --> B3[用Read查看目标文件]

    C --> C1[先Read文件]
    C1 --> C2{是否为新文件？}
    C2 -->|是| C3[用Write创建]
    C2 -->|否| C4[用Edit修改]

    D --> D1[用Bash执行构建/测试]
    D1 --> D2[是否存在错误？]
    D2 -->|是| D3[修复后重试]
    D2 -->|否| D4[继续执行]

    E --> E1[明确任务主题]
    E1 --> E2[是否为独立任务？]
    E2 -->|是| E3[并行委派]
    E2 -->|否| E4[串行委派]

    style B fill:#e1f5ff
    style C fill:#fff4e1
    style D fill:#e8f5e9
    style E fill:#f3e5f5

使用任何工具前，先在脑海中对任务进行分类： -「我是否在探索新内容？」→ 探索工具集 -「我是否在修改内容？」→ 编辑（需先执行读取操作） -「我是否在验证内容？」→ Bash 验证 -「我是否在委派任务？」→ 带有明确主题的 Task

反模式规避：

• 请勿使用Write进行修改操作（请使用Edit）
• 执行Edit前请勿跳过Read操作
• 未通过Bash验证前，请勿宣称工作完成
• 调用Task时请勿使用空任务主题
• 当可并行执行时，请勿采用串行方式进行探索

优点：

• 基于88个真实会话的数据驱动
• 减少token浪费与用户修正操作
• 加快工作流完成速度
• 具备工具选择的清晰心智模型
• 规避常见反模式

缺点：

• 依赖工具可用性（例如，需借助Bash进行验证）
• 并行委派会增加成本
• 针对简单的一次性任务，可能表现得更慢
• 需要具备始终遵循模式的自律性