AI Infra项目实战：构建LLM网关、RAG与MCP集成的工程化架构-育师

1. 先搞清楚“AI Infra 项目”在简历里到底意味着什么

如果你正在准备AI或后端开发的面试，想把“AI Infra”（AI基础设施）项目写进简历，那首先要明白面试官想看到什么。他们不是想听你罗列一堆技术名词，而是想确认：你是否真的理解如何把零散的AI能力（比如大模型、知识库、工具调用）整合成一个稳定、可扩展、能解决实际问题的工程系统。

一个典型的误区是，把“我用过LangChain调了API”或者“我搭了个RAG demo”就当作AI Infra项目。这远远不够。真正的AI Infra项目，核心是工程化和端到端。它意味着你需要考虑从用户请求接入、路由决策、知识检索、模型调用、工具执行，到最终结果返回、日志监控、错误处理的完整链路。你写在简历上的“LLM网关 + RAG + LLM-Wiki，结合 MCP、Skills”，恰好是这条链路上几个非常关键且能体现你工程深度的组件。

LLM网关：这是流量的总入口和调度中心。它解决了模型厂商切换、负载均衡、限流降级、统一鉴权、成本核算和监控埋点的问题。写这个，说明你考虑过生产环境的稳定性和可运维性。
RAG：这是让大模型“说真话”、减少幻觉的核心技术。但难点不在于调用检索接口，而在于知识库的构建、更新、索引优化和检索质量评估。你如何处理多源异构数据？如何做分块（Chunking）和向量化？如何平衡召回率与精度？如何做冷启动和增量更新？
LLM-Wiki：这可以理解为你基于RAG构建的一个具体应用场景（比如内部知识库问答），它考验的是你将RAG能力产品化的能力，包括前端交互、会话管理、溯源展示等。
MCP：这是Model Context Protocol，一个由Anthropic等公司推动的协议，旨在标准化LLM与外部工具/数据源的连接方式。了解并应用MCP，表明你关注行业前沿标准，致力于构建更开放、可插拔的AI应用架构，而不是写死一堆API调用。
Skills：可以理解为封装好的、可供LLM调用的具体工具能力（如计算器、查天气、执行数据库查询）。集成Skills，体现了你构建智能体的思路，让LLM不仅能回答问题，还能执行动作。

所以，当你的简历上出现这个组合时，面试官会默认你具备构建一个微服务化、插件化、具备知识增强和工具调用能力的AI应用后端的潜力。接下来，你需要用项目细节证明这一点。

2. 如何设计你的“端到端”项目架构与核心流程

一个能经得起深挖的项目，必须有清晰的架构图和核心数据流。不要只写“我用了Spring Boot和Milvus”，要讲清楚它们是如何协作的。

2.1 分层架构设计

一个建议的分层架构如下：

接入层：LLM网关。可以使用开源的LLM Gateway项目（如OpenAI格式兼容的网关），或基于Spring Cloud Gateway/Kong自行封装。核心是统一API入口（/v1/chat/completions），并在这里实现认证、路由（根据请求头或内容分发到不同下游服务）、限流、日志和基础监控。
应用服务层：
- 对话服务：处理普通的聊天对话，直接调用底层LLM API（如OpenAI、通义千问、DeepSeek等）。通过网关路由过来。
- RAG问答服务：处理需要知识库辅助的问答。这是核心，内部会调用检索模块。
- 工具调用服务：处理需要执行Skills的请求。根据LLM生成的工具调用请求（遵循Function Calling格式），路由到具体的Skill执行器。
能力层：
- 检索模块：封装向量数据库（如Milvus, Qdrant, Weaviate）的交互、文本分块、向量化（使用BGE、text2vec等嵌入模型）逻辑。向上为RAG问答服务提供retrieve(query, top_k)接口。
- Skills执行引擎：一个Skills的注册中心与执行器。Skills可以本地实现（如一个计算函数），也可以是远程服务。MCP Server可以在这里被集成，作为一个标准化的Skill供给源。你的服务可以充当MCP Client，调用这些标准化工具。
- LLM调用客户端：封装对多个LLM供应商API的调用，处理不同的API格式、错误重试、Token计数等。
数据层：
- 向量数据库：存储文档块向量。
- 关系型数据库：存储用户对话历史、Skill执行日志、知识库元数据等。
- 对象存储：存储原始的PDF、Word等知识库源文件。

2.2 核心数据流：一次RAG+Tool Call的请求

假设用户问：“我们公司Q3的销售额是多少？顺便帮我计算一下环比增长率。”

