面试官问：“你的 Agent 记忆系统，能扛住多轮对话吗？”

“2 年 Agent 开发经验，主导过企业级对话 Agent 上线，熟悉 LangGraph、Mem0 等主流框架”

看到这份简历，我直接从记忆系统切入。Agent 能不能在生产环境跑稳，记忆是最关键的一环——比工具调用、比规划能力都关键。

结果聊了半小时，候选人对记忆的理解停留在"把聊天记录存到向量数据库里"。这不叫记忆系统，这叫日志存储。

Agent 记忆是目前面试的高频考点，也是 Agent 工程落地的核心难题。记什么、怎么存、什么时候取、什么时候删——每一步都有讲究。今天这场面试，把 Agent 记忆系统从原理到工程全部拆开来讲。

Round 1：Agent 记忆系统有哪几种类型？和人类记忆有什么关系？

面试官：“你在做 Agent 时用了什么记忆机制？能不能系统地讲讲 Agent 记忆有哪些类型？”

候选人：“嗯…就是短期记忆和长期记忆吧。短期记忆放在上下文里，长期记忆存到向量数据库。”

正解：

只分短期和长期是不够的。生产级 Agent 的长期记忆至少要细分成三种：语义记忆、情景记忆、程序记忆——少一种，Agent 的能力就会有明显短板。

这套分类来自认知科学对人类记忆的研究（Tulving, 1972），被 2023 年斯坦福的 Generative Agents 论文和后续大量 Agent 研究直接采用。

先说短期记忆。Agent 的短期记忆就是 LLM 当前的上下文窗口——模型能"看到"的所有信息。对话历史、系统 prompt、工具返回值，全部挤在这个窗口里。窗口满了，旧信息就得被截断或压缩。LangGraph 里叫 Checkpointer，用 MemorySaver 或 PostgresSaver 做会话级持久化。

短期记忆的工程瓶颈很明确：上下文窗口有大小限制（128K tokens 听起来很大，但 Agent 执行十几轮工具调用后，上下文很容易就满了），而且 LLM 对上下文中部的信息存在中间迷失问题（Lost in the Middle），位置靠中间的内容被模型关注到的概率明显低于头部和尾部。

再说长期记忆的三个子类型：

语义记忆（Semantic Memory）——存事实和知识。“用户是后端工程师”、“公司用的是 PostgreSQL”、“项目预算 50 万”。这些信息不绑定具体对话，是跨 session 复用的通用知识。存储方式通常是结构化的 key-value 或知识图谱。Mem0 的 factual memory 和 Letta 的 core memory blocks 都属于这类。

情景记忆（Episodic Memory）——存具体经历。“上周二用户问了 RAG 检索不准的问题，我推荐了 reranker，用户说有效”。这类记忆带时间戳、带上下文、带结果反馈，是 Agent 从经验中学习的基础。Generative Agents 论文里的 memory stream 就是典型的情景记忆。

程序记忆（Procedural Memory）——存技能和流程。“当用户要求生成周报时，先查本周任务列表，再汇总进度，最后生成 Markdown 格式报告”。程序记忆决定 Agent 怎么做事，通常以 prompt 模板、工作流定义或学习到的策略形式存在。这类记忆容易被忽略，但对复杂 Agent 是刚需——MemP 和 LEGOMem 专门研究如何从情景记忆中提炼出可复用的程序记忆。

三种记忆协同工作的逻辑：语义记忆提供事实基础，情景记忆提供经验参考，程序记忆指导执行流程。缺语义记忆，Agent 每次都要重新问用户基本信息；缺情景记忆，Agent 无法从成功或失败中学习；缺程序记忆，Agent 每次遇到同类任务都像第一次做。

还有一个进阶点：记忆的**固化（Consolidation）**过程。情景记忆可以通过后台 LLM 归纳，提炼成语义知识。比如 Agent 连续 5 次帮用户处理 CSV 数据时都用了 pandas，这个模式可以被提炼成语义记忆"该用户偏好 Python + pandas 做数据处理"。Letta 的 sleep-time agent 和 Mem0 的异步提取都在做这件事。（来源：LangChain LangMem 概念文档、Letta 官方博客）

要点速记

