saihm-mcp

SAIHM MCP Server

**面向自有托管式 SAIHM 运营方的标准客户端。**它本身不包含任何密码学功能，需要提供运营方端点 URL 和运营方令牌。如果你只想快速启用记忆，免费，约一分钟即可，请使用 @saihm/mcp-server-pro，并让你的 Agent 说 “加入 SAIHM”。

· Apache-2.0

初次接触 SAIHM？观看 6 分钟概览（含字幕和文字稿），或阅读 SAIHM 手册（PDF）。

此软件包是标准客户端：八种记忆工具，任何 MCP Agent——Claude Code、Claude Desktop、Cursor，或你自己的 Agent——都可以调用。它本身不包含任何密码学功能。它通过普通 MCP 使用公开文档化的 SAIHM 记忆协议，并连接到你指定的任意 SAIHM 运营方。

我应该选择哪个软件包？

• 你运行或订阅了自己的 SAIHM 运营方——选这个。它不包含密码学功能且依赖精简，正是其设计目的：它可接入由托管式运营方提供的服务，由运营方在服务器端执行密码学操作。 → 安装 · 配置
• 你只想快速启用记忆，免费，约一分钟即可——请使用 @saihm/mcp-server-pro 并让你的 Agent 说 “加入 SAIHM”。它会在你自己的设备上封装单元，因此可以使用托管的非托管式服务——这个不含密码学功能的软件包无法使用该服务。无需银行卡。→ 免费试用

想先看看它如何运行？适用于所有主流模型的可运行演示，无需联网，也无需账户——查看运行效果。

这是什么

一个 Model Context Protocol 服务，提供八种工具，任何兼容 MCP 的 AI Agent（Claude Code、Claude Desktop、自定义 Agent）都可以调用，以获得由用户拥有的持久化加密记忆层：

• saihm_remember — 存储加密记忆单元
• saihm_recall — 检索记忆，由你的运营方解密
• saihm_forget — 擦除记忆；擦除是通过密码学还是访问控制实现，取决于你的运营方（请参阅其文档）
• saihm_status — 协议运行时统计信息和存储层级概览
• saihm_share / saihm_revoke_share — 按分片 ID 与另一个 Agent 分享选定的记忆分片，并撤销该访问权限
• saihm_governance_propose / saihm_governance_vote — 协议治理；默认未启用，因此除非你的运营方已启用此功能，否则会报错

每种工具都会转发到运行完整协议栈的 SAIHM 运营方端点。服务本身不持有加密材料、不提供存储，也不运行协议；这些都由运营方端点提供。

工具参考

工具	标题	行为
saihm_remember	记住	写入新的记忆单元
saihm_recall	回忆	只读；可安全重复调用
saihm_forget	忘记（GDPR 擦除）	具有破坏性——擦除后无法恢复
saihm_status	状态	只读
saihm_share	分享	写入分享合约
saihm_revoke_share	撤销分享	撤销授权
saihm_governance_propose	提议（治理）	转发提案；默认未启用
saihm_governance_vote	投票（治理）	转发投票；默认未启用

每种工具都带有 MCP 注解（readOnlyHint、destructiveHint、idempotentHint、openWorldHint）和便于人类理解的 title，因此 MCP 宿主可以要求用户确认，Agent 也能在推理时选择合适的工具。

配套包

此软件包支持 MCP，不包含任何加密功能，因此始终需要配置运营方端点和令牌。还有两个配套包可满足其余需求：

• @saihm/mcp-server-pro — 即插即用的 MCP 服务，可自行执行客户端加密操作，并且支持自助开通，包括免费套餐。如果你还没有端点，应使用此软件包 — 参见免费试用。
• @saihm/client-pro — 提供相同客户端加密功能的库，可嵌入你自己的应用中：在你自己的设备上执行后量子密封、经过身份验证的共享和可证明擦除，让运营方始终无法读取数据。

查看运行效果

可运行的一键演示会在各大模型 — Claude、GPT、DeepSeek、Qwen、Kimi、GLM — 中使用你拥有的记忆，然后证明你可以将其擦除；还提供适用于 LangChain、LlamaIndex、CrewAI、AutoGen 和 LangGraph 的即插即用适配器。每个演示都可离线运行，约需一分钟；无需账户。

