search-web

# 网络搜索

## 概述

本技能采用 **Evaluator-optimizer 模式** 进行系统性多轮网络研究，搜索前使用结构化 Ask 流程澄清需求。核心特性：

1. **三层 Ask 框架** — 研究目标分类 → 模式专用提问 → YAML 需求文档
2. **智能跳过规则** — 根据用户输入自动跳过已回答的问题
3. **Escape hatch 快速模式** — 用户不耐烦时提供可控降级选项
4. **研究模式分类** — 聚焦/扫描/全面三种模式对应不同策略
5. **评估器 - 优化器循环** — 质量驱动的迭代搜索

```
工作流程：
1. 需求澄清 — 三层 Ask 框架
   ├─ 1.1 项目重述（Re-ground）
   ├─ 1.2 研究目标分类
   ├─ 1.3 模式专用提问（聚焦/扫描/全面）
   ├─ 1.4 逃生舱口（Escape hatch）
   └─ 1.5 输出研究需求文档（YAML）
2. 评估任务与查询构建
   ├─ 2.1 确定搜索模式（easy/medium/hard）
   ├─ 2.2 选择初始研究方向
   ├─ 2.3 创建搜索任务（todos）
   └─ 2.4 构建查询集群（运用高级搜索技巧）
3. 分发子代理搜索（并行）
   ├─ 3.1 创建搜索团队（TeamCreate）
   ├─ 3.2 启动并行搜索（2~4 个 Agent）
   └─ 3.3 子代理写入独立文件（turn-{n}/search-agent-{n}-task.md）
4. 聚合结果到结构化日志
   ├─ 4.1 初始化会话目录（/tmp/search-web/{date}/{task}/）
   ├─ 4.2 创建协调日志（master-log.md）
   └─ 4.3 父代理记录事件时间线
5. 评估器 - 优化器循环
   ├─ 5.1 启动评估器（读取 turn-{n}/search-agent-*.md）
   ├─ 5.2 评估器输出报告（turn-{n}/search-evaluator-turn-{n}.md）
   ├─ 5.3 决策点（全 5/5 则 COMPLETE，否则 CONTINUE）
   └─ 5.4 启动优化器（生成 turn-{n}/query-optimizer-turn-{n}.md）
6. 交付经过验证的结果
   ├─ 6.1 生成最终报告（report.md）
   ├─ 6.2 向用户展示主日志位置
   ├─ 6.3 用户审核与反馈
   └─ 6.4 如果用户有 `/save-ob-chaos` 技能，执行并存档报告文件
```

---

## AskUserQuestion 格式规范

**所有 AskUserQuestion 调用必须遵循以下结构：**

1. **Re-ground** (1-2 句)
   - 声明当前项目、分支、任务
   - 说明当前进度

2. **Simplify**
   - 用 16 岁能懂的语言解释问题
   - 避免内部术语，使用具体例子

3. **Recommend**
   - `RECOMMENDATION: 选择 [X] 因为 [一行理由]`
   - 包含 `Completeness: X/10`

4. **Options**
   - A) B) C) 格式
   - 显示 effort 估算 `(human: ~X / CC: ~Y)`

**示例：**

> **当前项目：** my-app | **分支：** feature-search
>
> 你想研究 React 19 的新特性。简单理解：你想知道 React 19 有什么变化，以及是否值得升级。
>
> RECOMMENDATION: Choose C（全面调查）because 升级决策需要完整的利弊分析
>
> **你想通过这次搜索达到什么目的？**
>
> A) 快速了解 — 10 分钟概览（Completeness: 5/10, human: ~30min / CC: ~3min）  
> B) 标准研究 — 了解主要变化和迁移成本（Completeness: 8/10, human: ~2h / CC: ~10min）  
> C) 全面调查 — 深入所有新特性、性能对比、社区反馈（Completeness: 10/10, human: ~1d / CC: ~20min）

---

## 步骤 1：需求澄清 — 三层 Ask 框架

**不要直接开始搜索**。先通过结构化提问澄清研究目标。

### 1.1 项目重述（Re-ground）

使用 AskUserQuestion：

> **当前项目：** {project-name} | **分支：** {_BRANCH}
>
> 你要求我进行网络搜索研究。让我先确保我理解正确：
>
> 你的原始请求是："*{user-original-request}*"
>
> 我理解你想研究：**{提炼后的核心主题}**
>
> 是这样吗？
>
> A) 是的，开始研究  
> B) 不完全对 — *请澄清*

