一句话定位:大模型应用不是"调一次 API"就完事的产品,它是一种会随业务复杂度持续生长的架构形态。从单点调用到企业 AI 中台,每一阶段的拆分都不是为了好看,而是为了把上一阶段爆掉的某个属性——延迟、成本、上下文、权限、可观测——单独拎出来治理。FDE 在客户现场要做的事,就是判断客户当前在哪一阶段、什么时候必须升级、以及如何用最小代价迁过去,而不是一上来就卖一套中台。

一、为什么"架构演进"是 FDE 必须掌握的视角

在企业落地现场,FDE 最常踩的两个坑,本质都是"阶段错配":

• 阶段过早:客户才刚把一个内部知识问答跑通,FDE 就建议上 Agent 编排平台 + 多模型路由 + 评估中心,结果是三个月交付不了,运维接不动,项目黄。
• 阶段过晚:客户每天已经有 5 万次 LLM 调用分散在 8 个业务系统里,每个系统自己拼 Prompt、自己缓存、自己写降级,成本失控、口径不一、出问题没人能定位。FDE 还在帮它优化单条 Prompt。

架构演进视角的核心价值,是给 FDE 一把判断当前形态与下一站形态的尺子。这把尺子不是"越先进越好",而是"复杂度信号是否已经出现"。下面四阶段模型是这把尺子的刻度。

二、架构演进四阶段总览

业界对大模型应用架构的演进,大致可以收敛成四个阶段,它们不是严格的时间先后,而是复杂度阶梯:前一阶段是后一阶段的子集,后一阶段把前一阶段内部爆掉的某个维度抽出来单独成层。

阶段	核心抽象	典型组件	解决的主问题	爆掉的维度
一、单点 LLM 调用	函数调用	SDK + Prompt + 业务代码	把"生成能力"接进业务	上下文、成本、可观测
二、RAG 应用	检索增强	向量库 + Embedding + 重排 + Prompt 模板	把"私域知识"接进生成	多源知识、权限、评估
三、Agent 系统	工具编排	Planner + Tool 注册 + 记忆 + 循环	把"多步任务"交给模型自主完成	可控性、成本、监控
四、Agent 平台(企业 AI 中台)	能力分层	模型网关 + 知识中心 + Agent 平台 + 评估中心 + 可观测	把"模型能力"做成企业共享基建	组织协同、治理、演进

一个反复被验证的判断:FDE 在现场 80% 的"架构问题",不是技术选型错了,而是客户被放错了阶段。把 RAG 阶段的客户硬推上 Agent 平台,和把 Agent 平台阶段的客户按在单点调用上,都会让项目死得很体面。

三、阶段一:单点 LLM 调用

3.1 架构形态(文字架构图)

[业务代码] → [Prompt 模板(硬编码)] → [LLM SDK] → [模型 API] → [解析/后处理] → [业务结果]
                       ↑
                  少量 Few-shot 示例

整个系统里只有一处调用模型,没有向量库,没有工具,没有编排。Prompt 是字符串拼接,经常和业务逻辑写在一个函数里。

3.2 适用场景

• 内部工具的辅助生成:邮件润色、会议纪要摘要、SQL 草稿生成。
• 容错率高的非关键路径:推荐理由生成、商品标题改写。
• PoC / Demo:证明"模型能干这件事"。

3.3 痛点与演进信号

这一阶段的痛点几乎都是Prompt 散落和无评估:

• 同一个能力在三个系统里各写一份 Prompt,口径不一。
• 改一处 Prompt 不知道有没有把别处改坏,因为没有评估集。
• 模型一升级(Prompt 不再兼容新模型),全靠人工抽测。

升级信号:当你开始听到"我们要让模型回答基于公司文档"——这是阶段一的告别钟,下一步必然走向 RAG。当你听到"这三个系统的 Prompt 能不能统一管"——这不是 RAG 信号,是模型网关信号,属于阶段四的局部提前。

四、阶段二:RAG 应用

4.1 架构形态

[用户提问]
   ↓