• 在线演示： https://saihm-admin.github.io/saihm-demos/
• demo-claude-code 可将此服务接入 Claude Code 和 Cursor，作为 MCP 服务使用。

实测 — 上下文令牌最多可减少约 86%。 大多数 Agent 每轮都会重新发送完整对话记录，因此一次会话中的上下文开销会以约 O(N²) 的速度增长；改为检索数量有限的记忆单元后，在一项贴近实际的多会话编码任务中，输入令牌减少了 62.8%–85.9%。基准测试开放、离线且具确定性 — 你可以亲自复现结果，而非盲目信任：

git clone https://github.com/SAIHM-Admin/saihm-token-benchmark
cd saihm-token-benchmark && npm install && node benchmark.mjs

安装

npm install @saihm/mcp-server
# or run directly without install:
npx @saihm/mcp-server

配置

服务需要两个环境变量：

SAIHM_ENDPOINT_URL=https://operator.example.com/mcp
SAIHM_AUTH_HEADER=Bearer <token-issued-by-your-operator>

还没有端点和令牌？ 它们由 SAIHM 运营方 签发。 此软件包有意设计为不包含加密功能，因此需要一个托管式 运营方 — 由它在服务器端执行加密并返回明文。

https://saihm.net 上的 SAIHM 托管服务并非此类服务。 它从设计上采用 非托管模式：只存储密文，从不持有你的密钥，因此，只有持有密钥的客户端 才能打开在那里密封的单元。要使用托管服务 — 包括免费试用（使用 GitHub 登录，无需银行卡）— 请使用 @saihm/mcp-server-pro， 它会在你自己的设备上进行密封和打开。请参阅下文的 免费试用和加入 SAIHM。

请将此软件包用于你自行运行或订阅的托管式运营方。 在配置运营方之前，工具将无处可连接，并返回错误。

• SAIHM_ENDPOINT_URL — 你自行运行或订阅的托管式 SAIHM 运营方端点。 并非 https://saihm.net 上的托管服务，该服务采用非托管模式 — 请参阅上方说明。
• SAIHM_AUTH_HEADER — 运营方要求的 Authorization 标头值（通常为在通过密钥绑定 完成注册后签发给你的 Bearer <token>）。此服务不限定身份验证方式，并且绝不传输 原始私钥；运营方的注册流程会将你的签名密钥保留在你的设备上。

这两个变量都从进程环境中读取。此软件包不会加载 .env 文件 — 它没有 dotenv 依赖，也不会从磁盘读取配置 — 因此，请在 MCP 宿主的服务器配置 env 块中设置它们，或在启动服务的 shell 中导出它们。如果为了方便而将它们 保存在 .env 文件中，请在启动前自行加载，并确保不将该文件纳入版本控制。

免费试用（使用 GitHub 登录）

想在付费前通过真实基础设施测试 SAIHM？通过 GitHub 设备登录验证您是独立个体后，即可开始免费试用，仅用于测试，无需银行卡。试用通过非托管的 @saihm/mcp-server-pro 客户端运行，该客户端会在您自己的机器上封装存储单元，因此运营方无法查看其中内容。

首先生成您的主密钥——它永远不会离开您的机器，也是访问您记忆的唯一密钥：

openssl rand -hex 32 > saihm-master.key && chmod 600 saihm-master.key

然后激活：

SAIHM_ENDPOINT_URL=https://saihm.net/mcp \
SAIHM_MASTER_SECRET_FILE=./saihm-master.key \
SAIHM_TIER=FREE \
  npx -y @saihm/mcp-server-pro free-join

系统会显示一组短代码和一个链接：在浏览器中打开 https://github.com/login/device，并输入该代码。登录过程始终在浏览器中进行——此客户端不会查看或持有您的 GitHub 令牌；令牌会在服务端交换，并以临时方式保存。free-join 返回后，按常规方式启动服务（移除 free-join），服务便会自动为您开通免费试用。无需银行卡，也无需取消——这是固定的一次性额度，不是自动续订的订阅。

准备好用于生产环境了吗？可直接升级为月度套餐——签名密钥不变，记忆不变，无需重新开通。

成功效果

接入服务不等于实际使用。关键时刻是第一次成功返回内容的回忆——在此之前，您的存储为空，Agent 也没有特别的理由去调用它。

