多数据源并发召回为什么使用专用线程池，如何隔离共享线程池风险？

核心回答

Ragent 的固定问答流程会先改写、拆分问题和识别意图，再并发召回相关知识片段，融合后交给模型生成回答。本例按 ragent.engine.type=workflow 说明固定问答流程。固定版本默认配置为 agent，由另一个 AgentScope Agent 入口通过知识工具复用检索模块，两条主线应分别说明。

这条路线把子问题编排、通道召回和内部取数放进不同的专用执行器，减少对全局共享池的依赖；但不同检索源并没有各自独占一个池。它还提供通道超时与空结果降级，能放弃慢通道结果，不能据此认为底层任务已经停止或请求总耗时一定不超过该值。

三层线程池分别承担什么？

检索模块的输入是子问题、意图作用域与召回预算，输出是供融合、重排和上下文组装使用的知识片段。

• ragContextExecutor 按子问题并发构建检索上下文。
• ragRetrievalExecutor 并发执行当前启用的向量、关键词、图谱或网页通道。通道是否参与，仍受后端配置和开关控制。
• innerRetrievalExecutor 承担通道内部的并行取数，例如向量和关键词的补充路，以及需要逐库执行的向量检索。

线程池配置中，前两者的线程数均为可用 CPU 数的四倍，使用不存储任务的 SynchronousQueue；内部取数池的核心数为两倍、最大数为四倍，队列容量为 100。三者都使用 CallerRunsPolicy。这些是当前实现的配置，是否适合部署环境仍需结合任务扇出、连接池和负载验证。

这种划分分开了编排与子任务使用的执行资源，但向量、关键词等通道仍共享通道池，主路与补充路也共享内部池。若某个外部源经常超时，进一步按依赖设置独立池或并发额度，属于可评估的改进，不是已有的每源隔离能力。

超时和降级具体怎样生效？

多通道引擎先提交各通道任务，分别挂上 orTimeout，再等待结果；超时或异步失败会转换为空通道结果，让其余结果继续融合。各任务先并发提交，后面逐个 join() 不等于按顺序才开始查询。

超时处理没有取消底层任务。向量、关键词补充路的异常也分别转换为空列表，正常返回的主路候选仍可保留。

还有一个饱和边界：代码先调用 supplyAsync(..., executor)，返回后才配置超时。若触发调用者执行，supplyAsync 可能在提交线程中执行慢查询，直到它返回后才挂上计时；后续通道的提交也会被延后。因此，配置中的通道超时不是整次请求的硬截止，调用者执行还会突破“任务只占专用池工作线程”的设想。

怎样验证隔离是否有效？

验证需要同时看结果与资源占用，可以用可控的检索替身注入慢响应、异常和正常结果，再逐步增加并发：

• 单源变慢： 检查健康通道的候选是否仍进入融合、超时是否被记录；继续观察返回后的活动线程和连接，确认后台任务何时真正结束。
• 线程池饱和： 检查任务是否在调用者线程运行、后续通道提交是否延迟，以及队列等待和端到端 P95／P99 是否上涨。SynchronousQueue 没有积压长度，不能只靠队列为零判断系统有余量。
• 补充路失败： 检查主路候选是否保留；全部通道无可用证据时，固定流程应结束并提示未检索到相关文档，而非继续生成知识答案。
• 持续负载与恢复： 关联提交／完成速率、活跃线程、排队时间、拒绝或调用者执行次数、超时率和连接等待。恢复依赖后，确认过期任务没有持续挤占新请求。

这些检查分别回答“返回是否按预期降级”和“资源是否真正受到约束”；仅看到接口及时返回，不能证明慢源已经被隔离。