• 短期记忆 = 上下文窗口，LangGraph 用 Checkpointer 做 session 级持久化
• 长期记忆三类：语义（事实）、情景（经历）、程序（技能）
• 缺任何一类都有明显短板：缺情景 → 不能从经验学习，缺程序 → 不能复用技能
• 固化机制：情景记忆 → 语义/程序记忆，异步后台处理

Round 2：MemGPT 把记忆做成了操作系统？这是怎么实现的？

面试官：“你提到了 Letta。MemGPT 的论文你看过吗？它为什么要用操作系统的思路来管理记忆？”

候选人：“大概知道，好像是用了虚拟内存的概念，把记忆分成了内存和硬盘两层…具体细节不太记得了。”

正解：

MemGPT 的核心洞察是：LLM 的上下文窗口就像 CPU 的物理内存——容量有限。操作系统用虚拟内存和分页机制解决了物理内存不够的问题，同样的思路可以用来管理 Agent 的记忆。

MemGPT（2023，UC Berkeley，Packer 等人）提出了一个两层记忆架构：

第一层：In-Context Memory（类比 RAM）。这层在 LLM 的上下文窗口内，包含三部分：系统指令（不可编辑）、可读写的记忆块（Memory Blocks，核心创新）、以及近期对话历史。默认配置下，Letta 的 ChatMemory 类提供 “human” 和 “persona” 两个记忆块，各 2K 字符。Agent 可以通过工具调用直接编辑这些块：memory_insert（插入新信息）、memory_replace（替换旧信息）、memory_rethink（重新组织）。

第二层：Out-of-Context Memory（类比硬盘）。包括 Recall Memory（完整对话历史，支持文本搜索和日期搜索）和 Archival Memory（长期存储，支持向量检索）。当上下文窗口快满时，旧对话被压缩成递归摘要，存入 Recall Memory。Agent 需要历史信息时，通过 conversation_search 或 archival_memory_search 工具主动检索。

关键设计：Agent 自己管理自己的记忆。 传统 RAG 是被动检索——系统帮你找文档塞进 prompt。MemGPT 是主动管理——Agent 自己决定记什么、忘什么、什么时候从"硬盘"读数据到"内存"。这通过工具调用实现：Agent 的每一个动作都是 tool call，包括给用户发消息（send_message 工具）和记忆操作（core_memory_append、archival_memory_insert 等）。

Heartbeat 机制是另一个巧妙设计。MemGPT 在工具调用中注入 request_heartbeat 参数，如果设为 true，Agent 执行完当前工具后会立刻获得下一轮执行机会，不需要等待用户输入。这实现了 Agent 的连续执行——一次用户请求可能触发多轮工具调用链，中间穿插记忆读写操作。

现在的演进方向：Sleep-Time Agent。 原版 MemGPT 把记忆管理和对话响应放在同一个循环里，导致两个问题：记忆操作会增加响应延迟，以及 Agent 在对话压力下可能顾不上整理记忆。Letta V1 引入了 sleep-time agent，把记忆的整理、固化、清理放到异步后台处理，类似人类在睡眠中巩固记忆。（来源：MemGPT 论文、Letta 官方文档）

工程落地时的注意点：

1. 记忆块大小要控制。2K 字符的默认限制不是随意设的——块太大会挤占上下文空间，块太小存不下关键信息。生产环境建议根据业务场景调整，人均画像信息通常 1-2K 够用

2. 对话压缩的时机。Letta 在上下文使用率到 75% 时触发压缩，这个阈值需要根据模型的实际上下文长度和任务复杂度调整

3. 自编辑记忆的幻觉风险。Agent 可能会把错误信息写入 core memory，一旦写入就会持续影响后续所有交互。需要在写入前做校验，或者记录编辑历史以便回滚

要点速记

• 两层架构：In-Context（RAM）+ Out-of-Context（硬盘），核心是 Memory Blocks
• Agent 通过 tool call 自编辑记忆，不是被动 RAG 检索
• Heartbeat 机制实现连续执行，一次请求触发多轮工具调用链
• Sleep-Time Agent 把记忆整理放到异步后台，降低响应延迟

Round 3：记忆检索怎么做？只靠向量相似度够不够？

面试官：“你的 Agent 存了几万条记忆，用户来了一个新问题，怎么从里面捞出最相关的几条？”

候选人：“用向量相似度啊，对用户问题做 embedding，然后 cosine similarity 找最近的 top-k。”

