返回日志
•3 分钟阅读

谷歌 Open Knowledge Format 演进至 v0.2：智能体信任与可信信号

深入解析 OKF v0.2 如何在 AI 知识图谱中构建智能体信任、数据溯源、可信层级、失效控制与抗幻觉的可信计算。

Google CloudAI AgentsRAGOKFBigQueryData Engineering
谷歌 Open Knowledge Format 演进至 v0.2：智能体信任与可信信号

当我最初在 Implementing Google's Open Knowledge Format (OKF) in Practice 中记录我们对谷歌 Open Knowledge Format 的实现时，核心目标是解决 AI 智能体的上下文隔离问题。通过将纯 Markdown 文件组织为带有 YAML 前言的可导航、可链接图谱，智能体能够递归遍历文档树节点，而不是依赖不精准的向量检索。

OKF v0.1 奠定了坚实的基础：标准 Markdown、轻量级 YAML 元数据（type、title、description、tags）以及明确的相对链接。

然而，随着平台工程团队从人工撰写的文档转向自主的多智能体系统，一个根本性的挑战浮出水面：当 AI 智能体在夜间持续编写和更新成千上万个知识概念时，下游智能体或人类如何信任这些知识库？

人类撰写的文档具有隐性的信任保证——有开发者编写并对其准确性负责。而当智能体自主生成 10,000 个表定义、指标规范和操作指南时，这种隐性保证就消失了。

为了解决这一挑战，谷歌云发布了 Open Knowledge Format (OKF) v0.2 规范。本次更新在保持与 v0.1 完全向下兼容的同时，直接在 YAML 元数据中引入了结构化的 智能体可信信号 (Agentic Trust Signals) 和 可信计算 (Attested Computations)。

从描述上下文到决策信任

在 OKF v0.1 中，YAML 元数据回答的是描述性问题：这是什么节点？有哪些标签描述它？它指向何处？

OKF v0.2 引入了 决策字段 (deciding fields)——旨在让智能体在消耗 Token 阅读 Markdown 正文 之前，评估节点的来源、新鲜度和权威性。

解析成千上万个文档节点的完整正文来评估信任度在计算上是非常昂贵的。将可信信号提升到 YAML 前言中，使智能体和确定性系统能够在图谱遍历期间以极低的成本过滤掉未经验证、陈旧或已废弃的概念。

OKF Concept Frontmatter
├── Describing Fields (v0.1)  ──> type, title, description, resource, tags
└── Deciding Fields   (v0.2)  ──> generated, verified, status, stale_after, sources

OKF v0.2 中的 5 大核心可信信号

OKF v0.2 确立了五个标准化的元数据家族，回答关于任何知识概念的关键问题：

1. 数据溯源 (sources)

OKF v0.2 并没有指定一个任意的信任评分，而是在 sources 数组中记录原始的溯源信号。条目可以指向外部文档、包内的相对路径或数据库范围，并附带可信度标记（author、usage_count、last_modified）。

在正文中，具体声明使用标准 Markdown 脚注链接回这些来源（例如 [^warehouse-schema]）：

sources:
  - id: warehouse-schema
    resource: https://wiki.acme.internal/data/warehouse/schemas/sales
    title: Acme Retail Warehouse Schema
    author: team:data-platform
    usage_count: 1240
    last_modified: 2026-06-15
  - id: revenue-policy
    resource: policies/revenue-recognition.md
    title: Revenue Recognition Policy (FY2026)
    author: human:jsmith@acme
    last_modified: 2026-06-15

2. 可信层级 (generated 对比 verified)

OKF v0.2 明确区分了概念的创建者与确认者：

  • generated: { by, at }：记录创建实体（例如 reference_agent/gemini-2.5-pro）及创建时间戳。
  • verified: [ { by, at } ]：记录由自动化流程或人工审核进行的独立验证。

使用者可以从这些字段推导出三个明确的 可信层级 (Trust Tiers)：

  1. 未经验证 (Unverified)：缺少 verified 键。
  2. 机器确认 (Machine-Confirmed)：由自动化后台工具（如夜间 CI/CD 检查器）严格验证。
  3. 人工审核 (Human-Reviewed)：由人类开发者明确签署确认（例如 human:kliu@acme）。
generated: 
  by: reference_agent/gemini-2.5-pro
  at: 2026-06-30T14:00:00Z
verified:
  - by: human:jsmith@acme
    at: 2026-07-01T09:00:00Z

高管汇报流水线可以专门过滤 human-reviewed 指标，而测试环境则可以接受 machine-confirmed 概念。

3. 新鲜度 (stale_after)

OKF v0.2 没有使用相对 TTL 时长（例如“30 天有效”），而是使用绝对 ISO-8601 日期（例如 stale_after: 2026-12-31）。

相对 TTL 取决于获取概念的时间，会导致智能体产生非确定性行为。绝对日期支持简单的日期比较：如果当前系统时间超过 stale_after，该概念在被使用前会被标记为需要重新验证。

4. 生命周期 (status)

概念通过明确的生命周期状态演进：draft → stable → deprecated（省略时默认为 stable）。