---

### 1.2 研究目标分类

**若用户确认（选 A）**，使用 AskUserQuestion：

> **你想通过这次搜索达到什么目的？**
>
> - **验证假设** — 你有一个具体想法，需要找到支持/反对的证据
> - **探索未知** — 你对某领域不了解，需要系统性概览
> - **对比决策** — 需要在几个选项之间做选择（技术选型、方案对比等）
> - **追踪最新** — 了解某领域的最新进展、版本、趋势
> - **深度调查** — 全面收集信息，形成完整认知

**模式映射：**
- 验证假设 / 对比决策 → **聚焦模式**（Focused Mode）
- 探索未知 / 追踪最新 → **扫描模式**（Scan Mode）
- 深度调查 → **全面模式**（Comprehensive Mode）

---

### 1.3 模式专用提问（一次只问一个）

#### 聚焦模式提问（验证假设 / 对比决策）

依次 AskUserQuestion（智能跳过已回答的问题）：

**Q1：具体假设**
> 你的具体假设是什么？请用一句话陈述你认为的结果。
>
> 示例：*"我认为 Next.js 14 的 App Router 性能比 Pages Router 慢 20% 以上"*

**Q2：反证标准**
> 什么样的证据会让你改变想法？（反证标准）
>
> A) 官方基准数据即可  
> B) 需要多个独立来源一致  
> C) 需要看到实际代码/案例  
> D) 其他：____

**Q3：范围边界**
> 研究范围有多广？
>
> - **窄** — 聚焦特定版本/场景（如仅 Next.js 14.2+）
> - **中** — 包含相关生态（如对比其他框架）
> - **宽** — 历史演变 + 未来趋势

#### 扫描模式提问（探索未知 / 追踪最新）

依次 AskUserQuestion：

**Q1：背景水平**
> 你对这个主题的当前了解程度？
>
> - **完全新手** — 需要基础概念解释
> - **有一定了解** — 知道主要术语，需要深入
> - **很了解** — 关注最新进展和边缘案例

**Q2：信息时效**
> 信息时效要求？
>
> - **仅最新** — 2024-2026 年的信息
> - **包含历史** — 需要演变脉络
> - **无特殊要求** — 质量优先

**Q3：输出偏好**
> 你希望输出什么形式？
>
> A) 执行摘要（2-3 段关键结论）  
> B) 结构化对比表（优缺点、适用场景）  
> C) 详细报告（带引用、置信度评估）  
> D) 原始发现清单（你自己整理）

#### 全面模式提问（深度调查）

依次 AskUserQuestion：

**Q1：研究深度**
> 你希望研究到什么程度？
>
> - **快速概览** — 1 轮搜索，30 分钟内完成
> - **标准研究** — 2-3 轮评估器-优化器循环
> - **穷尽研究** — 最多 4 轮，直到质量达标

**Q2：质量阈值**
> 置信度要求？
>
> - **高** — 多源交叉验证，矛盾必须解决
> - **中** — 主要来源可信即可
> - **低** — 快速获取方向性信息

**Q3：特殊角度**
> 是否需要关注特定视角？（可多选）
>
> - [ ] 负面评价 / 已知限制
> - [ ] 中文资料 / 国内实践
> - [ ] 学术论文 / 权威研究
> - [ ] GitHub Issues / 真实用户反馈
> - [ ] 无需特殊角度

---

### 1.4 智能跳过规则

**只问那些答案尚不明确的问题。**

| 用户原始请求 | 自动跳过 | 默认设置 |
|-------------|---------|---------|
| "我想快速了解一下" | 跳过 1.2 目标分类 | 扫描模式 |
| "帮我深入调研" | 跳过 1.2 目标分类 | 全面模式 |
| "验证一下这个想法" | 跳过 1.2 目标分类 | 聚焦模式 |
| "只需要最新信息" | 扫描模式下跳过 Q2 | latest-only |
| 提供完整技术对比列表 | 对比决策跳过 Q1 | 使用用户列表 |

---

### 1.5 追问矩阵（当答案不够具体时）

