# Paged Context Protocol

一个模型无关、由用户拥有的上下文存储协议：以持久、可寻址的 Page 连接跨会话与跨项目历史，让授权模型通过普通工具自行搜索、读取、修订和关联。

## Metadata

- HTML: https://glenzli.com/projects/paged-context-protocol/
- Markdown: https://glenzli.com/projects/paged-context-protocol.md
- Collection: Projects
- Language: zh-CN
- Published: 2026-07-15
- Status: active
- Tags: llm-context, protocol, memory, model-agnostic, context-engineering

## Content

Paged Context Protocol，简称 PCP，是一套面向模型、由用户拥有的逻辑上下文存储协议。它解决的不是模型如何管理眼前的上下文窗口，而是模型如何访问窗口之外的历史：旧会话、其他项目、任务分支，以及尚未写进当前仓库的想法。

当前的 `v0.4.0-draft` 将 PCP 明确收缩为上下文 backing store。协议定义持久 Page 的身份、版本、作用域、来源、关系和基本读写语义；至于何时搜索、选择 grep 还是语义检索、怎样压缩当前窗口，都交给模型或 Harness 自己决定。

## 项目入口

  ![Paged Context Protocol 将跨会话与跨项目历史组织为持久 Page 空间](/images/projects/paged-context-protocol-banner.png)

## 核心原则

    **模型管理当前上下文**
    阅读顺序、working set、搜索计划、摘要和压缩策略属于模型或 Harness，不进入协议状态机。

    **用户拥有长期上下文**
    历史不绑定在单一模型、服务商、会话或项目目录中，经过授权的不同模型可以访问同一逻辑空间。

    **Page 保持稳定身份**
    `page_id` 跨时间标识同一逻辑对象，`revision_id` 标识不可变版本；进入或离开模型窗口不改变身份。

    **原始历史可以恢复**
    摘要、索引和模型笔记属于可重建的派生层，不能静默覆盖唯一的原始来源。

PCP 使用统一的逻辑地址空间，但不做全局注入。每次搜索都必须落在明确的 Scope 和权限范围内；跨项目内容即使语义上高度相关，也不能绕过授权进入候选结果。

## 协议边界

| 组成 | 负责什么 |
| --- | --- |
| PCP Core | 约束 Page、Revision、Scope、Provenance、Relation 及其读写和生命周期语义。 |
| Model Client | 自行决定何时搜索、读取、写入、修订或关联 Page，以及采用什么搜索顺序。 |
| Host | 连接聊天、项目、工具与 Store，负责认证、授权、Scope 选择、预算和结果注入。 |
| PCP Store | 持久化 Page、Revision、Relation、原始事件和索引，后端可以是文件、SQLite、数据库或搜索系统。 |
| Adapter | 将仓库、文件、消息或其他 Memory 映射为 Page，同时保留稳定来源。 |

这是一套语义协议，不是特定传输协议。实现可以暴露 MCP tools、HTTP、JSON-RPC、CLI、本地函数或文件系统视图，只要不同入口仍指向同一组 Page 与 Revision。

## 最小数据模型

| 对象 | 含义 |
| --- | --- |
| `Page` | 可以被模型独立寻址和组合的最小持久逻辑对象，不等于固定 Token 块，也不强制包含摘要。 |
| `Revision` | Page 的不可变版本；修订必须生成新的 `revision_id`，并可用 `expected_revision_id` 检测并发冲突。 |
| `Scope` | 由 `owner_id`、`namespace` 和 `visibility` 构成的访问边界。 |
| `Provenance` | 记录内容由谁、通过什么操作和哪些输入版本进入 Store；证明来源链，但不自动证明内容为真。 |
| `Relation` | Revision 之间有类型、有方向的关系，例如 `depends_on`、`contradicts`、`supersedes` 或 `derived_from`。 |
| `Facets` | 可选的摘要、关键词、锚点和符号等读取或索引辅助，不替代原始证据。 |

一个最小 Page Revision 可以写成：

```json
{
  "page_id": "pg_01...",
  "revision_id": "rev_01...",
  "owner_id": "user_01...",
  "namespace": "project:formal-math",
  "visibility": "private",
  "lifecycle_status": "active",
  "created_at": "2026-07-15T20:00:00+08:00",
  "created_by": {
    "actor_type": "system",
    "actor_id": "continuity_host"
  },
  "payload": {
    "media_type": "text/markdown",
    "content": "此前对有限乘积紧致性的证明讨论……"
  },
  "source_refs": ["conversation:2026-05-14#message-32"],
  "provenance": [
    {
      "operation": "ingest",
      "actor_type": "system",
      "actor_id": "continuity_host",
      "timestamp": "2026-07-15T20:00:00+08:00",
      "input_revision_ids": []
    }
  ]
}
```

