做 AI 应用这一两年我最大的感受是很多人把 GPT-4o 这类大模型当成了应用本身反而忽略了它背后的工程架构。模型再强如果没有一层灵活的多 Provider 切换机制业务代码就会被厂商绑死没有 RAG 知识库模型就只能凭空想象读不到你的业务资料没有 Agent 编排AI 就永远停留在你问一句、它答一句的单轮问答做不了真正复杂的任务。这是系列文章的第四篇我结合自己这段时间在 AI 模块架构设计上的实操把多 Provider 切换、RAG 知识库、Agent 编排这三块核心内容拆开讲清楚——它们各自的原理、彼此的边界以及一个可落地的整体架构长什么样。如果你正在做一个中大型 AI 应用或者准备把个人项目往工程化方向演进这篇文章应该能给你不少能直接抄作业的东西。1. 先想清楚一件事AI 模块架构到底在解决什么问题很多团队的 AI 应用是从一个可用的 Demo开始的。Demo 阶段无所谓架构一个 Python 脚本、一个 API Key、几个 Prompt 模板就能跑起来。但当你要把它变成真正面向用户的系统时三个问题会接连蹦出来。1.1 模型依赖、知识隔离、任务复杂化三大痛点第一个是模型依赖。所有代码都直接调用 OpenAI 的 SDK意味着你被绑定在这家厂商的能力和定价体系上。厂商一涨价、一出限流、一故障你的服务就跟着遭殃。更现实的情况是不同任务适合不同模型——复杂的代码推理用 Claude日常问答用 DeepSeek长文档总结用本地部署的 Qwen价格差了十几倍。第二个是知识隔离。大模型的训练数据有截止日期而且它完全不知道你公司的内部规范、产品参数、历史项目文档。你问它我们的 DataX 接入服务支持哪些认证方式它只会一本正经地胡说八道。想让模型回答私有域问题就得给它一个外接知识库这就是 RAG 要解决的。第三个是任务复杂化。真实业务里没有多少单轮问答场景。用户说帮我把这几个接口的测试用例生成一下再按模板填到项目目录里模型需要先分析需求再决定调用什么工具然后逐步执行最后反馈结果。这就是 Agent 编排的范畴了。1.2 三者的分工边界别把架构做成大泥球用个不恰当的类比AI 应用就像一个公司。多 Provider 切换是招聘和管理多个大脑谁擅长什么就派谁上谁出故障就换谁。RAG 知识库是公司的资料库大脑不能凭空知道公司业务得给它配一个能随时检索的档案室。Agent 编排是项目管理流程把一个复杂目标拆解成多个步骤协调大脑、资料库和工具按顺序执行最后交付结果。这三件事边界很清楚Provider 管用哪个模型、RAG 管喂什么知识、Agent 管做什么任务。但如果设计不当它们会互相纠缠——比如 RAG 的结果直接塞进 Provider 的调用逻辑里或者 Agent 直接操作向量库的细节最后整个代码库变成一个大泥球改一处崩三处。我见过一个项目把知识库检索逻辑写死在某个 Provider 的适配器里换一家模型就导致检索代码不可用排查了半天才找到原因。所以架构设计的第一原则是三个模块之间只通过标准接口通信内部实现完全隔离。后面我会具体讲接口怎么设计。2. 多 Provider 切换别让业务代码绑死在某一家模型上2.1 Provider 抽象层统一接口是所有事情的地基多 Provider 切换首先要解决的是接口统一问题。OpenAI 的 SDK、Anthropic 的 SDK、本地 Ollama 的接口参数格式各不相同。但它们在抽象层面做的事都一样输入一个消息列表输出一个回复。所以我们要做的就是在它们之上加一层统一的 Provider 接口。我习惯用 Python 的抽象基类来定义这个接口from abc import ABC, abstractmethod from dataclasses import dataclass dataclass class ChatMessage: role: str # system | user | assistant content: str dataclass class ChatResponse: content: str model: str usage: dict class ChatProvider(ABC): 所有模型 Provider 必须实现的统一接口 abstractmethod async def chat( self, messages: list[ChatMessage], temperature: float 0.7, max_tokens: int 2048, ) - ChatResponse: ... abstractmethod async def embed(self, texts: list[str]) - list[list[float]]: 如果这个 Provider 还负责向量化就实现这个方法 ...为什么接口要设计成消息列表进、消息列表出因为这是所有大模型共用的最底层抽象。格式转换、重试、超时这些事全部在 Provider 内部消化业务层永远只跟ChatProvider打交道。以 OpenAI 兼容协议为例一个最简实现长这样class OpenAICompatibleProvider(ChatProvider): def __init__(self, base_url: str, api_key: str, model: str): from openai import AsyncOpenAI self.client AsyncOpenAI(base_urlbase_url, api_keyapi_key) self.model model async def chat(self, messages, temperature0.7, max_tokens2048): raw_messages [{role: m.role, content: m.content} for m in messages] resp await self.client.chat.completions.create( modelself.model, messagesraw_messages, temperaturetemperature, max_tokensmax_tokens, ) return ChatResponse( contentresp.choices[0].message.content, modelself.model, usage{ prompt_tokens: resp.usage.prompt_tokens, completion_tokens: resp.usage.completion_tokens, }, )DeepSeek、通义千问、Moonshot 这些厂商都提供 OpenAI 兼容接口所以写一个OpenAICompatibleProvider就能覆盖一大片。Anthropic 的接口格式不一样需要单独写一个AnthropicProvider但对外暴露的还是同一个chat()方法。这层抽象的价值在于业务层永远不知道你换了一家模型。2.2 配置管理与路由策略从配置文件到运行时分发Provider 的定义有了接下来是配置和路由。配置这块我强烈建议用配置文件 环境变量的组合不要把 API Key 硬编码进代码里。一个典型的配置文件TOML 格式长这样[providers.openai] type openai base_url https://api.openai.com/v1 api_key_env OPENAI_API_KEY models [gpt-4o, gpt-4o-mini] [providers.deepseek] type openai_compatible base_url https://api.deepseek.com/v1 api_key_env DEEPSEEK_API_KEY models [deepseek-chat, deepseek-reasoner] [providers.local] type openai_compatible base_url http://localhost:11434/v1 api_key_env NO_NEED models [qwen2.5:14b]这里的api_key_env指向环境变量名运行时从os.environ读取避免密钥泄漏。本地部署的模型不需要 Key可以给一个空占位。路由策略是很多人忽略的部分。真实场景里你不能永远只用一个 Provider得根据任务类型、成本预算、可用性动态分发。我常用的路由维度有三个按能力路由代码生成、复杂推理 → 顶级模型闲聊、格式化输出 → 便宜模型。按成本路由内部测试、批量任务 → DeepSeek 这类性价比高的模型线上高价值场景 → 更稳的厂商。按隐私路由涉及内部数据 → 本地部署模型公开信息 → 云厂商模型。路由管理器可以简单实现为一个带规则的转发层class Router: def __init__(self, providers: dict[str, ChatProvider]): self.providers providers async def chat(self, messages, route_by: str default, **kwargs): if route_by code and code_provider in self.providers: return await self.providers[code_provider].chat(messages, **kwargs) if route_by cheap and cheap_provider in self.providers: return await self.providers[cheap_provider].chat(messages, **kwargs) return await self.providers[default].chat(messages, **kwargs)别小看这个简单的路由层它升级成故障转移非常自然当默认 Provider 连续失败 N 次Router 自动把流量切到备用 Provider业务无感。我在生产环境里就是靠这个机制硬扛过一次上游服务商的大面积故障。2.3 降级、容灾与成本控制的实际经验多 Provider 不只是能切换还得切换得聪明。我给几个实践建议第一Provider 要有健康状态标记。每次调用失败时记错误次数超过阈值就临时摘除该 Provider一段时间后再放回重试。这能避免请求持续打到已故障的供应商上。第二区分软超时和硬超时。大模型接口响应不稳定有时慢不是故障只是排队。建议给单个请求设一个较长的硬超时比如 60 秒但业务层自己设一个更短的等待阈值比如 10 秒超过后先尝试其他 Provider而不是干等。第三做好成本可观测。每次 Provider 返回的usage字段记录了 token 消耗统一入库汇总这样月底算成本账时心里有数。很多团队直到收到天价账单才发现某个调用循环里把上下文无限叠加上去了。3. RAG 知识库让大模型真正读过你的业务资料多 Provider 解决的是大脑选择问题RAG 解决的是大脑知识问题。我先讲全链路再重点讲一个很多人问我的点——结构化表格数据怎么入库。3.1 RAG 全链路拆解从原始文档到可检索的向量完整的 RAG 流程可以拆成五个环节加载解析 → 清洗分块 → 向量化 → 存储索引 → 检索注入。加载解析PDF、Word、HTML、Markdown 各有各的解析库。建议统一抽象成DocumentLoader接口每种格式一个实现。PDF 用 PyMuPDFWord 用 python-docxHTML 用 BeautifulSoup。这一步的目标只有一个把原始文件转成纯文本。清洗分块这是影响检索质量最大的环节。原始文本里充满了噪音——页眉页脚、目录、水印、无关链接。清洗之后要分块分块策略直接决定向量检索的命中率。我常用的方法不是简单按固定 token 切而是先按段落边界粗分再把过短的段落合并到相邻块里每块控制在 500-800 token 之间def split_document(text: str, chunk_size: int 800, min_chunk: int 300) - list[str]: paragraphs text.split(\n\n) chunks, buffer [], for para in paragraphs: para_len len(para) if len(buffer) para_len chunk_size and buffer: chunks.append(buffer.strip()) buffer para elif len(buffer) para_len chunk_size: buffer \n\n para else: # 超长段落内部按句子切 for sent in para.replace(。, 。\n).splitlines(): if len(buffer) len(sent) chunk_size: chunks.append(buffer.strip()) buffer sent else: buffer sent if len(buffer) min_chunk: chunks.append(buffer.strip()) return chunks分块的两个经验一是保留语义完整性尽量别把一个段落从中间硬切二是块间留少量重叠避免跨块的上下文信息丢失。实际项目里我把重叠设为 100-150 token检索效果明显比完全无重叠好。向量化与存储分块完成后调用 Embedding 模型OpenAI 的 text-embedding-3-small或者本地的 BGE 系列把每块转成向量存入向量数据库。存储层可选择的范围很广从开源的 Chroma、Milvus、Qdrant到云厂商自带的向量检索服务。对中小项目我推荐 Chroma部署简单单机上就能跑得很好数据量上千万级再考虑分布式方案。检索与注入用户提问时把问题也转成向量在库里做余弦相似度检索取出 Top-K 块。这一步还有个进阶操作叫混合检索——向量检索捕获语义相近但关键词不同的结果BM25 关键词检索捕获词汇精确匹配的结果两者合并后再用重排序模型统一打分。混合检索对专业名词密集的领域特别管用因为它能轻微抑制向量模型的语义漂移问题不过这里的核心实际就一句话纯向量检索召回结果不够精确时试试混合检索。3.2 表格这类结构化数据到底该怎么进 RAG 知识库我看到有趣的案例有人问 系列产品表格怎么存入 RAG 知识库这几乎是每个做企业知识库的人都会遇到的实际问题。Excel、CSV、数据库导出的产品参数表如果直接按行拆开丢给模型效果惨不忍睹——因为每行数据脱离表头后完全失去上下文。我的处理方法是分表的大小选择不同策略小表格少于几十行的产品参数表整个表格转成 Markdown 格式作为一个 chunk 整体入库。这样检索时只要命中这个 chunk模型就能看到完整的表结构和全部数据回答准确率最高。大表几百上千行整表入库会让 chunk 太长检索容易漏。我的做法是把表头嵌入每一行每行转成一句自然语言描述。比如一个产品表有型号、内存、价格、发货地四列某行数据就转成型号为 Pro-256 的产品内存为 16GB价格为 6999 元发货地为上海。这样检索16GB 内存的 Pro 系列价格时这一行作为独立 chunk 就能被精确命中。超大的历史数据表先按业务维度把表拆成若干子表比如按产品线拆、按年份拆每个子表再按上面的两种方式处理。拆表的逻辑不是技术问题而是业务问题——找熟悉业务的人来定拆分维度比程序员自己拍脑袋可靠得多。另外除了向量检索结构化数据最好同时保留一份原始记录进数据库。RAG 返回的只是给模型看的上下文有时候用户需要的不只是自然语言回答还要精确的原始数值。设计一个检索结果附原始数据的接口能省掉很多二次查询的麻烦。3.3 检索质量调优召回、重排与参数选择RAG 上线后最常被问的是为什么检索出来的东西不相关。影响最大的几个参数按权重排序分块粒度 向量模型 Top-K 数量 重排策略。分块粒度前面说了。向量模型的选择上中文场景我用 BGE-large-zh 或者 embedding-3-small英文场景用 OpenAI 默认全套就能跑。Top-K 的取值需要平衡精度和上下文长度——K 太大注入的无关内容会干扰模型K 太小关键信息可能漏掉。我一般先在 K5 附近跑一轮看回答质量再调整。还有一个很实用的调优手段为不同的文档类型建不同的索引集合Collection。比如把产品文档、技术规范、FAQ 分别存放在不同的 Collection 里检索时根据用户问题的分类路由器决定查哪个甚至多个 Collection 各查一批再合并。这个做法比把所有内容塞进一个大池子更可控召回精度明显更高。4. Agent 编排从单次问答到多步骤任务4.1 Agent 的核心运行循环观察、思考、行动、观察如果说 RAG 是给模型增加了知识Agent 就是给模型增加了手和脚。目前业界主流 Agent 框架LangChain、LlamaIndex、自研框架底层的运行机制大多是 ReAct 模式的变体核心循环就四步推理Reason模型观察当前状态决定下一步该做什么。行动Act调用一个工具比如搜索知识库、执行代码、请求外部 API。观察Observe拿到工具执行结果加入上下文。重复直到模型判断任务已完成输出最终答案。一个最简实现可以写成这样async def run_agent(question: str, tools: ToolRegistry, provider: ChatProvider): messages [{role: user, content: question}] for step in range(10): resp await provider.chat( messagesmessages, toolstools.definitions(), # 把工具描述传给模型 temperature0.2, ) if resp.finish_reason tool_calls: messages.append(resp.assistant_message) for call in resp.tool_calls: tool_result await tools.execute(call.name, call.arguments) messages.append({role: tool, content: str(tool_result)}) else: return resp.content return 任务步骤过多已自动终止这个循环看起来简单真正的复杂度在工具层。很多团队 Agent 做不好不是模型不够聪明而是工具定义得太粗糙。4.2 Tool ProviderAgent 的手怎么设计Tool Provider 这个说法其实就是在强调一件事工具是 Agent 可以动态调用的外部能力集合需要有统一的注册、校验、执行机制。工具定义要注意三个细节第一工具描述要给模型看。模型决定调用哪个工具时完全依赖工具的名字和描述。你写get_weather(city)获取某个城市的天气就够了不要写一堆实现细节。描述词要偏向模型的语义理解宁可具体也不要抽象。第二入参要严格校验。Agent 生成的参数经常不完整或者格式不对。在工具执行前用 JSON Schema 校验参数失败的请求直接返回明确的错误信息给模型让模型基于错误信息自我修正而不是抛异常打断整个循环。第三工具要可观测。每次工具调用的入参、出参、耗时都要记日志。Agent 跑出错时95% 的情况是可以通过翻工具调用日志快速定位的——是工具返回了脏数据还是模型传错了参数一目了然。工具集设计上有个反直觉的经验别一开始就堆十几个工具。工具太多了模型反而更容易选错。先把最核心的三五个工具做精再逐步增加。每加一个工具都要跑一遍全部回归用例确认模型的工具选择率是上升的而不是被新工具带偏了。4.3 三种常用的编排模式顺序、循环、多 Agent 协作Agent 编排不是只有单个 Agent 反复调用工具这一种形态。我实际用下来三种模式覆盖了大多数业务场景顺序链模式任务有明确的处理顺序比如先检索知识库再生成回复最后写入日志。这种模式最简单可靠每个环节复用同一个 Provider 或不同的 Provider只要链路中每一步都对就行。循环反馈模式就是 4.1 里的 ReAct 循环适合任务流程不确定、需要模型自己根据中间结果逐步决策的场景。比如分析这份日志并给出优化建议模型可能需要先看日志、再查文档、再跑个脚本验证每一步依赖上一步的输出。多 Agent 协作模式当任务可以拆成多个子任务并行执行时用多个 Agent 分别负责不同部分最后汇总。典型例子是生成一份竞品分析报告可以拆成资料收集 Agent、数据分析 Agent、文案撰写 Agent三个各自调用不同的工具和模型最后汇总到一个整合的上下文里。多 Agent 不是银弹它带来的协调成本非常高。我的经验是任务能用一个 Agent 的循环解决就不要上多 Agent需要并行时让每个子 Agent 只负责一个非常明确的职责边界不要交叉重叠。有一次我把资料收集和文案撰写让两个 Agent 同时负责同一个内容源结果两边检索到的信息互相矛盾汇总时白白浪费了大量时间最后还得人工校准。4.4 会话记忆Agent 与 RAG 之间的短期工作记忆Agent 运行还有一个经常被忽视的组件——会话记忆。RAG 管的是长期知识文档库会话记忆管的是短期事实本次对话里已经确认的信息。多轮 Agent 任务里模型需要记住用户刚才说的偏好、前一步工具返回的关键值否则每轮对话就失忆重新回答一遍。我的做法是给会话单独建一个记忆缓存区每次 Agent 循环结束时把关键信息工具执行结果摘要、用户明确表示过的偏好写进去下一轮开始时注入系统提示词。注意不要无限叠加记忆超过一定量就做摘要压缩否则上下文长度会失控这在后面的踩坑部分还会遇到。5. 三者合流一套可落地的模块化架构参考5.1 模块间的数据流讲完三个模块很多人会困惑它们到底怎么拼在一起。我的架构设计里模块间调用关系是单向的用户请求 │ ▼ Agent 编排层负责整体任务拆解 │ ├── 调用 Router → 选择 Provider多 Provider 切换 │ │ │ ├── RAG 检索服务向量库 文档库 │ │ │ │ │ └── 检索结果注入上下文 │ │ │ └── Tool 执行层外部 API、代码执行等 │ └── 汇总结果 → 返回用户这个数据流有一个核心原则Agent 编排层是唯一的路由入口RAG 和 Tool 都是被调用的服务而不是主动拉取数据的组件。为什么因为只有这样你才能把 Agent 逻辑单独测试把 RAG 单独测试替换任意一块都不影响整体。具体到一次真实请求流程是这样的用户输入帮我查一下 Pro-256 的库存然后生成一份补货申请单发给采购。Agent 编排层识别到两个子任务查库存和生成补货单。查库存需要 RAG 知识库因为库存信息在业务文档或数据库里。编排层调用 RAG 检索服务得到库存数据注入上下文。编排层让模型判断下一步生成补货单需要调用表单工具。Tool 执行层生成补货单调用发送接口。汇总所有步骤结果给用户一个完整回复。这条链路里每个环节都可能用到不同的 Provider——查库存用便宜的模型就够了生成补货单语义要求高切到更强的模型。这就是模块化架构的意义。5.2 最小主流程示例我这里给一个缩减过的主流程伪代码逻辑上完整细节边界可以按需扩展class AIApplication: def __init__(self, router, retriever, tools): self.router router self.retriever retriever self.tools tools self.agent AgentRunner(providerself.router, toolsself.tools) async def handle(self, user_input: str) - str: # 1. 尝试先用 Agent 编排处理支持工具调用 agent_response await self.agent.run(user_input) if not agent_response.needs_knowledge: return agent_response.content # 2. 需要外部知识时走 RAG 检索 docs await self.retriever.search(user_input, top_k5) context \n\n.join(doc.content for doc in docs) # 3. 带知识上下文重新调用模型 final_messages [ {role: system, content: 基于以下资料回答问题 context}, {role: user, content: user_input}, ] final await self.router.chat(final_messages) return final.content这个主流程的简陋并不是缺点——它把三个模块的职责边界划定得非常清楚AgentRunner管任务拆解和工具调用Retriever管知识检索Router管模型选择。每一块都可以拿出来单独优化和测试。6. 上线后我踩过的坑配置、超时与请求过大架构设计得再好落地时也免不了踩坑。这一章我把这段时间实际遇到的几个典型问题完整还原出来包括排查链路和最终解法希望能帮你少走几个弯路。6.1 base_url 缺失这类配置错误的根因有朋友向我求助日志里反复出现类似这样的错误配置错误: provider 缺少 base_url 配置还有一个config.toml: model provider openai not found的错误。报错各不相同根因都是同一个配置文件里的 Provider 注册信息不完整或者引用名对不上。先说 base_url 缺失。用 OpenAI 兼容协议时SDK 必须知道 API 服务的地址才能拼请求。如果配置里只写了模型名和 API Key没写base_url请求就发不出去。这个错误的典型出现时机是把某一家模型商的配置从别处拷贝过来但忘了改base_url或者是配置管理工具自动生成配置时漏填了这个字段。再说model provider openai not found。配置文件里注册的名字是default但代码里路由层引用的是openai键名不一致就会报 provider not found。这个排查起来更隐蔽因为框架启动时不一定检查所有引用通常要到某个请求真正被路由到错误键名时才暴露。解法启动时做配置校验扫描所有路由规则里引用的 Provider检查是否存在、配置是否完整base_url、api_key_env 是否都能解析到实际值校验失败直接报错退出别等运行时再炸。另外把 Provider 的注册名当成一种公共契约在配置文件和路由代码之间建立一个共享常量避免手写字符串不一致。6.2 API Key 管理失控的教训另一个高频错误是no api key for provider route deepseek-official这类。现象是代码本地跑得好好的部署到服务器后就开始报缺 Key。原因十有八九是环境变量没有正确传递——你设置了.env文件但没被加载或者 CI/CD 平台的环境变量配置漏了这一项。还有一次遇到missing session id (400)的错误排查后发现是某条请求链路里会话状态没有正确传递网关拒绝了请求。这个和 API Key 无关但暴露了同一个问题请求的元数据鉴权信息、会话 ID要在同一套机制里管理不能这里手动传一截、那里靠默认值。我的解法统一做一个CredentialManager在进程启动时从环境变量或密钥管理服务加载所有 Provider 的 Key集中持有Provider 实例化时从CredentialManager获取禁止 Provider 内部自己读环境变量。这样排查时只需要查一个地方而不是在十几个文件里搜os.getenv。还有一个免费额度相关的提醒部分服务商的免费套餐对使用环境有明确限制比如限制调用来源、限制频率。我碰到过一次free tier can only be used from ...的报错最后发现是触发了配额限制规则。这种限制通常写着configuration error或policy violation的字样容易被误判成配置错误。处理方式是先查服务商文档里关于免费套餐的调用条件说明确认当前的调用环境是否满足不要盲目重试。6.3 Agent 执行超时排查链路完整还原报错信息是the agent execution provider did not respond in time. this may indicate the model is overloaded or the request is too complex。第一次遇到这个问题时我的第一反应是模型厂商出故障了但在管理后台看了看服务指标正常。后来我把整个链路拆开计时才发现问题出在 Agent 循环里我为了让模型能准确调用工具把工具定义写得很长又把前几轮的工具调用结果全部保留在上下文中。本来一步能完成的推理模型需要生成很长的响应单次请求耗时飙到 60 秒以上超过了框架的硬超时阈值。排查链路先确认是模型调用慢还是工具执行慢——日志里给每个环节标时间戳很快就能定界。然后看上下文是不是过大——把请求的 token 数打印出来通常能发现上下文已经堆到几万 token。最后看是不是并发问题——如果所有请求都同步等待模型响应线程池被占满是必然结果。解法一是缩短单次 Agent 循环的上下文把多余的工具调用历史压缩成摘要而不是原样保留二是给模型调用和工具执行分别设置独立的超时时间模型慢就换 Provider 重试工具慢就检查工具本身三是把 Agent 循环改成支持并发——多个独立工具调用可以并行发出而不是串行等待。6.4 413 payload too large上下文失控的典型症状这个错误的完整信息大致是unexpected status 413 payload too large: upstream provider rejected the request because the payload is too large。HTTP 413 的意思是请求体超过服务器允许的上限。这类错误在我用 RAG Agent 组合时出现得最多。原因几乎都是一个RAG 注入的 chunk 太多 Agent 历史太久导致请求 payload 超出上游限制。有段时间我把 Top-K 从 5 调到了 20觉得反正向量库检索那么快多给点上下文总没错结果请求体瞬间涨到几十 MB直接触发 413。解法在上游限制之外自己给 payload 设一个更保守的上限比如 30000 token约 60 MB 的字符串取决于编码不过一般建议按 token 而不是字节来管。超过上限时丢弃最旧的上下文或者降低 RAG 的 Top-K再发起请求。另外给 RAG 注入的上下文加一个摘要层——把多个相似 chunk 合并成一个摘要而不是全部塞进上下文。这个优化在保证回答质量的同时能把请求体积降一个数量级。6.5 其他零散但重要的提醒在收尾之前再分享几个零散的实践心得。第一测试要覆盖 Provider 不可用 场景。很多团队的测试只覆盖正常调用一旦 Provider 返回 500、限流、超时代码就原形毕露。建议在测试环境里用 mock Provider 模拟各种故障把降级路径跑通。第二RAG 不只有向量检索一种形态。对高频的精确匹配问题查价格、查日期、查状态直接查数据库往往比向量检索更准更快。设计一个先查结构化数据、查不到再走向量检索的混合检索链路效果比纯 RAG 好得多。第三Agent 的每一步都要可解释。给 Agent 的每一次工具调用加上可读的日志和轨迹记录trace方便用户或开发者事后查看为什么 AI 做出了这个返回。这在很多合规场景里不是可选项而是必须项。我自己每次 Agent 跑出诡异结果都是靠翻 tool call 轨迹快速定位的。这篇架构梳理到这里所有核心模块都过了一遍。最后分享一个我自己的小习惯在实践里我会给每个模块留后门。多 Provider 切换时留一个手动强制指定 Provider的开关RAG 检索时留一个直接查看检索到哪些文档的调试接口Agent 编排最后保留一个人工介入修正的入口。这不算多高深的设计但确实让它在多次疑难问题排查中省了大量精力。对这个架构如果你正在做类似的事情建议从最小闭环开始先接两个 Provider加一个简单的 RAG 检索再让 Agent 调一个工具逐步把链路跑通再谈优化。不要一开始就追求多 Provider 自动路由 混合检索 多 Agent 协作的大而全那只会让问题排查变成一场灾难。