LinkedIn 为什么要为招聘 Agent 单独造一层"认知记忆"
招聘 Agent 上线后，LinkedIn 团队观察到一个有意思的现象：HR 在与 Agent 对话的过程中，会反复透露自己的招聘偏好，同时还会对候选人的匹配程度给出直接反馈。这些偏好并非一次性表达，而是会跨多个职位持续出现——今天定义一个"高级后端工程师"的标准，明天很可能就会影响另一个相似岗位的筛选逻辑。
换句话说，HR 的招聘偏好具有持久性和迁移性，不是单次会话能覆盖的。
基于这个发现，LinkedIn 决定为招聘 Agent 构建一套完整的个性化记忆层，而不仅仅是维护一次对话的上下文。这套记忆层需要覆盖记忆的完整生命周期：理解什么被摄入、如何被检索、怎样判断上下文相关性、如何组织和持续更新——这正是认知记忆 Agent（Memory Agent）的由来。
四层记忆架构
LinkedIn 的记忆系统并非单一结构，而是拆成了多层，以应对不同类型的用户信息：
- 对话记忆（Conversation Memory）：记录当前会话中用户表达的即时需求和任务目标，信息最新、最实时。
- 情景记忆（Episodic Store）：提供时间维度的查询能力，支持跨时间窗口检索偏好变化。
- 语义记忆（Semantic Memory）：聚合用户在多个产品触点（招聘 Agent、候选人搜索等）上长期积累的偏好特征，是最深层的个性化来源。
三层叠加，构成了招聘 Agent 对每位 HR 的"认知画像"，让 Agent 不只是响应单次提问，而是真正理解这个人一直在找什么样的候选人。
程序记忆：捕捉用户「做事方式」的差异
Praveen Bodigutla 指出，每位用户与 Agent 交互时的权衡取舍和表达偏好都存在显著差异。以招聘场景为例，有的招聘人员更看重候选人的地理位置和工作场所类型，有的则更关注资历和具体职责要求。这种「用户如何完成任务」的方式，就被存储在程序记忆层中。
整体来看，记忆系统呈现一种分层蛋糕结构：对话记忆、情景记忆、程序记忆和语义记忆在不同粒度和精确度上协同工作。
核心挑战：从单一数据流中分离多维信号
Ryan Donovan 随即追问：这四类记忆都来自招聘网站上的讨论和互动，那么从这条统一的数据流中提取各类行为信号的难点在哪里？
Bodigutla 解释说，招聘人员与 Agent 的交互会产生大量数据。以完整招聘流程为例，通常需要先编写职位描述，再反复优化；随后查看候选人列表、给出反馈、联系候选人、筛选归档——所有这些操作的信息都会不断累积。
团队为此设计了专门的摄取服务（Ingestion Service），在运行时和近实时地观察这些交互并进行压缩整合。固定工作流的 Agent 相对容易处理，因为每个步骤的边界清晰可辨。但随着向深度 Agent 和更复杂交互演进，各步骤之间会产生交叉回溯——招聘人员可能先校准候选人，再回头修改职位描述，如此往返多次。
Bodigutla 总结了这中间的核心挑战：
- 边界识别：准确划定会话边界和交互子主题
- 信息组织：在压缩过程中不丢失关键内容
- 可发现性：确保记忆能够被后续检索到
- 时效性处理：当用户在对话过程中改变偏好时（例如临时排除某地区候选人，或改为寻找具备互补技能的简历），系统必须优先处理最新信息
- 冲突解决：当检索到的记忆与当前查询存在矛盾时，需要正确处理
- 低延迟：以上所有操作必须在低延迟条件下完成
多角色招聘与记忆的继承问题
Ryan Donovan 接着提问：招聘人员往往会同时为多个岗位招聘，这是否会导致偏好集合之间的混乱？
Bodigutla 承认存在难度，但同时也带来了积极的偏好迁移效应。他进一步揭示了记忆组织结构背后的设计思路：
我们发现招聘助手场景中天然存在树形结构。例如一位招聘人员有多个招聘项目，每个项目都有各自的偏好——这是最细粒度的叶子节点。再往上一层，可以聚合到招聘人员个人维度。再往上还有队列维度：同公司、招聘类似岗位的多位招聘人员之间存在信息共享。
当系统能够按照数据本身和交互中固有的结构来挖掘和组织信息时，就会产生意想不到的价值。对于新入职的招聘人员来说，他们无需从头开始，系统已经提供了一份蓝图——告诉他们公司在同类岗位招聘过程中的优先级排序和偏好表达方式。
统一的记忆编排层
当被问及如何在多样化的应用场景中构建统一的记忆平台时，Praveen Bodigutla 的思路是将通用能力标准化，将个性化空间开放给上层应用。
核心设计逻辑：
- 记忆编排层（Memory Orchestration Layer）：负责信息的读取、写入、推理与合成，接口固定、流程标准化。这套工作流在所有应用中保持一致，确保记忆的获取与推理路径稳定可靠。
- 记忆结构本身则允许定制：以招聘场景为例，记忆结构是清晰的树状层级（按项目、团队分组偏好），但在社交类或关系图谱类应用中，可能更适合图结构。应用方可以自行设计长期记忆与偏好的组织方式，只要通过标准工具接口暴露出来，整个编排与推理层无需改动即可兼容。
可插拔的记忆结构
关键在于"标准接口"这一设计选择：即便底层数据结构不同，只要暴露方式统一，上层的编排层、推理层、合成层就完全不用调整。这意味着同一套平台能力，可以跑在截然不同的记忆结构之上。
差异主要体现在：
- 长期记忆表示：不同应用对"什么值得长期记住"有不同定义。
- 情节边界（Episode Boundaries）：招聘场景中，单次交互信号清晰、噪声低，边界就是单次行为；而有些场景中，一次完整活动会跨多个阶段，情节边界就变成了多阶段。
记忆的分类与合成
系统中的记忆大致分为三类：
- 情景记忆（Episodic Memory）：原始交互记录，保留粒度。
- 语义记忆（Semantic/Consolidated Memory）：经过离线整理任务合并、去重、补充外部信息后的结构化记忆。
- 程序记忆（Procedural Memory）：从交互中推断提取的结构，需要时主动"挖掘"出来。
整个记忆流动路径：摄取服务（Ingestion）→ 离线整理任务（Consolidation）→ 检索服务（Retrieval），中间经过编排层统一调度。
相关性判断：摄取与检索的双重逻辑
Ryan Donovan 追问了一个核心问题：系统如何判断什么是"相关的"？这实际上涉及两个不同的相关性维度。
维度一：摄取相关性——哪些信息值得进入记忆
不同于传统 RAG"尽可能提取全部内容"的思路，Praveen 强调领域专业知识在摄取阶段就介入判断：
- 应用场景决定信号来源：招聘场景中，系统需要识别招聘者在哪些产品界面上表达了偏好、表达了什么类型的偏好。
- 设定可衡量的终局目标：例如招聘效率是否真正提升、摩擦是否降低，这成为判断"什么值得记忆"的依据。
- 透明度优先：绝不默默聚合偏好，否则招聘者可能事后否认"我根本没说过这个"。这引出了溯源（Traceability）机制——每条被合成的偏好都标注来源。
维度二：检索相关性——从记忆库中提取什么
摄取阶段决定了记忆库的内容质量，检索阶段则决定最终呈现给应用的内容。两者共同构成"相关性"的完整定义：入库前过滤 + 出库时匹配，而不是一股脑把所有可能相关的内容都塞进上下文。
AI 记忆系统的三重挑战：采集、评估与检索
个性化偏好与引用机制
系统将用户的偏好表达视为一类特殊的"引用型记录"（type citations）——每条记录不仅包含用户做了什么，还附带"为什么系统判断这是用户特定偏好"的依据。这些引用记录构成了个性化领域情报的核心，使 AI 能够回溯信息来源，确保答案可溯源、可解释，而非黑盒输出。
团队正在推进一项用户控制功能：未来用户可以主动声明"这条偏好已不再适用，请遗忘"，或主动补充"我还学到了新的偏好，请一并记住"。系统将提供相应入口，允许用户以键值对形式添加或修正个人信息。
三层评估与持久化质量保障
信息写入记忆层之前，系统会经过三层评估（three-tier evaluation）：
- 第一层：确保信息不丢失——用户输入中的实体与关键事实，在持久化时必须完整保留；
- 第二层：验证引用准确性——每个记忆节点都附带来源依据，支持后续回溯；
- 第三层：衡量对任务的实际帮助程度——系统追踪"是否减少了对话轮次"、"是否提升了关键结果"等指标，以此评估记忆的实用性。
这一评估机制同时服务于透明度目标：用户能够看清"系统为何做出某个推荐或判断"，而不只是得到一个结论。
标准检索与动态查询的取舍
从检索侧看，场景分为两类： 可预见的标准模式：例如招聘人员每次登录时，系统会主动拉取其全部已知信息——这类检索可以预聚合、缓存，降低每次的响应成本。
不可预知的动态模式：例如招聘人员正在浏览某候选人的简历，突然想起"我之前给类似候选人提过相似的反馈吗"，这类跨上下文、跨时间的关联查询无法预先缓存。系统必须根据用户当前工作流阶段和实时表达的偏好，实时提取最相关记忆片段，降低噪声、提升信号密度。
这也是区别于传统 ETL 管线的关键所在：系统不能简单存储所有活动记录，否则会造成上下文膨胀（context bloat），反而损害决策质量。
偏好冲突与动态加权策略
当同一偏好被用户反复表达时，系统是否将其视为"更可靠的信号"？当前实现中，多次出现的偏好本身已具备足够价值，系统通过层级优先级和冲突解决策略来处理多层记忆之间的矛盾。
然而更复杂的探索方向是：权重 scheme 能否根据用户重复表达的行为动态演化。团队关注的不是"偏好表达的次数"，而是"重复表达是否意味着系统引入了摩擦"——如果用户反复纠正同一偏好，说明系统没有正确合成已有信息，反而造成了困扰。
下游的第三层指标会捕捉这类摩擦：系统会对比"信息不加区分地全量召回"与"经过优先级加权后精准呈现"两种策略的实际效果，找到"减少认知负担"与"保持信息完整性"之间的最优平衡点。
LinkedIn 个性化记忆的访问控制与隔离机制
Praveen Bodigutla 详细介绍了 LinkedIn 在记忆层如何实现数据隔离与权限管控。
多租户隔离与身份验证
LinkedIn 为每次应用内存初始化都配置独立的数据存储，不同应用之间完全隔离，不存在跨租户复用数据的情况。此外，系统会核验登录用户身份，确保其只能访问自己对应的那部分记忆，超出权限范围的数据一概不开放。
记忆以层级结构组织，每个节点都附带所有者标签。所有工作流步骤中，系统都会携带正确凭证传递，以确保信息只流向有权限访问的用户。
个性化与共享的平衡
这套架构实际上为每位用户提供了个性化记忆，同时允许在合规条件下与同群组用户共享，形成针对特定领域的个性化智能（domain intelligence）。两种模式可以在设置中统一管理，无需两套独立系统。
工程优化：从 GraphRAG 到树形结构
放弃 GraphRAG 的原因
团队最初采用 GraphRAG 构建长期记忆并建立索引，但很快发现两个致命问题：速度慢、成本高。GraphRAG 每次重建索引都需要大量 LLM 调用来识别节点间的关联，无法支撑 LinkedIn 的数据规模。
增量更新策略
树形层级结构带来了显著优化机会：当某个叶节点、分支或特定节点需要更新时，系统只需沿该分支向上传播变更，无需重算和重建整个记忆索引。这极大降低了计算开销。
在检索侧，智能检索层会识别记忆的更新时间戳，结合优先级队列来解决数据冲突，确保向用户及应用 agent 提供的始终是最新的记忆内容。
成本与确定性优化
检索编排的并行化改造
编排层本身是一个"规划合成 LLM 层"，负责在记忆检索后进行复杂推理。团队发现，将顺序规划改为单步并行规划效果更好——系统基于历史信息判断该用户最活跃的数据表面，一次性并行调用所需的记忆工具集，而非逐个串行触发。
选择性 LLM 调用
并非所有查询都需要完整的推理流程。如果用户请求只是拉取记录，且对话中已有足够上下文，系统直接返回结果，无需再次触发复杂推理。这种选择性调用策略显著减少了不必要的 LLM 消耗。
综合来看，LinkedIn 通过层级记忆结构、增量更新、并行规划与选择性推理四项工程决策，在保证记忆新鲜度与一致性的前提下，实现了大规模场景下的成本可控与低延迟响应。
内存延迟与 Agent 记忆的未来方向
延迟预算：内存仅占 10%~20%
对话中指出，内存 Agent 在整个应用响应延迟预算中所占的比例非常有限。由于应用需要从多个来源抓取信息并综合响应，内存操作通常只能分配到总延迟预算的 10% 到 20%。这意味着内存层的每一个设计决策都必须以低延迟为前提。
推理引擎层面的优化手段
为控制延迟，团队在 vLLM 服务引擎层面引入了多项优化：
- Prefix Caches（前缀缓存）：重复利用已计算的前缀结果，减少冗余推理。
- Chunk Prefills（分块预填充）：将长序列切分为小块预加载，降低首 token 延迟。
这些手段共同作用，显著压缩了端到端响应时间。
结构化输出：减少无序推理 token
对话还强调了结构化输出的重要性。如果放任 LLM 自由生成任意长度的推理 token，延迟会随之飙升。通过提供清晰的 API 规范，引导 LLM 按照预定格式生成内容并限制 token 数量，能够在保持输出质量的同时有效控制延迟。
未来研究方向
记忆持久化层与抽象
团队正在探索记忆持久化层的不同实现方案，以及向 LLM 提供记忆访问的抽象接口。随着 LLM 能力持续增强，"LLM 自己管理记忆"正成为可能——需要设计一套完整的记忆生命周期管理框架，支持动态调整底层存储（例如切换至虚拟文件系统），同时保持上层接口的稳定性。
归因与评估难题
归因（attribution）是当前最具挑战性的问题之一：应用 Agent 获取的信息来源多样，评估其准确性和来源可靠性需要建立稳健且具有代表性的评估体系，以捕捉用户交互模式的变化。
会话边界识别与 compaction
另一个重点方向是动态识别会话边界、对历史会话进行压缩（compaction），以及从端到端视角而非单层视角进行整体优化。
学术进展
相关研究成果已发表在 KDD 会议，团队鼓励读者关注他们的论文发表和后续博客更新。
评论