LinkedIn Hiring Assistant：把招聘要求变成可确认、可持续执行的任务

招聘人员可能在候选名单到来后才发现：系统理解错了资历、把可协商条件当作硬门槛，或把另一个项目的偏好带进来。搜得越快，偏差可能放大得越快。

LinkedIn Hiring Assistant 将早期需求对齐与后续后台执行分开。这个案例的工程重点，是让招聘要求成为可检查的任务依据，让持续运行的任务有状态，让记忆有业务范围，而不是把一段聊天记录反复塞回模型。产品工程架构

先确认条件，再扩大执行

需求接收阶段收集职位、地点、资历和资格要求，并让招聘人员确认；各项条件还涉及负责任 AI 的检查。随后，搜寻能力调用既有招聘搜索和推荐能力，评价能力结合候选资料等证据逐项判断资格，学习能力根据反馈提出要求调整。

“提出调整”与“悄悄改规则”不是一回事。公开架构保留人工审阅批准，让反馈转为新要求之前有控制点。对招聘任务，这条边界很重要：一次拒绝候选人可能只反映当前岗位特定原因，不应未经确认就推广为此招聘人员的永久偏好。

需求确认、候选评价与搜索反馈也各自有责任。评价应该说明与哪些条件匹配、证据来自哪里；搜索反馈可以帮助调整召回策略，却不能把“更容易找到人”自动等同于“标准应该放宽”。公开材料没有给出这种取舍的统一优化公式。

公开能力的输入、输出与人类责任可以具体拆开看，而不只列子代理名称：

表中是官方产品架构披露的能力，不表示每个账户都开启全部渠道和功能。尤其不能从“能发消息”推断所有联络都无需人工控制。

规划与执行分开，执行结果仍可改变后续计划

每名招聘人员对应独立的代理实例、身份和消息邮箱。监督代理根据输入、会话与工作流状态规划任务，再交给执行环节；执行可调用子代理、子图或单一工具，随后重新判断剩余任务。子代理在这里被建模为工具，并不是每个子代理都拥有独立身份和邮箱。

这一区分避免把概念上的“多个代理”误画成多套完整服务。规划层负责任务范围与依赖，执行层负责局部工具使用，重新规划负责处理新信息。实际实现仍要承担指令遵循、误生成及成本延迟等问题；采用 Plan-and-Execute 并不自动证明比其他模式更安全。

对读者而言，更值得观察的是任务边界是否清楚：哪一步需要用户确认，哪一步可以后台继续，哪一个新事件会使旧计划失效？只有把这些问题落到业务对象上，规划才不只是模型写出的一份待办清单。

长任务靠消息生命周期，不靠网页一直开着

LinkedIn 复用了既有消息基础设施：顺序投递、消息历史、持久重试和多线程执行，支撑跨会话的长任务。生命周期服务在消息系统与代理的 gRPC 接口之间做适配，使能力开发者不必直接处理所有消息细节。

能力注册也沿用已有服务契约：开发者在 gRPC 定义上补充平台元数据，由构建插件登记到技能注册服务。注册服务使编排层知道有什么能力、如何调用；它不是靠模型猜测接口名字。

交互请求与异步任务对响应时延和一致性有不同要求。平台文章讨论了同步快速路径与异步消息路径的取舍；不能把一个路径的行为推成所有操作的统一保证。消息系统提供交付基础，也不等于业务动作天然只执行一次。候选联络等有副作用的操作仍需要其产品控制，公开文章没有披露完整幂等协议。代理平台实现

前端显示的是任务状态，不是一串聊天气泡

产品采用客户端 SDK 与 GraphQL 返回带展示信息的数据模型，通过会话级发布订阅通道推送任务和界面变化。流式部分结果让用户不必等全部结束；跨设备、跨会话同步让同一个任务的进度不依附某个浏览器页面。

这说明“用户看到什么”也是代理系统的一部分。已经确认的要求、后台进度、等待人工处理的动作，需要在界面上持续可见。只显示最后一条自然语言回复，用户难以判断系统仍在工作、已经完成，还是正在等自己。

公开资料支持这些机制，但没有给出完整前端状态枚举、事件 schema 或所有暂停/恢复规则。本文不以自拟状态机填补这段空白。

记忆要区分“发生过什么”与“可以用于哪个项目”

LinkedIn 公开的 Cognitive Memory Agent 将会话、经历、语义偏好和程序性知识分别处理。即时写入与较重的批量整理承担不同任务；检索会结合问题、记忆键与工具组织相关内容，而非只有一次向量相似度查询。

这些类型可以帮助解释记忆对象的差别，但不能直接推导 Hiring Assistant 每个页面都使用同一处理链。平台能力与具体产品实现需要分开。认知记忆平台

后续 HLTM 论文披露了 Hiring Assistant 的分层语义记忆。其树按业务归属组织：账户、招聘席位、项目，而不是仅按内容语义聚类。查询先根据身份确定允许检索的子树，再在范围内找信息。这把权限放在候选生成之前；不能只在生成答案时要求模型“不要泄露”。

每个节点有三种视图：

