图解AI应用架构设计：从LLM、Agent到MCP的完整指南

1. 为什么“图解”才是理解AI应用架构的正确姿势

做AI应用开发这几年，我最大的感受是：大部分人不是不会写代码，而是脑子里没有一张清晰的架构图。你问他“你的AI应用怎么跑的”，他能给你讲一堆名词——Agent、LLM、MCP、RAG、Tool Calling——但真要他画出来数据从哪进、在哪分流、在哪调模型、在哪落库，立刻就卡壳了。

这不是能力问题，是认知结构问题。AI应用架构和传统Web架构最大的区别在于：传统架构的数据流是确定的，AI应用的数据流是概率性的。一个请求进来，可能走LLM直接回答，可能触发Agent规划，可能调用外部工具，可能检索知识库，甚至可能因为模型幻觉走了一条你根本没设计过的路径。这种不确定性，用文字描述很容易漏，但画成图就一目了然。

所以“图解AI应用架构设计”这个主题，核心价值不在于教你画漂亮的流程图，而在于用可视化的方式强迫你把每个模块的边界、职责、数据流向想清楚。我自己带团队做AI项目，评审第一关就是看架构图——图画不清楚，说明你根本没想明白。

这篇文章适合三类人：一是刚转AI应用开发的工程师，想建立完整的架构认知；二是有传统后端经验但没做过AI产品的开发者，想知道差异在哪；三是技术负责人，需要一套可复用的架构设计方法论来评审和指导团队。我会从分层设计讲到核心模块拆解，再到实操搭建和问题排查，尽量把每个“为什么这么设计”讲透。

2. AI应用架构的分层设计与核心思路拆解

2.1 为什么AI应用需要单独的分层架构

传统CRUD应用的架构分层大家很熟：Controller → Service → DAO → DB。这套东西在AI应用里依然有用，但不够用。因为AI应用多了几个传统架构里不存在的角色：模型推理层、上下文管理层、工具调用层、Agent编排层。这些角色的引入，让数据流从“线性”变成了“网状”。

我见过很多团队一开始不做分层，直接把OpenAI的SDK调用塞进Controller里，结果三个月后代码变成一团乱麻：prompt散落在各个文件、工具调用逻辑和业务逻辑混在一起、换个模型要改十几个地方。这就是没有架构设计的代价。

我的建议是采用五层架构，从下到上依次是：

• 基础设施层：模型接入、向量数据库、缓存、消息队列、日志监控
• 能力层：LLM调用封装、Embedding服务、工具注册中心、MCP协议适配
• 编排层：Agent调度、工作流引擎、上下文管理、记忆系统
• 应用层：具体的业务逻辑，比如客服、写作、代码助手
• 交互层：API网关、前端界面、流式输出处理

这个分层的核心原则是依赖单向向下：应用层可以调编排层，编排层可以调能力层，但反过来不行。这样做的理由是，AI应用最不稳定的部分就是模型和工具，把它们隔离在底层，上层业务逻辑就不会因为换个模型或者加个工具而大改。

2.2 LLM在架构中的定位：它不是数据库，是推理引擎

很多人第一次做AI应用，会把LLM当成一个“智能数据库”来用——输入问题，输出答案。这个认知是错的，会导致架构设计跑偏。

LLM的本质是一个无状态的推理引擎。它不存储任何东西，每次调用都是独立的。你给它什么上下文，它就基于什么上下文推理。这意味着两件事：第一，所有需要“记住”的东西，都得你自己在架构里实现（这就是记忆系统和上下文管理的由来）；第二，LLM的输出是概率性的，同样的输入可能得到不同输出，所以架构里必须有校验和兜底机制。

理解这一点，你就能明白为什么AI应用架构里会有那么多“额外”的模块。向量数据库是为了给LLM补充它不知道的知识，工具调用是为了让LLM能操作外部世界，Agent编排是为了让LLM能多步推理，记忆系统是为了让LLM有连续性。这些模块不是锦上添花，是LLM本身能力边界的必然补充。

