Agent 记忆与 RAG 怎么做：一场把我问到哑口无言的技术面试

lihui_006

146人浏览 · 2026-07-13 22:47:11

lihui_006 · 2026-07-13 22:47:11 发布

Agent 记忆与 RAG 怎么做：一场把我问到哑口无言的技术面试

引子：一道"送分题"，问到我哑口无言

前阵子聊一个 AI 项目的技术方案，对方是个带过团队的技术负责人。开场问题很轻松：

“你们的 Agent 是怎么做记忆的？”

我心想这不是送分题吗，张口就来：“存历史对话呗，再配一个向量数据库做检索。”

对方点点头，接着一句一句往下追：

“大模型不是本来就有记忆吗，为什么还要额外做一套记忆系统？”
“如果只是把历史对话全塞进上下文，不够用吗？”
“聊了几百轮之后，上下文塞不下了，怎么办？”
“记忆到底存在哪？什么时候写进去、写什么、不写什么？”
“存下来的东西，怎么用？每次都全量塞给模型？”
“向量检索出来的结果，直接扔给大模型就完事了？”
“Agent 会不会自己判断’这些资料够不够回答’，不够怎么办？”

七个问题，一个比一个往工程细节里钻。我发现自己前面答得越顺口，后面越心虚——“记忆"和"RAG"这两个词我说得很熟练，但真被摁在地上一层层问"具体怎么实现”，答案立刻从"体系化认知"退化成"零散印象"。

这篇文章就是把这场拷问补完的产物。我把这七个追问原样保留，作为全文的路线图——按这个顺序讲透，你大概率也不会被问倒。

第一章：先把"记忆"这个词的水分挤干净

面试官： 大模型不是本来就有记忆吗，为什么还要额外做一套记忆系统？

这个问题背后藏着一个真实的混淆：大模型的"记忆"和 Agent 的"记忆"，根本不是一回事。

大模型确实"记得"很多东西——但那是训练阶段把海量语料压进参数里的世界知识，写死在权重矩阵里，推理时只能读、不能写，你没法让它"记住"今天和你聊了什么。这叫参数记忆（Parametric Memory），它稳定、但是冻结的。

那对话过程中的"你还记得我刚才说的吗"是怎么做到的？靠的是上下文窗口（Context Window）——你把完整的历史对话原样塞进每一次请求里，模型每次都是"从零看一遍全部聊天记录"再回答，它自己什么都没存。这是一种运行时的、易失的记忆：关掉这个会话，或者上下文塞不下要截断，这部分"记忆"就没了。

Agent 记忆要解决的正是这道鸿沟：怎么让一个本质上"每次都失忆"的推理引擎，表现得像一个有连续人格、记得住事情的东西。答案不是让模型自己变聪明，而是外挂一套运行时的、可读写、能跨会话持久化的存储系统，由 Agent 在合适的时机去读、去写。

三层记忆一次说清楚：

	参数记忆	上下文记忆	Agent 记忆系统
存在哪	模型权重	当前请求的 messages 数组	外部数据库 / 文件 / 向量库
读写方式	训练时写入，推理时只读	每次请求整体带入，会话结束即失效	Agent 主动读写，跨会话持久
更新成本	极高（要重新训练/微调）	免费，但有长度上限	低，随时增删改
典型内容	世界常识、语言能力	本轮对话的来龙去脉	用户偏好、历史事件、长期事实

搞懂这三层，你就能听懂认知科学里那套记忆分类框架为什么会被搬进 Agent 设计里——因为它精确对应了"该往哪层存"这个工程决策：

工作记忆（Working Memory）：当前正在处理的这一轮任务，对应上下文窗口本身。
情景记忆（Episodic Memory）：具体发生过的事——“上周三用户抱怨过登录很慢”，带时间戳、可回溯。
语义记忆（Semantic Memory）：从具体事件里沉淀出的抽象事实——“这个用户偏好简洁的回复”“这个客户的合同到期日是 X 月 X 日”。
程序性记忆（Procedural Memory）：怎么把一件事做对的流程/技能——“给这个客户开发票要走的三步审批”。

后面三章分别对应"工作记忆怎么管理"“情景/语义记忆怎么存”“程序性记忆怎么检索出来用”——这条分类线，就是这篇文章的骨架。

第二章：短期记忆——上下文窗口里的精打细算

面试官： 聊了几百轮之后，上下文塞不下了，怎么办？

