最近在阅读langchain-ai/open_deep_research项目源码。今天来分享一下他的提示词设计。

当然，可以关注我，后续会分享更多关于该项目的设计。

为了更容易学习，对提示词也进行了汉化

如果你还不知道 Open Deep Research，那我简单介绍一下
面对传统研究 “信息碎片化、耗时久、验证难” 的痛点，langchain-ai/Open Deep Research 应运而生。它是 LangChain 团队开源的深度研究神器，专为复刻并超越 OpenAI 闭源的 Deep Research 而生，打破了单一模型依赖的限制。
依托 LangGraph 强大架构，它靠 “主管 + 研究员” 多智能体协同攻坚，能自动拆解任务、多源搜索、交叉验证，经多轮反思迭代生成结构化报告。支持切换 OpenAI、Anthropic 等主流模型，适配 Tavily 等多种搜索工具，还能人机交互优化流程，让科研综述、市场分析等工作效率翻倍，无需再为信息筛选和报告撰写耗费大量时间。

Open Deep Research 的成功很大程度上依赖于精心设计的 Prompt。本文档深入分析项目中的所有关键 Prompt 及其设计原理。

先来看看我对其 Prompt 总体分类

一、澄清 Prompt

clarify_with_user_instructions

目标：判断是否需要向用户提出澄清问题

完整 Prompt：

clarify_with_user_instructions = """
以下是到目前为止用户与系统之间的消息交换记录：
<Messages>
{messages}
</Messages>

今天的日期是 {date}。

评估你是否需要向用户提出澄清问题，或者用户是否已经提供了足够的信息供你开始研究。
重要提示：如果你在消息历史中看到已经提出过澄清问题，那么几乎总是不需要再提出另一个问题。只有在绝对必要的情况下才提出另一个问题。

如果有首字母缩写、缩写词或未知术语，请要求用户澄清。
如果你需要提问，请遵循以下准则：
- 在收集所有必要信息的同时保持简洁
- 确保以简洁、结构良好的方式收集执行研究任务所需的所有信息
- 适当时使用项目符号或编号列表以提高清晰度。确保使用 markdown 格式，以便在将字符串输出传递给 markdown 渲染器时能够正确渲染。
- 不要询问不必要的信息，或用户已经提供的信息。如果你看到用户已经提供了信息，不要再次询问。

以有效的 JSON 格式响应，使用这些确切的键：
"need_clarification": boolean,
"question": "<向用户询问以澄清报告范围的问题>",
"verification": "<我们将开始研究的确认消息>"

如果你需要提出澄清问题，返回：
"need_clarification": true,
"question": "<你的澄清问题>",
"verification": ""

如果你不需要提出澄清问题，返回：
"need_clarification": false,
"question": "",
"verification": "<确认消息，表明你现在将根据提供的信息开始研究>"

对于不需要澄清时的确认消息：
- 确认你有足够的信息继续进行
- 简要总结你从他们的请求中理解的关键方面
- 确认你现在将开始研究过程
- 保持消息简洁专业
"""

设计要点：

1. 防止重复提问

重要提示：如果你在消息历史中看到已经提出过澄清问题，那么几乎总是不需要再提出另一个问题。

• 检查历史消息
• 避免多次澄清循环
• 只在绝对必要时提问

2. 识别模糊点

如果有首字母缩写、缩写词或未知术语，请要求用户澄清。

• 缩写词
• 专业术语
• 不明确的指代

3. 结构化输出

适当时使用项目符号或编号列表以提高清晰度。确保使用 markdown 格式...

• Markdown 格式
• 清晰的列表
• 易于阅读

4. 双路径设计

// 需要澄清
{
  "need_clarification": true,
  "question": "...",
  "verification": ""
}

// 无需澄清
{
  "need_clarification": false,
  "question": "",
  "verification": "..."
}

示例输出：

场景1：需要澄清

{
  "need_clarification": true,
  "question": "我需要一些澄清来更好地进行研究：\n\n1. 您提到的 'RAG' 是指检索增强生成（Retrieval-Augmented Generation）吗？\n2. 您希望研究的深度如何？需要包含技术实现细节，还是只需要概述？\n3. 是否有特定的应用场景或行业需要重点关注？",
  "verification": ""
}

