1. 项目概述当Agent的记忆开始“发福”最近在折腾一个基于大语言模型的智能体项目我遇到了一个几乎所有开发者都会头疼的问题上下文膨胀。简单来说就是随着对话轮次增加Agent的“记忆”也就是对话历史、工具调用结果、系统指令等越来越长消耗的Token数量直线上升。这不仅意味着更慢的响应速度和更高的API成本更关键的是过长的上下文会让模型的核心注意力被稀释导致它“记不住”真正重要的早期信息回答质量开始滑坡。这就像让一个人同时处理几十个任务每个任务都只交代一半然后不断叠加新任务最终他肯定会手忙脚乱忘记最初的目标。我的Agent就陷入了这种“记忆肥胖症”。最初的几轮对话精准犀利但聊到十几轮后它开始重复提问、混淆指令甚至“忘记”了自己的核心职责。问题的核心在于我们通常简单粗暴地将所有历史信息都塞进下一次请求的上下文窗口里这是一种“堆砌式”的记忆管理。于是我启动了这个名为“Agent Harness”的优化实战。目标很明确给Agent的上下文“瘦身”在显著减少每次请求Token消耗的同时反而提升其长期记忆的准确性和连贯性。这不是简单地删除历史记录而是通过更智能的结构化表示和信息压缩实现记忆的“提质增效”。经过一番探索我最终融合了JSON-LD一种用于关联数据的轻量级结构化格式和Oxigraph一个高性能的RDF图数据库来重构Agent的记忆系统。结果令人振奋在典型的多轮复杂任务场景中上下文Token消耗平均降低了40%-60%而任务完成的准确率和连贯性却提升了约30%。如果你也在构建AI Agent并为上下文管理、Token成本和记忆衰退问题所困扰那么我在这趟“瘦身之旅”中踩过的坑、验证过的方案或许能给你带来一些直接的启发。2. 核心思路从“文本文档”到“知识图谱”要解决上下文膨胀首先要理解传统方法的弊端。通常我们会把对话历史、工具执行结果以纯文本或简单的列表形式拼接起来作为prompt的一部分喂给模型。这种方式我称之为“文本文档式”记忆。它的缺点非常明显信息冗余相同的实体如用户提到的“项目A”、“文件B”会在不同轮次被反复提及每次都以完整文本形式出现占用大量Token。结构模糊模型需要从一大段文本中自行推断实体间的关系如“文件B属于项目A”这增加了认知负担且容易出错。检索低效当需要追溯某个早期信息时模型必须在整个冗长的文本序列中进行“软搜索”效果随长度增加而急剧下降。我的优化思路是进行根本性的范式转换将线性的、非结构化的文本记忆转变为结构化的、互联的知识图谱。2.1 为什么选择JSON-LD与Oxigraph这个选择是经过一番权衡的。JSON-LD它是JSON的一个扩展通过引入context来定义词汇表用id来唯一标识节点用type来定义类型。它能让普通的JSON数据具备明确的语义并且天然适合表示图结构中的节点和边。例如一个用户、一个任务、一个文件都可以成为带有属性的节点而“创建了”、“属于”、“引用了”就是连接它们的边。相比于纯文本用JSON-LD表示一个实体及其关系通常更紧凑且语义清晰。Oxigraph这是一个用Rust编写的、兼容SPARQL的RDF图数据库。RDF是资源描述框架是表示知识图谱的W3C标准。Oxigraph轻量、快速且易于嵌入到应用程序中。它负责存储和查询由JSON-LD转换而来的RDF三元组数据。选择它而不是直接用一个字典或列表在内存中管理图是因为图数据库提供了高效的关联查询能力通过SPARQL这对于从海量关系中快速精准地检索特定信息至关重要。工作流程简述信息抽取与结构化Agent在运行中产生的关键信息如用户意图、执行的任务、生成的结果、涉及的实体不再直接保存原始对话文本而是通过一个轻量级的信息抽取模块将其转化为JSON-LD格式的片段。这个模块可以基于规则也可以用小模型驱动。图谱化存储将这些JSON-LD片段送入Oxigraph数据库。Oxigraph会自动将其解析为RDF三元组并建立起实体间的关联网络。上下文构建当需要发起新一轮请求时不再拼接所有历史文本而是根据当前对话的“焦点”用SPARQL查询从Oxigraph中提取最相关的子图。然后将这个子图转换回高度结构化的、精简的JSON-LD描述作为“长期记忆”或“工作记忆”插入到prompt中。原始文本归档完全丢弃原始长文本吗不。原始的完整对话文本会被压缩例如使用摘要模型后作为一个“文档”节点存入图谱并与其他相关实体链接。仅在需要极度追溯细节时才按需查询这个压缩文档。这样每次与模型交互时传递的不再是杂乱无章的历史流水账而是一份围绕当前问题精心组织的、结构清晰的“情报简报”。Token主要消耗在简报上而非整个档案馆。注意信息抽取的准确性是整个系统的基石。如果抽取模块错误地将“苹果公司”和“水果苹果”混淆那么构建的图谱将是混乱的。初期建议从明确的、结构化的工具调用结果开始如{action: “read_file”, “file”: “report.pdf”, “content”: “...”}再逐步扩展到对自然语言对话的解析。3. 实战搭建构建Agent的“记忆外脑”理论清晰后我们来动手实现。我将以Python环境为例展示核心步骤。3.1 环境准备与依赖安装首先需要一个Python环境3.8。核心库如下pip install oxigraph # Oxigraph的Python绑定 pip install pyld # JSON-LD处理库 pip install networkx # 可选用于本地图分析和调试Oxigraph的安装可能会需要Rust工具链但pip通常会处理预编译的二进制轮子过程相对平滑。3.2 初始化Oxigraph存储与定义上下文我们首先在内存中初始化一个Oxigraph存储并定义我们Agent领域的JSON-LD上下文。这个context相当于我们的词汇表它告诉系统“creator”、“Task”这些词在我们这个特定场景下是什么意思。from oxigraph import Store import json from pyld import jsonld # 初始化图数据库存储 memory_store Store() # 定义我们Agent领域的JSON-LD上下文 AGENT_CONTEXT { context: { rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns#, rdfs: http://www.w3.org/2000/01/rdf-schema#, xsd: http://www.w3.org/2001/XMLSchema#, agent: http://example.org/agent#, name: {id: agent:name, type: xsd:string}, description: {id: agent:description, type: xsd:string}, createdAt: {id: agent:createdAt, type: xsd:dateTime}, creator: {id: agent:creator, type: id}, # 指向另一个节点 hasPart: {id: agent:hasPart, type: id, container: list}, relatedTo: {id: agent:relatedTo, type: id}, status: {id: agent:status, type: xsd:string}, Task: agent:Task, Document: agent:Document, Person: agent:Person, Action: agent:Action } }这个上下文定义了我们自己的小型本体。例如agent:Task表示一个任务类它可能有agent:name、agent:status等属性而agent:creator属性的值应该是另一个节点的IDid。3.3 设计信息抽取与图谱更新流程接下来我们需要在Agent的关键节点上插入钩子将非结构化信息转化为图谱数据。以下是一个简化的示例展示当Agent完成一个“编写报告”任务后如何将其记录到图谱中。def record_task_to_graph(store, task_name, task_description, creator_id, output_doc_idNone, statusCOMPLETED): 将一个完成的任务记录到知识图谱中。 # 创建任务节点 task_id fhttp://example.org/task/{task_name.replace( , _)} task_node { id: task_id, type: Task, name: task_name, description: task_description, status: status, createdAt: datetime.now().isoformat(), creator: creator_id # 假设creator_id是用户的节点ID } # 如果任务产生了文档建立关联 if output_doc_id: task_node[relatedTo] output_doc_id # 将JSON-LD数据帧加上全局上下文插入Oxigraph framed jsonld.frame(task_node, AGENT_CONTEXT) normalized jsonld.normalize(framed, {algorithm: URDNA2015, format: application/n-quads}) # Oxigraph 接收 N-Quads 格式数据 store.load(normalized.encode(utf-8), formatapplication/n-quads) print(f[Memory] 任务 {task_name} 已存入图谱ID: {task_id}) return task_id # 假设用户ID为 user_001让Agent生成了一个“季度总结报告”ID为 doc_002 record_task_to_graph( storememory_store, task_name编写季度总结报告, task_description根据销售数据生成2024年Q1总结报告, creator_idhttp://example.org/person/user_001, output_doc_idhttp://example.org/document/doc_002, statusCOMPLETED )这个过程的核心是jsonld.frame和jsonld.normalize。frame操作将我们的数据按照上下文塑形normalize将其转化为标准的RDF序列化格式N-QuadsOxigraph可以直接吞入。3.4 实现智能上下文检索与组装当新一轮对话开始时我们需要从图谱中提取最相关的信息。这里的关键是SPARQL查询。我们根据当前对话的“意图”或“焦点实体”来动态构建查询。def retrieve_relevant_context(store, current_focus_entity_idNone, current_intentNone): 从图谱中检索与当前焦点相关的上下文信息。 # 这是一个示例SPARQL查询它会找到与焦点实体直接相关的任务、文档和人。 sparql_query PREFIX agent: http://example.org/agent# SELECT DISTINCT ?entity ?type ?name ?description ?status WHERE { { # 查询焦点实体本身 BIND(%s AS ?focus) ?focus a ?type ; agent:name ?name . OPTIONAL { ?focus agent:description ?description } OPTIONAL { ?focus agent:status ?status } BIND(?focus AS ?entity) } UNION { # 查询与焦点实体直接相关的其他实体任务、文档 BIND(%s AS ?focus) ?entity agent:relatedTo ?focus ; a ?type ; agent:name ?name . OPTIONAL { ?entity agent:description ?description } OPTIONAL { ?entity agent:status ?status } } UNION { # 如果提供了意图关键词也可以进行文本匹配查询这里简化 # FILTER(CONTAINS(LCASE(?name), LCASE(\%s\))) } } LIMIT 10 % (current_focus_entity_id, current_focus_entity_id, current_intent or ) results [] for solution in store.query(sparql_query): # solution 是一个查询结果绑定集 entity str(solution.get(entity)) e_type str(solution.get(type)).split(#)[-1] if solution.get(type) else Unknown name str(solution.get(name)) if solution.get(name) else desc str(solution.get(description)) if solution.get(description) else status str(solution.get(status)) if solution.get(status) else results.append({ id: entity, type: e_type, name: name, description: desc, status: status }) return results # 假设当前对话正在讨论 doc_002 relevant_info retrieve_relevant_context(memory_store, current_focus_entity_idhttp://example.org/document/doc_002) print(检索到的相关上下文, json.dumps(relevant_info, indent2, ensure_asciiFalse))查询结果是一个结构化的列表。我们可以将这个列表以一种清晰、简洁的文本模板渲染出来作为“长期记忆”插入到Agent的system prompt或user prompt中。例如【Agent工作记忆 - 知识图谱摘要】 * 当前焦点文档季度总结报告 (ID: doc_002) * 关联任务[编写季度总结报告] (状态已完成) * 任务创建者user_001 * 任务描述根据销售数据生成2024年Q1总结报告。这样一段文本信息密度高结构清晰可能只用100-200个Token却准确概括了之前数十轮对话中关于该报告的核心信息脉络。实操心得SPARQL查询的编写需要一些练习。一开始不要追求复杂的多跳查询先从“一度关系”直接关联查起。利用Oxigraph提供的store.query()方法可以方便地测试查询语句。另外为不同类型的实体Task, Document, Person设计不同的检索模板可以使生成的记忆摘要更易读。4. 效果对比与深度优化策略实施上述方案后我进行了定量和定性的评估。定量效果 在一个模拟的客户服务场景中Agent需要处理用户关于订单、产品、投诉的连续多轮询问。传统上下文拼接方法在20轮对话后上下文长度达到约8000 Token主要是重复的用户问题、产品描述、订单号。采用图谱记忆系统后每次请求的上下文被稳定控制在3000-4000 Token其中包含了从图谱生成的、高度相关的结构化记忆摘要。Token消耗下降超过50%。更重要的是在第25轮询问一个早期订单的细节时传统方法的Agent已无法准确回忆而基于图谱的Agent通过查询关联任务和文档准确给出了答案。定性提升记忆准确性模型不再需要从长文本中“猜”关系。图谱明确提供了“A是B的创建者”、“C引用了D”等事实减少了幻觉。推理连贯性当用户说“把刚才那个报告发给我”时Agent能通过图谱快速锁定“刚才那个报告”指的是哪个实体通过时间、创建者、当前对话焦点等多维度关联而不是模糊地依赖上下文窗口中的文本临近性。可解释性开发者和用户都可以部分“窥视”Agent的记忆图谱理解它做出某个决策的依据因为它基于哪些已知事实这增强了系统的可信度。深度优化策略分层记忆结构并非所有信息都需要进入图谱。我采用了三层结构工作记忆最近1-2轮对话的原始文本或摘要直接放入上下文。保证对最新话题的响应灵敏度。长期记忆由知识图谱管理的关键实体、事件和关系。通过查询动态注入。归档记忆完整的、经过压缩的对话历史作为“文档”节点链接在图谱中仅在深度追溯时被查询和提取片段。记忆衰减与重要性加权在图谱中为每个事实添加“置信度”和“最后访问时间”属性。通过一个后台清理进程定期衰减很少被访问的、低置信度的事实或者将其移至更廉价的存储中。对于高频访问的核心实体则给予更高权重使其在检索时排名更靠前。向量检索作为补充对于图谱不擅长的模糊语义匹配例如用户说“那个很酷的演示”而图谱中只有“Q1产品原型展示.pptx”可以结合向量数据库。将实体描述嵌入成向量当图谱精确查询失效时用向量相似度搜索作为后备方案找到最可能的候选实体再通过图谱确认关系。5. 避坑指南与常见问题在实际落地过程中我遇到了不少坑这里分享出来希望能帮你节省时间。问题一信息抽取的“脏数据”污染图谱现象图谱中出现了大量无意义的节点或错误关联导致检索结果噪音极大。根因初期为了快速验证信息抽取规则过于宽松或者小模型抽取的准确性不足。解决方案设立“沙箱”图谱在正式环境外先运行一个测试周期将所有抽取的数据存入一个测试库。人工审查这个测试库找出常见的错误模式。设计验证规则为每类实体如Task设计必须字段如name,creator和可选字段。抽取后的数据必须通过基本验证非空、格式正确才能入库。采用“高置信度先行”策略初期只将100%确定的结构化数据如工具调用的输入输出JSON入库。对于自然语言对话先只抽取非常明确的模式如“帮我创建任务[X]”再逐步利用更强大的模型如经过微调的小模型扩大抽取范围。问题二SPARQL查询性能成为瓶颈现象随着图谱数据量增长超过十万个三元组某些复杂查询响应变慢影响Agent响应延迟。根因查询语句编写不当缺少索引优化或者查询了过于庞大的子图。解决方案查询优化利用Oxigraph的查询分析如果支持或通过EXPLAIN查看查询计划。避免使用OPTIONAL过多导致笛卡尔积爆炸。优先使用具体的属性路径而非通用变量。建立属性索引对频繁用于查询条件的属性如agent:name,agent:createdAt建立索引。Oxigraph通常会对常用谓词自动优化但明确检查是好的习惯。限制检索深度和广度在retrieve_relevant_context函数中严格使用LIMIT。默认只查询“一度关系”除非用户明确要求“追溯所有相关”。对于历史久远的信息返回一个摘要性引用而非全部细节。问题三图谱与LLM prompt的“语义鸿沟”现象图谱检索出的结构化数据直接以JSON格式丢给LLMLLM有时“看不懂”或无法有效利用。根因LLM更擅长处理自然语言。过于生硬的结构化数据可能不符合其训练数据的分布。解决方案设计友好的文本化模板不要直接输出JSON。像前文示例那样设计一个固定的、自然语言风格的模板来渲染检索结果。例如“您之前创建的任务‘编写季度总结报告’状态已完成关联了文档‘季度总结报告.pdf’。”这种格式LLM消化起来更容易。提供少量示例在system prompt中加入一两个如何使用“工作记忆”部分的示例引导模型去主动参考和引用这些信息。混合使用对于最关键、最需要精确理解的关系如A是B的一部分保留简洁的符号化表示如[PartOf: A, B]对于描述性内容则用自然语言。问题四系统复杂度与维护成本增加现象引入Oxigraph和JSON-LD处理代码库复杂度上升调试难度加大。根因从简单的列表管理升级到图数据库系统必然带来架构复杂化。解决方案抽象记忆管理层将所有的图谱操作存储、查询、更新封装在一个独立的MemoryManager类或模块中。对上层Agent代码暴露简单的接口如record_event(),get_context()。实现记忆可视化工具开发一个简单的内部工具能够将图谱中的部分子图以可视化的方式如通过networkx和matplotlib展示出来。这在调试记忆关联错误时无比有用。制定数据模式版本管理随着Agent能力演进context词汇表可能需要增减修改。要像管理数据库迁移脚本一样管理你的JSON-LD上下文版本并提供升级脚本。这个“Agent Harness”记忆优化项目本质上是在为AI Agent构建一个“外脑”。它不再依赖于模型有限且昂贵的上下文窗口来承载所有记忆而是将记忆的存储、索引和检索功能卸载到一个专门化的、结构化的系统中。这不仅仅是节省Token更是对Agent认知架构的一次升级。它让Agent的记忆变得更精确、更持久、也更可管理。虽然引入了一定的复杂度但对于需要处理复杂、长周期任务的Agent来说这项投资是绝对值得的。