（面试官内心 OS）：又是把记忆检索等同于向量搜索的…

正解：

只用向量相似度，Agent 会频繁捞出"语义相关但实际没用"的记忆。生产级记忆检索至少需要三维打分：Recency（时效性）、Relevance（相关性）、Importance（重要性），缺一不可。

这个三维检索框架来自 2023 年斯坦福的 Generative Agents 论文（Park 等人），现在已经成为 Agent 记忆检索的标准范式。

公式：

score = α_recency × recency + α_relevance × relevance + α_importance × importance

三个权重 α 在原始论文中都设为 1，每个维度的分数归一化到 [0, 1]，最终取 top-k。

逐个拆解：

Recency（时效性）——最近的记忆优先。采用指数衰减函数，每小时衰减 0.995。如果一条记忆 24 小时没被访问，recency 分降到约 0.89；一周没访问降到约 0.71。这模拟了人类记忆的遗忘曲线——越久没回忆的信息，被想起来的概率越低。但如果一条旧记忆被重新检索到（"访问"了一次），它的 recency 分会被重置。这对应心理学中的间隔重复效应。

为什么需要 recency？因为同一个事实可能随时间变化。用户上个月说"我用的是 Python 3.8"，本周说"刚升级到 3.12"。如果只靠向量相似度，两条记忆的语义距离几乎为零，但旧的那条已经过时了。Recency 能让新信息自然覆盖旧信息。

Relevance（相关性）——语义相关的记忆优先。这一步才是向量检索。对查询和每条记忆分别做 embedding，算 cosine similarity。语义越接近，分数越高。

Importance（重要性）——关键记忆优先。这是最容易被忽略的一维。"今天天气不错"和"用户刚被裁员"这两条记忆的重要性完全不同。Generative Agents 的做法是让 LLM 直接对每条记忆打 1-10 的重要性分数。一条记忆在存入时就被标注重要性，高分记忆在检索时获得额外加权。

更先进的系统如 Mnemosyne（RAND）在此基础上引入了动态衰减和访问加成：recency 用 e^(-age/30) 衰减，每次被检索到加 0.1 分（上限 +2.0），如果是图结构记忆还有邻居节点的接近度加成 +0.05。

前沿演进：从固定权重到可学习权重。 原始论文的三个 α 都是手调的。人大和华为联合研究提出了用 MoE（Mixture of Experts）门控函数来自适应调整权重——不同 query 类型、不同时间点，三个维度的权重比例动态变化。比如用户问"上周三发生了什么"时，recency 权重自动提高；用户问"我们的技术栈是什么"时，importance 权重自动提高。实验结果显示，自适应权重比固定权重在 LOCOMO benchmark 上提升了 8-12%。（来源：Generative Agents 论文、Frontiers 2025、alphaXiv Learn to Memorize）

工程排查指南：

记忆检索不准时的排查顺序：

1. 先查 Relevance：embedding 模型选对了吗？中文场景用 bge-m3 或 gte-large，不要用纯英文模型

2. 再查 Recency：衰减率是否合理？0.995/小时适合对话场景，如果是知识库场景，衰减要更慢（0.999）

3. 最后查 Importance：重要性打分的 prompt 要明确定义什么算"重要"，否则 LLM 容易给所有记忆打高分

4. 检查 top-k 值：k 太小可能漏掉关键信息，k 太大则引入噪声。对话场景 k=5-10，复杂推理场景 k=15-20

要点速记

• 记忆检索 = Recency × α + Relevance × α + Importance × α，三维加权
• Recency 用指数衰减（0.995/小时），解决信息过时问题
• Importance 由 LLM 打分（1-10），防止琐碎记忆压过关键记忆
• 前沿方向：MoE 门控自适应权重，比固定权重提升 8-12%
• 排查顺序：embedding 模型 → 衰减率 → 重要性 prompt → top-k 值

Round 4：Agent 的记忆越来越多，什么时候该删？怎么删？

面试官：“你的 Agent 跑了半年，存了 10 万条记忆，性能明显下降。怎么处理？”

候选人：“呃…加个定时任务，定期删掉老数据？”

正解：

定期按时间删是最偷懒的做法，而且会删掉有价值的旧记忆。正确的策略是：该记的长期记，该忘的及时忘——遗忘不是 bug，是 feature。

