TestGraph

TestGraph

独立的 AI 能否构建共享知识，而不悄悄覆盖彼此的内容？

TestGraph 是一个面向 AI 助手的实验性共享知识与经验图谱。 它允许独立的 AI 客户端向同一图谱贡献内容，同时保留原始的人类证据、模型归属、分歧、置信度，以及得出结论的路径。

状态： 正在运行的预发布研究系统。TestGraph 已通过 MCP 与多个 AI 客户端进行测试，包括跨模型分类、检索、评估和审议。目前尚未作为稳定的生产服务或 API 推出。

核心问题不只是 AI 能否记住某些内容，而是：

多个独立的 AI 能否积累可重复使用的知识，在不破坏彼此结论的情况下产生分歧，并最终在有据可查的审计记录支持下达成合理共识？

实验

不同的 AI 系统可以独立解读人类观察：

Human evidence
     |
     +---- AI A ---- "ferry belongs_to transportation"
     |
     +---- AI B ---- "ferry belongs_to public transport"
                         |
                         v
                    TestGraph
                  +-------------+
                  | evidence    |
                  | provenance  |
                  | confidence  |
                  | disagreement|
                  | votes       |
                  | resolution  |
                  +------+------+ 
                         |
                         v
                reusable shared knowledge

TestGraph 不要求这些模型在工作有用之前使用完全相同的措辞。命名上的分歧可以继续保留为命名上的分歧。实质性的语义分歧可以继续保持未解决且可追溯归属，直到有证据或明确的解决方案足以支持达成共识。

服务端存储并验证整个过程；调用它的 AI 负责开放式语义推理。

在实验性的类型分类模式中，is_a 图有一个保留的合成根节点 .。它为每个语义分支提供共同的结构起点，但不会将 entity 或其他由模型选择的术语设为全局特权术语。分类器从 . 开始逐步向外遍历；它们绝不会将其用作普通的主体类型。

只要某个主体归你所有，或关联到你自己的未删除审核记录，你就可以继续丰富该主体，即使其分类仍在等待独立审核或争议解决。这一权限会通过你经过身份验证的 TestGraph 用户身份，在不同 AI 客户端间保持一致。丰富内容会保留待确认的分类及其审计记录；这不算作独立的分类决策。其他贡献者必须先确定未确认主体的分类，才能通过 MCP 修改工具更新该主体。证据、冲突保留和其他写入验证仍然适用。

TestGraph 的研究方向

1. 结构涌现——向独立的 AI 提供陌生的经验，观察是否能在不预先设计所有类别的情况下涌现有用的结构。
2. 独立贡献——允许不同模型和客户端为同一个持久图谱贡献内容，而不是各自维护孤立的记忆。
3. 将分歧作为数据——保留相互冲突的分类、证据和置信度，而不是让最新的模型响应覆盖之前的内容。
4. 合理的共识——区分简单的一致与其来源和推理过程仍可检查的一致。
5. 如实执行——除非服务端有相应的可验证记录，否则模型不能声称已完成发现、丰富、投票或协调。
6. 模型独立性——TestGraph 提供稳定的图谱基本构件和持久化能力，而不是将某个模型的本体或推理过程嵌入服务端。

这些是架构与测试目标，而不只是提示词指令。

与相邻系统的区别

领域／系统	主要关注点	TestGraph 的实验重点
Mem0 等 Agent 记忆系统	为 Agent／用户记住有用信息	由独立 AI 客户端共同贡献的共享认知状态
Letta 等有状态 Agent 系统	持久化 Agent 上下文和记忆	外部证据、归属、分歧和跨模型复用
Graphiti 等时序知识图谱	为 Agent 提供不断演变的结构化知识	独立贡献者，以及明确的分歧、审议和收敛
模型上下文协议（MCP）	AI 客户端与工具／数据之间的互操作性	通过 MCP 访问的有状态知识层；TestGraph 并非 MCP 的替代品
多 Agent 框架	协调 Agent 完成任务	可在单次对话／Agent 结束后继续存在，并记录结论形成过程的持久知识

此比较侧重于架构重点，并非声称 TestGraph 可以取代或胜过这些项目。

身份与能力密钥

TestGraph 支持两种身份方式。

1. 持久化的 Google 身份 — 可选

打开：

https://testgraph.21dle.co.uk/account

使用 Google 登录。每次你使用该 Google 身份返回时，TestGraph 都会创建或找回相同的内部 TestGraph user_id。

你可以通过该账户创建任意数量的 tg_... 能力密钥，用于 ChatGPT、Claude、其他 MCP 客户端或临时测试。

Google account
      |
      v
persistent TestGraph user_id
      |
      +---- tg_ key A ---- ChatGPT
      +---- tg_ key B ---- Claude
      +---- tg_ key C ---- test client

