块化重构(memory-restructure-plan)换了底层数据结构,但 L1↔L2 的流动没跟着改,
导致这条链出现结构性失效。本次按设计原文修复。
## 断点(生产实测)
**① L2 只存渲染视图,事件本体丢失**
ContextToDoc 把每条事件拍平成一行:truncate(Response,100)、truncate(工具输出,200)。
生产库 1000 篇归档文档实测:
- response 段恰好 103 字符(=100+"..."):311/2094 = 15.1%
- 工具输出段恰好 203 字符:7593/13261
- ToolsUsed 完全不存
⇒ 原文在落库那一刻就不存在了,召回再全也拿不回来。
**② L2 里没有文本块,与 L1 不同构**
L2 块分布 image 437 / audio 7 / text 0 —— 文本全靠 Content 这个视图。
**③ 召回造合成事件,时间戳用归档时刻**
doc_query 用 d.CreatedAt 造一条 cold_storage 事件、正文取 Content 再截 2000 字、
且完全不回填 Blocks。块自带 created_at(捕获时刻),实测与 doc.created_at
差近两小时,却没人用。
**④ 块在 Consume 时两层同时消失**
Consume 从内存与磁盘同时删除文档,而块的字节只存在于那个 .json 里。
生产 L2 有 444 个块,其中 396 个不在 L3(约 248MB)—— 一旦被命中即永久丢失。
## 修法(按设计,不是按我的推断)
设计前提(写进 ARCHITECTURE 与计划文档):
· 记忆块是唯一物理载体,层是持有关系
· L1 与 L2 结构同构,唯一区别是「是否直接投喂给模型」
· 正文(含多媒体正文)内联在块里;事件只是块的容器
· 任何一层都不压缩(视图不是记忆)
· 内核不得硬编码任何插件行为
1. Doc 增加 Events []DocEvent(与 ContextEvent 同构),成为文档主体
2. 正文各自成块:Input 一块、Response 一块(BlockText,Text 即正文)
3. restoreDocEvents 逐条按原始时间戳迁回 L1,块随事件迁回
4. Content 保留为渲染视图(contentFromEvents 生成),不再是原文载体
5. 蒸馏 docToTriples 改用 documentOriginalText:从块读原文,不再用视图
6. 删掉 ARCHITECTURE 里「过滤 agentcli/terminal 来源」——那是内核硬编码
插件名,改由插件经 NoMemory/Cleaner 声明
## 顺带修掉的真实缺陷
simpleHash 是 O(n²) 且哈希串长度正比于内容:
for _, c := range s { h += fmt.Sprintf("%x", c) }
压力测试实测 1.25MB 正文归档耗时 **270 秒**;生产实测 content_hash
是 content 的 2.2 倍(52072 字 → 114491 字)。
换成 sha256 前 16 字节:**270s → 0.52s(520 倍)**,定长 32 hex。
## 存量
按拍板不迁移,等系统自然冲刷。降级路径:无 Events 的旧文档仍按旧行为召回
(整篇渲成一条事件),不伪造成「有原始事件」。生产副本实测 1104 篇旧文档
全部正常加载。
## 判据(16 条,全部有变异自证)
document/blockflow_test.go(11 条):正文完整性、文本块粒度、逐条保留、
视图定位、幂等、存量兼容、原文可用性、hash 线性、3 条压力
core/recalldoc_test.go(5 条):逐条回填、原始时间戳、块迁回、
回填不截断、存量降级、批量压力
变异全部被抓:
· 落库 truncate(100) → ArchivePreservesFullText(实测 len=303/原 10215)
· Input/Response 合成一块 → InputAndResponseAreSeparateTextBlocks(实际 1)
· 召回用 d.CreatedAt → RestoresEachEventAtOriginalTimestamp(回填 1/期望 3)
· 召回不回填 Blocks → MigratesBlocksBackToContext
· 召回再截 2000 字 → TextIsNotTruncatedOnTheWayBack(2003/原 18020)
· 恢复 O(n²) hash → HashIsLinearAndFixedLength(超时 >300s)
## 验证
- go build ./... 通过
- go test ./... -count=1:58 包 0 失败
- go test -race ./internal/memory/document/ ./internal/agent/core/:通过
- 生产数据副本实际启动:1104 篇文档加载正常、0 崩溃、干净退出
- 副本 e2e:新归档 2 事件 / 4 文本块、正文 3207 字完整回读、时间戳精确
## 不改
- 公开 SDK 契约(TextEvent / DocMemoryAPI / InsertWithMedia 已等价)
- 存量文档(等自然冲刷)
- 渲染层截断常数(独立议题,避免与本次修复互相掩盖)
8.3 KiB
English | 中文
HologramAgent — 项目概览
这是什么
HologramAgent 是一个持续运行的个人智能 Agent 框架。
核心架构:一个长时间运行的内核进程(homed),通过插件系统接入各种 IO 通道(QQ、Web、命令行等)。内核负责 LLM 调用编排、记忆管理、知识检索;插件负责所有外部 IO——收发消息、执行文件操作、搜索网络等。
设计要点
核心域与应用域分离 — 内核(核心域)不执行任何 IO 操作,所有 IO 能力归属插件(应用域)。边界通过 PluginSDK 明确定义:
- 插件向内核注册工具(Tool),供 LLM 调用
- 插件挂入处理管道(Stage),在各阶段拦截/改写消息流
- 插件订阅/发布事件(Event),松耦合通信
- 插件通过 IO API 排队或打断投递输入
这一划分的意义在于职责边界清晰:内核专注于编排与记忆管理,插件负责具体 IO 实现,二者互不耦合。
业务语义留在插件层 — 内核不定义业务对象:终端、命令历史、设备状态、媒体库
都属于插件域。以终端为例,PTY、会话生命周期与输出缓冲全归 agentcli;WebUI 与
CLI 需要终端面板时,订阅事件总线(EventTerminalOutput + EventToolCall)
自己攒视图,而不是去读内核里的某个状态组件。内核只提供事件总线与插件注册面——
新增一类能力不需要改内核,也不会在核心里堆出第二套业务真相。
三层记忆架构 — 三层不是三种数据结构,而是同一批记忆块的三层持有关系:
- Context 层(L1,直接投喂):内存中预训练词嵌入评分的事件窗口(StaticEmbedder 词向量 → CosineSimilarity,TF-IDF 回退),实时维护最近上下文,低相关性事件自动下沉到下一层
- Document 层(L2,不直接投喂):与 L1 结构同构——同样的事件 + 同样的块,只是不直接进模型视野;支持显式提交和隐式归档,冷数据蒸馏到 Graph
- Graph 层(L3,持久):SQLite 图数据库,顶层仍是三元组(节点 + 关系边),但节点从
entities表升级为memory_blocks;BFS 遍历召回,蒸馏管道从对话中提取三元组
★ L1 与 L2 唯一区别是「是否被直接投喂给模型」:L2 不是 L1 的摘要层,也不是 另一种数据形态。召回 = 把事件(连同它持有的块)从“不投喂”的持有层迁回“投喂”的持有层。
★ 正文(含多媒体正文)内联在块里:文本块的 Text 是正文,媒体块的 Data 是字节。
不存在「块 + 外部正文」的分离形态。任何一层都不压缩 —— 视图(检索摘要、渲染结果)
可以是压缩的,但视图不是记忆。
三层流动:上下文 → 冷归档 → 长期图记忆,构成从短期到持久的信息衰减与整合管道; 每一次都是迁移(块 ID 与向量不变,只换持有层),不是复制。
媒体记忆(v1.2.0 起:一等记忆块) — 图片/音频不是附属物,而是记忆的一等节点:
- 内容寻址存储(CAS):digest 寻址,元数据在 SQLite、blob 在磁盘(两级分桶),相同字节只存一份,
每次
Get重校 digest(磁盘损坏静默返回脏数据比报错更危险) - 媒体块直接参与向量检索:块携带自己的多模态向量与指纹,正文里不再有任何媒体标记
- 无独立 GC、无引用计数、无 keep-set:记忆块遵循单层不变量——Context → Document → Graph 是块的迁移,不是复制、也不靠引用保活;删除块即删内容
- v1.1.1 起贯通插件边界:插件可通过
InsertWithMedia/InjectInputMedia读写媒体, 模型可用memory_commit/doc_commit的media_digests参数关联媒体 - 旧机制已整体拆除:此前把视觉模型生成的描述写进正文、以
[<mime> <短digest>] <描述>标记 参与检索的描述式索引,以及media_refs引用计数,均已在 v1.2.0 删除——描述是模型生成的 二手信息,检索「别人转述的图片」不如检索图片自己的向量
它实际做了什么
代码位于项目仓库根目录,Go 语言实现。
内核 (internal/agent/core/):
eventloop.go— 消息循环(eventLoop),从 IO 层排队接收输入process.go/stages.go— 处理管道:记忆召回 → 人格注入 → LLM 调用 → 工具执行 → 输出发送,7 阶段钩子toolcall.go— 工具调度与执行context.go— 上下文管理(预训练词嵌入评分 StaticEmbedder → CosineSimilarity,TF-IDF 回退),自动剪枝低相关性事件- LLM 调用通过 Provider 接口抽象,多源自动降级
记忆系统 (internal/memory/):
- GraphDB (
graph.go) — SQLite,entities + relations 表,BFS 遍历 - Document Store (
document/document.go) — 临时记忆,JSON 文件 + TF-IDF 向量索引,消费即删 - Text Memory (
text/text.go) — 原始对话日志,JSONL 文件轮转 - Social Store (
social/social.go) — 人格特质 + 关系网,包装 GraphDB - Memory Indexer (
indexer.go) — 自动将 GraphDB 实体向量化,用户输入时召回注入 system prompt
知识库 (internal/knowledge/knowledge.go):
- 文件系统目录
knowledge/<name>/content.md - TF-IDF 向量搜索,独立于记忆系统的索引实例
- LLM 通过
knowledge_search/knowledge_create/knowledge_list三个工具操作
插件系统 (internal/plugin/):
- 内置插件:Go
init()自注册,编译进内核 - 外部插件(v1.0.0 起):编译为普通 Go 二进制
plugin.bin,内核 spawn 为独立子进程, 经 stdio JSON-RPC(控制面)+ 共享内存段(数据面)+ 事件环(通知面)通信;也支持 Lua 脚本插件 (C ABI 动态库通道-buildmode=c-shared已在 v1.0.0 整体删除) - PluginSDK (
internal/sdk/) 定义四通道:RegisterTool / RegisterStage / Subscribe / RegisterOutputChannel - 阶段钩子 7 个:on_input → pre_action → post_action → before_toolcall → after_toolcall → before_output → after_output
LLM Provider (internal/agent/api/provider.go):
- Provider 接口:Name / Chat / ChatStream / MaxContextTokens
- 唯一实现
LuaAdaptedProvider:所有源都经 Lua 适配脚本做请求/响应变换; 适配器脚本位于internal/lua/adapters/,每类协议一个.lua脚本 - 内置 10 个适配器:deepseek / openai / anthropic / gemini / mistral / groq / github / kimicode / ollama / server
- 源(
core.llm.sources.<name>.*)由部署时配置,数量不固定,不随内置适配器数绑定
WebUI (internal/plugins/webui/):
- 嵌入式 SPA 仪表盘(
dashboard.html通过//go:embed打包) - REST API:状态查询、配置管理、记忆操作、知识库管理、插件管理
- 兼容 OpenAI API 格式的
/v1/chat/completions端点 - SSE 事件流
/api/v1/chat/events
ClawHub 适配器 (internal/plugins/clawhubadapter/):
- 统一加载 OC 插件(Node.js)、Python sidecar、JS sidecar、SKILL 四种插件类型
- RegistryDispatcher 模式:Tool/Provider/Channel/Stage 注册通知分发
- ClawHub 市场搜索与安装:
clawhubadapter_search/clawhubadapter_npm_install - 9 种 Provider 类型映射为 LLM 可用工具(图片生成、搜索、语音等)
- OC 通道自动注册为 IO 设备,支持文本/文件/图片/音频能力标志
项目状态
核心功能已可运行。插件系统和 SDK 已就绪,可独立开发外部插件。
- 内置插件(13 个):webui / cli / agentcli / cfgmgr / healthcheck / kbtree / multimodal / pluginmgr / clawhubadapter / remotedevice / skillmgr / seemedia / seq
- 判定标准:只有必须使用内部 SDK 能力(公开 SDK 没有的接口面)的插件才内置,其余一律外置为 .hmap 插件(详见 ARCHITECTURE「内置插件的判定标准」)
- 外部插件示例(hologramagentsdk 仓库
example/,含 Go 和 Lua 两种类型):qq / files / a2a / ai_image / bili / browser / calendar / editdoc / memo / music / ocr / rss / sanitizer / weather / luademo - 打包分发:
.hmap插件包格式,通过 WebUI 安装