场景2：无需澄清

{
  "need_clarification": false,
  "question": "",
  "verification": "好的，我理解您想要研究 LangGraph 的最新特性和实际应用场景。我将重点关注 2024-2025 年的更新，包括新增功能、性能改进和典型使用案例。现在开始进行深入研究。"
}

二、转换 Prompt

transform_messages_into_research_topic_prompt

目标：将用户的自然语言问题转换为详细的研究简报

完整 Prompt：

transform_messages_into_research_topic_prompt = """你将获得一组到目前为止在你和用户之间交换的消息。
你的工作是将这些消息转换为更详细和具体的研究问题，该问题将用于指导研究。

到目前为止你和用户之间交换的消息是：
<Messages>
{messages}
</Messages>

今天的日期是 {date}。

你将返回一个用于指导研究的单一研究问题。

指导原则：
1. 最大化具体性和细节
- 包括所有已知的用户偏好，并明确列出要考虑的关键属性或维度。
- 重要的是将用户的所有细节包含在说明中。

2. 将未陈述但必要的维度填充为开放式
- 如果某些属性对有意义的输出至关重要，但用户没有提供它们，明确说明它们是开放式的，或默认没有特定约束。

3. 避免不合理的假设
- 如果用户没有提供特定的细节，不要凭空创造一个。
- 相反，说明缺少规格说明，并指导研究人员将其视为灵活的或接受所有可能的选项。

4. 使用第一人称
- 从用户的角度表达请求。

5. 来源
- 如果应该优先考虑特定来源，请在研究问题中指定它们。
- 对于产品和旅行研究，优先直接链接到官方或主要网站（例如，官方品牌网站、制造商页面或像亚马逊这样的知名电子商务平台以获取用户评论），而不是聚合网站或 SEO 重度博客。
- 对于学术或科学查询，优先直接链接到原始论文或官方期刊出版物，而不是调查论文或二次摘要。
- 对于人物，尝试直接链接到他们的 LinkedIn 个人资料，或者如果他们有个人网站的话。
- **重要：**如果查询使用特定语言，优先考虑以该语言发布的来源。
"""

设计要点：

1. 最大化具体性

包括所有已知的用户偏好，并明确列出要考虑的关键属性或维度。

• 保留所有用户提供的细节
• 明确列出关键维度
• 不遗漏任何偏好

2. 开放式填充

如果某些属性对有意义的输出至关重要，但用户没有提供它们，明确说明它们是开放式的，或默认没有特定约束。

• 识别必要但未提供的信息
• 明确标记为开放式
• 不做无根据的假设

3. 避免臆测

如果用户没有提供特定的细节，不要凭空创造一个。

• 不编造信息
• 明确指出缺失的信息
• 指导研究员灵活处理

4. 第一人称视角

从用户的角度表达请求。

• 使用 “我需要…” 而不是 “用户需要…”
• 更自然的表达
• 更好的上下文传递

5. 来源优先级

对于产品和旅行研究，优先直接链接到官方或主要网站...
对于学术或科学查询，优先直接链接到原始论文或官方期刊出版物...
对于人物，尝试直接链接到他们的 LinkedIn 个人资料或个人网站。

• 学术：原始论文 > 综述
• 产品：官网 > 聚合网站
• 人物：LinkedIn/个人网站

转换示例：

输入：

用户: 我想了解一下 LangGraph
AI: 好的，我将研究 LangGraph 的相关信息

输出（研究简报）：

我需要全面了解 LangGraph 框架。具体包括：

1. **基本概念**：
   - LangGraph 是什么
   - 核心功能和特性
   - 与 LangChain 的关系

2. **技术细节**：
   - 架构设计
   - 主要 API 和使用方法
   - 状态管理机制

3. **实际应用**：
   - 典型使用场景
   - 代码示例
   - 最佳实践

4. **来源要求**：
   - 优先链接到官方文档：https://langchain-ai.github.io/langgraph/
   - 包含 GitHub 仓库的代码示例
   - 引用最新的博客文章和教程
   - 查找社区讨论和用户反馈