下面用一个简单例子展示整个产品。接入服务（见下一节）并重启宿主后，对您的 Agent 说：

记住，我喝咖啡不加奶，而且我正在开发一个名为 ferry 的 Rust CLI。

……然后开始新的对话（或重启宿主），并询问：

你对我了解多少？

新对话应该会返回这两条信息，并且您的宿主应显示一次 saihm_recall 调用。新对话从未看到过第一次对话——是记忆将它们传递了过来。在此基础上构建任何内容之前，请先确认这一往返流程正常。

如果回忆结果为空，几乎总是以下原因之一：

现象	原因	解决方法
完全没有提供 SAIHM 工具	宿主从未启动服务	在下面的 JSON 中保留 timeout，然后重启宿主
提供了工具，但 Agent 从未调用	没有常驻指令要求它调用	参见下文的告诉您的 Agent 使用它——这是最常见的原因
回忆已执行，但结果为空	第一轮没有存储任何内容	按名称调用 saihm_remember，然后再次回忆
出现 401 或 403，且您的端点是 saihm.net 或 saihm.coti.global	该服务为非托管服务——此客户端无法读取它	改用 @saihm/mcp-server-pro；参见上文的免费试用
从您自己的运营方收到 401 或 403	令牌无效	通过该运营方重新签发令牌
出现 could not reach ...	端点错误或无法访问	检查 SAIHM_ENDPOINT_URL；消息中会指出原因

宿主说明（2026-09-23）。 托管端点为 https://saihm.net/mcp。旧主机 saihm.coti.global 将继续提供相同服务，直到 2026-12-31，之后将停止服务；如果配置中仍使用该主机，请将 SAIHM_ENDPOINT_URL 切换为 https://saihm.net/mcp。

接入 Claude Code

{
  "mcpServers": {
    "saihm": {
      "command": "npx",
      "args": ["@saihm/mcp-server"],
      "env": {
        "SAIHM_ENDPOINT_URL": "https://operator.example.com/mcp",
        "SAIHM_AUTH_HEADER": "Bearer <token>"
      },
      "timeout": 60
    }
  }
}

保留 timeout，并确保代码块是严格的 JSON，不带尾随逗号。 不识别 timeout 的宿主会忽略它，但 Cline 只允许服务用 1.5 s 启动——这不足以让 npx 解析并启动软件包；如果服务未能在截止时间前启动，就会被静默跳过，聊天中不会显示任何错误。

告诉你的 Agent 使用它

接入服务后，工具便可用；但这并不意味着 Agent 会主动调用它们。把下面这段话告诉 Agent 一次，并将它保存在 Agent 已经读取的持久化指令中：

充分使用 SAIHM 协议，以最大限度节省 token。从现在起使用我的 SAIHM 记忆。在每次会话开始时，回想你已经了解的关于我的信息。当我告诉你值得保留的内容——我的偏好、决定或正在进行的项目——请记住它。为了确认现在就能正常工作：记住我今天接入了 SAIHM，然后把这件事回想出来告诉我。

支持 MCP 提示词的宿主可以按需加载相同的规则，无须粘贴：服务提供了 saihm_session_bootstrap 提示词，其中包含完整的存储、回忆、分享和擦除指南。只有在请求时才会获取，不会在每次会话中都获取。

为什么这种设置最节省 token。 无论 Agent 是否使用工具，每次会话中介绍这些工具都会产生固定开销。回忆能够弥补这笔开销：一次 saihm_recall，如果能免去你重新解释项目、偏好或上周的决定，节省的 token 就会超过介绍工具的开销；会话越长、保留的会话越多，节省的 token 就越多。永远不调用工具的 Agent 只会承担开销，却无法获得任何回报——因此，最好明确设置上述指令，而不是寄希望于 Agent 自己领会。

持久化哪些内容，以及存储位置

服务本身不会持久化任何内容。运营方端点运行完整的协议栈：它会加密并将单元持久化到已配置的持久化存储中，同时记录审计事件。加密方式以及擦除依赖的是密码学手段还是访问控制，由运营方决定：有关这些内容和各层级的详情，请参阅运营方的文档，并参见下文的**存储由运营方负责（这是有意的设计）**。

存储由运营方负责（这是有意的设计）

