deepsearch

# DeepSearch 深度检索工作流 ## 什么时候使用 - 需要系统性研究一个复杂主题（不是简单问答） - 需要从多个维度/来源验证信息 - 要求生成结构化、可追溯的调研报告 - 愿意参与多轮迭代过程的用户 ## 设计原则 1. **检查点模式**：每完成一个检查点就通知用户，保持参与感 2. **并发控制**：最多4个subagent并行，保证质量（官方推荐0.5倍于默认8） 3. **多轮迭代**：支持基于中间结果补充检索 4. **用户不打扰**：明确的进度状态让用户知道agent正在工作 ## 工作流程 ### Phase 1: 需求澄清与规划（检查点 #1） **目标**: 明确检索范围，获得用户确认 **执行**: 1. 分析用户查询，识别核心问题和关键维度 2. 初步规划 3-5 个检索维度（根据复杂度调整） 3. **检查点**: 向用户展示规划 ``` 📋 检索规划 主题: [用户查询] 计划检索维度: 1. [维度1] - [预期获取的信息] 2. [维度2] - [预期获取的信息] 3. [维度3] - [预期获取的信息] 预计并发: 3-4 个subagent 预计时间: 2-5 分钟 确认执行请回复 "开始"，或调整维度。 ``` **用户确认后进入 Phase 2** ### Phase 2: 第一轮并行检索（检查点 #2..#N） **目标**: 并行执行多个维度的深度检索 **并发控制**: ```yaml maxConcurrentSubagents: 4 # 严格限制，保证稳定性 spawnMode: "run" # one-shot模式，完成后自动清理 ``` **执行**: 1. **Spawn Subagents**（最多4个并行）: ```typescript sessions_spawn({ task: "深度检索[维度1]...", label: "dim-1-official", // 命名规范: 轮次-维度-来源类型 mode: "run", cleanup: "delete" }) // ... 最多4个 ``` 2. **立即通知用户**: ``` 🚀 启动检索 已启动 N 个并行检索任务: • [dim-1] 官方文档与白皮书 • [dim-2] 技术社区讨论 • [dim-3] 竞品对比分析 • [dim-4] 最新动态新闻 ⏱️ 预计 1-3 分钟完成，完成后将自动汇报... ``` 3. **等待回调**（自动触发）: - 每个subagent完成后自动推送结果 - **检查点**: 每完成一个就更新进度 ``` ✅ 进度更新 (2/4 完成) [dim-1] 官方文档检索完成 关键发现: [1-2句话总结] 进行中: [dim-2], [dim-3], [dim-4] ``` 4. **所有Subagents完成**: ``` ✅ 第一轮检索完成 (4/4) 各维度结果摘要: • [dim-1]: [关键发现] • [dim-2]: [关键发现] • [dim-3]: [关键发现] • [dim-4]: [关键发现] ``` ### Phase 3: 分析与迭代决策（检查点 #N+1） **目标**: 评估信息完整性，决定是否需要补充检索 **执行**: 1. 交叉验证第一轮结果 2. 识别信息缺口: - 缺少哪个维度的信息？ - 哪些说法需要进一步验证？ - 发现了哪些需要深挖的新线索？ 3. **检查点**: 向用户汇报并征求意见 ``` 📊 第一轮检索分析 已获取信息: ✅ [维度1] - 充分 ⚠️ [维度2] - 部分，发现矛盾观点需验证 ✅ [维度3] - 充分 ❓ [维度4] - 发现新线索[XXX]值得深入 建议补充检索: 1. 验证[维度2]的矛盾观点 2. 深入调查新线索[XXX] 选择: [A] 执行建议的补充检索 [B] 直接生成当前报告 [C] 告诉我你想补充什么 ``` **用户选择 A/C 进入 Phase 4，选择 B 进入 Phase 5** ### Phase 4: 补充检索迭代（可选，可多次） **目标**: 针对信息缺口进行精准补充 **执行**: 1. 基于用户反馈确定补充检索任务（1-3个） 2. **Spawn 补充 Subagents**（并发数 ≤ 剩余配额） 3. **检查点**: 类似 Phase 2 的进度更新 4. **完成后**: 回到 Phase 3 再次评估 **迭代深度建议**: 最多 2-3 轮迭代，防止过度搜索 ### Phase 5: 综合与输出（最终检查点） **目标**: 生成结构化、可追溯的深度检索报告 **执行**: 1. 整合所有轮次的结果 2. 交叉验证，标注可信度 3. 生成报告 **输出格式**: ```markdown # 深度检索报告: [主题] ## 执行摘要 3-5 条核心发现 ## 详细发现 ### 维度 1: [名称] **来源**: [具体来源列表] **关键信息**: - 要点1（可信度: ⭐⭐⭐⭐⭐） - 要点2（可信度: ⭐⭐⭐⭐） **证据**: [引用/截图/链接] ### 维度 2: [名称] ... ## 信息源评估 | 来源类型 | 可信度 | 时效性 | 备注 | |---------|--------|--------|------| | 官方文档 | ⭐⭐⭐⭐⭐ | 2024-01 | 权威 | | 技术社区 | ⭐⭐⭐ | 2024-03 | 多观点 | ## 不确定性标注 - [某信息]: 仅单一来源，需进一步验证 - [某观点]: 存在行业争议 ## 后续建议 - 如需验证[XXX]，可以检索[YYY] - 建议关注[ZZZ]的最新动态 ``` ## Subagent 使用规范 ### 检索 Subagent 的任务描述模板 ```markdown 你是一位专业的[领域]研究员。请深度检索以下主题: **任务**: [具体的检索目标] **维度**: [这是哪个维度的检索] **要求**: 1. 至少访问 3-5 个高质量来源 2. 对矛盾信息进行交叉验证 3. 记录所有来源 URL 4. 评估信息可信度 5. 返回结构化发现（要点形式） **输出格式**: ## 检索发现: [维度名称] ### 核心发现（3-5条） 1. [发现1] - 来源: [URL/文档] 2. [发现2] - 来源: [URL/文档] ... ### 信息来源评估 | 来源 | 类型 | 可信度 | 时效性 | |-----|------|--------|--------| | ... | ... | ... | ... | ### 待验证/不确定的信息 - [某项信息]: 原因 ``` ### 浏览器使用 **并发建议**: 同一subagent内按顺序浏览，不同subagent之间并行 ```typescript // Subagent 内部: 顺序访问多个来源 for (const url of sources) { await browser({action: "open", url}) const snapshot = await browser({action: "snapshot"}) // 分析内容 } // 不同subagent: 自动并行（共享同一Chrome的多tabs） // subagent-A: browser({url: "source-A.com"}) // subagent-B: browser({url: "source-B.com"}) // 同时执行 ``` ## 用户参与策略 ### 何时主动通知用户 | 时机 | 通知内容 | 目的 | |------|---------|------| | 规划完成 | 检索维度和计划 | 获得确认，调整方向 | | 任务启动 | 已开始 N 个任务 | 让用户知道正在执行 | | 每完成 1 个 | 该维度关键发现 | 保持参与感 | | 每完成 25/50/75% | 整体进度 | 管理预期 | | 一轮结束 | 汇总 + 迭代建议 | 征求意见 | | 发现重要线索 | 可能改变方向 | 让用户决策 | | 完成 | 最终报告 | 交付成果 | ### 消息风格 - **简洁**: 每次检查点 2-4 句话 + 关键信息 - **结构化**: 使用 emoji、列表、表格增强可读性 - **行动导向**: 明确告诉用户下一步需要什么（"请确认"、"请选择"） - **透明**: 主动说明不确定性和局限性 ## 边界情况处理 ### 如果用户中途发新消息 **策略**: 礼貌说明当前状态，询问优先级 ``` 👋 收到新消息 当前正在进行深度检索（Phase 2, 2/4 完成）。 选择: [A] 继续当前检索，新消息稍后处理 [B] 暂停当前，先处理新消息（进度保留） [C] 终止当前，专注新消息 默认: [A]（5秒后自动继续） ``` ### 如果检索遇到技术问题 **策略**: 透明沟通 + 替代方案 ``` ⚠️ 检索进度更新 [dim-2] 遇到访问限制，正在尝试替代来源... 调整: - 跳过 [dim-2] 的 [受限来源] - 已找到 2 个替代高质量来源 - 预计延迟 30 秒 继续执行，如有变化将及时通知。 ``` ### 如果信息过于庞大 **策略**: 主动建议聚焦 ``` 📊 初步检索发现信息量很大 当前维度已有 20+ 高质量来源。 建议: [A] 继续全面检索（预计需 5-8 分钟） [B] 聚焦最相关的 3-5 个来源（推荐，2-3 分钟） [C] 告诉我你最关心哪个方面 请选择... ``` ## 最佳实践 1. **质量 > 数量**: 宁可少 spawn 一个，也要保证每个任务清晰 2. **快速失败**: 如果某维度 30 秒无有效结果，及时汇报并建议调整 3. **来源透明**: 始终标注信息来源，让用户可追溯 4. **承认局限**: 主动说明哪些信息没有找到或无法验证 5. **保留上下文**: 多轮迭代时引用之前轮次的发现，避免重复 ## 示例对话流程 **用户**: "帮我深度调研一下向量数据库的现状" **Agent**: [Phase 1] 展示规划 ``` 📋 检索规划 主题: 向量数据库现状调研 计划维度: 1. 主流产品对比 (Pinecone/Milvus/Weaviate/pgvector) 2. 技术架构解析 (索引算法/存储引擎) 3. 应用场景与案例 4. 2024年最新动态与趋势 预计并发: 4 subagents 预计时间: 3-5 分钟 确认执行请回复 "开始" ``` **用户**: "开始" **Agent**: [Phase 2] 启动 + 进度更新 ``` 🚀 启动检索 已启动 4 个并行任务: • 产品对比分析 • 技术架构解析 • 应用场景调研 • 最新动态追踪 ⏱️ 进行中... ``` [30秒后] ``` ✅ 进度更新 (1/4 完成) 产品对比检索完成 关键发现: Pinecone在托管服务领先，Milvus开源生态最强，pgvector在Postgres用户中增长最快 进行中: 技术架构、应用场景、最新动态 ``` [60秒后] ``` ✅ 第一轮检索完成 (4/4) 各维度已获取充分信息。正在分析... ``` **Agent**: [Phase 3] 分析与建议 ``` 📊 第一轮分析 已获取: ✅ 产品对比 - 充分，发现3个主流方向 ✅ 技术架构 - 充分，HNSW/IVF-FLAT为主流 ✅ 应用场景 - 充分，RAG/推荐/搜索三大场景 ✅ 最新动态 - 发现重要线索: 2024年多模态向量检索成为热点 建议补充: 1. 深入调研"多模态向量检索"的技术实现 2. 验证 Milvus vs Weaviate 的性能对比数据 选择: [A] 执行补充检索 (预计+2分钟) [B] 直接生成当前报告 [C] 其他... ``` **用户**: "A" **Agent**: [Phase 4] 补充检索... [最后] **Agent**: [Phase 5] 最终报告 ``` # 深度检索报告: 向量数据库现状 ## 执行摘要 1. 市场分化明显: 托管服务(Pinecone) vs 开源方案(Milvus/Weaviate) 2. 技术收敛: HNSW成为事实标准索引算法 3. 应用场景成熟: RAG成为最大增长驱动力 4. 新兴趋势: 多模态向量检索快速崛起... [完整报告...] ```