简介：本文从上下文耗尽这一常见现象切入，分析深度搜索代理在长链路检索中容易卡住的原因，并对“单代理串行推理”与“多代理分工协同”两种方案进行对比。文章会说明两类思路各自的特点、适用场景和选型依据，帮助开发者在构建AI搜索与复杂信息处理流程时，更合理地设计代理结构与上下文管理策略。
在AI深度搜索代理的评测中，有一个结果让不少团队重新审视了系统设计。一些能力较强的模型被放进标准搜索代理框架，去完成需要多轮网络检索才能回答的问题。测试给出了相当充裕的上下文长度，甚至接近一部长篇文本的容量。
但结果并不理想。相当比例的任务没有答错，而是根本没答完，就被上下文限制截断了。
这个现象说明，AI搜索能力的瓶颈不一定出在“检索意图判断”或“资料阅读理解”上，而可能出在更基础的地方：代理在长任务推进中，把自己的工作记忆塞满了。
研究者把问题归纳为两个层面：
这两类问题并不是新发现。此前已经有一些工程手段试图缓解，例如压缩历史上下文、摘要缓存、人工拆分任务等。但要同时解决角色耦合与上下文累积，需要一个更系统的设计思路。
在讨论如何缓解上述问题时，业界逐渐形成两类典型的实现路径。
这是较早出现、也是最常见的搜索代理形态。一个模型同时负责推理、搜索动作调用、证据整理和最终回答。它的工作方式类似于在一条不断增长的消息记录里，反复执行“读取—判断—行动—读取”的循环。
这类方案的优势是结构简单。开发者只需要维护一个代理实例、一个提示词模板和一套搜索工具接口。对于短链路问答、浅层事实核查和低轮次检索任务，它的开发成本与调试成本都比较低。
但问题在于，它的能力边界非常明显。随着轮次增加，以下现象会逐渐出现：
这些问题不是简单增加上下文长度就能消除。上下文越长，模型在长历史中定位关键信息的难度也可能越高。换句话说，单代理串行推理的瓶颈往往来自“记忆管理方式”，而不是“模型不够强”。
另一类方案尝试把不同职责拆开。例如，由一个代理负责规划检索步骤，另一个代理负责阅读和压缩页面内容，第三个代理负责整合证据并形成答案。它们共享的不是同一条不断膨胀的对话记录，而是更明确的工作产物，例如结构化笔记、证据表、待验证问题列表和最终草稿。
这种思路的出发点，是把“过程思考”和“答案产出”从同一上下文中解耦。规划代理不需要保留所有页面原文，阅读代理也不需要承担最终结论的表述压力。
多代理方案通常包含以下工作流：
这种结构让不同类型的中间信息有了不同的存放位置。过程性内容不会被无限堆进同一个提示上下文，推理噪声得到一定控制。
但多代理方案的复杂度也明显更高。开发者需要设计不同代理之间的数据传递格式、错误处理机制和状态管理方式。任务的合理拆分本身就是一个工程问题。如果拆分粒度不合适，代理之间来回传递的开销可能超过收益。
尽管两套方案在架构思路上存在明显差异，但它们仍然有不少共同点。
无论使用单代理还是多代理，目标都是让模型在信息不完整、需要多步检索的场景中，逐步逼近可靠答案。
两类方案通常都需要接入搜索能力、网页读取能力或文档检索能力。模型本身不直接拥有答案，而是通过对外部信息的读取、筛选和整理来形成结论。
即使是多代理方案，也无法完全摆脱上下文长度限制。每个子代理仍然需要在有限的工作记忆内完成自己的任务。区别在于，多代理方案更强调“不让所有记忆共用同一个空间”。
工程上，两者都需要处理工具调用、失败重试、解析错误、异常返回等问题。区别更多体现在状态如何划分、信息如何在阶段之间传递。
单代理串行推理的核心是一条不断延伸的执行链。模型在多轮循环中反复切换“想想下一步”和“实际执行”的状态。它的架构可以概括为：
用户问题 → 模型推理 → 搜索动作 → 读取结果 → 模型再推理 → 继续搜索 → 最终回答
多代理分工协同则更像一条流水线，每一步的输出被整理成下一步可消费的“工作产物”，而不是全部塞回同一个对话上下文。例如：
用户问题→ 规划代理：拆解子问题→ 检索代理：执行搜索→ 提取代理：整理证据→ 写作代理：生成答案
其中，规划代理的中间推理不一定要完整出现在写作代理的输入中。写作代理看到的是经过筛选和结构化后的证据池，而不是全部搜索历史。
单代理方案中，信息流呈线性累积。每一轮新增内容都会叠加到已有历史之上。即使某个搜索结果不相关，它仍然可能留在后续上下文中，持续制造干扰。
多代理方案中，信息流更接近“合并—压缩—传递”。原始搜索结果经过提取后，只保留与问题相关的部分；无效信息可以在阶段之间被丢弃；不同子问题可以使用不同的上下文分支。
这种信息流设计带来一个直接好处：最接近最终答案的那一步，不必背上全部过程负担。模型更容易聚焦于证据，而不是淹没在搜索片段中。
单代理方案对早期错误较敏感。例如，模型在第一步选择了错误的检索关键词，后续即使发现问题，也可能因为历史中已经积累了错误搜索结果而难以纠正。更常见的情况是，模型受既有内容影响，倾向于继续沿着错误方向深入。
多代理方案在理论上可以在阶段之间引入“校验”和“重规划”。规划代理可以根据证据提取结果调整下一轮子问题；写作代理如果发现证据不足，也可以请求补充检索，而不需要从上下文里逐字翻找旧内容。
当然，这并不意味着多代理方案不会出错。阶段之间的信息损失、提取偏差、任务拆解错误，都会引入新的风险。但错误的传播路径更可控一些。
单代理方案通常只需要维护一个模型会话，资源消耗较为线性。对于较浅的检索任务，它的响应速度更快，调用链更短。
多代理方案往往涉及更多次模型调用。即使是同一个底层模型，也需要为规划、提取、写作等环节分别执行推理。这会带来额外的计算成本、时间成本和接口调用复杂度。在任务较简单时，多代理方案可能显得“重”。
单代理方案调试起来更直观。出现问题的时候，可以直接检查模型完整的执行轨迹。缺点是调优手段有限，因为所有问题都纠缠在同一条链路中。
多代理方案调试成本更高，但可调空间也更大。开发者可以单独调整某个代理的提示词、输出格式或工作逻辑，而不必每次都影响整条链路。对于需要长期维护、反复迭代的复杂搜索流程，这种模块化会更有价值。
| 对比维度 | 单代理串行推理 | 多代理分工协同 |
|---|---|---|
| 架构复杂度 | 较低，逻辑集中在单条执行链 | 较高，需要设计任务拆分与信息传递 |
| 上下文增长方式 | 线性不断累积 | 阶段间可压缩、筛选和重置 |
| 角色边界 | 推理、检索、写作职责耦合 | 规划、提取、写作等职责相对分离 |
| 早期错误传播 | 容易持续影响后续步骤 | 可通过阶段产物进行纠正和重规划 |
| 有效信息密度 | 随轮次增加可能下降 | 更依赖结构化证据，信息噪声相对可控 |
| 开发与调试成本 | 较低，流程直观 | 较高，需要额外设计代理协作机制 |
| 适合任务 | 短链路问答、事实核查、轻量搜索 | 多跳推理、长链路证据收集、深度研究 |
| 对模型调用成本 | 相对较低 | 相对更高，多次调用和阶段处理 |
| 性能稳定性 | 对简单任务较稳定 | 对复杂任务更可控，但增加了系统复杂度 |
当任务满足以下条件时，单代理方案通常更合适：
例如，面向知识库的简单问答、对某个明确对象的基本信息查询、基于少量页面的摘要生成等，单代理串行推理足以应对。此时引入多代理反而会增加工程负担。
当任务具备以下特征时，更值得考虑多代理方案：
例如，复杂研究报告生成、多角度事实核查、需要对比多个候选方案的技术调研、长文档与网络信息结合的分析任务等。这些任务更强调过程管理与证据质量，而不是单次推理速度。
选型时，不要只比较“单代理”和“多代理”这两个名字，而应关注以下几个方面：
一个较为务实的做法是，先用单代理方案完成原型，在真实任务中观察上下文耗尽、答案截断、信息混淆等问题是否频繁出现。如果这些现象成为主要瓶颈，再逐步将规划、提取和写作拆分为独立代理。
如果从单代理方案迁移到多代理方案，需要特别注意以下几点：
AI搜索代理在长链路任务中频繁“憋死”的现象，并不是单纯增加上下文长度就能解决。单代理串行推理将规划、检索、阅读和写作放在同一条不断膨胀的上下文中，虽然结构简单，但在复杂任务中容易出现职责耦合和信息噪声累积。
多代理分工协同通过拆分角色、阶段化整理证据、控制信息传递范围，缓解了过程性内容对最终答案的干扰。但它也带来更高的系统复杂度、更多的模型调用和更复杂的运维要求。
两者之间没有绝对的优劣。是否选择多代理架构，取决于任务长度、答案质量要求、团队维护能力和成本预算。对于短链路搜索任务，单代理方案依然是最直接高效的选择；对于需要多轮检索、证据整合和交叉验证的深度研究场景，将职责适度拆分的多代理设计，往往更能保证最终答案完整、可追溯且不被过程信息淹没。
真正的改进方向，不在于把上下文越开越大，而在于让不同性质的信息待在应该待的地方。