请求接入：请求到达LLM网关，网关进行鉴权、限流后，根据路径或内容特征，将请求路由到“RAG问答服务”。
意图识别与路由：RAG服务首先可能用一个轻量级分类模型或规则判断：这个问题需要知识库（查销售额）还是需要工具（计算增长率）。更常见的做法是，全部交给LLM做规划。服务会组装一个包含系统指令、可用Skills描述的Prompt给LLM。
LLM规划与工具调用：LLM返回一个结构化响应，可能包含两部分：a) 需要检索“Q3销售额”的相关信息；b) 需要调用“计算器”Skill，参数是销售额数据。
并行执行：
- RAG分支：服务从LLM响应中提取检索Query（如“Q3 销售额”），发送给检索模块。检索模块从向量库中找到相关文档片段，返回给服务。
- Tool Call分支：服务从LLM响应中提取要调用的Skill名称和参数，调用Skills执行引擎。引擎找到本地计算器Skill或通过MCP调用远程计算服务，执行计算并返回结果。
结果合成：RAG服务将检索到的文档片段和工具执行结果，再次组装成Prompt，发送给LLM进行最终答案的合成。LLM生成自然语言回答：“根据财报，Q3销售额为500万元。Q2销售额为400万元，环比增长率为25%。”
响应返回：最终答案经由RAG服务、网关返回给用户。

这个流程清晰地展示了LLM作为“大脑”，RAG提供“记忆”，Skills提供“手脚”的协作模式。在简历或面试中，画出这个流程图并讲解，比你罗列十项技术都有用。

3. 关键组件的落地细节与避坑指南

3.1 LLM网关：不只是代理

做什么：统一入口，路由到不同的下游服务（自有模型、OpenAI、Azure、RAG服务、工具服务）。
关键实现：
- 路由策略：基于请求头X-Model-Type，或基于Prompt内容关键词进行路由。
- Fallback机制：当主用模型（如GPT-4）超时或失败，自动降级到备用模型（如GPT-3.5-Turbo）。这需要在网关层面维护模型列表和健康状态。
- Token计数与成本核算：在网关处统一计算请求和响应的Token数，关联到用户或部门，用于成本分摊。可以使用tiktoken等库。
- 监控告警：集成Prometheus暴露指标（请求量、延迟、错误率、Token消耗），配置Grafana看板和告警规则。
避坑点：
注意：不要将业务逻辑（如RAG检索）放在网关中。网关应保持轻量，只做流量管控。复杂的业务路由最好放在后端的业务服务里，网关只做初步分流。

3.2 RAG系统：质量比功能更重要

核心挑战：检索质量直接决定最终答案质量。很多人只关注了“搭起来”，没关注“好不好用”。
关键实现：
- 文本分块：不要简单按固定字符数切割。对于中文，尝试按标点、段落，或使用语义分割模型。对于表格、代码，需要特殊处理以保持结构。
- 向量模型选型：不要盲目使用通用的text-embedding-ada-002。针对中文领域，BGE、text2vec系列模型通常有更好表现。需要在自己的业务语料上做小规模测试，看相似问题能否召回正确答案。
- 检索优化：
  - 混合检索：结合向量检索（语义）和关键词检索（如BM25），提升召回率。
  - 重排序：初步检索出10个片段后，使用一个更精细的交叉编码器模型（如bge-reranker）对它们进行重排序，选出最相关的3个送入LLM，可以显著提升精度并节省Token。
- 知识库更新：设计一个流水线，支持增量更新。新文档入库后，能自动触发分块、向量化、索引更新，并让旧缓存失效。
避坑点：
- 数据清洗：90%的RAG问题源于脏数据。PDF解析乱码、HTML标签未去除、无关广告文本等，都会污染向量空间。必须花时间做数据预处理。
- 评估体系：搭建一个简单的评估流程。准备一批标准问题（Q）和参考答案（A），用你的RAG系统跑出答案（A‘），使用LLM（如GPT-4）自动评判A’与A的相关性、准确性。没有评估，优化就是盲目的。

3.3 MCP与Skills集成：实现动态能力扩展

MCP是什么：你可以把它理解为AI版的“USB协议”。一个MCP Server对外提供一组标准化的工具（比如数据库查询、画图、发送邮件），任何兼容MCP Client的AI应用（如Claude Desktop、你的服务）都能发现并调用这些工具，而无需为每个工具单独开发集成代码。
如何集成：
1. 在你的“Skills执行引擎”中，集成一个MCP Client。这个Client可以主动连接到你配置的MCP Server（例如，一个提供公司内部数据库查询的MCP Server）。
2. MCP Server启动时会向Client声明自己提供的工具列表（名称、描述、参数schema）。
3. 当你的服务需要为LLM提供工具选项时，它不仅可以列出本地Skills，还可以从MCP Client获取远程工具列表，一并组装进Prompt。
4. LLM选择调用某个MCP工具时，你的服务通过MCP Client将参数转发给对应的MCP Server执行，并返回结果。