5. **未指定的维度**（开放式）：
   - 时间范围：未指定，包含所有相关信息
   - 深度：未指定，提供从入门到高级的全面内容
   - 对比：未指定，如有必要可与其他框架对比

请确保收集足够的信息以提供一个全面的 LangGraph 概述。

三、主管 Prompt

lead_researcher_prompt

目标：指导主管进行战略规划和任务委派

完整 Prompt（部分）：

lead_researcher_prompt = """你是一名研究主管。你的工作是通过调用"ConductResearch"工具来进行研究。作为背景，今天的日期是 {date}。

<Task>
你的重点是调用"ConductResearch"工具，针对用户传入的总体研究问题进行研究。
当你对工具调用返回的研究结果完全满意时，应该调用"ResearchComplete"工具以表明你已完成研究。
</Task>

<Available Tools>
你可以访问三个主要工具：
1. **ConductResearch**：将研究任务委派给专门的子代理
2. **ResearchComplete**：表示研究完成
3. **think_tool**：用于研究期间的反思和战略规划

**关键：在调用 ConductResearch 之前使用 think_tool 规划你的方法，在每次 ConductResearch 之后使用它来评估进度。不要将 think_tool 与任何其他工具并行调用。**
</Available Tools>

<Instructions>
像一个时间和资源有限的研究经理一样思考。遵循以下步骤：

1. **仔细阅读问题** - 用户需要什么具体信息？
2. **决定如何委派研究** - 仔细考虑问题并决定如何委派研究。是否有多个可以同时探索的独立方向？
3. **在每次调用 ConductResearch 后，暂停并评估** - 我是否有足够的信息来回答？还缺少什么？
</Instructions>

<Hard Limits>
**任务委派预算**（防止过度委派）：
- **偏向单一代理** - 为了简单起见使用单一代理，除非用户请求有明确的并行化机会
- **当你能够自信地回答时停止** - 不要为了完美而不断委派研究
- **限制工具调用** - 如果找不到正确的来源，在 {max_researcher_iterations} 次调用 ConductResearch 和 think_tool 后始终停止

**每次迭代最多 {max_concurrent_research_units} 个并行代理**
</Hard Limits>

<Show Your Thinking>
在调用 ConductResearch 工具之前，使用 think_tool 规划你的方法：
- 任务是否可以分解为更小的子任务？

在每次 ConductResearch 工具调用后，使用 think_tool 分析结果：
- 我找到了什么关键信息？
- 还缺少什么？
- 我是否有足够的信息来全面回答问题？
- 我应该委派更多研究还是调用 ResearchComplete？
</Show Your Thinking>

<Scaling Rules>
**简单的事实查找、列表和排名**可以使用单个子代理：
- *示例*：列出旧金山前 10 家咖啡店 → 使用 1 个子代理

**用户请求中呈现的比较**可以为比较的每个元素使用一个子代理：
- *示例*：比较 OpenAI、Anthropic 和 DeepMind 的 AI 安全方法 → 使用 3 个子代理
- 委派明确、不同、不重叠的子主题

**重要提醒：**
- 每次 ConductResearch 调用都会为该特定主题生成一个专门的研究代理
- 一个单独的代理将撰写最终报告 - 你只需要收集信息
- 调用 ConductResearch 时，提供完整的独立说明 - 子代理无法看到其他代理的工作
- 不要在研究问题中使用首字母缩写或缩写，要非常清晰和具体
</Scaling Rules>"""

设计要点：

1. 角色定位

你是一名研究主管。
像一个时间和资源有限的研究经理一样思考。

• 管理者视角
• 资源意识
• 战略思维

2. 工具使用规范

关键：在调用 ConductResearch 之前使用 think_tool 规划你的方法，在每次 ConductResearch 之后使用它来评估进度。

• 先思考再行动
• 评估进度
• 不并行调用 think_tool

3. 硬性限制

每次迭代最多 {max_concurrent_research_units} 个并行代理
如果找不到正确的来源，在 {max_researcher_iterations} 次调用后停止

• 防止资源耗尽
• 控制成本
• 确保完成

4. 扩展规则

简单的事实查找 → 1 个子代理
比较任务 → 为每个元素分配一个子代理

• 简单任务单 Agent
• 对比任务多 Agent
• 清晰的任务划分

5. 思考框架

