AI Agent 落地避坑：从多Agent路由翻车，最终收敛到「域聚合Agent+多Tool」最优架构

最近在企业智能问答 Agent 项目落地中，完整踩了一遍单Agent多Tool、纯多Agent路由分发、混合域聚合Agent三大架构的所有坑。

很多新手开发都有一个误区：多Agent架构=更高级、更专业。

但真实生产落地结论完全相反：过度拆分多Agent是大部分AI对话系统脏数据、上下文污染、路由判错、混合意图翻车的核心根源。

本文结合实战踩坑，复盘三种架构的优劣、边界问题，以及最终落地的工业级折中最优方案：域聚合Agent + 域内多Tool + 前置重排序。

一、初期架构：纯多Agent路由分发（按意图拆分）

1.1 初始设计思路

最开始采用行业主流的 Router + 专家Agent 模式，按用户意图一刀切拆分三大独立Agent：

• ChatAgent：负责闲聊、问候、日常对话
• KnowledgeAgent：负责内部制度、文档、流程RAG问答
• BusinessAgent：负责订单、售后、业绩、报表业务数据查询

路由层四层决策逻辑：Redis会话缓存 → 关键词字典匹配 → LLM意图分类 → 兜底降级。

整体设计初衷：职责解耦、工具隔离、单Agent职责单一、减少工具幻觉。

1.2 实战致命坑（真实落地翻车点）

架构跑通Demo很简单，但接入真实用户对话后，暴露出多个无法根治的硬伤：

坑1：共享Session上下文互相污染（最严重）

整套系统共用同一套 Redis ChatMemory、同一个 SessionId。
用户先查订单、查报表（产生大量业务历史），再切换闲聊：
路由正确分发到 ChatAgent，但闲聊Agent会读取全部业务历史上下文，大模型被脏数据带偏，闲聊输出业务数据、乱回复订单内容。
反之亦然：闲聊后切业务，冗余闲聊文本干扰业务工具调用与RAG检索。

坑2：路由一刀切，无法处理同域混合意图

多Agent路由的本质是二选一、一刀切分发。
用户提问：“帮我查下本月订单和销售业绩”
订单、业绩同属业务域，但路由分类边界模糊，极易分发错误，导致工具无法调用、回答异常。
只要用户一句话包含多个同业务场景诉求，纯路由架构直接失效。

坑3：意图重叠场景无解，补丁永远补不完

业务问题、知识库问题存在大量重叠场景：
例如：“退款的官方流程是什么？”
既属于业务操作，又属于知识库制度查询。
路由判业务、判知识都合理，无论判给谁，都会出现能力缺失。
靠关键词拦截、Prompt约束、上下文Rerank降噪，都只是治标不治本的补丁，永远存在逃逸case。

坑4：多套Agent逻辑冗余，维护成本极高

三套Agent重复实现：SSE流式输出、异常捕获、链路追踪、工具循环逻辑。
代码大量冗余，迭代需求需要同步改三处，极易出现版本不一致bug。

二、备选方案：回归纯单Agent多Tool架构

踩完多Agent路由坑后，第一想法是：干脆去掉路由，回归单Agent，所有工具全部托管给一个Agent。

2.1 优势

• 彻底消灭路由分发错误问题
• 天然支持混合意图，一句话同时调用多个工具
• 单套会话上下文，无跨Agent隔离、无上下文污染割裂问题
• 代码极简，维护成本极低

2.2 无法规避的硬缺陷

单Agent挂载全部工具，工具数量越多，大模型工具幻觉概率指数上升。
闲聊场景下，模型依然能看到订单、知识库工具，存在概率性乱调用工具、强行检索数据的问题。
同时，每次请求下发全部工具列表，Token开销大、推理延迟高，生产稳定性一般。

行业共识：单Agent挂载超过5‑8个工具，准确率会明显下滑。

三、最终落地最优解：域聚合Agent + 域内多Tool + 前置重排序

结合两套架构的优缺点，最终收敛出折中且最适合生产落地的架构，解决所有痛点，无明显短板。