Skills设计：本地Skills应设计成无状态、功能单一的函数或微服务。例如：

# 一个简单的计算器Skill示例 class CalculatorSkill: name = “calculator” description = “执行数学计算，支持加减乘除和括号。” parameters = {...} # JSON Schema定义参数 def execute(self, expression: str) -> str: try: # 安全警告：生产环境必须使用安全的eval替代方案，如ast.literal_eval或自定义解析器 result = eval(expression) return str(result) except Exception as e: return f“计算错误: {e}”

避坑点：
- 安全性：这是最大的坑。尤其是执行计算、代码、系统命令的Skill，必须进行严格的输入验证、权限控制和沙箱隔离。永远不要相信LLM直接生成的、未经清洗的参数去调用系统命令。
- 工具描述：给LLM的工具描述（description和parameters）必须清晰、准确、无歧义。模糊的描述会导致LLM错误调用。

4. 从Demo到简历：如何提炼亮点并准备面试问答

项目跑通只是第一步，如何表达才是关键。

4.1 简历项目描述公式

不要写：“负责LLM网关和RAG系统的开发。” 要写：“主导设计了公司AI中台的智能问答架构，通过引入LLM网关统一了多模型接入与流量管控，使模型切换成本降低70%；搭建了基于混合检索与重排序的RAG管道，在内部知识库场景下将答案准确率从60%提升至85%；通过集成MCP协议，实现了外部工具的动态插拔，支持业务方快速上线新的AI能力。”

要点：技术栈 + 你做的具体设计/决策 + 可量化的结果（提升效率、降低成本、提高准确率、支持业务规模）。即使没有真实线上数据，也可以用“通过压测，系统支持QPS达到…”，“通过人工评估，准确率提升至…”来表述。

4.2 预设面试问题与回答思路

问：你的RAG系统检索效果不好怎么办？
- 答：我会启动一个排查链路。首先，检查输入，看用户问题是否清晰，是否需要query改写。其次，检查数据，看被检索的文档块质量，是否分块不合理或包含噪音。然后，检查模型，评估使用的向量模型是否适合当前领域，考虑微调或更换。接着，检查检索过程，是否可以考虑引入混合检索或重排序。最后，检查LLM合成，看提供给LLM的上下文是否过多或过少，调整上下文窗口和Prompt指令。我们建立了基于LLM-as-Judge的自动评估流程来辅助这个过程。
问：LLM网关如何做负载均衡和熔断？
- 答：负载均衡方面，对于同一个模型（如GPT-4），我们配置了多个API-KEY，网关采用轮询或加权随机策略分发请求，避免单个KEY限流。熔断方面，我们集成了Resilience4j或Sentinel，为每个下游模型服务设置独立的熔断器。当请求失败率或慢调用比例超过阈值，熔断器会打开，后续请求快速失败，并定期进入半开状态试探恢复。同时，网关会实时监控各模型服务的延迟和错误码，用于动态调整路由权重。
问：MCP和你们自己写的Skills有什么区别？怎么选？
- 答：MCP是一种标准化协议，适合将已有的、复杂的、独立的外部服务（如内部CRM系统、数据分析平台）暴露给LLM。它的优势是解耦和标准化，服务提供方只需实现MCP Server，所有MCP Client都能用。而我们自己写的Skills，通常是轻量的、通用的、无状态的工具函数（如计算、格式化、简单查询），更适合内嵌在应用内部，延迟更低，控制更强。选型上，对于公司核心业务系统，我们推荐其提供MCP接口；对于通用小工具，我们内部实现为Skill。
问：如何保证工具调用的安全性？
- 答：这是一个多层防御体系。第一层，权限控制：在网关和业务服务层校验用户身份和权限，决定其能否调用特定Skill。第二层，输入验证与清洗：对LLM传来的参数进行严格的Schema校验和内容过滤（如防SQL注入、命令注入）。第三层，沙箱隔离：对于执行代码或命令的高风险Skill，必须在独立的、资源受限的容器或沙箱环境中运行。第四层，操作审计：所有工具调用必须记录详尽的日志（谁、何时、调用什么、参数、结果），用于事后审计和问题追踪。