面向运营方——请先阅读。 SAIHM 不会将你的持久化存储硬性绑定到任何单一提供商，也不会悄悄为你配置存储。选择并配置单元的持久化位置，是你有意承担的职责。 这是为了方便运营方并保障数据自主权而作出的刻意设计选择，并非功能缺失。如果记忆写入因存储错误而失败，几乎总是因为尚未配置后端。

采用这种方式的原因：

• 提供商自主权。 你可以决定将租户的加密单元存放在哪里。协议绝不会将你锁定在某一家供应商或某个网络。
• 先本地存储，再进行深度归档。 运营方通常会先将写入路由到本地 IPFS（Kubo）节点——速度快、权威且由你自己控制——然后异步写入 Filecoin 深度归档提供商，例如 Pinata、Synapse 或 Lighthouse。同一套内容寻址方式适用于这两个层级。
• 你的记忆和租户的记忆走同一条路径。 无论你配置哪个后端，它都会同时服务于运营方自己的记忆和所有租户的记忆——不存在硬编码到某个提供商的独立隐藏存储端。

需要配置的内容（运营方部署指南列出了具体设置）：

• 一个可访问的 IPFS / Kubo 端点（建议使用本地节点），用于提供权威的低延迟层；以及
• 至少一个 Filecoin / IPFS 固定存储提供商的凭据，用于持久化深度归档。

如果两者都未配置，端点将没有可用于持久保存单元的位置，并会拒绝写入，而不是丢失数据。这是有意为之。

不想自行运行存储服务？加入 SAIHM。

你有两种选择，任选其一即可：

1. 运行自己的运营方端点，并按上文所述配置存储后端——完全自主，使用你自己的基础设施。
2. 加入托管式 SAIHM 运营方，由其为你提供持久化存储。它以盲式／非托管方式运行：配合客户端加密封装（参见 @saihm/client-pro 和 @saihm/mcp-server-pro），它始终只存储密文，绝不持有你的密钥——因此，你既能使用托管存储，又无需放弃密钥控制权。通过 https://saihm.net 上的 Join SAIHM 注册（付费托管服务）。

报告引擎

报告库作为子导出打包，因此运营方可使用自己的工具将 8 个 MCP 调用组合成定制报告（无需额外依赖或服务）：

import {
  validateBespokeTemplate,
  registerTemplate,
  generateRegistryAttestation,
  StubPublicRegistry,
  InMemoryReportingRuntime,
  GDPR_ART15_FIELDS,
  REGISTRY_ATTESTATION_FIELDS,
  type BespokeReportTemplate,
} from "@saihm/mcp-server/reporting";

此软件包仅支持 ESM——使用 "type": "module"，且 exports 映射声明了 import 条件，没有 require 条件。因此，在 CommonJS 项目中调用 require("@saihm/mcp-server/reporting") 会因 ERR_PACKAGE_PATH_NOT_EXPORTED 而失败，这看起来像是子导出不存在；实际上它存在，问题出在模块系统上。两个入口点——根路径和 /reporting——都会如此。升级 Node 也无济于事：当前的 Node 20.x 虽然可以 require() ES 模块，但只有在匹配到 require 条件时才会生效，而此软件包未声明该条件，因此所有受支持版本都会出现相同的失败。请使用 import，或在 CJS 中通过动态 await import() 加载。

涵盖内容

• 字段全集（FIELD_UNIVERSE）——280 个字段（262 个框架字段 + 18 个账本字段）。验证时，任何投影范围超出此集合的模板都会被拒绝。在按数量规划前，请先查看具体构成：12 个 GDPR 第 15 条字段、11 个 GDPR 第 17 条字段和 18 个账本字段，是带有子条款引用的原始规范名称；其余 239 个字段——SOC 2 Type 1 和 2、ISO 27001 以及全部 4 个 AML 子前缀——都是确定性的结构占位符（如 iso27001_F01、aml_ctr_item_01 等），需要映射到你自己的规范名称。这些是经过强制校验的投影槽位，并非监管字段枚举，因此选择 iso27001 会得到 31 个经过校验的槽位，而不是 31 个具名 ISO 27001 字段。未来工作包括依据主要来源将其替换为原始规范名称。
• 定制模板架构——zod 验证器 + 全集成员检查 + 范围／上限强制检查。
• 授权路径验证器——4 条路径：public / self / operator-self / operator-for-downstream。这些验证器检查结构——形状、十六进制格式、重放窗口以及类型与授权的关联。签名验证由你注入的回调完成；在用其控制任何操作前，请参阅接入签名验证器。
• 收据生成——稳定且按域隔离的收据命名空间下的 6 个子类型（report_generated / report_rejected / template_registered / template_superseded / erasure_chain_broken / rate_limit_exceeded）。
• 框架冒烟测试——用于端到端连通性验证的 registry-attestation（公共授权）。

