
最近在整理项目经历时我遇到了一个典型的困惑简历上写满了“RAG”、“LLM”、“Agent”这些热门词汇但面试官一问细节要么是“调用了API”要么是“用了LangChain”再深究下去就只剩下“参考了官方文档”。这让我意识到很多所谓的“AI项目”其实只是停留在“会用工具”的层面距离“理解系统”和“解决工程问题”还差得很远。直到我尝试把几个看似独立的概念——LLM网关、RAG、LLM-Wiki、MCP、Skills——串联成一个完整的“AI Infra”项目叙事整个思路才豁然开朗。这不再是一个个孤立的工具使用报告而是一个关于如何为大型语言模型构建服务化、可扩展、可观测的基础设施的工程实践。面试时你可以从网关的流量治理讲到RAG的召回优化再从MCP的协议设计聊到Skills的生态集成每一环都扣着“端到端能力”这个核心。今天我就来拆解一下如何把这个组合拳写进简历并真正讲出一个有深度、有细节、能体现你工程思维的故事。1. 从“调用API”到“构建服务”重新理解AI Infra的价值很多人对AI Infra人工智能基础设施的第一反应是“高大上”是只有大厂才玩得起的庞然大物。但在我看来它的核心价值非常朴素把一次性的、脚本式的AI实验变成可重复、可管理、可协作的在线服务。我们项目里常见的“LLM网关”就是这个理念的起点。1.1 LLM网关不止是代理更是治理中心当你只有一个ChatGPT账号时你不需要网关。但当你需要对接多个模型GPT-4、Claude、文心一言、通义千问、管理不同团队的密钥配额、统一日志和监控、实施速率限制和熔断降级时一个统一的入口就变得至关重要。核心功能它首先是一个反向代理将形形色色的模型APIOpenAI格式、Anthropic格式、国产模型自定义格式统一成内部标准接口。这解决了“模型异构”的问题。关键治理更重要的是它承载了非功能性需求。你可以在这里实现认证鉴权哪个应用、哪个用户有权限调用调用额度还剩多少流量控制防止某个应用突发流量打垮后端模型服务。监控与可观测性记录每一次调用的耗时、Token消耗、费用、成功/失败状态。这是后续成本分析和性能优化的基础。降级与熔断当某个模型服务响应缓慢或不可用时自动切换到备用模型或返回友好提示。在简历或面试中提到“实现了LLM网关”你不能只说“用Nginx配了个反向代理”。你要能讲清楚你为什么需要它你用它解决了什么具体的工程问题比如多模型成本分摊、突发流量导致服务雪崩以及你是如何设计关键模块如路由策略、监控指标的。1.2 为什么这是Infra思维的开始因为从这里开始你的视角从“如何让这段提示词生效”切换到了“如何让这项AI能力稳定、高效、安全地服务所有业务方”。这是从“炼丹师”到“工程师”的关键一步。你的技术栈也不再局限于Python和LangChain而是会涉及到Web框架FastAPI/Spring Boot、中间件Redis做限流、监控系统Prometheus/Grafana等更广泛的后端知识。2. RAG与LLM-Wiki从“向量检索”到“知识工程”有了稳定的模型调用能力接下来要解决模型“不知道”的问题。RAG检索增强生成是标准答案但很多人的实践止步于“文本切块 - 向量化 - 存入Milvus - 查询”。这远远不够。2.1 LLM-Wiki一个活的、可运营的知识库“LLM-Wiki”这个名字起得很好它暗示这不仅仅是一个向量数据库而是一个需要持续维护和运营的知识系统。数据来源与处理知识从哪来爬虫抓取、内部文档、会议纪要、工单记录。不同的来源意味着不同的清洗、去重、格式化规则。你如何处理PDF表格、扫描图片中的文字如何拆分长文档才更符合语义按章节、按主题而非固定长度元数据与过滤除了向量本身强大的元数据文档来源、更新时间、部门、置信度是精准召回的关键。面试官可能会问“当用户问‘2024年Q3的销售政策’时你的系统如何确保不返回2023年的旧政策”——答案就在元数据过滤。召回策略与重排简单的余弦相似度够用吗是否需要结合BM25等关键词检索进行混合搜索Hybrid Search召回的Top N个片段是否需要用一个小型交叉编码器Cross-Encoder模型进行精排Re-ranking这直接决定了最终答案的质量。2.2 RAG的深水区评估与迭代一个更高级的讨论点是你如何知道你的RAG系统变好了还是变差了评估指标除了人工抽查可以设计自动化评估答案相关性Answer Relevance、上下文相关性Context Relevance、事实一致性Faithfulness。这需要构造测试集和评估逻辑。持续迭代基于评估结果你可能需要调整文本分块策略、尝试不同的嵌入模型Embedding Model、优化检索查询Query Rewriting/Expansion。这是一个闭环的优化过程。在项目中体现这一点说明你不仅实现了RAG更是在以产品化的思维运营它。你可以说“我们为LLM-Wiki建立了基于准确率、召回率和人工评分的评估体系并据此迭代了三次文本分块策略将业务问答的准确率提升了15%。”3. MCP与Skills从“单一应用”到“能力生态”这是让项目格局打开的另一点。当你的AI能力RAG问答、数据分析、画图被封装成服务后如何让其他应用甚至其他AI Agent方便地调用这就是MCPModel Context Protocol和Skills要解决的问题。3.1 MCP定义AI与工具对话的“普通话”你可以把MCP理解为一套标准协议它规定了AI模型如Claude Desktop如何发现、调用外部工具你的RAG系统、数据库、内部API。实现一个MCP Server就意味着你的能力可以被任何支持MCP协议的客户端如Claude、未来可能更多的AI桌面应用直接使用。项目中的体现你可以将你的“LLM-Wiki问答”能力包装成一个MCP工具。当用户在Claude中问及公司内部知识时Claude会通过MCP协议调用你的服务并将结果融入对话。这比要求用户打开另一个网页或复制粘贴要优雅得多。技术要点实现MCP Server需要遵循其规范定义工具名称、描述、参数列表并处理JSON-RPC格式的请求。这考察的是你对接口设计和协议的理解。3.2 Skills开箱即用的能力模块Skills的概念更贴近终端用户。它可以是一个精心调校的提示词模板一个集成了特定工作流的AI应用或者一个调用了一系列工具的复杂Agent。与MCP的关系一个Skill可以底层调用多个MCP工具来完成复杂任务。例如一个“市场周报生成”Skill可能会依次调用“检索上周销售数据”MCP工具、“分析数据趋势”MCP工具和“生成PPT大纲”MCP工具。在项目中设计Skills你可以基于LLM-Wiki创建几个典型的Skills“新员工答疑”Skill自动回答关于考勤、报销、IT设置等高频问题。“技术文档专家”Skill针对代码库、API文档进行深度问答和示例生成。“竞品分析助手”Skill从爬取的竞品信息中提取结构化对比报告。在简历中你可以这样描述“基于LLM网关和RAG知识库我们抽象出一组标准的AI能力服务并通过实现MCP协议将其开放。在此基础上我们为不同业务线如客服、研发、市场封装了即开即用的Skills降低了AI能力的应用门槛。”4. 端到端项目实战如何串联与落地现在让我们把这些模块拼装起来形成一个有血有肉的“端到端能力”项目描述。这部分的重点是讲清楚数据流、技术选型和踩过的坑。4.1 系统架构与数据流一个清晰的架构图胜过千言万语面试时可以画在白板上。核心数据流如下用户请求抵达LLM网关。网关进行认证、限流后将请求路由给后端的AI应用例如一个RAG问答应用。RAG应用接收到用户问题首先向LLM-Wiki向量数据库发起检索获取相关上下文。将“问题上下文”组装成提示词通过LLM网关再次调用选定的大语言模型。将模型生成的结果返回给用户。同时MCP Server持续运行将“RAG问答”作为一个工具暴露出去。Claude Desktop等客户端可以通过该协议直接调用此工具。基于核心能力封装的Skills提供给业务方直接使用。4.2 技术栈选型思考解释你的每一个技术选择能体现你的决策能力。网关层为什么用Spring Cloud Gateway而不是Nginx可能是因为你需要更灵活的Java生态插件来实现复杂的鉴权逻辑。为什么用FastAPI可能是因为它异步性能好与Python AI栈集成更顺滑。向量数据库为什么选Milvus而不是Pinecone或Qdrant可能是出于对开源可控、性能以及和现有技术栈如Java的LangChain4j集成的考虑。RAG框架为什么用LangChain/LlamaIndex它们提供了丰富的文本加载、分块、检索链模板能快速搭建原型。但你也需要指出它们的缺点比如在复杂生产流程中可能显得笨重有时需要自己实现更精细的控制逻辑。MCP实现目前社区资源如何你是完全自研还是基于某个开源SDK这体现了你的技术探索和整合能力。4.3 核心挑战与解决方案这是面试的精华部分证明你不仅做过还思考过、解决过问题。挑战一检索精度不高现象经常召回不相关的片段导致答案胡言乱语。排查与解决检查文本分块发现固定长度分块切断了完整的句子或段落。改为尝试按标点、按章节语义分块。丰富查询对原始用户问题进行关键词扩展或重写使用小模型让查询意图更明确。引入重排在向量检索后加入一个轻量级的交叉编码器模型对候选片段进行精排提升Top1的相关性。挑战二网关层超时与熔断现象高峰期部分请求响应慢甚至拖垮整个服务。排查与解决监控发现特定模型API如GPT-4的响应时间波动大。实施策略在网关注册每个模型服务的健康状态配置熔断器如Sentinel。当某个模型错误率或慢调用比例超过阈值暂时熔断快速失败并降级到使用更快的模型如GPT-3.5-Turbo或返回缓存结果。挑战三MCP工具的描述与调试现象Claude无法正确理解或调用我们提供的工具。排查与解决工具描述发现工具的名称、描述、参数schema描述不够清晰自然。参照优秀示例用LLM优化了工具描述使其更符合AI的理解习惯。错误处理在MCP Server端完善了错误码和友好错误信息返回帮助客户端Claude向用户解释问题。5. 写在简历上讲在面试中最后我们来落地到最初的问题如何写到简历上以及面试时如何展开。5.1 简历项目描述示例项目名称企业级AI能力中台与知识库系统AI Infra核心职责设计并主导开发了统一LLM网关集成多源模型实现流量治理、成本监控与熔断降级使模型服务可用性达到99.9%。构建了基于Milvus与LangChain的RAG知识库LLM-Wiki通过优化文本分块、混合检索与重排策略将内部知识问答准确率提升至85%。遵循MCP协议将RAG问答等核心能力封装为标准化工具并开发了面向客服、研发的即用型Skills降低了业务方使用AI的门槛。建立了从数据接入、向量化、服务化到应用封装的端到端AI能力交付流程。5.2 面试叙述框架当面试官让你介绍这个项目时可以按以下逻辑展开定基调“这是一个关于AI工程化、而不仅仅是模型调用的项目目标是构建公司内部可复用的AI基础设施。”讲动机“我们最初面临模型调用混乱、知识分散、能力无法复用的痛点所以决定从网关治理、知识整合和能力标准化三个维度系统性地解决。”拆模块“首先网关解决了‘管’的问题……”展开1.1和4.3的挑战二。“其次RAG和LLM-Wiki解决了‘知’的问题……”展开2.1和4.3的挑战一。“最后MCP和Skills解决了‘用’的问题……”展开3.1 3.2和4.3的挑战三。谈成果与度量“最终我们将内部AI需求的响应效率提升了X倍问答准确率达到了Y并支撑了Z个业务场景的接入。”反思与展望“过程中我们意识到评估体系、数据质量治理比算法本身更重要。未来计划在知识图谱融合、Agent工作流编排上做进一步探索。”通过这样一个有层次、有细节、有思考的叙述你展示的就不再是几个工具的使用技能而是一个工程师构建复杂系统、解决实际问题的完整能力。这正是当前AI应用从demo走向生产环境时最被需要和看重的价值。