lionad-morotar/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）

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

研究目标: {提炼后的目标}
研究模式: {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 工具创建搜索任务

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

---

步骤 3：分发子代理搜索

3.1 创建搜索团队

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

3.2 启动并行搜索

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

搜索代理配置：

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 评估器代理

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（需求文档）：

研究目标: 验证 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

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