几乎每周都有新的智能体记忆产品出现，卖点都是让智能体拥有持久上下文。但其中大多数解决的是问题中错误的那一半。
记忆本身不会让智能体变聪明。它只是整套系统里的一个环节，必须和其他能力连起来才有意义：检索层负责让智能体真正拿到完成任务所需的信息；捕获（Capture）记录发生过什么；整合（Consolidation）再把这些记录变成下一次会话可用的内容。少了任何一环，都算不上学习，只是在记笔记。一个埋在自己笔记里的智能体甚至可能比没有笔记更糟，因为它行动前还得先把笔记全部翻一遍。
真正问题的一直是“记忆产品”周围的连接，存储本身反倒没有那么难。把上下文拼到一起涉及很多部件，难点也不只在技术。访问权限怎么拿、分散在多个系统里的信息怎么汇总，这些经常带有团队所谓的“政治”属性。
本文关注的是整套系统长什么样，并继续沿用此前对元知识图谱的定义。自学习智能体系统不能理解成在模型旁边外挂一块记忆，它本质上是一套完整架构；之所以呈现出特定形态是因为有三个很多团队还没有明确命名的问题。
智能体就像一个永远结束不了新人期的新员工
很多人已经感受到这个问题，只是很少把它直接说出来。
想想最近加入团队的一位新员工。能力很强，履历也不错，对专业领域十分熟悉，但入职第一天仍然不了解公司：不知道客户是谁，不熟悉内部定义，也不知道团队上个季度做过什么决定、为什么那样决定。之后的几周和几个月里，他会不断询问、参加会议、吸收那些散落在正式流程之外的知识，慢慢脱离新人状态。一年左右他脑中会形成一套关于组织如何运作的工作模型；很大一部分工作价值，正来自这套模型。
智能体也差不多，不过问题不在于它不能学习，没有机制替它保留已经学到的内容。每天早上，它都带着对外部世界的大量知识开始工作，却对你的公司几乎一无所知；工作几个小时之后，当天形成的经验又全部消失。它像一个第一天表现很好的新人，第二天仍停留在第一天，第三天也是如此。
而且即使只看同一天，情况也没有好多少。智能体所需的知识分散在它触达不了的系统里：数据仓库（warehouse）、湖仓（lakehouse）、文档存储、工单历史，还有埋在上个月讨论串里的各种决策。让一个不和同事交流的新员工陷入孤立的数据孤岛和访问壁垒，也同样挡在智能体和工作所需知识之间。结果就是系统里出现了一群能力很强却不断失忆的“员工”，之后再反过来追问它们为什么没有持续进步。
自学习智能体的架构要处理的就是这两个问题：让智能体穿过这些孤岛拿到知识，也让它保留下已经学会的东西，使第二天的起点比第一天更靠前。换成一句更准确的话，自学习不是记忆存储的属性，而是贯穿整套系统的一条循环。智能体拉取企业数据解决真实问题，操作与结果被记录下来，原始事件继续被提炼成持久的学习成果，再流回后续交互。循环每跑一次，智能体都应该比之前多积累一点可复用的经验。
这里讨论的也不是新的智能体平台。市场上已经有足够多这类产品，本文关注的是平台下面那一层。
这一层用图承载上下文、记忆和捕获能力，可以被不同 harness 组合使用，无论上层跑的是 Claude Code、Codex，还是自行开发的系统。
第一个问题：一次交互从来不只包含一种意图
很多系统在这里出错，根源往往是它们根本没有看到这个问题，具体处理方式反倒是第二层问题。
智能体行动时，表面上是在响应用户请求。但用户请求只对应一种意图，实际需要处理三种。
用户意图（user intent）是最直接的，就是输入框里明确写出的要求。智能体意图（agent intent）来自任务分解，是智能体为了得到答案而推导出的子目标和执行步骤。组织意图（organisational intent）则包含公司的目标、政策、定义，以及这家公司处理特定事务时沿用的方式。最后这一类内容几乎不会出现在 Prompt 里。用户询问定价时不会顺手重述公司的折扣政策，也不会每次都解释业务里的“活跃账户”到底怎么定义，因为这些对内部人员本来就是常识；智能体却看不见。
还有最难的第三种意图。只针对用户请求本身做优化，很容易得到一个语言流畅、语气自信，却不符合组织实际情况的答案。因为智能体没有一个真人同事在入职第一个月里逐渐吸收的长期背景。它给出的可能是教科书答案，而业务真正需要的是“你们公司的答案”。
元知识图谱位于底层，正是为了补上这里缺失的组织上下文。组织意图不是某种只能临时靠 Prompt Engineering 拼出来的抽象概念，它早已存在于业务术语表、所有权规则、血缘关系、政策和历史决策里。这些信息天然互有关联，图可以把它们保存为连接起来的元数据，并在需要时取出相关部分。这样，智能体面对一次请求时能够协调三种意图，而不是只理解用户意图，再猜剩下两种。
图 3 展示了这个过程。用户请求和智能体推导出的子目标直接进入系统，组织意图从图中取出；工作进入路由之前，三者先合成一个统一理解。
图 3。三种意图，一个统一理解。用户意图和智能体意图直接进入；组织意图由元知识图谱提供，它本来就以元数据形式存在于图中。三者协调为一个统一理解，再把这个理解交给编排器（orchestrator）。
第二个问题：数据不会移动，但上下文必须移动
湖仓、数据仓库、业务存储、文档仓库、外部数据源仍然保存各自的数据。数据体量大，受治理和监管约束，不可能也不应该整体复制进某个新的智能体记忆存储。任何从“先集中所有数据”开始的方案，实际上在起点就把自己放进了一个很难结束的迁移项目。
元知识图谱不复制这些数据。它保存数据位置的指针、解释数据含义的语义层（semantic layer），以及说明数据应当如何使用的元数据。数据管理员、智能体、co-pilot、BI 工具、ETL 任务和应用程序，需要什么上下文就从这里取什么上下文。数据留在原系统，移动的是上下文。这样一来，架构不必等一场大规模迁移结束后才能开始工作。
真正发挥作用的元数据分成四类：技术（technical）元数据包括 schema、血缘和 Pipeline；业务（business）元数据包括术语表、所有权和政策；运营（operational）元数据记录质量、新鲜度、成本和使用情况。第四类是很多 catalog 还没有覆盖的智能体（agentic）元数据，其中包含智能体和人在使用系统过程中积累的决策、trace、纠正和偏好。
关键交互也不是单向读取：上下文流向使用者，而 trace、纠正以及陈旧事实则允许逐渐衰减。每轮循环结束后，图应该变得更聪明一点，而不只是装下更多内容。
图 4。元知识图谱所处的上下文。数据留在原地，移动的是指针、语义和元数据。
第三个问题：记忆不是一种东西，也不能只靠一种机制
问“智能体的记忆存在哪里”，很多团队会直接回答是存储介质：向量数据库、图，或者更常见的一组组织得比较松散的 Markdown 文件。后者往往在出现第二个用户或第二个智能体时就开始失控。但存储位置其实不是最关键的问题，真正影响架构的是这些记忆如何被访问。
其实更有用的问法是：谁决定访问记忆，访问发生在哪条执行路径上，允许占用多少延迟预算。顺着这个问题往下看你就会发现完整的记忆系统不可能只靠一条路径，它至少包含三条，而且三者对执行方式的要求几乎相反。
捕获（Capture）必须被动、确定性地运行。每次会话都要执行，不调用模型，也不做判断，不依赖智能体自己有没有想到“应该记一下”。如果捕获还要靠智能体主动记笔记，最关键的那些轮次反而最容易漏掉。
召回（Recall）需要按需触发，并由智能体自己决定。执行到一半时，只有智能体知道当前缺少什么，也只有它能判断此时该请求哪一段信息。
整合（Consolidation）可以很慢，最好完全离开关键路径。把大量原始事件压缩成少量持久、互不矛盾的学习成果，本来就是反思性工作，没有理由为了它阻塞用户当前这一轮。
把三件事塞进同一种机制，至少会牺牲其中两件。典型失败模式就是“单存储、单路径”的记忆系统：为了捕获而变得过于积极，又因为同一条路径太重而无法做好低延迟召回。更合理的做法无需给某一种机制加冕，可以直接把它们放到两个轴上观察：谁发起——智能体，还是外层 harness；什么时候运行——当前轮次内联执行，还是脱离当前轮次放到后台。这样会得到四个象限。
图 5。编排频谱。两个轴分别描述谁发起工作以及何时运行，由此形成四个象限：hooks 和 tools 在当前轮次内联运行，loops 和 managed subagents 在后台运行。第一版先交付目前能够跨 harness 移植的两种机制：hooks 和 tools。
在 harness 决定的一侧，hooks 根据生命周期事件被动触发，不需要模型调用；后台 loops 负责耗时较长的整合，把原始事件提炼成持久学习成果。在智能体决定的一侧，tools 负责当前轮次中的按需召回和写入；managed subagents 或后台智能体处理那些脱离当前轮次、需要更多判断的整理任务，相当于一个被委派出去的图书管理员，负责合并、协调和晋升内容。
四个象限并非彼此隔绝。hook 可以从记忆存储中读取准备注入的内容，而智能体又可以向这块存储写入信息，于是出现一种组合：机制由 harness 发起，实际注入的内容却受到智能体影响。继续往前推，harness 自身也可能变得动态。假如智能体判断某个任务应该每天五点执行，并且可以自行创建它，那么智能体实际上已经开始塑造自己的系统管线。
一张图说清楚完整系统
把前面的部分放到一起，整套架构可以压缩到一张图里。
每次交互都先处理三种意图并把它们协调为一个统一理解：在这个组织里，这个用户真正问的是什么，智能体又把请求拆成了怎样的计划。统一理解进入编排器，编排器把任务路由给专业 worker。worker 经由语义层访问数据，先确认哪些内容相关，再真正读取；内部来源找不到答案时，再访问 Web 或外部增强源。围绕每一轮交互，hooks 负责那些不该依赖智能体主动记住的确定性工作——模型回答之前注入合适的上下文，回答之后捕获全部事件。离开当前轮次后，后台整合步骤继续处理原始事件流，把它们提炼成持久学习成果；评估门（evaluation gate）判断哪些内容值得留下，只有通过的内容才会写回。
这张图里最关键的一点，是学习主体有两个：智能体会学习。自己的 trace 被捕获并继续整合后，下一次会话可以从比上一次更靠前的位置开始。
人也在学习。人会审阅智能体输出、纠正错误，并把纠正结果送回系统，系统继续捕获这些反馈。人类反馈属于主路径，评估门会把它作为奖励信号（reward signal），据此判断哪些内容可以晋升为持久记忆。自学习循环有一个很现实的风险：如果完全放任系统自己运行，它既会整合成功经验，也会整合错误。出现频率不代表正确性。人的验证决定哪些学习成果真正值得保留，所以“晋升”必须是一次判断，而不能只是自动写入。
智能体和人的两条循环都经过同一个共享上下文层，也就是元知识图谱。共同底座让学习结果持续累积，不会随着会话结束而消失。
图 6。自学习多智能体系统。三种意图（用户、组织、智能体）先协调，再交给编排器把工作路由给专业 worker。worker 通过 tool surface 和语义层访问数据；hooks 负责捕获和召回；后台整合循环提炼学习成果；评估门以人的反馈作为奖励信号，只把通过评估的内容在验证后晋升并写入共享上下文层。两个主体都在学习：智能体和人。虚线边框表示有意留给下一步的部分，其中包括衰减函数，并不属于第一版实现。
总结
这篇文章承接此前对元知识图谱（上下文图谱）的定义，把讨论推进到智能体学习架构：三种意图在一个共享、受治理、可衰减的上下文层上完成协调，智能体和人都经由这层上下文学习。图位于架构中心，因为组织意图本质上是一组相互连接的元数据，而图最适合保存这种关系。现实中的蚂蚁群体也采用类似方式。
by Firat Tekiner