这是工作记忆层面最直接的工程问题。上下文窗口再大也是有限资源，而且不是越满越好——扔进去的历史越长，单次请求的延迟和成本越高，检索/推理质量还可能因为"中间信息丢失"（Lost in the Middle，模型对超长上下文中间部分的关注度显著低于开头结尾）而下降。所以"塞不下了"从来不是终点，而是每一个长时间运行的 Agent 从第一轮对话起就要面对的常态问题。

主流做法分三条路线，思路完全不同：

路线一：截断/滑动窗口。 只保留最近 N 轮，早期对话直接扔掉。最简单，但代价也最直白——早期的关键约束、用户第一句话交代的背景，可能说没就没了。

路线二：摘要压缩（Summarization）。 把早期对话喂给模型，生成一段浓缩摘要替换掉原文，原始细节丢失但保留大意。这是目前最常见的工程手法，实现上通常是"最近 K 轮原文 + 更早内容的滚动摘要"混合模式。

路线三：剪除（Pruning）。 不总结，直接删掉不再需要的部分——比如一次工具调用已经用完、结果也已经被模型消化吸收了，那这次调用的原始输入输出就是纯粹的"垃圾数据"，占位置但没信息增量，直接清掉。

这三条路线经常被混着讲，但摘要和剪除是两种本质不同的压缩，值得拆开说清楚——这也是这道题最容易在追问里露馅的地方。以 Claude API 的两个真实机制为例：

Compaction（压缩） 是"总结式"的：当对话接近上下文触发阈值（默认 150K tokens）时，服务端自动把早期内容概括成一个 compaction 内容块，原文被替换成摘要。这里有一个非常容易踩的工程坑：你必须把返回的完整 response.content（包括这个 compaction 块）原样传回下一轮请求，而不能只提取文本部分——只传文本会导致压缩状态丢失，服务端无法在此基础上继续维护上下文。

Context Editing（上下文编辑） 是"剪除式"的：按策略清除旧的工具调用结果（clear_tool_uses，可选连输入参数一起清）或思考过程（clear_thinking），不生成摘要，直接删。适合那些"用完就没有信息增量"的内容——比如 Agent 读了一个文件、内容已经被消化，原始文件内容留在上下文里就是纯粹的浪费。

💡 开发者视角：面试里最容易被问穿的地方，是"你分得清压缩和删除吗"。摘要有信息损失但保留大意，适合"早期背景仍有价值，但不需要逐字精确"的场景；剪除没有信息损失（因为压根不保留），适合"这部分内容已经被处理完、不会再被引用"的场景。把两者混为一谈，会导致要么该删的舍不得删（浪费 token），要么该总结的直接砍掉（丢失关键约束）。

第三章：长期记忆——写到哪、什么时候写、写什么

面试官： 记忆到底存在哪？什么时候写进去、写什么、不写什么？

短期记忆解决的是"这一次会话内怎么不超支"，长期记忆要回答的是完全不同的问题：这次会话结束之后，哪些东西值得留到下一次。

3.1 存在哪：三种载体，服务三种查询模式

载体	适合存什么	典型查询方式
文件 / 文档存储	结构化不强的自由文本笔记	按路径读取、全文/关键词搜索
向量数据库	大量非结构化文本，需要"语义相近"检索	相似度搜索（第四、五章详细展开）
图数据库	实体和实体之间的关系网络	“谁认识谁”"什么导致了什么"这类关系查询

三者不互斥，成熟的 Agent 记忆系统往往是组合拳：文件/文档存原始事实和笔记，向量库存用于语义检索的知识片段，图数据库存关系密集的结构化信息（比如客户关系图谱）。

一个容易被低估的事实是：文件系统本身就是一种完全合格的记忆实现，不需要一上来就上向量数据库。Claude API 的 memory 工具就是这个思路的直接体现——Claude 通过读写一个固定的 /memories 目录下的文件来实现跨会话记忆，支持查看、创建、字符串替换、插入、删除、重命名这几个基本操作，本质上就是"让模型自己管理一个笔记本"。简单、可审计、不需要额外的向量化基础设施，很多场景够用了。

💡 开发者视角：这里有一条容易被忽视但代价极高的安全边界——绝不能把 API key、密码这类凭证写进记忆文件。记忆是会被原样读回、拼进未来上下文的，一旦写入就相当于把凭证明文留在了一个会被反复"复述"的地方。同理，如果记忆系统允许模型自己指定文件路径，一定要做路径穿越校验（对路径做规范化后确认仍落在记忆目录内，拒绝 ..、软链接这类逃逸手法）——这条不是理论风险，是真实的工程checklist条目。

