面完出来我在地铁上坐过了三站。不是难过是脑子被掏空之后的那种呆滞。面试官揪着“记忆”这一个点换了六种姿势盘问我我差点以为自己没长脑子。先说下背景面的岗位是Agent开发方向是大模型应用落地。面试官是典型的技术流说话不快但每个问题都像手术刀——先切进去再搅一搅看看你到底是真懂还是背的。最折磨人的是第7题他问我“第11轮怎么处理总结”我答完他沉默了两秒又换个方式问“那前10轮就不管了吗”我补答他又问“那你这总结是增量还是全量”……同一个坑他看我掉进去三次。不废话了上硬菜。简单讲讲你的Agent项目基于大模型实现 ReAct 模式下的自主规划能力解决长线任务学习检索与记忆规划。我的项目核心就是ReAct 框架。ReAct 不是让模型一次性吐答案而是把它塞进一个 **“思考→行动→观察”**的循环里。实际工程里这个循环是在代码里用while实现的每次循环把Thought Action Observation拼成新的上下文喂给模型直到模型输出Final Answer或者达到最大步数限制。每一步的 Observation 都是真实环境的反馈不是模型瞎编的——这就保证了长线任务的可靠性。短期记忆的具体实现方式是什么这个问题面试官问得很细。短期记忆在工程上就是上下文窗口里当前正在用的那坨东西。我采用 **“滑动窗口 触发式总结”**策略设定一个 Token 上限阈值比如模型窗口是 16k我设 12k 为警戒线上下文里始终保留System Prompt 最近 2~3 轮完整对话一旦总 Token 超过警戒线把历史对话丢给一个轻量级总结模型或者用主模型自己总结生成一段 200~300 Token 的摘要然后把摘要塞进上下文替换掉那些被总结的早期轮次。这里有个细节总结不是把对话“翻译”一遍而是抽取关键信息——用户的目标是什么、已经完成了哪些步骤、当前卡在哪、有哪些重要约束。这样才能保证后续对话不跑偏。什么叫“快到上限了”对话是怎么逐步叠加的“快到上限”指的是上下文当前累积的 Token 数逼近了模型接口的硬限制或者你自己设置的安全水位。对话的叠加逻辑很多初学者会以为是“覆盖”其实是“追加”轮次 1: [System] [User_1] [Assistant_1] → 假设 1500 Token轮次 2: [System] [User_1] [Asst_1] [User_2] [Asst_2] → 3000 Token轮次 3: ... 继续追加 → 4500 Token每一轮都是把新产生的 query 和 response 拼接到已有上下文的末尾然后整个包裹一起发给模型接口。模型没有“记忆”能力它每次看到的都是这个拼接后的完整字符串。所以如果一轮对话里工具调用特别多比如调了 5 个工具每个返回 500 Token 的日志那这一轮可能直接吃掉 3000 Token很快就把窗口撑爆。如果对话轮次过多你怎么去做优化我当时给了三层方案面试官听完点了点头——但他后面绕着我这个方案又问了四五个问题明显是觉得我“说得漂亮但经不起推敲”。我的三层设计是Layer 1System包含角色设定、工具定义、输出格式约束。这部分绝对不能动一动 Agent 的人设就崩了。Layer 2近期窗口最近 2~3 轮完整对话确保模型对“当前在干什么”有精准感知。为什么是 2~3 轮因为大多数多步任务的核心上下文就在最近几轮里再往前的已经被执行完了。Layer 3历史摘要把更早的对话压缩成一个“进度报告”包含已完成目标、未完成目标、关键中间结果。什么时候去触发这个总结动作面试官开始绕我了。他反复问“什么时候”但我后来才明白他想问的是触发条件的具体数值策略和触发后的原子操作。触发条件有两个维度**条件一阈值触发。**我用双阈值策略——硬阈值接口上限的 90%和软阈值接口上限的 70%。到达软阈值时异步生成摘要并缓存到达硬阈值时同步阻塞当前对话强制完成总结后再继续。同步阻塞会影响用户体验所以软阈值提前准备是关键。**条件二步数触发。**当工具调用步数超过 5 步还没出结果说明任务在绕远路强制总结一次帮模型“抬起头来看方向”。触发之后的操作不是简单调个 API——要把当前上下文完整拷贝一份在副本上做总结然后原子性地替换上下文中的历史部分。绝对不能在线程里改到一半就发请求否则并发场景下数据全乱。是每一轮对话都要去做总结吗绝对不是。每一轮都做总结的话你会遇到三个问题计算开销爆炸每次总结都是 1 次 LLM 调用对话到 50 轮的时候你就得调 50 次额外的 LLM成本直接翻倍信息衰减加速摘要再摘要信息损失是指数级的。第一轮总结可能保留 80% 信息第二轮总结可能只剩 60%到第五轮基本就剩“用户问了点啥”延迟不可接受用户每说一句话都要等 2~3 秒的总结时间产品直接凉了。只在触发条件满足时才做——平时就是老老实实做追加。假设已进行 10 轮并做了总结第 11 轮开始时总结怎么处理是重算前 11 轮还是叠加这个问题我当时卡了两秒——因为我确实没仔细设计过这个场景。正确做法是“增量叠加而非全量重算”。第 10 轮结束时你有一个摘要S_1-10它已经消耗了比如 300 Token。第 11 轮的新对话D_11有 800 Token。第 11 轮开始时你直接把S_1-10 D_11拼在一起发给模型。不是把 1~11 轮全部拿出来重新总结一遍。全量重算的时间复杂度是 O(n²)而且耗费的 Token 是增量方式的 10 倍以上。但这里有个陷阱如果S_1-10本身已经占了 300 Token加上D_11又到了阈值第 12 轮要触发新总结时你需要对S_1-10 D_11做一次新的总结生成S_1-11然后丢弃S_1-10——这本质上是一个分层摘要树每一层都是对上一层的压缩。如果前 10 轮都变成了总结那之前的原始上下文就不需要了吗面试官问这个问题的时候我差点掉坑里——我说“不需要了”他眉头一皱。其实原始上下文必须持久化存储但不发送给模型。存到数据库里的原始数据有什么用审计溯源当模型给出错误答案时你得能回放“它当时看到了什么”摘要重建如果发现摘要质量太差可以重新生成不用从零开始积累长期记忆检索用户的某句关键指令可能在摘要里被压缩丢了但原始数据里还有后续按需检索能找回来。发给模型的永远只是那个压缩后的摘要 最近几轮。长期记忆可以按需检索召回具体在什么情况下需要检索这个问题我答得不好只说了“意图路由”。复盘一下长期记忆检索的触发时机取决于“当前问题对历史信息的依赖程度”我在项目里没做知识图谱所以跨实体的复杂推理检索确实是我的短板。如果做了知识图谱还能支持“用户 A 在 3 天前提到过的那个项目和今天这个需求有什么关联”这类高阶检索。每轮对话都要注入记忆吗长短期记忆是同时注入吗都不是。短期记忆是常驻上下文——每一轮都在不需要额外“注入”它就在那儿。长期记忆是按需动态注入——先走意图路由路由判断“需要查历史”时才去向量库检索 Top-K把检索结果作为前缀拼到当前上下文里。如果同时注入长短期记忆那上下文里会塞满无关信息。比如用户问“给我订个外卖”你同时把三个月前的聊天记录也塞进去纯属浪费 Token 而且增加干扰。如何减少工具过多带来的 Token 消耗这是一道很实战的题。工具多了工具描述schema本身就能吃掉你一半的上下文。举个例子一个完整的工具定义带参数 JSON Schema通常 200~5000 Token如果你有 30 个工具光 tool descriptions 就占 6000~15000 Token留给对话的就所剩无几了。我的方案是“意图识别 渐进式披露”关键数据50 个工具用完整加载需要 50 × 400 20000 Token。用渐进式披露第一轮只消耗 50 × 20 1000 Token第二轮加载 3 个完整 Schema 消耗 3 × 400 1200 Token。总计 2200 Token节省了 89%。而且这个方法还有额外好处模型在第一步看到的是精简列表选择工具的准确率反而上升了——因为干扰项少了注意力更集中。你的 RAG 是用什么技术实现的标准的 RAG 链路但每一步都有工程细节文档预处理按语义边界切分不是暴力按 500 字切用RecursiveCharacterTextSplitter保留段落完整性chunk size 512overlap 64Embedding 模型用的是 BGE-large-zh-v1.51024 维对中文语义支持好向量索引存到 Milvus 里建 IVF_FLAT 索引平衡速度和召回检索query embedding 后用余弦相似度召回 Top-20Rerank用 BGE-reranker-v2 对 Top-20 做精细排序取 Top-5 送入 LLM生成把 Top-5 的原文拼接成上下文加上“如果你不知道就说不知道”的 instruction送进主模型。如何判断向量的相似度我用余弦相似度。公式本质是计算两个向量在高维空间里的夹角余弦值值越接近 1 说明方向越一致语义越相近。除了余弦相似度还了解其他相似度算法吗欧几里得距离。公式值域 [0, ∞)越接近 0 越相似。听不懂说人话面试官这句话直接把我整不会了。他让我“说人话”解释余弦相似度。我当时有点慌说“反正 RAG 用余弦就对了”——这个回答不合格。正确的“人话”解释应该是**你把每个文本想象成高维空间里的一根箭。余弦相似度不看这根箭有多长只看它指向的方向。两根箭指向越接近同一个方向它们的意思就越像。**比如“猫”和“老虎”这两根箭方向很近但“猫”和“汽车”的方向就岔开了。RAG 里我们只关心“意思像不像”不关心“词多不多”所以用看方向的余弦不用看距离的欧氏。余弦相似度与欧几里得距离在工程应用中的具体区别是什么这道题我跪得最彻底。回来之后我把数学彻底补了一遍。核心差异不是“一个看方向一个看距离”这么简单——真正的关键在于 Embedding 向量在训练时已经被归一化了。绝大部分 Embedding 模型包括 BGE、OpenAI Ada输出的向量都是L2 归一化的——也就是每个向量的模长||V|| 1。在归一化前提下余弦相似度和欧氏距离是数学等价的所以当你用归一化向量时按余弦排序和按欧氏排序的结果完全一样。那为什么业界都选余弦不选欧氏余弦相似度欧几里得距离对向量模长敏感吗不敏感敏感在归一化场景下等价于点积计算最快需要开方略慢直观理解“语义方向是否一致”“空间位置是否接近”高维稳定性相对稳定易受维度灾难影响工程上选余弦的真正原因余弦相似度在未归一化场景下也能工作而欧氏在未归一化场景下会被模长差异主导导致“高频词向量”永远比“低频词向量”距离更近。为了安全大家都用余弦。项目中一共使用了几个模型分别是什么4 个Embedding 模型BGE-large-zh1024 维把文本转稠密向量用于 RAG 索引和检索路由分类模型BERT-base 微调轻量级 110M 参数跑意图识别——因为它太小了可以做到毫秒级响应不占用主模型的宝贵上下文主 LLMQwen-72B 或 Claude 3.5负责所有推理、规划、生成Rerank 模型BGE-reranker-v2Cross-encoder 结构对召回的 Top-20 做精细打分。分工明确小模型干脏活累活路由、向量化大模型干脑力活推理生成Rerank 做连接器。如何控制模型的幻觉问题我当时答非所问了说“看 RAG 召回准确性”。回来把完整防御体系梳理出来了分层解释输入层RAG 检索到的文档质量是防幻觉的根本。如果召回的都是垃圾模型再怎么约束都白搭。所以 Rerank 那一步至关重要。推理层温度调低到 0.1~0.3减少模型的“创造性发散”。用 Chain-of-Thought 强制模型在输出最终答案前先写“推理过程”——一旦推理过程出现矛盾可以在后处理里拦截。上下文层System Prompt 里明确写“如果上下文中没有明确信息直接回答‘我不知道’不要编造”。实测这句话能降低 30% 的幻觉。输出层要求模型在回答中标注引用来源[Doc_3]后处理里校验这个 Doc_3 是否真的在上下文中。如果引用了不存在的文档直接拒答。如何观察模型召回了哪些块这就是RAG 的可观测性。我在项目里做了一个“检索审计日志”每次 query 都记录四样东西Query 原文向量检索召回的 Top-20 文档 ID 及其 cosine 分数Rerank 之后的 Top-5 文档 ID 及其 rerank 分数最终拼进上下文的那 5 段原文。有了这个日志线上如果出了 bad case可以直接回放是检索没召回到相关文档召回率问题还是召回了但 rerank 排下去了排序问题还是召回了也排上去了但模型没用好生成问题三层归因一层层查。简历别的项目随便问了问主要工作常规的 STAR 法则介绍没展开。面试官明显对 Agent 那块更感兴趣。算法题Leetcode 143. 重排链表这是全场的翻车点我自愿认领。题目L0 → L1 → ... → Ln重排为L0 → Ln → L1 → Ln-1 → ...我的骚操作先把链表节点存到 Python 列表里然后双指针取数再重新串起来。写到一半面试官探头看了一眼屏幕“你这是用数组解的。这题考的是链表原地操作你偷懒了吧。”当场社死。正确的 O(1) 空间解法分三步走def reorderList(head): if not head or not head.next: return # 第一步快慢指针找中点 slow, fast head, head while fast and fast.next: slow slow.next fast fast.next.next # 第二步反转后半段 prev, curr None, slow while curr: nxt curr.next curr.next prev prev curr curr nxt # 第三步交替合并 first, second head, prev while second.next: tmp1, tmp2 first.next, second.next first.next second second.next tmp1 first, second tmp1, tmp2为什么不能用数组因为这题考察的是链表指针操作能力——找中点快慢指针、反转三指针、合并指针交错。用数组把节点存起来复杂度虽然也是 O(n)但面试官要看的是你操作指针的手艺不是 Python 列表的 API 熟练度。更惨的是输入输出全得自己写。我花了 20 分钟建链表、写打印函数最后跑起来还报错。早知道直接跟面试官坦白“我不太熟链表的输入输出构造”说不定还能混个思路分。你平时调试代码怎么调试的我说“断点 AI”。不对吧最简单的方式不是打印一下吗面试官一句话把我点醒了“你把你写的代码打印一下不就能找哪个地方出问题了吗”他说得对。Print debugging 是最原始最有效的手段尤其在算法题这种单文件场景下。我发现自己被 AI 惯坏了——遇到 bug 第一反应是“贴给 AI 帮我看”而不是自己加几行print追变量。两种场景业务工程断点 日志系统 AI 辅助算法题/脚本print 是王道秒级反馈无需任何环境依赖。我这个习惯得改。最近了解的 AI 内容我说了OpenClaw和Claude Code 源码。OpenClaw 是一个开源 AI 智能体核心能力是让大模型获得本地 Shell 权限自主执行终端命令。它的工作流完全是 ReAct 范式但加了一层安全沙箱——所有系统调用都要经过一个权限审批模块。讲一下 Claude Code 架构这块我纯属吟唱压根没看过源码。回来补了课Claude Code 是 Anthropic 的编码 Agent背后是50 万行 TypeScript。它的核心设计理念是“工具隔离 无共享可变状态”有40 个独立工具模块文件读写、Bash 执行、代码搜索、测试运行等每个工具有自己的输入 Schema、权限级别、执行逻辑不存在跨工具共享的全局可变状态——所有状态通过上下文显式传递查询引擎会把用户需求转成结构化的工具调用序列然后在一个循环里顺序执行。这其实是一种“微服务化”的 Agent 架构——每个工具可以单独升级、单独测试、单独做权限管控避免了一个工具出错把整个 Agent 拖垮。建议下去再补一点 Harness 的知识Harness 是一个Agent 工程化框架核心思想是通过分层规范文档来约束编码 Agent 的行为AGENTS.md定义 Agent 的角色边界和能力范围ARCHITECTURE定义代码仓库的架构约束TASKS.md定义当前任务拆解。它的本质是把“提示词工程”升级为“规范工程”——让 Agent 不是靠一段又长又臭的系统提示词来理解任务而是通过读取结构化文档来获得上下文。这样更可控、更可审计。反问业务我问了业务方向——安全风险相关的 AI。主要是用大模型做内容安全审核、违规行为识别、风险态势感知。属于 ToB 的合规方向业务复杂度高而且对模型的可解释性和低幻觉要求极为苛刻——因为误判会产生法律风险。这也解释了为什么面试官对幻觉问题追着问了那么久。最后说两句复盘这场面试我暴露的问题很清晰**一是基础数学不扎实。**余弦和欧氏的区别属于最底层知识我没答透。**二是被工具惯坏了。**刷题偷懒用数组解链表、debug 依赖 AI——面试官看这些细节就像看透明人。三是系统设计的颗粒度不够。记忆管理策略我说得出“总结最近几轮”但面试官一问“触发条件的具体数值策略”、“第 11 轮是增量还是全量”、“原始数据存不存”我就卡了。这暴露了我只做过 Demo 级别的 Agent没上过生产。**四是手撕代码真得练。**链表题用数组偷懒被当场识破输入输出都不会写——这波不冤。面完出来我在地铁上把这些问题从头到尾过了一遍然后掏出手机记了 3000 字的笔记。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
