AI应用架构设计实战：五层拆解Agent、RAG与可观测性

最近这半年，我前前后后帮不少团队做过AI应用架构设计的评审。有个现象挺有意思：同样是做AI应用，有的团队聊起来头头是道，一落地就四处失控；有的团队技术栈看着朴素，却总能在Demo阶段之后继续稳定迭代。差别往往不是谁的模型调得更好，而是谁在动手写代码之前，先把系统的边界、流向、依赖关系在图纸上过了一遍。这里的“图解”不是画PPT，而是一种工程化思考方式。这篇内容我打算从自己实操和排错经验出发，把AI应用架构设计拆成交互层、Agent编排层、模型访问层、数据层和可观测性五块来聊，每块都会给出画架构图时的要点，也覆盖AI Agent、多智能体协作、提示词管理、AI测试这些大家常搜的热点问题。

1. 一张好的AI应用架构图，画的不只是模块，更是边界和数据流

1.1 为什么画图比写代码更早暴露问题

做架构设计评审时，很多团队一上来就打开IDE，说“我已经把界面差不多写好了，就是模型调用一直不稳定”。这时候如果让他们花十分钟把整个系统画出来，大概率会发现：他们既没有独立的模型网关，也没有储备降级方案，对话历史全部塞在前端内存里，换个设备用户就失忆，而“RAG知识库”实际上只是一堆没切分的PDF。这些问题其实在写代码之前就已经决定了，只是代码写完后更难发现。画架构图这件事，本质上是在做一个低成本的“结构预演”。

架构图之所以有效，是因为它强迫你把系统的输入、输出、状态、外部依赖一件件摆到桌面上，逼你去回答“信息到底从哪里来，又要到哪里去”这类基础问题。在AI应用架构设计中，这一点尤为关键，因为大模型的可变性让每一个环节都可能是薄弱点，如果你连这些薄弱点在哪里都不知道，后面的调试就是大海捞针。

画图不意味着要把每个组件都用统一建模语言的标准画得很严格。对我而言，一个白板、一张Excel表格甚至一行缩进文本都行。关键是图要能表达“边界和流向”，而不只是“盒子和线条”。很多团队画的图看起来非常完整，但实际上只是一张静态的代码关系图，完全看不出来一次用户请求会在哪个环节耗时最多，哪条链路的失败率最高。画图的时候与其问“系统里有哪些模块”，不如多问几个“如果……会怎么样”。比如“如果向量库查询返回空结果，模型拿到的是什么提示词”“如果第三方模型接口超时，用户的请求是不是就直接失败”。这些问题一旦写出来，架构的薄弱点就无处可藏。

1.2 架构图的四件套：交互、编排、模型访问、数据底座

我习惯把AI应用的手绘草图分成四层：交互层、Agent编排层、模型访问层、数据与记忆层。这是一个经验性的分层框架，不是官方标准，但用来做AI应用架构设计会非常顺手。为什么这么分？因为每一层回答的问题都不同：

如果你把四层全部堆到一张图上，非常容易爆掉。所以画图时我一般先用一张粗粒度的大图确定全局，再为每一层单独画一张细一点的图。比如你有“AI绘画”类的应用，交互层除了聊天框还有图片生成的参数表单，模型访问层可能同时接入文生图模型和对话模型，两者的延迟、成本、失败模式都不一样，必须分开画清楚。再比如你是一个“AI编程助手”类应用，交互层要处理的是编辑器插件和WebIDE，编排层里可能包含代码分析、文件读写、命令行执行等工具，模型访问层要考虑代码上下文的长度限制和敏感信息脱敏。四件套看着简单，却能覆盖绝大多数AI应用的架构表达。

1.3 画图前必须回答的三个问题

开画之前，我会先逼团队回答三个问题，这三个问题不搞清楚，画出来的图再好看都会在执行时走样。

第一个问题：用户的输入到底从哪里进来？是网页、App、微信群、飞书机器人还是IDE插件？这些入口决定了并发模型和协议适配的方式。第二个问题：模型调用是核心链路还是可降级链路？如果模型不可用，系统是变成只读模式，还是用更小的模型顶上，还是直接报错？第三个问题：数据与知识的边界在哪里？哪些数据能进入上下文，哪些只能存在企业数据库里做权限控制，哪些是会话级状态，哪些要写进长期记忆？

这三个问题在架构图上通常表现为几个关键箭头和多出来的中间方块。每画一个箭头，都应该能说清它承载的是什么格式、多大体积、多高的频率。我见过很多失败的AI应用，最大的问题不是模型不行，而是箭头不清：用户数据被当成公开知识直接发给模型，业务状态散落在各种全局变量里，知识库的更新没有人负责。这些问题的种子，早在第一版架构图里就埋下了。