三路检索使用不同的匹配方式：属性视图把问题拆成多个短查询，计算与属性表示的余弦相似度，对每个短查询最相关的 k 项取均值，再汇总为节点分数；问答视图取问题与节点中预生成问题的最大相似度；摘要视图比较查询与单句摘要的表示。各路分别取最相关记忆，将属性集合、问答与摘要合并为答案上下文，并返回作为依据的记忆节点 ID。它不是把命中的原始历史全文重新塞回模型。

这里的预计算把工作从在线阶段前移。属性和预生成问答有利于具体问题，父级摘要帮助回答跨项目的概括请求。三者的互补性需要评价证明，而不是因为名称不同就默认有用。

三路检索各取候选后合并，支持最终带来源的回答；公开机制不是一个已知固定权重的混合公式。索引阶段从叶节点向上聚合，处理重复、冲突和无用内容；源内容变化时更新受影响节点及祖先，避免每次全树重做。

可横向查看，点击打开原尺寸 ↗

图依据 HLTM v3 方法章节重构；业务范围先于检索，三视图用于相关性匹配。它不描述全部招聘服务，也不复制论文原图或提示词。

这个设计有两种不同的“正确”：检索结果属于当前身份允许的范围；内容本身仍准确、及时并有出处。前者不能替后者担保。错误或过时偏好即使没有越权，也可能损害招聘判断。HLTM 论文 v3

评测不能只问“记住了吗”

记忆系统至少要分别检查：信息抽取与覆盖是否正确；检索回答是否相关、完整且有依据；进入招聘产品后是否改善实际任务。这几种指标不能互换，较好的摘要分数不代表候选筛选一定更好。

HLTM 的招聘评价集包含 1,341 项任务，其中 868 项为概括型问题、473 项为检索型问题。论文在 GPT-4o mini 等给定实验设置下，报告概括问题语义正确性为 0.892，对照完整上下文为 0.791、RAG 为 0.770；这是评分，不是候选录用准确率。

消融实验更能说明机制是否必要：去掉树形聚合，检索型 F1 从 0.782 降至 0.618；去掉基于查询模式的适配，降至 0.593；只保留摘要则为 0.730。它支持这批数据下聚合、适配和多视图有贡献，不证明任意业务都需要同样复杂的树。

论文报告其语义质量优于所列基线；这属于特定数据与评价协议下的实验。生产部分描述超过 3,000 次会话、1,000 个招聘席位的使用观察，监督代理在超过 40% 会话中调用记忆；调用记忆的需求对齐会话，负面反馈率低 5–10 个百分点，但不是足以证明所有收益因果关系的随机对照实验。

增量索引也需看对象。论文报告其生产批处理从数天缩至半天量级、减少模型调用与成本，讲的是索引管道，不是每次招聘请求的延迟。把这些数值写成“招聘快了多少”会改变指标含义。

查询模式适配也有具体边界：在一个历史窗口中提取反复出现的问题模式与属性，帮助下一轮问答、属性提取和摘要聚合；设置最小支持要求，避免被单次问题带偏，敏感场景可增加人工审核。它不是每问一个问题就立即改写全局记忆。

评价基准的答案由领域人员标注；模型裁判另外用约 200 项、每项 2–4 名专家的样本检查一致性，κ 超过 0.8 描述的是标注一致性，不是记忆系统准确率。读者若要复现实验，还应固定数据、基础模型和嵌入模型，区分生产 PySpark 管道与论文独立 Python 基准实现。完整线上阈值仍未公开。

平台还区分开发与生产观测：开发阶段借助 LangSmith 查看详细调用和控制流；生产阶段使用符合隐私约束的 OpenTelemetry 结构化轨迹，覆盖模型调用、工具和记忆使用。轨迹再汇成离线评价与回归数据。Playground 允许检查注册能力、历史记忆和不同身份/许可条件，使一部分问题能在上线前复现。它不意味着把真实用户的完整上下文无差别外送到开发工具。

多语言扩展，维护的是规则而不只是译文

另一个容易被低估的工程面是语言。英语提示词更新后，所有语言版本都需要同步；简单在最后翻译输出，会丢失此前没有表达的语法与专业惯例。

LinkedIn 把语言专家确认的规则集中为共享评价规则，分析提示词中依赖语言的元素，按需检索对应规则，再改写成语言感知模板。能力足够时用提示词处理；小模型需要时，在共享基座上按语言训练低秩适配器（LoRA），同一部署在运行时选取对应适配器；各语言可以独立训练、增加、迭代与回滚。任务是否完成和语言是否自然，采用不同评价，专家校准后再扩大自动评测。

这条路径的可借鉴处，是把专业知识变成可复用、可回归的规则，而不是要求每个子代理作者重新发现同一套语言问题。国际化工程

用一个真实招聘项目检查闭环

迁移团队可以拿一个已授权项目，从确认的条件开始追踪：搜索用了哪些条件，候选评价依据是什么，哪条反馈会提出规则更新，谁批准，记忆写进哪个业务范围，另一个项目为何能用或不能用，后台任务在关闭页面后如何恢复可见。

若其中任何一步只能回答“模型会理解”，就还缺少可验证的工程责任。这个案例不要求复制 LinkedIn 的规模；它要求把理解、执行、记忆和权限分别做成能检查的对象。