企业官网建设流程全解析

1. 项目概述：OpenShart，一个严肃的加密内存框架

如果你正在构建AI智能体应用，并且这些智能体需要处理哪怕一丁点敏感信息——无论是用户的个人身份信息、商业机密，还是医疗记录——那么“内存安全”就是你无法回避的生死线。传统的做法是什么？把数据加密后存进数据库。听起来很安全，对吧？但问题在于，一旦你的数据库被攻破，或者那个唯一的加密密钥泄露，攻击者就能像打开一个宝箱一样，拿到里面所有的东西。这就像把所有的鸡蛋放在一个篮子里，然后只给篮子加了一把锁。

OpenShart的出现，就是为了从根本上颠覆这个模型。它的核心思想不是“锁住篮子”，而是“把鸡蛋打碎，分别藏起来”。即使有人找到了其中几块碎片，他们得到的也只是一堆毫无意义的垃圾。这个框架将AI智能体的上下文记忆进行分片、加密和分布式存储，确保没有任何单一的存储位置持有完整的记忆。它的名字（OpenShart）或许带着一丝黑色幽默，但其内部实现——基于Shamir秘密共享、AES-256-GCM认证加密、HMAC可搜索加密，以及企业级的访问控制——却严肃得令人敬畏。它专为AI智能体设计，旨在为你的Agent记忆提供企业级甚至政府级的加密保护。

1.1 核心需求解析：为什么AI智能体需要特殊的内存安全？

AI智能体，尤其是那些能够自主执行任务、访问外部工具和数据的Agent，其工作内存中可能暂存着大量敏感的中间结果。例如，一个处理客户服务请求的Agent，可能会在对话中接触到用户的电话号码、订单号甚至地址；一个分析财务报表的Agent，其记忆里则可能存有未公开的营收数据。这些数据在传统的、基于会话或数据库的存储模型中，面临着几个独特的安全挑战：

首先是“记忆泄露”的风险。智能体的记忆通常是连续的上下文，一次对话或任务中的所有信息都关联在一起。如果这个上下文被完整地窃取，攻击者获得的信息价值是巨大的。OpenShart通过Shamir秘密共享技术，将一段记忆内容分割成N个碎片（称为“份额”），并设置一个阈值K（例如3-of-5）。这意味着，要重建原始记忆，你至少需要收集到K个碎片。单独的一个或两个碎片在密码学上是完全随机的噪声，不包含任何有用信息。这种“碎片化”策略，将单点泄露的风险降到了最低。

其次是“可搜索性”与“隐私性”的矛盾。智能体需要能快速检索相关的历史记忆。如果所有记忆都加密了，如何在不解密的情况下进行搜索？全量解密再匹配在性能和安全性上都是灾难。OpenShart采用了基于HMAC-SHA256的可搜索加密方案。在存储记忆时，它会从内容中提取关键词或特征，生成对应的HMAC令牌（Token）并建立索引。搜索时，查询词同样被转换成HMAC令牌，然后在索引中进行匹配。整个搜索过程，搜索引擎（或存储后端）看到的只有不可逆的哈希值，完全接触不到明文内容，实现了“可搜索加密”。

最后是“合规与访问控制”的复杂性。在企业或受监管的环境中，不同角色、不同部门的智能体对数据的访问权限必须有严格的区分。OpenShart内置了基于角色的访问控制（RBAC）、部门隔离，甚至模拟了美国政府的分级保密模型（从公开、受控非密信息到绝密/敏感分隔信息），并强制执行Bell-LaPadula强制访问控制模型（“不上读，不下写”原则）。这意味着，一个低保密级别的Agent无法读取高保密级别的记忆，反之，高保密级别的Agent也不能将信息“写”到低保密级别的存储区域，防止了信息泄露。

2. 核心安全机制深度剖析

OpenShart的安全不是靠单一魔法，而是由多层防御机制叠加而成的“深度防御”体系。理解每一层的工作原理，有助于你在实际部署中做出正确的配置选择。