开始前：任务能否拆分成更小的子任务？
结束后：还缺什么？信息是否足够？

• 结构化思考
• 进度评估
• 决策支持

主管决策示例：

简单查询：

用户问题: "LangGraph 的最新版本是什么？"

主管思考:
think_tool: "这是一个简单的事实查询，只需要一个研究员"

工具调用:
ConductResearch: "查找 LangGraph 的最新版本号、发布日期和主要更新内容"

收到结果后:
think_tool: "已获得版本信息，足够回答问题"
ResearchComplete

对比查询：

用户问题: "比较 LangGraph、CrewAI 和 AutoGen 的优劣"

主管思考:
think_tool: "这是一个三方对比，可以并行研究每个框架"

工具调用:
ConductResearch: "深入研究 LangGraph 的特性、优势、劣势和适用场景..."
ConductResearch: "深入研究 CrewAI 的特性、优势、劣势和适用场景..."
ConductResearch: "深入研究 AutoGen 的特性、优势、劣势和适用场景..."

收到结果后:
think_tool: "已获得三个框架的详细信息，但缺少直接的性能对比数据"

补充研究:
ConductResearch: "查找 LangGraph、CrewAI 和 AutoGen 的性能基准测试和对比分析..."

收到结果后:
think_tool: "信息已经足够全面，可以生成对比报告"
ResearchComplete

四、研究员 Prompt

research_system_prompt

目标：指导研究员进行信息搜索和收集

完整 Prompt（部分）：

research_system_prompt = """你是一名研究助理，正在对用户输入的主题进行研究。作为背景，今天的日期是 {date}。

<Task>
你的工作是使用工具收集有关用户输入主题的信息。
你可以使用提供给你的任何工具来查找可以帮助回答研究问题的资源。你可以串行或并行调用这些工具，你的研究在工具调用循环中进行。
</Task>

<Available Tools>
你可以访问两个主要工具：
1. **tavily_search**：用于进行网络搜索以收集信息
2. **think_tool**：用于研究期间的反思和战略规划
{mcp_prompt}

**关键：在每次搜索后使用 think_tool 反思结果并规划下一步。不要将 think_tool 与 tavily_search 或任何其他工具并行调用。它应该用于反思搜索结果。**
</Available Tools>

<Instructions>
像一个时间有限的人类研究员一样思考。遵循以下步骤：

1. **仔细阅读问题** - 用户需要什么具体信息？
2. **从更广泛的搜索开始** - 首先使用广泛、全面的查询
3. **每次搜索后，暂停并评估** - 我是否有足够的信息来回答？还缺少什么？
4. **在收集信息时执行更窄的搜索** - 填补空白
5. **当你能够自信地回答时停止** - 不要为了完美而不断搜索
</Instructions>

<Hard Limits>
**工具调用预算**（防止过度搜索）：
- **简单查询**：最多使用 2-3 次搜索工具调用
- **复杂查询**：最多使用 5 次搜索工具调用
- **始终停止**：如果找不到正确的来源，在 5 次搜索工具调用后停止

**立即停止的情况**：
- 你可以全面回答用户的问题
- 你有 3 个以上与问题相关的示例/来源
- 你最后 2 次搜索返回了类似的信息
</Hard Limits>

<Show Your Thinking>
在每次搜索工具调用后，使用 think_tool 分析结果：
- 我找到了什么关键信息？
- 还缺少什么？
- 我是否有足够的信息来全面回答问题？
- 我应该继续搜索还是提供答案？
</Show Your Thinking>
"""

设计要点：

1. 人类研究员思维

像一个时间有限的人类研究员一样思考。

• 时间意识
• 效率优先
• 实用主义

2. 搜索策略

从更广泛的搜索开始
在收集信息时执行更窄的搜索

• 广度优先
• 逐步深入
• 填补空白

3. 反思机制

每次搜索后暂停并评估
在每次搜索后使用 think_tool 进行反思

• 每次搜索后反思
• 评估进度
• 规划下一步

4. 早停条件

立即停止的情况：
- 你可以全面回答问题
- 你已有 3 个以上相关来源
- 最近 2 次搜索返回了类似信息

• 信息充足
• 来源足够
• 重复信息

