AI 与 Agent 与 Data 这三个词放在一起看起来像三条独立路线先学模型再学智能体最后学数据。实际做了几轮项目后你会发现它们本质上是同一件事的三个面。模型负责理解和生成Agent 负责把理解和生成变成可执行的动作Data 决定这些动作有没有依据、有没有效果、能不能持续优化。这篇文章适合三类人准备转 AI 应用岗位的开发者已经在做传统后端或数据处理想往智能体方向靠的人以及面试前需要把零散知识整理成答题体系的求职者。文章不会只列学习资源也不会只给一份面试题清单而是把“学习顺序、项目节奏、面试答法、常见坑点”放在一起按我实际带人和被问时最常走的路径拆一遍。1. 先搞清楚 AI、Agent、Data 分别解决什么问题很多人学不下去不是因为内容难而是因为没分清这三条线各自的位置。一旦混着学就会陷入“既想搞懂模型原理又想马上写 Agent还想把数据管道搭好”的死循环。1.1 大模型解决的是“理解与生成”不是“办事”大模型的核心能力是给定一段输入生成一段合理输出。它能写摘要、能翻译、能补全代码、能给你解释一个概念但这些都只是“生成”。模型本身不会主动去查天气、不会调用接口、不会在任务做到一半时发现自己缺参数然后自动补上。它更像一个能力很强但不会主动行动的人。理解到这一点很重要。很多新手拿到一个需求第一反应是“我把它写成 Prompt 丢给大模型”。写 Prompt 确实能解决一部分问题但只要任务涉及多个步骤、需要外部数据、需要判断中间结果Prompt 就不够用了。1.2 Agent 解决的是“目标拆分、工具调用和自主执行”Agent 做的事是把一个大目标拆成若干小步骤每个步骤调用对应的工具然后根据中间结果决定下一步干什么。它改变的是工作方式从“一次性生成”变成“循环执行”。举例来说如果让你做一个“自动整理 PDF 发票并生成报销单”的小工具不用 Agent 的做法是你写脚本扫描 PDF调用 OCR再调大模型提取字段最后写死逻辑填进 Excel。用 Agent 的做法是告诉 Agent 目标“把这些 PDF 变成报销单”它自己拆出“读取文件、识别类型、提取金额、检查缺失项、生成表格”这几步每一步调用对应工具遇到识别失败还会尝试换一种方式重试。Agent 的价值不在单个模型能力而在编排能力。它需要你思考什么时候该让模型做判断什么时候该走确定性代码什么时候该让模型自己决定调用哪个工具。1.3 Data 解决的是“Agent 的知识来源与效果验证”Data 这条线最容易被忽略但它恰恰是 Agent 能不能从玩具变成生产力的关键。Data 在 AI Agent 项目里至少承担四个角色知识来源私有知识库、企业文档、产品说明书通过 RAG 方式注入模型。上下文记忆对话历史、用户偏好、任务状态需要存储和读取。评测依据你拿什么数据来验证 Agent 回答正确、步骤合理、成本可控。监控反馈线上日志、用户反馈、失败样本都是后续优化的数据燃料。如果你的 Agent 只会聊通用常识那不需要 Data一旦要处理企业真实业务80% 的时间和难点都会落在数据清洗、分块、索引、召回评估、失败样本分析上。2. 学习路线从基础能力到 Agent 项目落地的五个阶段下面这条路线不是唯一答案但比较适合从开发背景转过来的节奏。整体原则是先把模型当工具调通再研究怎么让模型在流程里工作最后用数据保证流程稳定。2.1 第一阶段补齐大模型调用能力与基础原理这个阶段不用死磕模型训练。你需要能回答几个核心问题大模型为什么能生成回答Transformer 的注意力机制大概在做什么。Token 是什么为什么不同模型的上下文窗口会限制输入长度。温度和 top_p 参数会如何影响输出。什么是 system prompt、user prompt、assistant message它们分别控制什么。实操上先选一个主流大模型 API 跑通最简单的调用。不管选哪家关键是理解请求结构和返回结构模型名称、消息列表、参数、最大输出长度、返回内容字段。不要一上来就套封装好的 SDK先看原生请求更容易理解机制。这个阶段的环境准备以简单为主。不需要自建 GPU 服务器用云端 API 就能学。需要准备的东西是 Python 环境、API Key、一个能跑 Jupyter Notebook 的编辑器以及基本的网络请求能力。2.2 第二阶段掌握 Prompt、RAG 和上下文管理Prompt 工程不是玄学它是一套控制模型行为的方法。至少要掌握角色设定给模型定义身份和回答边界。示例驱动用 few-shot 示例让模型模仿格式。步骤指令把复杂任务拆成步骤让模型按步骤执行。输出约束要求模型输出 JSON并约定字段。自我纠错指令让模型检查自己的结果是否满足条件。RAG 是这一阶段的重点。RAG 的完整流程如下准备文档清洗 PDF、Word、Markdown。分块按章节或固定长度切分文本。嵌入用向量模型把文本块转成向量。存储写入向量数据库。召回用户提问时检索最相关的若干块。生成把检索结果和用户问题一起交给大模型。很多人流程能跑通但效果不稳定。常见原因是分块粒度不对、嵌入模型选得随意、召回数量拍脑袋。这个阶段不要急着追新框架先用一个最小链路跑通再逐段调优。2.3 第三阶段Agent 核心机制与框架Agent 的四个核心机制是必须掌握的规划Planning把目标拆解成步骤包括计划生成和动态调整。记忆Memory短期记忆存当前任务上下文长期记忆存历史偏好和知识。工具Tools将外部 API、代码函数、数据库操作封装成模型可调用的接口。反思Reflection让模型分析自己哪里做错并修正下一步动作。推荐的学习顺序是从最简单的 ReAct 模式开始。ReAct 的思想是思考Thought→ 行动Action→ 观察Observation→ 再思考。先手工实现一遍再用框架改造。框架这一块可以看 LangChain、LlamaIndex、AutoGen 或 Spring AI。但注意框架是方便工程化的工具不是 Agent 本身。如果你连“模型如何调函数”这件事都没理解直接套框架会特别痛苦。2.4 第四阶段Data 工程与评估体系Agent 跑起来只是开始。真正让它稳定的是数据工程构建知识库数据管道采集、清洗、去重、分块、向量化、增量更新。构建评测数据集每个场景准备 50 到 100 条问答对标注标准答案。建立评估指标回答是否正确、是否引用知识库、是否拒绝不知道的问题、成本是否可控。失败样本回归每次修改后用同一批失败样本做回归测试。我见过太多项目把 90% 时间花在“让 Agent 跑起来”留给评测的时间只有半天。结果演示时很惊艳一到真实数据就开始胡说。数据评测必须从一开始就建立哪怕第一版很粗糙。2.5 第五阶段项目实战与简历项目设计项目选择不要太大。一个可以在一到两周完成、又能讲清楚数据与 Agent 关系的小项目比一个空壳大项目有价值。推荐方向企业文档问答助手用 RAG 回答 HR 政策、产品知识。数据分析助手让 Agent 根据用户问题写 SQL、执行查询、解释结果。运营周报自动生成读取业务数据生成周报初稿。智能工单处理判断工单类型、提取关键字段、给出处理建议。判断项目好坏有三个标准有没有真实数据有没有评测方式有没有失败案例。只讲“做了个 Agent 能回答问题”的项目在面试里撑不过两轮追问。3. 三条技术主线的上手实验路径与演示案例这里给出一套可以直接跟着做的实验路径从最简单的 API 调用开始逐步扩展到 RAG 和 Agent。你不需要一次跑完可以先选一条线跑通。3.1 跑通一个简单的大模型 API 调用先写一个最小请求确认环境、密钥、网络都没问题。示例结构如下from openai import OpenAI client OpenAI( api_key你的密钥, base_url服务地址 ) resp client.chat.completions.create( model你的模型名称, messages[ {role: system, content: 你是一个短视频脚本助手。}, {role: user, content: 帮我写一段介绍 AI 视频工具的开头。} ], temperature0.7, max_tokens500 ) print(resp.choices[0].message.content)这段代码的关键不是跑通而是理解几个点api_key 和 base_url 的来源与正确性。messages 里的 system 消息控制风格边界user 消息是用户输入。temperature 值越高回答越自由但可复现性越差。max_tokens 限制输出长度避免一次返回过长。如果报错先按这个顺序排查密钥是否有效、base_url 是否正确、模型名称是否存在、请求字段是否多传了不支持的参数、本地网络是否正常。不要一上来就怀疑代码逻辑这类调用的报错大多是配置问题。3.2 RAG 问答 Demo从一篇本地文档开始给自己准备一篇 Markdown 或 PDF 文档先不分块直接用整篇文档做检索是不现实的原因在于上下文可能超长。建议按 300 到 500 字分块块与块之间加少量重叠避免语义被切断。简化流程如下# 1. 读取文档 # 2. 按长度分块 # 3. 用嵌入模型计算向量 # 4. 存到向量数据库 # 5. 检索相似块 # 6. 拼到 Prompt 让模型回答RAG 效果的坑一般出现在三处文档本身格式乱表格、扫描件、双栏 PDF 解析后内容错位。分块太大导致检索噪声多太小导致信息不完整。嵌入模型和业务语言不匹配。第一个 Demo 不要追求高分。先把流程跑通打印出每一步的输入输出特别是“检索到了哪些块”。你会发现很多回答不准确的原因不是模型不行而是根本没召回对内容。3.3 Agent 工具调用 Demo让模型学会调函数Agent 和普通问答的关键差异是工具调用。下面是一个常见实现结构def get_weather(city: str) - str: # 返回天气信息 return f{city} 今天晴25°C tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city] } } } ]模型本身不执行函数。它做的只是根据用户问题输出一个“应该调用 get_weather参数 city 等于 北京”的结构。真正执行函数的是你的代码执行完再把结果作为消息回传给模型模型才能继续回答用户。所以 Agent 开发里最容易踩的坑就是以为模型“会自己调用工具”。实际上工具调用是模型输出和你的代码逻辑相互配合的结果。你要负责定义函数模型负责决定什么时候调用、怎么填参数你的运行时负责真正执行。先手工实现一轮“接收模型工具调用 → 执行 → 回传结果”理解了这套流程再去看框架里的 Tool 注册和 Agent 循环就会清晰很多。4. 典型面试问题分析与答题思路AI Agent 相关岗位的面试通常不是只问算法而是混合考察基础理解、工程能力、项目深度和系统设计。下面按高频问题分类拆解。4.1 基础问题模型原理、Prompt 与上下文面试官常问的第一类问题是确认你对模型有基本认知。问题温度参数调高和调低有什么区别答法不要只说“高更随机低更确定”。更好的答法是补一句调低温度适合需要严格格式、稳定结果的场景比如抽取结构化数据调高温度适合创意写作但要接受结果可能不符合预期。问题什么是上下文窗口超长文本怎么处理答法可以分两步先解释上下文窗口是模型能同时处理的 Token 数量再说明超长文本要么截断、要么摘要、要么走 RAG 检索。如果只回答“输入超过限制就报错”会显得缺少工程意识。问题System Prompt 有什么用答法要点System Prompt 定义模型角色、输出约束、回答边界用户消息才是真正的任务输入。在实际项目里System Prompt 可以做成配置文件方便不同业务场景切换。4.2 Agent 核心问题规划、记忆、工具、反思Agent 方向的问题更注重机制设计和工程落地。问题Agent 和普通的大模型接口调用有什么区别答法建议抓住几个关键差异Agent 不是一次调用就结束而是多轮循环Agent 可以调用外部工具来弥补模型不了解的实时信息Agent 有记忆机制可以跨步骤保留状态。核心是自主性和工具使用能力。问题如果 Agent 执行业务操作怎么保证安全这个问题几乎必问。答法要具体限制工具权限只暴露必需要的接口。高风险操作加人工确认或二次验证。设置超时和最大调用次数防止无限循环。记录完整会话日志方便问题回溯。用沙箱或测试环境验证新工具。问题Agent 的“记忆”怎么实现答法要点分短期记忆和长期记忆。短期记忆可以放在本次会话上下文中就是不断把历史消息拼进 Prompt长期记忆需要外部存储比如把用户偏好或历史结论写入数据库在需要时检索回填。别把记忆理解成一个缓存变量它本质上是数据存取逻辑。问题如果 Agent 在中间某一环出错怎么办答法建议先说预防机制比如 Prompt 里要求模型输出结构化结果、工具调用时做强校验再说重试逻辑比如失败后让模型根据错误信息重新规划最后说兜底策略比如超过 N 次失败后转人工。面试官想听的是你有没有容错思维。4.3 RAG 与 Data 问题召回、评测、数据质量Data 相关问题的核心是看你会不会用数据方法解决模型效果问题。问题RAG 检索出来的内容不相关怎么办不要只答“换个向量模型试试”。更好的链条是先检查数据源和分块质量是否包含大量无关内容。再检查召回数量是否太少导致信息不全或太多导致噪声大。调重排序Rerank先粗召回再精排。最后调整给模型的 Prompt明确要求只根据上下文回答不要自行补脑。问题怎么评估一个 RAG 系统好不好答法要点至少包含四个维度。召回率看相关文档有没有被检索出来回答准确率看最终答案是不是正确引用率看模型是不是真的使用了检索内容拒绝率看遇到不知道的问题敢不敢说不知道。这些维度都需要一个标注好的测试数据集。问题Agent 上线后怎么持续优化答法要点把线上日志沉淀成数据资产。每天分析失败样本给失败样本分类比如“工具参数错误”“知识检索遗漏”“模型输出格式不合格”然后逐类修复。这是 Data 在 Agent 项目里的核心价值。4.4 项目经验问题如何证明 Agent 真的有效这类问题最容易暴露项目水分。问题介绍一下你做的 Agent 项目。一个比较好的结构是背景业务场景是什么之前怎么做的痛点是什么。方案用了什么模型几个 Agent哪些工具为什么这样设计。数据知识库来自哪里评测集怎么构建测试样本多少。结果成功率多少耗时多少成本多少比之前好在哪里。失败分析哪些问题还没解决你下一步打算怎么优化。问题你的 Agent 准确率多少如果说不出来就很被动。所以做项目时一定要自己评估一版数字哪怕样本只有几十条也能说明你有评估意识。同时说明样本规模小结果仅供参考。问题你项目里的 Agent 如果换一个业务场景还能用吗这道题考架构抽象能力。答法可以提工具逻辑与业务逻辑解耦、Prompt 做成配置、知识库通过 RAG 替换、评测集重新标注。如果能把这些说清楚会比单纯强调技术栈成熟更有说服力。4.5 系统设计问题生产环境中的 Agent 该怎么设计面试官如果认为你基础不错通常会出一个开放设计题。问题让你设计一个智能客服 Agent需要考虑哪些模块建议从四个层面回答入口层用户从哪里进怎么处理多轮对话。决策层Agent 如何判断是回答知识库问题、查询订单、还是转人工。工具层订单查询、退换货流程、物流接口怎么封装成工具。数据层知识库更新频率、用户历史、日志存储、评测机制。问题如果高并发进来Agent 服务会怎么崩答法不要太复杂。先答服务本身的请求队列和限流再说模型 API 的并发限制最后说缓存设计。一样的重复问题不要每次都打大模型可以让 Agent 先查缓存命中就直接返回。5. 实操避坑清单与资源分配建议这几条坑是我在带项目和学习群里反复看到的高频问题提前写出来能省很多时间。5.1 不要先把所有框架都学一遍最常见的拖延方式就是收集一堆框架教程。今天看 LangChain明天看 LlamaIndex后天看 AutoGen最后每个都只知道一点概念却没有一个项目能落地。更合理的做法是先用原生代码控制一个 Demo比如没有框架时如何调用模型、如何处理多轮消息、如何解析工具调用结果。走通一遍后再用框架重写你会更清楚哪些能力是框架节省的哪些问题框架也解决不了。5.2 不要跳过数据质量直接调模型如果你的 RAG 回答不准不要第一时间改 Prompt 或换模型。先看数据源和分块。很多时候是知识库里存在大量过时信息、格式混乱内容或重复文档模型想答对也难。数据质量问题是 Agent 项目里最隐蔽的资源黑洞。优先级应该是先让数据干净再优化检索最后才考虑调模型参数。5.3 不要只看成功案例训练日志和失败用例更重要很多人在项目报告里只写“能回答正确”的样例。面试时被问一句“哪些场景失败了”就答不上来。真正有价值的项目除了演示出来的成功案例还要有一份失败样本清单。我会额外建议每个项目从第一天开始建一个debug目录专门存放失败输出、错误日志、修复记录。它既是你的调试材料也是面试时最难得的差异化素材。5.4 不要一上来就上多 Agent 架构单 Agent 能解决的事不要拆成三个 Agent。多 Agent 看起来更“高级”但也意味着更复杂的协调机制、更多的模型调用次数、更高的成本、更难的调试链路。先做单 Agent把一个完整流程跑稳把工具调用、记忆、错误处理都做扎实。确认单 Agent 确实能力不够再考虑拆分工。这个原则能帮你避免 90% 的无意义复杂度。6. 从能演示走向能上线可观测、可控、可评估做完一个 Demo 项目之后如果想进一步冲高一点可以把重心放在“生产化”三个词上。这也是很多人从初级到进阶的分水岭。6.1 可观测性日志、链路追踪与成本统计Agent 是多步循环每个环节都可能出错。所以需要比普通接口更细的日志记录每一轮模型的输入消息和输出结果。记录工具调用的参数、返回值和耗时。记录每次记录的 token 消耗和请求成本。给每次任务生成一个 trace_id方便串联完整的会话链路。成本尤其值得关注。一个看似简单的 Agent 任务可能因为循环多次调用模型实际费用是单次问答的十倍。没有成本追踪项目很容易在上线后发现预算超标。6.2 可控性权限、超时、人工审批Agent 一旦能调工具就涉及权限控制问题。例如如果 Agent 能查数据库、发邮件、改订单风险等级会很高。安全建议默认最小权限只允许调业务必要的工具。写操作与读操作区分对待写操作最好人工确认。设置单次任务的最大步骤数、超时时间和重试次数。敏感接口增加二次审批机制通过后 Agent 才能执行。6.3 可评估性用 Data 思路做评测闭环到这一步Data 已经不是知识库那么简单而是整个 Agent 的评测与反馈体系。建议每两周更新一次评测集把线上新增的失败样本加入回归集。每次修改 Prompt、换模型、调召回参数都用同一批测试数据跑对比。用表格记录每次变体的准确率、拒答率、成本、耗时。有了这套数据闭环你的 Agent 就不再是一个“改一个参数不知道影响“的黑盒而是一个可以持续迭代的产品系统。7. 最后留给我自己的三条判断标准写到这里我想到刚接触 Agent 时最常犯的错总想找一个万能框架、一套万能 Prompt、一份万能面试题。后来发现真正稳定发挥的人靠的都是对几个基本机制的踏实理解。如果你现在准备入行或者准备面试我建议不要急着囤课程。先用一个小项目把这三个基本功打通一个能可靠调用的大模型接口、一套能检索和评估的 RAG 链路、一个能调用工具的 Agent 循环。这三件事跑通再配合一到两个真实业务场景的失败案例分析不管是做项目还是应对面试你都会有东西可讲。AI、Agent、Data 三个词看着很宽落到实际就是一串非常具体的问题我的数据从哪里来我的模型怎么根据数据回答问题我的 Agent 怎么根据答案采取行动我的评测怎么证明这一切有效。把这条链走通方向就不会乱。
AI、Agent与Data：从大模型调用到RAG与工具调用的学习路线
AI 与 Agent 与 Data 这三个词放在一起看起来像三条独立路线先学模型再学智能体最后学数据。实际做了几轮项目后你会发现它们本质上是同一件事的三个面。模型负责理解和生成Agent 负责把理解和生成变成可执行的动作Data 决定这些动作有没有依据、有没有效果、能不能持续优化。这篇文章适合三类人准备转 AI 应用岗位的开发者已经在做传统后端或数据处理想往智能体方向靠的人以及面试前需要把零散知识整理成答题体系的求职者。文章不会只列学习资源也不会只给一份面试题清单而是把“学习顺序、项目节奏、面试答法、常见坑点”放在一起按我实际带人和被问时最常走的路径拆一遍。1. 先搞清楚 AI、Agent、Data 分别解决什么问题很多人学不下去不是因为内容难而是因为没分清这三条线各自的位置。一旦混着学就会陷入“既想搞懂模型原理又想马上写 Agent还想把数据管道搭好”的死循环。1.1 大模型解决的是“理解与生成”不是“办事”大模型的核心能力是给定一段输入生成一段合理输出。它能写摘要、能翻译、能补全代码、能给你解释一个概念但这些都只是“生成”。模型本身不会主动去查天气、不会调用接口、不会在任务做到一半时发现自己缺参数然后自动补上。它更像一个能力很强但不会主动行动的人。理解到这一点很重要。很多新手拿到一个需求第一反应是“我把它写成 Prompt 丢给大模型”。写 Prompt 确实能解决一部分问题但只要任务涉及多个步骤、需要外部数据、需要判断中间结果Prompt 就不够用了。1.2 Agent 解决的是“目标拆分、工具调用和自主执行”Agent 做的事是把一个大目标拆成若干小步骤每个步骤调用对应的工具然后根据中间结果决定下一步干什么。它改变的是工作方式从“一次性生成”变成“循环执行”。举例来说如果让你做一个“自动整理 PDF 发票并生成报销单”的小工具不用 Agent 的做法是你写脚本扫描 PDF调用 OCR再调大模型提取字段最后写死逻辑填进 Excel。用 Agent 的做法是告诉 Agent 目标“把这些 PDF 变成报销单”它自己拆出“读取文件、识别类型、提取金额、检查缺失项、生成表格”这几步每一步调用对应工具遇到识别失败还会尝试换一种方式重试。Agent 的价值不在单个模型能力而在编排能力。它需要你思考什么时候该让模型做判断什么时候该走确定性代码什么时候该让模型自己决定调用哪个工具。1.3 Data 解决的是“Agent 的知识来源与效果验证”Data 这条线最容易被忽略但它恰恰是 Agent 能不能从玩具变成生产力的关键。Data 在 AI Agent 项目里至少承担四个角色知识来源私有知识库、企业文档、产品说明书通过 RAG 方式注入模型。上下文记忆对话历史、用户偏好、任务状态需要存储和读取。评测依据你拿什么数据来验证 Agent 回答正确、步骤合理、成本可控。监控反馈线上日志、用户反馈、失败样本都是后续优化的数据燃料。如果你的 Agent 只会聊通用常识那不需要 Data一旦要处理企业真实业务80% 的时间和难点都会落在数据清洗、分块、索引、召回评估、失败样本分析上。2. 学习路线从基础能力到 Agent 项目落地的五个阶段下面这条路线不是唯一答案但比较适合从开发背景转过来的节奏。整体原则是先把模型当工具调通再研究怎么让模型在流程里工作最后用数据保证流程稳定。2.1 第一阶段补齐大模型调用能力与基础原理这个阶段不用死磕模型训练。你需要能回答几个核心问题大模型为什么能生成回答Transformer 的注意力机制大概在做什么。Token 是什么为什么不同模型的上下文窗口会限制输入长度。温度和 top_p 参数会如何影响输出。什么是 system prompt、user prompt、assistant message它们分别控制什么。实操上先选一个主流大模型 API 跑通最简单的调用。不管选哪家关键是理解请求结构和返回结构模型名称、消息列表、参数、最大输出长度、返回内容字段。不要一上来就套封装好的 SDK先看原生请求更容易理解机制。这个阶段的环境准备以简单为主。不需要自建 GPU 服务器用云端 API 就能学。需要准备的东西是 Python 环境、API Key、一个能跑 Jupyter Notebook 的编辑器以及基本的网络请求能力。2.2 第二阶段掌握 Prompt、RAG 和上下文管理Prompt 工程不是玄学它是一套控制模型行为的方法。至少要掌握角色设定给模型定义身份和回答边界。示例驱动用 few-shot 示例让模型模仿格式。步骤指令把复杂任务拆成步骤让模型按步骤执行。输出约束要求模型输出 JSON并约定字段。自我纠错指令让模型检查自己的结果是否满足条件。RAG 是这一阶段的重点。RAG 的完整流程如下准备文档清洗 PDF、Word、Markdown。分块按章节或固定长度切分文本。嵌入用向量模型把文本块转成向量。存储写入向量数据库。召回用户提问时检索最相关的若干块。生成把检索结果和用户问题一起交给大模型。很多人流程能跑通但效果不稳定。常见原因是分块粒度不对、嵌入模型选得随意、召回数量拍脑袋。这个阶段不要急着追新框架先用一个最小链路跑通再逐段调优。2.3 第三阶段Agent 核心机制与框架Agent 的四个核心机制是必须掌握的规划Planning把目标拆解成步骤包括计划生成和动态调整。记忆Memory短期记忆存当前任务上下文长期记忆存历史偏好和知识。工具Tools将外部 API、代码函数、数据库操作封装成模型可调用的接口。反思Reflection让模型分析自己哪里做错并修正下一步动作。推荐的学习顺序是从最简单的 ReAct 模式开始。ReAct 的思想是思考Thought→ 行动Action→ 观察Observation→ 再思考。先手工实现一遍再用框架改造。框架这一块可以看 LangChain、LlamaIndex、AutoGen 或 Spring AI。但注意框架是方便工程化的工具不是 Agent 本身。如果你连“模型如何调函数”这件事都没理解直接套框架会特别痛苦。2.4 第四阶段Data 工程与评估体系Agent 跑起来只是开始。真正让它稳定的是数据工程构建知识库数据管道采集、清洗、去重、分块、向量化、增量更新。构建评测数据集每个场景准备 50 到 100 条问答对标注标准答案。建立评估指标回答是否正确、是否引用知识库、是否拒绝不知道的问题、成本是否可控。失败样本回归每次修改后用同一批失败样本做回归测试。我见过太多项目把 90% 时间花在“让 Agent 跑起来”留给评测的时间只有半天。结果演示时很惊艳一到真实数据就开始胡说。数据评测必须从一开始就建立哪怕第一版很粗糙。2.5 第五阶段项目实战与简历项目设计项目选择不要太大。一个可以在一到两周完成、又能讲清楚数据与 Agent 关系的小项目比一个空壳大项目有价值。推荐方向企业文档问答助手用 RAG 回答 HR 政策、产品知识。数据分析助手让 Agent 根据用户问题写 SQL、执行查询、解释结果。运营周报自动生成读取业务数据生成周报初稿。智能工单处理判断工单类型、提取关键字段、给出处理建议。判断项目好坏有三个标准有没有真实数据有没有评测方式有没有失败案例。只讲“做了个 Agent 能回答问题”的项目在面试里撑不过两轮追问。3. 三条技术主线的上手实验路径与演示案例这里给出一套可以直接跟着做的实验路径从最简单的 API 调用开始逐步扩展到 RAG 和 Agent。你不需要一次跑完可以先选一条线跑通。3.1 跑通一个简单的大模型 API 调用先写一个最小请求确认环境、密钥、网络都没问题。示例结构如下from openai import OpenAI client OpenAI( api_key你的密钥, base_url服务地址 ) resp client.chat.completions.create( model你的模型名称, messages[ {role: system, content: 你是一个短视频脚本助手。}, {role: user, content: 帮我写一段介绍 AI 视频工具的开头。} ], temperature0.7, max_tokens500 ) print(resp.choices[0].message.content)这段代码的关键不是跑通而是理解几个点api_key 和 base_url 的来源与正确性。messages 里的 system 消息控制风格边界user 消息是用户输入。temperature 值越高回答越自由但可复现性越差。max_tokens 限制输出长度避免一次返回过长。如果报错先按这个顺序排查密钥是否有效、base_url 是否正确、模型名称是否存在、请求字段是否多传了不支持的参数、本地网络是否正常。不要一上来就怀疑代码逻辑这类调用的报错大多是配置问题。3.2 RAG 问答 Demo从一篇本地文档开始给自己准备一篇 Markdown 或 PDF 文档先不分块直接用整篇文档做检索是不现实的原因在于上下文可能超长。建议按 300 到 500 字分块块与块之间加少量重叠避免语义被切断。简化流程如下# 1. 读取文档 # 2. 按长度分块 # 3. 用嵌入模型计算向量 # 4. 存到向量数据库 # 5. 检索相似块 # 6. 拼到 Prompt 让模型回答RAG 效果的坑一般出现在三处文档本身格式乱表格、扫描件、双栏 PDF 解析后内容错位。分块太大导致检索噪声多太小导致信息不完整。嵌入模型和业务语言不匹配。第一个 Demo 不要追求高分。先把流程跑通打印出每一步的输入输出特别是“检索到了哪些块”。你会发现很多回答不准确的原因不是模型不行而是根本没召回对内容。3.3 Agent 工具调用 Demo让模型学会调函数Agent 和普通问答的关键差异是工具调用。下面是一个常见实现结构def get_weather(city: str) - str: # 返回天气信息 return f{city} 今天晴25°C tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city] } } } ]模型本身不执行函数。它做的只是根据用户问题输出一个“应该调用 get_weather参数 city 等于 北京”的结构。真正执行函数的是你的代码执行完再把结果作为消息回传给模型模型才能继续回答用户。所以 Agent 开发里最容易踩的坑就是以为模型“会自己调用工具”。实际上工具调用是模型输出和你的代码逻辑相互配合的结果。你要负责定义函数模型负责决定什么时候调用、怎么填参数你的运行时负责真正执行。先手工实现一轮“接收模型工具调用 → 执行 → 回传结果”理解了这套流程再去看框架里的 Tool 注册和 Agent 循环就会清晰很多。4. 典型面试问题分析与答题思路AI Agent 相关岗位的面试通常不是只问算法而是混合考察基础理解、工程能力、项目深度和系统设计。下面按高频问题分类拆解。4.1 基础问题模型原理、Prompt 与上下文面试官常问的第一类问题是确认你对模型有基本认知。问题温度参数调高和调低有什么区别答法不要只说“高更随机低更确定”。更好的答法是补一句调低温度适合需要严格格式、稳定结果的场景比如抽取结构化数据调高温度适合创意写作但要接受结果可能不符合预期。问题什么是上下文窗口超长文本怎么处理答法可以分两步先解释上下文窗口是模型能同时处理的 Token 数量再说明超长文本要么截断、要么摘要、要么走 RAG 检索。如果只回答“输入超过限制就报错”会显得缺少工程意识。问题System Prompt 有什么用答法要点System Prompt 定义模型角色、输出约束、回答边界用户消息才是真正的任务输入。在实际项目里System Prompt 可以做成配置文件方便不同业务场景切换。4.2 Agent 核心问题规划、记忆、工具、反思Agent 方向的问题更注重机制设计和工程落地。问题Agent 和普通的大模型接口调用有什么区别答法建议抓住几个关键差异Agent 不是一次调用就结束而是多轮循环Agent 可以调用外部工具来弥补模型不了解的实时信息Agent 有记忆机制可以跨步骤保留状态。核心是自主性和工具使用能力。问题如果 Agent 执行业务操作怎么保证安全这个问题几乎必问。答法要具体限制工具权限只暴露必需要的接口。高风险操作加人工确认或二次验证。设置超时和最大调用次数防止无限循环。记录完整会话日志方便问题回溯。用沙箱或测试环境验证新工具。问题Agent 的“记忆”怎么实现答法要点分短期记忆和长期记忆。短期记忆可以放在本次会话上下文中就是不断把历史消息拼进 Prompt长期记忆需要外部存储比如把用户偏好或历史结论写入数据库在需要时检索回填。别把记忆理解成一个缓存变量它本质上是数据存取逻辑。问题如果 Agent 在中间某一环出错怎么办答法建议先说预防机制比如 Prompt 里要求模型输出结构化结果、工具调用时做强校验再说重试逻辑比如失败后让模型根据错误信息重新规划最后说兜底策略比如超过 N 次失败后转人工。面试官想听的是你有没有容错思维。4.3 RAG 与 Data 问题召回、评测、数据质量Data 相关问题的核心是看你会不会用数据方法解决模型效果问题。问题RAG 检索出来的内容不相关怎么办不要只答“换个向量模型试试”。更好的链条是先检查数据源和分块质量是否包含大量无关内容。再检查召回数量是否太少导致信息不全或太多导致噪声大。调重排序Rerank先粗召回再精排。最后调整给模型的 Prompt明确要求只根据上下文回答不要自行补脑。问题怎么评估一个 RAG 系统好不好答法要点至少包含四个维度。召回率看相关文档有没有被检索出来回答准确率看最终答案是不是正确引用率看模型是不是真的使用了检索内容拒绝率看遇到不知道的问题敢不敢说不知道。这些维度都需要一个标注好的测试数据集。问题Agent 上线后怎么持续优化答法要点把线上日志沉淀成数据资产。每天分析失败样本给失败样本分类比如“工具参数错误”“知识检索遗漏”“模型输出格式不合格”然后逐类修复。这是 Data 在 Agent 项目里的核心价值。4.4 项目经验问题如何证明 Agent 真的有效这类问题最容易暴露项目水分。问题介绍一下你做的 Agent 项目。一个比较好的结构是背景业务场景是什么之前怎么做的痛点是什么。方案用了什么模型几个 Agent哪些工具为什么这样设计。数据知识库来自哪里评测集怎么构建测试样本多少。结果成功率多少耗时多少成本多少比之前好在哪里。失败分析哪些问题还没解决你下一步打算怎么优化。问题你的 Agent 准确率多少如果说不出来就很被动。所以做项目时一定要自己评估一版数字哪怕样本只有几十条也能说明你有评估意识。同时说明样本规模小结果仅供参考。问题你项目里的 Agent 如果换一个业务场景还能用吗这道题考架构抽象能力。答法可以提工具逻辑与业务逻辑解耦、Prompt 做成配置、知识库通过 RAG 替换、评测集重新标注。如果能把这些说清楚会比单纯强调技术栈成熟更有说服力。4.5 系统设计问题生产环境中的 Agent 该怎么设计面试官如果认为你基础不错通常会出一个开放设计题。问题让你设计一个智能客服 Agent需要考虑哪些模块建议从四个层面回答入口层用户从哪里进怎么处理多轮对话。决策层Agent 如何判断是回答知识库问题、查询订单、还是转人工。工具层订单查询、退换货流程、物流接口怎么封装成工具。数据层知识库更新频率、用户历史、日志存储、评测机制。问题如果高并发进来Agent 服务会怎么崩答法不要太复杂。先答服务本身的请求队列和限流再说模型 API 的并发限制最后说缓存设计。一样的重复问题不要每次都打大模型可以让 Agent 先查缓存命中就直接返回。5. 实操避坑清单与资源分配建议这几条坑是我在带项目和学习群里反复看到的高频问题提前写出来能省很多时间。5.1 不要先把所有框架都学一遍最常见的拖延方式就是收集一堆框架教程。今天看 LangChain明天看 LlamaIndex后天看 AutoGen最后每个都只知道一点概念却没有一个项目能落地。更合理的做法是先用原生代码控制一个 Demo比如没有框架时如何调用模型、如何处理多轮消息、如何解析工具调用结果。走通一遍后再用框架重写你会更清楚哪些能力是框架节省的哪些问题框架也解决不了。5.2 不要跳过数据质量直接调模型如果你的 RAG 回答不准不要第一时间改 Prompt 或换模型。先看数据源和分块。很多时候是知识库里存在大量过时信息、格式混乱内容或重复文档模型想答对也难。数据质量问题是 Agent 项目里最隐蔽的资源黑洞。优先级应该是先让数据干净再优化检索最后才考虑调模型参数。5.3 不要只看成功案例训练日志和失败用例更重要很多人在项目报告里只写“能回答正确”的样例。面试时被问一句“哪些场景失败了”就答不上来。真正有价值的项目除了演示出来的成功案例还要有一份失败样本清单。我会额外建议每个项目从第一天开始建一个debug目录专门存放失败输出、错误日志、修复记录。它既是你的调试材料也是面试时最难得的差异化素材。5.4 不要一上来就上多 Agent 架构单 Agent 能解决的事不要拆成三个 Agent。多 Agent 看起来更“高级”但也意味着更复杂的协调机制、更多的模型调用次数、更高的成本、更难的调试链路。先做单 Agent把一个完整流程跑稳把工具调用、记忆、错误处理都做扎实。确认单 Agent 确实能力不够再考虑拆分工。这个原则能帮你避免 90% 的无意义复杂度。6. 从能演示走向能上线可观测、可控、可评估做完一个 Demo 项目之后如果想进一步冲高一点可以把重心放在“生产化”三个词上。这也是很多人从初级到进阶的分水岭。6.1 可观测性日志、链路追踪与成本统计Agent 是多步循环每个环节都可能出错。所以需要比普通接口更细的日志记录每一轮模型的输入消息和输出结果。记录工具调用的参数、返回值和耗时。记录每次记录的 token 消耗和请求成本。给每次任务生成一个 trace_id方便串联完整的会话链路。成本尤其值得关注。一个看似简单的 Agent 任务可能因为循环多次调用模型实际费用是单次问答的十倍。没有成本追踪项目很容易在上线后发现预算超标。6.2 可控性权限、超时、人工审批Agent 一旦能调工具就涉及权限控制问题。例如如果 Agent 能查数据库、发邮件、改订单风险等级会很高。安全建议默认最小权限只允许调业务必要的工具。写操作与读操作区分对待写操作最好人工确认。设置单次任务的最大步骤数、超时时间和重试次数。敏感接口增加二次审批机制通过后 Agent 才能执行。6.3 可评估性用 Data 思路做评测闭环到这一步Data 已经不是知识库那么简单而是整个 Agent 的评测与反馈体系。建议每两周更新一次评测集把线上新增的失败样本加入回归集。每次修改 Prompt、换模型、调召回参数都用同一批测试数据跑对比。用表格记录每次变体的准确率、拒答率、成本、耗时。有了这套数据闭环你的 Agent 就不再是一个“改一个参数不知道影响“的黑盒而是一个可以持续迭代的产品系统。7. 最后留给我自己的三条判断标准写到这里我想到刚接触 Agent 时最常犯的错总想找一个万能框架、一套万能 Prompt、一份万能面试题。后来发现真正稳定发挥的人靠的都是对几个基本机制的踏实理解。如果你现在准备入行或者准备面试我建议不要急着囤课程。先用一个小项目把这三个基本功打通一个能可靠调用的大模型接口、一套能检索和评估的 RAG 链路、一个能调用工具的 Agent 循环。这三件事跑通再配合一到两个真实业务场景的失败案例分析不管是做项目还是应对面试你都会有东西可讲。AI、Agent、Data 三个词看着很宽落到实际就是一串非常具体的问题我的数据从哪里来我的模型怎么根据数据回答问题我的 Agent 怎么根据答案采取行动我的评测怎么证明这一切有效。把这条链走通方向就不会乱。