--- title: 深度研究的四次尝试：为什么最后回到提示词 canonical: "https://xiaofeng.dev/writing/deep-research-attempts/" pubDate: 2026-09-22 author: 唐小锋 Xiaofeng TANG description: 最近在做一个复杂的消费品市场调研，从「严格本地研究」一路试到 Kimi DeepResearch，中间踩了 Deep Research 接入的各种坑。值得单独拎出来讲讲。 tags: [Deep Research, AI Search, Prompt Engineering, GEO] --- 最近在做一个复杂的消费品市场调研，从「严格本地研究」一路试到 Kimi DeepResearch，中间踩了 Deep Research 接入的各种坑。值得单独拎出来讲讲。 ## 尝试一：直接调用深度研究 API 或插件能力 结论：深度研究能力主要通过网页端或产品内插件提供，开发者无法直接通过模块调用或 API 调用并集成到自己的流程中。 - **OpenAI**：官方文档说明可以通过 Responses API 使用 `o3-deep-research` 和 `o4-mini-deep-research` 模型（[Deep Research 指南](https://developers.openai.com/api/docs/guides/deep-research)），需要至少包含一个数据源（web search、remote MCP 或 file search）。2026 年 9 月 9 日起，OpenAI 在 ChatGPT Business 版中正式发布了 Deep Research 插件（版本 0.1.14），Work/Codex 用户可以通过 `@Deep Research` 在各端使用，消耗现有额度或 workspace credits。但实际在非 Business 订阅 Work / Codex 中无法直接通过模块调用，API 暂不适合国内的场景。 - GitHub Issue [#29741](https://github.com/openai/codex/issues/29741) 是一个功能请求，希望在 Codex Mac app 中加入原生的 Deep Research 任务模式，能够结合当前 workspace 上下文做研究。Issue 中指出，ChatGPT 的 Deep Research 和 Codex 的 workspace 上下文目前是割裂的，且单独调用 API 需要额外计费。 - `o3-deep-research` 模型已被标记为 Deprecated，退役日期 2026-11-19，替代模型为 `gpt-5.6-sol`（[Azure 模型退役计划](https://learn.microsoft.com/azure/foundry/openai/concepts/model-retirement-schedule)）。OpenAI 似乎在向基座模型 + 搜索接口的模式迁移，而非维护独立的深度研究模型。 - **豆包、Kimi** 等国内产品的深度研究能力同样仅限网页端体验，API 平台未提供独立的深度研究端点。 - 单次深度研究的搜索规模通常在数百次级别，公开来源显示典型 sources 数为 50–200（[Deep Research 模式对比](https://presenc.ai/research/deep-research-mode-comparison-2026)），部分复杂任务可能更多。 ## 尝试二：本地模拟多轮搜索研究 / Goal 模式 两种思路都试过：用 `web_search` + 外挂豆包搜索 API 本地模拟；或者开 Goal 模式做长程任务。 共同的问题：**仍然需要规定研究范围、产出的边界和约束条件。** 不规定明确边界情况下，它的产出非常不稳定。 具体坑： - 同时接 `web_search` 和豆包搜索 API，codex 会在两个源之间摇摆，效果反而不如单源。 - 豆包搜索 API 拿不到网页正文以及 PDF 内容，只能拿到摘要和片段 —— 这是另一个更复杂的问题。 - 而且没有解决根本问题：长程任务。 - Goal 模式反而更没用：它对研究边界的要求严格，常常因为提示词过于严格而过早结束任务。 - 子代理这种事儿没什么用。上下文割裂的损耗远大于分工的收益。 ## 尝试三：用开源 Skill 模拟 找了一圈，缺少高星的 Skill 仓库或成品，社区上的使用案例也不多，效果不明确。并且鉴于 Skill 本身就是提示词，其多轮研究稳定性就是一个大问题，很难快速验证其 budget forcing 的效果。如果不能达到 OpenAI/Kimi 深度研究的 800 次检索的效果，这个方案并不值得尝试。 ## 尝试四：回退到网页深度研究的提示词设计 绕了一圈，最后还是回到网页版深度研究的方案上，毕竟它真的输出了一个质量尚可的结果，并且踏踏实实做了数百次搜索。更多的精力应该是放到提示词设计上。 检索了 OpenAI 深度研究提示词的最佳实践之后的几个收获： - **过宽 / 过严都不太好。** 太宽了模型乱跑，太严了变成工作流，失去了研究的灵活性。 - **规定结果，不要规定过程。** 告诉它最终要交付什么，比告诉它第一步做什么第二步做什么效果好。 - **对于复杂研究，需要有研究方法规则。** 一些宏观方法方面的约定还是有必要。它其实是最终结果的一部分，不单纯是过程。比如要不要交叉验证、要不要标注来源、要不要区分事实和推测。这些是研究规范，属于结果的质量标准。 - **Schema 和数据清洗不应该是研究的任务。** 一上来就规定 JSON Schema，模型会为了满足形式化字段要求，而影响研究准确性。推进使用广召回的思路开展研究，再用后置的 grounding 来收敛和结构化。深度研究本质上是高召回，不要放太多数据处理和清洗工作。 - **OpenAI** 乍一看读了 800+ 链接，但是结果很差。很多链接只是扫了标题，真正消化的没多少。 - **Kimi** 比 OpenAI 强很多。可见性不错（每次 50 个，再进一步探索），中文信源友好。 完整的实践可以参考 [OpenAI Deep Research 指南](https://developers.openai.com/api/docs/guides/deep-research)——可以说明研究的问题、期望结果、相关限制条件，也可以指定报告结构和来源；长程任务的提示词实践则参考 [Claude 提示词最佳实践](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices)。 ## 我最终采用的结构 提示词分为四个部分： 1. **角色与任务定义**：明确研究主体身份、研究目标及交付对象。报告用于结构化市场地图的数据导入与人工审阅，优先级依次为事实准确与可追溯、候选覆盖完整、口径可比、数值完整。不得为满足字段要求牺牲准确性，亦不得因数值缺失删除已核验的市场对象。 2. **固定研究范围**：以表格形式界定地域、渠道、纳入品类、排除品类、研究窗口、基准年与币种。此部分对应前文所述「研究范围的预先界定」——不界定则产出不稳定。 3. **研究与筛选规则**：共 13 条规则，覆盖候选覆盖、实体层级（公司/品牌/产品线/SKU）、来源优先级、交叉验证、数值性质标注（直接披露/计算/估算/代理/不可得）、梯队判断、分类归属、增长期间可比性及结束条件等。此部分对应前文所述「研究方法中的宏观过程属于结果质量标准」——并非规定执行过程，而是规定研究规范。 4. **唯一输出格式**：一份固定的 Markdown 模板，包含三个部分——市场总表、产品线模板（每条重复）、来源与数据缺口附录。所有来源集中于附录，主报告表格内不嵌入链接。模板结构较为松散，不要求 JSON Schema，数值缺失以「不可得」标注——对应前文所述「Schema 与数据清洗应留给后置 grounding 收敛」。 整体对应前述原则：以表格界定研究范围，以规则定义研究规范而非执行过程，输出仅提供模板而不约束 Schema，以保障高召回，结构化与数据清洗留待后置收敛。