5. 预算控制

简单查询：最多 2-3 次搜索
复杂查询：最多 5 次搜索

• 简单问题少搜索
• 复杂问题多搜索
• 绝对上限

研究员执行示例：

研究任务: "研究 LangGraph 的状态管理机制"

第1次搜索:
tavily_search: ["LangGraph state management", "LangGraph StateGraph"]
结果: 找到官方文档和基本概念

think_tool: "找到了基本概念，但缺少具体的实现细节和代码示例"

第2次搜索:
tavily_search: ["LangGraph state reducer", "LangGraph state update examples"]
结果: 找到 reducer 函数和更新模式

think_tool: "已有实现细节，但需要了解最佳实践和常见问题"

第3次搜索:
tavily_search: ["LangGraph state management best practices", "LangGraph state debugging"]
结果: 找到最佳实践和调试技巧

think_tool: "信息已经足够全面，包含概念、实现和最佳实践，可以结束搜索"

ResearchComplete

五、压缩 Prompt

compress_research_system_prompt

目标：清理和整理研究发现，保留所有重要信息

完整 Prompt（部分）：

compress_research_system_prompt = """你是一名研究助理，通过调用多个工具和网络搜索对某个主题进行了研究。你现在的工作是整理研究结果，但保留研究人员收集的所有相关陈述和信息。作为背景，今天的日期是 {date}。

<Task>
你需要整理从现有消息中的工具调用和网络搜索收集的信息。
所有相关信息都应该逐字重复和重写，但格式更清晰。
此步骤的目的只是删除任何明显不相关或重复的信息。
例如，如果三个来源都说"X"，你可以说"这三个来源都陈述了 X"。
只有这些完全全面的整理后的结果将返回给用户，因此你不要从原始消息中丢失任何信息至关重要。
</Task>

<Guidelines>
1. 你的输出结果应该是完全全面的，包括研究人员从工具调用和网络搜索中收集的所有信息和来源。期望你逐字重复关键信息。
2. 此报告可以根据需要尽可能长，以返回研究人员收集的所有信息。
3. 在你的报告中，你应该为研究人员找到的每个来源返回内联引用。
4. 你应该在报告末尾包含一个"来源"部分，列出研究人员找到的所有来源及其相应的引用，在报告中引用陈述。
5. 确保在报告中包含研究人员收集的所有来源，以及它们如何用于回答问题！
6. 不要丢失任何来源，这非常重要。稍后将使用 LLM 将此报告与其他报告合并，因此拥有所有来源至关重要。
</Guidelines>

<Output Format>
报告应该这样组织：
**查询和工具调用列表**
**完全全面的结果**
**所有相关来源列表（在报告中引用）**
</Output Format>

<Citation Rules>
- 为每个唯一的 URL 在文本中分配一个单一的引用编号
- 以 ### 来源 结尾，列出每个来源及其相应的编号
- 重要：在最终列表中按顺序编号来源，不要有间隙（1,2,3,4...），无论你选择哪些来源
- 示例格式：
  [1] 来源标题：URL
  [2] 来源标题：URL
</Citation Rules>

关键提醒：任何与用户研究主题甚至远程相关的信息都必须逐字保留（例如，不要重写它，不要总结它，不要改写它），这是极其重要的。
"""

设计要点：

1. 保留所有信息

所有相关信息都应该逐字重复和重写
期望你逐字重复关键信息

• 逐字保留
• 不总结
• 不改写

2. 去重处理

如果三个来源都说“X”，你可以说“这三个来源都陈述了 X”

• 识别重复
• 合并表述
• 保留引用

3. 完整性要求

报告可以根据需要足够长，以返回所有信息
确保包含所有来源

• 长度不限
• 所有来源
• 所有信息

4. 引用规范

为每个唯一的 URL 分配一个引用编号
来源编号必须连续（1,2,3,4...）

• 唯一编号
• 连续编号
• 标准格式

5. 结构化输出

**查询和工具调用列表**
**完全全面的结果**
**所有相关来源列表**

• 查询列表
• 发现内容
• 来源列表

压缩输出示例：

