AI Agent 总在混乱的上下文里重建真相？Cruxible 用可验证的状态层让知识沉淀下来

你的 AI 编码 Agent 每次打开新会话，都要从头理解项目的上下文。它读取 README、扫描代码库、推理依赖关系——然后生成答案。问题是：下一次会话，它还要重新做一遍。同样的查询、同样的代码库、同样的架构决策，每次都要重新「猜」一次。如果两个 Agent 窗口同时工作，它们甚至可能对同一个问题给出不同的回答。

这不是模型能力的问题，而是状态管理的问题。Markdown、RAG、向量记忆——这些手段让 Agent 能读取文本，但无法确保它读到的内容是经过验证的、一致的、可追溯的。每次新会话，模型都在重建「真相」，而重建的结果随模型版本、上下文窗口、甚至 prompt 的微小变化而漂移。

Cruxible 用完全不同的方式解决这个问题：它不是一个上下文工程工具，而是一个可验证的状态层——Agent 和人类共同操作的、类型化的、经过治理的知识图谱。所有声明都有来源、有审查记录、有可重现的收据。Apache-2.0 开源，pip install cruxible 即可开始使用。

问题：Markdown 和 RAG 无法保证「真相一致」

先看一个典型的 Agent 工作流：你让 Claude Code 分析某个安全漏洞的影响范围。它会读取你的文档、搜索代码中的关联引用、推理哪些组件受到影响。结果看起来合理——但你无法确认它是否遗漏了什么。

这不是因为模型不聪明。Markdown 和 RAG 的本质问题是：它们返回的是「相似的文本」，而不是「精确的答案」。Claim 就是文本，没有来源标注，没有审查状态。任何人都可以编辑，没有任何机制阻止一个编辑删除了关键证据。检索返回相似的块，但无法执行精确的多跳关联查询。每次读取都是全新的重建，两次结果可能不一致。

Cruxible 的答案很直接：不要优化上下文，而是建模领域。把那些反复出现、共享使用、一旦出错代价高昂的知识，从文本变成类型化的、受治理的状态。

Cruxible 的核心架构

Cruxible 是一个 Python 库（pip install cruxible），核心是一个确定性的状态引擎。它不调用 LLM，没有隐藏的 API 调用——所有状态写入和查询都是确定性的。

它的核心概念非常清晰：

1. 实体和关系：你在 YAML 配置中定义领域的实体类型和关系类型，就像写 Terraform 配置一样
2. 受治理的写入：关系可以被标记为「受治理」——不能直接写入，必须通过提案→审查→批准流程
3. 确定性工作流：工作流编排读取、转换和写入，每一步都产生可验证的收据
4. MCP 工具：通过 FastMCP 暴露给任何 AI 编码 Agent（Claude Code、Cursor、Codex 等）

配置文件的样例如下：

entity_types:
  Supplier:
    properties:
      supplier_id: { type: string, primary_key: true }
      name: { type: string, indexed: true }
  Incident:
    properties:
      incident_id: { type: string, primary_key: true }
      title: { type: string, indexed: true }
      severity: { type: string, optional: true }

relationships:
  - name: incident_impacts_supplier
    from: Incident
    to: Supplier

两种写入模式：硬事实 vs 判断

Cruxible 区分两种状态写入方式，它们受到完全不同的对待：

这意味着：你能确定地从 CSV 导入供应商列表和组件清单（直接写入），但「这个安全事件影响了哪些供应商」是一个判断——Cruxible 不允许直接写入这类关系。工作流只能提案影响边，然后由人工（或设定权限的 Agent）审查批准。

cruxible run --workflow build_seed_state
cruxible apply --workflow build_seed_state --from-last-preview

cruxible propose --workflow propose_incident_impacts
cruxible group list --status pending_review
cruxible group resolve --group GRP-7f3a --action approve \
  --rationale "Confirmed against supplier geography"

查询带收据：Agent 不再「猜测」