[Query 改写 / HyDE] → [Embedding] → [向量检索 Top-K]
                                          ↓
                              [重排 Rerank] → [Top-N]
                                          ↓
                              [权限过滤 / 去重 / 截断]
                                          ↓
                          [Prompt 拼装(上下文 + 问题)]
                                          ↓
                                    [LLM 生成]
                                          ↓
                              [引用标注 / 后处理] → [答案]
   ↑
[离线管线:文档切分 → Embedding → 入库]

RAG 的本质是把"模型不知道的东西"在推理时实时塞进上下文。它把阶段一的"Prompt 是静态字符串"升级成"Prompt 是检索结果的动态拼装"。

4.2 适用场景

• 企业知识库问答、规章制度查询、产品手册助手。
• 代码库问答、合同条款抽取、客服知识检索。
• 任何"答案必须可溯源、不能瞎编"的场景。

4.3 痛点与演进信号

RAG 一旦上规模,会同时爆掉四个维度:

• 多源知识:文档来自 OA、Wiki、Confluence、共享盘,权限模型各不相同,直接混检会越权。
• 切分策略:不同文档类型(PDF 表格、Markdown、代码)需要不同 chunk 策略,一刀切召回率塌掉。
• 评估缺位:换了 Embedding 模型或 chunk 大小,不知道是变好了还是变差了。
• 多模态:图、表、扫描件纯文本检索拿不到。

升级信号一(向 Agent 走):用户的问题不再是一问一答,而是"帮我查这三个文档,对比一下,再生成一份报告"——单一检索 + 单次生成撑不住多步任务。

升级信号二(向中台走):第二个、第三个业务线都要做 RAG,但向量库、Embedding 服务、权限模型各搭一套——这时候该把"知识中心"抽出来共享。

五、阶段三:Agent 系统

5.1 架构形态

[用户目标]
   ↓
[Planner / 路由] ──┐
   ↓               │
[工具选择] → [调用工具 A] → [观察结果]
   ↓               ↑
[反思/再规划] ─────┘   (ReAct / Plan-Execute / 反思循环)
   ↓
[记忆:短期会话 + 长期向量记忆]
   ↓
[最终输出]

Agent 把"模型只生成文本"升级成"模型决定调用什么工具、看结果、再决定下一步"。核心新增组件是 Tool 注册表、Planner、记忆、循环控制。MCP(Model Context Protocol)在这一阶段成为工具接入的事实标准。

5.2 适用场景

• 多步任务:数据分析助手(查数 → 画图 → 写结论 → 发邮件)。
• 需要外部动作:工单处理、运维排障、跨系统操作。
• 开放式探索:研究助理、代码 Agent。

5.3 痛点与演进信号

Agent 系统的痛点集中在可控性、成本、可观测三件事:

• 循环失控:Agent 卡在工具调用循环里,token 烧穿,成本爆炸。
• 黑盒:一次回答调了 12 个工具,哪个工具出了错没人知道,因为没埋点。
• 工具散落:每个 Agent 自己定义工具,重复造轮子,口径不一。
• 评估极难:同一个任务跑两次结果不同,传统准确率指标失效。

升级信号:当公司里有 3 个以上团队都在造 Agent,每个 Agent 各自接工具、各自做监控、各自踩坑——这就到了该把"Agent 平台"抽成共享层的时候。注意:不是把所有 Agent 合并成一个超级 Agent,而是把注册、编排、监控、工具市场做成平台。

六、阶段四:Agent 平台(企业 AI 中台)

6.1 整体架构

到了这一阶段,模型能力不再属于某个业务系统,而是变成企业的共享基建。中台把前面三个阶段里反复出现的横切关注点(cross-cutting concerns)抽成独立层:

┌─────────────────────────────────────────────────────────────┐
│                      业务前台(多个业务线)                      │
│   客服助手 / 数据分析助手 / 法务助手 / 研发助手 / 运维助手 …      │
└────────────┬────────────────────────────────────────────────┘
             │ 统一接入