核心思想：放弃「按意图拆分Agent」，改为「按业务域聚合Agent」

不再拆分闲聊Agent、知识Agent、业务Agent，而是同域能力聚合，跨域轻量路由。

3.1 全新架构分层

1）路由层（只做大域区分，不做精细切割）

路由只负责三分类，边界极宽、极少判错：

• 业务域意图 → 进入 BusinessDomainAgent
• 知识库域意图 → 进入 KnowledgeDomainAgent
• 纯闲聊 → 直接兜底回复，不进入工具Agent链路

路由不再处理精细意图、不再一刀切拆分同域重叠需求，大幅降低出错概率。

2）域聚合Agent（核心亮点）

每个Agent只负责一个完整业务域，域内所有能力靠多Tool实现：

• BusinessDomainAgent：聚合订单、业绩、退款、售后所有业务工具，同域混合意图（查订单+看业绩）全部由Agent内部多Tool调度，路由无需感知
• KnowledgeDomainAgent：聚合多路RAG召回、重排、文档解析工具，专注内部知识库问答

核心解决：同域重叠、多诉求混合提问的路由翻车问题。

3）前置重排序+上下文降噪

所有DomainAgent统一执行前置 历史Rerank过滤：

• 业务Agent自动过滤闲聊、知识库无关历史，杜绝脏数据干扰
• 知识库Agent自动过滤业务冗余上下文，提升RAG精准度

同时前置做检索重排、去重、低分文档过滤，只引导模型、不强制决策，兼顾灵活性与稳定性。

4）闲聊轻量化降级

干掉独立 ChatAgent，闲聊作为路由兜底分支：
识别为纯闲聊时，不加载任何工具、不进入工具循环，直接流式回复，零幻觉、零工具误调用。

3.2 跨域重叠问题最终解决方案

针对「业务+知识」跨域重叠场景（退款流程、制度咨询）：
业务域Agent内置知识库工具依赖，业务场景下可自主调用文档检索工具，无需路由纠结归属。
彻底解决边界模糊、双向归属的疑难场景。

3.3 核心生产代码示例（Spring‑AI Java伪代码）

关键点：域路由、上下文Rerank降噪、域内绑定工具集合、闲聊不走Agent工具链路

/**
 * 域聚合Agent入口服务
 */
@Service
public class DomainAgentService {

    private final LlmRouter llmRouter;
    private final ChatMemory redisChatMemory;
    private final ContextRerankFilter contextRerankFilter;

    // 业务域Agent，只绑定业务域工具集合
    private final ChatClient businessDomainAgent;
    // 知识库域Agent，只绑定知识库工具集合
    private final ChatClient knowledgeDomainAgent;

    /**
     * 构造初始化：每个域Agent只注入本域Tool，不全局灌入全部工具
     */
    public DomainAgentService(ChatClient.Builder builder,
                              OrderTool orderTool,
                              ReportTool reportTool,
                              RefundTool refundTool,
                              KnowledgeRagTool knowledgeRagTool,
                              DocumentRetrieveTool docRetrieveTool,
                              DocRerankTool docRerankTool) {

        // 业务域聚合Agent：业务工具 + 内嵌知识库工具，处理业务+制度混合问题
        businessDomainAgent = builder
                .defaultTools(orderTool, reportTool, refundTool, knowledgeRagTool)
                .build();

        // 知识库域聚合Agent：仅文档相关工具
        knowledgeDomainAgent = builder
                .defaultTools(docRetrieveTool, docRerankTool)
                .build();
    }