3.2 什么时候写：三种时机，权衡实时性和信噪比

实时写入：每一轮交互后立刻更新，比如用户说"以后都用简体中文回复我"，Agent 当场把这条偏好记下来。优点是不会漏，缺点是容易记成"流水账"——事无巨细全存，检索的时候噪音一大堆。

反思式写入（Reflection）：不是每轮都写，而是定期让 Agent"回头看"最近一段经历，从一堆具体事件里提炼出更高层的洞察再写入。这个思路最早来自斯坦福 2023 年那篇"生成式智能体"（Generative Agents）论文——它给每个 Agent 维护一条带时间戳的记忆流（Memory Stream），检索时按**近期性（recency）、重要性（importance）、相关性（relevance）**三个因子加权打分取回相关记忆，同时周期性地触发"反思"，把琐碎观察压缩成更抽象、更有复用价值的结论，而不是让记忆库无限膨胀成一本流水账。这套设计到今天依然是长期记忆架构的参照系。

显式触发写入：用户明确说"记住这个"才写。最省事，但完全依赖用户主动，覆盖率最低。

生产系统通常三种都要——高置信度的显式指令实时写，日常交互攒一批之后跑一轮反思提炼，不做全量记流水账。

3.3 什么该存、什么不该存：重要性打分与遗忘机制

记忆不是越多越好。塞进去的东西越多，检索时的噪音越大、成本越高，还可能出现"两条记忆互相矛盾却都被检索出来"的尴尬局面。所以生产级的记忆系统都需要一层准入过滤：

重要性打分：新信息值不值得存，通常用一个轻量模型或规则给一个分数，低于阈值的直接丢弃（比如"今天天气不错"这种寒暄大概率不值得进长期记忆）。
去重：新信息和已有记忆语义重复，选择合并而不是重复堆叠。
遗忘机制：给记忆加时间衰减权重，或者定期做 LRU（最近最少使用）清理——记忆系统不是日志系统，不追求"完整保留一切"，而是追求"随时能捞出当下最有用的那一部分"。

生产环境还要考虑记忆的版本与审计——谁在什么时候改了哪条记忆、能不能回滚。这不是过度设计，是真实的合规和调试需求。Claude 的 Managed Agents Memory Store 给了一个可以直接参照的实现范式：每一次记忆变更（新增/修改/删除）都会生成一条不可变的版本快照，记录操作者身份和时间戳；更新时还支持乐观并发控制——传入基于内容哈希的前置条件，只有内容和预期一致才允许写入，否则返回冲突，逼你先读最新状态再改，避免并发写互相覆盖。多用户场景下，记忆还要按"仓"隔离（一个 Agent 会话最多可以挂载多个记忆仓，比如一个只读的共享知识库 + 一个当前用户专属的可写仓），这是避免记忆跨用户串味的关键设计。

第四章：从记忆到检索——RAG 到底在解决什么问题

面试官： 记忆存下来了，怎么用？每次都全量塞给模型？

这一句追问，直接把话题从"怎么存"拽到了"怎么取"——而这正是 RAG（Retrieval-Augmented Generation，检索增强生成）真正要解决的问题。

一个常见的误解是把 RAG 当成一种"给大模型接个知识库"的黑箱功能。拆开看，它的动机其实很朴素：记忆库可以无限增长，但上下文窗口是有限的，你不可能把全部记忆塞进每一次请求。 唯一的出路是：每次只挑出"跟当前问题最相关的那一小撮",按需拿出来用。这个"挑"的动作，就是检索（Retrieval），RAG 就是"检索出来的内容 + 生成"这两步的组合。

完整链路长这样：

六个环节，每一环都有独立的工程决策点，也是接下来面试官继续追问"怎么搭"时最容易被问穿的地方。

第五章：RAG 向量数据库从 0 到 1 怎么搭

拿到"怎么搭一个向量数据库"这种问题，最怕的回答方式是甩出一堆工具名字。真正能说明白的，是每一步"为什么这么选"。

5.1 切片（Chunking）：第一步就决定了检索的天花板

原始文档不能整篇塞进向量库——太长的文本一旦被压缩成一个向量，语义会被稀释到检索不出细节；太短又丢失上下文。所以第一步永远是切片。