┌────────────▼────────────────────────────────────────────────┐
│                       企业 AI 中台                            │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────────┐   │
│  │ 模型网关  │  │ 知识中心  │  │ Agent 平台│  │  评估中心    │   │
│  │(路由降级 │  │(统一 RAG │  │(注册编排 │  │(评估集回归 │   │
│  │ 成本缓存)│  │ 权限图谱)│  │ MCP 市场)│  │ 指标看板)  │   │
│  └──────────┘  └──────────┘  └──────────┘  └──────────────┘   │
│  ┌────────────────────────────────────────────────────────┐  │
│  │              可观测与治理(统一日志/Trace/审计/配额)       │  │
│  └────────────────────────────────────────────────────────┘  │
└────────────────────────┬────────────────────────────────────┘
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
   [商用模型 API]    [自研/开源模型]    [私有化部署]

下面逐层展开。

七、模型网关

7.1 它解决什么

当公司里有 8 个系统都在调模型,每个系统自己处理"用哪个模型、怎么降级、怎么省钱、怎么缓存",必然出现:同一份 Prompt 在 A 系统用 GPT、在 B 系统用 Claude、口径不一致;某模型限流时 A 系统挂了 B 系统不知道;重复 Query 各自烧 token。模型网关把这些收敛成一个统一入口。

7.2 核心能力

• 多模型路由:按任务类型(分类/抽取/生成/代码)、按租户、按成本预算,把请求路由到不同模型。路由策略可以是规则,也可以是一个轻量分类模型。
• 降级与容灾:主模型超时/限流/内容审核失败,自动 fallback 到备模型;支持重试退避、熔断。
• 成本控制:按团队/项目/用户设 token 配额与预算告警;按调用计费回写到业务线。
• 语义缓存:对相同或语义相近的 Query 直接返回缓存结果,大幅压成本(客服场景缓存命中率常达 30%–50%)。
• 统一日志:每次调用的入参、出参、token、延迟、模型版本全留痕,供评估中心和可观测层消费。

7.3 代表实现

开源侧 LiteLLM 把 100+ 模型 API 统一成 OpenAI 协议,自带路由、重试、缓存、成本看板;OneAPI / New API 在国内生态里常被用作多渠道聚合与计费网关。自研团队则常在它们之上加一层公司内的路由规则与审计。FDE 落地建议:除非有强合规要求,不要从零写网关,直接基于 LiteLLM 二开,把精力放在路由策略和缓存策略上。

八、知识中心

8.1 它解决什么

每个业务线各建一套向量库,导致:同一份公司文档被 Embedding 了八遍,存储和入参成本翻倍;权限模型各写各的,A 部门的 Agent 能检索到 B 部门的机密;切分策略不一致,召回质量参差。知识中心把"知识的接入、切分、索引、检索、权限"做成共享服务。

8.2 核心能力

• 统一数据接入:对接 OA、Wiki、Confluence、SharePoint、共享盘、代码仓、工单系统,增量同步而非全量重灌。
• 多策略切分:按文档类型(结构化表、Markdown、代码、扫描件)路由到不同 chunker;支持父子分块、滑窗、按语义切分。
• 多索引共存:稠密向量(语义)+ 稀疏检索(BM25,关键词)+ 知识图谱(实体关系)三路混合检索,互为补充。
• 统一权限:文档级、段落级 ACL,检索时按调用方身份过滤,杜绝越权。这是知识中心最容易被低估、却最不能省的一块。
• 知识图谱融合:对实体密集型场景(供应链、组织架构、产品 BOM),图谱比纯向量更稳,可作为 RAG 的高置信补充源。

8.3 一个常见误区

很多团队把"知识中心"等同于"一个大向量库"。实际上向量库只是存储层,知识中心的价值在接入管线、切分策略、权限、混合检索、评估闭环这五件事上。存储选 Milvus / Qdrant / pgvector 哪个,远没有这五件事重要。

九、Agent 平台

9.1 它解决什么