`payload` 可以保存正文，也可以只保存对大文件或对象存储的稳定引用。协议不封闭内容类型；对话、代码、图片、决定、失败路线、开放问题和模型整理出的索引，都可以成为 Page。

## Core 接口

      **发现与读取**
      先发现 Store 和 Scope，再搜索候选 Page，并按需要读取正文、来源、关系或版本历史。

```text
DescribeCapabilities
ListScopes
SearchPages
ReadPages(manifest | payload | source_spans | relations | facets | history)
```

这些接口不是固定管线。模型可以先查符号、先看时间、遍历关系，或者并行组合全文与语义检索。

      **写入、修订与关联**
      新内容获得稳定 Page 身份；修改产生新 Revision，关系保留明确的来源端点和创建者。

```text
WritePage(payload, scope, provenance, idempotency_key)
RevisePage(page_id, expected_revision_id, payload)
LinkPages(from_revision_id, relation_type, to_revision_id)
```

Store 不原地覆盖已发布 Revision。摘要、合并和重组也必须产生新的派生 Page、Revision 或 Relation。

      **事件与生命周期**
      Host 可以摄入原始消息和工具事件；临时排除、归档、撤回和物理删除保持不同语义。

```text
IngestEvent
SuppressPages
TombstonePage
DeletePage
```

`SuppressPages` 只影响当前任务或查询；`TombstonePage` 保留审计关系；不可恢复删除必须受用户权限和保留策略控制。

## 一次跨项目查找

下面是一种合法调用方式，不是 PCP 规定的固定流程。模型可以先列出可访问的 Scope，再在授权范围内搜索：

```json
{
  "query": "此前是否讨论过有限乘积保持紧致性的证明路线？",
  "scopes": ["project:formal-math", "user:user_01"],
  "mode": "auto",
  "filters": {
    "relation_types": ["depends_on", "inspired_by"],
    "lifecycle_status": ["active", "superseded"]
  },
  "limit": 20
}
```

Search 结果返回 Page 与 Revision 身份、原始 Scope、匹配通道、可用 facets 和后续读取能力。模型随后可以读取正文、指定来源范围或关系图，而不是接收一段来源已经消失的拼接文本。

## v0.4 移除了什么

`v0.4.0-draft` 与旧 `v0.3.0-alpha` 不向后兼容。重构保留 Page 的稳定身份、按需访问和来源可追溯性，同时撤掉对模型运行方式的规定。

| v0.3.0-alpha | v0.4.0-draft |
| --- | --- |
| Router、Worker、Consolidator、Auditor 四处理器 | Model Client、Host、Store、Adapter 的逻辑边界，不规定部署拓扑 |
| Intent Focus 和固定路由阶段 | 普通 `SearchPages` query，由模型自行拆解和组合 |
| `Summary -> Detail -> Unpacked` 变焦状态机 | 可选 Facets、一次性 Read Projection 和 Relation traversal |
| `Consult / Explore / Shelve / Purge` | 普通 Search、Read、Harness working-set 管理和独立生命周期操作 |
| 单独的 P-Mem Profile | 持久 Page Store 直接成为 PCP Core |
| 单轴 `trust` | 分离 authority、integrity、epistemic status、sensitivity 和 instruction policy |

旧版本没有被删除，而是作为设计记录保存在 `deprecated/v0.3.0-alpha/`。它说明了为什么曾经需要细致的运行时脚手架，也说明了这些流程在模型能够自行管理上下文后为何退出 Core。

## 权限与来源

PCP 要求权限先于相关性：未授权内容不能因为搜索分数高而被返回。跨 Scope 召回必须显式发生，结果也必须携带原始 Scope。

外部材料、历史对话和模型派生 Page 默认都是数据，不会因为进入 Store 就自动获得指令权限。来源完整性、事实状态、敏感级别和指令资格是不同问题，不能再压成一个“可信”标签。用户则必须能够查看、导出、限制和删除自己的长期上下文。

## 当前状态

PCP 目前是 `v0.4.0-draft` 协议草案，不是已经发布的 SDK 或托管服务。当前工作集中在最小 Core 与接口边界；具体实现、跨模型行为，以及百万级高密度上下文上的一致性与效果仍需评测。

这个页面描述的是协议能力与设计取舍，不构成性能声明。

## 文档入口

| 文档 | 内容 |
| --- | --- |
| `README.md` | 中英文项目概览、核心原则、非目标和当前状态。 |
| `PROTOCOL.md` | `v0.4.0-draft` 中文规范，覆盖数据模型、Core 接口、生命周期、权限与一致性要求。 |
| `PROTOCOL-en.md` | 当前英文协议规范。 |
| `deprecated/README.md` | 历史协议索引。 |
| `deprecated/v0.3.0-alpha/README.md` | v0.3 的淘汰原因、仍然有效的贡献和概念迁移表。 |