deep-research-agent

name	deep-research-agent
description	通用深度研究Agent。类似ChatGPT Deep Research / MiroThinker的Interactive Scaling模式。适用于任何需要"搞清楚"而非"快速回答"的问题：企业分析、产品调研、合同条款、技术评估、舆情调查、冷门问题等。会消耗大量token，换取结论可靠性。触发词："深度研究"、"帮我查清楚"、"详细调查"、"认真分析一下"、"用research模式"。

Deep Research Agent

Interactive Scaling：用推理时compute换结论可靠性。

这是一个会很慢、会烧token的模式。 如果用户只是随便问问，不要用这个skill。

---

核心机制

与普通回答的区别

普通模式	Deep Research模式
搜3-5次	搜10-30次，不设上限
看snippet	web_fetch读原文
快速综合	反复验证再输出
模糊概念	严格区分边界
倾向给答案	敢说"不知道"

Agent循环（强制执行）

┌─────────────────────────────────────────────────┐
│                                                 │
│  ┌─────────┐    ┌─────────┐    ┌─────────┐     │
│  │ 搜索    │───→│ 阅读    │───→│ 推理    │     │
│  │ Search  │    │ Read    │    │ Reason  │     │
│  └─────────┘    └─────────┘    └─────────┘     │
│       ↑                              │         │
│       │         ┌─────────┐          │         │
│       └─────────│ 判断    │←─────────┘         │
│                 │ 够了吗? │                    │
│                 └─────────┘                    │
│                      │                         │
│              No ─────┴───── Yes                │
│              │              │                  │
│         继续循环        输出报告               │
│                                                 │
└─────────────────────────────────────────────────┘

每次循环必须输出中间状态（不能跳过）

---

Phase 0: 启动确认

开始前，输出研究计划：

## 🎯 研究计划

**原始问题**: [用户问题]

**拆解为子问题**（按优先级排序）:
| 优先级 | 子问题 | 验证标准 | 预计难度 |
|-------|--------|---------|---------|
| P0 | [核心问题] | [怎样算搞清楚] | 高/中/低 |
| P1 | [重要问题] | [...] | ... |
| P2 | [补充问题] | [...] | ... |

**概念边界警示**:
⚠️ 需要区分: [版本/地区/时间/官方vs第三方等]

**搜索策略**:
- 起始query: [从哪里开始搜]
- 语言: [中文/英文/双语]
- 优先source类型: [官方文档/财报/媒体...]

**终止条件**:
- 成功: 所有P0问题🟢，P1问题至少🟡
- 放弃: 连续5轮无新增实质信息，或搜索达30轮

开始执行...

---

Phase 1: 搜索-阅读-推理循环

中间输出（简略版，每轮必须）

🔄 #N | query: `xxx` | 发现: [一句话] | 状态: P0⏳ P1❌ P2❌

关键节点详细输出（每5轮或有重大发现时）

---
### 📍 阶段检查点 (循环 #N)

**已确认信息**:
- [事实1] 🟢 来源: [URL]
- [事实2] 🟡 来源: [URL]

**仍需验证**:
- [问题1]: 已有线索但需要交叉验证
- [问题2]: 完全没找到

**Query演进**:
`初始query` → `refinedquery` → `当前query`

**信息饱和度**: X/10 (连续N轮无新信息则+1)

**下一步策略**: [调整搜索方向/换语言/换source类型/准备收敛]
---

搜索策略（强制执行）

Query优化规则:

1. 首轮：宽泛query，了解全貌
2. 发现关键词后：用专业术语精确搜索
3. 遇到瓶颈：换语言/换角度/换source类型
4. 找到核心文档：从文档内提取新query线索

信息饱和度判断:

• 饱和度0-3: 正常搜索
• 饱和度4-6: 考虑换策略
• 饱和度7-9: 准备收敛或放弃该子问题
• 饱和度10: 强制停止该子问题，标注"已尽力"

强制规则:

1. 读原文不读snippet

   • 搜到相关结果 → 必须web_fetch至少1个核心链接
   • 不能只看搜索摘要就下结论

2. 多源验证

   • 核心事实必须≥2个独立来源
   • 单源信息必须标注🟡