2.3 Agent与MCP：编排层的两个关键抽象

Agent和MCP是当前AI应用架构里最热的两个概念，但很多人搞不清它们的关系。我用一句话概括：Agent是“谁来做”，MCP是“用什么做”。

Agent解决的是“自主决策”问题。传统程序是你写死if-else，Agent是让LLM自己决定下一步做什么。一个Agent通常包含：规划模块（拆解任务）、执行模块（调用工具）、反思模块（检查结果）。Agent架构的核心难点在于容错——LLM可能规划错、可能调用错工具、可能陷入循环，所以架构里必须有最大步数限制、结果校验、异常回滚这些机制。

MCP（Model Context Protocol）解决的是“工具标准化”问题。在MCP出现之前，每个AI应用接入工具都要自己写适配层，GitHub一套、数据库一套、文件系统一套，重复劳动严重。MCP定义了一套标准协议，让工具提供方和AI应用方解耦。你可以把它理解成“AI世界的USB接口”——只要工具实现了MCP协议，任何支持MCP的AI应用都能直接调用。

在架构图上，Agent在上，MCP在下。Agent决定要做什么，通过MCP去调用具体工具。这个分层让系统既灵活又可控。

2.4 一张图看懂完整数据流

我把一个典型AI应用的请求处理流程画成文字版架构图，你可以对照着理解：

用户输入 ↓ [交互层] API网关 → 鉴权 → 限流 → 请求路由 ↓ [应用层] 业务逻辑 → 判断是否需要AI能力 ↓ [编排层] Agent调度器 ├→ 加载上下文（历史对话 + 记忆） ├→ 规划任务（LLM推理） ├→ 决定调用工具 │ ↓ │ [能力层] MCP工具注册中心 → 调用具体工具 │ ↓ │ 工具返回结果 → 回填上下文 ├→ 循环直到任务完成或达到最大步数 ↓ [能力层] LLM调用封装 → 模型推理 ↓ [基础设施层] 日志、监控、缓存 ↓ [交互层] 流式输出 → 用户

这张图里每个箭头都是数据流，每个方框都是职责边界。画清楚这张图，你的架构设计就成功了一半。

3. 核心模块的细节解析与实操要点

3.1 LLM调用封装：别让SDK裸奔

新手最容易犯的错，就是在业务代码里直接调OpenAI SDK。我早期也这么干过，结果换模型的时候改了三十多个文件，痛不欲生。

正确的做法是在能力层做一个LLM Gateway，把所有模型调用统一收口。这个Gateway要处理几件事：

第一，多模型适配。不同模型的API格式不一样，有的用messages数组，有的用prompt字符串，有的支持function calling有的不支持。Gateway要做格式转换，让上层业务代码不感知底层用的是哪个模型。

第二，重试与降级。LLM调用失败是常态，网络抖动、限流、模型过载都会导致失败。Gateway要内置指数退避重试，重试失败后自动降级到备用模型。我一般配置主模型失败重试2次，还失败就切备用模型，再失败才抛异常。

第三，Token计数与成本控制。每次调用都要记录input tokens和output tokens，累计到用户或租户维度。这不是可选项，是必须项——我见过太多团队上线一个月才发现账单爆炸。

第四，流式输出处理。现在用户都习惯了打字机效果，Gateway要统一处理SSE流式响应，把不同模型的流式格式转成统一格式。

一个简化的Gateway接口设计大概长这样：

class LLMGateway: def chat(self, messages, model=None, stream=False, tools=None): # 1. 选择模型（默认模型或指定模型） # 2. 格式转换（统一messages格式转成目标模型格式） # 3. 调用模型（带重试） # 4. 记录token和耗时 # 5. 返回统一格式响应 pass def embed(self, texts, model=None): # 向量化，同样要统一封装 pass

