面试官可能会问：“一个 Deep Research 任务里有检索、分析和写报告，是不是应该分别做三个 Agent？”
很多人会直接回答“多 Agent 分工更专业”。但把三个 Prompt、三个名字和三段对话连起来，不代表系统真的获得了新的能力。任务边界不清时，多 Agent 只会增加消息传递、上下文复制、状态一致性和失败归因成本。
反过来，一个 Agent 同时面对大量工具、相互冲突的指令、很长的中间轨迹和多个独立目标，也可能出现工具选择混乱、注意力被稀释、一步失败拖垮整条链路的问题。此时合理拆分可以隔离上下文、权限和评估，让每个角色只处理自己擅长的一段。
所以这道题应从任务是否存在可验证的职责边界开始，而不是比较“一个模型和多个模型谁更聪明”。先用单 Agent 加工具建立基线，找到真实失败证据，再决定是否按角色拆分。拆分要换来上下文隔离、专用工具、独立验收、故障隔离或真实并行中的至少一项，否则只是架构装饰。
先给出 30 秒回答
复杂任务不一定要拆成多 Agent。我会先用单 Agent 加工具建立端到端基线，观察失败是否来自上下文过长、工具集合过大、角色目标冲突、权限边界不同、子任务能否独立评估，或是否存在真实并行机会。只有职责相对正交、输入输出契约清楚、可以独立验收，而且拆分收益大于通信与一致性成本时才拆。步骤强耦合、共享上下文很多、决策必须频繁来回或任务本来很简单时，单 Agent 通常更稳。上线前用同一任务集比较完成质量、失败恢复、Trace、调用开销和人工纠错，不用 Agent 数量证明系统先进。
最关键的是先问“拆分解决哪个已观察到的问题”，而不是先决定要用几个 Agent。
拆分只有在职责、上下文、权限或评估边界真实存在时才有价值。
先定义什么叫单 Agent
单 Agent 不等于只能做一步，也不等于只能调用一个工具。
一个 ReAct Agent 可以围绕同一目标循环执行思考、选工具、观察结果和继续决策。它可以调用搜索、网页访问、代码执行、数据库查询等多个工具，也可以维护结构化 State、Checkpoint 和失败恢复。
它的关键特征是：主要决策由同一个角色和一套核心上下文完成，目标、工具结果和后续动作都在同一控制循环里。
这套设计的优势是状态路径短。模型不需要把中间结论翻译成另一个 Agent 的输入，调试时可以沿同一 Trace 看计划、工具和答案。对于目标明确、步骤不多、工具集合可控、上下文共享度高的任务，单 Agent 通常是最小可行方案。
不要为了“看起来像 Agent 团队”，把同一个 Prompt 复制三份再换名字。若三个角色使用相同模型、相同上下文、相同工具和相同验收标准，它们很可能只是增加调用次数。
多 Agent 真正改变了什么
多 Agent 的价值来自角色专业化和边界，而不是数量。
每个 Agent 可以有独立目标、提示、上下文、工具权限、状态视图和评估器。检索角色只负责形成搜索查询并返回带来源的证据；分析角色只读取授权证据，识别冲突与缺口；报告角色根据已确认材料组织结构，不重新访问任意外部资源。
这种拆分能减少每个角色看到的无关信息，让工具集合更小，也便于为不同阶段设不同成功条件。检索失败不必伪装成报告质量问题，写作风格错误也不需要重跑所有搜索。
但它同时引入交接。上游必须把结果压成下游可理解的契约；共享状态要有版本；重复事实要去重；权限要随角色变化；失败要决定局部重试还是整体回退。每多一个 Agent，就多一条潜在信息损失与责任不清的边。
第一个判断：职责是否相对正交
可拆分的职责通常可以用一句话说清输入、动作、输出和完成条件。
例如“检索角色接收研究子问题，输出带 URL、时间、摘要和相关性说明的证据候选”，它有独立输入输出，也能单独检查是否有来源、是否与问题相关。
如果两个角色必须持续共享全部隐式推理，频繁互相补充上下文，且任何一步都无法独立验收，拆分价值就很弱。比如一个简单数据查询中，把“理解字段”和“生成 SQL”强行拆给两个 Agent，后者仍需要看到用户问题、Schema 和前者所有假设，交接可能比单 Agent 更复杂。
正交不代表完全独立，而是边界足够稳定。上游输出什么、下游依赖什么、错误怎样返回都能写进契约。若契约只能写“把你知道的都发过去”，说明职责还没有拆清。
第二个判断：上下文是否需要隔离
单 Agent 的上下文会同时包含系统规则、用户目标、计划、工具描述、历史 Observation 和中间草稿。任务变长后，无关信息增多，模型可能忽略关键约束或在大量工具中选错。
多 Agent 可以让每个角色只看到必要视图。检索角色需要查询、来源规则和搜索工具，不需要完整写作模板；报告角色需要证据、结构和表达要求，不需要原始搜索日志；评审角色需要验收标准和产物，不需要影响其判断的生成草稿过程。
但上下文隔离不是简单截断。被隐藏的信息中可能有关键约束。拆分前要列出每个角色的最小必要上下文、禁止访问内容和来源引用。交接使用结构化工件，而不是将上一个 Agent 全部聊天记录复制过去。
如果所有角色最终都要看同一份完整上下文，拆分不能解决注意力问题，反而会把相同 Token 重复发送。
第三个判断：工具与权限是否不同
一个拥有搜索、写数据库、发消息、删除文件和运行代码等全部工具的 Agent，能力面过大。即使 Prompt 要求谨慎，模型选错工具的影响也可能很高。
按职责拆分可以执行最小权限。研究 Agent 只读公开资料，执行 Agent 才能调用有副作用的业务工具，发布 Agent 必须经过人工批准。每个 Agent 的 Tool Registry 更小，工具描述更聚焦。
权限边界真实存在时，拆分有明显价值。但不能只在 Prompt 中写“你无权发布”，底层仍把发布工具暴露给它。工具网关要根据身份和角色执行授权，交接也不能把敏感结果复制给无权下游。
如果所有工具都是低风险只读，并且数量少，权限通常不足以单独支持多 Agent。可以先通过工具路由和分组减少暴露面。
第四个判断：能否独立评估
多 Agent 最容易被忽视的收益，是把端到端失败拆成可验收阶段。
检索阶段可以检查证据覆盖、来源可访问、时间与问题相关；分析阶段检查冲突、缺口和结论是否有证据；报告阶段检查引用、结构和未支持主张。这样最终答案错误时，Trace 能定位最早失效的阶段。
如果角色没有自己的完成条件，系统仍然只能看最终答案好不好。此时多 Agent 只是把同一黑盒拆成多个黑盒。
拆分前应为每个角色定义输入 Schema、输出 Schema、禁止项、成功条件、错误类型和测试样本。能否写出这些内容，是判断职责是否成熟的直接方法。
第五个判断：是否有真实并行价值
互不依赖的子问题可以并行。例如研究一个主题时，多个子问题可以同时检索，最后由统一节点合并。并行可能缩短等待外部工具的总时长，也能让不同角色独立探索。
但“可以并行”不等于“应该同时启动更多 Agent”。子任务依赖同一限流服务、共享昂贵上下文、结果高度重复或最终合并很复杂时，并行会增加成本与去重工作。
需要先画依赖图。没有数据依赖的分支才可并行；必须使用上游结果的步骤保持顺序；对共享资源设置并发与背压；合并节点定义去重、冲突和缺失分支处理。
没有真实运行数据时，只能说设计上允许并行，不能承诺具体延迟降低比例。
先确认失败证据，再判断职责、上下文、权限、评估和并行边界。
哪些场景更适合单 Agent
任务步骤少且目标清楚。用户问一个限定范围的问题，Agent 调一两个只读工具即可完成，没有必要引入角色交接。
子步骤高度耦合。每一步都需要完整理解上一轮细节，输出难以形成稳定契约，拆分会反复复制上下文。
工具集合小且权限一致。工具选择没有明显混淆，副作用风险可由网关和人工确认控制。
评估只能端到端完成。中间阶段无法定义独立正确性，强行拆分不利于归因。
任务量与并发不足。多 Agent 的通信、状态和运维开销无法被专业化或并行收益抵消。
系统还在探索需求。先用单 Agent 快速建立任务集、失败样本和 Trace，通常比过早设计复杂团队更容易找到真实边界。
哪些信号说明应该考虑拆分
同一个 Agent 的系统提示出现相互冲突的角色要求，例如既要大胆探索，又要保守审核；既要生成方案，又要独立批判自己的结论。
工具数量和领域跨度增大，模型经常选错工具，或工具权限无法按最小原则收敛。
上下文中存在大量阶段性噪音，报告角色只需要结论和证据，却被原始搜索轨迹淹没。
某一阶段有清楚且可独立评估的产物，例如证据包、代码补丁、风险报告或审查结论。
部分分支天然并行，等待外部工具占主要时间，并且结果可以通过稳定合并规则汇总。
故障需要隔离。一个来源访问失败不应让全部任务重头开始，某个评审不通过可以退回特定阶段。
这些是“考虑拆分”的信号，不是自动结论。仍要比较单 Agent 加工具路由、上下文压缩、专用节点或代码工作流是否已能解决。
多 Agent 会新增哪些成本
通信成本。每次交接都要序列化目标、事实、假设和未完成项，信息可能丢失或被误读。
状态一致性。多个角色可能同时修改计划、证据或工件，需要单一事实源、版本和冲突规则。
上下文复制。相同背景发送给多个 Agent，会增加 Token 与延迟。
评估成本。每个角色需要独立数据集、契约测试和端到端组合测试。
错误传播。上游错误可能被下游当作事实放大，必须保留来源和验证节点。
权限与隐私。共享消息可能把一个角色可见的数据泄露给另一个角色。
运维复杂度。重试、超时、幂等、并发、背压、版本兼容和 Trace 都比单循环更多。
如果方案评审只写收益不写这些成本，通常说明设计仍停留在概念层。
一个 Deep Research 任务怎样判断是否拆分
假设任务是“围绕一个技术主题检索资料、识别冲突、形成带引用报告”。
先做单 Agent 基线：同一角色规划子问题，调用搜索和访问工具，整理证据并写报告。记录工具选择错误、上下文长度、引用遗漏、失败恢复和人工纠错。
如果主要问题是搜索工具太多，可以先做工具路由，不一定拆角色。如果主要问题是原始网页占上下文，可以把内容存工件并摘要，不一定多 Agent。如果报告经常把未验证搜索摘要当事实，而证据检查可以独立验收，则可以考虑拆出证据分析或审查角色。
若子问题互相独立，可以并行检索，但每个分支输出统一证据 Schema。分析节点只接收来源、摘录、时间和相关性，不看无关工具日志。报告节点只使用已确认证据，并保留引用。
最终仍要与单 Agent 基线比较。若拆分没有降低最早失败率、人工修正或任务成本，只增加了调用次数，就应该回退或缩小拆分范围。
单 Agent 和多 Agent 应该怎样做公平对比
使用同一任务集、同一工具权限、同一模型能力范围和同一最终验收条件。不能给多 Agent 更多工具与上下文后，再把提升归因于 Agent 数量。
任务集需要覆盖简单任务、长任务、工具失败、证据冲突、权限拒绝、信息不足和需要人工确认的场景。简单任务用于验证多 Agent 是否过度设计，复杂任务用于观察专业化价值。
记录端到端完成、各阶段首次失败、调用数量、Token、等待时间、重试、人工介入和最终引用质量。没有真实数据时只定义这些观测口径，不填写数字。
还要做消融：单 Agent 加工具路由、单 Agent 加摘要与工件、固定代码工作流、两角色拆分和完整多 Agent。这样才能知道收益来自上下文隔离、工具收敛、独立评审，还是仅仅增加了采样次数。
评估结果可能支持“不拆”。这不是失败，而是说明任务的最小可靠架构已经足够。
专业化收益必须和通信、状态、评估与权限成本一起比较。
拆分后最少需要哪些契约
虽然本题不展开具体编排，但决定拆分之前必须确认交接可实现。
每个角色至少定义：目标、输入字段、可见上下文、可用工具、输出字段、完成条件、失败类型和是否允许重试。跨角色工件保存来源、版本和所有者。共享 State 指定哪些字段只有某个角色可写，避免互相覆盖。
交接内容区分事实、推断和待验证项。下游不能把上游一句自然语言总结直接当权威事实。重要证据保留引用，必要时回读原始工件。
如果这些契约写不出来，先不要拆。模糊职责进入多 Agent 后，只会在运行时用更多对话解决本可以在设计时解决的问题。
常见的四种假拆分
第一种是角色改名。Researcher、Analyst、Writer 使用相同提示和全部工具，只是顺序调用。
第二种是重复投票。多个 Agent 回答同一个问题，却没有独立证据、不同权限或明确聚合规则，只靠多数决定事实。
第三种是把代码步骤包装成 Agent。固定格式转换、字段校验和确定性路由本可由代码完成，却交给模型增加不确定性。
第四种是 Supervisor 包办一切。名义上有多个角色，实际所有上下文、判断和修复都回到中央 Agent，形成单点瓶颈。
识别假拆分的方法很简单：删除某个角色后，系统失去了什么独立能力、权限边界或验收证据？如果回答只是“少调用一次模型”，这个角色很可能没有必要。
怎样做上线前验收
先验证单 Agent 基线可回放，知道失败发生在哪。没有基线就无法证明拆分价值。
再验证每个角色的契约与权限。给检索角色输入非法项目、无权资源和工具错误；给分析角色冲突证据与缺失证据；给报告角色不支持的主张，检查它是否拒绝编造。
组合测试覆盖上游为空、部分分支失败、重复证据、版本冲突、超时、重试和人工中断。多 Agent 不应因为一个角色无结果就无限互相对话。
端到端比较结果要能支持回退。若简单任务显著变复杂，考虑按任务风险动态选择单 Agent 或多 Agent，而不是全站统一走最复杂路径。
先证明问题存在，再证明拆分真的解决它。
面试官会怎样连续追问
追问一：任务复杂就应该拆多 Agent 吗
不一定。复杂可能来自工具、状态或长上下文，可以先用工具路由、工件化和代码工作流解决。只有存在稳定职责、权限或独立评估边界时才值得拆。
追问二：多 Agent 最大的收益是什么
不是模型数量，而是上下文、工具、权限和评估专业化，以及可验证的故障隔离或并行。
追问三：什么时候单 Agent 更好
目标清楚、步骤少、子任务强耦合、共享上下文多、工具权限一致、无法独立验收时，单 Agent 路径更短更容易调试。
追问四：怎样证明拆分有效
用同一任务集与单 Agent 基线比较端到端完成、首次失败、人工修正、调用开销和 Trace，并做工具路由、摘要、工作流与角色拆分消融。
追问五：多个 Agent 意见不一致怎么办
先看它们是否引用不同事实或只是表达不同。事实冲突需要来源和验证器，策略冲突按任务规则或人工裁决，不能仅用多数投票代替证据。
追问六：固定步骤也需要 Agent 吗
确定性的格式转换、路由和校验优先用代码。Agent 用在需要语义判断、开放探索或不确定决策的位置。
单 Agent 还是多 Agent：怎样给出工程判断
我不会因为任务复杂就直接拆多 Agent。先用单 Agent 加工具建立基线，记录失败是上下文过长、工具混淆、角色目标冲突、权限过大、无法独立评估，还是缺少并行。职责相对正交、输入输出契约清楚、每个阶段能独立验收，并且拆分能带来上下文隔离、最小权限、故障隔离或真实并行时，我才会拆。步骤强耦合、共享信息多、任务简单或所有角色最终都看相同上下文时，单 Agent 更稳。拆分后每个角色要有自己的目标、工具、可见状态、输出 Schema 和失败类型。最后用同一任务集与单 Agent、工具路由和代码工作流基线比较，而不是用 Agent 数量证明架构先进。
拆分多 Agent 前，先核对这十项
- 是否先建立单 Agent 基线，并保存可回放 Trace。
- 每个角色能否用一句话说清输入、输出和完成条件。
- 拆分是否真正隔离上下文、工具、权限、评估或故障。
- 子任务是否有稳定契约，而不是传递全部聊天记录。
- 是否把确定性转换、校验和路由优先交给代码。
- 并行分支是否真的无依赖，并有并发、去重和合并边界。
- 是否评估通信、状态、一致性、权限和运维成本。
- 是否覆盖上游为空、部分失败、冲突、超时和人工中断。
- 评估是否允许得出“不拆更好”的结论。
- 没有真实数据时，是否避免虚构效率、延迟和质量提升。
单 Agent 与多 Agent 没有固定高下。真正专业的选择，是用最小的可靠结构完成任务，并且能用失败证据解释为什么此处需要拆、为什么别处不需要。