| 用户答案类型 | 追问问题 | 追问话术示例 |
|-------------|---------|-------------|
| 模糊/宽泛 | 范围澄清 | "这个词会返回大量结果，我们需要缩小范围。具体是哪个方面/场景？" |
| 没有定义成功标准 | 质量阈值 | "什么算'找到答案'？需要多高的置信度？(高=多源验证/中=主流来源/低=初步了解)" |
| 没有输出偏好 | 输出形态 | "需要的是 3 句话摘要、详细报告、还是原始发现列表？" |
| 没有时间边界 | 时效性要求 | "信息需要多新？1 周内/1 月内/1 年内/不限？" |
| 没有失败条件 | 停止条件 | "什么情况下算'没找到答案'？什么时候可以停止搜索？" |

---

### 1.6 提问质量原则

#### 反奉承规则 — 禁止使用的语言

| ❌ 禁用 | ✅ 改用 |
|--------|--------|
| "这是个有趣的问题" | 直接说问题难点在哪 |
| "有很多方式可以思考这个" | 选一种并说明理由 |
| "你可能会考虑..." | 说"应该..."并说明原因 |
| "这可以工作" | 说"这能/不能工作因为..." |

#### 追问纪律

- 第一个答案通常是包装过的版本，真实答案在第二或第三次追问后
- **推一次，再推一次** — 直到答案具体可执行
- 命名常见失败模式（"搜索词太宽泛"、"没有明确目标"）

#### BAD vs GOOD 示例

**场景：用户说"搜索 LLM 评估框架"**

❌ **BAD:**
> "好的，我来搜索 LLM 评估框架的最新信息"

✅ **GOOD:**
> "LLM 评估框架是个大领域，有数百个结果。我们需要缩小范围：
> - 你是想比较主流框架（RAGAS/TruLens/DeepEval）？
> - 还是想找特定任务的评估（如代码生成/数学推理）？
> - 或是想了解评估方法论（自动评估 vs 人工评估）？
>
> 具体是哪个方向？"

---

### 1.7 逃生舱口（Escape hatch）

**若用户表达不耐烦**（如"直接搜"、"跳过这些问题"）：

> 理解，这些问题确实会多花 2-3 分钟，但它们决定搜索质量。
>
> **快速模式：** 我基于你的原始请求选择合理默认值，立即开始搜索。你之后可以要求深入特定方向。
>
> RECOMMENDATION: Choose B（继续提问）because 2-3 分钟的前期澄清可避免 20 分钟的无效搜索
>
> A) 好的，快速模式（Completeness: 6/10）  
> B) 不，继续问完（Completeness: 10/10）

**若用户第二次表达不耐烦**：尊重选择，直接进入步骤 2，使用默认配置：
- 研究模式：scan
- 质量阈值：medium
- 输出格式：执行摘要

---

### 1.8 输出：研究需求文档（YAML）

根据用户回答，生成结构化需求：

```yaml
研究目标: {提炼后的目标}
研究模式: {focused/scan/comprehensive}
背景水平: {beginner/intermediate/expert}
质量阈值: {high/medium/low}
时效要求: {latest-only/history-ok/none}
输出格式: {summary/comparison-table/detailed-report/raw-findings}
特殊角度: [negative, chinese, academic, github-issues, none]
反证标准: {string}
范围边界: {narrow/medium/wide}
```

需求文档输出到：`/tmp/search-web/{YYYY-MM-DD}/{task-name}/task.yaml`

目录结构预览：
```
/tmp/search-web/2026-04-05/powershell-bash-research/
├── task.yaml                    # 研究需求文档
├── master-log.md                # 协调日志
├── report.md                    # 最终报告
├── turn-1/                      # 第 1 轮
│   ├── search-agent-1-task.md
│   ├── search-agent-2-task.md
│   └── search-evaluator-turn-1.md
├── turn-2/                      # 第 2 轮
│   ├── search-agent-3-task.md
│   ├── search-agent-4-task.md
│   ├── search-evaluator-turn-2.md
│   └── query-optimizer-turn-2.md
└── turn-3/                      # 第 3 轮（最终轮无 optimizer）
    ├── search-agent-5-task.md
    ├── search-agent-6-task.md
    └── search-evaluator-turn-3.md
```

此文档将指导步骤 2 的查询集群构建，并注入评估器提示词。

---

## 步骤 2：评估任务与查询构建

### 2.1 确定搜索模式

根据步骤 1.8 的"研究需求文档"确定 `$mode`：

