1. 项目概述一个真正“记住”你的开源AI智能体最近在AI智能体Agent这个赛道上有一个项目让我眼前一亮它叫“Hermes Agent”。这个名字本身就很有意思赫尔墨斯是希腊神话中的信使之神象征着沟通与信息的传递。而这个项目最核心的卖点也是它区别于市面上绝大多数“健忘”AI助手的关键就是它的“记忆”能力。简单来说Hermes Agent是一个开源框架旨在构建能够长期、持续地记住与你互动的上下文、偏好、习惯甚至未完成任务并据此提供个性化服务的AI智能体。这听起来似乎理所当然但实际体验过各种AI工具的朋友都知道当前的AI模型无论是基于API的ChatGPT还是本地部署的开源大模型在对话中基本都是“金鱼记忆”——每次对话都是一个新的开始。你需要在每次对话中重复你的背景、你的需求、你之前讨论过的细节。这对于构建一个真正能成为个人助理、长期伙伴的AI来说是致命的短板。Hermes Agent正是为了解决这个问题而生。它通过一套精巧的架构将“记忆”作为核心模块让AI能够跨越会话边界真正地“认识”你。这个项目适合谁呢首先是AI应用开发者。如果你想构建一个需要长期用户粘性的应用比如个性化学习伴侣、健康管理助手、创意协作伙伴Hermes Agent提供的记忆框架是绝佳的起点。其次是技术爱好者和研究者。你可以深入其架构理解如何将向量数据库、图数据库与大语言模型结合来实现复杂的记忆存储与检索逻辑。最后即使是普通用户如果你对部署一个属于自己的、有“灵魂”的AI助手感兴趣Hermes Agent也提供了相对清晰的路径。2. 核心架构与设计哲学记忆如何被结构化要理解Hermes Agent为什么能“记住”我们必须先拆解它的核心架构设计。这不仅仅是简单地把对话历史存进数据库而是一套关于如何结构化、存储、检索和应用“记忆”的完整方法论。2.1 记忆的三层结构从瞬时到永恒Hermes Agent将记忆抽象为三个层次这种分层设计是其智能的基石工作记忆Working Memory这相当于AI的“短期记忆”或“注意力焦点”。它存储当前对话轮次中的上下文通常就是最近几次的问答。这部分记忆直接提供给大语言模型LLM用于生成当前的回复。它的特点是容量小、存取快、但易挥发对话结束后通常会被清空或压缩归档。长期记忆Long-Term Memory这是项目的核心。它存储所有需要被长期保留的信息。但“长期记忆”本身又是一个复杂的集合Hermes Agent进一步将其细分事实性记忆Factual Memory关于“你”的客观事实。例如“用户张三是一名住在北京的软件工程师喜欢摄影和骑行。”“用户李四对花生过敏。”这类信息通常以“键-值”对或三元组实体-关系-实体的形式存储便于精确查询。情景记忆Episodic Memory特定事件或对话片段的记录。例如“上周二用户和我讨论了关于Python异步编程的困惑并约定本周找一些实战项目。”“昨天用户提到他计划下个月去日本旅行正在做攻略。”这类记忆带有时间戳和上下文更像是一个日记本。程序性记忆Procedural Memory用户的行为模式和偏好。例如“用户通常喜欢用Markdown格式接收代码示例。”“当用户提问技术问题时提供中英文对照的术语解释会让他更满意。”这类记忆通过分析历史交互数据提炼而来用于优化未来的交互策略。记忆索引与元记忆Memory Index Meta-Memory这是管理记忆的“记忆”。它记录了不同记忆之间的关联、记忆的权重重要性、新鲜度、访问频率、以及记忆的摘要。例如系统知道“摄影”这个事实与“上周讨论购买新镜头”的情景记忆以及“用户偏好看器材评测视频”的程序性记忆是高度关联的。当话题涉及“摄影”时这些关联记忆会被协同检索出来。注意这种分层和分类不是死板的教条在实际实现中开发者可以根据应用场景调整。例如一个医疗健康助手可能更需要强化“事实性记忆”如病史、用药记录而一个创意写作伙伴则可能更依赖“情景记忆”如过往的故事构思片段。2.2 核心组件交互流程理解了记忆的结构我们来看这些组件是如何协同工作的。一个典型的“记忆-响应”周期如下接收用户输入用户提出一个问题或指令例如“帮我回顾一下我们上周讨论的旅行计划”记忆检索Retrieval系统不会直接把所有记忆丢给LLM那会超出上下文窗口并引入噪音。而是先进行“记忆检索”查询理解首先系统可能用一个轻量级的LLM或规则分析用户查询的意图和关键实体如“上周”、“旅行计划”。向量检索将用户查询转换为向量Embedding然后在向量数据库中搜索与之最相关的“情景记忆”和“事实性记忆”片段。这能找到语义上相关的内容即使没有完全匹配的关键词。图遍历检索如果系统使用了图数据库来存储记忆关联此时可以沿着“旅行”-“日本”-“攻略”-“日期”这样的关联路径找到所有相关的记忆节点。时间与重要性过滤根据查询中的“上周”进行时间过滤并根据记忆的权重元记忆对结果进行排序确保最相关、最重要的记忆优先。记忆增强上下文构建检索到的相关记忆片段与当前的“工作记忆”最近几句对话一起被精心组织成一个提示Prompt上下文。这个组织过程本身就有讲究比如按时间倒序排列情景记忆把关键事实放在前面等。LLM推理与生成这个富含长期记忆的增强上下文被送入大语言模型如GPT-4、Claude或本地部署的Llama 3。LLM基于此生成回复这个回复自然就包含了“记忆”中的信息例如“当然上周二我们讨论了你计划下个月15号左右去日本东京和京都为期10天。你当时对关西地区的古建筑和怀石料理特别感兴趣我推荐了《Lonely Planet日本》作为参考书。需要我帮你细化一下行程草案吗”记忆更新与固化对话结束后系统不会浪费这次交互。它会启动“记忆更新”流程摘要生成可能调用LLM将本轮重要的对话内容总结成一段精炼的“情景记忆”摘要存入长期记忆。事实提取从对话中提取新的“事实性记忆”如用户确定了出行日期并更新数据库。关联建立将新生成的记忆与旧的、相关的记忆建立关联丰富记忆图谱。记忆衰减与清理对于长期未被访问或重要性很低的记忆可以实施“衰减”或归档避免记忆库无限膨胀影响检索效率。这个流程构成了Hermes Agent智能行为的闭环让每一次交互都成为加深“了解”的机会。3. 关键技术实现与选型解析理论很美好但落地需要坚实的技术栈。Hermes Agent作为一个开源项目其技术选型体现了实用性与前瞻性的平衡。我们来深入看看几个关键部分的实现思路。3.1 记忆的存储后端向量数据库与图数据库的抉择记忆存储是基础设施。Hermes Agent通常推荐或支持以下几种后端各有优劣向量数据库如Chroma Pinecone Weaviate Qdrant核心用途主要用于存储和检索“情景记忆”和“事实性记忆”的文本嵌入Embedding。当用户查询时通过计算查询向量与记忆向量之间的相似度如余弦相似度快速找到语义相关的记忆。优势语义检索能力极强能处理“意思相近但表述不同”的情况。部署相对简单生态成熟。劣势不擅长处理精确匹配、复杂关系如“用户A的朋友B喜欢C”和频繁更新。它更像一个“文档库”。实操建议对于大多数起步项目使用Chroma轻量、开源、易集成或Pinecone托管服务、省心来存储记忆片段是完全足够的。将每段记忆如一次对话摘要或一个用户事实及其元数据时间、类型、关联ID作为一个向量存储。图数据库如Neo4j NebulaGraph核心用途用于存储“记忆元数据”和“记忆间的关联”。例如可以建立“用户”节点连接“有爱好”边到“摄影”节点“摄影”节点又连接“发生于”边到“上周讨论”事件节点。优势直观地表示和查询复杂关系。非常适合实现“元记忆”和关联检索。例如可以轻松查询“用户所有与‘学习’相关且发生在‘晚上’的记忆”。劣势相对更重学习曲线稍陡。纯图数据库对非结构化文本记忆内容本身的语义检索支持不如向量数据库。实操建议在需要高度个性化、记忆关系复杂的场景下如知识管理、社交网络分析型Agent可以考虑引入图数据库。一个混合架构是很好的选择用向量数据库存记忆内容本身用图数据库存记忆的索引和关联关系两者通过唯一ID联接。传统关系型数据库如PostgreSQL或文档数据库如MongoDB核心用途存储结构化的“事实性记忆”用户档案、设置和作为记忆索引的元数据表。PostgreSQL配合pgvector扩展也能同时获得关系型数据管理和向量检索的能力成为一站式的选择。优势事务支持好数据结构规整适合存储需要频繁更新和精确查询的数据。劣势原生语义检索能力弱除非使用pgvector处理复杂关联查询时可能不如图数据库直观。实操建议对于轻量级应用使用PostgreSQL pgvector是一个极其实用和流行的选择它平衡了结构化和语义化查询的需求。心得不要追求“最完美”的架构起步。我的经验是从一个简单的向量数据库如Chroma开始专注于让记忆的存储和检索先跑起来。当业务逻辑复杂到需要频繁处理“关系”时再考虑引入图数据库或强化关系型数据库的设计。过早优化是万恶之源。3.2 记忆的生成与摘要让LLM成为记忆的策展人记忆不是原始对话的简单堆积那样会迅速导致信息过载和检索效率低下。Hermes Agent的核心智慧之一在于利用LLM本身来加工记忆。记忆摘要Summarization在一段较长的对话或一个任务完成后调用LLM生成摘要。例如将长达50条消息的技术讨论总结为“用户理解了Python装饰器的核心概念但在异步装饰器的应用上存在困惑已推荐阅读《Fluent Python》相关章节”。这个摘要就成为一条新的、高信息密度的“情景记忆”。提示词设计摘要的提示词至关重要。你需要明确指令“请将以下对话总结为一段不超过3句话的摘要重点提取用户的核心诉求、达成的共识以及待解决的问题。” 并可以提供示例Few-shot Learning来引导LLM产出格式和风格一致的摘要。事实提取Fact Extraction从对话中自动抽取结构化事实。例如从“我下周五晚上飞上海住两晚”中提取出(用户, 行程, 上海),(时间, 下周五晚上),(时长, 两晚)等三元组存入事实库。实现方式可以设计专门的提示词让LLM进行信息抽取也可以使用训练好的命名实体识别NER和关系抽取RE模型。对于开源方案使用LLM如Llama 3配合精心设计的提示词灵活性和准确性往往更好。记忆重要性打分Importance Scoring并非所有对话都值得记住。系统需要判断一段信息的“记忆价值”。这可以通过规则如包含关键词“偏好”、“永远”、“总是”、“不喜欢”、通过LLM判断“请判断以下信息对长期了解用户是否重要”、或通过后续的访问频率来动态调整。简单规则示例用户明确说“记住我咖啡不加糖” - 高重要性。用户问“今天天气怎么样” - 低重要性可能无需进入长期记忆。3.3 检索策略与相关性排序找到对的记忆当记忆库越来越大如何快速准确地找到最相关的记忆这就是检索策略要解决的问题。Hermes Agent通常采用混合检索策略关键词检索稀疏检索使用传统的全文检索引擎如Elasticsearch或数据库的LIKE查询快速匹配明确的关键词。例如用户问“我的过敏史”直接匹配“过敏”关键词。这一步召回率高但精度可能不足。向量检索稠密检索如之前所述使用向量数据库进行语义搜索。它能找到“我对花生过敏”这样的记忆即使用户问的是“我有什么食物不能吃”。这一步精度高能理解语义。元数据过滤结合时间范围“上周”、记忆类型“事实”、重要性分数等进行过滤缩小检索范围。重排序Re-ranking将前几步检索到的候选记忆比如Top 20用一个更精细但开销更大的模型可以是另一个LLM或一个交叉编码器模型如bge-reranker进行重新打分和排序选出最终的Top 3或Top 5注入上下文。图扩散检索如果使用了图数据库在找到初始记忆节点后可以沿着关联边“扩散”开来找到与之相连的其他相关记忆。例如找到“日本旅行”记忆节点后可以扩散找到关联的“预算”、“航班”、“酒店”等节点。相关性排序的挑战最相关的记忆不一定是语义最相似的。比如用户问“我们上次聊的那个相机推荐”语义上最相似的可能是“一篇关于相机评测的文章”但实际上你需要的是“上周二对话中关于推荐索尼A7C的记录”。因此时间衰减因子、访问频率、以及专门训练的重排序模型都至关重要。4. 实战部署与核心配置指南理论和技术栈聊了不少现在我们动手看看如何实际部署和配置一个具有基本记忆功能的Hermes Agent。这里我们以一个基于FastAPI后端、使用Chroma存储记忆、集成OpenAI GPT-4 API的简化版为例。4.1 环境准备与依赖安装首先创建一个干净的Python环境推荐3.9并安装核心依赖。# 创建项目目录并进入 mkdir hermes-agent-demo cd hermes-agent-demo python -m venv venv # Windows: venv\Scripts\activate # Linux/Mac: source venv/bin/activate # 安装核心依赖 pip install fastapi uvicorn chromadb openai python-dotenv pydanticrequirements.txt文件内容示例fastapi0.104.1 uvicorn[standard]0.24.0 chromadb0.4.18 openai1.3.0 python-dotenv1.0.0 pydantic2.5.0 sentence-transformers2.2.2 # 用于生成文本向量4.2 核心模块代码实现我们创建几个核心文件来构建系统。1. 配置与环境变量 (.env)OPENAI_API_KEYyour_openai_api_key_here EMBEDDING_MODELtext-embedding-ada-002 # OpenAI的嵌入模型或本地模型如 all-MiniLM-L6-v2 LLM_MODELgpt-4-1106-preview CHROMA_PERSIST_DIRECTORY./chroma_db2. 数据模型定义 (models.py)from pydantic import BaseModel, Field from datetime import datetime from typing import Optional, List, Dict, Any from enum import Enum class MemoryType(str, Enum): FACTUAL factual EPISODIC episodic PROCEDURAL procedural class MemoryEntity(BaseModel): 记忆实体的基类 id: str content: str # 记忆的文本内容 embedding: Optional[List[float]] None # 文本向量 memory_type: MemoryType metadata: Dict[str, Any] Field(default_factorydict) # 如{user_id: 123, timestamp: ..., importance: 0.8} created_at: datetime Field(default_factorydatetime.now) last_accessed_at: Optional[datetime] None class ConversationMemory(BaseModel): 一次对话的记忆上下文 user_id: str session_id: str messages: List[Dict] # 原始的对话消息列表 summary: Optional[str] None # 本次对话的摘要 extracted_facts: List[Dict] Field(default_factorylist) # 提取出的事实 created_at: datetime Field(default_factorydatetime.now)3. 记忆管理核心 (memory_manager.py)import chromadb from chromadb.config import Settings from sentence_transformers import SentenceTransformer import openai import os from dotenv import load_dotenv from models import MemoryEntity, MemoryType from typing import List, Optional import uuid load_dotenv() class MemoryManager: def __init__(self): # 初始化Chroma客户端持久化存储 self.client chromadb.PersistentClient( pathos.getenv(CHROMA_PERSIST_DIRECTORY, ./chroma_db) ) # 获取或创建一个集合类似于数据库的表 self.collection self.client.get_or_create_collection(nameuser_memories) # 初始化嵌入模型这里示例使用本地模型降低成本。也可用OpenAI的嵌入API。 self.embedding_model SentenceTransformer(all-MiniLM-L6-v2) # 如果使用OpenAI则注释上一行使用下一行需配置API Key # self.embedding_model None self.openai_client openai.OpenAI(api_keyos.getenv(OPENAI_API_KEY)) def _get_embedding(self, text: str) - List[float]: 生成文本的向量嵌入 if self.embedding_model: return self.embedding_model.encode(text).tolist() else: # 使用OpenAI Embedding API response self.openai_client.embeddings.create( modeltext-embedding-ada-002, inputtext ) return response.data[0].embedding def store_memory(self, memory: MemoryEntity) - str: 存储一条记忆到向量数据库 if not memory.embedding: memory.embedding self._get_embedding(memory.content) memory_id memory.id if memory.id else str(uuid.uuid4()) # 存储到Chroma self.collection.add( documents[memory.content], embeddings[memory.embedding], metadatas[{**memory.metadata, type: memory.memory_type, id: memory_id}], ids[memory_id] ) return memory_id def retrieve_relevant_memories(self, query: str, user_id: str, top_k: int 5) - List[MemoryEntity]: 根据查询检索相关记忆 query_embedding self._get_embedding(query) # 在Chroma中查询同时用metadata过滤特定用户 results self.collection.query( query_embeddings[query_embedding], n_resultstop_k, where{user_id: user_id} # 元数据过滤只找该用户的记忆 ) memories [] for i in range(len(results[ids][0])): mem MemoryEntity( idresults[ids][0][i], contentresults[documents][0][i], embeddingresults[embeddings][0][i] if results[embeddings] else None, memory_typeresults[metadatas][0][i].get(type, MemoryType.EPISODIC), metadataresults[metadatas][0][i] ) memories.append(mem) return memories def generate_conversation_summary(self, messages: List[Dict]) - str: 使用LLM生成对话摘要 # 将对话历史格式化为文本 conversation_text \n.join([f{msg[role]}: {msg[content]} for msg in messages[-10:]]) # 取最近10轮 prompt f 请将以下对话总结成一段简洁的摘要不超过3句话重点提取 1. 用户的核心需求或讨论的主题。 2. 达成的主要结论或提供的解决方案。 3. 任何待解决的问题或下一步计划。 对话记录 {conversation_text} 摘要 try: response self.openai_client.chat.completions.create( modelgpt-3.5-turbo, # 摘要任务可以用小模型 messages[{role: user, content: prompt}], temperature0.2, max_tokens150 ) return response.choices[0].message.content.strip() except Exception as e: print(f生成摘要失败: {e}) return 未能生成摘要。4. 智能体主逻辑与API (main.py)from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import List import openai import os from dotenv import load_dotenv from memory_manager import MemoryManager from models import MemoryEntity, MemoryType, ConversationMemory import uuid import json load_dotenv() app FastAPI(titleHermes Agent Demo) memory_manager MemoryManager() openai_client openai.OpenAI(api_keyos.getenv(OPENAI_API_KEY)) class UserMessage(BaseModel): user_id: str session_id: str default message: str use_memory: bool True app.post(/chat) async def chat_with_memory(user_msg: UserMessage): 核心聊天端点集成记忆功能 user_id user_msg.user_id query user_msg.message # 1. 检索相关长期记忆 relevant_memories [] if user_msg.use_memory: relevant_memories memory_manager.retrieve_relevant_memories(query, user_id, top_k3) # 2. 构建增强系统提示词 system_prompt f你是一个有帮助的AI助手并且你拥有长期记忆。以下是一些关于用户【{user_id}】的过往记忆可能对本次对话有帮助 if relevant_memories: for i, mem in enumerate(relevant_memories): system_prompt f\n记忆{i1}{mem.memory_type}: {mem.content} else: system_prompt \n暂无相关长期记忆。 system_prompt 请基于这些记忆如果相关和当前对话友好、准确地回应用户。如果记忆中的信息与当前问题无关请忽略它们。 当前对话 # 3. 调用LLM生成回复 try: response openai_client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-3.5-turbo), messages[ {role: system, content: system_prompt}, {role: user, content: query} ], temperature0.7, max_tokens500 ) ai_response response.choices[0].message.content except Exception as e: raise HTTPException(status_code500, detailfLLM调用失败: {e}) # 4. 异步处理记忆更新 - 这里简化为同步生产环境应用消息队列 # 4.1 存储当前对话到临时会话历史实际应使用Redis或数据库 # 4.2 判断是否需要生成摘要并存储为长期记忆例如对话轮次5或用户主动要求 # 此处简化仅当查询包含“记住”等关键词时存储为事实记忆 if 记住 in query or note that in query.lower(): fact_memory MemoryEntity( idstr(uuid.uuid4()), contentf用户提及{query}, memory_typeMemoryType.FACTUAL, metadata{user_id: user_id, source: explicit_instruction} ) memory_manager.store_memory(fact_memory) return { user_id: user_id, response: ai_response, memories_used: [{id: m.id, content_preview: m.content[:50]...} for m in relevant_memories] } app.post(/summarize_session) async def summarize_session(user_id: str, session_messages: List[dict]): 手动触发总结一段会话并存入长期记忆 summary memory_manager.generate_conversation_summary(session_messages) episodic_memory MemoryEntity( idstr(uuid.uuid4()), contentf对话摘要{summary}, memory_typeMemoryType.EPISODIC, metadata{user_id: user_id, source: session_summary} ) mem_id memory_manager.store_memory(episodic_memory) return {status: success, memory_id: mem_id, summary: summary} if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)4.3 运行与测试在项目根目录下确保.env文件中的OPENAI_API_KEY已填写。运行服务python main.py使用curl或Postman进行测试# 测试带记忆的聊天 curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d { user_id: alice, message: 记住我对芒果过敏。, use_memory: true } # 返回示例{user_id:alice,response:好的我已经记下了你对芒果过敏。以后在涉及食物建议时我会特别注意这一点。,memories_used:[]} # 第二次提问测试记忆检索 curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d { user_id: alice, message: 推荐一些适合我的水果。, use_memory: true } # 理想的返回中memories_used应包含之前存储的过敏记忆且回复应避免推荐芒果。这个简化版实现了Hermes Agent最核心的记忆存储、检索和应用循环。你可以看到当用户第一次声明过敏信息后系统将其作为一条“事实性记忆”存储。当用户后续询问水果推荐时系统会先检索相关记忆“芒果过敏”并将其作为上下文提供给LLM从而生成个性化的、安全的回复。5. 高级特性与优化方向基础版本跑通后我们可以探讨如何让这个智能体变得更聪明、更高效。这些都是Hermes Agent项目深度探索的方向。5.1 记忆的主动管理与遗忘机制一个只会记住、不会忘记的AI是可怕的也是低效的。记忆管理必须包含“遗忘”或“降级”策略。基于时间的衰减为每条记忆附加一个“新鲜度”或“强度”值随着时间推移而衰减。每次被成功检索并利用时其强度增加。强度低于某个阈值的记忆在检索时优先级降低甚至可以被归档或删除。基于重要性的筛选在生成记忆摘要或提取事实时由LLM或规则对信息的重要性进行打分。例如“用户的结婚纪念日”重要性为9“用户今天喝了咖啡”重要性为1。低重要性记忆可以设置更短的保存时间或更快的衰减速度。记忆合并与去重当关于同一主题的记忆过多时例如用户多次提到喜欢猫系统可以定期触发记忆合并将多条相似记忆合并成一条更全面、更简洁的记忆避免冗余。用户可控的遗忘提供接口让用户主动删除或修正记忆。例如“忘记我刚才说的电话号码”或“我其实对花生不过敏了请更新”。5.2 多模态记忆与情感理解未来的个人助理不应只理解文字。多模态记忆存储用户可能分享图片、文档、语音消息。系统需要能提取这些多媒体内容中的信息通过图像识别、语音转文字、文档解析并将其转换为可存储和检索的文本摘要或特征向量与文本记忆关联存储。例如用户发了一张晚餐照片系统可以识别出食物并存储“用户似乎常吃意大利面”这样的记忆。情感与风格记忆分析用户历史对话的情感倾向积极、消极、中性和语言风格正式、随意、幽默。在回复时可以调整语气与之匹配。例如发现用户最近几次对话都很简短消极AI的回复可以更简洁并表达关心。5.3 分布式记忆与隐私安全记忆是高度敏感的个人数据。本地优先架构真正的个人智能体应该支持完全本地运行。所有记忆数据存储在用户自己的设备上模型使用本地或可信任的私有化模型如通过Ollama部署的Llama 3。Hermes Agent的开源特性为此提供了可能。联邦学习与加密记忆在需要云端协同的场景下可以采用联邦学习思路让模型在本地学习用户偏好只上传加密的、脱敏的模型参数更新。或者将记忆内容在本地加密后再上传到云端存储密钥仅用户持有。记忆访问控制定义不同级别的记忆隐私。有些记忆如工作项目细节可以被共享给“工作助理”角色有些记忆如健康数据则严格保密。系统需要实现基于角色的记忆访问控制。5.4 与工具和行动的集成一个能记住你的智能体最终要能替你做事。记忆驱动的自动化将记忆与自动化工具如Zapier, n8n或直接API调用结合。例如记忆“用户每周末上午9点健身”可以自动在每周五晚上提醒准备健身装备甚至自动预约周日的健身房。预测与主动服务基于长期记忆中的模式进行预测并主动提供服务。例如通过分析用户过去三个月的出行记录在类似时间点主动推送“是否需要预订机票/酒店”的提醒。或者发现用户每次学习新编程语言都会搜索某个教程网站可以在用户提到学习新语言时主动推荐该网站。跨应用记忆同步理想状态下用户在邮件中提到的会议时间、在日历中标记的生日、在笔记软件中写的项目计划都能被智能体安全地索引和关联形成统一的用户记忆图谱。这需要一套标准化的API和严格的用户授权协议。6. 常见问题与实战排坑指南在实际开发和调试Hermes Agent类项目时你会遇到一些典型问题。以下是我踩过坑后总结的经验。6.1 记忆检索不准确或召回无关信息这是最常见的问题。你的AI突然开始胡言乱语可能是因为注入了错误的记忆。问题根源嵌入模型不匹配用于生成存储记忆的嵌入模型与用于生成查询向量的模型不一致导致向量空间不匹配。元数据过滤缺失或错误没有正确过滤user_id导致检索到其他用户的记忆。记忆分块过大存储的“记忆”文本太长如整篇对话包含太多无关信息导致检索精度下降。缺少重排序向量检索返回的Top-K结果中可能混入几个语义相关但实际无关的片段直接全部注入会干扰LLM。解决方案统一嵌入模型确保存储和查询使用同一个嵌入模型。强化元数据为每条记忆添加丰富的元数据如user_id,session_id,topic,timestamp,importance_score。检索时严格用user_id过滤并可按topic和timestamp进一步筛选。优化记忆分块不要存储原始长文本。对于长对话先进行摘要存储摘要。对于长文档可以按语义或固定长度进行智能分块每个块单独存储和索引。引入重排序层在向量检索后用一个更精细的交叉编码器模型如BGE-Reranker对候选记忆进行重新打分只选择分数最高的1-2条注入上下文。这能显著提升精度。设置相似度阈值仅当记忆与查询的向量相似度超过某个阈值如0.7时才认为相关并注入。低于阈值的即使排在前面也舍弃。6.2 上下文窗口爆炸与Token消耗失控记忆太多导致提示词过长超出模型上下文窗口或造成不必要的API费用激增。问题根源无节制地将所有相关记忆的原始文本都塞进提示词。解决方案记忆摘要化这是最重要的手段。长期记忆应以摘要形式存在而非原始文本。动态上下文窗口管理实现一个“上下文管理器”它负责维护一个固定长度的“工作上下文”。每次新的用户输入到来时它决定哪些长期记忆需要被召回、哪些旧的工作记忆需要被压缩或丢弃。可以使用LLM来生成当前对话的简短摘要用以替换掉冗长的原始历史。分层注入不是所有记忆都平等。将检索到的记忆按相关性排序后可以尝试只注入最相关的一条完整记忆对于其他相关记忆仅注入其“关键词”或“极简摘要”并告诉LLM“还有其他相关记忆关于[X, Y]如需细节可告知。”使用支持长上下文的模型如果成本允许直接使用Claude-3-200k或GPT-4-128k这类超长上下文模型可以缓解压力但非根本解决之道。6.3 记忆冲突与信息不一致用户可能提供前后矛盾的信息如先说喜欢狗后说对狗毛过敏或者记忆本身存在错误。问题根源记忆系统被动存储所有信息缺乏冲突检测和消解机制。解决方案事实性记忆的版本管理与置信度对于事实性记忆如“用户过敏源”存储时附带置信度来源如“用户明确陈述”、“系统推断”、时间戳和版本号。当新信息存入时检查是否存在冲突。如果新信息的置信度更高如用户更近期的明确声明则覆盖旧信息或将旧信息标记为过时。让LLM参与冲突判断在存储新记忆前可以将与之可能冲突的旧记忆一起发给LLM询问“新信息[用户现在对猫过敏]与旧信息[用户养猫]是否冲突如果冲突应如何更新记忆”。根据LLM的判断来决定存储策略。提供用户修正接口当AI基于可能矛盾的记忆做出回应时可以附带询问“我记得你之前提到X现在你说Y需要我更新记忆吗”将最终裁决权交给用户。6.4 启动冷启动与早期表现新用户刚开始使用时记忆库是空的AI无法展现“个性化”的优势体验可能不如传统无记忆的ChatGPT。问题根源记忆系统需要数据积累。解决方案设计引导性对话在初次交互时主动引导用户提供一些基础信息。例如“为了更好为你服务可以告诉我你的名字以及你希望我主要在哪方面帮助你吗例如编程、写作、日程管理”。利用显式记忆指令鼓励用户使用“记住……”“以后请……”这样的句式系统检测到这类句式时会主动将其提取为高优先级事实记忆。设置默认人格或领域记忆即使没有用户个人记忆也可以预装一些通用的“角色设定”或“领域知识”作为初始记忆让AI在特定领域如“技术顾问”、“创意写手”下表现更好。快速学习设计在早期对话中提高记忆提取和存储的敏感度尽可能多地从有限对话中提取有效记忆快速构建初始用户画像。开发一个真正能“记住”你的AI智能体是一条充满挑战但回报巨大的道路。Hermes Agent项目为我们提供了一个优秀的开源起点和设计范本。从简单的向量存储到复杂的记忆图谱从被动的问答到主动的预测服务其演进空间非常广阔。最关键的是它让我们看到了AI从“通用工具”向“个人伙伴”演进的一种切实可行的技术路径。在实际动手时我建议从一个非常具体的垂直场景开始比如“健身饮食记录助手”或“个人读书笔记分析员”聚焦解决该场景下的记忆痛点迭代开发你会对记忆系统的价值有更深刻的理解。
开源AI智能体记忆系统：从向量检索到个性化服务的架构实践
1. 项目概述一个真正“记住”你的开源AI智能体最近在AI智能体Agent这个赛道上有一个项目让我眼前一亮它叫“Hermes Agent”。这个名字本身就很有意思赫尔墨斯是希腊神话中的信使之神象征着沟通与信息的传递。而这个项目最核心的卖点也是它区别于市面上绝大多数“健忘”AI助手的关键就是它的“记忆”能力。简单来说Hermes Agent是一个开源框架旨在构建能够长期、持续地记住与你互动的上下文、偏好、习惯甚至未完成任务并据此提供个性化服务的AI智能体。这听起来似乎理所当然但实际体验过各种AI工具的朋友都知道当前的AI模型无论是基于API的ChatGPT还是本地部署的开源大模型在对话中基本都是“金鱼记忆”——每次对话都是一个新的开始。你需要在每次对话中重复你的背景、你的需求、你之前讨论过的细节。这对于构建一个真正能成为个人助理、长期伙伴的AI来说是致命的短板。Hermes Agent正是为了解决这个问题而生。它通过一套精巧的架构将“记忆”作为核心模块让AI能够跨越会话边界真正地“认识”你。这个项目适合谁呢首先是AI应用开发者。如果你想构建一个需要长期用户粘性的应用比如个性化学习伴侣、健康管理助手、创意协作伙伴Hermes Agent提供的记忆框架是绝佳的起点。其次是技术爱好者和研究者。你可以深入其架构理解如何将向量数据库、图数据库与大语言模型结合来实现复杂的记忆存储与检索逻辑。最后即使是普通用户如果你对部署一个属于自己的、有“灵魂”的AI助手感兴趣Hermes Agent也提供了相对清晰的路径。2. 核心架构与设计哲学记忆如何被结构化要理解Hermes Agent为什么能“记住”我们必须先拆解它的核心架构设计。这不仅仅是简单地把对话历史存进数据库而是一套关于如何结构化、存储、检索和应用“记忆”的完整方法论。2.1 记忆的三层结构从瞬时到永恒Hermes Agent将记忆抽象为三个层次这种分层设计是其智能的基石工作记忆Working Memory这相当于AI的“短期记忆”或“注意力焦点”。它存储当前对话轮次中的上下文通常就是最近几次的问答。这部分记忆直接提供给大语言模型LLM用于生成当前的回复。它的特点是容量小、存取快、但易挥发对话结束后通常会被清空或压缩归档。长期记忆Long-Term Memory这是项目的核心。它存储所有需要被长期保留的信息。但“长期记忆”本身又是一个复杂的集合Hermes Agent进一步将其细分事实性记忆Factual Memory关于“你”的客观事实。例如“用户张三是一名住在北京的软件工程师喜欢摄影和骑行。”“用户李四对花生过敏。”这类信息通常以“键-值”对或三元组实体-关系-实体的形式存储便于精确查询。情景记忆Episodic Memory特定事件或对话片段的记录。例如“上周二用户和我讨论了关于Python异步编程的困惑并约定本周找一些实战项目。”“昨天用户提到他计划下个月去日本旅行正在做攻略。”这类记忆带有时间戳和上下文更像是一个日记本。程序性记忆Procedural Memory用户的行为模式和偏好。例如“用户通常喜欢用Markdown格式接收代码示例。”“当用户提问技术问题时提供中英文对照的术语解释会让他更满意。”这类记忆通过分析历史交互数据提炼而来用于优化未来的交互策略。记忆索引与元记忆Memory Index Meta-Memory这是管理记忆的“记忆”。它记录了不同记忆之间的关联、记忆的权重重要性、新鲜度、访问频率、以及记忆的摘要。例如系统知道“摄影”这个事实与“上周讨论购买新镜头”的情景记忆以及“用户偏好看器材评测视频”的程序性记忆是高度关联的。当话题涉及“摄影”时这些关联记忆会被协同检索出来。注意这种分层和分类不是死板的教条在实际实现中开发者可以根据应用场景调整。例如一个医疗健康助手可能更需要强化“事实性记忆”如病史、用药记录而一个创意写作伙伴则可能更依赖“情景记忆”如过往的故事构思片段。2.2 核心组件交互流程理解了记忆的结构我们来看这些组件是如何协同工作的。一个典型的“记忆-响应”周期如下接收用户输入用户提出一个问题或指令例如“帮我回顾一下我们上周讨论的旅行计划”记忆检索Retrieval系统不会直接把所有记忆丢给LLM那会超出上下文窗口并引入噪音。而是先进行“记忆检索”查询理解首先系统可能用一个轻量级的LLM或规则分析用户查询的意图和关键实体如“上周”、“旅行计划”。向量检索将用户查询转换为向量Embedding然后在向量数据库中搜索与之最相关的“情景记忆”和“事实性记忆”片段。这能找到语义上相关的内容即使没有完全匹配的关键词。图遍历检索如果系统使用了图数据库来存储记忆关联此时可以沿着“旅行”-“日本”-“攻略”-“日期”这样的关联路径找到所有相关的记忆节点。时间与重要性过滤根据查询中的“上周”进行时间过滤并根据记忆的权重元记忆对结果进行排序确保最相关、最重要的记忆优先。记忆增强上下文构建检索到的相关记忆片段与当前的“工作记忆”最近几句对话一起被精心组织成一个提示Prompt上下文。这个组织过程本身就有讲究比如按时间倒序排列情景记忆把关键事实放在前面等。LLM推理与生成这个富含长期记忆的增强上下文被送入大语言模型如GPT-4、Claude或本地部署的Llama 3。LLM基于此生成回复这个回复自然就包含了“记忆”中的信息例如“当然上周二我们讨论了你计划下个月15号左右去日本东京和京都为期10天。你当时对关西地区的古建筑和怀石料理特别感兴趣我推荐了《Lonely Planet日本》作为参考书。需要我帮你细化一下行程草案吗”记忆更新与固化对话结束后系统不会浪费这次交互。它会启动“记忆更新”流程摘要生成可能调用LLM将本轮重要的对话内容总结成一段精炼的“情景记忆”摘要存入长期记忆。事实提取从对话中提取新的“事实性记忆”如用户确定了出行日期并更新数据库。关联建立将新生成的记忆与旧的、相关的记忆建立关联丰富记忆图谱。记忆衰减与清理对于长期未被访问或重要性很低的记忆可以实施“衰减”或归档避免记忆库无限膨胀影响检索效率。这个流程构成了Hermes Agent智能行为的闭环让每一次交互都成为加深“了解”的机会。3. 关键技术实现与选型解析理论很美好但落地需要坚实的技术栈。Hermes Agent作为一个开源项目其技术选型体现了实用性与前瞻性的平衡。我们来深入看看几个关键部分的实现思路。3.1 记忆的存储后端向量数据库与图数据库的抉择记忆存储是基础设施。Hermes Agent通常推荐或支持以下几种后端各有优劣向量数据库如Chroma Pinecone Weaviate Qdrant核心用途主要用于存储和检索“情景记忆”和“事实性记忆”的文本嵌入Embedding。当用户查询时通过计算查询向量与记忆向量之间的相似度如余弦相似度快速找到语义相关的记忆。优势语义检索能力极强能处理“意思相近但表述不同”的情况。部署相对简单生态成熟。劣势不擅长处理精确匹配、复杂关系如“用户A的朋友B喜欢C”和频繁更新。它更像一个“文档库”。实操建议对于大多数起步项目使用Chroma轻量、开源、易集成或Pinecone托管服务、省心来存储记忆片段是完全足够的。将每段记忆如一次对话摘要或一个用户事实及其元数据时间、类型、关联ID作为一个向量存储。图数据库如Neo4j NebulaGraph核心用途用于存储“记忆元数据”和“记忆间的关联”。例如可以建立“用户”节点连接“有爱好”边到“摄影”节点“摄影”节点又连接“发生于”边到“上周讨论”事件节点。优势直观地表示和查询复杂关系。非常适合实现“元记忆”和关联检索。例如可以轻松查询“用户所有与‘学习’相关且发生在‘晚上’的记忆”。劣势相对更重学习曲线稍陡。纯图数据库对非结构化文本记忆内容本身的语义检索支持不如向量数据库。实操建议在需要高度个性化、记忆关系复杂的场景下如知识管理、社交网络分析型Agent可以考虑引入图数据库。一个混合架构是很好的选择用向量数据库存记忆内容本身用图数据库存记忆的索引和关联关系两者通过唯一ID联接。传统关系型数据库如PostgreSQL或文档数据库如MongoDB核心用途存储结构化的“事实性记忆”用户档案、设置和作为记忆索引的元数据表。PostgreSQL配合pgvector扩展也能同时获得关系型数据管理和向量检索的能力成为一站式的选择。优势事务支持好数据结构规整适合存储需要频繁更新和精确查询的数据。劣势原生语义检索能力弱除非使用pgvector处理复杂关联查询时可能不如图数据库直观。实操建议对于轻量级应用使用PostgreSQL pgvector是一个极其实用和流行的选择它平衡了结构化和语义化查询的需求。心得不要追求“最完美”的架构起步。我的经验是从一个简单的向量数据库如Chroma开始专注于让记忆的存储和检索先跑起来。当业务逻辑复杂到需要频繁处理“关系”时再考虑引入图数据库或强化关系型数据库的设计。过早优化是万恶之源。3.2 记忆的生成与摘要让LLM成为记忆的策展人记忆不是原始对话的简单堆积那样会迅速导致信息过载和检索效率低下。Hermes Agent的核心智慧之一在于利用LLM本身来加工记忆。记忆摘要Summarization在一段较长的对话或一个任务完成后调用LLM生成摘要。例如将长达50条消息的技术讨论总结为“用户理解了Python装饰器的核心概念但在异步装饰器的应用上存在困惑已推荐阅读《Fluent Python》相关章节”。这个摘要就成为一条新的、高信息密度的“情景记忆”。提示词设计摘要的提示词至关重要。你需要明确指令“请将以下对话总结为一段不超过3句话的摘要重点提取用户的核心诉求、达成的共识以及待解决的问题。” 并可以提供示例Few-shot Learning来引导LLM产出格式和风格一致的摘要。事实提取Fact Extraction从对话中自动抽取结构化事实。例如从“我下周五晚上飞上海住两晚”中提取出(用户, 行程, 上海),(时间, 下周五晚上),(时长, 两晚)等三元组存入事实库。实现方式可以设计专门的提示词让LLM进行信息抽取也可以使用训练好的命名实体识别NER和关系抽取RE模型。对于开源方案使用LLM如Llama 3配合精心设计的提示词灵活性和准确性往往更好。记忆重要性打分Importance Scoring并非所有对话都值得记住。系统需要判断一段信息的“记忆价值”。这可以通过规则如包含关键词“偏好”、“永远”、“总是”、“不喜欢”、通过LLM判断“请判断以下信息对长期了解用户是否重要”、或通过后续的访问频率来动态调整。简单规则示例用户明确说“记住我咖啡不加糖” - 高重要性。用户问“今天天气怎么样” - 低重要性可能无需进入长期记忆。3.3 检索策略与相关性排序找到对的记忆当记忆库越来越大如何快速准确地找到最相关的记忆这就是检索策略要解决的问题。Hermes Agent通常采用混合检索策略关键词检索稀疏检索使用传统的全文检索引擎如Elasticsearch或数据库的LIKE查询快速匹配明确的关键词。例如用户问“我的过敏史”直接匹配“过敏”关键词。这一步召回率高但精度可能不足。向量检索稠密检索如之前所述使用向量数据库进行语义搜索。它能找到“我对花生过敏”这样的记忆即使用户问的是“我有什么食物不能吃”。这一步精度高能理解语义。元数据过滤结合时间范围“上周”、记忆类型“事实”、重要性分数等进行过滤缩小检索范围。重排序Re-ranking将前几步检索到的候选记忆比如Top 20用一个更精细但开销更大的模型可以是另一个LLM或一个交叉编码器模型如bge-reranker进行重新打分和排序选出最终的Top 3或Top 5注入上下文。图扩散检索如果使用了图数据库在找到初始记忆节点后可以沿着关联边“扩散”开来找到与之相连的其他相关记忆。例如找到“日本旅行”记忆节点后可以扩散找到关联的“预算”、“航班”、“酒店”等节点。相关性排序的挑战最相关的记忆不一定是语义最相似的。比如用户问“我们上次聊的那个相机推荐”语义上最相似的可能是“一篇关于相机评测的文章”但实际上你需要的是“上周二对话中关于推荐索尼A7C的记录”。因此时间衰减因子、访问频率、以及专门训练的重排序模型都至关重要。4. 实战部署与核心配置指南理论和技术栈聊了不少现在我们动手看看如何实际部署和配置一个具有基本记忆功能的Hermes Agent。这里我们以一个基于FastAPI后端、使用Chroma存储记忆、集成OpenAI GPT-4 API的简化版为例。4.1 环境准备与依赖安装首先创建一个干净的Python环境推荐3.9并安装核心依赖。# 创建项目目录并进入 mkdir hermes-agent-demo cd hermes-agent-demo python -m venv venv # Windows: venv\Scripts\activate # Linux/Mac: source venv/bin/activate # 安装核心依赖 pip install fastapi uvicorn chromadb openai python-dotenv pydanticrequirements.txt文件内容示例fastapi0.104.1 uvicorn[standard]0.24.0 chromadb0.4.18 openai1.3.0 python-dotenv1.0.0 pydantic2.5.0 sentence-transformers2.2.2 # 用于生成文本向量4.2 核心模块代码实现我们创建几个核心文件来构建系统。1. 配置与环境变量 (.env)OPENAI_API_KEYyour_openai_api_key_here EMBEDDING_MODELtext-embedding-ada-002 # OpenAI的嵌入模型或本地模型如 all-MiniLM-L6-v2 LLM_MODELgpt-4-1106-preview CHROMA_PERSIST_DIRECTORY./chroma_db2. 数据模型定义 (models.py)from pydantic import BaseModel, Field from datetime import datetime from typing import Optional, List, Dict, Any from enum import Enum class MemoryType(str, Enum): FACTUAL factual EPISODIC episodic PROCEDURAL procedural class MemoryEntity(BaseModel): 记忆实体的基类 id: str content: str # 记忆的文本内容 embedding: Optional[List[float]] None # 文本向量 memory_type: MemoryType metadata: Dict[str, Any] Field(default_factorydict) # 如{user_id: 123, timestamp: ..., importance: 0.8} created_at: datetime Field(default_factorydatetime.now) last_accessed_at: Optional[datetime] None class ConversationMemory(BaseModel): 一次对话的记忆上下文 user_id: str session_id: str messages: List[Dict] # 原始的对话消息列表 summary: Optional[str] None # 本次对话的摘要 extracted_facts: List[Dict] Field(default_factorylist) # 提取出的事实 created_at: datetime Field(default_factorydatetime.now)3. 记忆管理核心 (memory_manager.py)import chromadb from chromadb.config import Settings from sentence_transformers import SentenceTransformer import openai import os from dotenv import load_dotenv from models import MemoryEntity, MemoryType from typing import List, Optional import uuid load_dotenv() class MemoryManager: def __init__(self): # 初始化Chroma客户端持久化存储 self.client chromadb.PersistentClient( pathos.getenv(CHROMA_PERSIST_DIRECTORY, ./chroma_db) ) # 获取或创建一个集合类似于数据库的表 self.collection self.client.get_or_create_collection(nameuser_memories) # 初始化嵌入模型这里示例使用本地模型降低成本。也可用OpenAI的嵌入API。 self.embedding_model SentenceTransformer(all-MiniLM-L6-v2) # 如果使用OpenAI则注释上一行使用下一行需配置API Key # self.embedding_model None self.openai_client openai.OpenAI(api_keyos.getenv(OPENAI_API_KEY)) def _get_embedding(self, text: str) - List[float]: 生成文本的向量嵌入 if self.embedding_model: return self.embedding_model.encode(text).tolist() else: # 使用OpenAI Embedding API response self.openai_client.embeddings.create( modeltext-embedding-ada-002, inputtext ) return response.data[0].embedding def store_memory(self, memory: MemoryEntity) - str: 存储一条记忆到向量数据库 if not memory.embedding: memory.embedding self._get_embedding(memory.content) memory_id memory.id if memory.id else str(uuid.uuid4()) # 存储到Chroma self.collection.add( documents[memory.content], embeddings[memory.embedding], metadatas[{**memory.metadata, type: memory.memory_type, id: memory_id}], ids[memory_id] ) return memory_id def retrieve_relevant_memories(self, query: str, user_id: str, top_k: int 5) - List[MemoryEntity]: 根据查询检索相关记忆 query_embedding self._get_embedding(query) # 在Chroma中查询同时用metadata过滤特定用户 results self.collection.query( query_embeddings[query_embedding], n_resultstop_k, where{user_id: user_id} # 元数据过滤只找该用户的记忆 ) memories [] for i in range(len(results[ids][0])): mem MemoryEntity( idresults[ids][0][i], contentresults[documents][0][i], embeddingresults[embeddings][0][i] if results[embeddings] else None, memory_typeresults[metadatas][0][i].get(type, MemoryType.EPISODIC), metadataresults[metadatas][0][i] ) memories.append(mem) return memories def generate_conversation_summary(self, messages: List[Dict]) - str: 使用LLM生成对话摘要 # 将对话历史格式化为文本 conversation_text \n.join([f{msg[role]}: {msg[content]} for msg in messages[-10:]]) # 取最近10轮 prompt f 请将以下对话总结成一段简洁的摘要不超过3句话重点提取 1. 用户的核心需求或讨论的主题。 2. 达成的主要结论或提供的解决方案。 3. 任何待解决的问题或下一步计划。 对话记录 {conversation_text} 摘要 try: response self.openai_client.chat.completions.create( modelgpt-3.5-turbo, # 摘要任务可以用小模型 messages[{role: user, content: prompt}], temperature0.2, max_tokens150 ) return response.choices[0].message.content.strip() except Exception as e: print(f生成摘要失败: {e}) return 未能生成摘要。4. 智能体主逻辑与API (main.py)from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import List import openai import os from dotenv import load_dotenv from memory_manager import MemoryManager from models import MemoryEntity, MemoryType, ConversationMemory import uuid import json load_dotenv() app FastAPI(titleHermes Agent Demo) memory_manager MemoryManager() openai_client openai.OpenAI(api_keyos.getenv(OPENAI_API_KEY)) class UserMessage(BaseModel): user_id: str session_id: str default message: str use_memory: bool True app.post(/chat) async def chat_with_memory(user_msg: UserMessage): 核心聊天端点集成记忆功能 user_id user_msg.user_id query user_msg.message # 1. 检索相关长期记忆 relevant_memories [] if user_msg.use_memory: relevant_memories memory_manager.retrieve_relevant_memories(query, user_id, top_k3) # 2. 构建增强系统提示词 system_prompt f你是一个有帮助的AI助手并且你拥有长期记忆。以下是一些关于用户【{user_id}】的过往记忆可能对本次对话有帮助 if relevant_memories: for i, mem in enumerate(relevant_memories): system_prompt f\n记忆{i1}{mem.memory_type}: {mem.content} else: system_prompt \n暂无相关长期记忆。 system_prompt 请基于这些记忆如果相关和当前对话友好、准确地回应用户。如果记忆中的信息与当前问题无关请忽略它们。 当前对话 # 3. 调用LLM生成回复 try: response openai_client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-3.5-turbo), messages[ {role: system, content: system_prompt}, {role: user, content: query} ], temperature0.7, max_tokens500 ) ai_response response.choices[0].message.content except Exception as e: raise HTTPException(status_code500, detailfLLM调用失败: {e}) # 4. 异步处理记忆更新 - 这里简化为同步生产环境应用消息队列 # 4.1 存储当前对话到临时会话历史实际应使用Redis或数据库 # 4.2 判断是否需要生成摘要并存储为长期记忆例如对话轮次5或用户主动要求 # 此处简化仅当查询包含“记住”等关键词时存储为事实记忆 if 记住 in query or note that in query.lower(): fact_memory MemoryEntity( idstr(uuid.uuid4()), contentf用户提及{query}, memory_typeMemoryType.FACTUAL, metadata{user_id: user_id, source: explicit_instruction} ) memory_manager.store_memory(fact_memory) return { user_id: user_id, response: ai_response, memories_used: [{id: m.id, content_preview: m.content[:50]...} for m in relevant_memories] } app.post(/summarize_session) async def summarize_session(user_id: str, session_messages: List[dict]): 手动触发总结一段会话并存入长期记忆 summary memory_manager.generate_conversation_summary(session_messages) episodic_memory MemoryEntity( idstr(uuid.uuid4()), contentf对话摘要{summary}, memory_typeMemoryType.EPISODIC, metadata{user_id: user_id, source: session_summary} ) mem_id memory_manager.store_memory(episodic_memory) return {status: success, memory_id: mem_id, summary: summary} if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)4.3 运行与测试在项目根目录下确保.env文件中的OPENAI_API_KEY已填写。运行服务python main.py使用curl或Postman进行测试# 测试带记忆的聊天 curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d { user_id: alice, message: 记住我对芒果过敏。, use_memory: true } # 返回示例{user_id:alice,response:好的我已经记下了你对芒果过敏。以后在涉及食物建议时我会特别注意这一点。,memories_used:[]} # 第二次提问测试记忆检索 curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d { user_id: alice, message: 推荐一些适合我的水果。, use_memory: true } # 理想的返回中memories_used应包含之前存储的过敏记忆且回复应避免推荐芒果。这个简化版实现了Hermes Agent最核心的记忆存储、检索和应用循环。你可以看到当用户第一次声明过敏信息后系统将其作为一条“事实性记忆”存储。当用户后续询问水果推荐时系统会先检索相关记忆“芒果过敏”并将其作为上下文提供给LLM从而生成个性化的、安全的回复。5. 高级特性与优化方向基础版本跑通后我们可以探讨如何让这个智能体变得更聪明、更高效。这些都是Hermes Agent项目深度探索的方向。5.1 记忆的主动管理与遗忘机制一个只会记住、不会忘记的AI是可怕的也是低效的。记忆管理必须包含“遗忘”或“降级”策略。基于时间的衰减为每条记忆附加一个“新鲜度”或“强度”值随着时间推移而衰减。每次被成功检索并利用时其强度增加。强度低于某个阈值的记忆在检索时优先级降低甚至可以被归档或删除。基于重要性的筛选在生成记忆摘要或提取事实时由LLM或规则对信息的重要性进行打分。例如“用户的结婚纪念日”重要性为9“用户今天喝了咖啡”重要性为1。低重要性记忆可以设置更短的保存时间或更快的衰减速度。记忆合并与去重当关于同一主题的记忆过多时例如用户多次提到喜欢猫系统可以定期触发记忆合并将多条相似记忆合并成一条更全面、更简洁的记忆避免冗余。用户可控的遗忘提供接口让用户主动删除或修正记忆。例如“忘记我刚才说的电话号码”或“我其实对花生不过敏了请更新”。5.2 多模态记忆与情感理解未来的个人助理不应只理解文字。多模态记忆存储用户可能分享图片、文档、语音消息。系统需要能提取这些多媒体内容中的信息通过图像识别、语音转文字、文档解析并将其转换为可存储和检索的文本摘要或特征向量与文本记忆关联存储。例如用户发了一张晚餐照片系统可以识别出食物并存储“用户似乎常吃意大利面”这样的记忆。情感与风格记忆分析用户历史对话的情感倾向积极、消极、中性和语言风格正式、随意、幽默。在回复时可以调整语气与之匹配。例如发现用户最近几次对话都很简短消极AI的回复可以更简洁并表达关心。5.3 分布式记忆与隐私安全记忆是高度敏感的个人数据。本地优先架构真正的个人智能体应该支持完全本地运行。所有记忆数据存储在用户自己的设备上模型使用本地或可信任的私有化模型如通过Ollama部署的Llama 3。Hermes Agent的开源特性为此提供了可能。联邦学习与加密记忆在需要云端协同的场景下可以采用联邦学习思路让模型在本地学习用户偏好只上传加密的、脱敏的模型参数更新。或者将记忆内容在本地加密后再上传到云端存储密钥仅用户持有。记忆访问控制定义不同级别的记忆隐私。有些记忆如工作项目细节可以被共享给“工作助理”角色有些记忆如健康数据则严格保密。系统需要实现基于角色的记忆访问控制。5.4 与工具和行动的集成一个能记住你的智能体最终要能替你做事。记忆驱动的自动化将记忆与自动化工具如Zapier, n8n或直接API调用结合。例如记忆“用户每周末上午9点健身”可以自动在每周五晚上提醒准备健身装备甚至自动预约周日的健身房。预测与主动服务基于长期记忆中的模式进行预测并主动提供服务。例如通过分析用户过去三个月的出行记录在类似时间点主动推送“是否需要预订机票/酒店”的提醒。或者发现用户每次学习新编程语言都会搜索某个教程网站可以在用户提到学习新语言时主动推荐该网站。跨应用记忆同步理想状态下用户在邮件中提到的会议时间、在日历中标记的生日、在笔记软件中写的项目计划都能被智能体安全地索引和关联形成统一的用户记忆图谱。这需要一套标准化的API和严格的用户授权协议。6. 常见问题与实战排坑指南在实际开发和调试Hermes Agent类项目时你会遇到一些典型问题。以下是我踩过坑后总结的经验。6.1 记忆检索不准确或召回无关信息这是最常见的问题。你的AI突然开始胡言乱语可能是因为注入了错误的记忆。问题根源嵌入模型不匹配用于生成存储记忆的嵌入模型与用于生成查询向量的模型不一致导致向量空间不匹配。元数据过滤缺失或错误没有正确过滤user_id导致检索到其他用户的记忆。记忆分块过大存储的“记忆”文本太长如整篇对话包含太多无关信息导致检索精度下降。缺少重排序向量检索返回的Top-K结果中可能混入几个语义相关但实际无关的片段直接全部注入会干扰LLM。解决方案统一嵌入模型确保存储和查询使用同一个嵌入模型。强化元数据为每条记忆添加丰富的元数据如user_id,session_id,topic,timestamp,importance_score。检索时严格用user_id过滤并可按topic和timestamp进一步筛选。优化记忆分块不要存储原始长文本。对于长对话先进行摘要存储摘要。对于长文档可以按语义或固定长度进行智能分块每个块单独存储和索引。引入重排序层在向量检索后用一个更精细的交叉编码器模型如BGE-Reranker对候选记忆进行重新打分只选择分数最高的1-2条注入上下文。这能显著提升精度。设置相似度阈值仅当记忆与查询的向量相似度超过某个阈值如0.7时才认为相关并注入。低于阈值的即使排在前面也舍弃。6.2 上下文窗口爆炸与Token消耗失控记忆太多导致提示词过长超出模型上下文窗口或造成不必要的API费用激增。问题根源无节制地将所有相关记忆的原始文本都塞进提示词。解决方案记忆摘要化这是最重要的手段。长期记忆应以摘要形式存在而非原始文本。动态上下文窗口管理实现一个“上下文管理器”它负责维护一个固定长度的“工作上下文”。每次新的用户输入到来时它决定哪些长期记忆需要被召回、哪些旧的工作记忆需要被压缩或丢弃。可以使用LLM来生成当前对话的简短摘要用以替换掉冗长的原始历史。分层注入不是所有记忆都平等。将检索到的记忆按相关性排序后可以尝试只注入最相关的一条完整记忆对于其他相关记忆仅注入其“关键词”或“极简摘要”并告诉LLM“还有其他相关记忆关于[X, Y]如需细节可告知。”使用支持长上下文的模型如果成本允许直接使用Claude-3-200k或GPT-4-128k这类超长上下文模型可以缓解压力但非根本解决之道。6.3 记忆冲突与信息不一致用户可能提供前后矛盾的信息如先说喜欢狗后说对狗毛过敏或者记忆本身存在错误。问题根源记忆系统被动存储所有信息缺乏冲突检测和消解机制。解决方案事实性记忆的版本管理与置信度对于事实性记忆如“用户过敏源”存储时附带置信度来源如“用户明确陈述”、“系统推断”、时间戳和版本号。当新信息存入时检查是否存在冲突。如果新信息的置信度更高如用户更近期的明确声明则覆盖旧信息或将旧信息标记为过时。让LLM参与冲突判断在存储新记忆前可以将与之可能冲突的旧记忆一起发给LLM询问“新信息[用户现在对猫过敏]与旧信息[用户养猫]是否冲突如果冲突应如何更新记忆”。根据LLM的判断来决定存储策略。提供用户修正接口当AI基于可能矛盾的记忆做出回应时可以附带询问“我记得你之前提到X现在你说Y需要我更新记忆吗”将最终裁决权交给用户。6.4 启动冷启动与早期表现新用户刚开始使用时记忆库是空的AI无法展现“个性化”的优势体验可能不如传统无记忆的ChatGPT。问题根源记忆系统需要数据积累。解决方案设计引导性对话在初次交互时主动引导用户提供一些基础信息。例如“为了更好为你服务可以告诉我你的名字以及你希望我主要在哪方面帮助你吗例如编程、写作、日程管理”。利用显式记忆指令鼓励用户使用“记住……”“以后请……”这样的句式系统检测到这类句式时会主动将其提取为高优先级事实记忆。设置默认人格或领域记忆即使没有用户个人记忆也可以预装一些通用的“角色设定”或“领域知识”作为初始记忆让AI在特定领域如“技术顾问”、“创意写手”下表现更好。快速学习设计在早期对话中提高记忆提取和存储的敏感度尽可能多地从有限对话中提取有效记忆快速构建初始用户画像。开发一个真正能“记住”你的AI智能体是一条充满挑战但回报巨大的道路。Hermes Agent项目为我们提供了一个优秀的开源起点和设计范本。从简单的向量存储到复杂的记忆图谱从被动的问答到主动的预测服务其演进空间非常广阔。最关键的是它让我们看到了AI从“通用工具”向“个人伙伴”演进的一种切实可行的技术路径。在实际动手时我建议从一个非常具体的垂直场景开始比如“健身饮食记录助手”或“个人读书笔记分析员”聚焦解决该场景下的记忆痛点迭代开发你会对记忆系统的价值有更深刻的理解。
