企业官网建设流程全解析

Agent Memory Techniques 是一个包含 30 个可运行 Jupyter Notebook 的开源项目，系统梳理了 LLM Agent 的各大记忆技术。本文以其中的Knowledge Graph Memory（知识图谱记忆）为例，用尽量少的代码讲清楚：如何用"三元组"把对话变成一张关系网，让 Agent 具备多跳推理能力——不再只是记住孤立的事实，而是理解"谁和谁是什么关系"。

为什么 Agent 需要知识图谱记忆？

想象一张公司组织架构图：它不孤立地存"Bob 是工程师"，而是记录"Carlos 管理 Bob""Bob 参与 Project X""Project X 依赖 Q3 预算"。沿着这些连线走几步，你就能回答"谁管理着 Alice 的整个团队？"这类单条事实答不上来的问题。

这正是 07 Entity Memory 与 Knowledge Graph Memory 的本质区别：

知识图谱的核心结构很简单：

• 节点（Node）：实体，如人、项目、地点
• 边（Edge）：带类型的关系，如manages、depends_on、works_at
• 三元组（Triple）：每条关系记为(主语, 谓语, 宾语)

(Alice) --[manages]--> (Bob) (Wavelength) --[depends_on]--> (MusicGraph) (Priya) --[works_at]--> (Spotify)

Knowledge Graph Memory 的完整流程

官方实现 README 中，整个系统由三个组件协作完成，对应 knowledge_graph_memory.ipynb 里的三个类：

1. TripleStore：基于 NetworkX 有向图的存储。负责添加三元组、查询实体邻域、寻找两实体间最短路径、序列化为 JSON。
2. TripleExtractor：用 LLM 的 function calling（Claude tool-use）把自由文本解析成结构化的(subject, predicate, object)三元组。
3. KnowledgeGraphMemory：总控。构建提示词时先找出消息中提到的实体，取出它们的 1~2 跳邻域子图，作为上下文注入 prompt，回复后再抽取新三元组回写图。

流程一句话概括：每轮对话 → 抽取三元组 → 更新图；提问时 → 定位实体 → 取邻域子图 → 注入 prompt → 生成关系感知的回答。

核心技巧：三元组抽取

三元组抽取是整个技术的地基。实现方式是把"抽取关系"定义为一个 LLM 工具（tool schema），要求模型为每条关系输出三个字段：

• subject：源实体（要求简洁一致，如Alice而不是"我的朋友 Alice"）
• predicate：关系类型，统一用 snake_case，如works_at、manages
• object：目标实体

这种 LLM 抽取比规则方法灵活得多，但噪声也是最大的坑：模型可能输出不一致的谓词（manages与is_manager_of）或实体别名（Professor Chen与Prof. Chen），生产环境需要实体归一化（entity resolution）来兜底。

子图检索：别把整张图塞进 Prompt

图会越长越大，全量序列化塞进 prompt 既浪费 token 又稀释注意力。Knowledge Graph Memory 采用子图检索（Subgraph retrieval）：

1. 扫描当前用户消息，命中图中已知实体名（如"我的经理"→ Carlos）
2. 取出这些实体1~2 跳的邻域三元组
3. 格式化成可读文本（如Carlos --[manages]--> Aisha）注入 system prompt
4. 配合最近 10 条消息的滑动窗口一起送给 LLM

这样 prompt 里只有"问题真正触达的那一小片关系网"，成本可控、信噪比高。

多跳推理：图谱记忆真正 shines 的地方

多跳推理（multi-hop reasoning）是图谱记忆相对其他技术的杀手锏——它需要沿多条边串联分散在不同轮次的事实：

• "我参与的项目依赖哪个数据集？" →Priya → works_on → Wavelength → depends_on → MusicGraph
• "除了我，我的经理还管谁？" →Priya ← managed_by ← Carlos → manages → Aisha
• "Alex 和 Spotify 之间有什么联系？" → 需要找到跨实体族的最短路径

notebook 里还内置了一个对照实验：30 轮对话中埋入 10 条关系事实（穿插闲聊填充），最后用 10 个回忆问题（含多跳问题）考核 Knowledge Graph Memory 与"只保留最近 10 条消息"的滑动窗口。结果符合预期——滑窗会"忘掉"滚出窗口的关系事实，而图谱记忆把三元组固化下来，在关系密集型回忆任务上显著占优。实验设计可参考 notebook 源码。

跨会话持久化：关系知识随会话存活

TripleStore提供save/load：把整张图序列化成 JSON 边列表落盘，新会话加载后立即拥有全部历史关系——用户无需重新解释自己的世界。这在项目管理助手、组织助理这类长期使用场景中价值巨大。

局限与踩坑清单

如何选：Knowledge Graph Memory 与相似技术对比

组合使用是常见打法：向量检索负责"模糊找"，图遍历负责"精确走"，这一混合模式正是 Graphiti 与 Zep 的生产实现（见 docs/topics.md 的完整主题索引）。

上手指南：跑通第一个 Knowledge Graph Memory

1. 克隆仓库后安装依赖（需要 Python 3.8+ 与ANTHROPIC_API_KEY）：

pip install -r requirements.txt

2. 在.env中配置ANTHROPIC_API_KEY
3. 打开 all_techniques/08_knowledge_graph_memory/knowledge_graph_memory.ipynb，依次运行：构建关系图 → 检查三元组 → 可视化图谱 → 多跳问答 → 跨会话持久化 → 对照实验
4. 想深入原理，读 README.md 的 FAQ（含与 Entity Memory 的取舍、失败模式分析）

总结

• Knowledge Graph Memory把对话转化为(主语, 谓语, 宾语)三元组有向图，节点是实体、边是关系
• 三元组抽取靠 LLM function calling 完成，灵活但有噪声，需要归一化兜底
• 子图检索只把问题触及的 1~2 跳邻域注入 prompt，兼顾效果与 token 成本
• 多跳推理是其核心竞争力：串联分散在不同轮次的事实，回答"关系之问"
• 生产级扩展请看 24 Graph Memory (Graphiti)：时间感知 + Neo4j + 混合检索

如果你的 Agent 需要理解"谁管谁、谁依赖谁"，知识图谱记忆就是那份从"记住事实"升级到"理解关系"的钥匙 🔑。