| 研究模式 + 深度 | $mode | 代理数量 |
|---------------|-------|---------|
| focused/scan + 快速概览 | easy | 2 |
| comprehensive 或 标准研究 | medium | 3 |
| 穷尽研究 + 高阈值 | hard | 4 |

### 2.2 选择初始研究方向

根据研究模式选择策略：

**聚焦模式（focused）：**
- 优先搜索支持/反对假设的证据
- 寻找权威来源（官方文档、论文、基准测试）
- 关注矛盾观点和反证

**扫描模式（scan）：**
- 先撒大网获取概览
- 识别关键概念和术语
- 找到该领域的权威来源

**全面模式（comprehensive）：**
- 多角度并行：正面/负面/学术/实践
- 时间维度：历史演变 + 最新进展
- 地域维度：国际主流 + 中文社区

### 2.3 构建查询集群

使用以下技巧：
- **搜索技巧**：并排比较、时间限制等
- **公开基准**：具名评估数据集/框架等
- **特定站点**：GitHub issues、HN、StackOverflow 等
- **学术报告**：论文、arXiv、研究博客等
- **多角度**：如负面 Bug、限制、投诉等
- **多语种**：多语种搜索、国家或地区型搜索引擎等

根据用户选择的"特殊角度"，强制包含对应查询：
- `negative` → "{topic} limitations problems issues"
- `chinese` → "{topic} 中文 踩坑 实践"
- `academic` → "{topic} paper arxiv research"
- `github-issues` → "{topic} github issues bug"

### 2.4 使用 todos 工具创建搜索任务

```yaml
TaskCreate:
  subject: "网络搜索：{研究目标}"
  description: |
    研究目标：{提炼后的目标}
    研究模式：{focused/scan/comprehensive}
    质量阈值：{high/medium/low}
    当前轮次：1/{max_rounds}
```

---

## 步骤 3：分发子代理搜索

### 3.1 创建搜索团队

```yaml
TeamCreate:
  team_name: "search-web"
  description: "网络搜索团队，用于并行执行多个搜索查询"
```

### 3.2 启动并行搜索

使用 Agent 工具配合 `subagent_type: general-purpose` 和 `team_name: search-web` 启动并行搜索。

**搜索代理配置：**

```yaml
name: search-agent-{n}
subagent_type: general-purpose
team_name: search-web
prompt: |
  搜索："{query}"

  目标：{research_goal}

  **输出文件：** 将结果写入 `/tmp/search-web/{YYYY-MM-DD}/{task-name}/turn-{round}/search-agent-{n}-task.md`

  使用工具执行网络搜索。

  **⚠️ 错误处理规则：**
  - 如果遇到 429 Rate Limit 错误，**立即停止搜索**
  - 返回已获取的部分结果 + 错误说明
  - 不要无限重试或切换到其他工具继续搜索

  对于每个相关结果：
  1. 使用 WebFetch 获取页面内容
  2. 提取与研究目标相关的关键发现
  3. 记录：URL、标题、要点、相关度评分（1-5）

  **写入文件格式：**
  ```markdown
  # Search Agent {n} - Task Log

  ## 元数据
  - **查询：** "{query}"
  - **集群：** {cluster_name}
  - **启动时间：** {timestamp}
  - **状态：** {running/completed/error}

  ## 搜索结果

  ### 结果 1：{title}
  - URL: {url}
  - 相关度：{1-5}/5
  - 关键发现：
    - {要点}
  - 引用：
    - "{相关摘录}"

  ## 执行摘要
  - 结果数量：{N}
  - 平均相关度：{X}/5
  - 遇到错误：{none/429/other}
  ```

  如果结果不足，尝试变体查询。
  关注事实信息和有数据支持的论断。
  
  **返回给父代理：** 仅返回文件路径和状态摘要（如"完成，12 条结果，写入 search-agent-1-task.md"）
```

根据 `$mode`，**并行启动 2~4 个代理**（easy 2 个、medium 3 个、hard 4 个），每个代理使用不同的查询集群。

---

## 步骤 4：聚合结果

### 4.1 初始化会话目录

```bash
mkdir -p /tmp/search-web/{YYYY-MM-DD}/{task-name}
```

### 4.2 创建协调日志文件

主代理只记录协调日志，格式为单行时间戳记录：

**文件路径：** `/tmp/search-web/{YYYY-MM-DD}/{task-name}/master-log.md`