当业务逻辑发生变化时（例如更新成本分配公式），之前的定义会被标记为 status: deprecated。这既保留了历史查询的可复现性，又防止智能体将过时的指标应用于新任务：

type: Metric
title: Gross Margin (Legacy, pre-FY2026)
status: deprecated

可信计算：防止智能体盲目即兴编写 SQL

溯源和验证确认了指标定义符合公司政策。然而，当智能体汇报财务指标（例如年度累计收入）时，仍然存在一个严重的失败风险：智能体可能会即兴编写自己的 SQL 查询。

OKF v0.2 引入了一种新的概念类型：Attested Computation（可信计算）。它既定义了经批准的计算逻辑，又提供了一种验证机制，确保实际执行的查询与经批准的定义完全一致。

      ┌─────────────────────────────────────────────────────────┐
      │               Attested Computation Node                 │
      │  - runtime: bigquery                                    │
      │  - parameters: [year]                                   │
      │  - executor: skills/run-on-bq.md                        │
      │  - attester: attesters/sql_equality.py                  │
      └──────────────────────────┬──────────────────────────────┘
                                 │
                 1. Binds declared parameters
                 2. Executes sanctioned SQL
                                 ▼
                      ┌─────────────────────┐
                      │ Execution Receipt   │
                      │ - job_id            │
                      │ - executed_sql      │
                      │ - result            │
                      └──────────┬──────────┘
                                 │
                 3. Deterministic AST verification
                                 ▼
                      ┌─────────────────────┐
                      │  Attester Verdict   │
                      │  - OK / REJECTED    │
                      └─────────────────────┘

生产示例：BigQuery 收入可信验证

以下是用于 BigQuery 财年收入的 OKF v0.2 Attested Computation 概念节点示例：

---
type: Attested Computation
title: Revenue for a Fiscal Year
runtime: bigquery
parameters:
  - { name: year, type: integer, required: true }
executor:
  resource: skills/run-on-bq.md
receipt: [job_id, executed_sql, result]
attester:
  resource: attesters/sql_equality.py
generated:
  by: reference_agent/gemini-2.5-pro
  at: 2026-06-30T14:00:00Z
verified:
  - by: human:jsmith@acme
    at: 2026-07-01T09:00:00Z
status: stable
stale_after: 2026-12-31
sources:
  - id: revenue-policy
    resource: policies/revenue-recognition.md
    title: Revenue Recognition Policy (FY2026)
    author: human:jsmith@acme
    last_modified: 2026-06-15
---

# Computation

```sql
SELECT
  SUM(
    CASE 
      WHEN o.currency = 'USD' THEN o.net_amount
      ELSE o.net_amount * fx.rate_to_usd
    END
  ) AS revenue_usd
FROM `acme.sales.orders` AS o
LEFT JOIN `acme.finance.fx_daily_rates` AS fx
  ON fx.currency = o.currency 
 AND fx.rate_date = DATE(o.order_ts)
WHERE o.order_status = 'delivered'
  AND DATE_DIFF(CURRENT_DATE(), DATE(o.order_ts), DAY) >= 30
  AND EXTRACT(YEAR FROM o.order_ts) = @year

可信验证的执行逻辑

  1. 仅限声明参数绑定：智能体被限制为仅能提供声明的参数（@year）。它无法编辑 SQL 文本或添加自定义 WHERE 子句。
  2. 执行回执：执行层返回包含 job_id、executed_sql 和结果 (result) 的签名回执。
  3. 确定性验证：一个独立的 Python 脚本（sql_equality.py）将目标 SQL 和 executed_sql 解析为抽象语法树 (AST)。如果关键字、表连接或过滤条件存在差异，验证失败，结果被直接拒绝。

向下兼容与平滑迁移

OKF v0.2 被设计为一个完全增量且向下兼容的版本。现有的 v0.1 包无需修改即可继续有效使用。

核心 Schema 演进包括：

  • timestamp 被 generated.at 取代。
  • 正文中的引用章节 (# Citations) 被 YAML 前言中结构化的 sources 数组取代。
  • 在这两种情况下，如果缺少新键，v0.2 解析器会直接回退使用 v0.1 字段。
// OKF v0.2 解析器回退模式
const creationTime = frontmatter.generated?.at ?? frontmatter.timestamp;
const documentSources = frontmatter.sources ?? parseLegacyCitations(markdownBody);

核心要点

谷歌的 OKF v0.2 规范将简单的 Markdown 知识库提升为 AI 智能体可验证的图谱网络：

  1. 决策优于描述：YAML 前言中提升的元数据允许在加载正文文本之前进行低成本的信任过滤。
  2. 明确的可信层级：清晰区分 generated 与 verified 元数据，直观展示人工审核与自动确认。
  3. 确定性新鲜度：绝对 stale_after 日期避免了非确定性的 TTL 评估。
  4. 可信计算：结合参数限定执行与 AST 等价校验器，彻底消除了智能体在 SQL 中的幻觉。

通过采用 OKF v0.2 标准，平台工程团队可以在保持严格的数据治理和可审计性的同时，安全地扩展自主 AI 工作流。

Share this article