限制条件

• 每个 fieldProjections[] 条目都必须属于 FIELD_UNIVERSE。
• scope.customerIdHashes 为 64 位十六进制字符串；每个模板最多 10,000 个。
• scope.timeRange 时间窗口 ≤ 366 天。
• fieldProjections 长度为 1–200。
• framework ∈ {gdpr-art-15, gdpr-art-17, soc2-t1, soc2-t2, iso27001, aml, audit-export, billing-history, registry-attestation}。
• format ∈ {pdfa3, json, csv}。

示例

const template: BespokeReportTemplate = {
  templateId: "acme-q1-summary",
  templateVersion: 1,
  operatorIdHash: "ab".repeat(32),
  scope: {
    customerIdHashes: ["cd".repeat(32)],
    timeRange: { from: "2026-01-01T00:00:00Z", to: "2026-04-01T00:00:00Z" },
  },
  framework: "gdpr-art-15",
  fieldProjections: [GDPR_ART15_FIELDS[0], GDPR_ART15_FIELDS[1]],
  format: "pdfa3",
};
const v = validateBespokeTemplate(template);
if (!v.valid) throw new Error(v.errors.join(", "));

const runtime = new InMemoryReportingRuntime(); // replace with your audit-ledger runtime
const reg = await registerTemplate(template, runtime);
if (reg.ok) console.log("registered:", reg.templateHash);

在生产环境中，请将 InMemoryReportingRuntime 替换为能够将审计载荷持久化到运营方审计账本的运行时。

接入签名验证器

验证器本身不会验证签名。密码学功能通过注入提供，因此该包可以保持不依赖 EVM，并由你选择自己的库——但这意味着默认行为是有意设计的，切勿将其误认为强制验证：

• 未接入验证器时，验证器只检查格式。 它们会检查结构，并返回 ok: true，但不会检查任何签名。这适用于冒烟测试；不代表已获得授权。注入验证器之前，不要依据验证器结果来决定是否披露。
• 未验证的结果会通过以下三种标记之一明确说明。 如果某条路径在未检查签名的情况下返回 ok: true，就会在其 chainSummary 中追加标记；generateRegistryAttestation 会将其复制到回执的 authChainSummary 中，因此事后仍可区分冒烟测试运行与已验证披露。self 和 operator-self 会追加 /UNVERIFIED-shape-only；operator-for-downstream 则会分别报告两个部分：/operator-sig-unverified 和 /customer-sig-unverified。请使用导出的 chainSummaryIsUnverified() 进行审计，而不要手动匹配子字符串——针对大写标记进行区分大小写的子字符串测试只会匹配三种标记中的第一种，并会将完全未经验证的下游披露误判为已验证。
• 一旦接入任意验证器，无法覆盖的路径都会被拒绝。 接入这三个回调中的任何一个，就意味着当前是正式部署而非冒烟测试；此后，缺少自身验证器的路径会被拒绝，而不会作为仅检查格式的结果返回。在 self 路径中，调用方会提供 surface，并由 surface 选择验证器（web → verifyEip712，mcp → verifyMlDsa），因此只接入其中一个时，指定另一种 surface 的请求会被拒绝——否则调用方就可以选择你未接入验证器的 surface，从而完全跳过验证。operator-self 和 operator-for-downstream 的 operator 部分都同样要求 verifyMlDsa：如果只接入 verifyEip712，所有 operator 路径请求都会被拒绝，而不是在未经检查的情况下获得授权。 唯一有意保留的例外是 customer-grant 的 customer 部分：它会保留标记而非拒绝，因为 grant 可能通过带外方式进行身份验证——请参阅 verifyCustomerGrant；如果未定义它，请预期 chainSummary 中会出现 /customer-sig-unverified。
• 签署与本包验证时相同的字节。 导出 selfChallengeMessage、operatorSelfChallengeMessage、operatorDownstreamMessage 和 customerGrantMessage 正是为了此目的：每条路径都带有域标记，签署其他内容的签名将无法通过验证。