**格式：**
```
[14:30:00] [INIT] 搜索任务初始化，研究目标：{research_goal}
[14:30:05] [MKDIR] 创建目录 turn-1/
[14:30:05] [AGENT_START] search-agent-1 启动，查询：{query_1}，集群：comparison，输出：turn-1/search-agent-1-task.md
[14:30:05] [AGENT_START] search-agent-2 启动，查询：{query_2}，集群：limitations，输出：turn-1/search-agent-2-task.md
[14:30:50] [AGENT_DONE] search-agent-1 完成，结果数：12，耗时：45s
[14:30:52] [AGENT_DONE] search-agent-2 完成，结果数：8，耗时：38s
[14:31:00] [EVAL_START] 启动 search-evaluator，第 1 轮评估，输出：turn-1/search-evaluator-turn-1.md
[14:33:30] [EVAL_DONE] 评估完成，总分：3.2/5，建议：CONTINUE_SEARCH
[14:33:35] [ROUND_END] 第 1 轮结束，启动第 2 轮
[14:33:36] [MKDIR] 创建目录 turn-2/
[14:33:37] [OPTIM_START] 启动 query-optimizer，输出：turn-2/query-optimizer-turn-2.md
[14:35:00] [AGENT_START] search-agent-3 启动，输出：turn-2/search-agent-3-task.md
...
[14:45:00] [COMPLETE] 搜索完成，总轮次：3，最终评分：4.5/5
```

**协调日志原则：**
- 只记录事件类型、时间戳、关键元数据
- 不记录详细搜索结果（由子代理自己的文件记录）
- 便于快速追溯执行流程和定位问题

---

## 步骤 5：评估器 - 优化器循环

使用两个子代理形成反馈循环：评估器评估搜索结果，优化器基于评估结果优化搜索。

**评估器基调：挑战性和破坏性**

### 5.1 评估器代理

```yaml
name: search-evaluator
subagent_type: general-purpose
team_name: search-web
timeout: 180000
prompt: |
  你是研究质量评估器。根据我们的研究目标和质量标准评估以下搜索结果。

  研究目标：{goal}
  质量阈值：{high/medium/low}（来自步骤 1.8）
  研究模式：{focused/scan/comprehensive}

  **读取来源：** 从当前轮次目录读取所有搜索代理结果
  - `/tmp/search-web/{YYYY-MM-DD}/{task-name}/turn-{round}/search-agent-*.md`

  **输出文件：** 将评估报告写入 `/tmp/search-web/{YYYY-MM-DD}/{task-name}/turn-{round}/search-evaluator-turn-{round}.md`

  从以下维度评估（每项 1-5 分）：

  1. **覆盖度** - 结果是否从多个角度回答了核心问题？
  2. **来源质量** - 来源是否权威可信？
  3. **一致性** - 来源在关键事实上是否一致？
  4. **具体性** - 论断是否有数据/案例支持？
  5. **时效性** - 信息是否最新且相关？

  特殊规则（来自步骤 1.8）：
  - 若用户要求"仅最新"：2024-2026 信息正常评分，2023 年及以前降 2 分
  - 若用户要求"包含历史"：不扣分，但需标注时间

  **写入文件格式：**
  ```markdown
  # Search Evaluator - Turn {round} Report

  ## 元数据
  - **评估轮次：** {round}
  - **评估时间：** {timestamp}
  - **研究目标：** {goal}
  - **质量阈值：** {high/medium/low}

  ## 质量评估

  | 维度 | 评分 | 依据 |
  |------|------|------|
  | 覆盖度 | {1-5} | {简要说明} |
  | 来源质量 | {1-5} | {简要说明} |
  | 一致性 | {1-5} | {简要说明} |
  | 具体性 | {1-5} | {简要说明} |
  | 时效性 | {1-5} | {简要说明} |

  **总分**：{average}/5

  ## 缺口分析

  缺失或需要改进的内容：
  1. {具体缺口 1}
  2. {具体缺口 2}

  ## 改进建议

  为解决缺口，搜索：
  1. {具体后续查询 1}
  2. {具体后续查询 2}

  ## 完成评估

  **退出条件（必须全部满足）：**
  - [ ] 覆盖度 > 4.5（即 5/5）
  - [ ] 来源质量 > 4.5（即 5/5）
  - [ ] 一致性 > 4.5（即 5/5）
  - [ ] 具体性 > 4.5（即 5/5）
  - [ ] 时效性 > 4.5（即 5/5）

  **建议**：{CONTINUE_SEARCH / COMPLETE}

  > ⚠️ **硬性标准**：只有所有维度评分均为 5/5 时才能标记为 COMPLETE。任一维度 ≤4 必须继续搜索。
  ```

  **返回给父代理：** 仅返回文件路径和关键结论（如"评分 3.2/5，建议 CONTINUE，写入 turn-1/search-evaluator-turn-1.md"）
```

