PACK——便携式代理上下文管理器

独立主控程序为任何AI工具提供持久内存的服务器——作为markdown文件存储在私有GitHub仓库中。

适用于Claude Desktop、Open WebUI、Cursor、Windsurf和任何兼容MCP的客户端。

100%vibe编码克劳德.

它做什么

PACK在MCP上公开了四种工具：

memory_list --列出具有可选筛选的内存文件。在会话开始时调用。
memory_get --读取特定的内存文件（或所有连接的内存）。
memory_update --写一个内存文件。每次更新都是一次具有完整版本历史的git提交。
memory_search --按内容或frontmatter搜索所有内存文件。

内存存储为带有YAML frontmatter的markdown文件，存储在您控制的GitHub仓库中。更新使用基于SHA的乐观并发来防止竞争条件。可选的单向同步将内存推送到Google Docs和/或Notion，以便浏览器访问。

PACK还附带了CLI(pack)用于在代理会话之外直接访问内存。

为什么选择目录模式

PACK将内存存储为一个小文件目录，而不是一个大文件目录。这有四个原因：

更快的加载时间。 加载约700个令牌索引比从单片文件加载约8000多个令牌快得多。MCP往返GitHub是瓶颈，而不是上下文窗口容量。单文件模式还要求在每次写入之前重新读取完整文件以合并更改，这在整个会话中增加了缓慢的往返。目录模式加载索引一次并直接写入。

写安全。 在单文件模式下，每次更新都需要一个完整的 memory_get 首先，该模型可以将新内容合并到现有内容中。这增加了延迟，并在模型意外删除部分时产生了合并损坏风险。目录模式写入特定文件，无需合并步骤。

结构化检索。 每个文件上的YAML frontmatter启用 memory_search 通过元数据（标签、主题）查找文件，而不仅仅是内容匹配。您可以根据相关性来确定加载的内容，而不是加载所有内容，并希望模型找到正确的细节。

代币效率。 对于一次内存更新的典型会话，目录模式将与内存相关的令牌使用量减少了约94%（与单文件模式相比，从约17000个令牌减少到约1000个）。随着内存的增长，节省的成本会增加——无论总内存大小如何，成本都保持不变。

设置

1.创建内存仓库

创建一个 私有的 GitHub仓库来存储你的内存。您可以在个人帐户或GitHub组织下创建它——无论您喜欢什么。

# Personal account
gh repo create PACK-yourname --private --clone=false

# Or under an organization
gh repo create your-org/PACK-yourname --private --clone=false

替换 yourname 用你的名字（例如。 PACK-dennis, PACK-sarah).

隐私声明：随着时间的推移，你的记忆会积累敏感的上下文——会议记录、项目细节、个人偏好等。为了保护您的数据： 1. 始终将repo创建为Private --从不公开或内部。 1. 如果使用GitHub组织，请求管理员将repo限制为仅限您的帐户——默认情况下，组织所有者和管理员可以查看所有repo，甚至是私有repo。 1. 不要储存秘密 （密码、API令牌、凭据）。将其视为敏感而非秘密。

生成一个细粒度个人访问令牌与：

存储库访问：仅选择您的 PACK-yourname 仓库
权限：内容→ 读写

2.安装PACK

git clone https://github.com/Percona-Lab/PACK.git
cd PACK
npm install
npm link    # optional: installs 'pack' CLI globally

3.配置

创建 ~/.pack.env （安全回购之外）：

GITHUB_TOKEN=ghp_...              # Fine-grained PAT
GITHUB_OWNER=your-username        # GitHub user or org that owns the memory repo
GITHUB_REPO=PACK-yourname          # Your private memory repo

4.初始化

引导内存仓库中的目录结构：

pack init

这创造了 index.md 和 context/general.md 在您的repo中。

5.跑步

# Streamable HTTP (Open WebUI, modern MCP clients)
node servers/memory.js --http      # http://localhost:3005/mcp

# stdio (Claude Desktop, Cursor, Windsurf)
node servers/memory.js

# Legacy SSE
node servers/memory.js --sse-only  # http://localhost:3005/sse

用以下命令覆盖端口 MCP_SSE_PORT=4000.