Agent 系统阶段,每个团队自己搭 Planner、自己注册工具、自己写循环控制、自己埋点。结果是:工具重复定义(三个 Agent 各写一个"查订单"工具),口径不一;监控各自为政,出问题跨团队定位;新 Agent 从零造轮子。Agent 平台把这些抽成共享能力。

9.2 核心能力

• Agent 注册与发现:Agent 作为一等公民登记,带版本、负责人、SLA、依赖工具清单,业务前台像调服务一样调 Agent。
• 编排引擎:支持 ReAct、Plan-Execute、反思、多 Agent 协作等范式;支持人工介入节点(审批、确认)。
• 工具市场(MCP 工具市场):工具按 MCP 协议标准化注册,Agent 跨团队复用工具;工具带 schema、权限、用量统计、版本管理。
• 运行时监控:每个 Agent 的每一步工具调用、token 消耗、循环次数、失败率实时可见;支持按 trace 回放某次会话。
• 护栏与限流:最大循环数、单次预算上限、敏感操作二次确认、工具调用白名单。

MCP 的价值在平台层才真正兑现:单 Agent 时工具协议无关紧要,几十个 Agent 共存时,统一工具协议是工具市场能成立的前提。

十、评估中心

10.1 它解决什么

阶段一、二、三里,评估都是"局部"的:每个团队自己攒几条测试用例,自己跑,自己判分。结果是:模型一升级,谁也不知道全局是变好还是变差;Prompt 改一处,A 团队测了觉得没问题,B 团队的场景塌了没人知道。评估中心把"评估集、指标、回归"做成跨团队共享基建。

10.2 核心能力

• 统一评估集:按业务域组织的黄金集(golden set),覆盖常见、边界、对抗用例;版本化,变更走评审。
• 多维指标:任务准确率、引用忠实度(防幻觉)、工具调用正确率、延迟、成本、安全合规,分维度打分。
• 自动与人工结合:LLM-as-Judge 跑大规模回归,人工标注跑高价值样本与判官校准。
• 回归流水线:模型/Prompt/检索策略任一变更触发回归,出报告对比基线,红黄绿灯。
• A/B 与影子测试:新版本先影子跑(不影响用户),指标达标再灰度。

经验法则:没有评估中心的 Agent 平台,就是一辆没有仪表盘的车。客户愿意花钱建 Agent,却不愿意花钱建评估,是最典型的"看得见的功能看得见花钱、看不见的质量看不见花钱"错配。FDE 要在方案阶段就把评估中心写进预算。

十一、可观测与治理

横跨上述四层的是可观测与治理:统一 trace(一次用户请求贯穿网关 → 知识中心 → Agent → 工具的完整链路)、统一日志、统一审计(谁、何时、调了什么、返回了什么,合规留痕)、统一配额与成本归因。没有这一层,中台就只是"一堆组件堆在一起",出问题时无人能定位。

十二、架构演进的信号驱动

什么时候该从这一阶段升到下一阶段?FDE 在现场要盯四类信号,任何一类突破阈值,就该认真考虑升级:

信号维度	阶段一→二	阶段二→三	阶段三→四
性能/质量	模型答非所问,需要私域知识	一问一答撑不住多步任务	多团队各自优化,全局质量不可控
成本	单点烧 token,无缓存	RAG 重复 Embedding、重复检索	多系统各自调模型,成本无归因
需求复杂度	出现"基于公司文档回答"	出现"帮我对比、生成报告、执行操作"	出现"3+ 业务线都要 AI 能力"
组织规模	1 个团队	1–2 个团队	3+ 团队,跨业务线

关键判断:升级的触发器是"信号",不是"时间"。没有信号硬升级,是过度工程;信号已满不升级,是技术债。FDE 的工作是用数据把信号量化(调用次数、成本、故障率、团队数),让决策有依据而非拍脑袋。

十三、渐进式迁移策略

13.1 绞杀者模式(Strangler Fig)

不要"推倒重来"。新架构与旧架构并行运行,新功能走新架构,旧功能按调用频率/重要性逐步迁移到新架构,每迁一块就下线旧链路的一块。对大模型应用尤其重要,因为它容错率低、回归难,一次性切换风险极高。