### 5.2 决策点

**硬性退出标准：所有维度评分 > 4.5（即 5/5）**

基于评估器输出：

**如果所有维度 = 5/5（COMPLETE）：**
- 进入步骤 6
- 在主日志中记录最终评估

**如果任一维度 ≤ 4（CONTINUE_SEARCH）：**
- 提取改进建议
- 针对 ≤4 的维度优先构建新查询
- 返回步骤 3（最多 4 轮）

**注意**：不允许"综合判断"或"总体得分"绕过此标准。任一维度不达标就必须继续。

### 5.3 优化器代理（复杂情况可选）

```yaml
name: query-optimizer
subagent_type: general-purpose
team_name: search-web
timeout: 180000
prompt: |
  你是搜索查询优化器。基于评估器反馈，优化搜索策略。

  原始目标：{goal}

  **读取来源：** 从当前轮次目录读取评估报告
  - `/tmp/search-web/{YYYY-MM-DD}/{task-name}/turn-{round}/search-evaluator-turn-{round}.md`

  **输出文件：** 将优化建议写入 `/tmp/search-web/{YYYY-MM-DD}/{task-name}/turn-{round}/query-optimizer-turn-{round}.md`

  基于评估器识别的缺口，生成 2-3 个新的查询集群。
  避免重复先前的查询。

  **写入文件格式：**
  ```markdown
  # Query Optimizer - Turn {round} Report

  ## 元数据
  - **优化轮次：** {round}
  - **优化时间：** {timestamp}
  - **参考评估：** evaluator-turn-{previous_round}.md

  ## 评估器反馈摘要
  - 主要缺口：{gap_summary}
  - 关键评分：{scores}

  ## 优化的查询集群

  ### 集群 1：{缺口名称 A}
  - 主要："{优化后的查询}"
  - 变体：
    - "{变体 1}"
    - "{变体 2}"
  - 目标站点：{特定站点}
  - 理由：{为什么这能解决缺口}

  ### 集群 2：{缺口名称 B}
  ...

  ## 预期改进
  - 覆盖度提升：{X} → {Y}
  - 具体性提升：通过搜索 {specific_query}
  ```

  **返回给父代理：** 仅返回文件路径和集群数量（如"生成 3 个集群，写入 turn-2/query-optimizer-turn-2.md"）
```

---

## 步骤 6：交付经过验证的结果

### 6.1 最终摘要

向用户返回精简的研究摘要，然后撰写详细报告。

报告写入 `/tmp/search-web/{YYYY-MM-DD}/{task-name}/report.md`：

```markdown
# 研究报告：{task-name}

## 执行摘要
{回答核心问题的 2-3 段文字}

## 关键发现（含置信度）

| 发现 | 证据 | 置信度 |
|------|------|--------|
| {要点 1} | {来源} | 高/中/低 |
| {要点 2} | {来源} | 高/中/低 |

## 质量评估
- 覆盖度：{score}/5 - {简要说明}
- 来源质量：{score}/5 - {简要说明}
- 一致性：{score}/5 - {简要说明}

## 局限性
{仍不确定或需要进一步调查的内容}

## 来源
{带 URL 的关键引用}
```

### 6.2 主日志位置

向用户指出详细日志：
> 完整搜索会话日志：`/tmp/search-web/{YYYY-MM-DD}/{task-name}/master-log.md`

### 6.3 用户审核

询问：
- "研究完成，质量评分 {X}/5。是否足够？"
- "你是否希望我深入调查任何特定发现？"

---

## 多轮协议（带评估器反馈）

**第 1 轮：广泛探索**
- 用通用查询撒大网
- 评估器识别关键缺口

**第 2 轮：针对性调查**
- 解决第 1 轮评估中的具体缺口
- 搜索矛盾证据

