“帮我分析一下这个行业。”
这句话对人来说已经够模糊，对 Agent 更危险。
如果模型直接搜索“行业分析”，得到的通常是一堆范围不同、时间不同、口径不同的材料。它可能先看到市场规模，就围着规模写；也可能先看到一篇新闻，就把新闻里的观点当成整份报告的主线。
最后的报告很长，却没有回答三个最基本的问题：研究对象是谁，比较维度是什么，结论需要哪些证据。
Deep Research 超出普通搜索的地方，在于它会先把开放任务整理成一组可以执行、检查和收口的子任务。初始计划又不可能永远正确；Agent 看到新证据后，还要判断应该沿用原计划、补一个分支，还是推翻前提重新规划。
所以面试官真正想问的是：
一个开放研究问题怎样拆成可查证的子问题？每个子问题如何定义完成标准？中间出现信息缺口或矛盾时，系统怎样重规划而不陷入漫无目的搜索？
第一步先补全任务契约
很多“问题拆解”失败，是因为模型在用户意图还不清楚时就开始列目录。
用户说“比较三种方案”，至少还缺几类信息：用于什么场景，数据规模怎样，团队能承担多少运维，是否必须私有部署，时间范围是什么，最终要一页结论还是完整报告。
如果这些约束会改变结论，系统应该先追问。没有用户可以立即补充时，也要把假设写出来，例如“以下分析以小团队、自建服务、低运维为前提”。假设不应藏在报告最后，因为所有后续检索都受它影响。
一个清楚的任务契约可以包含五部分。
研究对象：到底比较哪些候选，是否允许执行中新增或淘汰候选。
研究维度：性能、成本、部署、生态、合规等哪些维度是硬要求，哪些只是补充。
时间范围：查当前状态、某个历史时间点，还是最近一段时间的变化。
证据要求：是否优先官方资料、论文和公开数据，是否允许使用二手分析。
交付格式：直接建议、对比表、带引用报告，还是只整理事实不做决策。
任务契约给后续计划划出边界。缺少这层约束，Agent 就无法判断查到什么时候算够，再工整的 Prompt 也解决不了这个问题。
哪些缺失信息必须先追问？
并不是每个模糊点都值得打断用户。
判断标准是：不同答案是否会改变研究路线或最终建议。部署方式、数据权限、时间范围和硬预算通常会改变候选与证据，应优先澄清；报告颜色、章节顺序之类偏好，可以先采用默认值，后续再调整。
追问也要具体。不要问“请补充更多信息”，而应问“你要求私有部署，还是可以使用托管服务？”“结论需要反映当前版本，还是梳理最近一年的变化？”用户一次就能回答，任务契约也能直接更新。
若产品形态不允许同步追问，可以输出两个备选研究范围，让用户选择；或明确采用最保守假设，并把它放在报告开头。系统必须把“用户确认的事实”和“为了继续执行采用的假设”分开存储，后续证据不能反过来把假设伪装成用户需求。
评测中应加入同一句模糊请求在不同约束下需要不同结论的样本，检查 Agent 是否先发现关键缺口，而不是直接沿默认偏好开始搜索。
子问题要拆到“可以采取动作”
一个子问题是否合格，可以看它能否对应明确动作和产出。
“研究候选 A”不够具体。Agent 不知道先查功能、成本还是部署，也不知道什么结果算完成。
“确认候选 A 是否支持私有部署，并找到官方部署文档”就清楚得多。动作是搜索并访问官方文档，产出是支持状态、适用版本、部署条件和来源。
“了解性能”也太宽。可以改成“在与当前数据规模接近的公开测试中，找到查询延迟或吞吐口径，并记录硬件、数据集和配置；如果口径不可比，明确标记不能横向比较”。
好的子问题通常包含四个字段：要确认的主张、允许使用的工具、期望证据和完成条件。
判断拆解是否合格，要看每一项能否独立行动并接受验收，句子数量并不重要。
三种最常用的拆解轴
第一种是按对象拆。
比较三个候选时，为每个候选建立相同的事实采集任务，再做横向综合。这样可以避免第一篇资料写了什么，报告就只比较什么。
第二种是按维度拆。
同一个对象可能需要分别研究能力、部署、成本、生态和限制。维度最好先由任务约束决定，而不是搜索后临时拼凑。
第三种是按依赖关系拆。
有些问题必须先得到前置事实，后续任务才有意义。例如先确认实际规模和查询模式，才能判断某个性能测试是否相关；先确认许可证，才需要继续评估商业使用边界。
真实任务通常把三种轴组合起来。可以先按维度定义统一模板，再按对象并行取证，最后按依赖关系安排先后顺序。
拆得太粗，Agent 会在一个节点里自由发挥。拆得太细，则会制造大量管理开销和重复搜索。判断粒度的标准是：一个子任务能否由一种主要动作完成，结果能否独立检查，同时又不会小到只查询一个无意义词条。
把计划做成一张带状态的任务图
很多 Demo 让模型先输出一个漂亮目录，然后逐条搜索。目录一旦生成就不再变化，这仍然是静态 Workflow，不是真正的研究规划。
研究计划至少需要记录四类状态。
已确认结论：已经得到可靠证据、当前可以使用的事实。
待验证假设：目前有线索，但证据还不足，不能写成确定结论。
信息缺口：应该回答却尚未找到资料的部分。
下一步任务：为了补缺口或验证假设，具体要执行什么动作。
这四类内容也可以成为演进报告的一部分。每轮新观察到来后，系统更新当前研究状态：新增证据、修改假设、关闭任务、创建任务或标记无法确认；网页全文则单独留在证据层，避免持续挤占上下文。
计划的价值是指导下一步和暴露缺口，而不是提前预测所有搜索关键词。
什么情况只更新当前分支？
如果新资料只是补充现有结论，就不需要重新规划。
例如当前任务是确认某方案的部署要求。第一份官方文档给出了操作系统，第二份补充了依赖版本。两份信息都属于同一个子任务，更新证据和完成状态即可。
如果一个来源暂时打不开，也不必改整张计划。可以在当前分支重试、换镜像、找另一份官方资料，或者标记该来源不可用。
如果搜索结果为空，先检查查询表达是否过窄。换关键词、去掉不必要限定、从候选名称切换到具体能力，仍然属于局部调整。
把所有意外都当成重规划，会让系统不断推翻自己，前面做过的工作难以复用。
什么情况应该触发重规划？
第一类触发是前提被推翻。
例如任务原本比较三种自建方案，执行中发现其中一个只提供托管服务。它不再满足硬约束，后续性能细节可能已经没有价值，计划应淘汰该候选或新增替代方案。
第二类触发是出现关键新对象。
研究某技术生态时，多份来源反复指向一个初始计划没有覆盖的核心组件。此时应增加一个研究对象，并为它补齐统一维度；继续沿旧关键词多搜一篇文章解决不了结构性缺口。
第三类触发是关键维度缺失。
初始计划只比较功能和性能，执行中发现许可证或数据合规会直接影响落地。这个维度会改变最终建议，应提升为正式任务，而不是报告末尾随口提醒。
第四类触发是证据冲突无法在当前路径解决。
两个来源给出相反结论，继续搜索相同关键词只会得到更多转述。计划需要增加“核对口径、时间、版本和原始出处”的分支。
第五类触发是预算与剩余价值不匹配。
已经消耗大量步骤，但某个低优先级问题仍然没有公开资料。系统可以降低该任务优先级，转而完成影响结论的关键部分，并在报告里保留缺口。
这些触发条件要能在 Trace 中看到。否则每次计划变化都像模型临时起意，团队无法复盘是合理调整还是跑偏。
重规划不能把已确认事实全部清空
最常见的错误，是每次重规划都让模型重新生成完整计划，旧状态被覆盖。
这样做有两个后果。一是已经验证过的结论失去来源，后面又被重复搜索；二是旧计划里的信息缺口被“写没了”，系统看起来完成，实际只是忘记了未解决问题。
更稳的方式是增量修改。
保留已经确认的事实和来源；关闭不再相关的任务并记录原因；为新增对象复制必要的比较维度；调整任务优先级；对被推翻的假设保留变更记录。
计划版本至少要能回答：这次为什么改，增加或删除了什么，哪些证据导致变化，剩余预算怎样重新分配。
这种记录保存的是可审计的任务动作和证据依据，并不展示模型的隐式思考过程。公开界面可以说明“新增合规检查，因为候选涉及外部数据传输”，无需暴露模型内部的逐字推理。
子任务还需要排序，不能全部同时开跑
拆出十几个子问题后，下一步不是立刻全部并行。
有些任务属于硬约束检查。候选如果不支持必须的部署方式，后续性能和生态调研可能都没有必要，应优先执行。
有些任务是前置依赖。没有确认版本和部署形态，就无法判断某份性能资料是否适用。前置事实没有得到之前，后续比较只能保持阻塞。
有些任务彼此独立，可以并行。例如三个候选都要确认许可证，各分支使用统一输出结构，完成后再横向合并。
还有些任务价值低但成本高。某个背景信息不影响最终建议，即使公开资料很难找，也不应挤占关键维度的预算。
因此可以为子任务记录优先级、依赖、预估动作、是否影响最终结论和当前状态。优先级不需要追求一个虚假的精确分数，但要能解释为什么先做这一项。
怎样控制并行分支的合并质量？
并行可以缩短等待，却会放大不一致。
如果三个分支各自用不同字段记录结果，综合阶段只能再次让模型阅读三篇自由文本，前面结构化拆解的价值就没了。
每个分支应使用统一交付：当前结论、支持证据、反对证据、来源时间、版本、限定条件、信息缺口和任务状态。比较类任务还要使用统一维度，某个分支没有数据就明确为空，不能用相近信息替代。
合并时先做结构校验，再处理冲突和缺口，最后才生成自然语言。若某个分支失败，主任务应知道缺的是哪一格，而不是把整个研究报告判定失败。
并行分支也要共享“已访问来源”和任务契约，避免三个 Agent 重复打开同一页面，或各自改变研究范围。共享的是可审计状态，不是彼此的隐式推理。
一个教学示例：技术选型任务怎样拆
下面是教学示例，不代表某个真实客户项目，也不包含实测结果。
用户请求：“为一个中小规模、希望少投入运维的知识库项目，比较三种向量存储方案，并给出建议。”
先整理任务契约：对象为三个候选；硬约束是中小规模和低运维；维度包括部署方式、过滤能力、扩展性、生态和迁移成本；优先官方资料；最终输出对比表、建议和限制。
第一组子任务确认候选是否满足硬约束。若某候选部署形态明显不符，可以提前停止后续深挖。
第二组子任务按统一维度采集事实。每一条都要求版本和来源，不能只记录“性能好”“生态强”。
第三组子任务检查资料是否可比。不同硬件、数据规模和索引参数下的性能数字不能直接横向排序。
第四组子任务综合取舍。建议必须回到用户约束，而不是宣布某个方案“最好”。
如果执行中发现用户现有数据库已经能够安装向量扩展，迁移成本这个维度的权重就会改变。计划需要新增“复用现有基础设施”的核验，而不是继续只比公开性能榜单。
四种失败拆解，一眼就能看出问题
失败一：按报告目录拆，不按证据任务拆
计划只有“背景、现状、趋势、建议”。这些是写作章节，不是研究动作。Agent 仍然不知道要查什么和怎样验收。
修复方式是先定义事实采集和核验任务，最后再把证据组织成报告目录。
失败二：每个候选使用不同维度
候选 A 查性能，候选 B 查价格，候选 C 查生态，最后无法比较。
修复方式是先建立统一维度模板，允许某些格子写“未找到可比资料”，不能用其他事实偷偷填补。
失败三：把搜索结果数量当完成条件
找到十个页面不代表问题已经回答。十篇文章可能都转载同一条未经核实的信息。
完成条件应与证据质量相关，例如是否找到原始出处、是否覆盖关键维度、冲突是否解释。
失败四：计划越改越大
模型每看到一个新名词就创建分支，任务范围不断膨胀。
修复方式是让新增任务必须说明它会影响哪个最终结论，并检查剩余预算。与任务契约无关的内容放入“可选延伸”，不进入主链路。
怎么验证拆解和重规划做得好不好？
第一，检查覆盖。
预先为评测问题标注必须回答的对象、维度和证据要求，看最终计划是否覆盖，不能只看生成了多少子问题。
第二，检查可执行性。
子任务是否能映射到明确工具，是否有完成状态，是否出现“继续深入研究”这种无法执行的空话。
第三，检查重复。
统计相同或高度相近的搜索、重复访问和已经关闭后重新创建的任务。重复多，通常说明状态没有保存好。
第四，检查计划变化质量。
人工查看重规划是否由新证据触发，是否保留旧事实，是否真正修复缺口。不能把“变更次数越多”当成更智能。
第五，检查最终证据。
每个关键结论能否回到一个或多个来源；报告里标出的信息缺口，是否与计划中未完成任务一致。
第六，检查任务利用率。
创建的子任务中，有多少真正影响了最终报告；有多少在没有新证据时反复重建；被提前关闭的任务是否保留原因。这个检查用于发现计划膨胀，不是要求所有任务都必须完成。
计划质量要看覆盖、可执行、少重复和证据闭环，而不是子问题数量。
面试官继续追问，怎么接？
追问一：子问题是不是越细越好？
不是。太粗会让模型自由发挥，太细会产生调度和重复开销。合适粒度是一项主要动作可以完成，结果能独立验收，同时对最终结论有明确贡献。
追问二：怎样避免重规划导致死循环？
限制计划变更范围和次数只是硬兜底，更重要的是每次变更必须引用新证据或明确缺口，并检查是否与历史计划重复。没有新增信息时不允许仅换一种说法重建计划。
追问三：用户没有给完整约束怎么办？
关键约束会改变结论时先追问；无法追问时明确写出假设，并在报告中保留。不能把模型猜测当成用户事实。
追问四：计划应该由一个模型生成，还是规则生成？
开放问题适合模型提出候选任务，硬约束、任务 Schema、预算和状态转换适合程序控制。两者结合比完全自由生成更容易验证。
追问五：如何让并行子任务最后可以合并？
所有分支使用统一输出 Schema，包括结论、证据、时间、版本、置信边界和缺口。没有统一结构，并行只会更快地产生一堆难以比较的文本。
怎样讲清“先拆解、再重规划”
我不会让模型收到开放问题后直接列一个报告目录，而会先整理任务契约，明确研究对象、时间范围、比较维度、证据要求和交付格式。然后把任务拆成可以执行和验收的子问题，每个子问题包含要验证的主张、可用工具、期望证据和完成条件。
执行过程中维护已确认结论、待验证假设、信息缺口和下一步任务。新观察只是补充现有维度时，更新当前分支；如果前提被推翻、出现关键新对象、发现会改变结论的新维度，或者来源冲突无法在当前路径解决，才触发重规划。重规划采用增量修改，保留已确认事实和来源，并记录为什么新增、关闭或调整任务，不能每次把旧计划全部覆盖。
验证时我会看计划是否覆盖必须回答的对象和维度，子任务是否可执行，重复搜索是否过多，计划变化是否由新证据触发，以及最终每个关键结论能否回到证据。我会控制子问题数量，用尽可能少的有效任务完成可核验研究。
你的 Planner 能否拿出这些证据
面试官真正会追的是计划怎样变化：准备一条由新证据触发增删任务的记录，再回答下面的问题。
- 你的“规划”是一次生成的目录，还是带状态、可以增量更新的任务结构？
- 子问题有没有明确输出和完成条件？
- 是否保存计划变更原因、触发证据和已关闭任务？
- 是否存在真实 Trace 可以证明重规划，而不是只在架构图里写了 Planner？
- 如果没有项目代码和轨迹，只能说这是设计方案，不能冒充已经上线。
Deep Research 的规划能力体现在：每拿到一份新证据，都知道下一步最值得查什么，而不必假装一开始就能猜对未来十步。