13.2 灰度发布

模型/Prompt/检索策略变更,先影子跑(不返回给用户,只记指标),再小比例灰度,指标达标全量。Agent 类应用必须带"一键回滚到上一版本"开关。

13.3 双写与影子流量

知识中心迁移时,新旧两套索引双写,检索先打旧、影子打新,对比召回质量稳定后切流。模型网关迁移同理,新模型先接影子流量。

13.4 一个落地节奏建议

FDE 推动客户从阶段二升阶段四,典型节奏:先抽模型网关(投入小、收益立竿见影、不破坏现有应用),再抽知识中心(收益大但要碰权限,周期长),最后抽Agent 平台和评估中心(组织协同成本最高,放最后)。评估中心虽然放最后建,但评估集要从第一天就开始攒——它是所有迁移能否安全进行的尺子。

十四、反模式

14.1 一步到位上中台

客户还停留在阶段一,FDE 就规划了全套中台。结果是:中台建好了,前台用不起来(因为没有那么多业务线消费),维护成本压垮团队,两年后中台被废弃。中台是复杂度的产物,不是复杂度的解药——没有足够多的前台消费,中台就是负债。

14.2 过度抽象

在只有一个 Agent 的时候就抽象出"Agent 框架的框架",在只有两类文档时就抽象出"通用切分引擎"。抽象应该跟随第三个真实用例出现,而不是预判。过早抽象比没有抽象更难改,因为它会被多个调用方依赖。

14.3 评估缺位狂奔

所有阶段升级都不带评估集,靠"感觉"判断好坏。结果是每一次升级都是赌博,回滚也没基线可比。这是 FDE 现场最常见的隐性失败模式。

14.4 把中台当项目,不当产品

中台是持续演进的内部产品,需要产品经理、需要 roadmap、需要消费方满意度调研。把它当一次性项目交付,交付即衰退。

14.5 忽视权限与审计

知识中心和模型网关最常被砍的就是权限与审计("先跑起来再说")。一旦出数据泄露事件,整个 AI 项目在该公司会被冻结数年。权限不是中台的加分项,是底线。

本专题小结

大模型应用架构的演进,本质是把复杂度沿横切关注点逐层剥离的过程:单点调用把"生成"接进来,RAG 把"知识"接进来,Agent 把"行动"接进来,中台把"模型能力"做成共享基建。每一阶段的升级都不是技术先进性的比拼,而是复杂度信号是否已突破阈值的回应。FDE 在现场的核心价值,不在于能搭出多先进的架构,而在于能准确判断客户当前在哪一阶段、下一个该剥离的维度是什么、以及如何用绞杀者模式和灰度把迁移风险压到最低。最该避免的,是带着一套预设的中台蓝图去匹配所有客户——那是卖方案的视角,不是落地的视角。评估中心虽常被排在最后建设,但评估集必须从第一天就开始攒,它是所有架构决策能否被验证的唯一尺子。

本专题来源

• FDE 驻场交付实践沉淀(单点调用 → RAG → Agent → 中台四阶段客户演进观察)。
• 主流大模型应用架构公开资料:LangChain / LlamaIndex 的 RAG 与 Agent 范式,ReAct、Plan-Execute、反思等 Agent 编排模式。
• 模型网关开源实现:LiteLLM、OneAPI / New API 的路由/降级/缓存/计费能力。
• MCP(Model Context Protocol)在 Agent 工具市场与标准化工具接入中的实践。
• 企业知识中台、混合检索(稠密向量 + BM25 + 知识图谱)、文档级 ACL 权限模型的工程实践。
• 评估方法论:LLM-as-Judge、golden set 回归、影子流量与 A/B 的工程化用法。
• 绞杀者模式(Strangler Fig)、灰度发布等经典架构演进方法在大模型场景的本地化应用。
• 一线反模式归纳:一步到位上中台、过度抽象、评估缺位、权限与审计后置等现场踩坑。