注意：Gateway不要做业务逻辑，只做技术适配。业务逻辑放应用层，这样Gateway才能被多个业务复用。

3.2 上下文管理：AI应用的“内存管理”

上下文管理是AI应用架构里最容易被低估的模块。很多人觉得就是把历史对话拼进去，能有多难？实际上这里面的坑非常多。

第一个坑是Token预算。每个模型都有上下文窗口限制，比如128K。但你不能把128K塞满，因为输出也要占Token，而且Token越多推理越慢越贵。我的经验是：输入上下文控制在模型窗口的60%以内，留40%给输出和缓冲。

第二个坑是信息优先级。上下文里通常包含：系统提示词、历史对话、检索到的知识、工具返回结果、当前用户输入。这些东西的重要性不一样，当Token不够时，要按优先级裁剪。我的优先级排序是：系统提示词 > 当前输入 > 最近3轮对话 > 检索知识 > 更早的对话。

第三个坑是记忆的持久化。短期记忆（当前会话）放内存或Redis，长期记忆（跨会话）要落库。长期记忆的写入策略很关键——不是所有对话都值得记，我一般用LLM做一次“记忆提取”，只把用户偏好、关键事实、重要结论存下来。

实操上，我建议把上下文管理做成一个独立的ContextManager类：

class ContextManager: def build_context(self, session_id, user_input, max_tokens=8000): # 1. 加载系统提示词 # 2. 加载长期记忆（从向量库检索相关记忆） # 3. 加载短期对话历史 # 4. 加载检索知识（RAG） # 5. 按优先级裁剪到max_tokens # 6. 组装成最终messages pass def save_memory(self, session_id, conversation): # 用LLM提取关键信息，存入长期记忆 pass

3.3 MCP工具接入：标准化带来的架构简化

MCP的价值在架构层面体现得最明显。没有MCP之前，每接一个工具都要写适配代码；有了MCP，工具接入变成了配置工作。

MCP的核心概念有三个：Server（工具提供方）、Client（AI应用方）、Transport（通信方式）。Server暴露工具列表和调用接口，Client发现工具并调用，Transport负责消息传递（可以是stdio、HTTP、SSE等）。

在架构设计上，我建议在能力层做一个MCP Hub，统一管理所有MCP Server的连接。MCP Hub的职责包括：

• 服务发现：启动时扫描配置，连接所有MCP Server
• 工具注册：把各Server的工具汇总成统一工具列表
• 调用路由：根据工具名路由到对应的Server
• 健康检查：定期ping各Server，剔除不可用的
• 权限控制：不同业务线只能访问授权的工具

一个MCP Hub的配置大概长这样：

mcp_servers: - name: filesystem transport: stdio command: npx args: ["-y", "@modelcontextprotocol/server-filesystem", "/data"] - name: database transport: http url: http://localhost:8080/mcp - name: github transport: stdio command: npx args: ["-y", "@modelcontextprotocol/server-github"]

提示：MCP Server的进程管理是个坑。stdio方式的Server是子进程，主进程挂了子进程可能变僵尸。建议用进程管理器（如supervisor）托管，或者用HTTP方式避免进程耦合。

3.4 Agent编排：从ReAct到Plan-Execute

Agent编排是架构里最复杂的部分，因为它涉及LLM的自主决策。目前主流的Agent模式有两种：ReAct和Plan-Execute。

ReAct是“思考-行动-观察”循环：LLM先想一步，调用工具，看结果，再想下一步。优点是灵活，适合探索性任务；缺点是容易陷入循环，而且每步都要调LLM，成本高。

Plan-Execute是先规划再执行：LLM先制定完整计划，然后逐步执行。优点是效率高，计划可以复用；缺点是计划可能不准确，执行中遇到意外不好调整。

