Inside LinkedIn's cognitive memory agent for agentic personalization

深入解析LinkedIn用于自主个性化的认知记忆代理 - Stack Overflow

2026年8月25日

深入解析LinkedIn用于自主个性化的认知记忆代理

Ryan邀请LinkedIn首席AI研究员Praveen Bodigutla进行对话，探讨其团队构建的四层记忆系统，该系统为LinkedIn的招聘助手提供了持久且个性化的状态。

[

Praveen解释了其团队为何放弃GraphRAG，转而采用树状结构记忆以实现更快的增量更新，并分享了他们在LinkedIn规模下如何平衡检索新鲜度、延迟预算和访问控制的实践经验。

在LinkedIn上联系Praveen。

祝贺Populist徽章获得者Luka Ganić，他关于"在Flutter中将SVG图像作为按钮"的回答质量如此之高，甚至超越了被接受的答案！

TRANSCRIPT

Ryan Donovan (00:00)

大家好，欢迎收听Stack Overflow播客，这里是讨论软件和科技相关话题的场所。我是主持人Ryan Donovan，今天我们讨论的是LinkedIn构建的一个非常庞大的自主记忆系统。我的嘉宾是Praveen Badagutla，他是LinkedIn的首席AI研究员。

Praveen Bodigutla (00:35)

感谢邀请，很高兴见到你，Ryan。

Ryan Donovan (00:37)

是的，很高兴你能来。在进入今天的主题前，请告诉我们你是如何进入软件和科技领域的。

Praveen Bodigutla (00:47)

如我所说，我是LinkedIn的首席AI研究员，领导着包括记忆代理在内的多个基础性项目，同时还是多个AI产品的创始工程师，负责企业端和消费端的产品开发。我到达现在的职位之路并不线性，我最初

Ryan Donovan (01:08)

嗯。

Praveen Bodigutla (01:09)

是在很久以前的Yahoo担任平台工程师，那时我刚完成计算机科学和经济学的本科学习。之后我在斯坦福和纽约大学完成了金融数学和数据科学的硕士课程，有机会与Andrew Ng、Kyun Kyoon Chou和Jeffrey Ullman等知名教授合作。我过去曾是纽约投资银行的量化开发人员，之后加入Alexa从事对话模型研究。

我职业生涯的核心主题始终是AI创新和平台建设

Ryan Donovan (01:51)

嗯。

Praveen Bodigutla (01:52)

让这些创新转化为对终端用户有用的产品。

Ryan Donovan (01:58)

是的。我认为今天我们讨论的内容在很多人关注的自主记忆和上下文层领域是一个重大创新。你们团队构建了一个完整的认知记忆代理来实现某种功能，能否给我们简单介绍一下这个项目的概况？Praise.

Praveen Bodigutla (02:25)

好的，

让我们从为什么构建认知记忆代理开始讲起。

Ryan Donovan (02:30)

是的，这是个很好的起点。是的。

Praveen Bodigutla (02:32)

So LinkedIn has developed and successfully launched this hiring agent or hiring assistance for the recruiters to manage their hiring workflows. And what we observed was through these interactions that the recruiter had with these agents, they expressed some of their hiring preferences and also they refined the role that they're hiring for.

Not only do they mention like where they are hiring for and also what are the skills that they're interested in, they also give direct feedback on the candidates that were shown to them. So what we observed was there is stickiness to these preferences, which actually translate to how they define a role on similar titles and other roles that they're hiring for. So in order to provide this really true agentic experience for recruiters.

We wanted to provide this personalization layer, and that is the genesis of the cognitive memory agent, which gives this concept of state for our

Ryan Donovan (03:32)

Praveen Bodigutla (03:33)

for our agents, which the users, which in this case are recruiters who were interacting with that. And why a memory agent is because we wanted to not just fetch context, but also manage the entire life cycle of memory or the whole memory flywheel, starting from

Understanding what's ingested, what's retrieved,

Ryan Donovan (03:54)

Praveen Bodigutla (03:55)

how it is contextually relevant, and how is it even organized and updated. So the memory agent basically manages this entire flywheel and provides this deep personalization for our end users. And that was the reason why we developed the memory agent.

Ryan Donovan (04:13)

Yeah. And I I think it's it's interesting you mentioned state and it's not just a sort of session conversational state. It's not just a sort of preferences state. Like it's a a whole it's a three layer sort of burrito of state here. can you talk about the what those three layers are and and and why you needed three layers?

Praveen Bodigutla (04:37)

Right, so the three layers or like the four layers or rather the memory that we use within our memory agent are one of them is the conversation memory, which is let's say you and I are interacting right now and we are expressing our preferences in terms of like different the tasks that we are trying to achieve. So that's most recent and that's up to date, and that's the information we have. Then we have on the other end our semantic memory layer, which is

the aggregated information of the user based on the interactions and preferences that they have expressed across sessions. And as you know, on LinkedIn we have different product offerings and different surfaces where the users interact with, and recruiters not only use the hiring assistant agent but also use a search platform to look for candidates. So they express those preferences there. So we want to make sure that.

The experience that the users have is we know what they're looking for and we are personalizing the whole experience for them. So the the semantic layer aggregates information not just across different interactions that the user has with the agent, but also they're based on their activities that they have on related product services as well. Now, in between, we also have the episodic store, which gives this temporal querying layer where

我们可以识别出用户最近进行的相关活动。因此，它不仅提供了信号的精确性，还提供了信息来源。假设我们汇总信息后，现在可以追溯到哪些活动促成了我们得出用户偏好的结论。最后但同样重要的是程序性记忆层。每个用户、每个招聘人员，如果他们实际上正在与代理交互，即使他们正在招聘类似职位，他们的交互方式、权衡取舍以及表达的偏好都大不相同。有些人可能更重视工作地点和工作类型，而另一些人则可能更关注职位级别和职位的具体方面。因此，用户完成这些任务（在这种情况下是招聘工作）的具体方式被记录在程序性记忆中。

记忆就像一个分层的蛋糕，包括对话记忆、情景记忆、程序性记忆和语义记忆，它以不同的粒度和精确度捕捉信息。

Ryan Donovan (07:09) 嗯，你知道的，状态大致分为三个终点桶，或者四个。但所有内容基本上都来自单一数据流，对吧？也就是网站上的讨论和互动。提取这些独立的行为状态标记的挑战是什么？

Praveen Bodigutla (07:38) 对，如果你观察对话流，这里有两组不同的数据源。第一组，假设是招聘人员或用户与代理的互动。如果具体讨论这一点，随着你积累这些互动，上下文可能会变得臃肿。例如，考虑一个包含多个步骤的招聘流程。首先，你需要从职位描述开始，然后细化职位描述。接着你将看到某些候选人，并对这些候选人提供反馈，然后联系某些候选人，偏好一些并归档其他。所有这些信息都会累积起来。在运行时，我们需要确保这些信息被正确压缩。我们有这个摄入服务，它在实时和近实时地查看这些互动时，会尝试进行整合。在固定工作流代理中，这相对容易一些，因为你知道工作流中每一步的边界。但随着我们转向更深层次的代理和更复杂的交互，这些步骤可能会相互关联。用户可能首先从校准候选人开始，然后返回去细化，然后在这些步骤之间来回切换。因此，识别正确的会话边界、识别正确的交互子主题，然后组织记忆并确保其可检索性。因此，这个数据流本身具有挑战性，因为你必须确保你已经压缩了数据，没有丢失信息，并且准确地表示了持久化的信息。最后但同样重要的是，我们还需要检索这些信息。现在

Ryan Donovan (09:24) 对。

Praveen Bodigutla (09:24) 当这个互动进行时，我可能会改变我的偏好。我可以说，你知道的，

Ryan Donovan (09:29) 嗯。

Praveen Bodigutla (09:29)

我不希望在这个特定地点招聘。也许我们其实应该寻找其他技能的人。

也许应该寻找具有互补技能的人。因此，当在对话过程中表达某些偏好时，这就引出了这样一个概念：嘿，我们如何确保最新、最及时的信息优先？如果在我们检索记忆并回答用户通过应用代理提出的问题时

Ryan Donovan (09:50)

是的。

Praveen Bodigutla (09:50)

出现任何冲突，这些信息必须准确、最新，并且冲突要正确处理，最重要的是还要保证低延迟。

Ryan Donovan (10:07)

是的。我想象着像这样的系统，招聘人员可能同时在为多个职位招聘。是否存在某种困难或复杂性，比如在多个偏好集合下同时进行招聘？

Praveen Bodigutla (10:25)

确实存在困难，但同时也有从相似职位集合中继承偏好设置的便利效果。现在，当我们讨论这个挑战时，首先需要理解我们的数据或偏好/记忆是如何组织的。在招聘助手的场景中，我们拥有天然的树状结构。

对于一些招聘偏好而言，例如，招聘人员可能有多个正在招聘的项目，每个项目都可以有其独立的偏好设置。这就是最细粒度的叶子节点。然后可以在招聘人员层级上聚合这些偏好。接着你还有这个群体，比如多个招聘人员。假设他们属于同一家公司，正在招聘相似的职位，他们会在不同群体成员之间共享信息。因此

当我们挖掘这些信息并进行组织时，这种组织方式与数据本身固有的结构以及交互方式相一致，实际上可以成为你的超级能力，帮助新加入的招聘人员快速启动对话。他们不需要从零开始，而是已经拥有公司如何根据职位和表达的偏好进行优先级排序的蓝图。

通过他们在同一群体成员之间的招聘流程和工作流程。

Ryan Donovan (11:55)

嗯，这确实是个很好的过渡。你提到这些信息是以树状结构存储的。那其他层级是如何处理的？是否存在统一的存储结构，还是说每个层级都是不同的工程问题？

Praveen Bodigutla (12:14)

是的，让我们先看看什么基本结构能适用于所有人，因为我们正在构建一个平台。我们并不是试图为每个不同应用重新设计和发明全新的记忆平台。是什么让每个应用都独一无二？如果记忆设计本身，我们的记忆代理是土地图代理，它使用某些工具来访问这些记忆层级。现在这些工具是非常通用的。

与我们实际读取和写入情景存储的方式类似，用于访问这些内存层的签名或API是固定的。然而，由于我们使用了工具，可以覆盖部分描述并根据特定应用程序、偏好和逻辑自定义数据存储方式。因此，这就是关于你如何规划和推理的记忆编排层。

该流程在标准化方面是固定的，即在响应前如何获取和推理内存的流程是统一的。就内存结构本身而言，在招聘代理的案例中，我们有一个清晰的基于项目和小组的偏好树状层次结构。然而，对于其他需要以图结构进行组织的应用场景，这种层次结构可能并不适用。例如，如果我与个人之间存在连接，但并非明确的层次结构，他们可以自行设计长期记忆结构和偏好结构并使其可用。但一旦通过标准接口或工具暴露了该结构，它就变得可查询了。由于我们了解如何查询，因此该结构也变得可发现。编排层、推理层以及合成层保持不变。

以个体表示为例，长期记忆通常会变化。事件边界可能不同。例如，在某些情况下，如招聘代理案例中，由于信号强度高，活动是单一的。我们希望减少噪声，提高信噪比。但在某些情况下，该活动可能跨越多个时间段。因此，这成为事件边界，以及需要持久化的数据。而保守记忆在结构上基本保持不变，因为这是我们正在合成的交互。程序性记忆是推断出的记忆。其中一些结构是基于应用相关性提取的。因此，这需要在应用层面提供一定程度的自定义能力，同时在平台层面提供基本的设计原则，这些原则非常稳定、通用，并能扩展到不同的应用场景和解决方案中。

Ryan Donovan (14:23)

Praveen Bodigutla (14:24)

正确。如果我理解正确，您是说所有内存层在进入最终应用之前，都会先经过某种形式的记忆编排处理，对吗？

Praveen Bodigutla (15:24)

是的。我们有专门的摄入服务，还有检索服务，以及离线整合任务，该任务整合所有信息，去除重复项，与外部数据源进行连接，补充额外信息，删除过时、重复和冲突的偏好信息。然而，整个记忆部分（包括管理记忆部分）都会经过摄入、组织和检索流程。

因此，长期以来，人们显然通过RAG（检索增强生成）或某种类型的向量数据库，从AI和代理中获取上下文和参考信息。这似乎涉及从多个来源提取信息、整合、聚合并判断哪些信息是有效的。

如何确定来自每个单独记忆存储的信息以及从这种聚合记忆块（或其他形式）中哪些信息是相关的？

Praveen Bodigutla（16:42）

是的。我认为当我们谈论相关性时，实际上涉及相关性的两个不同方面。第一个问题是：你从哪里同步所有信息？你如何知道这些信息是需要摄入并成为你记忆一部分的相关信息？第二个问题是：你如何检索相关信息？这通常与传统的RAG有何不同？

在传统的RAG中，我会提取所有信息，然后将其作为上下文提供给应用程序代理进行处理。从摄入的角度来看，领域专业知识会发挥作用，因为这个应用程序代理是为了解决特定问题而设计的。在这种情况下，招聘人员正在招聘并寻找候选人填补职位空缺。我们现在关注的要点是：我们需要消费哪些不同信号，这些信号反映了招聘人员表达的偏好。

最终目标是什么？我们如何衡量这一点？例如，我们是否真正提供了正确的记忆抽象，确保这是一个高效的架构，同时减少摩擦，使他们在招聘时更加高效和富有成效？这是我们使用的一个关键原则。例如，招聘人员与哪些不同的产品界面进行交互？他们在这些界面中提供了哪些类型的偏好？

我们如何实际综合这些信息？我们还希望让这个过程透明化。我们不想仅仅聚合信息，因为招聘人员可能表达过偏好，但后来却说：“我其实没有说过这个。”

Ryan Donovan（18:17）

Praveen Bodigutla（18:18）

这就是显着性空间（prominence space）和可追溯性（traceability）方面的重要性。

Ryan Donovan（18:21）

Praveen Bodigutla（18:21）

当我们摄入特定的细粒度信息到我们的事件存储中时，无论我们综合了什么信息，无论我们提供了什么信息，这都是你的偏好档案，这是你的偏好图谱，以及你的领域智能，个性化的领域智能。每种信息都带有类型引用，这些是实际记录，你可以说“这就是你做过的事情”，并解释“为什么我们认为这是你的特定偏好”。未来，我们还计划赋予用户更多控制权，当用户可以明确表示“我不再认为这是适合我的偏好，请忘记这一点”，或者“记住更多我尚未意识到的偏好，并让我提供帮助”。

他们可以在这里添加这些键值对或信息。这是从摄入的角度来看的。我们还有一个评估场景，例如我们有三层评估。当我们将信息持久化到记忆中时，我们确保信息不会丢失。例如，无论输入信息中存在哪些实体，当信息被持久化时，这些信息都会被保留，并且有相应的证明和引用。

确保我们为持久化存储的内存配备高质量的评估者，这使我们有信心确认这些信息确实是需要聚合、积累和综合以帮助招聘人员完成任务的正确信息。同时，透明性方面也能帮助他们了解我们为何做出某些决策。从检索的角度来看，情况变得有趣起来。

应用程序代理在查询内存时会使用一些标准模式。例如，每当招聘人员登录时，第一步就是获取所有信息。我们对此是清楚的，可以预先聚合、创建缓存并提供使用。但还有一些非标准的模式，这些模式更加动态。例如，招聘人员会从一个方面或工作流程步骤转移到另一个步骤，同时交错表达偏好并覆盖之前的偏好。因此，从检索的角度来看，现在需要根据他们表达的偏好提取正确的信息。例如，如果他们问：“我之前是否对类似活动给出了类似的反馈？是否有候选人曾收到过类似的反馈？当时我在技能方面的偏好是什么？”

这些查询我们无法提前预料。但因为我们有分层的内存结构，以及

Ryan Donovan（21:05）

Praveen Bodigutla（21:06）

可以像进行某种时间查询或基于EBR的检索。现在我们知道招聘人员处于工作流程的特定步骤，这是他们提供的上下文。基于上下文，提取最相关的信息，减少噪声并增强信号，然后将这些信息返回，使应用代理能够做出

更加精准的决策，并为招聘人员提供更有价值的信息，而不是仅仅提取所有活动信息，这可能导致上下文膨胀。

Ryan Donovan（21:38）

当然，是的。你们有没有做类似双重计数的处理？如果某人多次表达偏好，你们会认为这是更可靠的选择吗？还是说只是简单地认为这与我们已有的记录一致？

Praveen Bodigutla（21:57）

目前来看，即使不进行内部优先级排序，仅通过回忆这些信息就能带来巨大价值，即使在不同偏好之间没有明确的优先级。我们有优先级划分和冲突解决策略，用于优先使用某一层内存而非其他层。

不过，我们正在研究如何根据用户多次表达的偏好，动态调整权重方案。首先，我们不希望用户反复表达相同的偏好，这会引入摩擦。例如，如果我们未能正确综合

Ryan Donovan（22:43）

对，对，对。

Praveen Bodigutla（22:47）

并提供错误信息，他们可能会说：“不，不，在那个位置不对。”

Ryan Donovan（22:52）

Praveen Bodigutla（22:52）

其中一个下游指标，比如

我们称之为第三层级指标，它不仅衡量这种对产品的帮助性和影响，还衡量摩擦。这就像，我们是否真的减少了交互轮次？是否增加了术语数量？这是我们不得不做出的权衡。比如，如何在召回率和无需等待之间取得平衡，同时在信息的实用性与优先级排序、额外认知层和加权处理之间取得平衡，这可能会给成员带来更大的认知负担。

Ryan Donovan (23:26)

嗯。我的意思是，这些层级和你提到的提取与转换，听起来越来越像一个面向代理时代的ETL流程。这个说法准确吗？这里是否存在额外的复杂性？

Praveen Bodigutla (23:48)

我认为这些额外的复杂性正是它成为代理时代ETL流程的原因，其中

Ryan Donovan (23:53)

哈哈。

Praveen Bodigutla (23:54)

与其只是存储所有数据，我们必须非常谨慎，确保如我所说，我们捕捉的是有效信号而非噪音。

Ryan Donovan (24:06)

Praveen Bodigutla (24:07)

这正是使这些方面具有代理特性的地方，无论是从数据摄入还是从

检索角度来看，我们都能捕捉到正确的信号，并以易于发现、维护的方式组织数据，同时提供必要的治理和访问控制，从而实现安全的检索和管理，避免上下文污染，也防止信息从不应泄露的地方意外泄露。

Ryan Donovan (24:39)

Praveen Bodigutla (24:40)

这些地方的信息泄露。没错。

Ryan Donovan (24:44)

没错。所以你刚才的过渡非常自然，Raveen。我喜欢。你知道，LinkedIn是一个相当大规模的平台，有大量用户和大量个人数据。你提到了访问控制、安全性和防止信息泄露。你们在系统中构建了哪些功能来确保数据只流向正确的位置？

Praveen Bodigutla (25:11)

当然。我们实现了数据存储的多租户隔离。每当为某个应用设置内存时，我们希望确保每个应用都有自己的独立数据存储，不会复用其他应用的数据存储。因此，数据存储之间有明确的隔离。我们还确保登录的用户基于其身份验证凭据访问其应访问的内存，而不会越权访问。当我们以我之前提到的分层结构购买这些内存时，我们也会标记拥有访问权限的所有者。因此，在工作流程的每一步，我们都确保传递正确的凭据，以访问正确的信息，并且限制用户只能访问其有权访问的信息。

Ryan Donovan (26:07)

所以，可能不是每个用户都有一个完整的内存系统，但听起来已经非常接近了，对吗？

Praveen Bodigutla (26:17)

它为每个用户提供了个性化的记忆体验，同时在允许的情况下帮助他们与群体分享，并创建特定于该群体的领域智能，即针对该群体的个性化领域智能。因此你可以

Ryan Donovan (26:36)

Praveen Bodigutla (26:37)

在我们拥有的这种优美、树状结构的设置中同时管理这两者。

Ryan Donovan (26:43)

是的。我想谈谈这里的工程权衡，因为这似乎需要存储和检索大量额外数据，管理起来可能很复杂。你有没有考虑过优化策略，比如如何清理不再需要的数据？如何实现扩展？

减少接触成本，所有这些好的方面。

Praveen Bodigutla (27:14)

当然。说实话，当我们最初使用一些流行技术来创建我之前提到的长期记忆并进行索引时，我们使用了GraphRag。但后来我们意识到它既慢又不经济，因为它需要大量LLM调用以识别不同节点之间的关联，每次重建索引和重新创建记忆时

Ryan Donovan (27:34)

Praveen Bodigutla (27:34)

都导致我们无法在LinkedIn当前的规模上实现扩展。这种树状分层记忆结构帮助我们实现了增量更新优化，我们知道哪些叶节点、哪些分支以及具体哪些节点需要更新。我们只需沿着树的分支传递这些更新偏好，而无需重新计算和重新索引整个记忆。正如你正确指出的，新鲜度和一致性对我们非常重要。我们通过以下方式处理：我之前提到过，当检索层具备智能时，它会知道某段记忆是在特定时间点更新的，并按照优先级队列或优先级顺序解决数据中固有的冲突，利用这种智能确保向最终用户和与用户交互的应用代理提供正确、最新且相关的记忆。从摄入端来看，我们在之前讨论记忆压缩时提到过这一点。我们关注这些

Ryan Donovan (29:03)

Praveen Bodigutla (29:03)

即将进入的术语队列，当我们在提取这些活动并基于用户最近的活动做决策时，最新信息就包含在其中。有时通过简单的策略，比如如果某个信息超过特定时间范围（如六个月或一年）仍然有效，因为此时你已经

Ryan Donovan (29:30)

Praveen Bodigutla (29:31)

将这些信息整合到长期记忆中，它仍然可用。使用这些策略也有助于确保

记忆保持新鲜且

Ryan Donovan (29:40)

Praveen Bodigutla (29:40)

具有代表性，与用户当前正在做的事情相关。从一致性角度来看，我认为我们在讨论从不同数据源同步数据、识别相关数据源并将其作为长期记忆的一部分时已经涉及过这一点。

Ryan Donovan (29:57)

是的，你提到从图结构的RAG转向更树状的结构，以减少LLM调用次数。除了这一点，你们还做了哪些工程优化来减少这里的AI使用量，提高确定性，从而节省成本？

Praveen Bodigutla (30:17)

当然。我们的检索层或编排层本身就是一个计划合成器LLM层，它会通过检索到的记忆进行推理，以回答这些复杂查询，比如洞察和示例，例如“我正在做出哪些权衡”。你需要将所有相关信息都提取到该层。我们发现通过简化规划层可以实现优化。

不再采用顺序规划，而是采用一步并行规划，通过识别出正确的记忆工具集合来解决特定用户的查询，这些工具的选择基于历史信息，比如我们存储数据的位置，以及不同用户最活跃的交互界面。然后对响应合成进行选择性LLM调用。

如果查询只是获取记录，那么可以仅基于对话中已有的信息回答，不需要再次调用复杂的推理过程来处理所有记忆。因此，我们非常谨慎地设计这种编排方式，确保规划时间减少，信息能够被正确且低延迟地检索。

对应用代理而言，需要记住作为记忆代理的我们拥有的延迟预算，可能只占整个应用响应延迟预算的10%到20%，因为记忆只是上下文的一部分。应用需要从不同来源获取信息来合成响应并呈现给用户，因为他们的目标是完成任务。

所以，我们必须非常谨慎地设计这个架构，确保它能提供上下文相关的记忆，同时保持低延迟。在VLLM服务引擎层面，一些优化推理的优化措施，比如使用前缀缓存、分块预填充等，都对减少整体延迟有很大帮助。

最后但同样重要的是，对响应结构的使用要有明确的偏好。比如LLM，

如果允许其随意生成任意数量的推理token，可能会导致延迟增加。因此，

提供一个清晰的API，要求输出遵循结构化格式，同时引导LLM按照该格式生成内容并限制token数量，这也有助于减少整体延迟。

Ryan Donovan (32:48)

对，对。

Praveen Bodigutla (32:51)

现在我们已经进行了33分钟的讨论。如果你还有想补充但尚未提及的内容，可以趁这个机会讲一讲。否则，我可以问一些更具未来视角的问题。

Praveen Bodigutla (33:19)

我认为未来方向的问题确实很有趣。是的。

Ryan Donovan (33:25)

好的，让我来为你准备这个问题。是的，是的。

S 所以你之前稍微提到了一些未来想要解决的问题。那么，除了这些之外，你接下来最想解决的还有什么重大问题呢？

Praveen Bodigutla (33:43)

没错，实际上我们正在从内存持久化层等多个层面进行投资和探索，

Ryan Donovan (33:53)

Praveen Bodigutla (33:53)

以及我们希望为内存访问提供的抽象层。之所以重要，是因为随着大语言模型（LLM）变得越来越强大，我们将进入一个时代——我意思是，LLM正变得越来越强大，它们

Ryan Donovan (34:07)

Praveen Bodigutla (34:08)

也能够管理内存。但与此同时，你希望使用内存代理来管理整个内存生命周期。鉴于这些LLM或深度代理现在允许用户进行的交互具有动态性，如何为内存提供超越各层工具的抽象写法，使内存易于发现，并通过更改底层存储层（例如虚拟文件系统）来提供额外的优化层？这是我们现在重点投资的领域之一。此外，评估也是我们目前面临的最大挑战之一，即归因问题。正如我所说，应用代理不仅获取内存，还会从不同信息源获取信息。因此，

我们正在投资于稳健的评估和具有代表性的评估策略，以捕捉交互模式的变化。这是另一个我们正在积极投资的领域，以及通过动态识别会话边界、进行压缩并优化整体端到端流程（而不是单独优化各层）来实现进一步优化。

这些都是令人兴奋的应用研究和创新领域，我们对此充满期待。

Ryan Donovan (35:47)

好的，那我们进入结尾部分。我要表扬一位在Stack Overflow上获得徽章的人，然后我会说出我的名字、职位、行动呼吁，以及我在互联网上的联系方式，你也可以这样做。好的，现在是节目时间，我们要表扬一位在Stack Overflow上分享知识、展现好奇心并获得徽章的人。今天我们要表扬一位“大众认可”徽章得主。

一位给出的答案如此出色，以至于超过了被接受的答案。恭喜Luca Ganich回答了“在Flutter中将SVG图像作为按钮”的问题。如果你对此感兴趣，答案会在节目备注中。我的名字是Ryan Donvin，我负责编辑博客，主持这里的Stack Overflow播客。如果你有问题、担忧或想讨论的话题，或者只是想打招呼，可以给我发邮件至[email protected]。

如果你想直接联系我，可以在LinkedIn上找到我。

以及可能还有其他方式。

Praveen Bodigutla (36:53)

同样恭喜Luca

Ryan Donovan (36:55)

Praveen Bodigutla (36:56)

for providing really valuable insights and input. it was a pleasure talking to you, Ryan. and this was wonderful experience sharing the technology that we have built to solve some of the memory problems for different agents. And as you rightly identified, that this is this might be the new ETL or the second brain that we are building to solve some of these

Ryan Donovan (37:19)

Praveen Bodigutla (37:19)

agentic interactions and

really looking forward to see how the technology pans out. This is just the beginning and there is a lot more research that we are seeing is coming our way. really happy to be sharing what we have built so far and thank you for giving the opportunity and you can definitely reach me out on LinkedIn.

Ryan Donovan (37:37)

Okay. And what can they learn more about the project?

Praveen Bodigutla (37:42)

so some of the like we have papers that we have one of the papers was actually accepted at KDD. So I would encourage checking out the publications as well as the blog more blog posts that are coming that will come through as we develop and embark on this journey as as we explore and try to incorporate as well as develop and build the state of the art solutions for handling memory for personalization.

Ryan Donovan (38:07)

Wonderful. Well, thank you for listening, everyone, and we'll talk to you next time.

]