112 lines
3.0 KiB
Markdown
112 lines
3.0 KiB
Markdown
# Tool Call Strategy — 工具选择与组合
|
||
|
||
> 来源: Agent Evolution 实战验证
|
||
> 每次发现新的有效工具组合时追加
|
||
|
||
---
|
||
|
||
## 策略 1: 大任务并行化
|
||
|
||
**场景**: 多个独立子任务,需要加速
|
||
|
||
**组合**: `sessions_spawn` (并行) → `sessions_yield` (等待) → 合并结果
|
||
|
||
**示例**:
|
||
```
|
||
sessions_spawn(taskName="analyze-ecc", task="深度分析 ECC")
|
||
sessions_spawn(taskName="analyze-headroom", task="深度分析 headroom")
|
||
sessions_spawn(taskName="analyze-codegraph", task="深度分析 codegraph")
|
||
sessions_yield() // 等待全部完成
|
||
// 合并三个分析文件
|
||
```
|
||
|
||
**关键参数**:
|
||
- `mode: "run"` — 一次性后台任务
|
||
- `runTimeoutSeconds: 600` — 大任务 10 分钟超时
|
||
- `context: "isolated"` — 子 agent 不需要父上下文(省 token)
|
||
|
||
**经验**: 3 个项目并行 vs 串行,从 8 分钟降到 2.5 分钟
|
||
|
||
---
|
||
|
||
## 策略 2: 多轮对话式编码
|
||
|
||
**场景**: 需要逐步构建复杂模块
|
||
|
||
**组合**: 先独立测试 → 再集成
|
||
|
||
**示例**:
|
||
```
|
||
1. write detector.js → node detector.js < test.txt → 确认输出
|
||
2. write smart-crusher.js → node smart-crusher.js < data.json → 确认输出
|
||
3. write ctx-compress.js → cat data | node ctx-compress.js → 确认全链路
|
||
```
|
||
|
||
**反模式**: 全部写完再测 → 一个 bug 要回溯到多个文件
|
||
|
||
---
|
||
|
||
## 策略 3: 安全门控链
|
||
|
||
**场景**: 执行可能有风险的操作
|
||
|
||
**组合**: `risk-scorer` → `permission-gate` → `budget-tracker` → `audit-log`
|
||
|
||
```
|
||
Input: tool_name, command
|
||
→ ctx_execute("node src/security/risk-scorer.js '...input...'")
|
||
→ if REVIEW: show risk factors
|
||
→ if CONFIRM: ask user
|
||
→ if BLOCK: refuse
|
||
→ if ALLOW:
|
||
→ preCheck budget
|
||
→ execute
|
||
→ postRecord (audit log + budget usage)
|
||
```
|
||
|
||
---
|
||
|
||
## 策略 4: 压缩优先
|
||
|
||
**场景**: 工具输出可能在 500+ 字符
|
||
|
||
**组合**: `exec` → `ctx_compress` → 读压缩版本 → 需要时 `ctx_compress --retrieve`
|
||
|
||
```
|
||
大输出 → ctx_compress --json → { compressed, savings%, ccrHash }
|
||
→ 99% 情况下压缩版本就够了
|
||
→ 需要原始数据时: ctx_compress --retrieve <hash>
|
||
```
|
||
|
||
**经验**: 压缩版 99.1% 节省 build log,完全够定位问题
|
||
|
||
---
|
||
|
||
## 策略 5: CodeGraph 优先
|
||
|
||
**场景**: 代码搜索/理解
|
||
|
||
**组合**: `codegraph search` 优先于 `grep/find`
|
||
|
||
```
|
||
1. codegraph search "symbol_name" → 结构化结果 (kind + file + line)
|
||
2. 不够 → codegraph callers "symbol" → 调用关系
|
||
3. 还不够 → codegraph impact "symbol" → BFS 影响范围
|
||
4. 最后手段 → grep/read
|
||
```
|
||
|
||
**经验**: CodeGraph 比 grep 少 58% 工具调用(项目 README benchmark)
|
||
|
||
---
|
||
|
||
## 策略 6: 减少工具调用
|
||
|
||
**场景**: Agent 倾向于逐个文件 grep → 大量工具调用
|
||
|
||
**替代方案**:
|
||
- 「找所有 X」: `codegraph search X --limit 20` 替代 20 次 grep
|
||
- 「读大文件」: `ctx_compress` 替代 read 整个文件
|
||
- 「批量命令」: `ctx_batch_execute` 替代 5+ 个独立 exec
|
||
|
||
**关键指标**: 工具调用次数 > 必要次数 → 有优化空间
|