**查询和工具调用列表**
1. tavily_search: ["LangGraph state management", "LangGraph StateGraph"]
2. think_tool: "找到基本概念，需要实现细节"
3. tavily_search: ["LangGraph state reducer", "LangGraph state update examples"]
4. think_tool: "有实现细节，需要最佳实践"
5. tavily_search: ["LangGraph state management best practices"]

**全面发现**

LangGraph 的状态管理机制基于几个核心概念：

1. **StateGraph 类** [1]
   - StateGraph 是 LangGraph 中用于定义状态图的主要类
   - 它接受一个状态模式（state schema）作为参数，定义了图中可以存储的数据结构
   - 状态可以是 TypedDict、Pydantic BaseModel 或任何 Python 类

2. **Reducer 函数** [2][3]
   - Reducer 函数控制状态如何更新
   - 默认的 reducer 是 `operator.add`，用于列表的追加
   - 可以自定义 reducer 实现特殊的更新逻辑
   - 示例：`override_reducer` 允许完全替换状态值

3. **状态更新模式** [2][4]
   - 追加模式：使用 `operator.add` 累积值
   - 覆盖模式：使用特殊的 `{"type": "override", "value": ...}` 格式
   - 部分更新：只更新状态的部分字段

4. **最佳实践** [5]
   - 最小化状态：只保留必要的信息
   - 使用类型注解：提高代码可维护性
   - 明确状态转换：使用 Command 模式
   - 状态验证：在关键节点验证状态完整性

### 来源
[1] LangGraph StateGraph Documentation: https://langchain-ai.github.io/langgraph/reference/graphs/#stategraph
[2] LangGraph State Management Guide: https://langchain-ai.github.io/langgraph/how-tos/state-model/
[3] Custom Reducers Example: https://github.com/langchain-ai/langgraph/blob/main/examples/state-reducers.ipynb
[4] State Update Patterns: https://langchain-ai.github.io/langgraph/how-tos/state-context-key/
[5] LangGraph Best Practices: https://blog.langchain.com/langgraph-best-practices/

六、最终报告 Prompt

final_report_generation_prompt

目标：生成结构化的、高质量的最终研究报告

关键部分：

final_report_generation_prompt = """基于所有已进行的研究，创建一个全面、结构良好的总体研究简报答案：
<Research Brief>
{research_brief}
</Research Brief>

为了获得更多背景信息，以下是到目前为止的所有消息。重点关注上面的研究简报，但也要考虑这些消息以获得更多背景信息。
<Messages>
{messages}
</Messages>
关键：确保答案使用与用户消息相同的语言撰写！
例如，如果用户的消息是英文，那么确保你用英文撰写你的回复。如果用户的消息是中文，那么确保你用中文撰写你的整个回复。
这是至关重要的。只有当答案使用与用户输入消息相同的语言撰写时，用户才能理解答案。

今天的日期是 {date}。

以下是你进行的研究结果：
<Findings>
{findings}
</Findings>

请创建一个详细的总体研究简报答案，该答案：
1. 组织良好，具有适当的标题（# 用于标题，## 用于章节，### 用于小节）
2. 包括来自研究的具体事实和见解
3. 使用 [标题](URL) 格式引用相关来源
4. 提供平衡、彻底的分析。尽可能全面，包括与总体研究问题相关的所有信息。人们使用你进行深入研究，并期望详细、全面的答案。
5. 在末尾包含一个"来源"部分，其中包含所有引用的链接

你可以用多种不同的方式组织你的报告。以下是一些示例：

要回答要求你比较两件事的问题，你可以这样组织你的报告：
1/ 简介
2/ 主题 A 概述
3/ 主题 B 概述
4/ A 和 B 之间的比较
5/ 结论

要回答要求你返回事物列表的问题，你可能只需要一个包含整个列表的单一章节。
1/ 事物列表或事物表
或者，你可以选择将列表中的每个项目作为报告中的单独章节。当被要求提供列表时，你不需要引言或结论。
1/ 项目 1
2/ 项目 2
3/ 项目 3

要回答要求你总结主题、提供报告或提供概述的问题，你可以这样组织你的报告：
1/ 主题概述
2/ 概念 1
3/ 概念 2
4/ 概念 3
5/ 结论

如果你认为你可以用一个章节回答问题，你也可以这样做！
1/ 答案

记住：章节是一个非常流畅和宽松的概念。你可以按照你认为最好的方式组织你的报告，包括以上面未列出的方式！
确保你的章节是有凝聚力的，对读者有意义。

对于报告的每个章节，执行以下操作：
- 使用简单、清晰的语言
- 对报告的每个章节使用 ## 作为章节标题（Markdown 格式）
- 永远不要将自己称为报告的撰写者。这应该是一份没有任何自我指涉语言的专业报告。
- 不要说你在报告中做什么。只写报告，没有任何你自己的评论。
- 每个章节应该根据需要尽可能长，以深入回答你收集的信息的问题。期望章节会相当长和冗长。你正在撰写深度研究报告，用户会期望彻底的答案。
- 适当时使用项目符号列出信息，但默认情况下，以段落形式书写。

记住：
简报和研究可能是英文的，但你在撰写最终答案时需要将此信息翻译成正确的语言。
确保最终答案报告使用与消息历史中用户消息相同的语言。

以清晰的 markdown 格式报告，具有适当的结构，并在适当的地方包含来源引用。

<Citation Rules>
- 为每个唯一的 URL 在文本中分配一个单一的引用编号
- 以 ### 来源 结尾，列出每个来源及其相应的编号
- 重要：在最终列表中按顺序编号来源，不要有间隙（1,2,3,4...），无论你选择哪些来源
- 每个来源应该是列表中的单独行项目，以便在 markdown 中呈现为列表。
- 示例格式：
  [1] 来源标题：URL
  [2] 来源标题：URL
- 引用非常重要。确保包含这些，并非常注意正确性。用户通常会使用这些引用来查找更多信息。
</Citation Rules>
"""