记忆膨胀（Memory Bloat）是生产级 Agent 最常见的性能杀手。症状很明显：检索延迟从 100ms 涨到 1s+，Agent 回答开始跑偏（因为检索到了太多不相关的记忆），token 成本直线上升。

研究数据表明：使用"全部保存"策略的 Agent，在运行初期性能不错，但随着记忆积累，性能持续下降。引入基于效用评估和检索历史的删除策略后，性能反而提升了 10%。原因是低质量记忆稀释了检索结果的精度。（来源：Xiong et al., 2025）

五种遗忘策略，按场景选用：

1. 基于时间的衰减（Time-Based Decay）

每条记忆带时间戳，重要性分数随时间指数衰减。长时间未被访问的记忆自动降权，最终触发删除阈值（比如重要性分降到 0.1 以下就删除）。适合对话型 Agent，近期信息比远期信息重要的场景。

2. 基于访问频率的淘汰（LRU/LFU）

借鉴缓存策略：最近最少使用（LRU）或最不频繁使用（LFU）的记忆优先删除。如果一条记忆存了 3 个月从来没被检索命中过，大概率没有保留价值。实现简单，效果稳定。

3. 基于摘要的压缩（Summarization-Based Compression）

不删除，而是压缩。把 100 轮对话历史用 LLM 压缩成一段 500 字的摘要，细节丢失但核心信息保留。Letta 的递归摘要和 Mastra 的 Observational Memory 都用这个思路。Mastra 的数据：文本内容压缩比 3-6x，涉及工具调用的场景压缩比可达 5-40x。

4. 基于效用的清理（Utility-Based Pruning）

用一个专门的 LLM 评估每条记忆的效用分：这条记忆对未来的交互有多大帮助？效用分最低的 20% 定期清理。实验数据：效用评估 + 检索历史结合的删除策略，比不删除的 baseline 性能提升 10%。（来源：Xiong et al., 2025）

5. 冲突解决（Conflict Resolution）

新记忆和旧记忆矛盾时，需要主动处理。Mem0 的做法是在 Update 阶段把新提取的记忆和已有的相似记忆做比对，通过 Tool Call 决定是更新、合并还是删除旧记忆。比如用户说"我换工作了，现在在字节"，系统应该更新"用户在阿里"这条语义记忆，而不是同时保留两条矛盾信息。

工程落地建议：

1. 分层清理。语义记忆（事实）靠冲突解决来更新，不按时间删；情景记忆（对话经历）靠摘要压缩 + 时间衰减；程序记忆（技能）基本不删，只做版本更新

2. 设置存储上限。每个用户/session 的记忆条数设上限（比如 1000 条），超出时触发清理流程

3. 异步清理。不要在用户交互时同步做记忆清理，放到后台定时任务。推荐每天低峰期跑一次全量清理

4. 合规要求。涉及用户数据的记忆必须支持 GDPR 的"被遗忘权"——用户要求删除时，必须能从向量库、图数据库、摘要中完全清除相关信息。Mem0 的 SOC 2 合规和加密删除协议是目前行业标杆

要点速记

• 记忆膨胀是生产级 Agent 最常见的性能杀手，"全存"策略会持续降低性能
• 五种遗忘策略：时间衰减、LRU/LFU、摘要压缩（3-40x）、效用清理（+10%）、冲突解决
• 分层清理：语义记忆靠更新、情景记忆靠压缩+衰减、程序记忆做版本管理
• 合规刚需：支持 GDPR “被遗忘权”，用户数据可完全清除

Round 5：生产级 Agent 记忆系统怎么选型和设计？

面试官：“如果让你从零设计一个支持百万用户的 Agent 记忆系统，你会怎么做？”

候选人：“用 Mem0 或者 LangGraph 的 Store 不就行了？”

正解：

"用 Mem0"不是一个架构设计，是一个工具选型。生产级记忆系统需要回答四个问题：记什么、怎么存、怎么取、怎么清。工具只是其中一环。

架构设计四步法

第一步：定义记忆策略（记什么）

不是所有对话内容都值得记忆。需要先定义记忆的提取规则：

记忆提取策略： ├─ 用户画像信息 → 语义记忆（姓名、职业、偏好、技术栈） ├─ 关键交互结果 → 情景记忆（成功/失败的方案、用户反馈） ├─ 重复出现的任务模式 → 程序记忆（工作流模板） └─ 闲聊/寒暄/确认性回复 → 不存储

