简介这是一份面向2025年大模型Agent开发学习与面试备考的单选题实战习题集共25道单选与10道多选内容覆盖大语言模型、深度学习、机器学习等核心方向并延伸到分布式训练、模型部署推理加速、模型压缩与轻量化、评估指标、伦理安全、多模态融合、提示工程等实战知识点。文档以docx格式提供全包仅1个文件、大小15KB方便下载后在本地直接阅读和标记。已有189人学习浏览说明其具备一定参考价值。配套的答案与解析并非简单列出正确项而是针对LoRA、Adapter、TensorRT优化、知识蒸馏、剪枝、BLEU score、偏见检测、图文跨模态检索、Prompt Engineering等关键概念逐一解释原理与适用场景有助于读者快速厘清易混淆的技术定义在掌握基础的同时加深对模型高效训练、部署与安全评估的理解适合作为大模型Agent方向入门自测、课程练习或技术面试前的速查资料。1. 这份“基础卷”是从哪里来的以及我为什么做它2025年再聊大模型Agent开发已经不像2023、2024年那样还带着“试试看”的兴奋劲儿了。市面上真正能跑业务、能扛住线上流量的Agent项目越来越多但说实话大量涌入这个领域的人基础并不扎实。我会经常遇到一些候选人简历上写着“精通LangChain”“熟悉Agent开发”可一问到工具调用的底层流程、上下文窗口怎么管控、流式输出和实时终止怎么配合回答就开始含糊。这份《2025年大模型Agent开发实战习题-基础卷》本质上不是一份传统意义上的“考试题”。它的原型是我自己在带团队、做内部技术分享时沉淀下来的一套摸底题。每年我都会把它拿出来让新同学做一遍既是测试也是引导——通过十几道题把Agent开发中那些绕不开的概念、协议、框架思维、部署细节全部过一遍。整理成文档加上“含答案及解析”是想让自学的朋友也能获得相当于“有人在旁边讲一遍”的效果。这卷子定位在“基础卷”主要服务三类人刚学完大模型API调用、想往Agent方向走的后端开发者已经在用LangGraph、Dify或Coze做简单Agent但总觉得缺了底层逻辑的开发者准备跳槽或转岗需要用一套题快速自查Agent相关知识体系是否有盲区的人。它的考察范围也比较清楚大模型基础参数的理解、Agent核心机制工具调用、记忆、规划、主流编排框架的设计思路、RAG的常见误用以及工程化部署中的细节。下面我把这份卷子的核心题目和解析拆开讲一遍过程中的解析比题目本身更有价值。2. 大模型基础与API调用Agent的地基到底要打多牢基础卷第一部分从来不直接考概念背诵而是用实际场景题来看你是否有“真用过”的痕迹。这一部分我挑几道最有代表性的题目来讲。2.1 关于temperature参数出题思路和常见误区题目大概是这样的在构建一个代码生成型Agent时开发者在调用大模型API时把temperature设置为0.2结果发现生成的代码模板风格非常统一但偶尔出现重复逻辑问应该怎么调整。这个题的坑在于很多人不理解temperature的作用机制。temperature不改变模型“知道什么”它改变的是采样概率分布的尖锐程度。温度越低高概率token被选中的可能性越大输出越确定而代码生成场景中代码风格和格式需要稳定所以很多人的直觉是把温度调到接近0。但实际踩坑之后你会发现temperature太低会导致模型陷入局部重复模式尤其是长文本生成时容易出现循环片段。原因在于低温度下自回归生成的每一步都在挑选最高概率的token如果概率分布本身就比较平缓那么模型会倾向于选择那些在训练数据中出现频率高的模板化片段进而产生重复。我在实际项目里的经验是代码生成场景temperature取0.1到0.2之间没问题但要配合“禁止重复”的参数字段比如OpenAI接口里的frequency_penalty、或是一些开源模型中的repeat_penalty。纯靠调temperature解决不了重复问题这是这道题想让大家意识到的最核心的一点。此外0.2的温度下代码模板统一这件事并不完全是坏事。统一模板有利于后续的静态检查链路做模式匹配。如果Agent的输出是给机器继续处理的那稳定优先级高于创造性如果Agent的输出是给终端用户看的文案、创意那温度可以提高到0.7甚至更高。所以这道题更准确的答案是不要只调温度先判断下游是机器处理还是人阅读再决定参数组合方案。2.2 上下文窗口与外挂知识库为什么“放不进去”是常态另一道题我会这样出你正在开发一个文档问答Agent用户上传了一本300页的PDF每页约500个token总token数约15万。此时模型上下文窗口是128K约13万token左右你的第一反应是怎么办。很多人第一反应是“换更大窗口的模型”。表面上看2025年的模型上下文窗口已经普遍到了128K甚至200K但这里有两个容易被忽略的事实上下文窗口大不等于模型“理解”得好。超长上下文中模型对中间部分内容的注意力会明显下降也就是所谓的“lost in the middle”问题。把15万token全塞进去用户问文档第150页的内容时模型的表现可能让你怀疑人生。长上下文 高昂计算成本和延迟。每多一个tokenprefill阶段的计算量就线性增长。一次请求带10万token进去首token延迟会变得不可接受。这在面向用户的实时对话场景中是灾难。所以正确的处理路径是走RAG先做文档切分chunk、做向量化索引、检索之后再拼Prompt。但这道题里最常被忽略的下一步是“切多碎”和“检索召回多少条”。我在工程实践中常用的切片策略是按语义段落切单块控制在300到500 token之间重叠区50到100 token。召回时初始取top_k5到10条然后让大模型自己判断哪几条真正相关这种“召回归档再精选”的流程比单纯调大top_k有效得多。还有一种情况——如果Agent的定位是处理超长代码仓库RAG不一定是最优解。代码仓库有天然的依赖关系结构切片之后会丢失引用关系。这时候更适合用“仓库级Agent”的方案先让模型走一遍目录树定位到具体文件再读取文件内容相当于模拟人查代码的过程而不是一把梭全部切碎进向量库。2.3 Function Calling到底解决了什么问题很多Agent新手会误以为“工具调用就是让模型输出一段JSON”。其实准确的说法是Function Calling是让模型在生成自然语言回复之外还能输出结构化的函数调用指令由外部系统去真正执行执行结果再回传给模型。我出一道判断题用户说“帮我查一下北京明天天气”Agent的流程是“模型生成查询天气意图→外部API返回数据→模型再写一段给用户的回复”。这句话本质是没问题的但它是一个三层模型第一层模型感知到需要调用工具意图识别第二层模型按照预定义的函数Schema生成参数参数抽取第三层系统执行工具后把结果以消息形式追加到上下文中模型再做最终应答结果整合。框架帮我们封装了这三层但理解这三层之间的数据流是排查问题的关键。比如一个常见故障模型生成工具参数时把数字类型填成了字符串或者日期格式不符合API要求。框架层面不会替你修复参数类型如果你在定义工具Schema时没有把字段类型和描述写清楚模型就只能靠猜。在2025年多数主流模型已经在函数调用能力上做得不错但有一个细节仍然值得注意如果你定义的工具数量太多比如超过10个模型的选择准确率会明显下降。这时候需要进行工具分组把不相关的工具收拢到不同的“工作区”或子Agent中而不是把所有工具都暴露给主Agent。这道题想考察的就是——“你能不能在框架帮忙掩盖细节的情况下看穿底层逻辑”。3. Agent核心机制拆解工具调用、规划与记忆的连环局这一部分是全卷的核心也是很多“看起来会”的人翻车的地方。Agent与普通API调用的区别在于它有一个循环——Thought→Action→Observation→Thought……直到完成目标。基础卷会用几道题把这个循环里的关键点全部打一遍。3.1 ReAct模式别只背缩写我出一道场景题你正在开发一个客服Agent用户先问“我的订单什么时候发货”Agent查询了订单API发现已发货但用户接着问“那到哪了”。如果你只有订单API可用而没有任何物流API复现ReAct模式下整个思考过程可能经历什么。很多人的第一反应是“做不了返回不知道就行了”。但ReAct模式的正确玩法是Agent会基于已有信息做一步推理“已发货”是发货动作物流轨迹需要物流单号订单API里是否包含物流单号字段如果不包含是否有另一种途径比如通过订单号调用物流查询接口或者引导用户提供物流公司的短信通知编号。ReAct模式的价值恰恰在于它的“迟钝式自省”。每一步行动之后系统都把观察结果塞回上下文让模型决定下一步做什么。这种设计天然支持从局部失败中恢复。真的去写代码时这里的循环条件怎么控制是最大的坑——没有最大步数限制的话一个胡乱规划的小Agent可以无限循环下去消耗大量token和API额度。我处理的方式是每一轮工具调用后主动检查token消耗和步数超过阈值就触发“放弃总结”流程给用户一个诚实且有用的兜底答复而不是让用户等一个无限旋转的加载动画。3.2 记忆机制一个Context占位符引发的连锁问题Agent的记忆通常分为短期记忆上下文内、长期记忆向量库或KV存储、工作记忆当前任务的临时状态。基础卷有一道题会专门设计一个记忆覆盖导致的bug场景。题目大意一个会话型Agent在连续多轮对话后用户问“我刚才提到的预算还剩多少”Agent回答错误。排查发现本质原因是系统每轮对话都把对话历史截断到最近4轮而预算信息出现在第5轮。这个问题的深层梗在于系统的“短期记忆”不等于“用户视角的对话上下文”。开发者为了节省token只会往模型上下文里塞最近几轮对话但模型的所有推理都只能基于当前上下文。我见过太多项目在这里图省事用一个简单的截断函数处理历史消息结果扔掉了关键信息。一个相对成熟的方案是做“关键信息抽取”与“对话历史”分离。每一轮对话结束后用模型抽取用户提到的实体和约束写入结构化的Memory存储中。用户再次提到“预算”相关问题时检索链路会同时触发“对话历史搜索”和“Memory属性搜索”然后把两路结果拼进Prompt。这道题真的想考的是你能不能从“为什么会忘记”推导出“怎么设计记忆分层”。不是所有信息都值得塞进主上下文也不是所有信息都值得专门存储。短期记忆负责连贯性长期记忆负责事实保留中间需要一个提取和遗忘机制来管理。3.3 工具调用失败重试Agent的容错底线Agent实际跑起来最常发生的意外之一就是工具调用失败。别人问Agent“帮我订明天下午三点的会议室”Agent调用订会议室API返回错误——会议室已满。这里的基础操作是指定模型“如果目标会议室不可用请自动尝试备选时段或备选会议室”。但实际会更复杂一点——工具API本身可能因为网络问题超时此时返回的错误信息根本不含“可选的替代方案”。我在这道题的解析中会强调一套“分级重试”策略第一步识别错误类型。区分是参数错误模型生成的参数不对框架自动重新生成参数并调用、业务错误API正常返回但业务逻辑上无法满足、还是系统错误超时、5xx。第二步针对不同错误类型给出不同应对。参数错误——把错误信息反馈给模型必要时修正工具Schema业务错误——反馈给模型让它基于业务约束重新规划比如换一个时间系统错误——延迟重试重试次数上限3次超限则触发人工兜底。第三步无论重试是否成功都应该记录完整的调用链日志包括参数、错误信息、重试次数和最终结果。没有日志Agent出问题后你连排查的着手点都没有。这套内容在题目中出现的目的是考察你对“不可靠外部环境”的认知。市面上几乎所有的Agent教程都在讲怎么让模型“更聪明”但对真实的系统稳定性问题往往一笔带过。一个连外部工具超时都无法优雅处理的Agent智能程度再高也上不了生产。4. 从LangChain到LangGraph再到Dify/Coze框架选型的底层逻辑这个部分我会出一个对比题Team A用LangChain的AgentExecutor快速包了一个Demo2周内完成Team B用LangGraph重构整个流程花了1个多月但在复杂的多步工具调用场景中异常恢复能力和状态可视化明显更优。问这两条路线分别适合什么场景以及最终决策依据是什么。LangChain成为首选常常是因为生态成熟、文档多、封装好。但它的问题在于AgentExecutor这类“自动执行引擎”对流程的控制力比较弱。你想在工具A执行完后决定是否跳过工具B直接进入工具C这种条件分支在LangChain早期版本的表达很别扭你得写一大堆callback或自定义逻辑。LangGraph则是把Agent流程明确定义为一幅图节点Node是处理步骤边Edge是流转条件。每个节点执行前后都可以拿到完整状态也支持断点恢复。这种设计的价值在“可观测性”上极为突出——你可以随时查当前Agent执行到图上的哪个节点状态快照是什么甚至可以人为修改状态后让Agent继续跑。换到低代码平台Dify和Coze的优势在于业务同学也能拖拽出一个Agent而且内置了知识库、工作流编排、会话管理等企业级功能。它们对中小型业务的交付效率远高于手写框架但灵活性和对底层模型的细粒度控制较弱。我的建议其实很直接先想清楚你的Agent是“流程驱动”还是“模型驱动”。流程驱动的Agent——比如客服工单流转、审批机器人用LangGraph甚至Dify的编排都更合适。模型驱动的Agent——比如开放式的数据分析助手、代码Agent模型主导决策路径这时候用LangGraph的状态流来处理模型选择的动态行为就会比低代码平台舒服得多。框架选型没有银弹但有一件事是确定的别为了“赌未来”直接上最复杂的框架。等你的流程真的演化到需要细粒度控制再重构也不迟。而重构的底气来自你在之前的简单方案中已经把数据结构、日志体系、上下文管理这些事情理清楚了。5. 工程化与部署环节从“能跑”到“能上线”要补的课最后一部分基础卷放了几道偏工程实操的题。这些题很多人做不对不是因为不会写Agent逻辑而是没经历过“把Agent放上生产环境后”的毒打。5.1 流式输出与实时终止的配合一个聊天Agent如果走非流式接口模型推理耗时可能达到3到10秒用户只能盯着光标等。所以流式输出在交互型Agent中是刚需。但流式输出会带来一个工程难题用户看到模型已经输出的内容后想打断或停止生成系统需要立刻终止后端的大模型请求。这道题考查的关键是很多大模型API的流式响应一旦开始客户端断开连接后服务端不一定立刻停止生成除非你显式发送中断信号。我处理这个问题的惯用方法是服务端通过SSEServer-Sent Events向前端推送tokenSSE通道里维护一个request_id用户点击“停止”时前端向后端发一个cancel信号后端拿到request_id后调用SDK的abort方法同时清理生成任务在GPU/推理服务中的排队状态如果用的是自部署的推理服务比如vLLM、Ollama还需要在推理框架层面开启“客户端断开即停止”的配置否则请求会继续占着算力直到生成完毕。这个问题在开发环境里几乎遇不到因为它只在高并发或长时间生成时才会凸显成本问题。但上线后大量被浪费的算力和token消耗迟早会在账单上给你上一课。5.2 模型输出的JSON可靠性问题让模型输出结构化JSON是最常见的需求之一。但哪怕到了2025年模型在复杂场景下仍然可能输出残缺JSON、注释、或者多余文字。基础卷里肯定会有一道多选题考察各种防护手段。我推荐的加固链路是第一层依赖优先使用模型的JSON Mode或Structured Output能力从采样阶段限制输出为合法JSON第二层兜底拿到模型输出后别直接JSON.parse先走一个修复函数——用正则提取最外层大括号内的内容再把常见的非法转义字符做修复如果修复失败就重试让模型重新生成第三层校验JSON解析成功之后必须做字段级校验。模型可能生成了合法JSON但把数字字段填成了字符串此时校验器要能抛出明确的错误并触发重试。这套链路的本质是“永远假设模型会出错”并且每一层都争取在上层把错误拦截掉。一个Agent项目如果模型输出解析这个环节不够稳上层再漂亮的规划逻辑都会变成空中楼阁。5.3 本地部署、开源模型与云端API怎么选热词里大量出现“本地部署大模型”“大模型下载”“Ollama部署大模型”“GPU微调大模型”这类词。基础卷会有一道题对比自部署开源模型和调用云端API的适用场景。OpenAI兼容接口这个点经常被忽略。2025年的Ollama、vLLM、fastchat等主流框架都默认提供/OpenAI兼容接口意味着你在代码里切换本地模型和云端模型通常只需改base_url和模型名。这种兼容性设计让本地部署试错成本变得极低。那么什么场景适合本地部署我总结了几个信号数据敏感性极高无法出域业务请求量平稳且需要极低延迟离线或内网环境API成本已占到总成本不可忽视的比例。反过来如果需求多变、并发波动大、需要快速尝试不同模型的能力那云端API仍然是更省心的选择。本地部署还有一个隐性成本容易被低估——维护。模型更新要重新下载、推理框架要跟随社区补丁升级、GPU故障要有人处理。这些运维成本在项目早期不显现等线上跑起来后却会长期吃掉人力资源。所以这道题我的标准答案是初期以云端API验证效果中期利用OpenAI兼容接口做AB对比确定模型能力和成本都合适后再决定是否转移到自部署。5.4 RAG与微调数据类问题的最常见误用最后一个我想展开的是RAG和微调的选择题。2025年仍然有大量同学问我为什么我微调了模型它回答私有知识库问题还是不准核心原因通常只有一句话微调改变的是模型的“行为模式”和“格式习惯”不是给模型注入新知识的可靠方式。想让模型记住具体事实和长尾知识RAG是更合适的手段。微调更擅长的是风格对齐比如让模型用特定口吻回复、指令遵循能力的强化比如让模型学会在特定场景必须调用某个工具、以及输出格式的固定。实操中这两者也可以叠加使用先用RAG把知识库内容检索出来塞进Prompt保证回答的事实有据可依再用微调让模型学会“只基于检索内容回答不要自行编造”。很多上线跑得很稳的Agent产品走的都是这条组合路线。还有一个常见问题是“我的知识库有上层业务逻辑单纯切分文本段落检索召回率很低怎么办”这时你要做的不一定是调chunk size而是考虑“知识库结构感知”。比如业务文档里包含流程、表单、权限规则可以把这些字段显式建模为结构化知识在向量检索之外增加一条关键词/属性过滤通道两路并行召回再合并排序。这样知识库的“可检索性”会大幅提升而不是每一次都盲目去调向量相似度阈值。6. 我的习惯把这份卷子当作项目启动的体检清单这套题在内部被使用了快一年之后我逐渐发现它不只是一份考试卷更像是一个Agent项目启动前的“体检清单”。每次有新项目从想法进入执行阶段我都会提醒团队先过一遍这些问题模型参数有没有认真设过还是直接用了默认值工具调用失败有没有重试机制还是寄希望于模型永远生成正确参数记忆方案是简单截断还是按信息类型做了分层上下文里塞了多少对当前任务无用的噪音不少Agent项目“死”得并不明显——没有报错、没有崩溃但用户体感就是“不太聪明”或者用了几轮之后“越来越笨”。这种问题往往不是模型能力不够而是工程细节没有打磨到位。把一个基础概念里的“为什么”搞清楚比多堆几个炫酷的Demo有价值得多。最后分享一个小习惯我会要求每道题的解析里都写一个“坑”而且是那种只有动手做过才会遇到的坑。因为我看过太多人面试时能把概念倒背如流一上手就被一个不转义字符、一个超时配置卡住半天。希望这份基础卷能帮你在进入更复杂的Agent项目之前把最容易埋雷的地方先排一遍。本文还有配套的精品资源点击获取