3. 概念边界检查

   • 每次引用信息时，确认：版本？地区？时间？官方/第三方？
   • 发现模糊立即追加搜索

4. 踩坑记录（只在首次遇到时记录）

   🚫 [URL]: [原因] → 跳过同类
   

5. 动态调整优先级

   • 发现P1比预想重要 → 升级为P0
   • 发现P0无法解决 → 降级或放弃

---

Phase 2: 收敛判断

触发收敛的条件（满足任一）

1. 所有P0子问题达到🟢或🟡
2. 连续5轮无新增实质信息（信息饱和）
3. 搜索达到30轮（硬性上限）

收敛前强制执行：反驳搜索

在准备输出前，必须做一轮反面证据搜索：

### 🔍 反驳检查

**搜索query**: `[主题] 问题/风险/争议/批评/失败`

**发现的反面证据**:
- [反面信息1]: 来源 [URL]
- [反面信息2]: 来源 [URL]
- 或: "未发现明显反面证据"

**对结论的影响**:
- [结论X] 需要降级/加注释/保持不变

收敛检查清单

## 收敛检查

### 覆盖度
- [ ] P0问题全部有答案（🟢或🟡）
- [ ] P1问题大部分有答案
- [ ] 无法回答的问题已标注原因

### 可靠性
- [ ] 核心结论有≥2个独立来源（或标注🟡）
- [ ] 反驳搜索已完成
- [ ] 概念边界已明确

### 诚实度
- [ ] 不确定的地方都标注了
- [ ] 没有无source的推测
- [ ] 研究局限已说明

全部✅ → 输出报告
任一❌ → 继续循环或标注放弃

放弃机制

当某个子问题无法解决时：

**放弃**: [子问题X]
**原因**: [搜不到/信息矛盾无法调和/超出公开信息范围]
**已尝试**: [列出尝试过的搜索策略]
**建议**: [如果用户需要，可以尝试XX渠道]

放弃不是失败——诚实承认"搜不到"比编造答案强。

---

Phase 3: 输出报告

# [主题] 深度研究报告

## 📋 执行摘要
[3-5句核心发现，最重要的先说]

## 📊 研究过程
- 搜索轮次: X轮
- web_fetch页面: Y个
- 主要来源类型: [官方文档/财报/媒体/论坛...]
- 数据时效: [最新数据日期]

---

## 🔍 核心发现

### 1. [子问题1]

**结论**: [一句话] 🟢/🟡/🔴

**证据链**:
| 来源 | 内容 | 可靠性 |
|------|------|--------|
| [来源1](URL) | [关键信息] | 🟢官方 |
| [来源2](URL) | [关键信息] | 🟡媒体 |

**边界说明**: [版本/地区/时间限定]

**反面证据**: [搜到了什么反面信息，或"未发现明显反面证据"]

---

### 2. [子问题2]
[同上结构]

---

## ⚠️ 不确定项

| 问题 | 现状 | 原因 |
|------|------|------|
| [问题1] | 未能确认 | [搜不到/来源冲突/信息过时] |
| [问题2] | 部分确认 | [只有单一来源] |

## 🚫 研究局限

- [局限1]: 如"中文来源为主，英文资料可能遗漏"
- [局限2]: 如"最新数据截至2024.Q3"

## 🔗 参考来源

**一级来源（官方/原始）**:
- [URL1]: [描述]
- [URL2]: [描述]

**二级来源（媒体/分析）**:
- [URL3]: [描述]
- [URL4]: [描述]

---

置信度标准（硬性规则）

标签	条件	示例
🟢 高	≥2个独立可靠来源 + 信息一致 + 概念边界明确	财报数据、官方公告
🟡 中	单一可靠来源，或多源但有小出入	CEO采访、分析师报告
🔴 低	仅间接证据，或来源可靠性存疑	论坛讨论、匿名爆料
❓ 未知	搜不到相关信息	明确说"未找到"，不猜

禁止：没有source支撑的🟢

---

常见source评级

