跳到主要内容

6 篇博文 含有标签「memory」

查看所有标签

智能体记忆 Schema 演进:Protobuf 的困难模式

· 阅读需 12 分钟
Tian Pan
Software Engineer

第一次痛苦的智能体记忆(agent-memory)迁移总是教会我们同一个教训:存在两个模式(schema),而你只迁移了其中一个。存储层没问题 —— 每一行都已重写,每个键(key)都是新的形态,回填(backfill)作业也记录了成功。但智能体还是坏了。它继续向 user.preferences.theme 写入,却检索不到任何内容,然后从上下文中煞有介事地合成一个默认值,就好像这个键从未存在过一样。迁移操作手册显示一切正常。用户却报告记忆过时。

这种不对称是结构性的。一个依赖于重命名列的传统服务会收到硬错误,然后你进行修复。而一个依赖于重命名记忆键的智能体则会遇到软缺失,并围绕它进行胡编乱造。模式存在于两个地方 —— 你的存储和模型的上下文 —— 而你只能通过 SQL 脚本迁移其中的一个。

Protobuf 在二十年前通过规范化“仅限增加”的准则解决了这类问题的一个变体:字段是永恒的,数字是永恒的,网络类型永远不变,删除被弃用(deprecation)所取代。这一准则是智能体记忆的一个良好起点,但有一个额外的约束使其变得更加困难。Protobuf 接收者在设计上会忽略未知字段。智能体则不会。

并行智能体系统中的隐性数据损坏问题

· 阅读需 14 分钟
Tian Pan
Software Engineer

当一个多智能体系统开始出现奇怪的行为——给出不一致的答案、丢失任务追踪、做出与早期推理相矛盾的决策——本能反应是责怪模型。调整提示词,换一个更强的模型,添加更多上下文。

真正的原因往往更平凡,也更危险:并发写入导致的共享状态损坏。两个智能体读取同一块内存,都计算出更新,其中一个默默地覆盖了另一个。结果状态在技术上是有效的——没有异常抛出,没有模式违规——但在语义上是错误的。之后读取它的每一个智能体都在对错误信息进行正确的推理。

这种故障模式在单个操作层面是不可见的,在测试环境中难以复现,仅通过查看输出几乎无法与模型错误区分开来。O'Reilly 2025年关于多智能体内存工程的研究发现,36.9%的多智能体系统故障源于智能体间的不对齐——智能体在对共享信息的不一致视图上运行。这不是一个理论上的顾虑。

每个生产级 AI Agent 都需要的三个记忆系统

· 阅读需 12 分钟
Tian Pan
Software Engineer

大多数 AI agent 都会以同样的方式失败:它们在演示中表现完美,但在经历十次真实对话后就会分崩离析。那个上周二还帮用户配置账单集成的 agent,今天已经完全不记得那个用户是谁了。它再次询问对方的公司名称,然后是套餐层级,接着重新解释用户已经掌握的概念。体验从“有用的助手”降级为“健忘的聊天机器人”。

直觉反应是给问题增加更多上下文 —— 将对话历史塞进 prompt 并认为问题已解决。这种做法在达到一定规模前确实有效。在大规模场景下,全上下文方案的成本高得惊人,而且更麻烦的是,随着输入量的增长,性能会下降。研究表明,即使在模型宣称的限制范围内,LLM 的准确率也会随着上下文长度的增加而明显下降。100 万 token 的上下文窗口并不是一个记忆系统。

在生产环境中运行良好的 agent 将记忆视为头等架构关注点,而不是事后才考虑的事情。而那些做对的 agent 能够区分三种根本不同的持久化信息类型 —— 每种类型都有不同的存储模式、检索策略和衰减特性。

生产级 AI Agent 的记忆架构

· 阅读需 12 分钟
Tian Pan
Software Engineer

大多数团队都是事后才给他们的智能体添加记忆功能——通常是在用户抱怨智能体忘记了三轮对话前明确告知的信息之后。那时,解决方案似乎显而易见:把对话存储起来,以后再检索。但这种直觉往往导致系统在演示中表现出色,而在生产环境中却一塌糊涂。一个仅仅存储信息的记忆系统,与一个能在正确的时间可靠地呈现正确信息的系统之间存在巨大鸿沟,大多数智能体项目正是悄然失败于此。

记忆架构并非次要问题。对于任何处理多轮交互的智能体——无论是客户支持、编码助手、研究工具还是语音界面——记忆都是区分有状态助手和昂贵自动补全的关键。如果处理不当,智能体不会崩溃;但它会让人感觉有些不对劲,自相矛盾,或者自信地重复着用户两周前纠正过的过时信息。

LLM 驱动的自主智能体:实现真正自主的架构

· 阅读需 10 分钟
Tian Pan
Software Engineer

大多数声称在“生产环境中有智能体”的团队其实没有。调查一致显示,大约 57% 的工程组织已经部署了 AI 智能体——但当你应用严格的标准(LLM 必须能够规划、行动、观察反馈并根据结果进行调整)时,只有 16% 的企业部署和 27% 的初创公司部署符合真正的智能体标准。其余的只是加装了工具调用功能的“美化版”聊天机器人。

这种差距不在于模型能力,而在于架构。真正的自主智能体需要三个相互关联、协同工作的子系统:规划、记忆和工具使用。大多数实现只正确地完成了其中一个,部分实现了第二个,却忽略了第三个。结果是系统在演示中表现出色,但在生产环境中却会不可预测地失败。

个性化上下文工程:如何为 AI 智能体构建长期记忆

· 阅读需 8 分钟
Tian Pan
Software Engineer

大多数智能体演示都是无状态的。用户提问,智能体回答,会话结束——下一次对话从头开始。这对于计算器来说没问题。但对于一个应该了解你的助手来说,这就不行了。

有用的智能体和令人沮丧的智能体之间的差距,往往归结为一点:系统是否记住了重要信息。本文将详细阐述如何在生产级 AI 智能体中构建持久化、个性化的记忆——涵盖其四阶段生命周期、分层优先级规则以及如果你跳过工程设计将遇到的具体故障模式。