验证器请使用纯密码学库（EIP-712 使用 @noble/curves，FIPS 204 ML-DSA 使用 @noble/post-quantum）——该包本身不捆绑 EVM 工具。

const verifiers: AuthVerifiers = {
  verifyMlDsa: async (signature, message, publicKeyHash) => {
    /* your FIPS 204 verify over exactly `message` */
  },
};
const result = await validateAuthForKind("audit-export", auth, verifiers);
if (!result.ok) throw new Error(result.reason);
if (chainSummaryIsUnverified(result.chainSummary)) throw new Error("not actually verified");

安全

该服务采用一小组默认设置，避免配置错误导致 Authorization 标头在传输过程中泄露：

• 仅允许 HTTPS 端点，并在整个调用过程中保持这一要求。 SAIHM_ENDPOINT_URL 必须使用 https://。构造时会拒绝普通的 http://，但 127.0.0.1 和 localhost 除外（以便开发期间使用本地操作员端点）。由于此检查只涵盖配置的 URL，不会检查后续跳转，因此请求还会设置 redirect: 'error'——端点无法将调用及其请求正文重定向到从未经过验证的主机。
• 每次调用的中止时限。 每个请求都会在 AbortController 的控制下运行，并在 30s 后中止，避免端点无响应导致 MCP 服务无法处理其他请求。
• 响应大小上限。 上限为 16 MB，并通过两次检查强制执行。若 Content-Length 超过上限，会在读取正文前拒绝请求；此外，还会在正文流式传输时测量其大小，一旦超过上限便立即中止读取。因此，即使发送方未如实声明 Content-Length，或完全未声明，该上限仍然有效。
• 绝不回显标头。 Authorization 绝不会出现在抛出的错误消息或 stdout 中。
• 不从磁盘读取配置或用户数据。 配置完全通过环境变量传递，且绝不会写入磁盘。该软件包只会打开一个文件：启动时读取一次自身的 package.json，以使 serverInfo.version 与已发布版本一致（若无法读取，则回退为 0.0.0-dev）。任何凭证、单元格或用户数据路径都不会访问文件系统。
• 不使用任何 EVM 工具。 没有 ethers、没有 eth_*、没有 Solidity。如果操作员通过 AuthVerifiers 注入签名验证器，应使用纯加密库（@noble/curves、@noble/post-quantum）。

信任模型：此客户端信任操作员配置的任何端点。该端点返回的单元格 ID、审计锚点和报告回执会原样呈现给 Agent——对于通过 saihm_recall 显示的内容，操作员是权威来源。通过操作员的审计记录验证回执不在此服务的职责范围内；请使用 cellId 和 auditCellId 字段，并通过操作员自己的审计读取路径进行验证。

为确保分发完整性，每个发行版本都附带 npm registry 签名；请使用 npm audit signatures 验证（并检查 npm view @saihm/mcp-server --json | jq .dist）。

依赖项

已发布的 npm 软件包具有精简的运行时依赖：

依赖项	许可证	作用
Node.js (≥ 20.x)	MIT	运行时
@modelcontextprotocol/sdk	MIT	运行时；MCP SDK，绑定八个工具的接口
zod	MIT	运行时；验证工具输入和报告模板
@noble/hashes	MIT	运行时；仅用于内容摘要的 SHA-256——模板的 templateHash 和报告的 outputSha256。不会有任何密钥材料经过该库；参见 HARDENING.md §"Surface minimization"
TypeScript	Apache-2.0	仅构建时使用——运行 npm install @saihm/mcp-server 时不会安装
tsx	MIT	仅构建时使用；用于测试和 CLI 的 TypeScript 运行器

没有 copyleft 依赖，也没有专有依赖。操作员端点层的加密原语（ML-DSA-65 / Ed25519 / 密钥派生）不会打包进此 MCP 服务；建议实现协议栈的操作员使用 @noble/post-quantum 和 @noble/curves（MIT），而不是自行编写代码。

成就

