敞开的宫殿——你代理人的心灵宫殿
ECS为AI代理构建了认知记忆系统。
*意识，而不是记忆。*
中文文档
______________________________________________________________________
Open Palace是一个类似ECS（实体组件系统）的人工智能代理认知系统，作为本地MCP服务器交付。
它从一个前提开始： 代理是不可靠的指令追随者。告诉代理“始终在更改后提交”。它会忘记、跳过或格式错误。因此，必须发生的一切都是代码级管道（PostHook引擎），而不是系统提示符中的一行。
这不是内存插件。Open Palace管理着整个认知堆栈：
- 谁是代理人 *是* （实体注册表，具有双向SOUL同步和个性进化跟踪功能）
- 什么代理人 *知道* （具有三级索引和L2混合搜索的组件存储）
- 什么代理人 *决定及其原因* （双层变更日志，包括基本原理和被拒绝的替代方案）
- 谁是代理人 *与...互动* （带有交互标签和信任跟踪的关系记忆）
- 发生了什么 *自动地* （带库管理员、内存衰减、健康检查和可扩展管道的系统存储）
全部存储在本地 ~/.open-palace/，您拥有的一个自包含的git仓库。
问题
当前的代理框架通过上下文指令和markdown文件来管理认知。这以可预测的方式打破：
- 子代理以空白板条的形式生成。 一个衍生的“CMO”子代理对上一个“CMO“做了什么一无所知。具有相同角色的独立代理人？完全独立的实体，零共享状态。
- 跨会话内存不存在。 每一次新的会议都从头开始。如果没有结构化的日志、摘要或版本控制的存储，就没有传递决策和上下文的机制。上周决定了什么？代理人没有办法知道。
- 长上下文会降低准确性。 在会话中，随着上下文的增长，指令遵循的准确性会下降。压缩和修剪是按块丢弃的，而不是有选择地丢弃的，通常会在此过程中丢失决策上下文。
- 跨代理的冗余上下文。 在多智能体对话中，每个参与者都携带完整的上下文，而每个参与者只需要一小部分。选择性加载没有结构索引机制。
- 内存文件缺乏保护。 没有版本控制或结构约束，代理可以用相互矛盾的信息覆盖现有内存，无法回滚。
- 记忆只会积累，永远不会忘记。 如果没有主动遗忘，检索噪声会随着每个文件的增加而增加。经过几个月的使用，找到正确的信息变得更加困难，而不是更容易。
- 及时的指示是不可靠的。 上下文说明是建议性的。代理可能会忘记、跳过或错误格式化它们。关键操作需要代码级保证。
Open Palace通过确定性工程解决了这些问题：存储计算分离、代码级PostHooks、三级索引、基于温度的内存衰减、写验证和git支持的版本控制。
______________________________________________________________________
突出显示的功能
基于温度的记忆衰退。 记忆不是永恒的。Open Palace根据年龄、访问频率和参考人数对每个条目进行温度评分。冷数据会自动存档。固定条目受到保护。图书管理员的安全水印可确保在消化之前不会存档任何内容。结果：即使经过数月的累积数据，检索也保持精确。
压缩弹性上下文快照。 当主机驱逐上下文时，代理会立即恢复。 mp_snapshot_save 写入一个实时的仅覆盖状态文件——当前焦点、活动任务、阻止程序、最近的决策。压实后， mp_snapshot_read 在一次通话中恢复工作状态。不是会话日志。一个保存点。
写完整性保护。 在内存进入系统之前，可以根据现有数据对其进行验证。验证层检测四种风险类型：重复、矛盾、幻觉事实和过时的覆盖。决策类型条目会自动验证。原则是：永远不要盲目相信代理人的写作。
三层可插拔搜索。 L2搜索使用任何可用的后端：安装QMD（BM25+向量+LLM重新排序）时，Orama BM25作为嵌入式回退，或简单的关键字扫描作为最后手段。无需建设RAG管道。检索+摘要系统将L0/L1/L2结果与LLM合成相结合，以获得结构化答案。
关系记忆与信任跟踪。 标记的交互模式会随着时间的推移而积累。信任评分会根据明确的事件而变化。代理为每个用户或合作者构建一个结构化的配置文件——沟通风格、专业知识、偏好——为未来的交互提供信息。
集中式配置参考。 所有子系统中的每个可调参数（28个参数，涵盖库管理员计划、衰减阈值、验证规则、搜索后端等）都记录在一个可查询的引用中，其中包含默认值、类型、受影响的系统和代码位置。 mp_config_reference 返回可按关键字筛选的完整表。
______________________________________________________________________
太长，读不下去了
人工智能代理的ECS架构认知系统。身份+知识+决策+关系，有工程保证。
- ECS架构。 实体注册表（身份/个性）+组件存储（知识模块）+系统存储（自动化管道）。按需装卸。
- 三级指数。 L0主指数（\背景。 代理人不会携带所有东西。它携带一个压缩的全局索引（\提示说明。 必须发生的事情（git提交、索引更新、更改日志写入）是代码级的PostHooks，而不是可能被遗忘的LLM指令。
- 便携性>召回。 所有状态都是可序列化的、可转移的、版本控制的。复制
~/.open-palace/任何机器。
______________________________________________________________________
建筑
┌──────────────────────────────────────────────────────────────────┐
│ MCP Server (stdio) │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────┐ │
│ │ Entity Registry │ │ Component Store │ │ System Store │ │
│ │ Identity + SOUL │ │ Projects/Skills │ │ Librarian │ │
│ │ Evolution Log │ │ Knowledge/Rels │ │ Health Check │ │
│ │ Bidirectional │ │ Load/Unload │ │ Memory Decay │ │
│ │ Workspace Sync │ │ Per-component │ │ Retrieval+ │ │
│ │ │ │ Changelog │ │ Digest │ │
│ └──────────────────┘ └──────────────────┘ └──────────────┘ │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────┐ │
│ │ 3-Level Index │ │ Dual-Layer │ │ PostHook │ │
│ │ L0: Global Map │ │ Changelog │ │ Engine │ │
│ │ L1: Summaries │ │ + Write │ │ Auto git │ │
│ │ L2: Search/RAG │ │ Validation │ │ Auto index │ │
│ └──────────────────┘ └──────────────────┘ └──────────────┘ │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────┐ │
│ │ Context Snapshot │ │ Workspace Sync │ │ 3-Tier │ │
│ │ Compaction │ │ SHA256 diffing │ │ Search │ │
│ │ Recovery │ │ SOUL writeback │ │ QMD/Orama/ │ │
│ │ │ │ │ │ builtin │ │
│ └──────────────────┘ └──────────────────┘ └──────────────┘ │
│ │
│ Persistence Layer │
│ ~/.open-palace/ (YAML + Markdown + Git) │
└──────────────────────────────────────────────────────────────────┘______________________________________________________________________
快速开始
先决条件
- Node.js>=18（推荐：v22）
- npm
游标（推荐--单行安装）
bash Orama>内置）搜索所有数据|
| `mp_search_reindex` |手动重建搜索索引|
| `mp_search_status` |检查活动搜索后端、索引项目计数、上次重新索引时间|
### 关系：互动记忆
|工具|说明|
|------|-------------|
| `mp_relationship_get` |获取完整的关系记录（个人资料+互动标签+信任+历史记录）|
| `mp_relationship_update_profile` |更新实体简介（风格、专业知识、偏好）|
| `mp_relationship_log_interaction` |记录交互标签（自动累积计数）|
| `mp_relationship_update_trust` |更新信任评分并注明原因（限0.0-1.0）|
### 记忆衰退：主动遗忘
|工具|说明|
|------|-------------|
| `mp_decay_preview` |预览将存档的内容（带温度分数的模拟运行）|
| `mp_decay_pin` |固定/取消固定条目以防止或允许存档|
### 系统：自动化管道
|工具|说明|
|------|-------------|
| `mp_system_list` |列出已注册的系统及其运行状态|
| `mp_system_execute` |执行系统（库管理员、健康检查、记忆生成、记忆删除、检索摘要）|
| `mp_system_status` |检查运行历史和状态（包括图书馆员安全水印）|
| `mp_system_configure` |更新系统配置|
### 配置
|工具|说明|
|------|-------------|
| `mp_config_get` |按点路径读取配置|
| `mp_config_update` |更新配置值|
| `mp_config_reference` |查看所有28个可配置参数，包括默认值、类型、受影响的系统和代码位置|
### 入职
|工具|说明|
|------|-------------|
| `mp_onboarding_status` |检查设置状态，获取未完成步骤的指导|
| `mp_onboarding_init` |运行初始设置：创建技能、更新TOOLS.md、同步工作区文件|
______________________________________________________________________
## 关键系统
### 图书管理员
在多个级别将变更日志和草稿条目处理成摘要：
|级别|默认计划|它的作用|
|-------|-----------------|-------------|
| **摘要** |每日|总结最近的更改日志条目+将匹配的草稿注释添加到L1摘要中。使用安全水印跟踪每个组件的覆盖率|
| **合成** |每周|跨组件相关性分析、每周报告、项目相互依赖性|
| **审查** |每月|完整的L0重建、趋势分析、月度报告、清理建议|
| **抓伤分类** |按需|分析未推广的刮刮条目，匹配组件，建议促销|
图书管理员默认情况下通过MCP采样使用主机的LLM（不需要API键）。如果采样不可用，则返回到直接人类API。
### 记忆衰退
基于温度的主动遗忘，随着数据的增长保持检索的准确性：
- 每个条目都有一个温度分数： `age_base + access_bonus + reference_bonus + pin_bonus`
- 低于存档阈值的条目将被移动到 `archive/` （未删除）
- 图书管理员的安全水印可防止存档未处理的数据
- 固定入口受到永久保护（温度999）
- 可配置： `decay.archive_threshold`, `decay.max_age_days`, `decay.pinned_entries`
### 检索+摘要
使用LLM合成进行L0到L1到L2的渐进检索：
- 三层搜索后端：QMD（BM25+矢量+重新排序的混合搜索）可用时，Orama（嵌入式BM25）作为后备，简单的关键字扫描作为最后手段
- `mp_raw_search` 返回具有相关性得分的原始匹配片段
- `retrieval_digest` 该系统通过将摘要和搜索结果与LLM相结合来合成结构化答案
### 健康检查
验证整个内存系统：
- 索引一致性（L0条目与实际组件目录）
- 孤立检测（没有索引条目的组件，反之亦然）
- 稳定性评分（60天以上未验证的组件标记为陈旧）
- Git状态（未提交的更改）
- 实体同步状态
### 内存摄取
即使代理人写信给本地人 `memory/*.md` 文件，Open Palace在每次MCP服务器启动时通过SHA256 diffing自动捕获内容。被动安全网——代理不需要改变行为，内容就可以流入Open Palace。
### PostHook发动机
每次写入操作都会触发自动的副作用——git提交、索引更新、更改日志写入、搜索重新索引。代码级管道。代理不需要“记住”提交或更新索引。
______________________________________________________________________
## 发展
npm run typecheck # Type check without emitting npm run build # Compile TypeScript npx tsx src/test-e2e.ts # Run E2E tests (138 assertions)
## 路线图
- **第一阶段** --MCP服务器+实体+索引+组件+变更日志+PostHook
- **第2阶段** --L0/L1/组件/变更日志核心逻辑
- **第三期** --图书管理员+系统存储+健康检查
- **第3.5阶段** --入职+双向工作空间同步
- **v0.2** --工作记忆层（划痕+记忆摄入+图书馆员划痕分类）
- **v0.3** --光标集成（规则+技能自动安装，多环境入职）
- **v0.4** --上下文快照、库管理员安全门、内存衰减、写验证、关系内存、三层搜索（QMD/Orama/内置）、检索+摘要、状态评分、集中配置参考
______________________________________________________________________
## 致谢
最初的设计研究涉及研究六个游戏系统中的记忆和人格机制——矮人要塞、迪斯科极乐世界、复仇者系统（魔多之影/战争）、巴尔杜尔之门3、十字军之王3和Planescape：折磨。主要的收获是概念性的：分层记忆结构，即记忆应该是可见和可查询的，而不是隐含的，并且关系可以被捕获为标记的交互。我们没有直接移植任何游戏机制——LLM代理不需要状态机或个性评分系统——但这些游戏塑造了我们对问题空间的看法。
以下项目和著作对建筑产生了直接影响：
- [生成式智能体](https://github.com/joonspk-research/generative_agents) （斯坦福）——证明“结构化外部记忆+LLM反射”确实有效的论文。Open Palace的整个前提——代理应该向持久结构化存储写入和读取，而不是依赖于上下文窗口——都可以追溯到这项工作。
- [MemGPT/Letta](https://github.com/letta-ai/letta) --引入了具有加载/卸载操作的显式内存层，将LLM上下文视为托管资源。我们的组件挂载/卸载和“感知>上下文”原则来自相同的见解。
- [HippoRAG](https://github.com/OSU-NLP-Group/HippoRAG) --海马激发了层次检索。这直接塑造了我们从L0到L1到L2的渐进式拆包流程。
- [OpenViking](https://github.com/volcengine/OpenViking) --具有抽象/概述/详细级别的分层上下文加载。我们三级指标设计的最直接灵感。
- [A-MEM](https://github.com/WujiangXu/A-mem) --Zettelkasten风格的自组织笔记的代理记忆。强化了记忆条目应该相互关联的观点。
- [Mem0](https://github.com/mem0ai/mem0) --内存作为独立的基础架构层。验证了存储计算分离原理。
- [王的OpenClaw内存管理指南](https://x.com/wangray/status/2027034737311907870) --一份医生报告，记录了5个具有结构化记忆的代理30天的运行情况。基于温度的衰变模型、“先消化后遗忘”的安全原则、NOW.md压缩恢复模式和CRUD写入验证方法直接受到了本文见解的启发。Open Palace使用代码级保证而不是基于提示的指令来实现这些模式。
- [主控程序](https://modelcontextprotocol.io/) （Anthropic）——使Open Palace主机不可知的协议层。
- [开爪](https://github.com/nicepkg/openclaw) --我们集成的第一个主机环境。OpenClaw的工作空间文件约定直接塑造了双向同步和入职设计。
- [QMD](https://github.com/tobi/qmd) --本地混合搜索引擎（BM25+向量+LLM重新排序）。Open Palace的三层搜索后端使用QMD作为可用的最高质量选项。
**进一步阅读：** [作者@lijiuer92](https://x.com/lijiuer92/status/2025678747509391664) --对代理内存架构进行了很好的分析。
______________________________________________________________________
## 许可证
麻省理工学院