    /**
     * 对话主入口
     */
    public Flux<String> chat(String sessionId, String userQuery) {
        // 1、获取原始完整会话历史
        List<Message> originHistory = redisChatMemory.get(sessionId);

        // 2、大域粗路由，只区分三大域，不做细粒度意图
        DomainType domainType = llmRouter.classifyLargeDomain(userQuery, originHistory);

        // 【重点】闲聊直接兜底，不走Agent工具链路，零工具幻觉
        if(DomainType.CHAT == domainType){
            return simpleChatReply(userQuery);
        }

        // 3、上下文前置Rerank降噪：过滤掉和当前域无关的历史消息，解决上下文污染
        List<Message> cleanHistory = contextRerankFilter.filter(originHistory, userQuery, domainType);

        // 4、根据域选择对应聚合Agent，Agent内部自主调度多个tool处理混合意图
        ChatClient selectedAgent;
        if(DomainType.BUSINESS == domainType){
            selectedAgent = businessDomainAgent;
        }else if(DomainType.KNOWLEDGE == domainType){
            selectedAgent = knowledgeDomainAgent;
        }else {
            throw new RuntimeException("domain error");
        }

        // SSE流式输出，开启tool calling循环
        return selectedAgent.prompt()
                .messages(cleanHistory)
                .user(userQuery)
                .stream()
                .content();
    }

    /**
     * 纯闲聊轻量化兜底，不加载任何tool
     */
    private Flux<String> simpleChatReply(String query){
        // 简单大模型直接返回，不走工具调用循环
        return Flux.just("闲聊回复...");
    }

    public enum DomainType {
        BUSINESS, KNOWLEDGE, CHAT
    }
}

/**
 * 上下文Rerank过滤器核心片段：剔除无关历史，解决上下文污染
 */
@Component
public class ContextRerankFilter {
    public List<Message> filter(List<Message> rawHistory, String query, DomainType domainType){
        // 1、将历史消息与当前query做相关性打分
        // 2、根据domainType过滤不相关历史：业务域过滤闲聊消息；知识库域过滤大量业务对话
        // 3、保留最近N轮+高相关性历史，截断超长上下文
        // 返回清洗过后的干净消息列表给Agent使用
        return rawHistory.stream()
                .filter(msg -> scoreRelevant(msg, query, domainType) > 0.3)
                .limit(12)
                .toList();
    }

    private double scoreRelevant(Message message, String query, DomainType domainType){
        // 调用rerank模型做相关性打分
        return 0.0;
    }
}

四、三种架构终极对比（实战总结）

架构模式	优点	致命缺点	落地推荐度
纯多Agent意图路由	工具隔离、单Agent轻量化、Token开销低	上下文互相污染、混合意图无解、路由易判错、补丁泛滥、维护成本高	❌ 不推荐
纯单Agent多Tool	无路由错误、支持混合意图、代码极简	工具过多幻觉严重、闲聊易乱调用工具、推理开销大	⭐ 简单场景可用
域聚合Agent+多Tool	1. 同域混合意图完美支持 2. 路由极简、极少判错 3. 工具域隔离、幻觉低 4. 前置降噪杜绝上下文污染 5. 代码复用高、维护简单	极少数跨域场景需要单独适配	✅ 生产最优

五、落地核心结论（踩坑真心话）

1. AI Agent 架构，不是越复杂越高级，越拆分越稳定。过度精细化多Agent拆分，是中小对话系统BUG的最大来源。
2. 路由层只适合做大域粗分类，绝对不要做精细化意图切割，混合意图交给Agent内部多Tool消化。
3. 上下文污染的最优解，不是Session隔离、不是清空历史，而是域级Rerank动态降噪，兼顾记忆能力与纯净上下文。
4. 工具隔离的最优解，不是多Agent拆分，而是按业务域聚合工具，每个Agent工具数量可控，幻觉最低。
5. 闲聊不需要独立Agent，轻量化兜底、剥离工具能力，是性价比最高的稳定性方案。

六、最终架构流程（极简总结）

用户提问 → 粗粒度路由大域判断 → 前置Query改写+检索重排+历史降噪 → 进入对应域聚合Agent → 域内多Tool自主调度执行 → SSE流式输出应答

写在最后

很多教程、Demo 只会教你「如何做多Agent路由拆分」，但不会告诉你多Agent在真实对话场景的边界硬伤。

真正的生产落地，永远是取舍的艺术：

放弃极致拆分的理论优雅，换取真实场景的高稳定性、低BUG、易维护。

域聚合Agent + 域内多Tool + 前置重排序，是目前企业智能问答场景，兼顾代码简洁、用户体验、系统稳定性的最优落地架构。