**第 3 轮+：深入挖掘**
- 关注评估器中未解决的问题
- 搜索主要来源以填补缺口

**停止条件：**
- **所有维度评分 = 5/5**（硬性标准，不允许综合判断）
- 达到轮次限制（默认：4）
- 用户强制停止

---

## 质量标准参考

### 评分校准

| 分数 | 覆盖度 | 来源质量 | 一致性 | 具体性 | 时效性 |
|------|--------|---------|--------|--------|--------|
| 5 | 所有关键角度深度覆盖 | 多个权威来源 | 强烈共识 | 贯穿具体数据 | 最新且注明日期 |
| 4 | 大部分角度覆盖 | 以权威为主 | 微小差异 | 大部分具体 | 大部分最新 |
| 3 | 有缺口但可接受 | 好坏混合 | 部分矛盾 | 具体与概括混合 | 部分较旧 |
| 2 | 重大缺口 | 低质量为主 | 重大矛盾 | 主要是概括 | 明显过时 |
| 1 | 缺少关键视角 | 未经验证来源 | 完全矛盾 | 模糊论断 | 严重过时 |

---

## 最佳实践

1. **评估器是必需的** — 永远不要跳过质量评估
2. **硬性退出标准** — 所有维度必须达到 5/5，不允许"总体不错"的综合判断
3. **反馈要具体** — 模糊的"再搜索一下"没有帮助
4. **跟踪质量趋势** — 如果分数没有提高，重新考虑方法
5. **记录评估器输出** — 每次评估对透明度都很有价值
6. **前期澄清决定后期质量** — 不要跳过步骤 1 的问题
7. **追问至具体** — 舒适意味着还不够深入

---

## 时效性搜索指南

**当前日期：2026-04-05**

### 时效性敏感主题

为以下内容添加时效性过滤器或时间限定查询：
- **技术版本**（软件发布、框架更新）
- **市场数据**（价格、趋势、统计）
- **时事**（新闻、法规、政策）
- **研究论文**（最新发表、SOTA 结果）

### 时效性查询模式

```
# 最新版本
"{topic} latest version 2025 2026"
"{topic} release notes 2026"

# 当前最佳实践
"{topic} best practices 2025"
"{topic} guide 2026"

# 破坏性变更
"{topic} breaking changes 2025 2026"
"{topic} migration guide"

# 研究
"{topic} paper 2025 2026"
"{topic} benchmark 2025"
```

### 评估器的时效性调整

评估结果时，请考虑搜索日期：
- 2025-2026 年的信息：当前（正常权重）
- 2024 年的信息：对于快速发展的领域可能已过时
- 2023 年或更早的信息：对于技术主题可能已过时

当前是 2026 年，你需要相应调整**时效性**评分，并标记可能过时的关键信息。

---

## 示例会话

**用户请求**："搜索 LLM 代理在 PowerShell 上表现比 Bash 差的证据"

**步骤 1.1（项目重述）：**
- 用户确认研究目标：验证 LLM 代理在 PowerShell vs Bash 的表现差异

**步骤 1.2（目标分类）：**
- 用户选择"验证假设" → 进入聚焦模式

**步骤 1.3（聚焦模式）：**
- Q1 假设："LLM 代理在 PowerShell 上错误率更高"
- Q2 反证标准：需要多个独立基准
- Q3 范围：窄（仅代码生成任务）

**步骤 1.8（需求文档）：**
```yaml
研究目标: 验证 LLM 代理在 PowerShell vs Bash 的表现差异
研究模式: focused
质量阈值: high
时效要求: latest-only
输出格式: detailed-report
特殊角度: [github-issues]
```

**第 1 轮：**
- 查询：通用比较、基准搜索
- 评估器："覆盖度 3/5 - 需要更具体的基准；具体性 2/5 - 需要实际数字"
- 建议：CONTINUE

**第 2 轮：**
- 查询：SWE-bench 结果、pass@k 指标、GitHub issue 分析
- 评估器："覆盖度 4/5；具体性 4/5 - 找到好数据；一致性 3/5 - 一些矛盾论断"
- 建议：CONTINUE

**第 3 轮：**
- 查询：关注矛盾论断、主要来源
- 评估器："所有维度 = 5/5。满足硬性退出标准。"
- 建议：COMPLETE

**交付物**：带置信度评分和质量评估的验证摘要