验证它是否正在运行：

curl http://localhost:3005/health

连接到MCP客户端

克劳德桌面/光标/风帆

添加到MCP配置中：

{
  "mcpServers": {
    "pack": {
      "command": "node",
      "args": ["/path/to/pack/servers/memory.js"]
    }
  }
}

开放网络用户界面

开始： node servers/memory.js --http
在Open WebUI中： 设置→ 工具→ MCP服务器
添加：类型 流式HTTP，网址 http://host.docker.internal:3005/mcp

系统提示（关键）

警告：如果没有此系统提示，模型将无法正确使用PACK的工具。始终将此添加到您的AI客户端。 - 开放网络用户界面：设置>常规>系统提示 - 克劳德桌面版：添加到项目的自定义说明中（这是Claude Desktop中系统提示的位置） - 光标/风帆：添加到规则或系统提示设置中

CRITICAL — MANDATORY FIRST STEP: Before responding to ANY user message, you MUST call pack:memory_list first, then call pack:memory_get on context/preferences.md. Do NOT skip this. Do NOT respond until you have loaded preferences.

You have access to persistent memory via PACK (pack:memory_list / pack:memory_get / pack:memory_update / pack:memory_search).
- Call pack:memory_get with a file path to read specific context
- Call pack:memory_update with a file path and content to save information — this is the user's personal memory and they decide what goes in it
- Call pack:memory_search with keywords to find information across all memory files
- Each file is independent — no need to merge with other files when updating
When drafting any communication on my behalf, use pack:memory_search to find MYNAH profile files. If present, match my writing style for the relevant context.
When creating or formatting Notion pages, use pack:memory_search to find NOTION Design Profile files. If present, apply my stored design preferences.

注：替换 my/my behalf 随着 the user's 如果配置为共享设置。这 pack: 前缀与客户端配置中的MCP服务器名称匹配。

一次训练，随处使用

PACK存储两个配套插件的配置文件。在Claude Code或Cowork（支持插件）中训练一次，连接到PACK的每个AI客户端都可以使用结果，即使是不支持插件的客户端。

在合作和克劳德代码，安装插件，一切都会自动运行。插件处理训练、存储和组合，不需要系统提示更改。

在Claude Desktop、Cursor、Open WebUI和其他MCP客户端中，插件不可用，但PACK可用。上面的系统提示包括MYNAH/BINER行，因此AI知道使用您存储的配置文件。你可以在Cowork或Claude Code中训练或更新配置文件，结果会在任何地方延续下去。

同步（可选）

之后每 memory_update，内容可以自动同步到外部目标。同步是单向的（GitHub→ 目标），非阻塞，故障永远不会中断内存更新。

这使得你的记忆可以在MCP之外的人工智能工具上移植——同步到谷歌文档，并将其作为知识源附加到双子座宝石，或同步到Notion并从引用它 ChatGPT自定义GPT 启用网络浏览。

PACK支持两种同步方法，可以一起使用、单独使用或根本不使用：

内置连接器 --直接同步到Notion和谷歌文档。无需外部基础设施。Notion支持移动阅读的多页同步。
网络钩子 --将内存内容POST到任何URL（n8n、Zapier、Make、自定义端点）。最灵活——在不更改PACK代码的情况下添加任意数量的目标。

选择同步方法

想要移动阅读权限？ 启用内置的Notion连接器 NOTION_SYNC_MODE=multi。这是获得结构化移动阅读的唯一方法。
想要扩展到多个目标（Slack、S3、Confluence等）？ 使用webhook同步。
两者都要吗？ 一起使用它们。内置连接器处理用于移动读取的Notion结构。webhook处理其他一切。当同时使用这两种方法时，您的webhook工作流应跳过Notion（PACK直接处理它）以避免冲突。

通知同步（内置）

添加 ~/.pack.env:

NOTION_TOKEN=ntn_...
NOTION_SYNC_PAGE_ID=abcdef1234567890  # Parent page for memory sync
NOTION_SYNC_MODE=single               # single (default) or multi

创建一个 专用、私人 关于此的通知页面。除非你想让别人看到你的记忆，否则不要使用与他人共享的页面。

