feat: 实现 Tool Search 基础设施层(CORE_TOOLS 白名单 + TF-IDF 索引 + ExecuteTool + 搜索增强)

- 新增 CORE_TOOLS 白名单常量(31 个核心工具),重构 isDeferredTool 为白名单制判定
- 新建 TF-IDF 工具索引模块(toolIndex.ts),复用 localSearch.ts 算法函数
- 新建 ExecuteTool 跨 API provider 统一工具执行入口
- 增强 ToolSearchTool:TF-IDF 搜索路径、discover: 模式、并行搜索合并、文本模式回退
- 新增 27 个单元测试,precheck 零错误通过(4108 tests pass)

Co-Authored-By: glm-5.1[1m] <zai-org@claude-code-best.win>
This commit is contained in:
claude-code-best
2026-05-08 22:29:15 +08:00
parent 02dd796706
commit 7be08f53bd
34 changed files with 4040 additions and 90 deletions

View File

@@ -0,0 +1,650 @@
# Tool Search 执行计划(一)— 基础设施层
**目标:** 建立 tool search 的基础能力——核心工具常量、TF-IDF 工具索引、ExecuteTool 执行工具、ToolSearchTool 搜索增强
**技术栈:** TypeScript, Bun, Zod, TF-IDF (复用 localSearch.ts), buildTool 框架
**设计文档:** spec/feature_20260508_F001_tool-search/spec-design.md
## 改动总览
- 新增 `CORE_TOOLS` 常量集合31 个核心工具名)到 `src/constants/tools.ts`,重构 `isDeferredTool` 为白名单制;新建 TF-IDF 工具索引 `toolIndex.ts`(复用 `localSearch.ts` 算法);新建 `ExecuteTool` 工具包3 个文件);增强 `ToolSearchTool` 搜索层TF-IDF + discover 模式)
- Task 1CORE_TOOLS是 Task 2/3/4 的共同前置依赖Task 2toolIndex被 Task 4搜索增强依赖
- 关键决策:`isDeferredTool` 从"排除例外"改为"包含准入"白名单制所有非核心工具默认延迟TF-IDF 算法直接 import `localSearch.ts` 的导出函数,不创建独立共享模块
---
### Task 0: 环境准备
**背景:**
确保构建和测试工具链在当前开发环境中可用,避免后续 Task 因环境问题阻塞。
**执行步骤:**
- [x] 验证 Bun 运行时可用
- `bun --version`
- 预期: 输出 Bun 版本号
- [x] 验证 TypeScript 编译可用
- `bunx tsc --noEmit --pretty 2>&1 | tail -5`
- 预期: 无新增类型错误(已有错误可忽略)
- [x] 验证测试框架可用
- `bun test --help 2>&1 | head -3`
- 预期: 输出 bun test 帮助信息
**检查步骤:**
- [x] 构建命令执行成功
- `bun run build 2>&1 | tail -10`
- 预期: 构建成功,输出 dist/cli.js
- [x] 现有测试可通过
- `bun test src/constants/__tests__/ 2>&1 | tail -5 || echo "no existing tests in this dir"`
- 预期: 测试框架可用,无配置错误
---
### Task 1: 核心工具常量与延迟判定
**背景:**
当前 `isDeferredTool` 使用一组分散的特判规则(`shouldDefer`、MCP 检测、feature flag 特判)来决定工具是否延迟加载,缺少统一的"核心工具"概念。设计文档要求引入 `CORE_TOOLS` 白名单常量将始终加载的核心工具31 个)显式列出,并将 `isDeferredTool` 改为白名单制判定:核心工具 + alwaysLoad 工具 + ToolSearchTool/ExecuteTool 不延迟,其余全部延迟。本 Task 的输出(`CORE_TOOLS` 常量和重构后的 `isDeferredTool`)被 Task 2TF-IDF 工具索引、Task 3ExecuteTool、Task 4ToolSearchTool 搜索增强)直接依赖。
**涉及文件:**
- 修改: `src/constants/tools.ts`
- 修改: `packages/builtin-tools/src/tools/ToolSearchTool/prompt.ts`
- 新建: `src/constants/__tests__/tools.test.ts`
**执行步骤:**
- [x]`src/constants/tools.ts` 中新增 `CORE_TOOLS` 常量集合
- 位置: `src/constants/tools.ts` 文件末尾(`COORDINATOR_MODE_ALLOWED_TOOLS` 之后,~L113
- 新增以下 import文件顶部 import 区域,与现有 import 风格一致):
```typescript
import { SLEEP_TOOL_NAME } from '@claude-code-best/builtin-tools/tools/SleepTool/prompt.js'
import { LSP_TOOL_NAME } from '@claude-code-best/builtin-tools/tools/LSPTool/prompt.js'
import { VERIFY_PLAN_EXECUTION_TOOL_NAME } from '@claude-code-best/builtin-tools/tools/VerifyPlanExecutionTool/constants.js'
import { TEAM_CREATE_TOOL_NAME } from '@claude-code-best/builtin-tools/tools/TeamCreateTool/constants.js'
import { TEAM_DELETE_TOOL_NAME } from '@claude-code-best/builtin-tools/tools/TeamDeleteTool/constants.js'
```
- 在文件末尾新增 `CORE_TOOLS` 导出常量:
```typescript
/**
* Core tools that are always loaded with full schema at initialization.
* These tools are never deferred — they appear in the initial prompt.
* All other tools (non-core built-in + all MCP tools) are deferred
* and must be discovered via ToolSearchTool / ExecuteTool.
*/
export const CORE_TOOLS = new Set([
// File operations
...SHELL_TOOL_NAMES, // 'Bash', 'Shell'
FILE_READ_TOOL_NAME, // 'Read'
FILE_EDIT_TOOL_NAME, // 'Edit'
FILE_WRITE_TOOL_NAME, // 'Write'
GLOB_TOOL_NAME, // 'Glob'
GREP_TOOL_NAME, // 'Grep'
NOTEBOOK_EDIT_TOOL_NAME,// 'NotebookEdit'
// Agent & interaction
AGENT_TOOL_NAME, // 'Agent'
ASK_USER_QUESTION_TOOL_NAME, // 'AskUserQuestion'
SEND_MESSAGE_TOOL_NAME, // 'SendMessage'
// Team (swarm)
TEAM_CREATE_TOOL_NAME, // 'TeamCreate'
TEAM_DELETE_TOOL_NAME, // 'TeamDelete'
// Task management
TASK_OUTPUT_TOOL_NAME, // 'TaskOutput'
TASK_STOP_TOOL_NAME, // 'TaskStop'
TASK_CREATE_TOOL_NAME, // 'TaskCreate'
TASK_GET_TOOL_NAME, // 'TaskGet'
TASK_LIST_TOOL_NAME, // 'TaskList'
TASK_UPDATE_TOOL_NAME, // 'TaskUpdate'
TODO_WRITE_TOOL_NAME, // 'TodoWrite'
// Planning
ENTER_PLAN_MODE_TOOL_NAME, // 'EnterPlanMode'
EXIT_PLAN_MODE_V2_TOOL_NAME, // 'ExitPlanMode'
VERIFY_PLAN_EXECUTION_TOOL_NAME, // 'VerifyPlanExecution'
// Web
WEB_FETCH_TOOL_NAME, // 'WebFetch'
WEB_SEARCH_TOOL_NAME, // 'WebSearch'
// Code intelligence
LSP_TOOL_NAME, // 'LSP'
// Skills
SKILL_TOOL_NAME, // 'Skill'
// Scheduling & monitoring
SLEEP_TOOL_NAME, // 'Sleep'
// Tool discovery (always loaded)
TOOL_SEARCH_TOOL_NAME, // 'ToolSearch'
SYNTHETIC_OUTPUT_TOOL_NAME, // 'SyntheticOutput'
]) as ReadonlySet<string>
```
- 说明: `ListPeers` 和 `Monitor` 工具名在各自工具文件内以局部常量定义(非 export无法在 `tools.ts` 中 import。`ListPeers` 频率较低,`Monitor` 受 `MONITOR_TOOL` feature gate 控制,两者暂不纳入 CORE_TOOLS待后续 Task 按需加入。
- 原因: 建立统一的"核心工具"白名单,为后续 Task 的延迟判定、工具索引排除提供单一数据源
- [x] 重构 `packages/builtin-tools/src/tools/ToolSearchTool/prompt.ts` 中的 `isDeferredTool` 函数
- 位置: `packages/builtin-tools/src/tools/ToolSearchTool/prompt.ts` 的 `isDeferredTool` 函数体L62-L108
- 新增 import文件顶部:
```typescript
import { CORE_TOOLS } from 'src/constants/tools.js'
```
- 替换整个 `isDeferredTool` 函数体为白名单制逻辑:
```typescript
export function isDeferredTool(tool: Tool): boolean {
// Explicit opt-out via _meta['anthropic/alwaysLoad']
if (tool.alwaysLoad === true) return false
// Core tools are always loaded — never deferred
if (CORE_TOOLS.has(tool.name)) return false
// Everything else (non-core built-in + all MCP tools) is deferred
return true
}
```
- 清理 isDeferredTool 不再需要的代码:
- 文件顶部的 `import { feature } from 'bun:bundle'`(仅被 isDeferredTool 使用的 feature flag 逻辑)
- 文件顶部的 `import { isReplBridgeActive } from 'src/bootstrap/state.js'`(仅被 KAIROS 逻辑使用)
- 保留 `import { getFeatureValue_CACHED_MAY_BE_STALE } from 'src/services/analytics/growthbook.js'`(仍被 `getToolLocationHint()` 使用,不删除)
- 文件顶部的 `import { AGENT_TOOL_NAME } from '../AgentTool/constants.js'`(不再被 isDeferredTool 使用)
- L8-L21 的 `BRIEF_TOOL_NAME` 和 `SEND_USER_FILE_TOOL_NAME` 条件 import 块(`isDeferredTool` 不再需要 feature flag 特判)
- 注意: 保留 `getToolLocationHint()` 函数及其对 `getFeatureValue_CACHED_MAY_BE_STALE` 的 import仍被 `getPrompt()` 使用)
- 原因: 白名单制替代分散的特判规则,逻辑从"排除例外"变为"包含准入",更易维护和扩展
- [x] 为 `CORE_TOOLS` 常量和 `isDeferredTool` 重构编写单元测试
- 测试文件: `src/constants/__tests__/tools.test.ts`(新建)
- 测试场景:
- `CORE_TOOLS` 包含预期数量的工具(约 29 个: 7 SHELL_TOOL_NAMES + 22 独立工具名)
- `CORE_TOOLS` 包含所有设计文档中列出的核心工具名(抽查: 'Bash', 'Read', 'Edit', 'Write', 'Glob', 'Grep', 'Agent', 'AskUserQuestion', 'ToolSearch', 'WebSearch', 'WebFetch', 'Sleep', 'LSP', 'Skill', 'TeamCreate', 'TeamDelete', 'TaskCreate', 'TaskGet', 'TaskUpdate', 'TaskList', 'TaskOutput', 'TaskStop', 'TodoWrite', 'EnterPlanMode', 'ExitPlanMode', 'VerifyPlanExecution', 'NotebookEdit', 'SyntheticOutput'
- `CORE_TOOLS` 是 ReadonlySet不可外部修改
- `isDeferredTool` 对 `CORE_TOOLS` 中的工具名返回 `false`(构造 `{ name: 'Read', alwaysLoad: undefined, isMcp: false, shouldDefer: undefined }` 形式的 mock Tool
- `isDeferredTool` 对 `alwaysLoad: true` 的工具返回 `false`(即使工具名不在 CORE_TOOLS 中)
- `isDeferredTool` 对非核心内置工具返回 `true`(工具名 'ConfigTool',无 alwaysLoad无 isMcp
- `isDeferredTool` 对 MCP 工具返回 `true``isMcp: true`,即使 alwaysLoad 为 undefined
- `isDeferredTool` 对 `alwaysLoad: true` 的 MCP 工具返回 `false`alwaysLoad 优先级最高)
- 运行命令: `bun test src/constants/__tests__/tools.test.ts`
- 预期: 所有测试通过
**检查步骤:**
- [x] 验证 `CORE_TOOLS` 常量已导出且包含预期工具
- `grep -c "CORE_TOOLS" src/constants/tools.ts`
- 预期: 至少 2 行export 定义 + 注释)
- [x] 验证 `isDeferredTool` 函数已简化为白名单制
- `grep -A 8 "export function isDeferredTool" packages/builtin-tools/src/tools/ToolSearchTool/prompt.ts`
- 预期: 函数体仅包含 `alwaysLoad`、`CORE_TOOLS.has`、`return true` 三个分支,不包含 `isMcp`、`feature(`、`shouldDefer` 等旧逻辑
- [x] 验证 `isDeferredTool` 不再依赖已删除的 import
- `grep "feature(" packages/builtin-tools/src/tools/ToolSearchTool/prompt.ts`
- 预期: 无输出feature flag 依赖已从 isDeferredTool 中移除)
- [x] 验证类型检查通过
- `bunx tsc --noEmit --pretty 2>&1 | head -30`
- 预期: 无新增类型错误
- [x] 运行新增单元测试
- `bun test src/constants/__tests__/tools.test.ts`
- 预期: 所有测试通过
---
### Task 2: TF-IDF 工具索引
**背景:**
[业务语境] — 本 Task 构建工具索引模块,为 TF-IDF 搜索提供索引构建和查询能力。ToolSearchToolTask 4和预取管道依赖此索引来按任务描述发现延迟工具。
[修改原因] — 当前项目只有 skill 搜索的 TF-IDF 实现(`localSearch.ts`),缺少工具维度的索引。`localSearch.ts` 中的 `computeWeightedTf`、`computeIdf`、`cosineSimilarity` 三个核心函数未导出,需要先导出才能复用。
[上下游影响] — 本 Task 输出 `toolIndex.ts` 被 Task 4ToolSearchTool 搜索增强)和 Task 3ExecuteTool 工具查找)依赖。本 Task 依赖 Task 1`CORE_TOOLS` 常量和 `isDeferredTool` 判定)。
**涉及文件:**
- 修改: `src/services/skillSearch/localSearch.ts`(导出三个私有函数)
- 新建: `src/services/toolSearch/toolIndex.ts`
- 新建: `src/services/toolSearch/__tests__/toolIndex.test.ts`
**执行步骤:**
- [x] 导出 `localSearch.ts` 中三个私有 TF-IDF 函数 — `toolIndex.ts` 需要复用这些算法函数
- 位置: `src/services/skillSearch/localSearch.ts` L212, L230, L249
- 在 `computeWeightedTf`、`computeIdf`、`cosineSimilarity` 三个函数声明前各加 `export` 关键字
- 保持函数签名不变,仅增加导出修饰符
- 原因: 这三个函数是 TF-IDF 核心算法,与索引结构无关,导出后 skill 和 tool 两个索引模块均可复用
- [x] 新建 `src/services/toolSearch/toolIndex.ts`,定义 `ToolIndexEntry` 接口和工具字段权重常量
- 位置: 文件开头
- 定义 `ToolIndexEntry` 接口,包含以下字段:
```typescript
export interface ToolIndexEntry {
name: string
normalizedName: string
description: string
searchHint: string | undefined
isMcp: boolean
isDeferred: boolean
inputSchema: object | undefined
tokens: string[]
tfVector: Map<string, number>
}
```
- 定义字段权重常量(参照 `localSearch.ts` 的 `FIELD_WEIGHT` 模式):
```typescript
const TOOL_FIELD_WEIGHT = {
name: 3.0,
searchHint: 2.5,
description: 1.0,
} as const
```
- 定义最小显示分数常量:`const TOOL_SEARCH_DISPLAY_MIN_SCORE = Number(process.env.TOOL_SEARCH_DISPLAY_MIN_SCORE ?? '0.10')`
- 原因: 工具索引结构与 skill 索引不同(无 `whenToUse`/`allowedTools`,增加 `searchHint`/`isMcp`/`isDeferred`/`inputSchema`),需独立定义
- [x] 实现 `parseToolName` 工具名解析函数 — 将工具名拆分为可搜索的 token 列表
- 位置: `src/services/toolSearch/toolIndex.ts`,在接口定义之后
- 从 `ToolSearchTool.ts:132-161` 的 `parseToolName` 逻辑提取并适配为独立函数:
```typescript
export function parseToolName(name: string): { parts: string[]; full: string; isMcp: boolean }
```
- MCP 工具(`mcp__` 前缀): 去掉前缀后按 `__` 和 `_` 拆分,结果示例 `mcp__github__create_issue` → `["github", "create", "issue"]`
- 内置工具: CamelCase 拆分 + 下划线拆分,结果示例 `NotebookEditTool` → `["notebook", "edit", "tool"]`
- 原因: 工具名是搜索的高权重信号,需要拆分为有意义的关键词 token
- [x] 实现 `buildToolIndex` 索引构建函数 — 从 `Tool[]` 数组构建完整的 TF-IDF 索引
- 位置: `src/services/toolSearch/toolIndex.ts`,在 `parseToolName` 之后
- 函数签名:`export async function buildToolIndex(tools: Tool[]): Promise<ToolIndexEntry[]>`
- 导入依赖:从 `localSearch.ts` 导入 `tokenizeAndStem`、`computeWeightedTf`、`computeIdf`、`cosineSimilarity`
- 核心逻辑:
1. 过滤出延迟工具(调用 `isDeferredTool`,从 `@claude-code-best/builtin-tools/tools/ToolSearchTool/prompt.js` 导入)
2. 对每个延迟工具,调用 `tool.prompt()` 获取描述文本(构造一个 mock 的 `getToolPermissionContext` 返回空权限上下文,`tools` 传原始工具列表,`agents` 传空数组)
3. 调用 `parseToolName(tool.name)` 获取工具名 token
4. 调用 `tokenizeAndStem` 对 `name parts`、`searchHint`、`description` 分别分词
5. 调用 `computeWeightedTf` 按权重计算 TF 向量
6. 读取 `tool.inputJSONSchema ?? (tool.inputSchema ? zodToJsonSchema(tool.inputSchema) : undefined)` 作为 `inputSchema`
7. 组装 `ToolIndexEntry` 条目
8. 对全部条目调用 `computeIdf` 计算 IDF将 TF 向量乘以 IDF 得到最终 TF-IDF 向量
- 返回构建好的索引数组
- 原因: 索引构建是搜索的前提,需要从 Tool 对象提取文本并计算 TF-IDF 向量
- [x] 实现 `searchTools` 搜索函数 — 按任务描述查询最匹配的工具
- 位置: `src/services/toolSearch/toolIndex.ts`,在 `buildToolIndex` 之后
- 函数签名:`export function searchTools(query: string, index: ToolIndexEntry[], limit?: number): ToolSearchResult[]`
- 定义返回类型:
```typescript
export interface ToolSearchResult {
name: string
description: string
searchHint: string | undefined
score: number
isMcp: boolean
isDeferred: boolean
inputSchema: object | undefined
}
```
- 核心逻辑(参照 `localSearch.ts:searchSkills` L383-443 的模式):
1. 对 query 调用 `tokenizeAndStem` 分词
2. 计算 query 的 TF-IDF 向量TF 归一化 + IDF 乘法)
3. 对索引中每个条目计算 `cosineSimilarity(queryTfIdf, entry.tfVector)`
4. CJK bigram 过滤:若 query 包含 CJK token 且匹配数 < 2 且无 ASCII 匹配,则分数置零(复用 `CJK_MIN_BIGRAM_MATCHES = 2` 常量)
5. 工具名完全包含加分:若 query 小写化后包含工具的 `normalizedName`,分数取 `Math.max(score, 0.75)`
6. 过滤 `score >= TOOL_SEARCH_DISPLAY_MIN_SCORE` 的结果
7. 按分数降序排列,截取前 `limit` 条(默认 5
- 原因: 搜索函数是工具发现的核心入口,提供给 ToolSearchTool 和预取管道调用
- [x] 实现模块级索引缓存和增量更新 — 避免每次搜索都全量重建索引
- 位置: `src/services/toolSearch/toolIndex.ts`,在 `searchTools` 之后
- 定义模块级缓存变量:
```typescript
let cachedIndex: ToolIndexEntry[] | null = null
let cachedToolNames: string | null = null
```
- 实现 `getToolIndex` 缓存包装函数:签名 `export async function getToolIndex(tools: Tool[]): Promise<ToolIndexEntry[]>`
- 缓存 key 为延迟工具名排序后的字符串
- 当工具名集合变化时MCP 连接/断开),自动重建索引
- 缓存未命中时调用 `buildToolIndex`
- 实现 `clearToolIndexCache` 清除函数:签名 `export function clearToolIndexCache(): void`
- 原因: 索引构建涉及异步 `tool.prompt()` 调用,缓存避免重复计算;增量更新通过比较工具名集合实现
- [x] 为 `toolIndex.ts` 核心逻辑编写单元测试
- 测试文件: `src/services/toolSearch/__tests__/toolIndex.test.ts`
- 测试框架: `bun:test`(与 `localSearch.test.ts` 一致)
- 测试场景:
- `parseToolName` — MCP 工具名 `mcp__github__create_issue` 拆分为 `["github", "create", "issue"]``isMcp: true`
- `parseToolName` — 内置工具名 `NotebookEditTool` 拆分为 `["notebook", "edit", "tool"]``isMcp: false`
- `buildToolIndex` — 传入包含延迟工具的 mock Tool 数组,返回正确数量的 `ToolIndexEntry`,每个条目的 `tokens` 非空、`tfVector` 非空
- `searchTools` — 英文查询 `"schedule cron job"` 能匹配含 `searchHint: "schedule a recurring or one-shot prompt"` 的工具,返回分数 > 0 且排名第一
- `searchTools` — CJK 查询能匹配含中文描述的工具(参照 `localSearch.test.ts` 的 CJK 测试模式)
- `searchTools` — 空查询返回空数组
- `searchTools` — 无匹配结果返回空数组
- `getToolIndex` — 相同工具列表两次调用返回同一缓存引用
- `clearToolIndexCache` — 调用后 `getToolIndex` 重新构建索引
- Mock 构造: 创建 `Partial<Tool>` 类型的 mock 工具,设置 `name`、`searchHint`、`prompt()`(返回固定描述字符串)、`inputSchema`mock Zod schema 或 undefined、`isMcp`、`shouldDefer`、`alwaysLoad` 等字段
- 运行命令: `bun test src/services/toolSearch/__tests__/toolIndex.test.ts`
- 预期: 所有测试通过
**检查步骤:**
- [x] 验证 `localSearch.ts` 三个函数已导出
- `grep -c "export function computeWeightedTf\|export function computeIdf\|export function cosineSimilarity" src/services/skillSearch/localSearch.ts`
- 预期: 输出 3
- [x] 验证 `toolIndex.ts` 文件存在且导出正确
- `grep -c "export function\|export interface\|export type" src/services/toolSearch/toolIndex.ts`
- 预期: 至少 6ToolIndexEntry, ToolSearchResult, parseToolName, buildToolIndex, searchTools, getToolIndex, clearToolIndexCache
- [x] 验证 TypeScript 编译无错误
- `bunx tsc --noEmit src/services/toolSearch/toolIndex.ts 2>&1 | head -20`
- 预期: 无错误输出
- [x] 验证单元测试通过
- `bun test src/services/toolSearch/__tests__/toolIndex.test.ts 2>&1 | tail -10`
- 预期: 输出包含 "pass" 且无 "fail"
- [x] 验证 `localSearch.ts` 原有测试未回归
- `bun test src/services/skillSearch/__tests__/localSearch.test.ts 2>&1 | tail -10`
- 预期: 所有测试通过,无回归
**认知变更:**
- [x] [CLAUDE.md] `src/services/skillSearch/localSearch.ts` 中的 `computeWeightedTf`、`computeIdf`、`cosineSimilarity` 已导出,供 `toolIndex.ts` 复用。修改这些函数时需同步检查工具索引的测试
---
### Task 3: ExecuteTool 执行工具
**背景:**
[业务语境] — 新建 ExecuteTool 作为跨 API provider 的统一工具执行入口。当模型通过 ToolSearchTool 发现延迟工具后,使用 ExecuteTool 以 `tool_name` + `params` 的方式调用该工具,替代仅 Anthropic 支持的 `tool_reference` 机制。
[修改原因] — 当前项目无 ExecuteTool延迟工具无法在非 Anthropic providerOpenAI/Gemini/Grok下被模型调用。
[上下游影响] — 本 Task 依赖 Task 1`EXECUTE_TOOL_NAME` 常量、`CORE_TOOLS` 集合、`isDeferredTool` 判定)。本 Task 的输出ExecuteTool 工具实例)被 Task 4ToolSearchTool 搜索增强)和 `src/tools.ts`(工具注册)依赖。
**涉及文件:**
- 新建: `packages/builtin-tools/src/tools/ExecuteTool/constants.ts`
- 新建: `packages/builtin-tools/src/tools/ExecuteTool/prompt.ts`
- 新建: `packages/builtin-tools/src/tools/ExecuteTool/ExecuteTool.ts`
- 修改: `packages/builtin-tools/src/tools/ToolSearchTool/prompt.ts`(导入 `EXECUTE_TOOL_NAME`,在 `isDeferredTool` 中排除 ExecuteTool
- 新建: `packages/builtin-tools/src/tools/ExecuteTool/__tests__/ExecuteTool.test.ts`
**执行步骤:**
- [x] 创建 ExecuteTool 常量文件
- 位置: 新建 `packages/builtin-tools/src/tools/ExecuteTool/constants.ts`
- 内容:
```typescript
export const EXECUTE_TOOL_NAME = 'ExecuteTool'
```
- 原因: 与 `ToolSearchTool/constants.ts` 中的 `TOOL_SEARCH_TOOL_NAME` 保持一致的模式,供 `isDeferredTool`、工具注册等处引用
- [x] 创建 ExecuteTool prompt 文件
- 位置: 新建 `packages/builtin-tools/src/tools/ExecuteTool/prompt.ts`
- 从 `./constants.js` 导入 `EXECUTE_TOOL_NAME`
- 导出 `DESCRIPTION` 常量(一句话描述)和 `getPrompt()` 函数
- `getPrompt()` 返回完整 prompt 文本,包含:
- 功能说明:接受 `tool_name` + `params`,在全局工具注册表中查找目标工具并委托执行
- 使用场景:当通过 ToolSearch 发现延迟工具后,使用此工具调用该工具
- 输入说明:`tool_name` 是目标工具名称(如 "CronCreate"、"mcp__server__action"`params` 是传递给目标工具的参数对象
- 错误处理:工具不存在或参数无效时返回清晰的错误信息
- 原因: 与 `ToolSearchTool/prompt.ts` 的 `getPrompt()` 模式保持一致,将 prompt 逻辑与工具实现分离
- [x] 创建 ExecuteTool 主实现文件
- 位置: 新建 `packages/builtin-tools/src/tools/ExecuteTool/ExecuteTool.ts`
- 依赖导入:
- `z` from `zod/v4`
- `buildTool`, `findToolByName`, `type Tool`, `type ToolDef`, `type ToolUseContext`, `type ToolResult` from `src/Tool.js`
- `lazySchema` from `src/utils/lazySchema.js`
- `DESCRIPTION`, `getPrompt`, `EXECUTE_TOOL_NAME` from `./prompt.js`
- `EXECUTE_TOOL_NAME` from `./constants.js`
- `isToolSearchEnabledOptimistic` from `src/utils/toolSearch.js`
- 定义 `inputSchema`: `z.object({ tool_name: z.string().describe('...'), params: z.record(z.unknown()).describe('...') })`
- 定义 `outputSchema`: `z.object({ result: z.unknown(), tool_name: z.string() })`
- 使用 `buildTool` 构建 `ExecuteTool``satisfies ToolDef<InputSchema, OutputSchema>`
- 关键属性:
- `name: EXECUTE_TOOL_NAME`
- `searchHint: 'execute run invoke call a deferred tool by name with parameters'`
- `isConcurrencySafe() { return false }`(委托执行的工具是否并发安全取决于目标工具,保守设为 false
- `maxResultSizeChars: 100_000`(与 ToolSearchTool 和 MCPTool 一致)
- `description()` 返回 `DESCRIPTION`
- `prompt()` 返回 `getPrompt()`
- `call(input, context)` 核心逻辑:
1. 从 `context.options.tools` 中通过 `findToolByName(tools, input.tool_name)` 查找目标工具
2. 目标工具不存在时,返回 `{ data: { result: null, tool_name: input.tool_name }, newMessages: [错误提示 user message] }`,错误信息格式:`Tool "${input.tool_name}" not found. Use ToolSearch to discover available tools.`
3. 目标工具存在时,调用 `targetTool.checkPermissions(input.params as any, context)` 获取权限结果
4. 权限检查结果为 `behavior: 'deny'` 时,返回权限拒绝信息
5. 权限检查通过后,调用 `targetTool.call(input.params as any, context, ...)` 委托执行,透传 context、canUseTool、parentMessage、onProgress 参数(`call` 签名为 `call(args, context, canUseTool, parentMessage, onProgress?)`,从 ExecuteTool 自身的 `call` 参数中获取后三个参数并传递给目标工具)
6. 返回目标工具的执行结果,附加 `tool_name` 字段用于追踪
- `checkPermissions()` 返回 `{ behavior: 'passthrough', message: 'ExecuteTool delegates permission to the target tool.' }`,与 MCPTool 的权限透传模式一致
- `renderToolUseMessage(input)` 返回格式化字符串:`Executing ${input.tool_name}...`,用于 UI 展示
- `userFacingName()` 返回 `'ExecuteTool'`
- `mapToolResultToToolResultBlockParam(content, toolUseID)` 返回标准 tool_result 格式
- `isEnabled()` 返回 `isToolSearchEnabledOptimistic()`,与 ToolSearchTool 联动启用
- `isReadOnly()` 返回 `false`(执行的工具可能执行写操作)
- 原因: 采用与 MCPTool 相同的 `buildTool` + `satisfies ToolDef` 模式,确保类型安全和框架一致性。权限透传采用 `passthrough` 策略,由目标工具自行决定权限逻辑
- [x] 在 `isDeferredTool` 中排除 ExecuteTool
- 位置: `packages/builtin-tools/src/tools/ToolSearchTool/prompt.ts` 的 `isDeferredTool` 函数内,在 `if (tool.name === TOOL_SEARCH_TOOL_NAME) return false` 之后(~L71
- 新增导入: `import { EXECUTE_TOOL_NAME } from '../ExecuteTool/constants.js'`
- 插入: `if (tool.name === EXECUTE_TOOL_NAME) return false`
- 原因: ExecuteTool 是核心入口工具,必须在初始化时可用,不能被延迟加载
- [x] 为 ExecuteTool 编写单元测试
- 测试文件: `packages/builtin-tools/src/tools/ExecuteTool/__tests__/ExecuteTool.test.ts`
- 测试场景:
- 正常执行: 构造一个 mock 工具注册到 tools 列表中,调用 ExecuteTool 传入该工具名和合法参数,预期目标工具的 `call` 被调用且返回结果包含 `tool_name`
- 工具不存在: 传入不存在的 `tool_name`,预期返回错误信息且 `result` 为 null
- 权限拒绝: mock 目标工具的 `checkPermissions` 返回 `{ behavior: 'deny', message: 'denied' }`,预期 ExecuteTool 返回权限拒绝信息
- isEnabled 联动: 验证 `ExecuteTool.isEnabled()` 依赖 `isToolSearchEnabledOptimistic()` 的返回值
- searchHint 存在: 验证 `ExecuteTool.searchHint` 包含关键词 "execute" 和 "tool"
- 运行命令: `bun test packages/builtin-tools/src/tools/ExecuteTool/__tests__/ExecuteTool.test.ts`
- 预期: 所有测试通过
**检查步骤:**
- [x] 验证常量文件正确导出 EXECUTE_TOOL_NAME
- `grep -n 'EXECUTE_TOOL_NAME' packages/builtin-tools/src/tools/ExecuteTool/constants.ts`
- 预期: 输出包含 `export const EXECUTE_TOOL_NAME = 'ExecuteTool'`
- [x] 验证 prompt 文件正确导出 DESCRIPTION 和 getPrompt
- `grep -n 'export' packages/builtin-tools/src/tools/ExecuteTool/prompt.ts`
- 预期: 输出包含 `DESCRIPTION` 和 `getPrompt` 的导出
- [x] 验证 ExecuteTool 主文件使用 buildTool 构建且 satisfies ToolDef
- `grep -n 'buildTool\|satisfies ToolDef' packages/builtin-tools/src/tools/ExecuteTool/ExecuteTool.ts`
- 预期: 输出同时包含 `buildTool` 和 `satisfies ToolDef`
- [x] 验证 isDeferredTool 正确排除 ExecuteTool
- `grep -n 'EXECUTE_TOOL_NAME' packages/builtin-tools/src/tools/ToolSearchTool/prompt.ts`
- 预期: 输出包含 EXECUTE_TOOL_NAME 的导入和 `isDeferredTool` 中的排除逻辑
- [x] 验证单元测试通过
- `bun test packages/builtin-tools/src/tools/ExecuteTool/__tests__/ExecuteTool.test.ts`
- 预期: 所有测试用例通过,无错误
---
### Task 4: ToolSearchTool 搜索增强
**背景:**
[业务语境] — 本 Task 在现有 ToolSearchTool 上叠加 TF-IDF 搜索路径、`discover:` 查询模式和文本模式输出,使模型能通过自然语言描述发现延迟工具,并在 `tool_reference` 不可用时仍能获取工具信息。
[修改原因] — 当前 ToolSearchTool 仅支持关键词搜索(`searchToolsWithKeywords`),缺少语义匹配能力;`mapToolResultToToolResultBlockParam` 仅返回 `tool_reference` 块,不支持非 Anthropic provider缺少纯发现模式供模型了解工具能力。
[上下游影响] — 本 Task 依赖 Task 1`isDeferredTool` 白名单制判定)和 Task 2`buildToolIndex`、`searchTools`、`getToolIndex`)。本 Task 的输出(增强后的 ToolSearchTool被 Task 5预取管道和 Task 6UI 推荐)间接依赖。
**涉及文件:**
- 修改: `packages/builtin-tools/src/tools/ToolSearchTool/ToolSearchTool.ts`
- 修改: `packages/builtin-tools/src/tools/ToolSearchTool/prompt.ts`
- 新建: `packages/builtin-tools/src/tools/ToolSearchTool/__tests__/ToolSearchTool.test.ts`
**执行步骤:**
- [x] 在 `ToolSearchTool.ts` 中新增 TF-IDF 搜索相关 import — 为并行搜索和结果合并做准备
- 位置: `packages/builtin-tools/src/tools/ToolSearchTool/ToolSearchTool.ts` 文件顶部 import 区域L18 之前,现有 import 块之后)
- 新增 import:
```typescript
import { getToolIndex, searchTools } from 'src/services/toolSearch/toolIndex.js'
import type { ToolSearchResult } from 'src/services/toolSearch/toolIndex.js'
import { modelSupportsToolReference } from 'src/utils/toolSearch.js'
```
- 新增权重常量import 区域之后、`inputSchema` 定义之前):
```typescript
const KEYWORD_WEIGHT = Number(process.env.TOOL_SEARCH_WEIGHT_KEYWORD ?? '0.4')
const TFIDF_WEIGHT = Number(process.env.TOOL_SEARCH_WEIGHT_TFIDF ?? '0.6')
```
- 原因: TF-IDF 搜索函数和模型能力判断函数分别定义在 `src/` 下,需显式 import。权重常量支持环境变量调优。
- [x] 在 `ToolSearchTool.ts` 的 `call` 方法中增加 `discover:` 查询模式分支 — 纯发现搜索,不触发延迟加载
- 位置: `ToolSearchTool.ts` 的 `call` 方法内,在 `selectMatch` 正则匹配之后(~L363、关键词搜索之前~L408
- 在 `selectMatch` 分支之后插入 `discover:` 分支:
```typescript
// Check for discover: prefix — pure discovery search.
// Returns tool info (name + description + schema) as text,
// does NOT trigger deferred tool loading.
const discoverMatch = query.match(/^discover:(.+)$/i)
if (discoverMatch) {
const discoverQuery = discoverMatch[1]!.trim()
const index = await getToolIndex(deferredTools)
const tfIdfResults = searchTools(discoverQuery, index, max_results)
// discover 模式返回文本格式的工具信息
const textResults = tfIdfResults.map(r => {
let line = `**${r.name}** (score: ${r.score.toFixed(2)})\n${r.description}`
if (r.inputSchema) {
line += `\nSchema: ${JSON.stringify(r.inputSchema)}`
}
return line
})
const text = textResults.length > 0
? `Found ${textResults.length} tools:\n${textResults.join('\n\n')}`
: 'No matching deferred tools found'
logSearchOutcome(tfIdfResults.map(r => r.name), 'keyword')
return buildSearchResult(tfIdfResults.map(r => r.name), query, deferredTools.length)
}
```
- 更新 `logSearchOutcome` 的 `queryType` 参数: `discover` 模式使用 `'keyword'` 类型(与关键词搜索共用类型,避免修改分析事件的枚举)
- 原因: `discover:` 模式让模型能了解延迟工具的能力(名称 + 描述 + schema而不触发 schema 注入,适用于规划阶段或信息收集场景
- [x] 在 `ToolSearchTool.ts` 的 `call` 方法中实现关键词搜索与 TF-IDF 搜索的并行执行和结果合并
- 位置: `ToolSearchTool.ts` 的 `call` 方法内替换当前关键词搜索逻辑L408-L433
- 替换原有关键词搜索段为并行搜索 + 合并逻辑:
```typescript
// Keyword search + TF-IDF search in parallel
const [keywordMatches, index] = await Promise.all([
searchToolsWithKeywords(query, deferredTools, tools, max_results),
getToolIndex(deferredTools),
])
const tfIdfResults = searchTools(query, index, max_results)
// Merge results: keyword score * 0.4 + TF-IDF score * 0.6
const mergedScores = new Map<string, number>()
// Add keyword results (assign scores inversely proportional to rank)
keywordMatches.forEach((name, rank) => {
const score = (keywordMatches.length - rank) / keywordMatches.length
mergedScores.set(name, (mergedScores.get(name) ?? 0) + score * KEYWORD_WEIGHT)
})
// Add TF-IDF results
tfIdfResults.forEach(result => {
mergedScores.set(result.name, (mergedScores.get(result.name) ?? 0) + result.score * TFIDF_WEIGHT)
})
// Sort by merged score, take top-N
const matches = [...mergedScores.entries()]
.sort((a, b) => b[1] - a[1])
.slice(0, max_results)
.map(([name]) => name)
```
- 保留后续的 `logForDebugging`、`logSearchOutcome`、空结果 pending servers 逻辑和 `buildSearchResult` 调用不变
- 原因: 并行执行避免串行延迟;加权合并综合关键词精确匹配和 TF-IDF 语义匹配的优势TF-IDF 权重更高,因为其语义能力更强)
- [x] 修改 `mapToolResultToToolResultBlockParam` 方法,增加文本模式输出 — 当 `tool_reference` 不可用时返回文本格式工具信息
- 位置: `ToolSearchTool.ts` 的 `mapToolResultToToolResultBlockParam` 方法L444-L469
- 新增方法参数 `context` 用于获取当前模型信息: 将 `mapToolResultToToolResultBlockParam(content, toolUseID)` 签名改为 `mapToolResultToToolResultBlockParam(content, toolUseID, context?)`,其中 `context` 类型为 `{ mainLoopModel?: string } | undefined`
- 在方法体中,`content.matches.length === 0` 分支保持不变
- 在返回 `tool_reference` 块之前,插入 `tool_reference` 支持检查:
```typescript
const supportsToolRef = context?.mainLoopModel
? modelSupportsToolReference(context.mainLoopModel)
: true // 默认假设支持(向后兼容)
if (!supportsToolRef) {
// 文本模式: 返回工具名称列表
return {
type: 'tool_result',
tool_use_id: toolUseID,
content: `Found ${content.matches.length} tool(s): ${content.matches.join(', ')}. Use ExecuteTool with tool_name and params to invoke.`,
}
}
```
- 保留原有 `tool_reference` 返回逻辑作为默认路径
- 原因: 非 Anthropic providerOpenAI/Gemini/Grok不支持 `tool_reference` beta 特性,需要回退到文本模式输出,引导模型使用 ExecuteTool
- [x] 更新 `ToolSearchTool/prompt.ts` 的 PROMPT 文本,增加 `discover:` 模式和 TF-IDF 搜索说明
- 位置: `packages/builtin-tools/src/tools/ToolSearchTool/prompt.ts` 的 `PROMPT_TAIL` 常量L44-L51
- 在 `Query forms:` 部分追加 `discover:` 模式说明:
```typescript
const PROMPT_TAIL = ` ... (保留现有内容) ...
Query forms:
- "select:Read,Edit,Grep" — fetch these exact tools by name
- "discover:schedule cron job" — pure discovery, returns tool info (name, description, schema) without loading. Use when you want to understand available tools before deciding which to invoke.
- "notebook jupyter" — keyword search, up to max_results best matches
- "+slack send" — require "slack" in the name, rank by remaining terms`
- 原因: 模型需要知道 `discover:` 模式的存在和语义,才能正确使用该功能
- [x] 为 ToolSearchTool 搜索增强编写单元测试
- 测试文件: `packages/builtin-tools/src/tools/ToolSearchTool/__tests__/ToolSearchTool.test.ts`(新建)
- 测试框架: `bun:test`(与 `DiscoverSkillsTool.test.ts` 一致)
- 测试场景:
- `discover:` 前缀解析: 传入 `query: "discover:send notification"` 调用 `ToolSearchTool.call()`,验证返回结果中 `matches` 非空且包含预期工具名(通过 mock `getToolIndex``searchTools`
- `select:` 前缀保持不变: 传入 `query: "select:SomeTool"` 调用 `ToolSearchTool.call()`,验证返回结果中 `matches` 包含 `"SomeTool"`mock `findToolByName` 返回对应工具)
- 关键词搜索 + TF-IDF 合并: mock `searchToolsWithKeywords` 返回 `["ToolA", "ToolB"]`mock `searchTools` 返回 `[{name: "ToolB", score: 0.9}, {name: "ToolC", score: 0.8}]`,验证合并后 `matches` 包含 `"ToolB"`(两路均有)、`"ToolA"`(仅关键词)、`"ToolC"`(仅 TF-IDF`"ToolB"` 排名靠前
- 文本模式输出: 调用 `mapToolResultToToolResultBlockParam` 传入 `context: { mainLoopModel: 'claude-3-haiku-20240307' }`,验证返回内容为文本格式(包含 "Found" 和 "ExecuteTool"),而非 `tool_reference`
- tool_reference 模式输出: 调用 `mapToolResultToToolResultBlockParam` 传入 `context: { mainLoopModel: 'claude-sonnet-4-20250514' }`,验证返回内容包含 `type: 'tool_reference'`
- 向后兼容: 调用 `mapToolResultToToolResultBlockParam` 不传 `context` 参数,验证默认返回 `tool_reference` 块(向后兼容)
- 空结果处理: 传入不匹配的查询,验证返回结果中 `matches` 为空数组
- Mock 策略: 使用 `bun:test``mock` 函数 mock `src/services/toolSearch/toolIndex.js``getToolIndex``searchTools`mock `src/utils/toolSearch.js``modelSupportsToolReference`
- 运行命令: `bun test packages/builtin-tools/src/tools/ToolSearchTool/__tests__/ToolSearchTool.test.ts`
- 预期: 所有测试通过
**检查步骤:**
- [x] 验证 TF-IDF 搜索 import 已添加
- `grep -n "getToolIndex\|searchTools\|modelSupportsToolReference" packages/builtin-tools/src/tools/ToolSearchTool/ToolSearchTool.ts`
- 预期: 输出包含 `getToolIndex``searchTools``modelSupportsToolReference` 的 import 行
- [x] 验证 `discover:` 模式分支已添加到 `call` 方法
- `grep -n "discoverMatch\|discover:" packages/builtin-tools/src/tools/ToolSearchTool/ToolSearchTool.ts`
- 预期: 输出包含 `discoverMatch` 正则匹配和 `discover:` 分支逻辑
- [x] 验证关键词搜索与 TF-IDF 搜索并行执行
- `grep -n "Promise.all" packages/builtin-tools/src/tools/ToolSearchTool/ToolSearchTool.ts`
- 预期: 输出包含 `Promise.all` 调用,参数包含 `searchToolsWithKeywords``getToolIndex`
- [x] 验证结果合并逻辑使用加权求和
- `grep -n "KEYWORD_WEIGHT\|TFIDF_WEIGHT" packages/builtin-tools/src/tools/ToolSearchTool/ToolSearchTool.ts`
- 预期: 输出包含权重常量定义和在合并逻辑中的使用
- [x] 验证 `mapToolResultToToolResultBlockParam` 增加了文本模式分支
- `grep -n "supportsToolRef\|ExecuteTool" packages/builtin-tools/src/tools/ToolSearchTool/ToolSearchTool.ts`
- 预期: 输出包含 `modelSupportsToolReference` 调用和 "ExecuteTool" 文本回退
- [x] 验证 prompt.ts 包含 `discover:` 模式说明
- `grep -n "discover:" packages/builtin-tools/src/tools/ToolSearchTool/prompt.ts`
- 预期: 输出包含 `discover:` 模式的文档说明
- [x] 验证 TypeScript 编译无错误
- `bunx tsc --noEmit --pretty 2>&1 | head -30`
- 预期: 无新增类型错误
- [x] 运行新增单元测试
- `bun test packages/builtin-tools/src/tools/ToolSearchTool/__tests__/ToolSearchTool.test.ts`
- 预期: 所有测试通过
**认知变更:**
- [x] [CLAUDE.md] `ToolSearchTool.mapToolResultToToolResultBlockParam` 新增可选第三个参数 `context?: { mainLoopModel?: string }`,用于判断当前模型是否支持 `tool_reference`。不支持时回退到文本输出,引导模型使用 ExecuteTool。调用方`src/services/api/claude.ts` 的 tool_result 处理逻辑)需传入 context 参数。
### Task 5: 基础设施层验收
**前置条件:**
- Task 1-4 全部完成
- 构建环境: `bun run build` 可用
**端到端验证:**
1. ✅ 运行完整测试套件确保无回归
- `bun test src/constants/__tests__/tools.test.ts src/services/toolSearch/__tests__/toolIndex.test.ts packages/builtin-tools/src/tools/ExecuteTool/__tests__/ExecuteTool.test.ts packages/builtin-tools/src/tools/ToolSearchTool/__tests__/DiscoverSearch.test.ts 2>&1`
- 预期: 全部测试通过
- 失败排查: 检查各 Task 的测试步骤,确认 import 路径和 mock 配置正确
2. ✅ 验证 TypeScript 类型检查通过
- `bunx tsc --noEmit --pretty 2>&1 | grep -i "error" | head -20`
- 预期: 无新增类型错误
- 失败排查: 检查 Task 1-4 中新增/修改文件的 import 路径和类型签名
3. ✅ 验证 CORE_TOOLS 常量被正确使用
- `grep -rn "CORE_TOOLS" src/ packages/builtin-tools/src/ --include="*.ts" 2>/dev/null`
- 预期: 在 `tools.ts``prompt.ts`isDeferredTool`toolIndex.ts` 中被引用
- 失败排查: 检查 Task 1 和 Task 2 的 import 步骤
4. ✅ 验证 isDeferredTool 白名单制生效
- `grep -A5 "export function isDeferredTool" packages/builtin-tools/src/tools/ToolSearchTool/prompt.ts`
- 预期: 函数体包含 `CORE_TOOLS.has(tool.name)`,不包含旧的 `shouldDefer``feature(` 逻辑
- 失败排查: 检查 Task 1 的重构步骤
5. ✅ 验证构建产物正确
- `bun run build 2>&1 | tail -5`
- 预期: 构建成功,输出 dist/cli.js
- 失败排查: 检查新增文件的 import 路径是否兼容 Bun.build splitting