• OpenSSF 最佳实践通过徽章 — 项目 12898，100% 满足通过 标准（2026-05-19）。https://www.bestpractices.dev/projects/12898
• IETF — draft-saihm-memory-protocol-01（2026-05-27）已提交至 独立提交流；2026-07-25，ISE 完成审议并将其移出队列（datatracker 流现为 None），并指示该工作转向 IETF 工作组活动（agentproto 工作）。 它不是互联网标准，不获 IETF 背书，在 IETF 标准流程中也没有正式 地位。-01 草案仍可在 datatracker 上获取，作为当前参考文本。 https://datatracker.ietf.org/doc/draft-saihm-memory-protocol/
• npm 注册表 — 从 0.3.6（2026-06-30）起的版本均通过 GitHub Actions 使用 OIDC 可信发布发布， 并附带 npm sigstore 来源证明；0.3.6–0.3.10 均包含此证明，而更早的十个版本 （0.1.0–0.3.5）由人工发布，不包含此证明 — 详见 HARDENING.md §“分发完整性”，其中也记录了没有签名的版本标签。 0.3.4（2026-06-22）新增了醒目的“存储由运营方负责（这是设计如此）”部分 — 说明 BYO 存储以及 Join-SAIHM 托管、非托管的选项。 0.3.3（2026-06-22）是一个文档版本，准确说明了独立提交状态 （不暗示 IETF 背书），并交叉引用了配套包 @saihm/client-pro。 0.3.2（2026-06-22）修正了 README 和客户端注释中记录的运营方端点路径， 将其改为 /mcp（规范的 SAIHM_ENDPOINT_URL 路径）。0.3.1（2026-05-28）是一个元数据补丁，将 MCP serverInfo.version 的来源改为 package.json（从 0.1.0 到 0.3.0 均硬编码为 "0.1.0"）。 0.3.0（同样发布于 2026-05-28）使 saihm_status 响应结构 与 draft-saihm-memory-protocol-01 §3.4 保持一致（完整的八字段 架构：prs、bfsi、bfsi_window_start_ts、bfsi_R、 bfsi_M、shards、contracts、governance）。0.2.0（同样发布于 2026-05-28）使单元元组响应结构与 §2.1 保持一致； OpenSSF 最佳实践通过徽章于 2026-05-19 获得，同时完善了治理和保障文件；这些 文件首次进入 npm 是在 0.2.0（2026-05-28），因为它们准备时对应的 0.1.3 版本从未发布。
• MCP Registry / Glama — 已列入服务目录以供发现（2026-05-16）。

路线图

项目在 AAIF 提案 中维护了一份为期 12 个月的路线图，并发布于 https://saihm.net/roadmap。近期工作方向：

• 2026-Q2（已结束 — 有一项差距延续至后续阶段） — OpenSSF Silver 目标工作中的治理、行为准则、DCO 签署、覆盖率工具和保障论证均已完成。版本标签签名 尚未完成；GOVERNANCE.md §“发布”和 HARDENING.md §“分发完整性”均将其记录为 未解决的差距，并将其纳入下文的 Silver 工作方向。
• 2026-Q3 — 首批 2–3 个外部组织部署；待采用方面的阻碍消除后，正式提交 AAIF 项目提案。
• 2026-Q4 — NIST AI RMF 对照表公开征求意见；EU AI Act 合规检查清单生成器。目标是获得 OpenSSF Silver 奖项。
• 2027-Q1 — v1.0 参考实现。规范的标准化路径仍开放：ISE 路径已于 2026-07-25 关闭， 计划是在有可引用的 IETF 工作组文件后，以其作为规范性参考。项目无法决定该文件的发布时间， 因此不会声称其发布日期。

支持

SAIHM 由一位独立创始人开发和维护。如果它对你或你的组织有所帮助，请考虑 赞助该项目 — 赞助资金将用于持续开展协议、客户端和开放标准相关工作，并维持这一开放的 参考实现。

License

Apache-2.0 — see LICENSE.

Project

• Site: https://saihm.net
• Issue tracker: https://github.com/SAIHM-Admin/saihm-mcp/issues
• Security: see SECURITY.md for private vulnerability disclosure
• Contributing: see CONTRIBUTING.md and CODE_OF_CONDUCT.md
• Governance: see GOVERNANCE.md
• Changelog: see CHANGELOG.md