大模型应用开发走到今天单纯调用一次 API 已经解决不了真实业务问题。生产环境里最常见的 AI 工程岗位要求几乎都围绕三个关键词展开AI、Agent、Data。AI 指大模型本身的理解与生成能力Agent 指模型如何借助工具和记忆去完成任务Data 则决定模型回答的信息质量、知识边界和可评估程度。这篇文章把【AIxAgentxData专题课】的学习路线和典型面试问题做一次系统梳理适合正在转行 AI 应用开发、准备 Agent 相关岗位面试、或者想把手头 ChatBot 升级成可维护智能系统的工程师阅读。学习这类专题课最怕两件事一是跟着教程调通一个 Demo 就以为掌握了二是把精力全部放在追新框架上面试时却讲不清底层机制。这篇文章不会只罗列资源而是给出一条可执行的四阶段学习路线再用一个最小 Agent 闭环示例把模型、工具、数据串起来最后按模块拆解典型面试问题、答题结构和工程排查清单。1. 先把 AI、Agent、Data 放在同一张技术地图里1.1 AI 在这条路线里指的是什么在专题课语境里AI 主要指大语言模型及其周边的应用能力文本理解、代码生成、结构化输出、函数调用、多模态识别等。它解决的问题是“理解语言并生成合理内容”。但大模型有两个工程上绕不开的特性。第一它是概率模型同样的 Prompt 每次输出可能不同温度参数调高后差异更明显。第二它的输出格式不稳定让它返回 JSON 时偶尔会在中间夹解释文本。绝大多数 AI 工程问题本质都是围绕这两个特性做约束和兜底而不是期待模型“永远正确”。学习阶段至少需要掌握几个概念token 与上下文窗口的关系system prompt 与 user prompt 的分工temperature 和 top_p 对输出随机性的影响few-shot 示例的作用以及函数调用function calling / tool calling的基本原理。这些是后续理解 Agent 的基础。1.2 Agent 是从“回答问题”到“完成任务”的分水岭普通聊天机器人的工作模式是“用户提问 → 模型回答”模型不接触外部系统也没有行动能力。Agent 则把这个链路扩展成“用户给目标 → 模型拆解计划 → 调用工具 → 观察结果 → 继续推理 → 输出最终答案”。这里要区分两个层面。模型本身只是推理核心Agent 是包含模型、工具、记忆、循环控制在内的整个系统。所以面试时被问“Agent 是怎么工作的”正确回答方向不是“我用了某个框架”而是讲清楚感知、规划、行动、观察这四个环节如何循环。两种常见控制模式需要理解。ReAct 模式让模型交替进行推理和行动每一步先想“下一步要做什么、为什么”再调用工具把结果放回上下文继续推理。Plan-and-Execute 模式则先让模型生成完整计划再逐步执行执行中遇到错误再调整计划。前者灵活但 token 消耗大后者结构清晰但应对变化较弱实际项目经常混合使用。1.3 Data 在 Agent 系统里承担三重角色第一重角色是知识库。业务文档、FAQ、产品手册经过清洗、切片、向量化后存入向量数据库问答时先检索再让模型基于检索结果生成这就是 RAG。Data 在这里决定模型的知识边界知识库质量不高模型再强也白搭。第二重角色是记忆。Agent 的短期记忆是上下文窗口长期记忆则需要把历史对话摘要、用户偏好、任务状态写入外部存储需要时再检索回来。第三重角色是评估数据。没有评测集就无法回答“改了一个参数到底变好还是变坏”这个问题。专题课越到后面越强调评估因为可测量是工程化的前提。维度AIAgentData通俗解释会思考的模型会动手的模型系统模型的知识、记忆和考卷关键技术大模型 API、Prompt、函数调用规划、工具调用、记忆、多智能体协作采集、清洗、切片、向量化、检索、评测常见事故输出格式不稳定、幻觉死循环、乱调工具、权限失控检索不到、检索噪声大、评测失真2. 专题课学习路线四个阶段逐层加深2.1 阶段一模型 API、Prompt 与工具调用的基本功第一阶段的目标不是学会某个框架而是建立起“模型输出不可完全信任”的工程直觉。先用 Python 调通大模型 API写一个能完成多轮对话的脚本。然后练习 Prompt 设计把 system prompt 写清楚角色和约束用 few-shot 示例规定输出格式再尝试让模型以 JSON 格式返回结果。这时会发现一个典型问题模型偶尔会在 JSON 前后加说明文字于是需要学会在代码里做二次解析和兜底处理。这个阶段还应该理解函数调用。函数调用不是让模型真的执行代码而是让模型从预定义的工具列表里选出“应该调用哪一个”并生成符合参数 schema 的 JSON。模型返回的是调用意图真正执行的是业务代码这个边界必须分清楚。产出物建议是一个“输入问题 → 输出结构化 JSON”的命令行脚本。自测标准是换 20 个不同类型的问题统计 JSON 解析成功率而不是只看一两次运行效果。2.2 阶段二Agent 机制与框架先手写再引框架第二阶段最容易踩的坑是过早引入 LangChain、LlamaIndex、AutoGen、Spring AI 这类框架。框架把工具注册、记忆管理、模型路由都封装好了看起来效率很高但一旦面试官追问“你的 Agent 中间某一步卡住了怎么查”只会用框架的人往往答不上来。推荐顺序是先在几百行代码内手写一个最小 ReAct 循环模型生成决策、代码执行工具、结果回填上下文、循环直到输出最终答案。手写一遍之后对工具分发、终止条件、异常回传这些细节会有体感再去看框架源码或文档会容易理解它们为什么要设计这些抽象。框架学习要抓共性不要一个框架一个框架地背。所有 Agent 框架都会解决四件事模型怎么知道有哪些工具、工具返回值怎么塞回对话、上下文超长怎么办、多步循环怎么终止。把每个框架在这四个问题上的实现方式对比一下学习效率会高很多。Java 工程师还可以单独关注 Spring AI理解它如何把 Agent 能力嵌入 Spring 生态。2.3 阶段三Data 工程与 RAG 全链路RAG 是当前最容易出成果、也最容易暴露数据问题的方向。全链路包括数据采集、格式解析、清洗去重、分块、向量化、存储、检索、重排、组织上下文、生成回答。这个阶段要亲手做一遍完整链路并且记录每一项选择的效果。比如切片长度从 200 字调到 800 字检索命中率怎么变化加了重叠窗口后上下文冗余是否增加对问题做改写后再检索效果会不会更好。没有实验记录的学习等于没学。同时要建立评测意识。构造一份包含 50 到 100 条高质量问答对的数据集分成检索评测和生成评测两部分。检索评测看 TopK 命中率生成评测看回答是否完整覆盖问题要点、是否引用正确来源。这套评测集以后每次改动都要跑一遍防止“改好一个 case 弄坏一片”。2.4 阶段四综合项目与生产化打磨前三个阶段是技术能力第四阶段是工程能力。一个能上线的 Agent 系统除了核心链路还需要日志追踪、成本控制、异常处理、权限控制、安全防护和回滚机制。学习环境和生产环境的区别要重点区分。学习环境里 Agent 死循环最多损失几次 API 调用生产环境里可能产生线上资损、越权操作或敏感信息泄露。所以生产环境至少要加三类保护最大步数限制防止死循环工具执行前的参数与权限校验防止乱调完整的轨迹日志方便回溯问题。综合项目建议选一个自己熟悉的业务领域例如“内部知识库问答 Agent”或“售后服务工单 Agent”把数据接入、工具调用、人工接管、评估回归全部串起来。做完后整理成项目文档后面的面试就靠这个项目讲深度。阶段学习重点产出物自测问题一API、Prompt、函数调用稳定输出 JSON 的脚本换 20 个问题后解析成功率如何二ReAct 机制、Agent 框架手写最小 Agent 循环乱问问题时会死循环吗三数据清洗、切片、检索、评测一套 RAG 链路和评测集检索命中率、回答引用质量如何四日志、安全、成本、回滚一个可演示的综合项目线上出问题后能否快速定位3. 最小 Agent 闭环模型 工具 数据怎么协同3.1 选一个最小但完整的业务场景用“带 FAQ 知识库的客服 Agent”做示例。用户提出问题时Agent 先检索知识库如果需要创建工单再调用工单工具最后把结果整理成自然语言回复。这个场景覆盖了三要素数据来自 FAQ 文档Agent 负责规划和调用工具模型负责最终生成。代码是演示思路用的最小版本真实项目要把异常处理、权限校验和日志全部补上。3.2 数据准备先有可检索的知识RAG 的第一步是把原始文档转成可检索的片段。下面代码展示切片的基本思路按段落切分避免把一句话拆成两半超长段落再按句子边界截断。# data_pipeline.py 核心思路切片 简单重叠 def split_document(text, max_len300, overlap30): parts [] for para in text.split(\n\n): para para.strip() if not para: continue start 0 while start len(para): end start max_len if end len(para): cut para.rfind(。, start, end) if cut ! -1: end cut 1 parts.append(para[start:end]) start end - overlap return parts真实项目中切片完成后会调用 embedding 模型转成向量存入向量数据库。这里为了聚焦 Agent 主流程先用一个简单的文本重合度函数做检索原理是一样的给定一个查询返回最相关的知识片段。# retrieval.py 演示用的简单检索真实项目替换为向量检索 def retrieve_faq(question, chunks, top_k2): scored [] for item in chunks: score overlap_score(question, item[text]) scored.append((score, item[text])) scored.sort(keylambda x: x[0], reverseTrue) return [text for score, text in scored[:top_k]]overlap_score可以用字符交集比例实现也可以用 jieba 分词后的词重叠比例。这里的关键是理解“检索结果会被拼进 Prompt 交给模型”所以返回片段不宜过长否则会稀释模型注意力。3.3 核心循环让模型决定下一步动作Agent 主循环的核心是“模型决策 → 系统执行 → 结果回填 → 再次决策”。下面用伪代码演示这个循环llm_call表示调用大模型它返回两种结果之一一种是最终回答一种是工具调用意图。# agent_loop.py 最小 ReAct 循环 TOOLS { retrieve_faq: retrieve_faq, create_ticket: create_ticket, } def run_agent(user_query, max_steps5): context [{role: user, content: user_query}] for step in range(max_steps): decision llm_call( messagescontext, toolsTOOL_SCHEMAS, ) if decision[finish]: return decision[answer] tool_name decision[tool] arguments decision[arguments] try: result TOOLS[tool_name](**arguments) status ok except Exception as exc: result str(exc) status error print(fstep{step 1} tool{tool_name} status{status}) context.append({ role: tool, content: result, }) return 超过最大步数请人工接管TOOL_SCHEMAS是工具的描述列表告诉模型有哪些工具、参数是什么类型。llm_call在真实项目里对应具体 SDK 的函数调用接口。工具执行被 try except 包裹是为了把异常变成模型可以看到的文本模型可以在下一步修正参数或换一种处理方式。这个循环有三个设计点值得记住。第一工具执行永远由业务代码完成模型只是提出调用意图。第二工具执行结果以文本形式回填上下文相当于让模型“看到”行动后果。第三max_steps是硬保护任何情况下都不能漏掉否则模型可能无限循环。3.4 运行验证观察每一步决策和结果运行示例后正常输出应该类似下面的过程先检索知识库再决定是否创建工单最后给出最终回答step1 toolretrieve_faq statusok step2 toolcreate_ticket statusok 最终回答根据知识库退款需要提供订单号。我已经为你先生成一张退款咨询工单工单号 TK-2025-001客服会在 1 个工作日内处理。验证时不要只看最终答案要重点检查两点模型的每一步决策是否符合预期工具调用参数是否正确。如果发现模型跳过了检索直接回复说明知识库内容没有进入上下文如果工具参数乱填说明 schema 描述不够明确。还需要做失败验证。把工具改成会抛异常观察模型是否会读取错误文本并给出合理回应。如果模型对错误结果视而不见说明 Prompt 里的约束不够或者需要加上对工具返回状态的显式说明。3.5 最容易翻车的三个点第一个坑是把工具 schema 写得太复杂。参数名含糊、类型定义不完整模型生成的参数就会频繁出错。解决方法是让参数名贴近自然语言每个参数都写清楚示例值并在代码层面对参数做二次校验。第二个坑是漏掉终止条件。有些人只在 while 循环里靠“模型返回 finish”退出一旦模型连续输出工具调用意图就死循环API 费用暴涨。预防措施是同时设置最大步数和单次工具执行超时。第三个坑是让工具返回超长内容。检索结果动辄几千字直接塞回上下文后续推理会乱成本也高。应该在工具内部先截断或摘要只返回最必要的信息。4. 典型面试问题分模块拆解4.1 大模型与 Prompt 方向这一模块主要考察基本功高频问题有三个。“如何让模型稳定输出 JSON”答题时要分三层第一层是用结构化输出或函数调用机制从模型侧约束格式第二层是代码侧做校验解析失败时用正则提取、截断修复或重试第三层是兜底最终结果仍然解析失败就返回可读的降级文案。这样答能体现工程思维而不是停留在“我在 Prompt 里写了返回 JSON”。“temperature 调大有什么影响”要回答随机性增大、输出更多样适合创意写作检索问答和工具调用场景适合用较低值保持结果稳定。同时要说明这只影响生成阶段的采样策略不会改变模型知识本身更不能靠调大 temperature 来解决幻觉问题。“模型产生幻觉怎么办”合理的答法是把幻觉当成系统问题处理Prompt 约束模型只依据给定资料回答RAG 提供可追溯来源工具或数据库对关键事实做校验同时允许模型在不确定时回答“不知道”。不要把责任全部推给模型也不要用“我换了更强模型”这种没有信息量的回答。4.2 Agent 原理与架构方向“什么是 ReAct为什么有效”这是 Agent 方向必问题。要讲清全称是 Reasoning and Acting模型交替进行推理和行动先输出思考过程说明为什么这么做再调用工具工具结果回来后继续推理。它有效的关键是把思考过程暴露在上下文中让模型每一步都能基于最新信息修正方向而不是一次性生成答案。“Agent 和普通对话系统有什么区别”核心差异在于是否有行动能力和反馈回路。普通对话只有输入和输出Agent 多出工具调用和观察结果两个环节于是产生了新的工程问题工具怎么注册、调用权限怎么控制、循环怎么终止、失败怎么恢复。“Agent 记忆怎么做”可以把答案拆成两层短期记忆直接用上下文窗口控制重点是长度超长就用滑动窗口或摘要压缩长期记忆放外部存储需要时检索回填。面试官如果追问还可以补充任务状态记忆把进行到一半的流程持久化避免 Agent 重启后断掉。“多个工具之间怎么协调”回答方向是先让模型做路由根据用户意图选择工具复杂任务再引入规划层先生成步骤再逐步执行。关键点是给模型足够的工具描述和前置条件说明并在工具层做参数联动校验不能指望模型自己理解所有业务规则。4.3 RAG 与 Data 方向“为什么用 RAG 而不是微调”这是数据方向最常见的问题。回答要点业务知识会频繁更新RAG 只需更换知识库数据成本低、速度快RAG 可以返回来源引用可解释性强微调适合改变模型的风格、领域术语和行为规范不适合存放频繁变化的事实性知识。两者也能结合使用。“切片长度怎么选择”不要背一个固定数字。要说明切片长度取决于文档结构和问题粒度长文档用段落级切片更完整短问答用句子级更精准通常会在几百到一千 token 量级之间实验同时增加重叠窗口防止上下文被切断。最终选择要以评测集上的检索命中率为准。“检索结果不准怎么办”排查顺序是先确认是不是召回问题即正确答案根本没进 TopK再看是不是排序问题正确答案存在但排太靠后。召回问题可以从数据清洗、切片、embedding 模型、query 改写几个方向解决排序问题可以加 rerank 模型或元数据过滤。直接改 Prompt 是最常见的错误做法因为上下文里压根没有正确答案Prompt 写得再好也没用。“RAG 系统怎么评估”要区分配置阶段和上线阶段。配置阶段用 golden 问答对做离线评测分别看检索命中率和生成质量上线阶段通过日志和用户反馈回流真实问题持续扩充评测集。评测集是 RAG 系统的资产比单次调参重要得多。4.4 系统设计与工程化方向“设计一个客服 Agent”是综合题建议按五层答题数据层负责接入文档和用户信息问答层负责检索和生成动作层负责工具调用如创建工单、查询订单控制层负责会话状态、权限和人工接管运维层负责日志追踪、监控和评测回归。“延迟和成本怎么优化”从链路角度回答先做意图路由简单问题走轻量模型复杂问题走完整 Agent 链路对高频检索结果做缓存压缩上下文只保留必要信息和摘要工具执行尽量并行回答用流式输出改善体感。每项措施都要说明换来的代价比如缓存会降低时效性摘要可能丢失细节。“Agent 系统如何保障安全和合规”要点包括工具执行前做参数校验和权限校验防止 Agent 被诱导执行越权操作对敏感字段做脱敏日志中不记录明文关键信息限制工具可访问范围用最小权限原则在 Prompt 中防御注入攻击但不能只依赖 Prompt真正的防线在工具执行层。回答时如果能主动提到“需要审计日志出事可以回溯 Agent 每一步做什么”会明显加分。模块高频问题核心考点答题顺序大模型与 Prompt稳定输出 JSON、temperature、幻觉对模型不确定性的处理机制约束 → 代码校验 → 兜底方案Agent 原理ReAct、记忆、工具协调对循环控制的理解环节解释 → 代码结构 → 失败处理RAG 与 Data为什么 RAG、切片、评估对数据链路的掌握全链路 → 调参依据 → 评测方法系统设计客服 Agent、成本、安全综合工程能力分层设计 → 关键取舍 → 监控回滚5. 面试答题的结构、颗粒度与反例5.1 项目经历用 STAR 组织但要把“技术决策”讲出来STAR 本身不难难的是把技术决策讲出来。以“实现一个客服 Agent”为例不要只讲背景和结果要重点讲行动中的取舍。推荐这样组织背景是知识分散在多个文档人工回复效率低目标是做一个能回答问题并处理退款咨询的 Agent行动时先搭数据清洗和检索链路再手写 ReAct 循环最后加入最大步数和参数校验过程中发现切片过长导致检索噪声于是改成段落切片并加了标题元数据过滤结果是检索准确率提升Agent 死循环问题被兜底。这样回答既有结构又有技术深度。5.2 技术颗粒度会调 API 和会做系统是两种面试表现同样描述一个问题不同颗粒度的回答差别很大。低颗粒度的说法是“我用了向量数据库做 RAG效果挺好的”。面试官无法判断你到底做了什么。高颗粒度的说法是“我用文档段落做切片每段带来源标题存入向量数据库检索后先用分数阈值过滤再加一层 rerank最后把 Top2 片段拼进 Prompt我用 80 条 golden 问题评测命中率从 52% 提到 78%但对多轮指代仍然漏检”。这种回答暴露了真实的工程经验也自然引出后续深入问题。注意不要编造具体指标。面试官追问数据来源时编不下去反而扣分。可以说“我们内部做了抽样评测具体数字需要在环境里复测”这种稳妥表述。5.3 这三类回答最容易扣分第一类是名词党。把 Agent、RAG、多智能体、记忆网络全罗列一遍每个都说不深。面试官只要追问“ReAct 为什么有效”就会露馅。第二类是框架依赖党。所有问题都答“我们用的 LangChain 实现了”。框架是工具不是知识面试要讲机制而不是讲包名。第三类是甩锅党。出了任何问题都归因于“模型不行”“框架 bug”“数据太脏”。合理做法是承认不确定性同时给出定位思路和解决方案比如先看轨迹日志判断是检索问题还是决策问题。5.4 遇到不会的题如何展开排查思路面试不可能每个题都会关键是展示解决问题的路径。可以用“先拆解再假设再验证再兜底”来组织。例如被问“如果 Agent 连续生成重复工具调用你怎么排查”。可以这样答先看轨迹日志确认是在哪个步骤重复假设一模型上下文里工具结果没有正确回填导致它不断重试于是检查消息拼装逻辑假设二工具确实执行了但返回值没有状态标识模型误以为失败于是改进工具返回结构增加 success 字段如果仍然不行加最大步数和熔断让系统转人工。这个思路即使不完全正确也能证明你是有排查方法论的工程师。6. 常见坑、排查清单与下一步建议6.1 工程实践里反复出现的四个坑问题现象常见原因检查方式处理建议工具调用偶尔返回不了合法参数schema 复杂、参数名含义不清晰打印模型原始输出保留失败样本简化参数名加示例值代码层二次校验和重试Agent 陷入循环API 费用快速增长缺少最大步数或工具结果未正确回填查日志看是否出现重复工具名设置最大步数确保工具结果追加进上下文RAG 检索返回的内容与问题无关切片过大、embedding 不适合领域、没有重排单独打印检索 TopK 片段做检查调切片、加元数据过滤、加 rerank、改写 query评测集指标好但线上体验差评测问题和线上真实问题分布不一致对比日志里的真实问题与评测集定期从线上抽问题回流评测集做分布覆盖6.2 从现象倒推根因的排查清单排查 Agent 或 RAG 问题建议按以下顺序走不要上来就改 Prompt输入是否正确用户原始问题有没有被错误预处理例如乱码、截断、多余字符。数据是否就位知识库有没有更新新文档有没有完成切片和向量化。检索是否命中把检索结果打印出来确认正确答案是否进入 TopK。上下文是否完整工具返回结果是否真的追加到 messages还是只拼接了字符串。模型决策是否合理模型选择工具是否正确参数是否符合 schema。工具执行是否正确业务代码本身有没有报错返回值结构是否稳定。输出链路是否正常最终回答是否被后处理截断或格式转换破坏。监控是否覆盖线上有没有轨迹日志、token 用量统计和异常告警。这套清单的价值在于固定排查入口避免在“模型不行”这个结论上过早停住。绝大多数线上问题最后查出来都不是模型的问题而是数据没更新、参数没传对、日志没打全。6.3 给专题课学习者的几条可执行建议第一务必先手写一个一百行以内的 ReAct 循环再学框架。手写能建立对 Agent 四个环节的直觉框架只是把这个循环做得更工程化。第二用一份真实业务文档完成一次完整 RAG 实验并把每次切块和检索效果记录下来。真实文档会暴露格式混乱、重复内容、专有名词识别等问题这些才是工作的价值所在。第三从第一天就建立评测集。哪怕只有五十条问题也比没有任何验证标准强。后续所有优化都跑同一套评测集做回归防止改好一个坏一片。第四保留失败样本。无论是解析失败的 JSON、检索跑偏的 query还是工具参数错误都归集成文件。面试时能拿出真实失败案例和修复过程比背十个框架名更有说服力。第五关注经典文献和官方文档优于追新工具。ReAct、RAG 这几篇基础工作把核心机制讲得很清楚理解它们之后任何新框架在你眼里都只是这些机制的组合与封装。Java 方向可以结合 Spring AI 再补一套落地路径但同样要回到机制层面去理解。【AIxAgentxData专题课】的核心并不是三个独立知识点的拼接而是三者在真实系统中的协作方式。把模型能力当作推理核心用 Agent 结构赋予它行动能力用数据工程保证知识质量和可评估性才是这条学习路线真正要训练的能力。 大模型应用开发核心：AI Agent Data 学习路线与面试解析
大模型应用开发走到今天单纯调用一次 API 已经解决不了真实业务问题。生产环境里最常见的 AI 工程岗位要求几乎都围绕三个关键词展开AI、Agent、Data。AI 指大模型本身的理解与生成能力Agent 指模型如何借助工具和记忆去完成任务Data 则决定模型回答的信息质量、知识边界和可评估程度。这篇文章把【AIxAgentxData专题课】的学习路线和典型面试问题做一次系统梳理适合正在转行 AI 应用开发、准备 Agent 相关岗位面试、或者想把手头 ChatBot 升级成可维护智能系统的工程师阅读。学习这类专题课最怕两件事一是跟着教程调通一个 Demo 就以为掌握了二是把精力全部放在追新框架上面试时却讲不清底层机制。这篇文章不会只罗列资源而是给出一条可执行的四阶段学习路线再用一个最小 Agent 闭环示例把模型、工具、数据串起来最后按模块拆解典型面试问题、答题结构和工程排查清单。1. 先把 AI、Agent、Data 放在同一张技术地图里1.1 AI 在这条路线里指的是什么在专题课语境里AI 主要指大语言模型及其周边的应用能力文本理解、代码生成、结构化输出、函数调用、多模态识别等。它解决的问题是“理解语言并生成合理内容”。但大模型有两个工程上绕不开的特性。第一它是概率模型同样的 Prompt 每次输出可能不同温度参数调高后差异更明显。第二它的输出格式不稳定让它返回 JSON 时偶尔会在中间夹解释文本。绝大多数 AI 工程问题本质都是围绕这两个特性做约束和兜底而不是期待模型“永远正确”。学习阶段至少需要掌握几个概念token 与上下文窗口的关系system prompt 与 user prompt 的分工temperature 和 top_p 对输出随机性的影响few-shot 示例的作用以及函数调用function calling / tool calling的基本原理。这些是后续理解 Agent 的基础。1.2 Agent 是从“回答问题”到“完成任务”的分水岭普通聊天机器人的工作模式是“用户提问 → 模型回答”模型不接触外部系统也没有行动能力。Agent 则把这个链路扩展成“用户给目标 → 模型拆解计划 → 调用工具 → 观察结果 → 继续推理 → 输出最终答案”。这里要区分两个层面。模型本身只是推理核心Agent 是包含模型、工具、记忆、循环控制在内的整个系统。所以面试时被问“Agent 是怎么工作的”正确回答方向不是“我用了某个框架”而是讲清楚感知、规划、行动、观察这四个环节如何循环。两种常见控制模式需要理解。ReAct 模式让模型交替进行推理和行动每一步先想“下一步要做什么、为什么”再调用工具把结果放回上下文继续推理。Plan-and-Execute 模式则先让模型生成完整计划再逐步执行执行中遇到错误再调整计划。前者灵活但 token 消耗大后者结构清晰但应对变化较弱实际项目经常混合使用。1.3 Data 在 Agent 系统里承担三重角色第一重角色是知识库。业务文档、FAQ、产品手册经过清洗、切片、向量化后存入向量数据库问答时先检索再让模型基于检索结果生成这就是 RAG。Data 在这里决定模型的知识边界知识库质量不高模型再强也白搭。第二重角色是记忆。Agent 的短期记忆是上下文窗口长期记忆则需要把历史对话摘要、用户偏好、任务状态写入外部存储需要时再检索回来。第三重角色是评估数据。没有评测集就无法回答“改了一个参数到底变好还是变坏”这个问题。专题课越到后面越强调评估因为可测量是工程化的前提。维度AIAgentData通俗解释会思考的模型会动手的模型系统模型的知识、记忆和考卷关键技术大模型 API、Prompt、函数调用规划、工具调用、记忆、多智能体协作采集、清洗、切片、向量化、检索、评测常见事故输出格式不稳定、幻觉死循环、乱调工具、权限失控检索不到、检索噪声大、评测失真2. 专题课学习路线四个阶段逐层加深2.1 阶段一模型 API、Prompt 与工具调用的基本功第一阶段的目标不是学会某个框架而是建立起“模型输出不可完全信任”的工程直觉。先用 Python 调通大模型 API写一个能完成多轮对话的脚本。然后练习 Prompt 设计把 system prompt 写清楚角色和约束用 few-shot 示例规定输出格式再尝试让模型以 JSON 格式返回结果。这时会发现一个典型问题模型偶尔会在 JSON 前后加说明文字于是需要学会在代码里做二次解析和兜底处理。这个阶段还应该理解函数调用。函数调用不是让模型真的执行代码而是让模型从预定义的工具列表里选出“应该调用哪一个”并生成符合参数 schema 的 JSON。模型返回的是调用意图真正执行的是业务代码这个边界必须分清楚。产出物建议是一个“输入问题 → 输出结构化 JSON”的命令行脚本。自测标准是换 20 个不同类型的问题统计 JSON 解析成功率而不是只看一两次运行效果。2.2 阶段二Agent 机制与框架先手写再引框架第二阶段最容易踩的坑是过早引入 LangChain、LlamaIndex、AutoGen、Spring AI 这类框架。框架把工具注册、记忆管理、模型路由都封装好了看起来效率很高但一旦面试官追问“你的 Agent 中间某一步卡住了怎么查”只会用框架的人往往答不上来。推荐顺序是先在几百行代码内手写一个最小 ReAct 循环模型生成决策、代码执行工具、结果回填上下文、循环直到输出最终答案。手写一遍之后对工具分发、终止条件、异常回传这些细节会有体感再去看框架源码或文档会容易理解它们为什么要设计这些抽象。框架学习要抓共性不要一个框架一个框架地背。所有 Agent 框架都会解决四件事模型怎么知道有哪些工具、工具返回值怎么塞回对话、上下文超长怎么办、多步循环怎么终止。把每个框架在这四个问题上的实现方式对比一下学习效率会高很多。Java 工程师还可以单独关注 Spring AI理解它如何把 Agent 能力嵌入 Spring 生态。2.3 阶段三Data 工程与 RAG 全链路RAG 是当前最容易出成果、也最容易暴露数据问题的方向。全链路包括数据采集、格式解析、清洗去重、分块、向量化、存储、检索、重排、组织上下文、生成回答。这个阶段要亲手做一遍完整链路并且记录每一项选择的效果。比如切片长度从 200 字调到 800 字检索命中率怎么变化加了重叠窗口后上下文冗余是否增加对问题做改写后再检索效果会不会更好。没有实验记录的学习等于没学。同时要建立评测意识。构造一份包含 50 到 100 条高质量问答对的数据集分成检索评测和生成评测两部分。检索评测看 TopK 命中率生成评测看回答是否完整覆盖问题要点、是否引用正确来源。这套评测集以后每次改动都要跑一遍防止“改好一个 case 弄坏一片”。2.4 阶段四综合项目与生产化打磨前三个阶段是技术能力第四阶段是工程能力。一个能上线的 Agent 系统除了核心链路还需要日志追踪、成本控制、异常处理、权限控制、安全防护和回滚机制。学习环境和生产环境的区别要重点区分。学习环境里 Agent 死循环最多损失几次 API 调用生产环境里可能产生线上资损、越权操作或敏感信息泄露。所以生产环境至少要加三类保护最大步数限制防止死循环工具执行前的参数与权限校验防止乱调完整的轨迹日志方便回溯问题。综合项目建议选一个自己熟悉的业务领域例如“内部知识库问答 Agent”或“售后服务工单 Agent”把数据接入、工具调用、人工接管、评估回归全部串起来。做完后整理成项目文档后面的面试就靠这个项目讲深度。阶段学习重点产出物自测问题一API、Prompt、函数调用稳定输出 JSON 的脚本换 20 个问题后解析成功率如何二ReAct 机制、Agent 框架手写最小 Agent 循环乱问问题时会死循环吗三数据清洗、切片、检索、评测一套 RAG 链路和评测集检索命中率、回答引用质量如何四日志、安全、成本、回滚一个可演示的综合项目线上出问题后能否快速定位3. 最小 Agent 闭环模型 工具 数据怎么协同3.1 选一个最小但完整的业务场景用“带 FAQ 知识库的客服 Agent”做示例。用户提出问题时Agent 先检索知识库如果需要创建工单再调用工单工具最后把结果整理成自然语言回复。这个场景覆盖了三要素数据来自 FAQ 文档Agent 负责规划和调用工具模型负责最终生成。代码是演示思路用的最小版本真实项目要把异常处理、权限校验和日志全部补上。3.2 数据准备先有可检索的知识RAG 的第一步是把原始文档转成可检索的片段。下面代码展示切片的基本思路按段落切分避免把一句话拆成两半超长段落再按句子边界截断。# data_pipeline.py 核心思路切片 简单重叠 def split_document(text, max_len300, overlap30): parts [] for para in text.split(\n\n): para para.strip() if not para: continue start 0 while start len(para): end start max_len if end len(para): cut para.rfind(。, start, end) if cut ! -1: end cut 1 parts.append(para[start:end]) start end - overlap return parts真实项目中切片完成后会调用 embedding 模型转成向量存入向量数据库。这里为了聚焦 Agent 主流程先用一个简单的文本重合度函数做检索原理是一样的给定一个查询返回最相关的知识片段。# retrieval.py 演示用的简单检索真实项目替换为向量检索 def retrieve_faq(question, chunks, top_k2): scored [] for item in chunks: score overlap_score(question, item[text]) scored.append((score, item[text])) scored.sort(keylambda x: x[0], reverseTrue) return [text for score, text in scored[:top_k]]overlap_score可以用字符交集比例实现也可以用 jieba 分词后的词重叠比例。这里的关键是理解“检索结果会被拼进 Prompt 交给模型”所以返回片段不宜过长否则会稀释模型注意力。3.3 核心循环让模型决定下一步动作Agent 主循环的核心是“模型决策 → 系统执行 → 结果回填 → 再次决策”。下面用伪代码演示这个循环llm_call表示调用大模型它返回两种结果之一一种是最终回答一种是工具调用意图。# agent_loop.py 最小 ReAct 循环 TOOLS { retrieve_faq: retrieve_faq, create_ticket: create_ticket, } def run_agent(user_query, max_steps5): context [{role: user, content: user_query}] for step in range(max_steps): decision llm_call( messagescontext, toolsTOOL_SCHEMAS, ) if decision[finish]: return decision[answer] tool_name decision[tool] arguments decision[arguments] try: result TOOLS[tool_name](**arguments) status ok except Exception as exc: result str(exc) status error print(fstep{step 1} tool{tool_name} status{status}) context.append({ role: tool, content: result, }) return 超过最大步数请人工接管TOOL_SCHEMAS是工具的描述列表告诉模型有哪些工具、参数是什么类型。llm_call在真实项目里对应具体 SDK 的函数调用接口。工具执行被 try except 包裹是为了把异常变成模型可以看到的文本模型可以在下一步修正参数或换一种处理方式。这个循环有三个设计点值得记住。第一工具执行永远由业务代码完成模型只是提出调用意图。第二工具执行结果以文本形式回填上下文相当于让模型“看到”行动后果。第三max_steps是硬保护任何情况下都不能漏掉否则模型可能无限循环。3.4 运行验证观察每一步决策和结果运行示例后正常输出应该类似下面的过程先检索知识库再决定是否创建工单最后给出最终回答step1 toolretrieve_faq statusok step2 toolcreate_ticket statusok 最终回答根据知识库退款需要提供订单号。我已经为你先生成一张退款咨询工单工单号 TK-2025-001客服会在 1 个工作日内处理。验证时不要只看最终答案要重点检查两点模型的每一步决策是否符合预期工具调用参数是否正确。如果发现模型跳过了检索直接回复说明知识库内容没有进入上下文如果工具参数乱填说明 schema 描述不够明确。还需要做失败验证。把工具改成会抛异常观察模型是否会读取错误文本并给出合理回应。如果模型对错误结果视而不见说明 Prompt 里的约束不够或者需要加上对工具返回状态的显式说明。3.5 最容易翻车的三个点第一个坑是把工具 schema 写得太复杂。参数名含糊、类型定义不完整模型生成的参数就会频繁出错。解决方法是让参数名贴近自然语言每个参数都写清楚示例值并在代码层面对参数做二次校验。第二个坑是漏掉终止条件。有些人只在 while 循环里靠“模型返回 finish”退出一旦模型连续输出工具调用意图就死循环API 费用暴涨。预防措施是同时设置最大步数和单次工具执行超时。第三个坑是让工具返回超长内容。检索结果动辄几千字直接塞回上下文后续推理会乱成本也高。应该在工具内部先截断或摘要只返回最必要的信息。4. 典型面试问题分模块拆解4.1 大模型与 Prompt 方向这一模块主要考察基本功高频问题有三个。“如何让模型稳定输出 JSON”答题时要分三层第一层是用结构化输出或函数调用机制从模型侧约束格式第二层是代码侧做校验解析失败时用正则提取、截断修复或重试第三层是兜底最终结果仍然解析失败就返回可读的降级文案。这样答能体现工程思维而不是停留在“我在 Prompt 里写了返回 JSON”。“temperature 调大有什么影响”要回答随机性增大、输出更多样适合创意写作检索问答和工具调用场景适合用较低值保持结果稳定。同时要说明这只影响生成阶段的采样策略不会改变模型知识本身更不能靠调大 temperature 来解决幻觉问题。“模型产生幻觉怎么办”合理的答法是把幻觉当成系统问题处理Prompt 约束模型只依据给定资料回答RAG 提供可追溯来源工具或数据库对关键事实做校验同时允许模型在不确定时回答“不知道”。不要把责任全部推给模型也不要用“我换了更强模型”这种没有信息量的回答。4.2 Agent 原理与架构方向“什么是 ReAct为什么有效”这是 Agent 方向必问题。要讲清全称是 Reasoning and Acting模型交替进行推理和行动先输出思考过程说明为什么这么做再调用工具工具结果回来后继续推理。它有效的关键是把思考过程暴露在上下文中让模型每一步都能基于最新信息修正方向而不是一次性生成答案。“Agent 和普通对话系统有什么区别”核心差异在于是否有行动能力和反馈回路。普通对话只有输入和输出Agent 多出工具调用和观察结果两个环节于是产生了新的工程问题工具怎么注册、调用权限怎么控制、循环怎么终止、失败怎么恢复。“Agent 记忆怎么做”可以把答案拆成两层短期记忆直接用上下文窗口控制重点是长度超长就用滑动窗口或摘要压缩长期记忆放外部存储需要时检索回填。面试官如果追问还可以补充任务状态记忆把进行到一半的流程持久化避免 Agent 重启后断掉。“多个工具之间怎么协调”回答方向是先让模型做路由根据用户意图选择工具复杂任务再引入规划层先生成步骤再逐步执行。关键点是给模型足够的工具描述和前置条件说明并在工具层做参数联动校验不能指望模型自己理解所有业务规则。4.3 RAG 与 Data 方向“为什么用 RAG 而不是微调”这是数据方向最常见的问题。回答要点业务知识会频繁更新RAG 只需更换知识库数据成本低、速度快RAG 可以返回来源引用可解释性强微调适合改变模型的风格、领域术语和行为规范不适合存放频繁变化的事实性知识。两者也能结合使用。“切片长度怎么选择”不要背一个固定数字。要说明切片长度取决于文档结构和问题粒度长文档用段落级切片更完整短问答用句子级更精准通常会在几百到一千 token 量级之间实验同时增加重叠窗口防止上下文被切断。最终选择要以评测集上的检索命中率为准。“检索结果不准怎么办”排查顺序是先确认是不是召回问题即正确答案根本没进 TopK再看是不是排序问题正确答案存在但排太靠后。召回问题可以从数据清洗、切片、embedding 模型、query 改写几个方向解决排序问题可以加 rerank 模型或元数据过滤。直接改 Prompt 是最常见的错误做法因为上下文里压根没有正确答案Prompt 写得再好也没用。“RAG 系统怎么评估”要区分配置阶段和上线阶段。配置阶段用 golden 问答对做离线评测分别看检索命中率和生成质量上线阶段通过日志和用户反馈回流真实问题持续扩充评测集。评测集是 RAG 系统的资产比单次调参重要得多。4.4 系统设计与工程化方向“设计一个客服 Agent”是综合题建议按五层答题数据层负责接入文档和用户信息问答层负责检索和生成动作层负责工具调用如创建工单、查询订单控制层负责会话状态、权限和人工接管运维层负责日志追踪、监控和评测回归。“延迟和成本怎么优化”从链路角度回答先做意图路由简单问题走轻量模型复杂问题走完整 Agent 链路对高频检索结果做缓存压缩上下文只保留必要信息和摘要工具执行尽量并行回答用流式输出改善体感。每项措施都要说明换来的代价比如缓存会降低时效性摘要可能丢失细节。“Agent 系统如何保障安全和合规”要点包括工具执行前做参数校验和权限校验防止 Agent 被诱导执行越权操作对敏感字段做脱敏日志中不记录明文关键信息限制工具可访问范围用最小权限原则在 Prompt 中防御注入攻击但不能只依赖 Prompt真正的防线在工具执行层。回答时如果能主动提到“需要审计日志出事可以回溯 Agent 每一步做什么”会明显加分。模块高频问题核心考点答题顺序大模型与 Prompt稳定输出 JSON、temperature、幻觉对模型不确定性的处理机制约束 → 代码校验 → 兜底方案Agent 原理ReAct、记忆、工具协调对循环控制的理解环节解释 → 代码结构 → 失败处理RAG 与 Data为什么 RAG、切片、评估对数据链路的掌握全链路 → 调参依据 → 评测方法系统设计客服 Agent、成本、安全综合工程能力分层设计 → 关键取舍 → 监控回滚5. 面试答题的结构、颗粒度与反例5.1 项目经历用 STAR 组织但要把“技术决策”讲出来STAR 本身不难难的是把技术决策讲出来。以“实现一个客服 Agent”为例不要只讲背景和结果要重点讲行动中的取舍。推荐这样组织背景是知识分散在多个文档人工回复效率低目标是做一个能回答问题并处理退款咨询的 Agent行动时先搭数据清洗和检索链路再手写 ReAct 循环最后加入最大步数和参数校验过程中发现切片过长导致检索噪声于是改成段落切片并加了标题元数据过滤结果是检索准确率提升Agent 死循环问题被兜底。这样回答既有结构又有技术深度。5.2 技术颗粒度会调 API 和会做系统是两种面试表现同样描述一个问题不同颗粒度的回答差别很大。低颗粒度的说法是“我用了向量数据库做 RAG效果挺好的”。面试官无法判断你到底做了什么。高颗粒度的说法是“我用文档段落做切片每段带来源标题存入向量数据库检索后先用分数阈值过滤再加一层 rerank最后把 Top2 片段拼进 Prompt我用 80 条 golden 问题评测命中率从 52% 提到 78%但对多轮指代仍然漏检”。这种回答暴露了真实的工程经验也自然引出后续深入问题。注意不要编造具体指标。面试官追问数据来源时编不下去反而扣分。可以说“我们内部做了抽样评测具体数字需要在环境里复测”这种稳妥表述。5.3 这三类回答最容易扣分第一类是名词党。把 Agent、RAG、多智能体、记忆网络全罗列一遍每个都说不深。面试官只要追问“ReAct 为什么有效”就会露馅。第二类是框架依赖党。所有问题都答“我们用的 LangChain 实现了”。框架是工具不是知识面试要讲机制而不是讲包名。第三类是甩锅党。出了任何问题都归因于“模型不行”“框架 bug”“数据太脏”。合理做法是承认不确定性同时给出定位思路和解决方案比如先看轨迹日志判断是检索问题还是决策问题。5.4 遇到不会的题如何展开排查思路面试不可能每个题都会关键是展示解决问题的路径。可以用“先拆解再假设再验证再兜底”来组织。例如被问“如果 Agent 连续生成重复工具调用你怎么排查”。可以这样答先看轨迹日志确认是在哪个步骤重复假设一模型上下文里工具结果没有正确回填导致它不断重试于是检查消息拼装逻辑假设二工具确实执行了但返回值没有状态标识模型误以为失败于是改进工具返回结构增加 success 字段如果仍然不行加最大步数和熔断让系统转人工。这个思路即使不完全正确也能证明你是有排查方法论的工程师。6. 常见坑、排查清单与下一步建议6.1 工程实践里反复出现的四个坑问题现象常见原因检查方式处理建议工具调用偶尔返回不了合法参数schema 复杂、参数名含义不清晰打印模型原始输出保留失败样本简化参数名加示例值代码层二次校验和重试Agent 陷入循环API 费用快速增长缺少最大步数或工具结果未正确回填查日志看是否出现重复工具名设置最大步数确保工具结果追加进上下文RAG 检索返回的内容与问题无关切片过大、embedding 不适合领域、没有重排单独打印检索 TopK 片段做检查调切片、加元数据过滤、加 rerank、改写 query评测集指标好但线上体验差评测问题和线上真实问题分布不一致对比日志里的真实问题与评测集定期从线上抽问题回流评测集做分布覆盖6.2 从现象倒推根因的排查清单排查 Agent 或 RAG 问题建议按以下顺序走不要上来就改 Prompt输入是否正确用户原始问题有没有被错误预处理例如乱码、截断、多余字符。数据是否就位知识库有没有更新新文档有没有完成切片和向量化。检索是否命中把检索结果打印出来确认正确答案是否进入 TopK。上下文是否完整工具返回结果是否真的追加到 messages还是只拼接了字符串。模型决策是否合理模型选择工具是否正确参数是否符合 schema。工具执行是否正确业务代码本身有没有报错返回值结构是否稳定。输出链路是否正常最终回答是否被后处理截断或格式转换破坏。监控是否覆盖线上有没有轨迹日志、token 用量统计和异常告警。这套清单的价值在于固定排查入口避免在“模型不行”这个结论上过早停住。绝大多数线上问题最后查出来都不是模型的问题而是数据没更新、参数没传对、日志没打全。6.3 给专题课学习者的几条可执行建议第一务必先手写一个一百行以内的 ReAct 循环再学框架。手写能建立对 Agent 四个环节的直觉框架只是把这个循环做得更工程化。第二用一份真实业务文档完成一次完整 RAG 实验并把每次切块和检索效果记录下来。真实文档会暴露格式混乱、重复内容、专有名词识别等问题这些才是工作的价值所在。第三从第一天就建立评测集。哪怕只有五十条问题也比没有任何验证标准强。后续所有优化都跑同一套评测集做回归防止改好一个坏一片。第四保留失败样本。无论是解析失败的 JSON、检索跑偏的 query还是工具参数错误都归集成文件。面试时能拿出真实失败案例和修复过程比背十个框架名更有说服力。第五关注经典文献和官方文档优于追新工具。ReAct、RAG 这几篇基础工作把核心机制讲得很清楚理解它们之后任何新框架在你眼里都只是这些机制的组合与封装。Java 方向可以结合 Spring AI 再补一套落地路径但同样要回到机制层面去理解。【AIxAgentxData专题课】的核心并不是三个独立知识点的拼接而是三者在真实系统中的协作方式。把模型能力当作推理核心用 Agent 结构赋予它行动能力用数据工程保证知识质量和可评估性才是这条学习路线真正要训练的能力。