我尝试用真实内存构建 Alexa——三个月失败后的收获

Source: Dev.to

关于 LangGraph、记忆架构的故事，以及我为何不再与 LLM 斗争，而是让系统变得可预测

它始于一次简单的挫折

我想构建一个类似 Alexa ——但更智能的东西。不是那种会在会话结束瞬间就把你忘掉的语音助手。也不是把你完整的对话历史存到文本文件里，然后称之为 “记忆” 的 AI。

我想要一个真正了解你的个人 AI——你的习惯、偏好、任务——并且像真实助理一样随时间变得更聪明。

听起来很简单，实际上并非如此。

第一步：Alexa 是怎么工作的？

在动手构建之前，我深入研究了 Alexa 的云架构。模型非常简洁：

1. 你的语音查询发送到云端。
2. 云端处理后调用大型语言模型（LLM），响应流回设备。

设备本身非常轻量——所有智能都驻留在服务器上。

问题： 内存到底存放在哪里？更重要的是——个人 AI 的内存到底是什么？

Step 2: 个人 AI 实际应该记住什么？

大多数 AI 项目都会跳过这个问题。他们把所有东西——每条信息、每个会话——都存下来，然后称之为记忆。那不过是日志文件，根本不是记忆。

我花时间思考什么才是真正对个人 AI 有意义的。经过大量思考，我归纳出四大类：

• 身份 – 你的身份、姓名、角色、基本信息
• 习惯 – 你经常做的事情、日常例行
• 偏好 – 你喜欢的做事方式、你享受的事物
• 事件与任务 – 日历事项、待办事项

其他一切都是噪音。你对 AI 说的大多数内容都不需要被存储。这个洞见成为整个项目中最关键的设计决策。

Step 3: Where to Store It — SQL vs. Vector DB

My first instinct was a SQL database: clean tables, structured data, easy to query.
但我很快遇到一个问题：不能直接用自然语言查询 SQL 数据库。你必须知道确切的键和列名。当用户说“提醒我你记得的我的健身计划是什么”时，这种方式行不通。

For natural‑language retrieval you need vector search — embed the query and the stored memories as vectors and find semantic matches.
要实现自然语言检索，需要使用 向量搜索——将查询和存储的记忆嵌入为向量，并寻找语义匹配。

The hybrid solution

Real data lives in SQL; context and meaning live in the vector store. Both work together.
真实数据存放在 SQL 中；上下文和含义存放在向量库中。两者协同工作。

Step 4: 第一次方法 — 让 LLM 拥有全部

在解决了存储问题后，我构建了版本 1：让 LLM 访问两个数据库作为工具，并让它自行决定何时读取和写入。

理论上 它很简洁。 实际操作中 则是一场灾难。

LLM 会产生幻觉。模型会自信地把记忆写入错误的类别，检索到无关的条目，或者——更糟糕的是——编造根本不存在的记忆。当你的系统的全部职责是提供可靠的记忆层时，幻觉是致命的。

我需要系统是 可预测的。即使它出现错误，我也需要知道它会在 哪里 出错。

第5步：真实架构——节点，而非魔法

Instead of one LLM doing everything, I broke the pipeline into dedicated nodes, each with a single responsibility:

User Input
   ↓
[Segmentation Node]
   – splits input into: memory_to_write | memory_to_fetch | ignore
   ↓
[Classification Node]
   – labels each piece: identity | habit | preference | event | task
   ↓
[Router Node]
   ├──→ [Memory Writer] → Pinecone + Postgres (parallel)
   └──→ [Memory Reader] → Fetch relevant context (parallel)
   ↓
[Final Answer Node]
   – aggregates context → single LLM call → response

使其成功的两个关键决策

1. Read and write in parallel – Running them sequentially killed latency. Parallelizing both brought response times down dramatically.
   并行读写 – 顺序执行会导致延迟飙升。并行化两者后，响应时间显著下降。

2. Use LLMs only where you have to – Every node that could be implemented with regex or deterministic logic was. LLMs are expensive in tokens and unpredictable. The only mandatory LLM call is the final answer generation.
   仅在必要时使用 LLM – 所有可以用正则或确定性逻辑实现的节点都采用了这些方式。LLM 在 token 费用上昂贵且不可预测。唯一必须的 LLM 调用是最终答案的生成。

Result: A system that’s predictable end‑to‑end. If something goes wrong, I know which node failed and why — infinitely better than a black box that hallucinates.
结果： 一个端到端可预测的系统。如果出现问题，我能明确是哪一个节点出错以及原因——这远比一个会产生幻觉的黑箱要好得多。

第6步：硬件梦想暂时破灭

I originally wanted Orion to be a hardware device — a tabletop robot, always listening, always learning. That vision is still there, but 2–3 months in I made a decision: get the software layer right first.

我最初希望 Orion 成为一款硬件设备——一台桌面机器人，始终在聆听，始终在学习。这个愿景仍然存在，但在项目进行 2–3 个月后，我做出了决定：先把软件层做好。

Hardware is a multiplier. If the memory architecture is broken, a physical device just amplifies the problem. If the memory architecture is solid, hardware becomes a packaging issue — not a fundamental one.

硬件是一个乘数。如果记忆架构出现问题，实体设备只会放大这个问题。如果记忆架构稳固，硬件就只是一种包装问题——而非根本性问题。

So Orion is now a software‑first memory layer. The hardware will come later, if at all. The memory problem was always the interesting part anyway.

因此，Orion 现在是一个 软件优先的记忆层。硬件可能以后再来，甚至可能根本不出现。无论如何，记忆问题一直是最有趣的部分。

技术栈概览

• LangGraph – 编排框架；管理节点图和状态
• Groq – 用于最终答案节点的高速 LLM 推理
• Pinecone – 用于语义记忆检索的向量存储
• Postgres – 用于结构化记忆（身份、任务、事件）的关系型数据库

(在此添加您使用的其他组件。)

# Orion – Agentic Memory Stack (Overview)

- **PostgreSQL (Supabase)** – Structured memory storage  
- **Redis** – Caching and fast in‑session state  
- **Jina** – Embeddings for vectorizing memory content  
- **LangSmith** – Tracing and debugging the graph (genuinely essential)  
- **FastAPI** – Serves the whole thing as a REST API  

3 个月前我会对自己说

• 问题 “存什么？” 比 “怎么存？” 更重要
  大多数人在回答设计问题之前就直接跳到技术实现。先把设计做好。
• 延迟是内存系统中的真实问题。
  并行检索 以及 写入不是可选的——它是必需的。
• 改变范围 不是 失败。
  放弃硬件、专注软件层面并不是放弃，而是聚焦。

接下来

• Orion 仍在开发中。
• 内存层已可工作。
• 接下来的步骤：
  1. 使检索更智能——更好的上下文注入。
  2. 为旧的/不相关的条目实现记忆衰减。
  3. 发布一个干净的 SDK，供其他开发者在自己的 AI 项目中直接使用。

如果你正在使用 LangGraph 或 agentic memory 构建某些东西，我真的很想交流。
GitHub 仓库是公开的：

大三（预毕业）计算机科学与工程学生。正在构建可能还不该工作的东西。