固定长度切分：按 token/字符数切，配合一定比例的重叠（overlap）防止关键信息被硬生生切在边界上。最简单粗暴，也最容易语义割裂。
语义边界切分：按段落、句子这类自然边界切，或者进一步用语义相似度检测"话题切换点"再切——切出来的每一块更接近一个完整的语义单元。
递归式切分：优先按大分隔符（段落）切，切完还是太长就退而求其次按句子、按词继续切，是目前工程上最常见的折中方案。

chunk size 是个纯粹的权衡问题，没有万能答案：切太碎，单个 chunk 语义不完整，检索精度会因为"向量表达的信息量不够"而下降；切太粗，一个 chunk 里混进多个不相关话题，向量被稀释，检索出来的相关性反而更差，而且生成阶段会塞进大量无关上下文。实践中大多落在几百 token 量级，具体数字要靠自己的文档特性和评估反复调。

5.2 向量化（Embedding）：把文本变成能算距离的坐标

切好的每一块文本，要通过一个 Embedding 模型转换成一串数字（向量），语义相近的文本对应的向量在空间里也彼此靠近——这正是《大语言模型底层原理》系列里讲过的"词嵌入"思想在文档级别的延伸，只是这里编码的对象从"词"换成了"一整段话"。

选型上有几个决策点：

开源自部署 vs 闭源 API：开源模型（如 BGE、GTE 系列）可以本地跑、没有调用成本、数据不出域；闭源 API 通常效果更稳定、免运维，但有调用成本和延迟。
向量维度：维度越高理论上表达力越强，但存储和检索开销也越大，不是越大越好。
要不要微调：通用 Embedding 模型在垂直领域（法律、医疗、内部代码库）上表现往往打折扣，专有名词、行业黑话的语义相近关系学不准。数据量和预算允许的话，在领域语料上微调 Embedding 模型能显著提升检索质量。

5.3 向量数据库选型：没有最好的，只有最合适的

数据库	特点	适合场景
Milvus	开源，面向大规模生产设计，云原生	数据量大、需要企业级部署能力
Pinecone	全托管商业 SaaS，开箱即用	想快速上线、不想自己运维
Weaviate	开源，原生支持混合检索、GraphQL 接口	需要向量+关键词混合检索
Qdrant	开源，Rust 编写，性能和 API 简洁度都不错	中大规模、看重性能和开发体验
pgvector	PostgreSQL 插件，把向量检索加进关系数据库	已经在用 Postgres，不想引入新组件
Chroma	轻量、可嵌入式运行	原型开发、中小规模应用

选型的核心问题从来不是"哪个最强"，而是：数据规模有多大、要不要混合检索、团队愿不愿意运维一个新组件、已有技术栈里有没有现成的关系数据库可以顺手扩展。 已经在用 Postgres 的团队，pgvector 往往是阻力最小的起点；数据量到了千万级往上、对检索延迟有硬指标，才需要认真考虑专用向量库。

5.4 索引算法：用直觉理解，不用啃数学

向量库底层靠近似最近邻（ANN, Approximate Nearest Neighbor）算法加速检索，不需要吃透数学推导，但要理解权衡：

HNSW（层次化可导航小世界图）：把向量组织成多层图结构，检索时从粗到细逐层跳转定位。查询快、召回率高，是目前最主流的选择，代价是构建索引和内存开销都比较大。
IVF（倒排文件索引）：先用聚类算法把向量空间切成若干"桶"，查询时只在最近的几个桶里搜索。内存效率更好，适合超大规模数据，但召回率通常略逊于 HNSW，而且聚类中心是预训练的，不太适合数据频繁变动的场景。

一句话总结这层权衡：HNSW 用内存换检索质量和速度，IVF 用检索质量换内存效率。

5.5 检索：语义相似 ≠ 语义相关，这是最容易被忽视的陷阱

向量检索本质是算"当前问题的向量"和"库里每个 chunk 向量"的相似度（通常是余弦相似度），取最接近的若干个。这里有一个反直觉但极其重要的真相：“相似"不等于"相关”，更不等于"事实一致"。 两句话讨论同一个话题、用词高度相近，向量距离会很近，但它们完全可能在陈述互相矛盾的事实（比如新旧两版价格政策）——向量检索没有能力判断谁对谁错，它只负责"像不像"，不负责"对不对"。