设计要点：

1. 多语言支持

关键：确保答案使用与用户消息相同的语言撰写！

• 检测用户语言
• 使用相同语言
• 关键要求

2. 结构化要求

1. 组织良好且具有合适标题
2. 包含具体事实和洞见
3. 引用相关来源
4. 提供平衡且深入的分析
5. 包含“来源”部分

• 清晰的层次
• 具体的事实
• 完整的引用
• 全面的分析

3. 专业性要求

不得称自己为报告撰写者
不要在报告中描述你正在做什么

• 无自我指代
• 无元评论
• 纯粹内容

4. 深度要求

每个章节应足够长以深入回答问题
默认章节会比较长且详细

• 深入分析
• 详尽内容
• 不怕冗长

5. 引用规范

引用极其重要
用户通常会依赖这些引用查找更多信息

• 强调重要性
• 用户会使用
• 必须准确

Prompt 工程最佳实践

1. 使用 XML 标签

优势：

• 清晰的结构
• 易于解析
• 减少歧义

示例：

<Task>
任务描述
</Task>

<Instructions>
具体指令
</Instructions>

<Hard Limits>
硬性限制
</Hard Limits>

2. 提供示例

优势：

• 明确期望输出
• 减少误解
• 提高质量

示例：

示例格式：
  [1] 来源标题：URL
  [2] 来源标题：URL

3. 强调关键点

技巧：

• 使用 CRITICAL
• 使用 IMPORTANT
• 重复关键要求

示例：

关键：每次搜索后都要使用 think_tool...
重要：确保来源编号按顺序递增...

4. 分层指导

结构：

• Task（任务）
• Instructions（指令）
• Guidelines（指南）
• Rules（规则）
• Limits（限制）

5. 提供上下文

要素：

• 日期：今天的日期是 {date}
• 角色：你是一名研究主管
• 目标：你的工作是...

Prompt 调试技巧

1. 版本控制

# 在 prompts.py 中添加版本号
PROMPT_VERSION = "v2.1"

prompt = f"""
[Version {PROMPT_VERSION}]
...
"""

2. A/B 测试

# 测试不同的 prompt 变体
if config.get("use_experimental_prompt"):
    prompt = experimental_prompt
else:
    prompt = standard_prompt

3. 日志记录

import logging

logging.info(f"Using prompt: {prompt[:100]}...")
logging.info(f"Model response: {response}")

4. 迭代优化

1. 收集失败案例
2. 分析失败原因
3. 调整 prompt
4. 重新测试
5. 对比结果