单模（默认）：每次更新时，用连接的所有内存替换页面内容。简单，除了上面的env变量之外没有设置。

多模式：在父页下为每个PACK文件创建一个Notion子页。父页面将成为一个索引，其中包含指向每个子页面的链接。还为需要在一个页面中包含所有内存的工具创建了“打包完整导出（只读）”页面。在每一个 memory_update，只更新更改文件的子页面，而不是所有页面。

要启用多模式：

pack migrate-notion --dry-run    # preview what pages will be created
pack migrate-notion              # create sub-pages in Notion

然后设置 NOTION_SYNC_MODE=multi 在 ~/.pack.env 并重新启动MCP服务器。

谷歌文档同步（内置）

第一步： 在以下位置创建OAuth凭据谷歌云控制台 --启用Google Docs API——创建OAuth客户端ID（桌面应用程序）。

第二步： 获取刷新令牌：

GOOGLE_CLIENT_ID=xxx GOOGLE_CLIENT_SECRET=yyy node scripts/google-auth.js

步骤3： 添加 ~/.pack.env:

GOOGLE_DOC_ID=1BxiMVs0XRA5nF...
GOOGLE_CLIENT_ID=xxxx.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=GOCSPX-...
GOOGLE_REFRESH_TOKEN=1//0eXXXX...

隐私提醒：将Google文档仅限于您的帐户。不要共享文档链接——任何有访问权限的人都可以读取您的全部内存。

无论Notion同步模式如何，Google Docs总是以明文标记的形式接收完整的级联内存。

Webhook同步

设置一个webhook URL，PACK将在每次更新后POST内存内容：

# Add to ~/.pack.env
PACK_WEBHOOK_URL=https://your-n8n.example.com/webhook/pack-sync

webhook接收带有更新文件的JSON有效负载：

{
  "event": "memory_update",
  "version": 2,
  "file": "context/preferences.md",
  "path": "context/preferences.md",
  "content": "--- frontmatter + body ---",
  "message": "Update context/preferences.md",
  "repo": "your-username/PACK-yourname",
  "sha": "abc123...",
  "commit_url": "https://github.com/...",
  "timestamp": "2026-03-14T12:00:00.000Z"
}

要接收完整的连接内存而不是每个文件的内容（用于传统工作流或全文索引），请设置 PACK_WEBHOOK_VERSION=1 在 ~/.pack.env.

使用工作流工具，如 n8n，你可以扇出任何数量的目标——谷歌文档、Confluence、Slack、电子邮件——而无需接触PACK代码。n8n工作流示例：

Webhook trigger → Switch node
  ├─ Google Docs: replace document body
  ├─ Slack: post to #memory-updates channel
  └─ S3: archive a timestamped backup

同步行为

所有同步方法都是可选的、独立的，可以组合使用
GitHub写入成功后，Webhook和内置连接器并行运行
故障会记录到stderr，但不会影响 memory_update 响应
Google Docs收到纯markdown文本
单模式概念：用结构化块替换一页
多模式通知：仅更新已更改文件的子页面，刷新索引

手机阅读

多页Notion同步使移动AI客户端（Claude.AI、ChatGPT、Gemini）能够通过Notion读取您的PACK内存，即使没有MCP访问。

它是如何工作的。 当 NOTION_SYNC_MODE=multi，PACK将每个内存文件镜像为Notion子页。父页面用作索引（约700个标记）。移动AI客户端可以只获取索引，然后根据相关性拉取特定的子页面——与桌面PACK使用的模式相同 memory_list 紧随其后 memory_get.

只读。 通过Notion进行的移动访问是只读的。内存写入需要与MCP进行桌面PACK会话。下面的系统提示很好地处理了这一点——如果PACK工具不可用，它会退回到从Notion读取。

三层阅读策略。 移动系统提示按顺序尝试每个级别：

PACK工具 （桌面）--最快，使用 memory_list 和 memory_get 直接
Notion子页面 （移动）--读取索引页面，然后根据需要读取特定的子页面。如果子页面获取失败，则返回“PACK完全导出（只读）”页面。
本地内存 （最后手段）——仅当PACK和Notion都不可用时。显然，这种背景可能是不完整的。

