关于 websearch-deep
websearch-deep 为复杂、多领域问题提供深度研究方法，面向需要整合多来源证据的研究任务。它采用问题拆解、多查询、证据综合和迭代完善流程，并强调引用透明度。
主要功能
- 01拆分研究问题
- 02生成多组搜索查询
- 03整合并评估证据
- 04迭代完善研究结果
- 05强调来源与引用透明
适用场景
- 01比较技术架构或算法
- 02分析市场与供应商
- 03研究政策与技术趋势
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/websearch-deep确认已加载。
详细介绍
深度 Web 研究策略
⚠️ 验证说明（临时调试用）：
使用此 Skill 时，必须创建一个验证文件，以证明已执行：
文件：deep-research-skill-was-executed.md（位于仓库根目录）
内容：
# Deep Research Skill Execution Verification
**Skill**: websearch-deep
**Executed**: {timestamp}
**Research Question**: {the question you researched}
**Mode**: Deep (6-phase methodology)
This file was created by the deep-researcher agent to verify that the websearch-deep Skill was successfully loaded and executed.
**Phases Applied**:
1. ✓ Problem Decomposition (3-5 sub-questions)
2. ✓ Multi-Query Generation (3-5 variations per sub-question)
3. ✓ Evidence Synthesis with Source Ranking (credibility/freshness/relevance)
4. ✓ Citation Transparency (numbered [1][2][3])
5. ✓ Structured Output (token-efficient template)
6. ✓ Iterative Refinement (max 5 iterations)
**Sub-Questions Generated**: {count}
**Queries Executed**: {count}
**Sources Consulted**: {count} ({authoritative_count} authoritative, {recent_count} recent)
**Iterations Performed**: {count}
**Output Format**: Token-efficient template (Executive Summary + Research Overview + Findings + Synthesis + Recommendations + Sources with URLs)
加载此 Skill 后，立即使用 Write 工具创建此文件。
此 Skill 的用途
为需要综合多个领域信息的复杂、多方面问题，提供全面的深度研究方法。通过问题分解、多查询策略、证据综合、引用透明度和迭代优化，实现 ChatGPT 风格的深入调查。
何时使用此 Skill
普遍适用：对于任何需要综合多来源分析和证据综合的问题，都使用此 Skill，包括技术、商业、教育、战略或调查类问题。
支持的问题类型：
- ✅ 技术：架构决策、算法、最佳实践、技术选型
- ✅ 商业：市场分析、竞争研究、供应商比较、趋势
- ✅ 教育：学习资源、概念解释、方法指南
- ✅ 战略：技术路线图、政策分析、决策框架
- ✅ 调查：根因分析、事件研究、模式识别
- ✅ 非技术：远程办公政策、组织架构、流程改进
示例问题：
- “将 X 与 Y 集成的最佳架构是什么？”（技术）
- “我们应该使用微服务还是单体架构？”（战略）
- “远程办公政策有哪些好处？”（商业／非技术）
- “素数生成算法之间有何异同？”（教育／技术）
- “哪些因素应影响我们的云供应商选择？”（商业／战略）
触发词：诸如“架构”“集成”“最佳”“策略”“建议”“比较”“评估”“迁移”“好处”“如何”“为什么”“我们是否应该”等关键词
关键信号：如果问题需要综合多来源分析和证据综合 → 使用此 Skill
说明
阶段 1：问题分解
目标：将复杂问题拆分为 3–5 个清晰、聚焦的子问题。
🔴 关键——研究范围：
深度研究仅查找外部知识——你无法访问代码库。
可以研究的内容：
- ✅ 官方文档：供应商网站（anthropic.com、docs.microsoft.com 等）
- ✅ 博客文章和资料：技术博客、Medium、Dev.to、工程博客
- ✅ 社区资源：Stack Overflow、GitHub 讨论、Reddit、论坛
- ✅ 行业最佳实践：设计模式、架构模式、标准方法
- ✅ 学术论文：研究论文、白皮书、会议论文集
- ✅ 库文档：通过 Context7 MCP（解析库 → 获取文档）
- ✅ Web 内容：通过 Fetch MCP 获取 HTML 内容
无法研究的内容：
- ❌ 项目内部文件：没有可用的 Read/Grep/Glob 工具
- ❌ 代码库模式：改用 /explain:architecture 或 research-codebase-analyst
- ❌ 项目特定实现：不属于外部研究范围
如果问题询问“我的项目”或“此代码库”： 从 Agent 文件（范围验证部分）返回错误并停止。
流程：
- 确定主要研究问题
- 分析问题结构和意图
- 将问题分解为逻辑子部分，共同完整回答整个问题
子问题标准：
- 具体：每个子问题都有清晰、聚焦的范围
- 完整：所有子问题合起来覆盖整个问题
- 独立：可以分别研究
- 可执行：能得出具体发现
分解示例：
Primary: "What's the best architecture for integrating Salesforce with SQL Server in 2025?"
Sub-Questions:
1. What are Salesforce's current integration capabilities and APIs (2025)?
2. What are SQL Server's integration patterns and best practices?
3. What middleware or integration platforms are commonly used?
4. What security and compliance considerations matter?
5. What scalability and performance factors should influence choice?
阶段 2：多查询生成
目标：为每个子问题生成 3-5 个查询变体，以最大限度地扩大覆盖范围（共 15-25 次搜索）。
查询变体策略：
- 变体 1 - 宽泛/通用："Salesforce integration APIs 2025"
- 变体 2 - 具体/技术："Salesforce REST API bulk data operations"
- 变体 3 - 比较/替代方案："Salesforce API vs MuleSoft vs Dell Boomi"
- 变体 4 - 最佳实践："Salesforce SQL Server integration patterns"
- 变体 5 - 最新更新："Salesforce API updates 2025"
高级搜索运算符：
site:domain.com- 搜索特定域名filetype:pdf- 查找 PDF 文档intitle:"keyword"- 搜索页面标题inurl:keyword- 搜索 URLafter:2024- 仅搜索近期内容"exact phrase"- 精确匹配
多查询集示例：
Sub-Q1: Salesforce Integration Capabilities
- site:salesforce.com "API" "integration" "2025"
- "Salesforce REST API" "rate limits" after:2024
- "Salesforce Bulk API 2.0" "best practices"
- filetype:pdf "Salesforce integration guide" 2025
- "Salesforce API" "breaking changes" after:2024
常见研究类型的查询模板
使用以下模板，为不同研究类型拟定高质量查询：
1. 技术架构研究
Official Docs: site:docs.{vendor}.com "{topic}" "architecture patterns" OR "design patterns"
Best Practices: "{topic}" "best practices" "production" after:2024
Comparisons: "{topic}" vs "{alternative}" "comparison" "pros cons"
Limitations: "{topic}" "limitations" OR "drawbacks" OR "challenges"
Recent Updates: site:{vendor}.com "{topic}" "updates" OR "changes" after:2024
2. 框架/库研究
Official Docs: site:docs.{framework}.com "{feature}" "guide" OR "documentation"
Community: site:stackoverflow.com "{framework}" "{feature}" "how to"
Real-World: "{framework}" "{feature}" "production" OR "case study" after:2024
Performance: "{framework}" "performance" OR "benchmarks" OR "optimization"
Ecosystem: "{framework}" "ecosystem" OR "plugins" OR "extensions" 2025
3. 业务/战略研究
Industry Analysis: "{topic}" "market analysis" OR "industry trends" 2024 2025
Vendor Comparison: "{vendor A}" vs "{vendor B}" "comparison" "review"
ROI/Benefits: "{solution}" "ROI" OR "benefits" OR "value proposition"
Implementation: "{solution}" "implementation guide" OR "getting started"
Case Studies: "{solution}" "case study" OR "customer success" after:2024
4. 教育/学习研究
Fundamentals: "{topic}" "introduction" OR "beginner guide" OR "explained"
Advanced: "{topic}" "advanced" OR "deep dive" OR "internals"
Tutorials: "{topic}" "tutorial" OR "step by step" after:2024
Common Mistakes: "{topic}" "common mistakes" OR "anti-patterns" OR "pitfalls"
Resources: "{topic}" "learning resources" OR "courses" OR "books" 2025
5. 合规/安全研究
Standards: "{topic}" "{standard}" "compliance" (e.g., "GDPR", "SOC2", "HIPAA")
Security: "{topic}" "security" "best practices" OR "vulnerabilities" after:2024
Official Guidance: site:{regulator}.gov "{topic}" "guidance" OR "requirements"
Audit: "{topic}" "audit" OR "checklist" OR "certification"
Tools: "{topic}" "{compliance}" "tools" OR "automation" 2025
6. 性能/优化研究
Benchmarks: "{topic}" "benchmark" OR "performance" "comparison" after:2024
Bottlenecks: "{topic}" "bottleneck" OR "slow" OR "performance issues"
Optimization: "{topic}" "optimization" OR "tuning" OR "best practices"
Monitoring: "{topic}" "monitoring" OR "observability" OR "metrics"
Scaling: "{topic}" "scalability" OR "high traffic" OR "production scale"
优先级：先查官方来源
- 始终先执行
site:anthropic.com或site:docs.{vendor}.com查询 - 使用官方文档的结果来完善社区/博客查询
- 将官方指南与实际经验交叉核对
🔴 关键：分批并行执行查询
执行模式（性能所必需）：
不要按顺序逐个执行查询。应将查询分成每组 5-10 个，并在单条消息中并行执行。
分批策略：
- 提前生成全部 15-25 个查询（涵盖所有子问题）
- 将查询分成每批 5-10 个
- 在单条消息中通过多次 WebSearch 工具调用执行每一批
- 等待本批完成后，再继续下一批
实现模式：
# Step 1: Generate all queries first
all_queries = []
for sub_question in sub_questions:
queries = generate_query_variations(sub_question) # 3-5 queries per sub-Q
all_queries.extend(queries)
# Total: 15-25 queries across all sub-questions
# Step 2: Execute in parallel batches
batch_size = 5 # Adjust 5-10 based on query complexity
for i in range(0, len(all_queries), batch_size):
batch = all_queries[i:i+batch_size]
# Step 3: Execute ALL queries in batch SIMULTANEOUSLY in single message
# Example: If batch = [q1, q2, q3, q4, q5], call:
# WebSearch(q1)
# WebSearch(q2)
# WebSearch(q3)
# WebSearch(q4)
# WebSearch(q5)
# ALL FIVE in the SAME message as parallel tool uses
results = execute_parallel_batch(batch)
process_batch_results(results) # Collect sources immediately
重要性：
- 顺序执行：25 个查询 × 每个 1 秒 = 总计 25 秒
- 分批执行（每批 5 个）：5 批 × 1 秒 = 总计 5 秒
- 提速：阶段 2 快 3-5 倍
批次大小指南：
- 简单查询（仅关键词）：使用 batch_size=10
- 复杂查询（高级运算符、多个 site: 筛选条件）：使用 batch_size=5
- 第 2 轮及之后的重新查询：使用 batch_size=3-5
分批执行示例：
Generated 25 queries across 5 sub-questions
Batch 1 (5 queries - executed in parallel):
WebSearch("site:salesforce.com 'API' 'integration' '2025'")
WebSearch("'Salesforce REST API' 'rate limits' after:2024")
WebSearch("'Salesforce Bulk API 2.0' 'best practices'")
WebSearch("filetype:pdf 'Salesforce integration guide' 2025")
WebSearch("'Salesforce API' 'breaking changes' after:2024")
→ Batch completes in ~1s, 5 results returned
Batch 2 (5 queries - executed in parallel):
WebSearch("'SQL Server ETL' 'best practices' 'real-time'")
WebSearch("site:docs.microsoft.com 'SQL Server' 'integration'")
...
→ Batch completes in ~1s, 5 results returned
Total: 5 batches × 1s each = ~5s (vs 25s sequential)
阶段 3：证据综合
目标：收集、排序、去重并综合多个来源的证据。
处理分批结果：
由于阶段 2 按并行批次执行查询，你会收到按批次分组的结果。请将所有批次的结果放在一起处理：
- 展平结果：合并批次 1 + 批次 2 + 批次 3 + ... → 单一的统一结果列表
- 去重：删除所有批次中的重复 URL（同一来源可能出现在多个查询中）
- 对所有来源排序：对展平后的完整列表（而非单个批次）应用 0-10 分评分
- 继续综合：使用统一、去重并排序后的来源列表综合证据
示例：
# Collect results from all batches
all_results = []
all_results.extend(batch1_results) # 5 results from batch 1
all_results.extend(batch2_results) # 5 results from batch 2
all_results.extend(batch3_results) # 5 results from batch 3
all_results.extend(batch4_results) # 5 results from batch 4
all_results.extend(batch5_results) # 5 results from batch 5
# Total: ~25 results (before deduplication)
# Deduplicate by URL
unique_sources = deduplicate_by_url(all_results)
# After dedup: ~15-20 unique sources (duplicates removed)
# Rank all unique sources
ranked_sources = rank_sources(unique_sources) # Apply scoring below
3a. 来源评分（0-10 分）
从三个维度为每个来源评分：
可信度评分（0-10）：
- 10：官方文档、同行评审论文
- 7-9：知名科技媒体（TechCrunch、Ars Technica）、信誉良好的供应商
- 4-6：技术博客、Stack Overflow、社区论坛
- 1-3：未经核实的来源、营销内容、个人博客
时效性评分（0-10）：
- 10：在过去 3 个月内发布
- 7-9：在过去 6-12 个月内发布
- 4-6：在过去 1-2 年内发布
- 1-3：发布于 2 年以前
相关性评分（0-10）：
- 10：直接回答子问题，并提供具体示例
- 7-9：回答子问题，但细节不完整
- 4-6：间接相关，需要解读
- 1-3：仅简要提及主题，参考价值有限
来源综合质量 =（可信度 × 0.5）+（时效性 × 0.2）+（相关性 × 0.3）
3b. 去重
- 识别不同来源中的重复发现
- 存在重复内容时，优先采用质量更高的来源（综合评分）
- 记录共识：3 个或更多来源意见一致 = 强信号
- 标记异议观点：只有一个来源提出的独特主张
3c. 矛盾解决
来源之间存在矛盾时：
- 检查日期：较新的来源可能反映了近期变化
- 评估权威性：官方文档优先于博客文章
- 呈现两种观点：“来源 A [1] 建议采用 X，而来源 B [2] 则建议采用 Y，因为……”
- 解释适用场景：“具体方案取决于规模：记录数 <100k 时采用 X [1]，>1M 时采用 Y [2]”
阶段 4：引用透明度（可点击格式）
目标：为每项事实性声明提供带编号的可点击引用。
🔴 关键要求 - 使用描述性内联链接：
内联引用格式（描述性名称 — 自然语言）：
Text with claim from [OpenAI: GPT-4](https://url "GPT-4 Technical Report (OpenAI, 2023-03-14)") and [Anthropic: Claude](https://url2 "Introducing Claude (Anthropic, 2023-03-14)"). Multiple sources: [Google DeepMind: Gemini](https://url3 "Gemini Model (Google DeepMind, 2023-12-06)"), [Meta: LLaMA](https://url4 "LLaMA Paper (Meta AI, 2023-02-24)").
为什么要使用描述性名称？
- ✅ 内联阅读更流畅（符合自然语言表达）
- ✅ 自我说明（读者无需查看参考资料即可了解来源）
- ✅ 仍可点击，并带有工具提示
- ✅ 适用于所有 Markdown 查看器（GitHub、VS Code、Obsidian、GitLab、终端）
格式：
[Organization: Topic](full-URL "Full Title (Publisher, YYYY-MM-DD)")
创建描述性名称（根据 URL 分析）：
- 提取组织名称：从域名提取（openai.com → OpenAI，anthropic.com → Anthropic）
- 提取主题：从 URL 路径或标题提取（gpt-4 → GPT-4，claude → Claude）
- 使用格式：
[组织：主题] - 重复来源：添加描述性后缀 —
[OpenAI：GPT-4]、[OpenAI：DALL-E]、[OpenAI：Whisper] - 通用页面：使用页面类型 —
[Stack Overflow：OAuth 实现]、[Medium：React 模式]
参考资料部分格式（位于研究内容末尾，按类别分组）：
## References
### Official Documentation
- **OpenAI: GPT-4** (2023-03-14). "GPT-4 Technical Report". https://openai.com/research/gpt-4
- **Anthropic: Claude** (2023-03-14). "Introducing Claude". https://www.anthropic.com/claude
### Blog Posts & Articles
- **Google DeepMind: Gemini** (2023-12-06). "Gemini: A Family of Highly Capable Models". https://deepmind.google/technologies/gemini
- **Meta: LLaMA** (2023-02-24). "Introducing LLaMA". https://ai.meta.com/blog/llama
### Academic Papers
- **Attention Is All You Need** (2017-06-12). Vaswani et al. https://arxiv.org/abs/1706.03762
### Community Resources
- **Stack Overflow: OAuth Implementation** (2024-08-15). https://stackoverflow.com/questions/12345
为什么要对参考资料部分进行分组？
- 按来源类型整理列表，便于浏览
- 方便区分权威来源与社区来源
- 一目了然地展示证据的多样性
- 可复制粘贴，以便进一步研究
类别说明：
- 官方文档：供应商文档、API 参考、官方指南
- 博客文章与文稿：公司工程博客、Medium、Dev.to、技术文章
- 学术论文：arXiv、研究论文、会议论文集、白皮书
- 社区资源：Stack Overflow、GitHub 讨论、Reddit、论坛
引号内的标题格式：
"完整标题（发布方，YYYY-MM-DD）"- 标题应简洁但能准确描述内容（如有可能，不超过 80 个字符）
- 始终注明发布方和日期，以提高可信度
悬停行为： 大多数 Markdown 查看器（GitHub、VS Code、Obsidian、GitLab）会在将鼠标悬停于引用时显示标题作为工具提示。
点击行为： 点击描述性名称会在浏览器中直接打开 URL。
内联用法示例：
Salesforce provides three primary API types according to [Salesforce: API Docs](https://developer.salesforce.com/docs/apis "Salesforce API Documentation (Salesforce, 2025-01-15)"): REST API for standard operations, [Salesforce: Bulk API 2.0](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/ "Bulk API 2.0 Guide (Salesforce, 2024-11-20)") for large data volumes (>10k records), and [Salesforce: Streaming API](https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/ "Streaming API Guide (Salesforce, 2024-10-05)") for real-time updates. Recent 2025 updates introduced enhanced rate limiting (100k requests/24hrs for Enterprise) and improved error handling as noted in [Salesforce Blog: API Updates](https://developer.salesforce.com/blogs/2025/01/api-updates "API Error Handling Improvements (Salesforce Blog, 2025-01-10)").
## References
### Official Documentation
- **Salesforce: API Docs** (2025-01-15). "Salesforce API Documentation". https://developer.salesforce.com/docs/apis
- **Salesforce: Bulk API 2.0** (2024-11-20). "Bulk API 2.0 Developer Guide". https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/
- **Salesforce: Streaming API** (2024-10-05). "Streaming API Developer Guide". https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/
### Blog Posts & Articles
- **Salesforce Blog: API Updates** (2025-01-10). "API Error Handling Improvements". https://developer.salesforce.com/blogs/2025/01/api-updates
兼容性：适用于 GitHub、VS Code（预览）、Obsidian、GitLab 以及所有 Markdown 查看器
阶段 5：结构化输出（均衡型——目标 250–350 行）
目标：提供全面、可直接用于实施的研究结果，并深入阐述相关内容。
设计原则：
- ✅ 深度均衡（250–350 行）——既不过于冗长，也不过度精简
- ✅ 与代码仓库无关（不包含特定仓库的细节）
- ✅ 可直接用于实施（执行摘要 + 建议指导后续步骤）
- ✅ 来源包含完整 URL（不可妥协）
- ✅ 通用（适用于任何问题：技术、业务、教育、战略）
输出模板：
# Deep Research: {Question}
## Executive Summary
{2-3 paragraph synthesis covering:
- What was researched and why it matters
- Key findings with citations [Org: Topic]
- Strategic recommendation with rationale}
Example length: ~150-200 words total across 2-3 paragraphs.
## Research Overview
- **Sub-Questions Analyzed**: {count}
- **Queries Executed**: {count} queries
- **Sources**: {count} total ({authoritative_count} authoritative / {auth_pct}%, {recent_count} recent / {recent_pct}%)
- **Iterations**: {count}
## Findings
### 1. {Sub-Question 1}
{Opening paragraph: What this sub-question addresses and why it's important}
{2-4 paragraphs of synthesized narrative with inline citations [1][2][3]. Each paragraph covers a specific aspect or theme. Include:
- Core concepts and definitions with citations
- How different sources approach the topic
- Practical implications and examples
- Performance characteristics or trade-offs where relevant}
**Key Insights**:
- {Insight 1: Specific, actionable statement} - {Why it matters and implications} [Org: Topic], [Org: Topic]
- {Insight 2: Specific, actionable statement} - {Why it matters and implications} [Org: Topic]
- {Insight 3: Specific, actionable statement} - {Why it matters and implications} [Org: Topic]
{Optional: **Common Patterns** or **Best Practices** subsection if relevant with 2-3 bullet points}
### 2. {Sub-Question 2}
{Repeat the same structure: Opening paragraph + 2-4 narrative paragraphs + 3-5 Key Insights}
{...continue for all sub-questions...}
## Synthesis
{2-3 paragraphs integrating findings across sub-questions. Show how the pieces fit together and what the big picture reveals.}
**Consensus** (3+ sources agree):
- {Consensus point 1 with source count} [Org: Topic], [Org: Topic], [Org: Topic]
- {Consensus point 2 with source count} [Org: Topic], [Org: Topic], [Org: Topic], [Org: Topic]
**Contradictions** *(if present)*:
- **{Topic}**: {Source A perspective [Org: Topic]} vs {Source B perspective [Org: Topic]}. {Resolution or context explaining difference}
**Research Gaps** *(if any)*:
- {Gap 1}: {What wasn't found and why it matters}
## Recommendations
### Critical (Do First)
1. **{Action}** - {Detailed rationale explaining why this is critical, what happens if not done, and expected impact} [Org: Topic], [Org: Topic]
2. **{Action}** - {Detailed rationale} [Org: Topic]
3. **{Action}** - {Detailed rationale} [Org: Topic]
### Important (Do Next)
4. **{Action}** - {Rationale with evidence and expected benefit} [Org: Topic]
5. **{Action}** - {Rationale with evidence} [Org: Topic]
6. **{Action}** - {Rationale with evidence} [Org: Topic]
### Optional (Consider)
7. **{Action}** - {Rationale and when/why you might skip this} [Org: Topic]
8. **{Action}** - {Rationale} [Org: Topic]
## References
### Official Documentation
- **{Org: Topic}** ({YYYY-MM-DD}). "{Full Title}". {Full URL}
- **{Org: Topic}** ({YYYY-MM-DD}). "{Full Title}". {Full URL}
### Blog Posts & Articles
- **{Org: Topic}** ({YYYY-MM-DD}). "{Full Title}". {Full URL}
### Academic Papers
- **{Paper Title}** ({YYYY-MM-DD}). {Authors}. {Full URL}
### Community Resources
- **{Platform: Topic}** ({YYYY-MM-DD}). {Full URL}
长度指南：
- 执行摘要：150–200 字
- 每个发现部分：300–400 字（开篇 + 叙述 + 洞见）
- 综合分析：200–250 字
- 建议：3 条关键建议 + 3–4 条重要建议 + 2–3 条可选建议，并详细说明理由
- 总目标：250–350 行
要求：
- 执行摘要：可在 <30 秒内浏览完毕，并完整概述整体情况
- 发现：每个部分包含 2–4 段叙述，外加 3–5 条关键洞见
- 叙述段落解释概念、展示证据并串联观点
- 关键洞见提炼出可执行的要点
- 综合分析：呈现全局情况，指出共识（并注明来源数量），探讨相互矛盾之处
- 建议：为每条建议详细说明理由（不能只有项目符号和引用）
- 来源：必须包含完整 URL、标题、作者／组织和日期
不应包含的内容（浪费令牌）：
- ❌ 带数字评分（0–10 分）的证据表格
- ❌ 特定仓库的细节（例如“主线程日志”“CARE 质量评分”）
- ❌ 单独的优缺点部分（应整合到建议中）
- ❌ 冗长的迭代日志或详细的方法步骤
阶段 6：迭代优化
目标：验证完整性并针对缺失内容重新查询（最多 5 次迭代）。
完整性验证清单：
- 所有子问题都有发现，并引用 3 个或更多来源？
- 已识别并解释矛盾之处？（如果没有，请明确说明“未发现矛盾”）
- 已纳入近期来源（过去 6–12 个月内）？
- 已优先采用权威来源（官方文档）？
- 已提供实用建议（3 条关键建议 + 3–4 条重要建议 + 2–3 条可选建议）？
- 已明确指出研究空白？
自动缺口检测逻辑：
gaps = []
completeness_score = 100
# Check citation coverage
for sub_q in sub_questions:
citation_count = count_citations(sub_q)
if citation_count < 3:
gaps.append(f"Sub-Q{i}: Only {citation_count} citations (need 3+)")
completeness_score -= 10
# Check for contradictions exploration
if contradictions_section_empty():
gaps.append("No contradictions explored - search for '{topic} criticisms' OR '{topic} limitations'")
completeness_score -= 10
# Check authoritative source coverage
auth_sources = count_authoritative_sources() # credibility >= 8
if auth_sources < total_sources * 0.5:
gaps.append(f"Only {auth_sources} authoritative sources ({round(auth_sources/total_sources*100)}%) - need 50%+")
completeness_score -= 10
# Check recency
recent_sources = count_recent_sources() # within 6 months
if recent_sources < total_sources * 0.3:
gaps.append(f"Only {recent_sources} recent sources ({round(recent_sources/total_sources*100)}%) - need 30%+")
completeness_score -= 5
# Check recommendation depth
if critical_recommendations < 3:
gaps.append(f"Only {critical_recommendations} Critical recommendations (need 3)")
completeness_score -= 10
# Check for research gaps section
if research_gaps_section_missing():
gaps.append("Research Gaps section missing - document what wasn't found")
completeness_score -= 5
return completeness_score, gaps
重新查询决策逻辑：
iteration_count = 1
completeness_score, gaps = validate_completeness()
# 🔴 MANDATORY: Always perform minimum 2 iterations
# Even if iteration 1 achieves 85%+, iteration 2 improves depth
if iteration_count < 2 or (completeness_score < 85% and iteration_count <= 5):
# Generate targeted re-queries for each gap
requery_list = []
for gap in gaps:
if "citations" in gap:
# Need more sources for specific sub-question
requery_list.append(f"'{sub_question_topic}' 'detailed guide' OR 'comprehensive overview'")
elif "contradictions" in gap:
# Need to explore downsides/criticisms
requery_list.append(f"'{topic}' 'criticism' OR 'limitations' OR 'downsides'")
requery_list.append(f"'{topic}' 'vs' 'alternative' 'when not to use'")
elif "authoritative" in gap:
# Need more official sources
requery_list.append(f"site:docs.{vendor}.com '{topic}' 'official'")
requery_list.append(f"site:{vendor}.com '{topic}' 'documentation'")
elif "recent" in gap:
# Need more recent sources
requery_list.append(f"'{topic}' 'updates' OR 'changes' after:2024")
requery_list.append(f"'{topic}' '2025' OR '2024' 'latest'")
# Execute re-queries in parallel batch (1-5 queries)
# Use smaller batch size for re-queries since they're targeted
requery_batch = requery_list[:5] # Up to 5 re-queries
# Execute ALL re-queries in batch SIMULTANEOUSLY in single message
# Example: If requery_batch = [rq1, rq2, rq3], call:
# WebSearch(rq1)
# WebSearch(rq2)
# WebSearch(rq3)
# ALL THREE in the SAME message as parallel tool uses
execute_parallel_batch(requery_batch)
iteration_count += 1
# Update findings incrementally
append_iteration_findings()
completeness_score, gaps = validate_completeness()
else:
# Either complete (≥85%) or max iterations reached
if completeness_score < 85%:
note_limitations_in_research_gaps_section(gaps)
finalize_output()
迭代更新模式： 添加后续迭代中获得的发现时，将其追加到现有部分：
### 1. {Sub-Question}
{Original findings from iteration 1}
**Iteration 2 Additions**:
{New findings from re-queries, with citations [Org: Topic], [Org: Topic], [Org: Topic]}
**Key Insights**:
- {Original insight 1} [Org: Topic]
- {Original insight 2} [Org: Topic]
- {NEW insight from iteration 2} [Org: Topic], [Org: Topic]
停止迭代的条件：
- 🔴 必须：至少迭代 2 次（iteration_count >= 2）
- ✅ 完整性评分 ≥ 85%
- ✅ 所有子问题都有 3 个或更多引用
- ✅ 已填写矛盾部分（或明确注明“未发现”）
- ✅ 权威来源占比超过 50%，近期来源占比超过 30%
- ✅ 至少有 3 条关键建议
- ⏱️ 或 iteration_count > 5（达到最大迭代次数）
仅在以下情况下停止：(iteration_count >= 2 AND completeness >= 85%) OR iteration_count > 5
达到最大迭代次数但完整性未达 85% 时： 添加明确的“研究空白”部分：
## Research Gaps
Due to iteration limit, the following gaps remain:
- {Gap 1}: {What's missing and why it matters}
- {Gap 2}: {What's missing and suggested follow-up approach}
示例
示例 1：架构决策研究
场景：用户询问：“2025 年，将 Salesforce 与 SQL Server 集成的最佳架构是什么？”
流程：
阶段 1——问题拆解：
Sub-Q1: Salesforce integration capabilities (2025)?
Sub-Q2: SQL Server integration patterns?
Sub-Q3: Middleware options?
Sub-Q4: Security considerations?
Sub-Q5: Scalability factors?
阶段 2——生成多条查询并批量执行：
Generated 25 queries across 5 sub-questions
Batch 1 (5 queries - executed in parallel):
WebSearch("site:salesforce.com 'API' 'integration' '2025'")
WebSearch("'Salesforce REST API' 'rate limits' after:2024")
WebSearch("'Salesforce Bulk API 2.0' 'best practices'")
WebSearch("filetype:pdf 'Salesforce integration guide' 2025")
WebSearch("'Salesforce API' 'breaking changes' after:2024")
→ Batch completes in ~1s, 5 results returned
Batch 2 (5 queries - executed in parallel):
WebSearch("'SQL Server ETL' 'best practices' 'real-time'")
WebSearch("site:docs.microsoft.com 'SQL Server' 'integration'")
WebSearch("'SQL Server Always On' 'high availability'")
WebSearch("'SQL Server CDC' 'change data capture'")
WebSearch("'SQL Server linked servers' 'performance'")
→ Batch completes in ~1s, 5 results returned
Batch 3-5 (15 more queries across 3 batches):
... (middleware, security, scalability queries)
→ Each batch completes in ~1s
Execution Time:
- 5 batches × ~1s each = ~5s total
- Sequential would be: 25 queries × 1s = 25s
- Speedup: 5x faster
阶段 3——证据：
18 sources identified
12 ranked as authoritative (credibility ≥ 8)
3 contradictions (real-time vs batch approaches)
阶段 4——引用：
[1] Salesforce API Guide (Cred: 10, Fresh: 10, Rel: 10, Overall: 10.0)
[2] MuleSoft Patterns (Cred: 9, Fresh: 8, Rel: 9, Overall: 8.9)
阶段 5——输出：
Executive Summary: 2 paragraphs
Findings: 5 sub-sections with 28 citations
Recommendations: 3 critical, 4 important, 2 enhancements
阶段 6——优化：
Iteration 1: Identified gap in disaster recovery
Iteration 2: Re-queried "Salesforce SQL backup strategies"
Iteration 3: Completeness 92% → finalized
输出：深度模式上下文文件，包含执行摘要、5 项子问题分析、证据表、综合分析、优缺点和 28 条引用
示例 2：技术选型研究
场景：“我们的电商平台应该采用微服务架构还是单体架构？”
流程：
问题拆解：
1. Scalability characteristics for e-commerce?
2. Team size and DevOps implications?
3. Transaction patterns differences?
4. Deployment complexity trade-offs?
5. Real-world e-commerce case studies?
多条查询（示例）：
"microservices e-commerce" "scalability" after:2024
"monolith vs microservices" "team size" "best practices"
site:aws.amazon.com "e-commerce architecture" "patterns"
证据综合分析：
15 sources (10 authoritative)
Consensus: Team size <20 → monolith, >50 → microservices
Contradiction: Database approach (shared vs distributed)
输出：结构化分析，包含两种方案的优缺点、团队规模建议、迁移注意事项，以及附有引用的案例研究
最佳实践
- 先广后窄：先从一般性查询开始，再根据初步发现深入探究具体问题
- 交叉核实多个来源：切勿依赖单一来源；应通过 3 个或更多来源交叉核实关键论断
- 优先选择近期资料：对于技术主题，优先选择发布于 1 年内的来源
- 优先查阅官方文档：从官方文档开始，再补充社区见解
- 记录矛盾之处：不要隐瞒相互矛盾的信息；应结合背景呈现
- 必要时迭代：不要强求面面俱到；如果经过 5 次迭代后仍有缺漏，请注明局限性
- 严谨引用：每项事实性论断都需要编号引用
常见模式
模式 1：架构决策研究
- 分解为：当前状态、需求、选项、权衡、案例研究
- 多路查询：官方文档、供应商对比、实际落地案例
- 综合：制作包含引用证据的优缺点矩阵
模式 2：技术迁移研究
- 分解为：当前技术评估、目标技术能力、迁移路径、风险分析、时间线估算
- 多路查询：迁移指南、成功/失败案例、工具对比
- 综合：制定包含风险缓解措施的分步迁移计划
模式 3：最佳实践研究
- 分解为：行业标准、常见模式、反模式、工具、案例研究
- 多路查询：官方指南、专家博客、会议演讲、GitHub 仓库
- 综合：汇总最佳实践清单并说明理由
故障排查
问题 1：来源过多，难以综合
- 聚焦排名靠前的来源（总分 ≥ 7.0）
- 按主题归类研究发现，而非按来源归类
- 先找出共识，再指出不同意见
问题 2：信息相互矛盾
- 检查发布日期（较新的资料可能反映近期变化）
- 评估来源权威性（官方 > 博客）
- 查找背景信息（矛盾可能取决于具体场景）
- 附上引用，呈现双方观点
问题 3：近期来源不足
- 将日期范围扩展至最近 2 年
- 检查技术名称是否变更（新旧术语）
- 结合近期来源与较早但权威的来源
- 在输出中注明：“基于 2023 年的来源；2025 年的更新有待核实”
问题 4：完整度低于 85%
- 找出具体缺口（哪些子问题的探究不够深入？）
- 针对性地重新查询 1–3 次
- 如果经过 3 次迭代后仍低于 85%，请明确注明局限性
集成点
- WebSearch Tool：通过 WebSearch 执行所有搜索查询
- Context7 MCP：适用时，补充官方框架/库文档
- 证据表：以结构化格式记录所有来源，以便评估质量
- 上下文文件：将研究发现保存到
.agent/Session-{name}/context/research-web-analyst.md
关键术语
- 子问题：主要研究问题中的一个聚焦组成部分
- 查询变体：以不同措辞/角度表达同一信息需求
- 来源质量评分：综合指标（可信度 + 时效性 + 相关性）
- 共识观点：得到 3 个或更多相互独立的权威来源支持的研究发现
- 矛盾：多个来源提出相互冲突的论断，需要结合背景理解
- 完整度评分：有充分证据支持的研究目标所占百分比
- 迭代：研究周期（查询 → 收集 → 综合 → 验证）
其他资源
评论
支持 Markdown