提取方式有两种选择：

• Hot Path（同步提取）：在对话过程中实时提取记忆。优点是立即可用，缺点是增加 100-300ms 延迟

• Background（异步提取）：对话结束后后台处理。延迟为零，但提取结果需要等待处理完成才可用

推荐组合：关键画像信息用 hot path（用户说"我是后端工程师"时立刻存），大量对话的模式总结用 background。

第二步：存储架构（怎么存）

记忆存储分层： ├─ L1 热数据：Redis / In-Memory（读延迟 < 5ms） ├─ L2 温数据：PostgreSQL + pgvector（读延迟 < 50ms） └─ L3 冷数据：对象存储 + 向量索引（读延迟 < 500ms）

百万用户级别的存储选型建议：向量检索用 pgvector 够到百万级（HNSW 索引，recall > 95%），千万级以上考虑 Milvus 或 Qdrant。关系/图数据用 Neo4j 或 PostgreSQL 的 graph 扩展。会话状态用 LangGraph 的 PostgresSaver 做 checkpoint，配合 Redis 做缓存层。

第三步：检索策略（怎么取）

python

def retrieve_memories(query, user_id, k=10): session_context = redis.get(f"session:{user_id}") candidates = vector_store.search( query=query, filter={"user_id": user_id}, top_k=k*3 ) scored = [] for mem in candidates: score = ( 0.3 * recency_score(mem.last_accessed) + 0.4 * mem.similarity + 0.3 * mem.importance / 10.0 ) scored.append((mem, score)) return sorted(scored, key=lambda x: -x[1])[:k]

权重配比建议：对话型 Agent（recency 0.4 / relevance 0.3 / importance 0.3），知识型 Agent（recency 0.2 / relevance 0.5 / importance 0.3）。

第四步：清理与运维（怎么清）

清理流水线（每日低峰期执行）： ├─ Step 1：冲突检测 → 矛盾记忆合并/更新 ├─ Step 2：效用评估 → 低效用记忆标记 ├─ Step 3：压缩 → 30 天以上情景记忆摘要化 ├─ Step 4：归档 → L2 → L3 迁移 └─ Step 5：删除 → 效用分 < 0.1 且 90 天未访问的记忆

工具选型决策

场景	推荐	理由
快速集成	Mem0	框架无关，SOC 2 合规
有状态 Agent	Letta	自编辑记忆 + ADE 调试
LangGraph 用户	LangMem	原生集成
图关系记忆	Mem0^g / Cognee	多跳推理场景
重度定制	自研	pgvector + Redis

Benchmark 参考（LOCOMO，GPT-4o-mini）：Letta 74.0%，Mem0^g 68.5%，OpenAI 内置 54%。（来源：Letta 博客、Mem0 论文）

常见坑

坑 1：把向量库当成完整记忆系统。向量库解决检索，不解决记忆管理。你还需要冲突检测、压缩、清理、访问控制。

坑 2：记忆提取过度。每句话都提取记忆，记忆库很快膨胀到不可用。Mem0 的经验：过度提取导致检索精度下降 15-20%。

坑 3：不做多租户隔离。百万用户的记忆混在一起，轻则检索慢，重则信息泄露。

要点速记

• 四步法：记什么 → 怎么存（L1/L2/L3）→ 怎么取（三维检索）→ 怎么清
• Hot Path 延迟 100-300ms，Background 延迟为零
• pgvector 百万级够用，千万级上 Milvus/Qdrant
• Letta 74.0% vs Mem0^g 68.5% vs OpenAI 54%（LOCOMO）

面试官点评

这场面试暴露了一个很普遍的认知误区：大多数人把 Agent 记忆等同于"对话历史 + 向量数据库"。

真正的记忆系统是分层的（短期/语义/情景/程序）、主动的（Agent 自己管理记忆，不是被动检索）、有选择性的（该记的记，该忘的忘）。这背后涉及认知科学的记忆理论、操作系统的虚拟内存设计、信息检索的多维打分——不是调一个 API 就搞定的。

建议：

1. 读两篇论文：Generative Agents（Park et al., 2023）理解三维检索框架，MemGPT（Packer et al., 2023）理解 OS 级记忆管理