2.1 Shamir秘密共享：如何实现“碎片化”安全？

Shamir秘密共享（SSS）是OpenShart实现“无单点完整数据”的基石。其数学原理基于多项式插值。简单来说，如果你想保护一个秘密S（在这里就是你的记忆内容），你可以构造一个（K-1）次多项式，其中常数项是S。然后，你在这个多项式曲线上选取N个不同的点（x, y）。每一个点（即一个碎片）本身不直接暴露S，但任意K个点就能唯一确定这个多项式，从而计算出常数项S。少于K个点，则有无限多个可能的多项式，无法确定S。

在OpenShart中，这个过程是自动化的：

1. 编码：首先，原始文本内容被转换为二进制数据。
2. 分片：框架使用SSS算法，根据你设定的安全预设（如standard使用2-of-3，classified使用5-of-8），将数据分割成N个碎片。
3. 存储：这N个碎片被分别存储。它们可以存放在同一个数据库的不同行、不同表，甚至理论上可以分发到不同的物理存储服务（如不同的云存储桶）。关键在于，没有任何一个存储位置持有足以重建记忆的K个碎片。

实操心得：阈值K和总数N的选择这是一个权衡艺术。K/N的比值越高（如5-of-6），安全性越高，因为攻击者需要攻破更多的碎片存储点。但这也意味着可用性略有下降（需要成功读取5个碎片才能恢复）。K/N比值越低（如2-of-5），可用性高，但安全性相对较低。OpenShart的预设（如government使用5-of-8）为高安全场景提供了良好的平衡。在生产中，你可以根据数据敏感性和存储可靠性来微调。

2.2 AES-256-GCM与每碎片密钥派生：双重加密保障

仅仅分片是不够的。如果一个碎片存储点被攻破，攻击者虽然拿不到完整记忆，但拿到了一个明文碎片，也可能从中推断出部分信息。因此，OpenShart对每一个碎片都进行了独立的加密。

1. 密钥派生：框架使用基于HMAC的密钥派生函数（HKDF），从主加密密钥为每一个碎片派生出一个唯一的加密密钥。这意味着，即使攻击者通过某种手段破解了某一个碎片的密钥，这个密钥也仅对该碎片有效，无法用于解密其他任何碎片。
2. 认证加密：每个碎片使用AES-256-GCM算法进行加密。GCM模式不仅提供了机密性（加密），还提供了完整性和真实性认证（通过认证标签）。这可以防止攻击者在传输或存储过程中篡改加密后的碎片数据。如果碎片被篡改，在解密验证标签时会失败，系统会立即拒绝该碎片，防止使用被污染的数据进行重建。

这个过程确保了：即使N个碎片存储点全部被泄露，攻击者面对的是N个用不同密钥加密的、无法识别的密文块。要获得任何有用信息，他们必须同时：1) 获取至少K个密文碎片；2) 破解每个碎片对应的唯一AES-256-GCM密钥。这在实际中几乎是不可能的。

2.3 HMAC可搜索加密：隐私与效能的平衡

这是OpenShart最巧妙的特性之一。智能体需要搜索记忆，比如“找出所有关于‘项目Alpha’的对话”。如果每次搜索都需要解密所有记忆，性能无法接受，且解密过程本身在内存中暴露了所有数据。

OpenShart的解决方案：

1. 索引生成（存储时）：当存储一段记忆时，框架会对其内容进行预处理（如分词、提取关键词），对每个关键词计算其HMAC-SHA256值。这个哈希值就是“搜索令牌”。同时，该令牌与对应记忆的ID（非内容）的关联关系被存入一个独立的搜索索引表。
2. 查询处理（搜索时）：当智能体搜索“项目Alpha”时，框架对查询词进行完全相同的预处理和HMAC计算，得到搜索令牌。然后，它直接在索引表中查找匹配该令牌的记忆ID列表。
3. 结果返回：返回的是记忆ID列表，不包含任何明文内容。只有当智能体调用recall方法时，才会触发解密和重建流程。