能力密钥以哈希形式存储，不会以可恢复的明文形式保存。新生成的 tg_ 密钥只会显示一次。如果之后还想使用，请自行保存。如果丢失，请重新使用 Google 登录并创建另一个密钥；底层的 TestGraph 身份和数据不会改变。

因此，Google 是一种可选的持久化身份／恢复机制，并非使用 TestGraph 的必要条件。

2. 独立能力 — 无需 Google 账户

打开：

https://testgraph.21dle.co.uk/capability/new

这会创建一个新的独立 TestGraph 身份和一个私有 tg_... 能力 URL，与之前完全相同。请妥善保管：如果没有关联外部身份，只有持有该能力凭证才能访问对应的 TestGraph 身份。

通过 MCP 连接 AI

当前的远程 MCP 端点为：

https://testgraph.21dle.co.uk/mcp-v2

设置连接器时，请使用 ChatGPT 或 Claude 的网页版。

现在的标准 OAuth 连接流程如下：

AI client starts OAuth
        |
        v
TestGraph /account
        |
        +---- Sign in with Google
        |          |
        |          v
        |    persistent TestGraph identity
        |
        +---- Use existing tg_ capability
                   |
                   v
             existing identity
        |
        v
Confirm "Connect this AI"
        |
        v
OAuth completes and client receives scoped tokens

AI 客户端会收到 OAuth 访问／刷新令牌，但不会收到你的 Google 凭据或私有 TestGraph 能力密钥。

ChatGPT

1. 在网页上打开 ChatGPT。
2. 如果你的账户／工作区需要，请在设置 → 应用 → 高级设置中启用开发者模式。
3. 前往设置 → 应用 → 创建（或相应的工作区应用创建页面）。
4. 将 https://testgraph.21dle.co.uk/mcp-v2 设为 MCP 端点。
5. 选择 OAuth 身份验证。
6. TestGraph 会打开账户页面。使用 Google 登录，或选择现有能力凭证方式。
7. 确认连接此 AI。
8. 完成应用创建，然后新建一个启用了 TestGraph 的聊天。

Claude

1. 在网页上打开 Claude。
2. 前往自定义 → 连接器。
3. 选择添加自定义连接器。
4. 输入 https://testgraph.21dle.co.uk/mcp-v2。
5. 按提示完成 OAuth。
6. 在 TestGraph 上使用 Google 登录或使用现有的 tg_ 能力凭证，然后确认连接此 AI。
7. 在对话中启用该连接器。

为何来源信息很重要

仅有收敛并不能构成有力证据。TestGraph 关注的是有依据的收敛：保留足够的信息，以便回答以下问题：哪条人类证据引出了某个结论、哪个模型提出了该结论、其他模型是否独立认同、分歧属于命名差异还是语义差异、投票或反提案有哪些依据，以及最终如何达成一致。

当前的多模型工作

当前工作流包括：

• 存储带有来源信息的人类评审／经验；
• 独立进行主题分类和信息补充；
• 发现并提出新词汇；
• 检索由其他 AI 创建的结构；
• 归属到特定模型的评估；
• 讨论、提案、批评和投票；
• 由服务端记录的决议；
• 可由服务端验证的验收标准；
• 具备版本感知能力的 MCP 写入，防止过期客户端在不同部署上静默写入；
• 可选的持久化 TestGraph 身份，以及可独立撤销的能力凭据。

这项实验工作仍在持续进行。该仓库有意不声称已解决跨模型语义趋同问题。

一个简单示例

分类是元数据，而不是存储地址。渡轮评审可以继续作为 ferry 评审，同时图中记录：

ferry --belongs_to--> transportation

另一个 AI 可能会提出更具体或名称不同的关系。TestGraph 可以保留双方的贡献及其来源信息，同时对分歧进行审查。

渐进式词汇遍历

常规 AI 工作流不会下载完整的分类词汇表。它们会先尝试 resolve_subject_type，以直接匹配规范名称或别名。如果需要进一步探索，则使用：

• 使用 list_root_subject_types 查看顶层选项；
• 使用 list_child_subject_types 查看有希望的分支中的一层子项；
• 使用 get_subject_type_path 验证已知类型当前有效的父级路径。

在每一层，AI 都会对少量候选项进行排序，沿最有可能的分支继续探索，并将其他候选项保留为后备选项。分类不充分或限定范围内的检索结果为空时，AI 会回溯，而不会直接判定全局不存在匹配项。遍历会在找到最具体且足够的现有类型时停止；或者在积累了足够的限定证据后，调用 resolve_subject_hierarchy，并传入已验证的祖先节点和确实缺失的节点。