2. 交互层：聊天框、工作台和多模态入口的取舍

2.1 对话不仅是前端组件，更是一种后端协议

很多入门者把聊天应用理解为“一个输入框 + 一个接口”。如果你只做原型，这么理解没有问题；一旦要考虑用户体验和工程稳定性，就会发现对话背后需要一套有状态的协议。

一轮对话要发给模型的并不只有用户当前输入，还有历史消息、系统提示词、工具执行结果，这些内容加起来可能几千甚至几万个token。多轮对话本身就是一场“流式数据交换”：用户输入进去，模型流式吐字，工具调用结果回填，再吐字，再回填。如果把这套逻辑全部压在前端组件里，刷新页面就丢上下文，而且不同业务方之间很难复用。

我在架构上会把交互层拆成三个要素：会话标识、消息协议、流式通道。会话标识解决“同一个用户的多轮请求如何关联”；消息协议定义“系统提示词、用户消息、工具结果、评分结果用什么结构传递”；流式通道解决“长耗时任务怎么把进度推给前端”。在技术选型上，你可以用WebSocket、SSE或者WebRTC的数据通道，但我自己的经验是，除非有很强的双向交互需求，否则优先用SSE或HTTP流式返回，实现简单，容错也更容易。

2.2 从单轮聊天到多模态工作台

现在的AI应用早就不是纯对话框。AI绘画、AI视频、AI短剧、AI语音对话，甚至AI辅助专利识别的系统，都会带有文件上传、参数调节、素材管理这类非对话模块。交互层一旦变成“工作台”，架构图就要多出几类模块：素材上传与预处理、任务进度管理、结果展示与再编辑。

以AI绘画为例，用户的参数可能要经过一个“提示词增强”接口，再交给文生图模型，图片生成过程往往要十几秒甚至几分钟。这时候如果前端一直等待HTTP返回，所有用户都会被连接数拖垮。正确做法是后端先生成一个“任务ID”，把图片生成请求推进异步队列，前端通过轮询或SSE拿到进度。这个看似很小的改动，会让架构图里多出一个“任务队列”组件，而这一层恰恰是普通CRUD架构中没有的东西。

多模态的另一个问题是输入与输出的不对称。文本可以流式输出，图片只能整张返回，视频只能分段生成后拼接，音频可能要边生成边播放。画图时如果不对这些差异做清楚标注，开发阶段就会反复遇到“按文本接口设计、被图片返回卡死”的问题。

2.3 用户并发与应用服务怎么扛

“AI Agent怎么扛并发”是个关注度很高的问题，很多团队一开始把并发当成“后端加机器”就能解决，但在AI应用里没那么简单。普通Web请求通常在几百毫秒内就结束了，Agent任务可能要执行几十秒甚至几分钟，期间要调用大模型、工具、数据库、第三方接口，任何一个环节卡住，整个任务都会卡住。

如果你们的Agent应用有500个用户同时触发任务，你的服务并不是同时发起500次模型调用那么简单，还要考虑任务队列堆积、外部工具的限流、模型供应商的配额。我的建议是在交互层和Agent编排层之间明确画出“任务队列”这个组件，把所有同步请求转成异步任务。

这样做有三个好处：第一，用户可以立刻拿到任务ID，前端有了稳定的进度锚点；第二，队列能自然削峰，不会因为瞬间流量直接打爆底层模型API；第三，任务失败时还可以有重试策略，而不是让用户盯着“请求超时”白屏。并发还要考虑“胶水层”的线程模型，是单消费者模式、多消费者模式还是每个Agent独占一个执行环境，这些都会直接影响你的峰值吞吐量。架构图阶段把队列、消费者数量、超时机制写在图上，上线后踩并发坑的概率会小很多。

3. Agent编排层：任务拆解、工具调用和多智能体协作的关键

3.1 什么场景才需要引入AI Agent

很多团队一听到AI Agent就觉得应该让大模型全权接管所有业务流程，这是一个很大的误区。Agent本质上是“大模型 + 任务循环 + 外部工具”的组合，适合的是那些无法用固定规则穷举、需要动态判断的多步骤任务。

比如“帮用户把一份合同摘要成表格并写入系统”，这个任务需要读取文件、抽取字段、校验逻辑、写入数据库，中间步骤会随着输入不同而变化，用固定代码写虽然能写，但是非常死板，用Agent动态编排反而合适。但如果你要做的是一个“根据用户所属地区返回对应提示语的界面”，这种流程简单稳定，用代码写死比Agent更可靠。