当你查询一个受治理的状态图时，结果不仅是一个 JSON 数组——它还附带一个收据，记录了查询的完整执行路径：

cruxible query run components_exposed_by_incident \
  --param incident_id=INC-42 \
  --json

返回结果中包含 receipt_id 和一个 receipt 对象，详细记录了查询类型、参数、遍历的每个边：

{
  "items": [
    { "entity_type": "Component", "entity_id": "component-main-board" }
  ],
  "receipt": {
    "operation_type": "query",
    "query_name": "components_exposed_by_incident",
    "parameters": { "incident_id": "INC-42" },
    "nodes": [
      { "node_type": "query", "detail": { "entry_point": "Incident" } },
      { "node_type": "edge_traversal", "relationship": "incident_impacts_supplier" },
      { "node_type": "edge_traversal", "relationship": "supplier_supplies_component" },
      { "node_type": "result", "entity_type": "Component", "entity_id": "component-main-board" }
    ]
  }
}

收据不是日志——它们是类型化的证据图。Agent 可以用收据验证「这个答案是怎么来的」，而不用重新推理一遍。两次同样的查询，同样的参数，得到同样的结果和同样的收据。

与 AI 编码 Agent 集成

Cruxible 通过 MCP 协议与 AI 编码 Agent 集成。安装 cruxible 后，在 Claude Code 或 Cursor 的配置中添加：

{
  "mcpServers": {
    "cruxible": {
      "command": "cruxible-mcp",
      "env": {
        "CRUXIBLE_MODE": "governed_write",
        "CRUXIBLE_SERVER_URL": "http://127.0.0.1:8100",
        "CRUXIBLE_SERVER_BEARER_TOKEN": ""
      }
    }
  }
}

Cruxible 提供四个累积的权限层级——read_only、governed_write、graph_write、admin——让每个 Agent 只获得完成工作所需的最低权限。

可组合的 Kit 系统

Cruxible 将领域模型打包为 Kit——一个包含本体定义、治理规则、命名查询、工作流和 Provider 的版本化单元。目前官方提供了 7 个 Kit：

• agent-operation：与 Agent 无关的操作层——工作项、审查请求、决策、风险、待决问题
• kev-reference + kev-triage：CISA 已知漏洞参考数据 + 本地资产暴露治理
• supply-chain-blast-radius：供应链影响范围分析
• project-domain / agent-release / case-law-monitoring：项目状态、发布管理、判例监控

Kit 的亮点在于可组合——overlay kit 可以在一个上游基础上叠加本地的状态、提案和工作流，就像 Docker 镜像的分层叠加。

谁适合用 Cruxible？

Cruxible 不是给「写一次就跑」的脚本用的。它的价值在以下场景最明显：

• 多 Agent 协作：多个 Agent 窗口（或不同工具）需要共享一致的领域知识
• 安全合规：Agent 的每一个声明都需要有来源和审查记录
• 长期项目：知识需要跨会话累积，而不是每次刷新都从头开始
• 可审计性：需要知道「谁在什么时候说了什么，依据是什么」

如果你只是写一篇一次性博客文章，或者做一个探索性原型，Markdown 或 RAG 完全够用。但当知识的准确性开始影响决策质量时，Cruxible 的治理状态层提供了一个远超过「猜」的可靠方案。

快速上手

pip install cruxible

CRUXIBLE_SERVER_STATE_DIR="$HOME/.cruxible/sandbox" cruxible server start

cruxible --server-url http://127.0.0.1:8100 init --kit supply-chain-blast-radius
cruxible context connect --server-url http://127.0.0.1:8100 --instance-id 

全部代码在 github.com/cruxible-ai/cruxible（Apache-2.0 许可证），完整的文档站包含了 CLI 参考、MCP 工具指南和 Kit 开发教程。

相关链接

• Cruxible GitHub 仓库
• Cruxible 官方文档
• PyPI 包
• MCP 工具参考