Deep Research 拿到一个大问题后，怎么拆成能查证的子问题？

“帮我分析一下这个行业。”

这句话对人来说已经够模糊，对 Agent 更危险。

如果模型直接搜索“行业分析”，得到的通常是一堆范围不同、时间不同、口径不同的材料。它可能先看到市场规模，就围着规模写；也可能先看到一篇新闻，就把新闻里的观点当成整份报告的主线。

最后的报告很长，却没有回答三个最基本的问题：研究对象是谁，比较维度是什么，结论需要哪些证据。

Deep Research 超出普通搜索的地方，在于它会先把开放任务整理成一组可以执行、检查和收口的子任务。初始计划又不可能永远正确；Agent 看到新证据后，还要判断应该沿用原计划、补一个分支，还是推翻前提重新规划。

所以面试官真正想问的是：

一个开放研究问题怎样拆成可查证的子问题？每个子问题如何定义完成标准？中间出现信息缺口或矛盾时，系统怎样重规划而不陷入漫无目的搜索？

第一步先补全任务契约

很多“问题拆解”失败，是因为模型在用户意图还不清楚时就开始列目录。

用户说“比较三种方案”，至少还缺几类信息：用于什么场景，数据规模怎样，团队能承担多少运维，是否必须私有部署，时间范围是什么，最终要一页结论还是完整报告。

如果这些约束会改变结论，系统应该先追问。没有用户可以立即补充时，也要把假设写出来，例如“以下分析以小团队、自建服务、低运维为前提”。假设不应藏在报告最后，因为所有后续检索都受它影响。

一个清楚的任务契约可以包含五部分。

研究对象：到底比较哪些候选，是否允许执行中新增或淘汰候选。

研究维度：性能、成本、部署、生态、合规等哪些维度是硬要求，哪些只是补充。

时间范围：查当前状态、某个历史时间点，还是最近一段时间的变化。

证据要求：是否优先官方资料、论文和公开数据，是否允许使用二手分析。

交付格式：直接建议、对比表、带引用报告，还是只整理事实不做决策。

任务契约给后续计划划出边界。缺少这层约束，Agent 就无法判断查到什么时候算够，再工整的 Prompt 也解决不了这个问题。

哪些缺失信息必须先追问？

并不是每个模糊点都值得打断用户。

判断标准是：不同答案是否会改变研究路线或最终建议。部署方式、数据权限、时间范围和硬预算通常会改变候选与证据，应优先澄清；报告颜色、章节顺序之类偏好，可以先采用默认值，后续再调整。

追问也要具体。不要问“请补充更多信息”，而应问“你要求私有部署，还是可以使用托管服务？”“结论需要反映当前版本，还是梳理最近一年的变化？”用户一次就能回答，任务契约也能直接更新。

若产品形态不允许同步追问，可以输出两个备选研究范围，让用户选择；或明确采用最保守假设，并把它放在报告开头。系统必须把“用户确认的事实”和“为了继续执行采用的假设”分开存储，后续证据不能反过来把假设伪装成用户需求。