在AI应用架构设计里，我的原则是“确定性逻辑用代码，不确定性判断用模型”。把这一条写在架构图的右上角，能避免团队把整个系统变成一个巨大的黑盒。引入Agent以后，架构图里要增加两个环节：任务规划器和执行循环。任务规划器负责把大目标拆解成子任务，执行循环负责按照计划调用工具、读取结果、判断下一步。这两个环节必须显式建模，否则Agent的执行过程就变成了一个无法维护的递归调用。

3.2 工具调用怎么进入架构：函数声明、权限与超时

工具调用是Agent架构里最危险也最容易遗漏的部分。我先说结论：每一个工具都要在架构图里标清楚三样东西，函数声明、权限边界、超时与重试策略。

函数声明让模型知道有哪些工具可用、每个工具的参数是什么。这个看似简单，实际上经常因为参数类型描述不清导致模型反复生成错误JSON。以下是一个简化的工具声明示例：

{ "name": "create_ticket", "description": "创建一条新的工单记录", "parameters": { "type": "object", "properties": { "title": { "type": "string", "description": "工单标题" }, "priority": { "type": "string", "enum": ["low", "medium", "high"] } }, "required": ["title"] } }

权限边界是最容易出事的：如果Agent能自由调用“发送邮件”“修改订单”“删除文件”这类工具，一个上下文理解偏差就可能造成不可逆后果。所以在架构图中，工具层一定要放一个“权限校验器”或者“审批流”，关键操作必须有二次确认。超时与重试策略也很关键，模型驱动的工具调用和代码驱动的调用不一样，模型经常会在一次错误的上下文中反复调用同一个工具，如果不加次数限制和熔断机制，你的第三方服务会被自己打爆，账单也会失控。我的实操建议是，在工具层统一封装一层“工具网关”，每个工具接入时配置好schema、权限标签、超时时间、最大调用次数、审计日志，这层做得越扎实，Agent越不会给你惹祸。

3.3 多智能体协作的模式与并发控制

多AI协作现在是热门方向，很多团队都在关注“多AI协作”“多个Agent一起工作”。先说架构上的分法：一种是“编排者-执行者”模式，主Agent负责拆解任务，多个子Agent分别执行，结果汇总回主Agent；另一种是“协商式”模式，多个独立Agent通过消息机制互相传递结果，共同决定最后输出。

前者适合相对有等级关系的任务，比如写一份市场调研报告，可以由主Agent拆分出信息搜集Agent、数据分析Agent、文案Agent；后者适合需要不同视角碰撞的任务，比如多角色会诊讨论一个产品方案。画图时，无论哪种模式，都要把“共享上下文”单独画出来。多个Agent如果各自维护一套私有记忆，协作就变成鸡同鸭讲；如果全部共享一个上下文，又会产生巨大的token开销。

折中的做法是设计一个“共享黑板”结构：任务目标、中间结论、最终结果放在公共存储里，每个Agent自己的中间推理放在私有上下文里，需要协作时才把关键结果写入黑板。并发控制要额外小心，多个Agent同时操作一个外部系统时，如果没有锁或事务隔离，会出现重复写入、覆盖结果等问题。架构图上可以加一个“协作消息队列”，让Agent之间用消息而非直接调用彼此的方法，这样解耦性好，出错也好排查。

4. 模型访问与提示词工程：网关、上下文预算和降级策略

4.1 统一模型网关：多供应商接入与fallback

第四层是模型访问层。很多人以为这层就是“调用模型接口”，最多加个缓存，其实远不止。一个成熟AI应用的模型访问层，应该是一层“统一模型网关”，对内屏蔽模型差异，对外统一计费和监控。

为什么要做这一层？因为模型供应商的稳定性、价格、能力经常变化，如果你的业务代码里到处直接调用模型API，一旦上游接口升级或者某个模型因为负载拒绝服务，系统就要跟着改。模型网关的核心功能有三个：路由、降级、限流。

路由可以按价格、延迟、质量策略把请求分到不同模型：简单对话可以走速度快的小模型，复杂推理可以路由到大模型；如果主模型返回异常，可以降级到备用模型或缓存结果。限流不只是做“每秒请求数”的限制，还要做token级的消耗限制，防止某个用户的一次超长输入把整月的模型预算烧完。画架构图时，我会把模型网关放在Agent编排层和数据层的中间，并在图上标注“模型A是主力，模型B是降级备胎，模型C用于低成本任务”这类注释，这样运维和后续开发一目了然。

4.2 提示词结构设计：系统、上下文、示例和工具的token开销