另一个纯向量检索的天生短板是：专有名词、缩写、精确数字这类需要"精确匹配"而非"语义相近"的内容，向量检索经常找不准——"订单号 A20231205"和另一个订单号在语义向量空间里可能靠得很近，但业务上是完全不同的两件事。

这正是**混合检索（Hybrid Search）**成为工程标配的原因：向量检索（Dense Retrieval，擅长语义相近）+ 关键词检索（Sparse Retrieval，如 BM25，擅长精确匹配）并行跑，再按某种融合策略（比如倒数排名融合 RRF）把两路结果合并排序。两条腿走路，互补短板。

5.6 重排（Rerank）：粗排捞得多，精排选得准

检索出来的候选（哪怕做了混合检索）直接扔给大模型，精度往往还不够——因为向量检索为了速度，用的是"分别编码 query 和 document 再比较向量"的 Bi-Encoder 架构，本质是一种粗糙的近似。

生产级 RAG 几乎都是两阶段架构：先用向量检索粗排，捞出一批候选（比如 Top 50）；再用 Cross-Encoder（把 query 和每个候选文档拼在一起，整体过一遍模型打分，精度高但慢，只能算少量 pair）做精排，从中选出真正最相关的少数几条（比如 Top 5）传给大模型生成。

💡 开发者视角：粗排负责"别漏掉"（提高召回率），精排负责"别塞错"（提高准确率）。很多团队第一版 RAG 效果不理想，往往不是 Embedding 模型选错了，而是省掉了精排这一步——直接把粗排的 Top 5 扔给模型，看似省了一次调用，实际上把噪音也一起喂进去了。

第六章：Agentic RAG——检索这件事，也该交给 Agent 自己判断

面试官： 向量检索出来的结果，直接扔给大模型就完事了？Agent 会不会自己判断"这些资料够不够回答"？

传统 RAG 的检索是"一次性"的：收到问题 → 检索一次 → 生成答案，中间没有反悔的机会。Agentic RAG 的核心变化是把检索也变成一个 Agent 可以自主决策、可以迭代的动作，而不是写死在流水线里的固定步骤。

常见的迭代手法有几类：

查询改写（Query Rewriting）：用户的原始问题往往表达模糊或者带指代（“它上个月的表现怎么样”），Agent 先把问题改写成更适合检索的形式，再去查。
多跳检索（Multi-hop Retrieval）：一次检索的结果不足以回答问题时，Agent 根据已经查到的内容，生成下一步该查什么，链式检索多轮，逐步逼近答案——常见于需要"先查 A，再根据 A 查 B"的复合问题。
Self-RAG / 自我评估：模型在拿到检索结果后，先自问"这些资料够不够回答这个问题"，不够就调整策略再查一次，而不是硬着头皮拿不充分的资料编答案。

这套"按需检索、边查边判断"的思路，和长期记忆系统里"按需换入"的设计哲学是同一件事。一个经典的类比来自 MemGPT（现更名为 Letta）这个项目：它把 LLM 的上下文管理比作操作系统的虚拟内存分页机制——热数据（当前正在处理的、频繁访问的）留在"主内存"（也就是上下文窗口），冷数据（暂时用不上但未来可能需要）“换出"到外部存储（向量库/文件系统），需要的时候再"换入”。模型自己决定什么时候该把哪块内容调进调出，这正是 Agentic RAG 和 Agent 记忆系统天然汇合的地方——记忆负责"存下什么"，RAG 负责"什么时候把它取回来"，Agentic 的部分负责让模型自己判断"取得够不够、要不要再取一次"。三者拼在一起，才是一套完整的、有状态的 Agent 记忆系统，而不是三个孤立的组件。

第七章：工程实战踩坑清单——问到这一步，才是真的在考经验

面试官： 说了这么多理论，你们实际项目里踩过什么坑？

这是最后一问，也是最诚实的一问——前面的答案背再熟也可能是从文档里抄的，这一问只能靠真踩过坑才答得出来。以下几条都是记忆+RAG 系统在生产环境里绕不开的现实问题。

Embedding 模型换版本，历史向量怎么办？ 不同版本、不同厂商的 Embedding 模型，向量空间互不兼容——旧向量和新向量根本不能放在一起比较相似度。换模型意味着全量历史数据要重新计算向量，这是一笔实打实的迁移成本，选型时最好提前想清楚，而不是等数据量上去了才发现要推倒重来。