我的实践经验是：简单任务用ReAct，复杂任务用Plan-Execute，超复杂任务用混合模式。混合模式是先Plan，执行中如果发现计划有问题，切换到ReAct重新规划。

Agent编排的架构要点：

• 最大步数限制：防止无限循环，一般设10-20步
• 工具调用校验：LLM可能调用不存在的工具或传错参数，要有校验层
• 中间结果缓存：相同工具调用可以缓存，省钱省时间
• 异常回滚：执行到一半失败，要能回滚已执行的操作
• 人工介入点：关键操作（如转账、删除）要暂停等人工确认

class AgentOrchestrator: def run(self, task, max_steps=15): plan = self.planner.plan(task) for step in plan.steps: if step.requires_confirmation: yield await_human_approval(step) result = self.executor.execute(step) if not self.validator.check(result): plan = self.planner.replan(task, step, result) if self.step_count > max_steps: raise MaxStepsExceeded() return self.synthesizer.summarize(results)

4. 从零搭建一个AI应用架构的完整实操

4.1 环境准备与技术选型

假设我们要搭建一个“智能代码助手”，能回答代码问题、检索代码库、执行简单命令。这个场景足够典型，涵盖了LLM、RAG、Agent、MCP四大核心能力。

技术选型上，我的建议是：

选型的原则是：核心链路用成熟方案，边缘链路可以自研。LLM调用、向量检索这些用成熟库，Agent编排逻辑建议自研，因为业务耦合太深，用框架反而受限。

4.2 搭建LLM Gateway与上下文管理

先搭最底层。LLM Gateway我用一个统一的类封装，支持多provider：

class LLMGateway: def __init__(self, providers): self.providers = providers # {"openai": ..., "anthropic": ...} self.token_counter = TokenCounter() async def chat(self, messages, model="default", stream=False): provider = self._select_provider(model) for attempt in range(3): try: response = await provider.chat(messages, stream=stream) self.token_counter.record(messages, response) return response except RateLimitError: await asyncio.sleep(2 ** attempt) except Exception as e: if attempt == 2: provider = self._fallback_provider() raise LLMCallFailed()

上下文管理我单独做一个ContextManager，核心是Token预算分配：