优势：

• 隐私保护：索引中只有哈希值，没有明文。即使是数据库管理员，也无法从索引中推断出原始内容。
• 性能高效：搜索是在哈希索引上的精确匹配，速度极快，复杂度接近O(1)。
• 确定性：相同的查询词总是生成相同的HMAC令牌，保证了搜索的可重复性。

注意事项：搜索模式的局限性当前基于HMAC的精确匹配搜索，不支持模糊搜索、语义搜索或范围查询。例如，搜索“run”不会匹配“ran”或“running”。如果你的应用需要更复杂的搜索能力，需要在应用层进行额外处理，或者考虑在加密前建立更复杂的索引（但这会带来设计复杂性和潜在的信息泄露风险）。OpenShart的设计哲学是在安全性和功能之间优先选择安全。

2.4 ChainLock：时序锁与API级防御

对于最高安全级别（government,classified）的记忆，OpenShart引入了ChainLock机制。这主要防御的是一种特定威胁：假设攻击者已经通过某种方式（如内部威胁）获得了主加密密钥和API访问权限，他们可能会编写脚本批量、高速地提取（recall）所有记忆。

ChainLock通过引入密码学挑战和时序约束来增加这种自动化攻击的难度和可检测性：

1. 随机序列：每次执行recall操作时，系统会生成一个随机的碎片解密顺序。攻击者无法预知先解密哪个碎片。
2. 哈希链与时间窗：解密过程被分解为多个步骤。每一步必须在严格的时间窗口内完成（例如≤2000ms），并且每一步的结果会生成一个令牌，作为下一步的输入，形成一个哈希链。任何一步超时或令牌不匹配，整个操作就会失败并触发安全事件。
3. 攻击检测：自动化脚本的解密步骤耗时通常是均匀的。ChainLock会分析步骤间的耗时，均匀的、机器般的速度模式会触发“潜在自动化攻击”的警报，可能导致账户被临时锁定。
4. 序列轮换：每次成功的recall后，用于生成解密序列的内部种子都会轮换，防止重放攻击。

简单来说，ChainLock让“偷取记忆”这个动作变得又慢又吵，极大地增加了攻击者被发现的概率，并为防御方争取了响应时间。

3. 从零开始：OpenShart集成与实操指南

理论讲完了，我们来点实际的。如何将一个现有的AI智能体项目（比如基于LangChain或CrewAI）的内存层，替换为OpenShart？下面是一个完整的、可操作的指南。

3.1 环境准备与安装

首先，确保你的环境符合要求。OpenShart是一个Node.js库，要求Node.js版本20或更高。

# 在你的项目根目录下 npm install openshart # 根据你选择的存储后端，安装对应的驱动 # 用于开发测试（内存或SQLite） npm install better-sqlite3 --save-dev # 如果选择SQLiteBackend # 用于生产环境 npm install pg # 如果选择PostgresBackend

OpenShart的核心是零运行时依赖（仅使用Node.js内置的crypto模块），但存储后端需要额外的包。

3.2 初始化与配置：选择你的安全等级

初始化是第一步，也是决定整体安全态势的一步。你需要做出几个关键选择：

