| name | search-web |
| description | 使用 Evaluator-optimizer 模式进行系统性多轮网络搜索，采用结构化 Ask 流程在搜索前澄清研究目标。基于 YC Office Hours 的提问方法论，确保搜索方向清晰、结果可验证。当用户需要深入调查复杂主题、验证假设或全面收集信息时使用。 |
| disable-model-invocation | true |
网络搜索
概述
本技能采用 Evaluator-optimizer 模式 进行系统性多轮网络研究，搜索前使用结构化 Ask 流程澄清需求。核心特性：
- 三层 Ask 框架 — 研究目标分类 → 模式专用提问 → YAML 需求文档
- 智能跳过规则 — 根据用户输入自动跳过已回答的问题
- Escape hatch 快速模式 — 用户不耐烦时提供可控降级选项
- 研究模式分类 — 聚焦/扫描/全面三种模式对应不同策略
- 评估器 - 优化器循环 — 质量驱动的迭代搜索
工作流程：
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 调用必须遵循以下结构：
-
Re-ground (1-2 句)
-
Simplify
- 用 16 岁能懂的语言解释问题
- 避免内部术语，使用具体例子
-
Recommend
RECOMMENDATION: 选择 [X] 因为 [一行理由]- 包含
Completeness: X/10
-
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：特殊角度
是否需要关注特定视角？（可多选）
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
- **查询：** "{query}"
- **集群：** {cluster_name}
- **启动时间：** {timestamp}
- **状态：** {running/completed/error}
- 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
- **评估轮次：** {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 轮：针对性调查
第 3 轮+：深入挖掘
停止条件：
- 所有维度评分 = 5/5（硬性标准，不允许综合判断）
- 达到轮次限制（默认：4）
- 用户强制停止
质量标准参考
评分校准
| 分数 | 覆盖度 | 来源质量 | 一致性 | 具体性 | 时效性 |
|---|
| 5 | 所有关键角度深度覆盖 | 多个权威来源 | 强烈共识 | 贯穿具体数据 | 最新且注明日期 |
| 4 | 大部分角度覆盖 | 以权威为主 | 微小差异 | 大部分具体 | 大部分最新 |
| 3 | 有缺口但可接受 | 好坏混合 | 部分矛盾 | 具体与概括混合 | 部分较旧 |
| 2 | 重大缺口 | 低质量为主 | 重大矛盾 | 主要是概括 | 明显过时 |
| 1 | 缺少关键视角 | 未经验证来源 | 完全矛盾 | 模糊论断 | 严重过时 |
最佳实践
- 评估器是必需的 — 永远不要跳过质量评估
- 硬性退出标准 — 所有维度必须达到 5/5，不允许"总体不错"的综合判断
- 反馈要具体 — 模糊的"再搜索一下"没有帮助
- 跟踪质量趋势 — 如果分数没有提高，重新考虑方法
- 记录评估器输出 — 每次评估对透明度都很有价值
- 前期澄清决定后期质量 — 不要跳过步骤 1 的问题
- 追问至具体 — 舒适意味着还不够深入
时效性搜索指南
当前日期：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
交付物：带置信度评分和质量评估的验证摘要