提示词工程是AI应用架构设计里最容易被低估的模块。提示词不只是写给模型看的文字，更是一套有结构的配置数据，要跟代码一样考虑版本和回归。我建议一个标准提示词模板至少包含五段：角色与系统说明、动态上下文、少量示例、工具函数描述、输出格式约束。

这五段不是随便拼接的，它们各自消耗不同量的token，也各自有不同的稳定性风险。系统提示词如果经常改，大模型的行为就经常变，这会造成很严重的回归问题；动态上下文往往占据最大token开销，动不动就好几千token；示例太多会压缩上下文空间，太少又稳定不住输出格式；工具函数描述过大会拖慢生成速度，过小又会导致模型遗漏可选参数。

架构上建议把提示词模板做成一等公民，放在单独的配置中心或者代码仓库里，带上版本号，每次修改走diff和评审。真正有工程素养的团队，会把提示词当成代码来管理，而不是当成“跟模型对话的口水话”。这样后期做AI测试和回归时才有的放矢。

4.3 上下文窗口管理：截断、压缩、摘要与检索

模型上下文窗口是固定有限的，而业务数据可能无限增长，上下文窗口管理因此成了模型访问层的核心难点。常见的做法有三类：截断、摘要、检索。截断最简单，直接扔掉最旧的消息，但会让模型失去早期上下文，用户问“我刚才说过什么”时只能崩掉。摘要叫做“滚雪球摘要”，每次对话结束后把前面内容总结成一小段塞进上下文，能保留主线但会丢失细节。检索则把知识放到模型之外，通过向量检索把最相关的片段拉进上下文。

我在实际项目里不是只用一种，而是组合：最近几轮对话原样保留，更早的内容做摘要，领域知识走RAG检索。操作层面有两个细节要特别注意。第一，要给上下文窗口留缓冲，不要把token塞到刚好顶格，因为工具返回和流式输出都可能额外占token，到顶之后就报错。第二，要区分“模型上下文”和“系统上下文”，前者是真正发到模型的内容，后者是整个会话期间积累但不需要每次都发送的数据，比如用户历史偏好或埋点事件。把这点想明白，你会发现有些数据根本不需要进入模型上下文，直接查询业务库反而更准确。

5. 数据与记忆：RAG流程、向量库和权限隔离

5.1 RAG不是一个库，而是一条垂直流水线

现在聊RAG的团队很多，但很多人对RAG的理解停留在“把PDF丢给向量库，再查出来拼给模型”。这个理解害了不少项目。RAG的完整链路其实是一条很长的管线：文档清洗、分割分块、嵌入向量、索引存储是离线一半；查询改写、向量检索、重排序、拼装上下文是在线一半。每一环都直接影响最终回答质量。

我做架构评审时，会先让团队把这条流水线画出来，然后逐一点名每个环节。文档清洗容易被忽略，但PDF目录、页眉页脚、表格和扫描件的处理不当，后面所有环节都会收到垃圾输入。分块策略要结合文档结构来定，一般块大小在256到512个token带部分重叠，同时保留标题层级信息作为元数据。离线索引和在线检索最好用同一个库，但嵌入模型版本一旦更新，索引必须重建。

在线检索端不要只做“top-k向量”，建议加一个重排序模型，把向量相似度粗排后的结果再做一次精细排序，这对回答质量的提升往往比换一个大模型更明显。在架构图上，这条流水线要画得足够细，因为它涉及离线任务调度、在线检索服务和上下文拼装三个子系统，每一个都可能成为性能瓶颈。

5.2 短期记忆与长期记忆：会话状态、向量库与业务库

对话系统的记忆分为临时记忆和长期记忆，架构上一定要分层。临时记忆一般放在Redis或内存里，数据结构是session_id到消息列表的映射，过期时间通常设为几十分钟，超时后可以自动清除。

长期记忆需要持久化，一种是用向量库存“用户说过的事实”，例如“用户喜欢喝美式咖啡”“家里有一只猫”，每次对话前通过向量检索把相关事实拉进上下文；另一种是用结构化数据库存“用户与系统的业务关系”，例如“上次订单信息”“当前订阅状态”，这类数据更适合用SQL查询而不是向量相似度。

画架构图的时候，我习惯在数据层画出两条明显的路径：一条是“知识路径”，负责从知识库检索领域信息；一条是“状态路径”，负责读写用户与业务的状态。很多AI应用乱就乱在这里：把知识、记忆、业务状态全部看成同一种数据，堆在一个向量库里，结果既不快也不准。

5.3 数据安全与权限隔离：架构里最容易遗漏的一环