import { OpenShart, PostgresBackend, Classification, SecurityLevel } from 'openshart'; import { randomBytes } from 'node:crypto'; import { Client } from 'pg'; // 1. 准备存储后端（以Postgres为例） const pgClient = new Client({ connectionString: process.env.DATABASE_URL, // 强烈建议启用SSL连接 ssl: { rejectUnauthorized: false } }); await pgClient.connect(); const storage = new PostgresBackend(pgClient); // 2. 生成或获取主加密密钥（32字节，256位） // 警告：此密钥必须绝对安全！丢失它意味着所有数据无法恢复。 // 生产环境应从安全的密钥管理系统（如AWS KMS, HashiCorp Vault）获取。 const encryptionKey = process.env.OPENSHART_MASTER_KEY ? Buffer.from(process.env.OPENSHART_MASTER_KEY, 'hex') // 从环境变量读取 : randomBytes(32); // 仅用于开发测试 // 3. 初始化OpenShart实例 const shart = await OpenShart.init({ storage: storage, encryptionKey: encryptionKey, securityLevel: SecurityLevel.GOVERNMENT, // 安全预设：'standard', 'enterprise', 'government', 'classified' agentId: 'customer-service-agent-01', // 智能体标识符 role: Role.CONTRIBUTOR, // 在企业RBAC中的角色 department: 'customer-support', // 所属部门 // 政府分级模型配置（如果使用） clearance: { level: Classification.CONFIDENTIAL, compartments: [] // 分隔信息，如['NOFORN', 'REL TO USA'] } }); console.log('OpenShart initialized with security level:', shart.config.securityLevel);

关键配置解析：

• securityLevel: 这是最重要的预设。standard提供了基础的加密和分片，适合内部工具。enterprise增加了RBAC和部门隔离，适合多团队协作。government和classified则引入了ChainLock和更严格的分片策略，适用于处理高度敏感数据。
• encryptionKey: 生命线。务必通过环境变量或密钥管理服务注入，绝对不要硬编码在源码中。考虑使用密钥轮换策略。
• 存储后端:MemoryBackend仅用于单元测试。SQLiteBackend适合单机开发或轻量级部署。PostgresBackend是生产环境的推荐选择，支持高并发和复杂查询。

3.3 核心操作：存储、搜索、召回与遗忘

现在，你的智能体可以通过shart实例来管理记忆了。

存储记忆（Store）

