1. 从一张架构图说起：AI应用到底该怎么搭
很多人第一次接触AI应用开发，脑子里冒出来的第一个念头是“调个API就完事了”。我刚开始也这么想，直到真正接手一个需要接入知识库、调用外部工具、还要维持多轮对话状态的项目，才发现事情远没有那么简单。一个能跑通的Demo和一个能上线的AI应用之间，隔着一整套架构设计的鸿沟。这也是为什么我想借“图解AI应用架构设计”这个题目，把这几年来在AI应用开发一线踩过的坑、总结出的分层思路，完整地摊开来讲一遍。
所谓AI应用架构设计，说白了就是回答一个问题：当用户输入一句话之后，系统内部到底发生了什么，这些环节分别由谁负责，它们之间怎么协作。这个问题听起来朴素，但它决定了你的应用是只能做单轮问答的玩具，还是能支撑复杂业务流程的生产系统。核心关键词AI应用、架构设计、Agent、LLM、MCP，其实正好对应了这套架构里的几个关键层次——LLM是大脑，Agent是手脚和调度中枢，MCP是连接外部世界的标准接口，而架构设计就是把这些东西组装成一个稳定整体的工程方法。
这篇文章适合谁看？如果你已经能调用大模型接口，但不知道如何组织一个完整项目；如果你听说过Agent和MCP，但不确定它们在架构里处于什么位置；如果你正在做AI应用开发，想找一套可参考的分层方案，那这篇内容应该能帮到你。我会尽量用图解式的思路，把每一层的职责、边界、常见坑都讲清楚，让你看完之后能直接对照着搭自己的架构。
2. 整体架构分层：把一团乱麻拆成五层
2.1 为什么必须分层
我见过太多AI项目，一开始就是一堆代码堆在一起：前端直接调模型接口，模型返回的结果直接塞进数据库，工具调用逻辑散落在各个文件里。这种写法在功能少的时候没问题，一旦要加记忆、加工具、加多模型切换，整个项目就会变成一团乱麻，改一处崩三处。分层不是为了好看，是为了让每一层的变化不影响其他层。比如你今天用某个模型，明天想换另一个，如果模型调用逻辑被封装在LLM层，上层业务代码一行都不用改。
从工程实践来看，一套完整的AI应用架构通常可以拆成五层：接入层、编排层、能力层、模型层、基础设施层。这个分法不是唯一的，但我觉得它最符合大多数AI应用的实际情况，也最容易对应到具体的代码模块。
2.2 五层架构的职责边界
先给一张文字版的架构图，从上到下依次是：
- 接入层：负责和用户交互，包括Web界面、移动端、API网关、消息队列等。这一层不关心AI逻辑，只负责把请求收进来、把结果送出去。
- 编排层：这是AI应用的核心，Agent就活在这一层。它负责决定什么时候调模型、什么时候调工具、什么时候查记忆、什么时候结束。可以理解为整个系统的调度中枢。
- 能力层：把各种外部能力封装成统一接口，包括工具调用、知识库检索、记忆存储、MCP客户端等。这一层是Agent的“工具箱”。
- 模型层：负责和LLM打交道，包括模型路由、Prompt管理、流式输出、Token计数、降级策略等。这一层屏蔽了不同模型之间的差异。
- 基础设施层：向量数据库、关系数据库、缓存、日志、监控、密钥管理等等。这一层是地基，平时不显眼，出问题的时候最要命。
这五层之间的关系是：接入层调用编排层，编排层按需调用能力层和模型层，能力层和模型层再依赖基础设施层。每一层只和相邻层交互，不跨层调用。这个约束看起来简单，但坚持下来能省掉大量重构成本。
2.3 一个请求的完整流转过程
为了让大家有直观感受，我描述一个典型场景：用户在聊天框里问“帮我查一下上个月的销售数据，并生成一个趋势图”。
请求从接入层进来，编排层的Agent开始工作。它先判断这个问题需要调用工具，于是通过能力层发起一次数据库查询工具调用。工具返回原始数据后，Agent发现还需要生成图表，于是再调用一个绘图工具。图表生成后，Agent把结果和一段自然语言总结一起返回给模型层，让LLM组织成最终回复。模型层处理完流式输出，结果回到接入层展示给用户。整个过程中，记忆模块在后台默默记录了这次对话的关键信息，方便后续追问。
这个流程里，每一层各司其职。如果数据库换了，只改能力层的工具实现；如果模型换了，只改模型层的路由配置；如果前端换了，只改接入层。这就是分层带来的好处。
3. Agent编排层：整个系统最烧脑的部分
3.1 Agent到底是什么，别被概念绕晕
Agent这个词现在被用得有点泛滥，很多人一听到就想到“自主智能体”“通用人工智能”之类的大词。但从工程角度看，Agent就是一个带循环的调度器。它的核心逻辑可以用一段伪代码概括：
while not done: response = llm.chat(messages, tools) if response.has_tool_call: result = execute_tool(response.tool_call) messages.append(result) else: done = True return response.content就这么简单。Agent和普通LLM调用的区别在于：普通调用是一次性的，问一句答一句；Agent是循环的，它会根据模型的输出决定下一步做什么，直到任务完成。这个循环就是Agent的灵魂。
3.2 编排模式的选择：ReAct、Plan-and-Execute还是Workflow
实际做Agent开发的时候，编排模式的选择很关键。我总结下来主要有三种：
| 模式 | 核心思路 | 适用场景 | 缺点 |
|---|---|---|---|
| ReAct | 边想边做，每步都让模型决定 | 探索性任务、工具调用不确定 | Token消耗大，容易绕圈 |
| Plan-and-Execute | 先规划完整步骤再执行 | 流程明确的多步任务 | 规划错误会导致全盘失败 |
| Workflow | 预定义流程，模型只填内容 | 业务规则固定的场景 | 灵活性差，但最稳定 |
我的经验是：能用Workflow就别用Agent。很多人一上来就想做全自主Agent，结果发现模型经常不按套路出牌，调试成本极高。如果业务流程是确定的，比如“先查订单、再判断状态、再发通知”，那就用Workflow把流程写死，只在需要理解自然语言的地方调模型。这样系统稳定，出了问题也好排查。只有当任务路径真的无法预先确定时，才上ReAct这类自主编排模式。
3.3 Agent记忆管理：短期、长期和会话隔离
Agent记忆是另一个容易踩坑的地方。我把它分成三类：
- 短期记忆：当前对话的消息列表，直接放在上下文里。注意要控制长度，超过模型窗口就得截断或摘要。
- 长期记忆：跨会话需要保留的信息，比如用户偏好、历史事实。通常存向量数据库，需要的时候检索出来注入上下文。
- 会话隔离：不同用户的记忆必须严格隔离，否则会出现A用户的信息泄露给B用户的严重问题。这一点在架构设计时就要考虑，不能等上线了再补。
我踩过的一个坑是：早期做记忆检索时没有加用户ID过滤，测试的时候用同一个账号没发现问题，上线后差点出大事。后来在能力层强制要求所有记忆操作必须带用户标识，从架构上杜绝这类问题。
3.4 Agent安全：别让工具调用变成漏洞
Agent安全这个词最近被提得很多，但很多人理解得比较窄，以为只是防止Prompt注入。实际上Agent安全至少包括三个层面：
第一是工具权限控制。Agent能调用的工具必须白名单化，不能让模型随意调用任意函数。比如一个客服Agent，就不应该有能力调用删除数据库的工具。
第二是输入输出过滤。用户输入可能包含恶意指令，模型输出可能包含敏感信息。这两端都要有过滤机制。
第三是操作审计。Agent的每一次工具调用、每一次模型请求都要有日志，出了问题能追溯。这在生产环境里是硬性要求。
4. MCP与工具层：让Agent真正能干活
4.1 MCP解决了什么问题
MCP是最近AI应用开发领域讨论度很高的一个概念。简单说，它是一套标准协议，让不同的工具和数据源能以统一的方式暴露给AI应用。在没有MCP之前，每接一个工具就要写一套适配代码，工具多了之后维护成本爆炸。MCP的出现相当于给工具调用定了一个USB接口标准，只要工具实现了MCP协议，任何支持MCP的AI应用都能直接调用。
从架构角度看，MCP位于能力层，是Agent和外部世界之间的桥梁。Agent不需要知道工具的具体实现，只需要知道MCP服务器暴露了哪些能力，然后按协议调用即可。这种解耦让工具生态可以独立发展，AI应用也可以灵活组合不同的工具。
4.2 MCP的三种接入方式
实际项目中，MCP的接入方式主要有三种：
- 本地进程：MCP服务器和AI应用跑在同一台机器上，通过标准输入输出通信。适合本地工具，比如文件操作、代码执行。
- 远程服务：MCP服务器部署在远端，通过网络通信。适合团队共享的工具，比如数据库查询、内部API。
- 嵌入式：把MCP能力直接集成到应用内部，不走独立进程。适合性能要求高的场景。
选择哪种方式，主要看工具的部署位置、性能要求和安全边界。我一般建议先从本地进程开始，跑通了再考虑远程部署。
4.3 工具设计的几个原则
工具设计得好不好，直接决定Agent能不能用好。我总结了几条原则：
第一，工具描述要清晰。模型是根据工具描述来决定调不调的，描述写得含糊，模型就会乱调或者不调。描述里要写清楚工具做什么、什么时候用、参数是什么意思。
第二，参数尽量简单。参数越多，模型填错的概率越大。能用枚举就不用自由文本，能用一个参数就不用三个。
第三，返回值要结构化。工具返回的结果最好是JSON格式，字段名清晰，方便模型理解。返回一大段自然语言文本，模型反而不好处理。
第四，错误信息要友好。工具调用失败时，返回的错误信息要能让模型理解发生了什么，这样它才能决定是重试还是换方案。
4.4 工具调用的常见故障排查
工具调用出问题的时候，排查思路一般是这样的：
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 模型不调用工具 | 工具描述不清、Prompt没引导 | 检查工具描述，在系统提示里明确说明可用工具 |
| 调用参数错误 | 参数定义复杂、缺少示例 | 简化参数，在描述里给示例 |
| 调用超时 | 工具执行慢、网络问题 | 加超时控制，检查工具实现 |
| 返回结果模型不理解 | 返回格式混乱 | 统一返回JSON，字段命名清晰 |
| 循环调用同一工具 | 模型陷入死循环 | 加最大调用次数限制，检测重复调用 |
这些坑我基本都踩过，尤其是循环调用那个，早期没有加限制，模型有时候会反复调同一个工具十几次，Token烧得飞快。后来在编排层加了最大迭代次数和重复调用检测，问题就解决了。
5. LLM模型层：屏蔽差异，统一出口
5.1 为什么需要模型层
现在市面上的LLM模型越来越多，各有各的接口格式、参数命名、返回结构。如果业务代码直接调模型接口，换一个模型就要改一堆地方。模型层的价值就在于把这些差异屏蔽掉，对上提供统一的调用接口。
模型层通常要处理这些事情：模型路由（根据任务选模型）、Prompt模板管理、流式输出处理、Token计数、超时重试、降级策略、成本统计。这些事情看起来琐碎，但每一项都直接影响应用的稳定性和成本。
5.2 模型路由策略
模型路由是模型层的核心功能之一。不同任务对模型的要求不一样：简单分类任务用小模型就够了，复杂推理任务需要大模型；对延迟敏感的场景要用快的模型，对质量敏感的场景可以用慢一点的。路由策略一般有几种：
- 按任务类型路由：分类、抽取用便宜模型，生成、推理用强模型。
- 按用户等级路由：付费用户用强模型，免费用户用基础模型。
- 按降级策略路由：主模型超时或失败时，自动切到备用模型。
我一般会在配置里维护一张路由表，把任务类型和模型对应起来，改的时候只改配置不改代码。
5.3 Prompt管理：别把Prompt散落在代码里
Prompt管理是很多项目容易忽视的地方。我见过不少项目，Prompt直接硬编码在业务逻辑里，改一个标点都要重新部署。正确的做法是把Prompt抽出来，集中管理，支持版本控制和热更新。
Prompt管理一般包括：模板定义、变量注入、版本管理、A/B测试。模板定义用占位符，比如{user_input}，运行时替换成实际内容。版本管理让每次Prompt变更都可追溯，出问题能回滚。A/B测试让不同Prompt可以对比效果，用数据决定用哪个。
5.4 流式输出与Token控制
流式输出是提升用户体验的关键。用户不用等模型生成完才看到内容，而是一个字一个字地显示出来，感觉响应快很多。实现流式输出要注意几点：接入层要支持SSE或WebSocket，模型层要正确处理流式响应，中间层要做好缓冲和错误处理。
Token控制是成本管理的关键。每次调用都要记录输入和输出的Token数，累计起来做成本分析。同时要设置单次调用的Token上限，防止异常情况导致费用失控。我一般会在模型层加一个Token预算检查，超过预算就拒绝或降级。
6. 实操落地：从零搭一个最小可用架构
6.1 技术选型建议
如果你现在要动手搭一个AI应用，我建议的技术栈是这样的：
- 接入层：FastAPI或Express，轻量够用，生态成熟。
- 编排层：LangChain或自己写，看团队熟悉程度。自己写其实不难，核心就是那个循环。
- 能力层：MCP客户端用官方SDK，向量库用Milvus或Qdrant，缓存用Redis。
- 模型层：自己封装一层，对接多家模型API，做好路由和降级。
- 基础设施：PostgreSQL存业务数据，Redis做缓存，对象存储放文件。
这个选型不是唯一的，但经过多个项目验证，比较稳。
6.2 最小可用架构的搭建步骤
第一步，先把模型层搭起来。封装一个统一的chat接口，支持传入消息列表和工具定义，返回模型响应。内部处理不同模型的差异，对外暴露统一格式。
第二步，实现Agent循环。写一个run_agent函数，接收用户输入，循环调用模型层，遇到工具调用就执行工具，直到模型返回最终答案。
第三步，接入MCP。启动一个MCP服务器，把常用工具注册进去，Agent通过MCP客户端调用。
第四步，加记忆。用向量数据库存对话历史，每次请求前检索相关记忆注入上下文。
第五步，加接入层。用FastAPI暴露一个聊天接口，支持流式输出。
这五步走下来，一个最小可用的AI应用架构就成型了。后面就是在这个骨架上不断加功能、做优化。
6.3 参数配置与调优经验
几个关键参数的经验值：
- 最大迭代次数：Agent循环最多跑10次，超过就强制结束，防止死循环。
- 上下文窗口：保留最近20轮对话，更早的做摘要或丢弃。
- 工具超时：单个工具调用超时设30秒，超时返回错误让模型决定下一步。
- 模型超时：单次模型调用超时设60秒，超时触发降级。
- 记忆检索条数：每次检索Top 5相关记忆，太多会稀释上下文。
这些值不是固定的，要根据实际场景调整。但有一个原则：所有可能无限循环或无限增长的地方，都必须有上限。
7. 常见问题与排查技巧实录
7.1 Agent不按预期调用工具怎么办
这是最常见的问题。排查顺序是：先看工具描述是否清晰，再看系统Prompt有没有引导模型使用工具，最后看模型本身是否支持工具调用。有些小模型对工具调用的支持不好，换个大模型可能就正常了。
7.2 流式输出中断怎么排查
流式输出中断通常有几个原因：网络不稳定、模型服务端超时、中间层缓冲问题。排查的时候先在模型层加日志，确认是模型没返回还是中间层丢了。如果是网络问题，加心跳和重连机制。
7.3 记忆检索不准怎么优化
记忆检索不准，一般是向量化质量或检索策略的问题。可以尝试：换更好的Embedding模型、调整分块策略、加关键词过滤、做混合检索（向量+关键词）。我实测下来，混合检索的效果比纯向量检索好不少。
7.4 Token消耗过快怎么控制
Token消耗快，通常是上下文太长或Agent循环太多。优化方向：压缩上下文、限制迭代次数、用小模型做预处理、缓存常见问题的答案。我一般会做一个Token消耗监控面板，每天看趋势，异常了及时查。
8. 一些个人体会
做AI应用架构设计这几年，我最大的体会是：不要追求一步到位。很多人一开始就想设计一个完美的架构，结果迟迟动不了手。实际上，架构是演进出来的，不是设计出来的。先搭一个能跑的最小版本，然后在实际使用中发现问题、解决问题，架构自然就长出来了。
另一个体会是：稳定性比先进性重要。新技术层出不穷，但不是每个都适合你的场景。选型的时候多问一句“这个技术解决了我什么实际问题”，如果答不上来，那可能就不需要它。
最后分享一个小技巧：给Agent加一个“思考日志”，把每一步的决策过程记下来。调试的时候看日志，比猜模型为什么这么做高效得多。这个习惯帮我省了大量排查时间。