class ContextManager: def __init__(self, max_tokens=8000): self.max_tokens = max_tokens self.budget = { "system": 0.15, # 系统提示词15% "memory": 0.15, # 长期记忆15% "history": 0.30, # 对话历史30% "retrieval": 0.25, # 检索知识25% "current": 0.15, # 当前输入15% } def build(self, session_id, user_input): context = [] context.append(self._load_system_prompt()) context.extend(self._load_memory(session_id, user_input)) context.extend(self._load_history(session_id)) context.extend(self._retrieve_knowledge(user_input)) context.append({"role": "user", "content": user_input}) return self._trim_to_budget(context)

这个预算分配不是拍脑袋的，是我踩坑踩出来的。早期我把history给到50%，结果检索知识放不下，回答质量下降。后来调整到30%，检索给25%，效果明显提升。

4.3 接入MCP工具与Agent编排

MCP工具接入我用官方SDK，启动时连接所有配置的Server：

class MCPHub: def __init__(self, config_path): self.servers = {} self.tools = {} self._load_config(config_path) async def start(self): for name, cfg in self.config.items(): server = await self._connect(cfg) self.servers[name] = server tools = await server.list_tools() for tool in tools: self.tools[tool.name] = {"server": name, "schema": tool} async def call(self, tool_name, arguments): if tool_name not in self.tools: raise ToolNotFound(tool_name) server = self.servers[self.tools[tool_name]["server"]] return await server.call_tool(tool_name, arguments)

Agent编排我用状态机模式，每个状态是一个节点，节点之间通过条件边连接：

class CodeAssistantAgent: def __init__(self, llm, mcp_hub, context_mgr): self.llm = llm self.mcp = mcp_hub self.ctx = context_mgr self.max_steps = 15 async def run(self, session_id, user_input): context = self.ctx.build(session_id, user_input) for step in range(self.max_steps): response = await self.llm.chat(context, tools=self.mcp.list_tools()) if response.has_tool_calls: for call in response.tool_calls: result = await self.mcp.call(call.name, call.arguments) context.append({"role": "tool", "content": result}) else: return response.content raise MaxStepsExceeded()

4.4 流式输出与前端对接

流式输出是用户体验的关键。后端用SSE推送，前端用EventSource接收。这里有个坑：Agent执行过程中可能有多轮LLM调用，每轮都要流式输出，但用户看到的是一个连续的流。

我的做法是在Agent层做流式聚合，把多轮LLM的输出拼成一个流：

async def stream_run(self, session_id, user_input): context = self.ctx.build(session_id, user_input) for step in range(self.max_steps): async for chunk in self.llm.chat_stream(context): if chunk.type == "text": yield f"data: {json.dumps({'type': 'text', 'content': chunk.text})}\n\n" elif chunk.type == "tool_call": yield f"data: {json.dumps({'type': 'tool', 'name': chunk.name})}\n\n" result = await self.mcp.call(chunk.name, chunk.arguments) context.append({"role": "tool", "content": result}) if not response.has_tool_calls: break yield "data: [DONE]\n\n"

前端接收时，根据type字段区分是文本还是工具调用，工具调用可以显示一个“正在执行xxx”的提示，让用户知道系统在干活。

5. 常见问题与排查技巧实录

5.1 LLM调用失败的排查思路

LLM调用失败是最常见的问题，我整理了一个排查表：

我遇到最多的是400错误，通常是messages格式不对。比如有些模型要求system message必须在最前面，有些要求tool message必须紧跟tool_call。建议在Gateway层做格式校验，提前拦截。

5.2 Agent陷入循环的解决

Agent循环是另一个高频问题。LLM可能反复调用同一个工具，或者在不同工具间来回跳。我的解决方案是三层防护：

第一层，最大步数限制。这是最基本的，超过15步直接终止。

第二层，重复检测。记录最近5步的工具调用，如果发现完全相同的调用重复出现，强制终止并返回当前结果。

第三层，进度评估。每3步让LLM评估一次“任务是否在推进”，如果连续两次评估都是“没有进展”，就重新规划或终止。

def check_loop(self, history): recent = history[-5:] calls = [(h.tool_name, h.arguments) for h in recent if h.type == "tool_call"] if len(calls) >= 3 and len(set(calls)) == 1: return True # 重复调用 return False

5.3 上下文超长的处理

上下文超长通常发生在长对话或大文档检索场景。我的处理策略是分级裁剪：

1. 先裁剪检索知识，只保留相似度最高的3条
2. 再裁剪历史对话，只保留最近5轮
3. 还超长就裁剪系统提示词，去掉非必要的示例
4. 最后还超长，就对历史对话做摘要压缩

摘要压缩是用LLM把早期对话总结成一段话，这样既保留了信息又大幅减少Token。我一般保留最近3轮原文，更早的做摘要。

5.4 MCP工具调用超时的处理

MCP工具调用超时很常见，尤其是文件系统、数据库这类IO操作。我的处理方式是：

• 每个工具调用设置独立超时（默认30秒，可配置）
• 超时后不直接失败，而是返回“工具执行超时”给LLM，让LLM决定是否重试或换方案
• 对于幂等操作，可以自动重试一次
• 对于非幂等操作（如写文件），超时后要检查实际状态，避免重复执行

提示：MCP Server如果崩溃，Client要能自动重连。我建议在MCP Hub里加一个健康检查循环，每30秒ping一次所有Server，发现不可用就标记并尝试重连。

5.5 成本失控的预防

成本失控是AI应用特有的问题。我的预防措施：

• Token预算：每个用户每天设置Token上限，超了降级到小模型
• 缓存：相同问题缓存答案，相同工具调用缓存结果
• 模型分级：简单任务用小模型，复杂任务用大模型
• 监控告警：每小时统计Token消耗，超过阈值告警
• Prompt优化：定期review prompt，去掉冗余内容

我实测下来，加了缓存和模型分级后，成本能降40%左右。缓存命中率在客服场景能到30%，在代码助手场景能到20%。

6. 架构演进与扩展方向

6.1 从单体到微服务的演进路径

一开始不要上微服务。我见过太多团队一上来就搞微服务，结果LLM调用、Agent编排、工具管理拆成三个服务，调试的时候日志都串不起来。

我的建议是单体起步，按需拆分。第一阶段所有模块在一个进程里，用模块化代码隔离。当出现以下信号时再考虑拆分：

• 不同模块的扩缩容需求差异大（比如LLM调用要GPU，工具调用要CPU）
• 团队规模超过10人，代码冲突频繁
• 某个模块成为性能瓶颈

拆分时优先拆LLM Gateway和MCP Hub，因为这两个是基础设施，被多个业务复用。Agent编排和应用层可以晚点拆。

6.2 多模态能力的架构扩展

多模态是趋势，架构上要提前留好扩展点。核心是在能力层增加多模态处理模块，统一处理图像、音频、视频的输入输出。

具体来说，LLM Gateway要支持多模态消息格式（OpenAI的content数组格式），上下文管理要能处理多模态内容（图片转base64或URL），工具层要能调用多模态工具（如图像生成、语音识别）。

架构上不需要大改，主要是消息格式的扩展。但要注意多模态内容的Token计算方式不同，图片按分辨率算Token，音频按时长算，这些要在Token计数器里单独处理。

6.3 Agent安全与容错设计

Agent安全是我最近重点研究的方向。Agent能自主调用工具，这意味着它可能执行危险操作。架构上要有几层防护：

权限层：每个Agent有明确的工具白名单，不能调用未授权的工具。

确认层：危险操作（删除、转账、发送）要人工确认，不能自动执行。

沙箱层：代码执行类工具要在沙箱里跑，限制资源访问。

审计层：所有工具调用记录日志，可追溯可回放。

熔断层：检测到异常行为（如短时间内大量调用）自动熔断。

容错方面，核心是幂等性设计。工具调用要支持幂等，这样重试不会产生副作用。对于非幂等操作，要用事务或补偿机制。

7. 我踩过的那些坑和最后的小技巧

做AI应用架构这两年，踩的坑比写的代码还多。分享几个印象最深的：

第一个坑是过度依赖框架。早期我用LangChain，什么都想用它的抽象，结果版本一升级全挂了。后来我改成核心逻辑自研，只在边缘用框架，稳定性大幅提升。框架是工具，不是架构。

第二个坑是忽视可观测性。上线第一个月，用户反馈“有时候回答很慢”，但我完全不知道慢在哪。后来加了Langfuse做链路追踪，才发现是某个MCP工具调用平均耗时8秒。没有可观测性，优化就是盲人摸象。

第三个坑是Prompt散落。早期prompt写在代码里，改一个prompt要重新部署。后来我把prompt抽到配置文件，支持热更新，迭代效率提升好几倍。现在我用prompt管理平台，支持版本、A/B测试、回滚。

最后分享一个小技巧：架构图要画两张，一张是设计图，一张是实际运行图。设计图是你期望的架构，运行图是从日志和监控里还原出来的实际调用链路。两张图对比，你就能发现哪些设计没落地、哪些调用是意料之外的。我每个月都会做一次这个对比，每次都能发现优化点。

这个架构后续还可以往几个方向扩展：一是加评估层，用LLM as Judge自动评估回答质量；二是加反馈层，把用户反馈回流到prompt优化；三是加多租户层，支持SaaS化部署。每个方向都是独立的模块，不影响核心架构。