一个复杂研究任务，常常可以拆成多个相对独立的方向。
例如比较几种技术路线，可以分别研究架构、部署、生态和风险；核验一个行业判断，可以分别寻找官方资料、论文和公开案例。
如果所有方向都由一条 Agent 链路串行完成，任务会很长，一处早期偏差也可能影响后面全部判断。Research-Synthesis 的思路，是先拆出可独立验收的研究单元，按依赖关系分批并行，再综合它们的结构化结果。
它听起来像“多开几个 Agent 就能更快”，这恰好忽略了最难的调度问题。
有的单元要等前置结果，有的会共享同一个搜索服务，还有的会因慢页面或限流变成尾部任务。并行度过高时，排队、重试和综合开销可能抵消节省的时间，因此不能保证一定更快。
所以面试官真正想听的是：
哪些子任务适合并行，怎样建立依赖图和分批调度，如何为共享工具分配并发与预算，慢单元拖尾时是等待、降级还是部分完成，最后又怎样验证综合成本没有抵消并行收益？
Research-Synthesis 不是简单地多开几个 Agent
并行的价值来自“原本必须等待的工作可以同时推进”，而不是 Agent 数量本身。
子任务之间存在强依赖时，后续单元在前置结果出现前没有完整输入。强行同时启动，往往只会造成返工。
即使子任务没有逻辑依赖，它们也可能竞争同一个模型服务、搜索配额或访问工具。并发过高会将执行时间从调用阶段移到排队和重试阶段。
多个单元返回后，综合器还要统一实体、版本、单位和来源关系。单元越多，去重、口径对齐和上下文组织的成本也越高。
结果冲突仍然需要处理，但它属于综合阶段的一个检查项。两个 Agent 得到不同数字，可能是版本、时间和测试条件不同，不应直接投票。
Research-Synthesis 的主问题因此是：哪些单元真正可以并行，共享资源能承受多少并发，最慢单元是否位于关键路径，以及综合开销是否值得。
并行调度先解决任务依赖和资源约束；结果进入综合阶段后，再处理来源独立与冲突。
哪些任务适合并行？
第一类是对象可以拆开。
比较三个技术方案时，每个研究单元负责一个对象，使用相同字段收集部署方式、能力边界和版本信息。
第二类是维度可以拆开。
同一个对象可以分别研究架构、性能口径、安全、生态和上线风险，前提是维度之间依赖较弱。
第三类是来源类型可以拆开。
一个单元寻找官方资料，一个查论文，一个寻找公开工程实践，用不同证据视角减少单一来源偏差。
第四类是验证任务可以拆开。
一个单元提出候选结论，另一个专门寻找反例、过时信息和限定条件。
不适合并行的是强依赖链路。如果第二步必须使用第一步识别出的实体和条件，强行同时执行只会让后续单元拿不到正确输入。
任务很小、共享工具有严格限流、综合成本高于执行成本时，也不值得拆。框架选型仍然要选择最低够用复杂度。
拆分标准决定并行质量
“你查一部分，我查一部分”不是合格计划。
每个研究单元需要明确六项内容。
一是研究问题。它必须可以独立回答，不能只写“继续深入”。
二是范围边界。包括对象、时间、版本、地区和不处理的内容。
三是交付字段。所有单元使用兼容 Schema，至少返回 Claim、Evidence、来源、限定条件、冲突和缺口。
四是来源要求。哪些字段必须由原始或官方资料支持，哪些可以使用第三方分析。
五是预算和停止条件。允许多少搜索和访问，什么时候返回部分完成。
六是依赖关系。真正依赖前序结果的单元不进入同一批并行。
拆得太粗，一个单元内部仍然很长；拆得太细，管理、去重和综合成本会超过收益。应让每个单元形成一个可以独立验收的研究闭环。
一条可执行的并行研究链路
第一步，规划器解析总任务，建立共同任务契约和全局术语表。
第二步，生成研究单元和依赖图。只有无前置依赖或前置已完成的节点进入当前并行批次。
第三步，调度器分配预算、工具并发和截止时间，避免所有单元同时打满同一个外部服务。
第四步，各研究单元独立执行，并按统一 Schema 返回主张、证据、冲突、缺口、执行状态和可审计动作摘要。
第五步，归一化层统一实体、版本、时间、单位和来源 ID，识别重复 URL 与同源转载。
第六步，综合器按主张聚合支持、反对和待验证证据，保留无法对齐的冲突。
第七步，根据缺口决定补充研究、局部重跑或生成部分完成报告。
第八步，发布前逐主张核验引用与限定条件，再生成统一报告。
并行只发生在无依赖研究单元，综合前还需要归一化和来源去重。
研究单元为什么要尽量独立？
如果所有 Agent 使用完全相同的提示、相同查询和相同搜索排序，它们很可能重复同一条路径。
表面上运行了三个 Agent，实际只是把一次偏差复制了三遍。
独立不等于随机乱搜。更合理的做法是让研究单元承担不同对象、维度或证据角色，同时共享用户任务和术语定义。
例如一个单元只核对官方能力边界，一个单元查公开实验条件，一个单元主动寻找失败案例。它们的交付 Schema 一致，但问题与来源策略不同。
还要控制信息泄漏。如果负责反证的单元一开始就看到主单元的完整结论，它可能只围绕现有说法搜索，而没有独立发现其他问题。可以只给它待核验主张和范围，不给带倾向的长解释。
独立性的最终判断仍落在证据上：来源是否真正独立，搜索路径是否高度重复，结论差异是否来自不同口径。
综合器先归一化，再写报告
多个单元可能用不同名字指同一个对象，也可能把同名对象误认为一个。
时间表达也不同：“当前版本”“去年发布”“最新文档”都需要落到具体访问时间和版本。
性能字段更容易出错。延迟、吞吐、准确率和成本依赖硬件、数据规模、并发、缓存和计算方式，字段名相同不代表可以横向合并。
来源也要标准化。带追踪参数的同一 URL、转载页面和引用同一公告的媒体应建立来源关系，不能重复计数。
因此综合器先建立实体映射、时间版本、单位口径和来源图，再处理主张。跳过这一步直接让模型“综合以下答案”，最容易生成一份语言统一、事实关系混乱的报告。
多个 Agent 结论冲突，怎样处理？
先检查对象是否一致。
一个结论谈云服务，另一个谈自托管版本，就不是同一对象。
再检查时间和版本。
旧资料与新发布说明不同，可能描述的是能力演进。
再检查指标和条件。
两个测试使用不同数据规模和硬件，数字不可直接投票。
再追溯原始出处。
多个页面若都引用同一份资料，只能视为一个证据源。
最后看证据强度与适用性。
官方文档适合确认功能，独立测试适合说明特定条件下的表现，用户讨论适合发现 bad case。来源类型不同，不能简单设置永久高低分。
若口径对齐后仍有真实冲突，报告应并列各自证据和适用条件，标记无法确认的部分。必要时触发一个定向复核单元，而不是让综合器凭多数或语言自信度选边。
一个教学场景：三个 Agent 得到“三种性能”
下面是教学情境，不代表真实产品或实测数字。
总任务要求比较某技术的公开性能边界。
研究单元 A 找到官方页面，报告一个理想配置下的结果。
研究单元 B 找到第三方测试，硬件、数据规模和过滤条件不同，数值更低。
研究单元 C 找到一篇博客，引用的其实就是 A 的官方页面，但省略了测试条件。
若使用多数票，A 和 C 看似形成两票，系统会选择官方数值。
合格综合应先识别 C 与 A 同源，再说明 A 和 B 的测试条件不可直接比较。最终报告可以分别呈现两个结果及条件，不能生成一个平均数，也不能说“多数来源证明”。
这个例子说明，综合阶段的单位是证据关系，不是答案数量。
并行一定更快吗？
不一定。
总耗时通常受最慢研究单元影响。一个页面反复超时，其他单元即使早已完成，综合器也可能等待。
共享搜索服务或模型服务有并发限制。任务并行过多会触发排队、限流和重试，尾延迟反而增加。
若子任务有隐含依赖，后续单元会因为输入不完整返工。
综合阶段也有固定成本。研究单元越多，归一化、去重、冲突处理和上下文组织越复杂。
因此需要并发上限、超时、部分完成策略和分批调度。并行的目标可以是缩短独立任务的墙钟时间，也可以是增加证据覆盖与可靠性。具体收益取决于任务结构、工具容量和综合开销，不能承诺必然提速。
失败隔离和局部重跑怎样设计？
每个研究单元要有独立状态：待执行、运行中、完成、部分完成、失败和取消。
某个单元失败，不应让已经完成的证据全部作废。综合器可以先判断它是否属于关键路径。若只是低优先级补充，报告可带缺口继续；若它覆盖用户必须项，则定向重试或降级来源。
重跑时要保留任务版本和幂等 ID。相同单元因网络重试返回两次，不能被当成两个独立研究结果。
若范围或任务契约发生变化，只重跑受影响单元，并重新检查与它相关的综合结论。不要无条件把所有 Agent 从头运行。
部分完成报告要列出成功单元、失败单元、已确认主张和未解决缺口。不能把缺一块的表格用模型补齐。
并行预算怎样分配？
平均分配最简单，却不一定合理。
关键路径、证据稀缺和用户必须项需要更高预算。容易从官方文档直接核验的子任务可以更早收口。主动寻找反例的单元可能搜索次数较多，但一旦找到能够改变结论的证据，价值也更高。
规划器可以先给每个单元基础预算，再根据早期结果动态调整。某单元连续返回重复来源，继续增加预算意义不大；某个关键冲突已经缩小到一个明确缺口，可以定向追加一次访问。
预算不仅是步骤数，还包括模型调用、工具调用、并发槽位、时间和来源数量。某个单元消耗完自己的额度，不能偷偷占用其他单元资源，也不能把预算耗尽标成正常完成。
动态调整要留下理由和全局上限，避免综合器每发现一个缺口就无限新增 Agent。
综合器怎样避免生成新的事实？
综合器很容易为了让段落连贯，在两个研究单元之间补一条没人验证过的因果关系。
解决方法是先生成主张级合并结果，再写自然语言。每个最终主张必须指向至少一个有效 Evidence ID，派生计算还要指向输入数据和方法。没有来源的连接句只能用于结构表达，不能新增事实含义。
对冲突主张，综合器只能选择三种状态：条件可解释后分别适用，证据不足后保留不确定，或触发定向复核。不能把两边平均，也不能因为一边文字更完整就判定它正确。
发布前可以反向检查：最终报告里每个关键事实，在研究单元输出中是否存在同义主张；如果只在综合稿首次出现，就进入人工或自动复核队列。
这种约束会让综合稿少一些“聪明补全”，却能明显降低多 Agent 合并时产生的新幻觉。
综合阶段怎样控制上下文？
把所有 Agent 的完整聊天记录交给综合器，很快又会遇到上下文膨胀。
研究单元应输出结构化结果：任务范围、主张、证据 ID、来源、限定条件、冲突、缺口和状态。原始网页与完整 Trace 放在外部存储。
综合器只读取当前需要的字段。遇到关键冲突时，再按 Evidence ID 取回相关片段。
相同主张先聚合来源，不要在上下文里重复十遍。相同来源的转载要建立父子关系。已经被判定过时的主张保留状态，但不与当前结论混排。
综合结果本身也需要版本。新增一个迟到单元时，只更新受影响主张，而不是让模型完全重写报告并改变无关内容。
Research-Synthesis 应该怎样评测？
第一，任务覆盖。
计划中的对象和维度是否都被研究，失败单元有没有造成隐藏空白。
第二，来源独立性。
多个研究单元是否只是重复同一查询和同一原始出处。
第三，冲突处理。
系统能否识别版本、时间和口径差异，能否保留无法解决的真实冲突。
第四，综合正确性。
最终主张是否被对应证据支持，是否在合并中产生了原单元都没有的新事实。
第五，执行效率。
观察墙钟时间、尾延迟、总工具调用、重复来源、限流、重试和综合开销。并行度越高不一定越好。
第六，恢复能力。
单元失败、迟到、重复返回和任务修改时，系统能否局部重跑并保持已有可靠结果。
覆盖、独立性、冲突和资源需要一起评估，不能只看最终答案相似度。
对照实验至少包含单 Agent 串行、按对象并行、按证据角色并行三种方案。任务要覆盖可完全并行、部分依赖和不适合并行的类型，才能找到选型边界。
Trace 怎样支持并行问题排查？
全局 Trace 需要关联总任务 ID、研究单元 ID、依赖版本、预算和综合批次。
每个单元记录开始与结束状态、工具调用、来源、主张和失败原因。综合节点记录读取了哪些单元版本、做了哪些来源归一、哪些冲突被保留或触发重跑。
排查尾延迟时，可以看到时间花在排队、工具超时、模型生成还是等待依赖；排查事实错误时，可以追到原研究单元和 Evidence ID；排查重复时，可以比较不同单元的查询、URL 和内容指纹。
不要只保存一张最终多 Agent 对话。没有单元与综合的层级关系，团队只能看到结果不一致，却无法确定是拆分、执行还是合并出了问题。
四类 bad case 怎样定位？
Bad case 一：三个 Agent 引用同一篇原文
建立规范化 URL、内容指纹和引用关系图。报告按原始出处计数，不按页面数量计数。
Bad case 二：综合器把不同版本揉成一句
统一实体和版本字段，主张合并前先检查适用条件。无法对齐时保持多条主张。
Bad case 三：一个慢单元拖住全部任务
设置单元截止时间、关键路径和部分完成策略。低优先级单元迟到后可作为报告增量更新。
Bad case 四：并行后工具限流更严重
在调度层设置按工具的并发和速率预算，使用排队、退避和备用来源，不能让每个 Agent 各自无上限重试。
面试官继续追问，怎么接？
追问一：为什么不直接跑三次，选最长的答案？
长度不代表证据质量。需要统一主张和来源结构，识别重复、冲突和限定条件，再按证据综合。
追问二：多个 Agent 多数一致，能认为是真相吗？
不能。它们可能共享模型偏差、搜索排序或同一原始来源。多数只能作为待核验信号，结论仍要回到独立证据。
追问三：怎样让并行单元既独立又不重复？
按对象、维度或证据角色拆分，给出不同范围与来源策略，同时共享任务契约和输出 Schema。执行后再用查询、URL 和内容指纹检查重复。
追问四：并行为什么可能更慢？
尾延迟由最慢单元决定，共享工具会限流，隐含依赖导致返工，综合器也有开销。需要受控并发和任务依赖图。
追问五：某个单元失败，是否必须全部重跑？
不需要。按主张和依赖关系判断影响，局部重跑失败单元，已有可靠证据继续保留；关键缺口未解决时输出部分完成。
面试时怎样解释并行研究与综合
Research-Synthesis 先把总任务拆成可独立验收的研究单元，再按依赖关系安排并行；多开几个 Agent 只是表象。规划阶段要统一用户任务、范围、交付 Schema、来源要求和预算，只有前置条件已满足的单元才进入当前批次。
调度器要按模型和工具容量限制并发，为每个单元记录截止时间、执行状态和幂等 ID。慢单元位于关键路径时定向重跑或降级；非关键单元超时时，可以保留缺口并输出部分完成。各单元仍用统一 Schema 返回 Claim、Evidence ID、来源和限定条件，来源冲突在综合阶段对齐口径后保留。
验收会比较串行和不同并行拆法在任务覆盖、墙钟时间、尾延迟、工具排队、重复调用、限流、局部恢复和综合开销上的表现。并行可能提高覆盖或缩短独立任务时间，但收益取决于依赖、工具容量和综合成本，不能承诺一定更快。
并行链路是否真的带来收益
用一条存在独立分支和尾部任务的 Trace 核对下面四点，别只凭任务同时启动就宣称提速。
- 子任务是否真的独立，还是存在未声明的前置依赖？
- 模型与各工具是否分别设置并发、预算和截止时间？
- 尾部任务能否按关键路径选择等待、重跑、降级或部分完成？
- 是否同时记录并发收益、尾延迟、失败恢复与综合开销？