检索到的内容和最新指令冲突，听谁的？ 检索出来的历史记忆，本质上是"过去某个时刻为真的信息"，可能已经被用户最新的一句话推翻（比如"以前记的收货地址"和"用户这次说的临时改地址"冲突）。生产系统需要在 Prompt 设计上明确优先级——通常是当前对话的显式指令优先于检索到的历史记忆，检索内容应该被当作"参考信息"而不是"必须遵守的事实"喂给模型，这个优先级如果不在系统提示里讲清楚，模型没法自己猜。

每次检索都要调用 Embedding，成本和延迟怎么控？ 高频场景下，把用户查询和常见 chunk 的向量做缓存，命中相同或高度相似的查询时直接复用，能省掉一大截实时调用开销。

没有标准答案，怎么评估 RAG 好不好？ 这是很多团队卡住的地方——没有 ground truth，肉眼评估又不可扩展。业界有一批开源评估框架（比如 RAGAS 这一类）会把"RAG 好不好"拆解成几个可独立打分的维度：答案是不是完全基于检索到的内容（忠实度）、检索出来的内容是不是真的相关（上下文精度/召回率）、答案本身是否回答了问题（相关性）。拆开评估比笼统地"感觉答得不错"靠谱得多。

知识库被"投毒"，间接提示注入。 这是一个真实存在、容易被忽视的安全问题：如果知识库的内容来源不完全可信（爬取的网页、用户上传的文件），恶意内容可以被精心构造成"看起来像正常资料，实则包含指令"的样子混进库里。一旦这段内容被检索出来拼进 Prompt，模型可能把其中的"指令"当真去执行——这就是间接提示注入。防御的第一原则和处理任何外部工具结果一样：检索到的内容永远是数据，不是指令，系统提示里要明确这个边界，对于影响面大的动作（发消息、改数据、调用外部服务），不能仅凭检索内容里的"指示"就执行。

多用户场景，记忆怎么隔离？ 一套 Agent 服务多个用户/租户时，记忆绝对不能串——用户 A 的偏好、历史事件不能被检索进用户 B 的上下文。工程上通常按租户 ID 做数据分区，检索时强制带上租户过滤条件；如果用的是支持多仓挂载的记忆系统，也可以用"一个只读共享库 + 每用户一个专属可写库"的组合，从数据层面就把隔离做实，而不是依赖 Prompt 里一句"不要泄露其他用户的信息"。

结语：记忆不是玄学，是几个经典 CS 概念的重新组合

回头看这七个追问，会发现一个挺有意思的事实：Agent 的"记忆"听起来玄乎，拆开全是计算机科学里的老熟人——短期记忆管理是缓存淘汰策略，长期记忆存储是数据库选型，检索是搜索引擎的经典两阶段架构（召回+排序），Agentic RAG 里"自己判断够不够、要不要再查一次"的循环，本质是操作系统虚拟内存分页思想的翻版。没有魔法，都是把已经被验证过几十年的工程套路，重新组合起来服务一个新的调用者——大模型。

真正的难点从来不在"知道这些概念"，而在于把它们拼对顺序、用对场景：什么时候该压缩、什么时候该剪除；什么记忆该实时写、什么该攒着反思后再写；检索出来的内容该信几分、和用户最新的话冲突了听谁的。这些判断题，恰好就是这场"面试"层层追问的真正用意——不是考你背了多少术语，是考你有没有真正在生产环境里把这套系统跑通过、踩过坑。

这篇是《AI Agent 核心机制》系列的第一篇，和《大语言模型底层原理》系列是接着讲的关系——如果说底层原理讲的是"大模型怎么想事情"，这个系列要讲的是"怎么把一个会想事情的模型，装配成一个真正能记事、会查资料、能持续做事的 Agent"。记忆和检索之外，工具调用怎么设计、多步规划怎么不跑偏、多 Agent 之间怎么协作，都会是这个系列接下来要拆的题目。

如果你也在被类似的问题问住过，欢迎评论区讨论，《AI Agent 核心机制》系列会持续更新，也欢迎把你被面试官问住的问题丢过来，说不定就是下一篇的选题。

本文是《AI Agent 核心机制》系列开篇，承接《大语言模型底层原理》系列——如果你想从头搞懂大模型是怎么"思考"的，请看《别再把 AI 当黑盒：万字拆解大语言模型的底层"暴力美学"》；想看注意力机制的工程实现细节，请看《自注意力中的 QKV 详解》系列。