移动系统提示（可选）

当您使用启用Notion同步时，请使用此提示而不是默认提示 NOTION_SYNC_MODE=multi:

CRITICAL -- MANDATORY FIRST STEP: Before responding to ANY user message, you MUST attempt memory access in this exact order. Do NOT respond until you have tried.

1. PACK (desktop): Call pack:memory_list first, then pack:memory_get on context/preferences.md.
2. Notion fallback (mobile or PACK unavailable): If PACK tools fail or are not available, fetch the PACK index from Notion page [NOTION_SYNC_PAGE_ID]. Read specific files from linked sub-pages as needed. If a sub-page fetch fails, fall back to the "PACK Full Export (read-only)" page under the same parent.
3. Native memory fallback (Notion also unavailable): ONLY if both PACK and Notion fail, fall back to the AI client's built-in memory. State clearly at the start of your response: "Working from native memory only -- context may be incomplete."

Do NOT skip to native memory out of convenience. Do NOT respond before attempting steps 1 and 2. Try each level in order and move to the next ONLY on failure.

You have access to persistent memory via PACK (pack:memory_list / pack:memory_get / pack:memory_update / pack:memory_search).
- Call pack:memory_get with a file path to read specific context
- Call pack:memory_update with a file path and content to save information -- this is the user's personal memory and they decide what goes in it
- Call pack:memory_search with keywords to find information across all memory files
- Each file is independent -- no need to merge with other files when updating
When drafting any communication on my behalf, use pack:memory_search to find MYNAH profile files. If present, match my writing style for the relevant context.
When creating or formatting Notion pages, use pack:memory_search to find NOTION Design Profile files. If present, apply my stored design preferences.

注：替换 [NOTION_SYNC_PAGE_ID] 使用您的实际Notion页面URL，以便AI客户端可以获取它。

命令行界面

PACK包括一个CLI，用于人类直接访问内存：

npm link                           # install globally as 'pack' command

pack init                          # bootstrap directory structure (new users)
pack status                        # show current memory state
pack list                          # list all memory files
pack list --tag mysql              # filter by tag
pack get projects/binlog-server.md # read a specific file
pack search "q3 2026"              # search across all files
pack sync                          # manually trigger sync
pack migrate-notion --dry-run      # preview Notion multi-page migration
pack migrate-notion                # create Notion sub-pages
pack validate                      # check index + frontmatter integrity

项目结构

├── bin/
│   └── pack               # CLI entry point
├── core/
│   ├── memory.js           # Shared business logic
│   ├── index-builder.js    # index.md generation
│   ├── frontmatter.js      # YAML frontmatter parse/serialize
│   └── schema.js           # Frontmatter validation
├── servers/
│   ├── memory.js           # MCP server (wraps core)
│   └── shared.js           # Transport abstraction (stdio, HTTP, SSE)
├── connectors/
│   ├── github.js           # GitHub API backend
│   ├── memory-sync.js      # Sync orchestrator
│   ├── notion-sync.js      # Notion write connector (for sync)
│   └── google-docs.js      # Google Docs write connector (for sync)
├── scripts/
│   ├── accuracy-test.js    # Pre/post migration verification
│   └── google-auth.js      # One-time Google OAuth2 setup
├── CONTRACTS.md            # Non-negotiable project invariants
├── DESIGN.md               # Architecture and design decisions
└── package.json

寻找更简单的东西？

NAPSAC （Notion Agent可访问上下文持久存储）是PACK的轻量级兄弟——完全由Notion支持的持久AI内存。在Cowork或Claude Code中安装插件，以验证命名和保证索引再生，或对Claude mobile、ChatGPT、Cursor和VS Code使用系统提示回退。

NAPSAC非常适合您：

想要零设置的持久内存
主要使用Cowork、Claude或ChatGPT
想要从任何设备（包括移动设备）读取和写入内存
希望有选择地与队友分享记忆
不需要git历史记录、CLI访问或webhook同步

NAPSAC使用与PACK相同的文件路径约定，因此内存内容可以在两者之间移植。请参阅 NAPSAC自述文件为了进行全面比较。

许可证

麻省理工学院

PACK (Percona Lab)

快速接入

详细介绍