async function storeCustomerQuery(userId: string, query: string) { try { const result = await shart.store( `用户 ${userId} 咨询：${query}。内部处理备注：需要优先跟进。`, { // 元数据，用于过滤和分类，不参与碎片化，但会以明文或加密形式存储（取决于后端） tags: ['customer', 'query', 'high-priority'], // 自定义分类级别，会覆盖自动检测 classification: Classification.CUI, // 例如，客户信息视为“受控非密信息” // 自定义分隔 compartments: ['INTERNAL'], // 设置时间戳 timestamp: new Date(), } ); console.log(`记忆存储成功。ID: ${result.id}, 检测到的PII级别: ${result.piiLevel}, 碎片数量: ${result.fragmentCount}`); return result.id; } catch (error) { console.error('存储记忆失败:', error); // 处理错误，可能是加密失败、存储失败或访问控制拒绝 throw error; } }

当调用store时，OpenShart内部会触发完整的流水线：PII检测 -> Shamir分片 -> 每碎片AES-GCM加密 -> HMAC索引生成 -> 存储所有碎片和索引 -> 写入审计日志。

搜索记忆（Search）

async function searchCustomerInteractions(keyword: string) { const results = await shart.search(keyword, { // 可选的搜索过滤器 tags: ['customer'], classification: Classification.UNCLASSIFIED, // 只能搜索等于或低于此级别的记忆 limit: 10, }); if (results.length === 0) { console.log('未找到相关记忆。'); return []; } console.log(`找到 ${results.length} 条相关记忆。`); // results 是一个数组，包含记忆的元数据（如id, tags, classification, timestamp），但不包含content！ return results.map(r => r.id); }

召回记忆（Recall）

async function recallMemory(memoryId: string) { try { const memory = await shart.recall(memoryId); // 回忆成功！memory对象包含完整的content和所有元数据。 console.log(`召回的记忆内容: ${memory.content}`); console.log(`原始标签: ${memory.tags}`); return memory; } catch (error) { if (error.code === 'ACCESS_DENIED') { console.warn(`智能体无权访问记忆 ${memoryId}。`); } else if (error.code === 'CHAINLOCK_BREACH') { console.error(`ChainLock检测到潜在攻击！记忆 ${memoryId} 的访问已被临时锁定。`); // 触发安全告警！ } else { console.error(`召回记忆失败:`, error); } throw error; } }

recall操作是最复杂的，它需要：1) 验证访问权限（Bell-LaPadula）；2) 从存储中获取至少K个碎片；3) 对于高安全级别，执行ChainLock协议；4) 用派生密钥解密每个碎片；5) 使用Shamir算法重建原始内容。

遗忘记忆（Forget）

async function complyWithGDPRRightToBeForgotten(userId: string) { // 1. 搜索该用户的所有记忆 const memoriesToForget = await shart.search(`用户 ${userId}`, { tags: ['customer'] }); // 2. 安全擦除每一条记忆 for (const memory of memoriesToForget) { await shart.forget(memory.id); console.log(`已安全擦除记忆: ${memory.id}`); } // 可选：导出擦除操作的审计日志，作为合规证据 const auditLog = await shart.export({ action: 'forget', agentId: shart.config.agentId }); // 将auditLog存档... }

forget操作不仅仅是删除数据库记录。它遵循美国国防部DoD 5220.22-M标准，对存储每个碎片的数据区域进行三次覆写（全零、全一、随机数据），并进行验证，确保数据无法通过磁盘恢复技术找回。最后才删除元数据。

3.4 与企业系统集成：RBAC与部门隔离

在真实的企业环境中，你的AI智能体可能分属不同部门（如销售、客服、研发），拥有不同角色。

import { DepartmentManager, ContextFlowManager, Role } from 'openshart'; // 初始化部门管理器 const deptManager = new DepartmentManager(); deptManager.registerDepartment({ id: 'sales', name: 'Sales', encryptionNamespace: 'sales-ns-2024', // 为每个部门使用独立的密钥命名空间，增强隔离 }); deptManager.registerDepartment({ id: 'support', name: 'Customer Support', encryptionNamespace: 'support-ns-2024', }); // 初始化上下文流转管理器 const flowManager = new ContextFlowManager(deptManager); // 场景：销售总监（EXECUTIVE）需要将一条信息下发给客服专员（CONTRIBUTOR） const executiveMessage = "重点客户 'Acme Corp' 的合同已续签，金额$500k。联系人：alice@acme.com。"; const redactedMessage = flowManager.pushDown( executiveMessage, Role.EXECUTIVE, // 发送者角色 Role.CONTRIBUTOR, // 接收者角色 'sales', // 发送部门 'support' // 接收部门 ); console.log(redactedMessage.content); // 输出: "重点客户 '[COMPANY_REDACTED]' 的合同已续签，金额[FINANCIAL_REDACTED]。联系人：[EMAIL_REDACTED]。" // PII和敏感财务信息被自动脱敏！ // 现在，客服部门的智能体可以用脱敏后的内容安全地存储记忆 const supportShart = await OpenShart.init({ storage, encryptionKey, securityLevel: 'enterprise', agentId: 'support-agent-01', role: Role.CONTRIBUTOR, department: 'support', // 部门隔离：support部门的智能体无法访问sales部门的加密命名空间 }); await supportShart.store(redactedMessage.content, { tags: ['task', 'follow-up'] });

这种机制确保了信息在组织内向下流动时，遵循“最小必要知情”原则，自动过滤掉低级别角色不应看到的信息。

4. 生产环境部署、监控与问题排查

将OpenShart投入生产，意味着你需要考虑高可用性、密钥管理、监控和故障恢复。

4.1 密钥管理：生命线的守护

主加密密钥的管理是重中之重。

策略一：环境变量（仅适用于开发/测试）

# .env 文件 OPENSHART_MASTER_KEY=你的32字节十六进制密钥字符串

风险：如果服务器被入侵，环境变量可能被读取。密钥轮换困难。

策略二：密钥管理服务（KMS）集成（生产环境推荐）

// 伪代码示例：从AWS KMS获取数据密钥 import { KMSClient, GenerateDataKeyCommand } from '@aws-sdk/client-kms'; const kmsClient = new KMSClient({ region: 'us-east-1' }); async function getEncryptionKey() { const command = new GenerateDataKeyCommand({ KeyId: process.env.KMS_KEY_ARN, KeySpec: 'AES_256', }); const response = await kmsClient.send(command); // response.Plaintext 是明文数据密钥，用于本次内存加密。 // response.CiphertextBlob 是加密后的数据密钥，需要存储起来（例如在数据库的配置表中）。 // 注意：Plaintext必须仅在内存中使用，用后立即清除（使用SecureBuffer）。 const plaintextKey = response.Plaintext; // 使用OpenShart的SecureBuffer包装，确保密钥不会在内存中停留过久或意外泄露。 const secureKey = new SecureBuffer(plaintextKey); // ... 使用secureKey // secureKey 超出作用域或被手动.destroy()后，内存会被覆写。 return Buffer.from(plaintextKey); }

优势：主密钥（CMK）由KMS安全保管，自动轮换。数据密钥（DEK）每次操作动态生成，明文仅在内存中存在极短时间。符合很多合规要求。

策略三：Shamir密钥托管对于防止密钥丢失，OpenShart提供了createEscrow功能，可以将主密钥通过Shamir秘密共享分给多个托管人。

import { createEscrow } from 'openshart'; const custodians = [trustee1PublicKey, trustee2PublicKey, trustee3PublicKey, trustee4PublicKey, trustee5PublicKey]; const keyShares = createEscrow(masterKey, custodians, { threshold: 3, totalShares: 5 }); // 将keyShares安全地分发给5个托管人。需要至少3人合作才能恢复主密钥。

4.2 存储后端选型与高可用

生产级Postgres配置建议：

1. 连接池：使用pg库的连接池，避免为每次操作创建新连接。
2. SSL/TLS：强制启用数据库连接加密。
3. 备份：设置定期的逻辑备份和持续归档（WAL）。
4. 监控：监控数据库连接数、查询性能、磁盘空间。
5. 表结构：OpenShart会自动创建所需表。建议定期执行VACUUM ANALYZE以优化性能。

4.3 监控与审计

OpenShart内置了完整的审计日志，所有操作（store, recall, search, forget）都会生成一个不可篡改的哈希链条目。

// 定期验证审计链的完整性 const isChainValid = await shart.verifyAuditChain(); if (!isChainValid) { console.error('审计链已被篡改！立即启动安全事件响应。'); // 触发告警，冻结相关账户，开始调查。 } // 导出审计日志用于合规审查 const auditExport = await shart.export({ startTime: new Date('2024-01-01'), endTime: new Date('2024-12-31'), agentId: 'specific-agent', action: 'recall', // 过滤特定操作 }); // auditExport 是一个包含所有审计条目的JSON数组，可以导入到SIEM或日志管理系统中。

你应该将审计日志实时导出到集中式日志平台（如ELK Stack, Splunk），并设置告警规则，例如：

• 短时间内大量recall失败（可能为暴力破解）。
• ChainLock违规触发。
• 审计链验证失败。
• 来自未授权部门或角色的访问尝试。

4.4 常见问题与排查技巧实录

在实际集成和使用中，你可能会遇到以下问题：

问题1：recall操作失败，错误信息为INSUFFICIENT_FRAGMENTS。

• 可能原因A：存储后端故障，导致无法读取到足够数量（K个）的碎片。
  • 排查：检查数据库连接和状态。检查对应的fragments表中，该memory_id对应的记录是否少于K条。可能是之前的store操作未完全成功，或forget操作有残留。
  • 解决：确保存储后端稳定。对于关键数据，考虑使用支持事务的存储后端（如Postgres），并将store操作包裹在事务中。
• 可能原因B：数据损坏。虽然AES-GCM能检测篡改，但磁盘位翻转或数据库损坏可能导致碎片数据无效。
  • 排查：检查数据库完整性。尝试手动查询碎片数据，看是否是有效的Base64或二进制格式。
  • 解决：从备份中恢复数据。如果该记忆不重要，可以执行forget清理，然后重新store。

问题2：搜索（search）返回的结果不准确或遗漏。

• 可能原因A：HMAC令牌生成不一致。存储和搜索时对文本的预处理（如大小写、空格、分词）必须完全一致。
  • 排查：OpenShart默认使用简单的空格分词和小写转换。确保你搜索的词汇与存储时内容中的词汇形式一致。搜索“New York”可能无法匹配“new york city”。
  • 解决：在存储和搜索前，在应用层对文本进行统一的标准化处理（如转为小写、移除标点、词干提取）。注意，这可能会略微增加信息泄露的风险。
• 可能原因B：访问控制限制。搜索会受到classification和department过滤器的限制。
  • 排查：确认执行搜索的智能体其clearance.level和department是否有权访问目标记忆的分类级别和部门。
  • 解决：调整智能体的权限配置，或确保记忆被存储在适当的分类和部门下。

问题3：性能问题，特别是store和recall操作慢。

• 可能原因A：加密/解密开销。AES-256-GCM和Shamir算法是计算密集型操作，对于非常大的记忆内容（如数MB的文本），会有明显延迟。
  • 排查：使用Node.js性能分析工具（如--inspect）定位瓶颈。通常加密是主要开销。
  • 解决：考虑限制单条记忆的大小（例如，拆分成多个小于100KB的记忆）。对于recall频繁的热数据，可以在应用层实现一个安全的、短期的缓存（缓存解密后的内容，并设置很短的TTL）。
• 可能原因B：数据库I/O。每个store操作涉及写入多个碎片行和索引行。
  • 排查：监控数据库的写入延迟和IOPS。
  • 解决：对数据库进行性能调优（索引、硬件升级）。考虑使用更快的存储（如SSD）。对于写入密集型场景，评估使用数据库连接池和批量写入的可能性（但需注意OpenShart API目前是单条操作）。

问题4：如何将OpenShart与现有的LangChain或CrewAI项目集成？

• 核心思路：你需要实现一个自定义的BaseChatMessageHistory（对于LangChain）或类似的记忆存储接口，在这个实现内部调用OpenShart的store,search,recall方法。
• 步骤：
  1. 创建一个类，例如OpenShartMessageHistory，实现BaseChatMessageHistory接口。
  2. 在addMessage方法中，将消息对象序列化（如JSON.stringify），然后调用shart.store()。
  3. 在getMessages方法中，你可能需要根据会话ID进行搜索（将会话ID作为tags存储），然后批量recall这些消息，反序列化后返回。
  4. 在clear方法中，找到该会话的所有记忆ID并调用shart.forget()。
• 注意：你需要设计一个策略来将LangChain的“会话”概念映射到OpenShart的记忆ID和标签上。通常，一个会话ID可以作为一个标签。

问题5：升级OpenShart版本或迁移存储后端。

• 升级版本：小版本号升级（如1.0.0 -> 1.0.1）通常是安全的。大版本升级（如1.x -> 2.x）可能涉及不兼容的API或数据格式变更。务必在测试环境充分验证，并先备份所有数据。查看项目的CHANGELOG和迁移指南。
• 迁移后端（如SQLite -> Postgres）：这是一个数据迁移过程。
  1. 使用旧后端和旧实例，通过list和recall操作，将所有记忆的明文内容和元数据导出到一个安全的中间文件（此过程需确保中间文件的安全）。
  2. 初始化新的Postgres后端和新实例（使用相同的主密钥）。
  3. 编写脚本，读取中间文件，使用新实例的store方法重新存储所有记忆。
  4. 验证新数据库中记忆的数量和可访问性。
  5. 切换应用配置，指向新的Postgres后端。
  6. 安全擦除旧数据库文件。