数据安全在AI应用架构中经常被当成“上线时再补”的环节，这是很危险的。最典型的问题有两个：一个是RAG知识库的越权检索。比如企业知识库里同时存放了不同部门的不同权限文档，如果你的检索不按用户角色过滤，任何用户都能问出别的部门的内部信息。另一个是用户私有数据被混进模型上下文，用户上传了一份文档，你把它切块放进了共享知识库，下一个用户就可能通过提示注入把它问出来。

这两类问题在普通系统中已经足够严重，在AI应用里因为模型会在生成时重组信息，风险会被进一步放大。架构图上一定要体现几类安全组件：权限过滤器，在检索前按用户角色过滤文档；数据脱敏组件，在模型输入输出层做敏感信息替换；内容安全审核组件，对生成结果做合规审查和风险过滤。这些组件看起来增加链路，实际的业务价值是：既保证用户数据隔离，又保证生成内容合规可控。尤其是当你把AI应用接入生产环境后，这个位置的缺失会让合规和运维团队非常难受。

6. 测试、可观测性与迭代：让架构图跟着产品一起变老

6.1 AI测试不是只测接口，还要测效果和质量

说到AI测试，很多人第一反应是单元测试和接口测试，这些当然要做，但对AI应用远远不够。因为大模型的非确定性导致同一个提示词每次输出都有细微差别，你可能要验证的不是调用成功，而是效果稳定。

我的做法是搞一个“效果回归集”，也叫黄金数据集：每一类典型场景收集几十条输入，标注出期望的行为和评价维度，每次修改提示词、更换模型或调整RAG链路时，跑一遍回归集，用规则判断加模型打分评估结果。规则判断适合强约束场景，比如“输出必须包含JSON字段”“不能提到竞品”；模型打分适合开放场景，比如“回答是否切题”“摘要是否跑偏”。

测试还要覆盖工具调用异常、模型超时、上下文溢出这些工程边界。架构图上记得给测试留一个位置，通常是在提示词配置管理、RAG配置管理和模型网关旁边加一条“回归测试触发”的虚线，表示任何配置变更都应该自动触发评估流程。没有这个机制，每次改完提示词都是一次赌博。

6.2 可观测性：链路追踪、成本计量和Token消耗

AI应用的可观测性比传统应用更复杂。一次用户请求可能经历“前端交互、Agent编排、多次模型调用、多次工具调用、RAG检索”这么长的链路，而且每一段都可能拖几秒甚至几十秒。如果没有链路追踪，生产环境里用户抱怨“很慢”时，你会完全无从下手。

可观测性至少要覆盖三类指标：链路追踪、成本计量、质量信号。链路追踪记录每一次请求经过了哪些Agent、调了哪个模型、花了多长时间、哪个工具调用失败；成本计量要统计每个用户、每个功能模块、每个会话的token消耗和金额，不然月底账单会吓死人；质量信号包括用户反馈点踩、拒答率、超时率、上下文截断次数，这些能帮你判断架构到底哪里最脆弱。

画架构图时，我会在图的底部加一条“可观测性横条”，示意所有组件都要上报事件到统一采集端。如果早期不设计这条横条，后期再插桩会非常痛苦，因为每个内部模块都缺少trace ID的透传逻辑。等你想看清楚每个Agent节点到底干了什么，就得把所有内部服务重构一遍。

6.3 从Demo到生产，架构图至少要改三轮

最后说迭代。AI应用的架构图不是画一次就完事，通常至少要跟着产品演进三轮。

第一轮是从想法到可演示原型，这个阶段架构图可以非常简陋，核心是验证模型能力和交互方式。Demo谁都能做，但你要知道哪些决定是为了演示牺牲掉的。第二轮是从原型到内测，这个阶段要补上模型网关、异步任务队列、会话存储和基本权限隔离，把当初“图上没画”的组件补回来。第三轮是从窄范围公测到大规模运营，这个阶段要加可观测性、效果回归、成本优化和更细粒度的安全策略，架构图会变得复杂很多，但每一根线条都必须有真实流量支撑。

如果团队在第一轮就拒绝了后面几轮的规划，等到上线前夕再去补，面临的就不是开发成本问题，而是线上事故风险。所以我的建议很直接：第一版架构图可以丑，但一定要把边界和流向留出来。

最后补充一条个人经验：没有哪张架构图是能画完不变的，重要的是你怎么对待这一次演变。我现在要求团队每次架构评审都要带上最新的图，哪怕只是用表格画的伪架构图，也比没有强。图跟代码一样，需要持续维护来保证一致性，如果架构图和线上的真实实现脱节了，它就不再是设计工具，而是误导工具。把AI应用架构设计当成不断画图、不断验证的过程，你会发现自己对系统的掌控力，远比你想象的要大。