2. 用 Letta 的 ADE 可视化工具实际跑一个 Agent，观察记忆块的编辑过程，比看十篇文章更直观

3. 在自己的项目里实现一个最小记忆系统：pgvector 存记忆 + 三维检索 + 定期清理，不用上框架，先理解核心逻辑

记忆是 Agent 从"能跑"到"能用"的分水岭。没有记忆的 Agent 每次对话都是一个新人；有记忆但管理不好的 Agent 会被自己的记忆淹没。

能把这套东西讲清楚的候选人不多，但讲得清楚的，对 Agent 工程化的理解通常不会差。

普通人如何抓住AI大模型的风口？

领取方式在文末

为什么要学习大模型？

目前AI大模型的技术岗位与能力培养随着人工智能技术的迅速发展和应用 ， 大模型作为其中的重要组成部分 ， 正逐渐成为推动人工智能发展的重要引擎 。大模型以其强大的数据处理和模式识别能力， 广泛应用于自然语言处理 、计算机视觉 、 智能推荐等领域 ，为各行各业带来了革命性的改变和机遇 。

目前，开源人工智能大模型已应用于医疗、政务、法律、汽车、娱乐、金融、互联网、教育、制造业、企业服务等多个场景，其中，应用于金融、企业服务、制造业和法律领域的大模型在本次调研中占比超过 30%。

随着AI大模型技术的迅速发展，相关岗位的需求也日益增加。大模型产业链催生了一批高薪新职业：

人工智能大潮已来，不加入就可能被淘汰。如果你是技术人，尤其是互联网从业者，现在就开始学习AI大模型技术，真的是给你的人生一个重要建议！

最后

只要你真心想学习AI大模型技术，这份精心整理的学习资料我愿意无偿分享给你，但是想学技术去乱搞的人别来找我！

在当前这个人工智能高速发展的时代，AI大模型正在深刻改变各行各业。我国对高水平AI人才的需求也日益增长，真正懂技术、能落地的人才依旧紧缺。我也希望通过这份资料，能够帮助更多有志于AI领域的朋友入门并深入学习。

真诚无偿分享！！！
vx扫描下方二维码即可
加上后会一个个给大家发
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】

大模型全套学习资料展示

自我们与MoPaaS魔泊云合作以来，我们不断打磨课程体系与技术内容，在细节上精益求精，同时在技术层面也新增了许多前沿且实用的内容，力求为大家带来更系统、更实战、更落地的大模型学习体验。

希望这份系统、实用的大模型学习路径，能够帮助你从零入门，进阶到实战，真正掌握AI时代的核心技能！

01 教学内容

• 从零到精通完整闭环：【基础理论 →RAG开发 → Agent设计 → 模型微调与私有化部署调→热门技术】5大模块，内容比传统教材更贴近企业实战！

• 大量真实项目案例： 带你亲自上手搞数据清洗、模型调优这些硬核操作，把课本知识变成真本事‌！

02适学人群

应届毕业生‌： 无工作经验但想要系统学习AI大模型技术，期待通过实战项目掌握核心技术。

零基础转型‌： 非技术背景但关注AI应用场景，计划通过低代码工具实现“AI+行业”跨界‌。

业务赋能突破瓶颈： 传统开发者（Java/前端等）学习Transformer架构与LangChain框架，向AI全栈工程师转型‌。

vx扫描下方二维码即可
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】

本教程比较珍贵，仅限大家自行学习，不要传播！更严禁商用！

03 入门到进阶学习路线图

大模型学习路线图，整体分为5个大的阶段：

04 视频和书籍PDF合集

从0到掌握主流大模型技术视频教程（涵盖模型训练、微调、RAG、LangChain、Agent开发等实战方向）

新手必备的大模型学习PDF书单来了！全是硬核知识，帮你少走弯路（不吹牛，真有用）

05 行业报告+白皮书合集

收集70+报告与白皮书，了解行业最新动态！

06 90+份面试题/经验

AI大模型岗位面试经验总结（谁学技术不是为了赚$呢，找个好的岗位很重要）

07 deepseek部署包+技巧大全

由于篇幅有限

只展示部分资料

并且还在持续更新中…

真诚无偿分享！！！
vx扫描下方二维码即可
加上后会一个个给大家发
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】