AI、Agent、Data 这三个词大量出现在同一张学习路线图、同一个岗位 JD、同一场技术分享里很多人的第一反应是这会不会只是把三个热门方向拼在一起制造话题等你真正动手做一个 AI 应用就会明白它们并不是三条互不相关的赛道而是同一套系统的三个层次大模型提供能力Agent 负责把能力编排成可执行的任务Data 则是一切推理和决策的底座。只懂其中一个很容易出现“模型调通了但产品落不了地”“Agent 写好了但数据一换就废”的局面。这篇文章不打算再从“什么是大模型”这种入门概念讲起而是直接拆解两个更实际的问题第一如果要把 AI、Agent、Data 作为一条完整的学习路线来准备应该按什么顺序学、学到什么程度第二现在的面试到底会怎么考每类问题的考察点在哪怎么回答才算真正理解而不是背了一套话术。读完你会得到一套可以直接对照执行的知识清单以及一份能用于准备笔试和面试的典型问题分析框架。1. 为什么 AI、Agent、Data 总是被放在一起1.1 三个方向各自的边界先给三个方向做一个比较清晰的边界划分。AI这里更准确地说是大模型应用方向关注的是模型本身的能力和调用方式怎么给模型输入、怎么设计提示词、怎么让模型输出更稳定、怎么评估模型效果以及在 RAG 和微调之间做选择。这部分的核心问题是“模型怎么理解任务”。Agent 关注的是智能体工程模型输出结果之后系统如何理解用户的意图如何把任务拆成多个步骤如何调用外部工具如何记住上下文如何处理失败重试。这部分的核心问题是“模型怎么完成任务”。Data 关注的是 AI 应用的数据链路原始数据从哪里来如何清洗如何切分如何向量化如何存储和检索以及效果不好时怎么从数据层面排查优化。这部分的核心问题是“模型依据什么做决策”。1.2 从系统视角看它们是一条链路如果把一个 AI 应用完整地画出来它们的关系非常清楚用户输入请求后系统先把请求交给 Agent 层进行意图识别和任务规划Agent 决定需要哪些外部信息时会调用 Data 层的检索服务把相关的文档片段取回来这些片段连同用户的原始问题一起交给大模型生成最终回答回答完成后还可以把用户的反馈、错误的例子重新写回数据层形成数据闭环。这就是为什么现在的企业招聘更倾向于“全链路型”候选人。岗位 JD 里频繁出现的“熟练使用大模型 API”“熟悉 Agent 框架”“熟悉向量数据库”并不是三个独立要求而是同一个岗位在不同环节的技能切面。1.3 企业要的是能打通链路的人只看模型论文、只会调 API、只会写 SQL 的人在 AI 应用岗位面前都有明显的短板。真正被认可的开发者是能在模型效果不好时想到去优化数据是在 Agent 调用失败时能从工具返回里定位原因是在系统上线后能建立评测集持续迭代的人。所以本文的学习路线按“模型应用 → Agent 工程 → 数据链路”的顺序展开每一阶段都强调产出物。面试准备也按这个逻辑来先掌握底层概念再准备系统设计题最后用代码题验证工程能力。2. 核心概念先理清LLM、RAG、Agent、MCP、Data Pipeline在进入学习路线之前先把几个高频概念之间的关系说清楚。很多面试回答听起来混乱本质是没有搞清概念之间的层次。2.1 大模型与它的“外挂”方案LLM大语言模型是 AI 应用的核心推理引擎。它解决的问题是“给定一段文本模型根据训练时学到的知识生成一段新的文本”。但大模型有两个天然限制训练数据有截止时间且不掌握企业内部数据回答可能会一本正经地编造事实也就是幻觉。为了弥补这两个限制工程上出现了 RAG 和微调两种主流方案。RAG检索增强生成是指先从外部知识库中检索出与问题相关的内容再把检索结果连同问题一起交给大模型生成回答。它相当于给模型开卷考试让模型基于给定的参考资料回答而不是凭记忆硬编。微调则是在预训练模型的基础上用一批特定格式的数据继续训练让模型学会某种风格或某种领域知识。它改变的是模型本身的参数。两者并不互斥实际项目中经常组合使用。下面的表格可以帮你快速记住它们的差异对比维度RAG微调是否修改模型参数不修改修改知识更新成本替换知识库即可需要重新训练对算力的要求低较高适合场景知识库问答、实时资料引用固定输出格式、特定风格主要风险检索质量影响生成效果数据质量差会导致模型退化2.2 Agent 到底是什么Agent智能体这个词被用得太多反而容易混淆。工程上的 Agent通常由四个部分组成模型、规划、工具、记忆。模型负责推理规划负责把任务拆解成步骤工具负责让 Agent 能执行外部动作比如查天气、查数据库、调用 API记忆负责保存多轮对话或历史经验。判断一个系统是不是真正的 Agent有一个很简单的标准它是否具备动态规划和外部工具调用能力。如果只是通过 if-else 判断用户说了什么关键词再返回写死的答案那它只是一个规则系统不是 Agent。围绕工具调用有两个概念需要提前了解。Function Calling 是让模型输出一个结构化的函数调用指令而不是直接输出纯文本。例如用户问“北京明天多少度”模型会输出一个 JSON 结构表示要调用一个名叫 get_weather 的函数参数是城市和日期。系统收到这个结构后去执行真实代码再把结果交回模型生成最终回答。MCPModel Context Protocol则是为了解决工具接入规范问题而诞生的开放协议。在没有 MCP 之前每个 Agent 框架对接外部工具都要自行设计一套格式。引入 MCP 后工具可以被标准化地描述和调用模型应用与外部系统之间有了统一的接口约束。面试时只要能把 Function Calling 和 MCP 的关系说清楚就能体现出对 Agent 工程现状的理解。2.3 Data 在 AI 应用中的角色Data 不是单纯指数据库。在 AI 应用里它是一条完整的数据管道数据采集、数据清洗、内容切分、向量化、向量存储、检索、重排、评测回流。有一个常见的误区是做 RAG 就是“把文档塞进向量数据库然后查一下”。实际上文档切分方式会影响检索质量Embedding 模型选择会影响相似度计算的准确性检索策略是取 Top-3 还是 Top-10 会影响生成质量甚至原始文档里有没有目录、表格、扫描件都会直接影响最终效果。Data 层是整个系统里最容易出现隐性瓶颈的地方。2.4 三者的关系总结整个技术栈可以按“数据底座 → 模型能力 → Agent 编排 → 上层应用”来理解数据层负责提供事实依据解决“模型不知道”的问题。模型层负责语义理解和内容生成解决“模型怎么思考”的问题。Agent 层负责连接模型、工具、数据和用户解决“任务怎么完成”的问题。面试中如果遇到综合性场景题先按这个层次拆解回答会清晰很多。3. 学习路线设计三个阶段逐步深入下面这套路线更适合有 Python 基础、没做过完整 AI 应用开发的开发者。三个阶段不是并列关系而是递进关系先会用模型再会编排模型最后会从数据层面优化整个系统。3.1 第一阶段大模型应用基础学习模块关键技能建议产出物Python 基础文件读写、异步请求、数据处理能写脚本处理文本大模型 API 调用对话补全、Embedding、参数控制一个能指定温度等参数的对话脚本Prompt 工程角色设定、思维链、少样本示例一个稳定输出的提示词模板模型评测人工评测、规则评测、简单评测集一段能批量测试回答质量的脚本这个阶段的目标是建立对模型能力的直觉。你需要亲手试出来同一个问题加上不同的系统提示词输出会差多少temperature 从 0 调到 0.7回答风格和稳定度会发生什么变化同样是输入客服场景输出格式怎么用 JSON 约束最稳定。很多开发者跳过了这个阶段直接去学 Agent 框架结果框架里的每个概念都见过出了问题却不知道是模型理解不到位还是框架配置有问题。先回到模型层积累经验后面会省很多时间。3.2 第二阶段Agent 工程化学习模块关键技能建议产出物Function Calling工具定义、参数提取、结果回填一个能调用真实函数的 AgentAgent 框架理解 Workflow 与 Agent 的区别一个带工具的客服问答 Agent记忆机制短期记忆、长期记忆支持多轮上下文的对话 Demo异常处理超时、重试、兜底回答对工具调用失败做降级处理此阶段最容易踩的坑是直接套用框架而不理解内部机制。LangChain、Spring AI 这类框架把 Agent 的开发难度降低了很多但你必须知道一个 Agent 请求在框架内部经历了哪几步用户输入进入后模型先判断是否需要调用工具如果需要框架会把工具定义传给模型模型返回结构化的调用参数框架执行工具后把结果作为新消息再次交给模型模型基于工具结果生成最终回答。整个链路并不神秘理解了它你排查问题的速度会大幅提升。3.3 第三阶段Data 与 RAG 深度融合学习模块关键技能建议产出物数据处理与清洗PDF/Word/HTML 解析、去重、格式归一一个文档清洗脚本文本切分按结构切分、按语义切分能处理长文档的切分模块向量化与存储Embedding 模型选择、向量数据库读写一个写入向量库的索引脚本检索优化混合检索、重排序、Top-K 调整一个可对比效果的检索 Demo评测回流构建评测集、记录错误样本一个简单的 RAG 效果评估脚本到了这个阶段你要围绕一个真实场景做端到端项目。假设你要做一个企业知识库问答系统流程就是拿一批真实的规章制度文档清洗后按章节切分向量化写入向量数据库用户提问后先检索相关片段再送大模型生成回答把常见的错误回答收集起来分析是检索没召回、还是回答偏离了原文再针对性优化。一个能跑通、能评估、能说清取舍的 RAG 项目比简历上写三个“熟悉”更有说服力。4. 典型面试问题分析下面这些问题是近几年 AI 应用面试中出现频率比较高的类型。我会给出问题、考察点和回答思路但更重要的是理解回答背后的逻辑。4.1 AI 基础方向RAG 和微调怎么选考察点是否理解两种方案的本质区别是否知道各自的成本与风险。回答思路先给结论再解释原因最后给一个判断框架。比如可以这样回答“我会先看两个维度知识更新频率和输出一致性要求。如果系统依赖的资料经常变化比如管理制度、产品文档、实时政策我会优先选 RAG因为只要替换知识库内容不需要重新训练模型如果业务要求固定的输出风格、固定的术语体系比如客服话术、报告生成且样本量足够才考虑微调。实际项目里也会两者结合用 RAG 提供事实用微调约束风格。”这个回答展示了你在成本和场景之间做取舍的工程思维而不是单纯背定义。4.2 Agent 方向Agent 和传统流程引擎有什么区别考察点是否真正理解 Agent 的适用边界。回答思路核心区别在“流程是否预先写死”。传统工作流引擎比如状态机或规则引擎每一步做什么是由开发者在代码里确定的优点是可控、可预测缺点是应对开放问题时几乎写不完规则Agent 则把决策权交给模型让模型根据用户输入动态决定下一步调哪个工具优点是灵活缺点是可能输出错误规划。更好的回答会强调实际工程里不会让 Agent 完全自由发挥而是先设计好工作流骨架把安全边界之外的步骤用人工规则兜住。这体现的是工程稳健性。4.3 Agent 方向设计一个能查天气的 Agent怎么落地考察点Function Calling 流程、工具注册、结果回填。回答思路先说意图识别再说工具定义最后说结果生成。用户说“北京明天多少度”Agent 框架把工具列表发给模型模型判断需要调用 get_weather参数是 city北京、date明天框架执行真实天气接口拿到温度字段后把结果拼接成新的消息给模型模型生成“北京明天最高气温 18 摄氏度”。这个流程需要你能现场写出工具定义的 JSON Schema。下一节的 5.2 会给出可直接参考的代码。4.4 Agent 方向多个 Agent 协作时怎么避免死循环和任务失控考察点多智能体系统的工程思维。回答思路需要提到任务上限、超时机制、循环检测、消息持久化和人工介入。比如每个 Agent 的任务步骤设置最大次数超过就终止Agent 之间通过消息队列通信记录执行轨迹对于关键业务Agent 执行完可以进入人工审核节点。不要为了体现高级而把多 Agent 说成万能方案实际上很多需求用单 Agent 加工具就能解决。4.5 Data 方向向量检索结果不准确你会怎么排查考察点定位问题的链路思维。回答思路按“数据 → 切分 → 向量化 → 检索 → 重排 → 生成”逐层排查。先看原始文档是否清晰再看切分后的片段是否完整包含关键信息再看 Embedding 模型是否适合中文场景再看检索 Top-K 是否过小、是否需要混合检索最后看是否需要加粗排序模型对候选结果重新排序。最忌讳的回答是“换个更好的向量数据库试试”因为问题大概率不在数据库本身。4.6 Data 方向如何评估一个 RAG 系统的效果考察点是否具备评测意识。回答思路可以回答用一组真实问题作为评测集对每个问题标注标准答案和参考文档片段然后分别计算检索命中率和答案生成质量。检索层面看是否有正确答案的片段被召回生成层面看回答是否忠实于给定资料是否包含错误事实。“没有评测就没有优化”是一句在面试中非常加分的判断。你不需要说出复杂的评测框架只要能把评测思路讲清楚已经超过大部分候选人。4.7 综合场景题企业知识库问答系统的整体架构考察点系统设计能力。回答思路按“数据接入层 → 处理层 → 存储检索层 → Agent 编排层 → 应用层”拆解同时要关注数据安全和权限控制。数据接入层负责处理不同来源的文档包括 PDF、Word、网页处理层负责清洗、去重、切分存储检索层负责向量化写入、检索召回Agent 编排层负责理解用户意图、决定是否需要查库、生成回答应用层负责用户界面和权限管理。不同部门的数据应该有访问控制不能被未授权的人检索到。把这段话讲完整就是一个合格的系统设计回答。5. 三类代码题的解题演示面试手写题通常不会要求写一个完整系统而是考察你能不能跑通关键链路。下面给出三个可复制的示例。5.1 最小 RAG 检索链路# 文件路径examples/rag_pipeline.py # 说明演示文档切分 - 向量化 - 检索 - 生成的最小链路。 # 实际项目可替换为更完善的文本处理和向量库。 from sentence_transformers import SentenceTransformer import numpy as np # 1. 初始化 Embedding 模型真实项目中按资源情况选择模型版本 embedder SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) # 2. 准备文档片段 docs [ 公司的年假制度规定入职满一年后每年享有 5 天带薪年假。, 请假流程员工需要在 OA 系统提交申请经理审批通过后方可休假。, 加班补贴按照基本工资的 150% 计算法定节假日按 300% 计算。, ] doc_vectors embedder.encode(docs) def retrieve(question, top_k1): # 3. 将用户问题转为向量 question_vector embedder.encode([question]) # 4. 计算余弦相似度并返回最相似的文档 scores [] for doc_vector in doc_vectors: score np.dot(question_vector[0], doc_vector) / ( np.linalg.norm(question_vector[0]) * np.linalg.norm(doc_vector) ) scores.append(score) ranking np.argsort(scores)[::-1] return [docs[i] for i in ranking[:top_k]] # 5. 模拟检索结果 if __name__ __main__: question 我入职满一年了可以休几天假 context \n.join(retrieve(question, top_k1)) print(检索到的参考资料) print(context)说明这段代码的核心价值是展示了 RAG 的检索环节。实际项目中你要把doc_vectors换成向量数据库的写入和查询但要理解的原型逻辑是一致的。运行前需要安装依赖pip install sentence-transformers numpy运行命令python examples/rag_pipeline.py如果你本地网络无法直接下载 Embedding 模型可以切换为调用企业内网或云服务提供的向量化接口本质上都是输入文本、输出向量。5.2 Agent 工具定义与 Function Calling 演示{ type: function, function: { name: get_weather, description: 查询指定城市在指定日期的天气情况, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如北京 }, date: { type: string, description: 日期格式为 YYYY-MM-DD缺省时为今天 } }, required: [city] } } }说明这段 JSON 是 Agent 框架中常见的工具定义格式。模型看到这个描述后会在需要时输出类似下面的调用指令{ name: get_weather, arguments: { city: 北京, date: 2025-01-15 } }拿到这个结构后你的代码负责解析参数、调用真实天气 API、把返回结果拼成文本。可以这样验证流程# 伪造一次天气 API 返回验证 Agent 判断是否正确 python -c print(北京 2025-01-15 晴最高气温 5℃最低气温 -4℃)这一步验证的是“模型会不会输出正确参数”而不是让你真的去对接天气服务。面试时能现场写下工具定义并解释模型返回后如何回填已经说明你具备 Agent 开发的基本功。5.3 数据清洗与向量化入库脚本# 文件路径examples/build_index.py # 说明演示读取原始文档 - 清洗 - 切分 - 向量化 - 写入向量数据库的流程。 # 这里使用字典模拟向量数据库写入真实项目按所选数据库替换。 import re from sentence_transformers import SentenceTransformer embedder SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) def clean_text(text): # 去除多余空白字符去掉网页非法字符 text re.sub(r\s, , text) text text.strip() return text def split_docs(text, max_length200): # 简单按句号切分允许超过 max_length 时再合并 sentences re.split(r[。], text) chunks [] current for sentence in sentences: if not sentence: continue if len(current) len(sentence) max_length: current sentence 。 else: chunks.append(current) current sentence 。 if current: chunks.append(current) return chunks # 模拟一批原始文本 raw_docs [ 员工手册 第一章 考勤管理 员工每天 上下班需要打卡。, 迟到超过 30 分钟需要提交说明。 , ] for idx, raw in enumerate(raw_docs): text clean_text(raw) chunks split_docs(text) for cidx, chunk in enumerate(chunks): vector embedder.encode(chunk) # 真实项目db.insert(id, vector, metadata{text: chunk, source: fdoc-{idx}}) print(f写入分片 doc-{idx}-{cidx}: {chunk}向量维度 {len(vector)})说明真实项目中清洗和切分远比示例复杂但核心逻辑不变。你需要理解三点原始数据必须清洗切分长度过长会稀释语义过短会丢失上下文向量化后要连同原文和元数据一起存入向量数据库否则检索到向量后无法生成回答。6. 简历与项目经验怎么写面试官看过太多“熟悉 LangChain”“熟悉 RAG”之类的描述真正能区分候选人的是项目描述是否具体、是否有取舍、是否有量化结果。推荐按这个结构写项目经验项目背景一句话说清业务问题例如“公司内部文档检索效率低员工找不到制度文件”。你的角色是独立完成还是负责其中某个模块。技术方案不要堆名词要说明为什么选这个方案。比如“因为制度文档更新频繁选择 RAG 而非微调”。关键挑战写一两个真正卡住你的问题以及你是如何定位和解决的。比如“初期检索召回率低定位后发现是切分粒度太粗改成按章节切分后效果明显提升”。结果与验证用数据或事实说明效果。例如“建立 200 条评测集检索命中率从 62% 提升到 81%”。另一个关键点是区分“用过”和“做过”。看过文档、跑通过 Demo、上线过真实系统这三种状态在面试里的深度完全不同。宁可只写一个自己真正吃透的项目也不要罗列五个只跑过 Demo 的功能。7. 常见误区与避坑指南误区真实情况建议学完 Agent 框架就等于会 Agent 开发框架只解决了部分工程问题不理解内部链路仍然无法排查问题先手动跑通一个无框架的最小 AgentRAG 效果不好就换更大更强的模型很多问题出在数据切分、检索和重排环节先用评测集定位瓶颈再考虑换模型微调可以解决所有问题微调成本高、更新慢且数据质量问题会被放大优先 RAG只有风格类问题才考虑微调向量数据库是 RAG 的核心向量数据库只是存储检索工具前期的数据处理更影响效果把时间花在清洗、切分、评测上面试只是背八股现在更看重系统设计、链路排查和工程细节多做端到端项目并把踩坑过程讲清楚不需要懂 Data只专注 AgentAgent 调用数据是不可分割的环节至少掌握一种向量数据库和数据处理流程另一个隐蔽的坑是忽视数据权限和合规。做企业知识库时不同角色的员工能访问的文档范围不一样这需要在系统设计阶段就规划好否则上线后很容易出现越权检索。面试时主动提到权限设计会让面试官认为你真的考虑过生产环境问题。8. 后续学习与面试准备建议综合来看AI、Agent、Data 的组合并不神秘。它本质上是在考察你能不能把一个真实问题通过“数据 → 模型 → 智能体”的链路变成可用产品。真正的分水岭不在于你知道多少概念而在于你能不能把一个项目完整地、可验证地做出来。建议下一步按这样的节奏行动先花一到两周把第一阶段的大模型 API 和 Prompt 练习做完确认你能独立写出一个稳定的对话脚本再用两周到一个月做一个小型 Agent最好让它连接一个真实的外部工具并设计好失败降级之后把精力压到一个 RAG 知识库项目上重点记录检索效果和生成效果的数字变化。这套路线不一定需要报课才能完成网上有大量官方文档和开源代码可参考。关键是每一阶段都要产出可运行的东西并把踩过的坑写成笔记。面试前把常见问题按 S-T-A-R 结构过一遍场景、任务、行动、结果能够用自己的话讲清楚项目其实比背题更有用。建议先收藏这份清单再对照你当前的能力缺口从最薄弱的一块开始补。AI 应用开发还在快速变化但工程能力的基本功不会过时。学会了拆解问题、验证效果、排查链路你就不会被某一个框架的版本更新淘汰。