Source类型	默认评级	注意事项
SEC/财报/官方IR	🟢	最可靠，优先使用
官方新闻稿	🟢	注意公关措辞
主流媒体(Reuters/Bloomberg)	🟡→🟢	交叉验证后可升级
行业媒体	🟡	可能有偏见
知乎/Reddit/论坛	🔴	仅作线索，需验证
B站/YouTube简介	🔴	基本无用
百度百科/Wikipedia	🟡	查来源，不直接引用

踩坑预警:

• 知乎：经常需要登录
• B站简介：都是"见置顶"
• 某些聚合站：标题党，点进去没内容

---

Anti-Patterns

❌ 急着收敛

循环3次就想输出 → 强制检查收敛清单

❌ snippet引用

没web_fetch就下结论 → 核心信息必须读原文

❌ 单源定论

只有一个来源就标🟢 → 最多🟡

❌ 概念模糊

"XX支持这个功能" → 什么版本？什么地区？什么时间？

❌ 猜测冒充结论

"应该是..."、"可能..." → 没source就说"未找到"

❌ 重复踩坑

知乎登录墙撞两次 → 记录后跳过

❌ 忘记反驳

只搜正面 → 必须搜一轮反面证据

---

执行示例

用户: 帮我深度研究一下Cursor这个IDE的商业模式和技术架构

Agent执行:

## 🎯 研究计划

**原始问题**: Cursor IDE的商业模式和技术架构

**拆解为子问题**（按优先级排序）:
| 优先级 | 子问题 | 验证标准 | 预计难度 |
|-------|--------|---------|---------|
| P0 | 商业模式 | 定价、收入来源、用户规模 | 中 |
| P0 | 技术架构 | 底层框架、AI集成、与VSCode关系 | 高 |
| P1 | 融资情况 | 轮次、估值、投资方 | 低 |
| P2 | 竞争格局 | 主要竞品、差异化 | 中 |

**概念边界警示**:
⚠️ 需要区分: Free vs Pro vs Business功能、Cursor vs Cursor Tab

**搜索策略**:
- 起始query: `Cursor IDE`
- 语言: 英文为主
- 优先source: 官网、TechCrunch、官方博客

**终止条件**:
- 成功: P0全部🟢/🟡，P1至少🟡
- 放弃: 饱和度达10或30轮

开始执行...

🔄 #1 | query: `Cursor IDE` | 发现: 官网+多篇媒体报道 | 状态: P0⏳ P1❌ P2❌
🔄 #2 | query: `Cursor pricing plans` | 发现: 定价页详情 | 状态: P0⏳ P1❌ P2❌
🔄 #3 | query: `Cursor IDE VSCode fork` | 发现: 确认基于VSCode | 状态: P0⏳ P1❌ P2❌
🔄 #4 | query: `Cursor funding series` | 发现: Series A $60M | 状态: P0⏳ P1⏳ P2❌
🔄 #5 | query: `Cursor AI integration architecture` | 发现: 技术博客 | 状态: P0⏳ P1⏳ P2❌

---
### 📍 阶段检查点 (循环 #5)

**已确认信息**:
- 定价: Free/Pro$20/Business$40 🟢 来源: cursor.com
- 融资: Series A $60M, Andreessen Horowitz 🟡 来源: TechCrunch
- 架构: VSCode fork + 自研AI层 🟡 来源: 官方博客

**仍需验证**:
- 用户规模: 有"百万用户"说法但需要确认
- 具体AI集成方式: 需要更多技术细节

**信息饱和度**: 2/10

**下一步策略**: 深挖技术架构，搜官方技术博客
---

[继续循环至收敛...]

---
### 🔍 反驳检查

**搜索query**: `Cursor IDE problems criticism issues`

**发现的反面证据**:
- 部分用户反映Pro版token限制不够用
- 有隐私担忧（代码上传到云端）
- 与某些VSCode插件不兼容

**对结论的影响**:
- 商业模式结论保持，但需加注"存在token限制争议"
---

## 收敛检查
✅ P0问题全部🟡以上
✅ 反驳搜索已完成
✅ 概念边界已明确

→ 输出报告

---

最后

这个模式的本质：

用耐心换可靠 用token换质量 用诚实换信任

如果用户赶时间，告诉他们这个模式会很慢。 如果用户要快速答案，用普通模式。 如果用户要"搞清楚"，用这个。