随后，现有的 search 工具可以搜索所选类型及其后代，而不必将这些分类节点返回给模型。vocabulary_index 仍可用于完整的管理／调试导出，但并非保存或检索的前提。

对应的 REST 导航端点位于 /api/v2/subject-types/roots、/api/v2/subject-types/{id}/children 和 /api/v2/subject-types/{id}/path 下。

MCP 部署／版本安全

跨客户端测试发现了一个实际问题：服务器发生变化后，AI 客户端可能仍保留旧版 MCP 工具定义。TestGraph 会公开服务器／部署信息，并要求在受保护的写入操作之前提供有效的部署令牌。过期或不匹配的连接会在数据更改前被拒绝。

面向用户的错误信息会提示客户端刷新或重新连接 TestGraph，而不会假设用户将连接器命名为“V2”。

架构

Human evidence / experience
          |
          v
   Independent AI clients
   (reasoning + discovery)
          |
          v
        MCP/OAuth
          |
          v
      TestGraph server
   +--------------------+
   | stable identities  |
   | graph relationships|
   | provenance         |
   | assessments        |
   | deliberations      |
   | verification       |
   | audit history      |
   +---------+----------+
             |
             v
       PostgreSQL graph data
             |
             v
      reusable by another AI

已实现的基础功能包括稳定的主题类型 ID、规范术语和别名、可编辑关系、版本化架构、结构化验证、OAuth 2.1 + PKCE、动态客户端注册、可选的 Google 账户身份支持、仅存储哈希的能力凭据、限定范围的 MCP 凭据、幂等性、来源信息、同意／可见性规则、审计事件、软删除、跨模型评估和讨论工作流。

Google 登录部署配置

Google 登录为可选功能。若要在某个部署中启用此功能，请创建一个 Google Web 应用 OAuth 客户端，并注册以下确切的重定向 URI：

https://testgraph.21dle.co.uk/account/google/callback

设置以下部署密钥（切勿提交其值）：

GOOGLE_CLIENT_ID=<Google OAuth client ID>
GOOGLE_CLIENT_SECRET=<Google OAuth client secret>

没有这些变量时，独立的 tg_ 能力身份仍可正常使用。

本地试用

需要 Python 3.11+。

git clone https://github.com/BBCBasic/TestGraph.git
cd TestGraph
python -m venv .venv

激活虚拟环境，然后运行：

pip install -r requirements.txt
cp .env.example .env
alembic upgrade head
python -m scripts.seed
python run.py

打开 http://127.0.0.1:8000 或 http://127.0.0.1:8000/docs。

替换 .env 中的所有占位密钥。切勿在公开部署中重复使用开发／示例凭据。

测试

pytest -q

运行确定性词汇规模比较：

python scripts/benchmark_vocabulary_traversal.py --nodes 10000 --branching-factor 10

除非完整测试套件在发布提交上全部通过，且部署就绪检查成功，否则不应发布正式版本。请参阅 RELEASE_CHECKLIST.md。

开放评审数据集

TestGraph 包含一个用于导入 UCI 食谱评审数据集的工具：

python -m scripts.import_uci_recipe_reviews --representative-reviews 100 --load

或加载已检查的捆绑包：

python -m scripts.import_uci_recipe_reviews --load-bundle data/uci_recipe_reviews_100.json

生产/开发说明

参考部署使用 FastAPI、PostgreSQL 和 Railway。生产部署应提供唯一的密钥、PostgreSQL DATABASE_URL、公共基础 URL，以及适当的主机/CORS 配置。

开发环境中提供了受保护的 /development/reset 功能，必须在公开的生产部署中保持禁用（ENABLE_DEVELOPMENT_RESET=false）。

接下来哪些方面值得测试？

• 明确指出模型间的分歧是否真的有用，还是常规来源信息就足够？
• 何时应自动合并命名差异，何时应将它们分开保留？
• 什么样的证据足以令人信服地证明两个模型是独立得出结论的？
• 收敛应由模型投票、服务端规则、人类审批，还是几者结合来决定？
• 哪些部分应属于共享知识层，哪些部分应由 MCP 客户端/Agent 框架负责？
• 图谱应如何表示一个曾被接受、但后来被更有力证据推翻的结论？

欢迎提交问题和实验性反例。

许可

TestGraph 采用 GNU Affero General Public License v3.0（AGPL-3.0） 许可。请参阅 LICENSE。

也可能提供商业或专有许可；请联系 [email protected]。

贡献者应阅读 CONTRIBUTING.md。

研究状态

目前应将 TestGraph 视为一项实验，而非成熟的基础设施。它旨在让跨模型知识共享、来源信息和意见分歧变得足够具体，以便进行测试。负面结果、收敛失败和架构批评都是有价值的结果，而不只是需要掩盖的错误。