Thalamus：给LLM打造认知外骨骼

1. 生物学的起源：为何 "LLM Cortex" 会崩溃

在人脑中，丘脑并非一个简单的被动线缆通道。它是心灵的中央中继站、感觉过滤器以及门控机制。它在信息到达大脑皮层之前对其进行处理、优先级排序和路由。如果没有这个主动过滤器，皮层就会被无尽的环境噪声淹没，导致即时的认知崩溃。

当前 AI 开发集成（如 VS Code Copilot 或 OpenWebUI）恰恰存在同样的问题。每次 IDE 与模型交互时，都会发送一团混乱的非结构化上下文：专有的 system prompts、庞大的目录树、静态的 skill 声明，以及完整未过滤的对话历史。

我们发现自己给 "LLM cortex" 喂了 150+KB 的 "Token Soup" 来回答诸如"这个函数在哪里定义的"这类琐碎问题。这种粗犷方式导致：

• 巨大的计算浪费：本地推理引擎（Ollama、Llama.cpp）上的预填充时间堪比《圣经》，VRAM 和芯片带宽被饱和（在统一内存硬件上本地工作时的一个关键问题）。
• 上下文漂移与熵增：模型由于前几轮积累的矛盾指令而失去焦点（"迷失在中间"）。
• 幂等性丧失：重复或失败的请求会不保留干净状态地重新发送相同的海量 token。

2. 范式转移："上下文窗口即 RAM，而非存储"

LLM 应用构建者犯了一个根本性错误：将上下文窗口当作硬盘来对待。

近期研究（2026 年由 Mem0 等项目形式化）表明，上下文窗口的行为与系统 RAM 完全一样：它是易失性的、计算成本极高的，且其性能随着输入 token 数量的增加而指数级下降。

此外，最新的科学文献（《意义的代价：为何每个语义记忆系统都会遗忘》）已经从数学上证明了纯粹基于语义搜索的系统（经典向量 RAG）存在内在局限性：仅基于几何意义来组织信息不可避免地会在负载下产生干扰、错误回忆和遗忘。向量搜索对于软件开发是不够的，因为那里需要的是精确制导。

因此，Thalamus 引入了一种混合的、确定性的记忆架构：

状态黑板（Postgres JSONB）：一个持久化的集中注册表，追踪活跃的"依赖契约"（真实的数据库 schema、API 契约、当前任务和现有组件）。LLM 不需要通过重读历史来推断项目状态；它收到的是一个确定性的快照。

情景记忆（Qdrant Vector DB）：仅用于通过主题路由检索相关的历史片段（例如，在做后端工作时隔离标记为 #database 的向量，防止 CSS 噪声污染 SQL 逻辑）。

3. 中间件的演进："白板"模式

在第一个概念实现中，Thalamus 通过 n8n 编排器被动运行，拦截 payload 并使用复杂的 Regex 来"清洗"客户端的 XML 标签。这种方法被证明是脆弱和不完整的：它迫使我们不断追逐各提供商不断变化的样板。

我们随后通过切换到 Tabula Rasa（主动重建）模式来优化架构。

Thalamus 现在作为独立的认知中间件用 FastAPI 编写，位于标准化网关（LiteLLM）之后。当客户端发送请求时：

Tabula Rasa：Thalamus 拦截调用并丢弃客户端的专有 system prompt，以避免 "token soup"。

可选的（非强制的）去脂器：微服务包含一个灵活的去脂器模块，用于清理客户端标签并提取有用信息（例如选中的代码或文件引用）。然而，这不是阻塞性约束：如果去脂器失败或客户端格式改变，流水线不会停止。

元数据提取：隔离 message_id（以确保 Postgres 上的幂等性）和 session_id。

主动重建：通过组合黑板快照、Postgres 聊天日志的滑动窗口以及用户最后的原始消息，从头构建一个密集且结构化的 prompt。

在深入架构之前，先简要反思一下我是如何产生这个想法的（仅有意大利语版本）。

👉 随机鹦鹉：超越隐喻，迈向"外星"智能

4. 流水线操作流程 v2

Thalamus 中每次交互的生命周期分为两个异步钩子：

Pre-Hook（上下文摘要）

• 幂等性检查：检查 message_id 是否已存在于 Postgres 中。如果是，立即返回缓存的响应。
• 状态和向量融合：提取活跃的 state_blackboard 并查询 Qdrant，按当前 topic_tag 过滤。
• Prompt 组装：通过使用 XML <thalamus_update> 标签插入结构化更新规则来生成最终 prompt。

Post-Hook（学习与写入状态）

• 契约解析：在 LLM 输出到达客户端之前拦截它，寻找 <thalamus_update> 块。
• 黑板补丁：在 Postgres 上执行原子更新（JSONB patch）以记录新的架构变更（例如新创建的文件或修改的 schema）。
• 情景日志：保存去脂后的聊天回合（仅用户/助手）到 Postgres，供未来调用使用。

Thalamus 是一个实验性开源项目，目前仍在开发中。

我想非常清晰和透明地说明，以避免产生错误的预期：目前，基础设施栈（Postgres + Qdrant + LiteLLM + FastAPI Core）已在 Docker 中准备就绪且可执行，但只有组件之间的逻辑和通信流被测试过。我们已经验证了拦截基础设施、持久化和 payload 传递，但尚未看到一个可在日常生产使用中运行的交钥匙助手。Agent 的深层逻辑和黑板上状态变更的稳定性正在积极开发中。

我们正处于项目最令人兴奋的阶段：理论与实践碰撞的阶段，有很多"开放的道路"可以探索。我们正在寻找开发者、软件架构师和本地 AI 爱好者来合作解决这些开放挑战：

• Gravity RAG 算法：在对话日志中实现 gravity_score 的逻辑时间衰减公式，从数学上决定一条消息何时应该"淡出"以避免情景记忆饱和。
• 黑板冲突管理：当 LLM 提议的变更与活跃契约或数据库 schema 矛盾时，设计解决方案算法。
• Prompt 多模型数据库调优：优化存储在 Postgres system_config 中的系统 prompt 模板（热存储），以将不同行为映射到不同模型（例如 DeepSeek-R1 与本地 Llama-3）。

如果你想亲手接触一个挑战上下文管理极限的架构。

停止发送 "token soup"。开始基于主动 Prompt 重建来编排高密度认知流。

⚠️ 项目状态：开发中（流程已验证的概念）

Thalamus 目前是一个高度实验性的开源概念。编排基础设施（FastAPI、Postgres、Qdrant 和 LiteLLM）已通过 Docker 完全脚手架化并容器化，但目前仅验证了逻辑通信流。它还不是一个即插即用的生产助手。我们正在积极开发核心的 Agent 推理循环和状态黑板补丁同步。

🚀 问题所在：上下文溢出与"迷失在中间"

当前 LLM-IDE 集成（VS Code Copilot、Continue、OpenWebUI）存在一个结构性缺陷：它们将 LLM 的上下文窗口当作硬盘而非 RAM 来对待。每一次查询都会发送高达 150KB+ 的非格式化 "Token Soup"（冗余的 system prompts、静态工具定义、完整非结构化的聊天历史，以及庞大的目录树）。

这种方法导致：

💬 在下方留下评论发表你的想法，或在仓库中开一个 issue 开始讨论设计！

---