Open Knowledge format v0.2 tackles agentic trust

OKF v0.2 增加信任信号 | Google Cloud 博客

数据分析

开放知识格式 v0.2 应对智能体信任问题

2026年7月25日

##### Sam McVeety

数据分析、工程、数据云技术负责人

##### Amir Hormati

BigQuery、工程、数据云技术负责人

##### 今天试用 Gemini Enterprise Business Edition

职场人工智能的入口

立即试用

当我们在2026年6月推出开放知识格式（Open Knowledge Format，OKF）时，我们主张智能体所需的上下文（表结构、指标定义、运行手册）应以某种格式存在，而不是依赖专有服务，也不应分散在非结构化文本块中。因此，OKF v0.1 的设计非常基础：仅使用 markdown、YAML 前置元数据和少量约定。

开发者社区的强烈反响和贡献为我们下一版本的开发指明了方向。自发布以来，贡献者提出了多项扩展提案（类型化关系边、智能体路由提示字段、可选的擦除一致性配置文件、.okfignore 约定等），提交了新的示例包，并开始整理 Google 之外构建的 OKF 生态工具。许多贡献和反馈反映了对 OKF 的更深层关注：当智能体开始向知识库写入内容时，这些内容真的可信吗？

最有价值的 OKF 包不会被一次性手动编写后永久读取。它们会持续由智能体生成，并被另一组智能体消费。人工编写的维基页面附带一个隐含保证：一个人编写了它，如果内容错误，你可以追究其责任。但当智能体在一夜之间生成一万个概念时，这种保证就消失了。为了实现问责，消费者（通常是另一个智能体）必须根据明确的信号来判断每个概念，并回答五个问题：

• 这是从什么产生的？（来源）
• 我应该信任它多少？（信任度）
• 它仍然有效吗？（新鲜度）
• 它是最新版本吗？（生命周期）
• 这个数字是否按照我们规定的方式生成？（证明）

在 OKF v0.2 中，现在可以通过前置元数据回答上述所有五个问题，同时格式仍像 v0.1 一样保持最小化意见。它增加了词汇，而非规则：类型仍然是唯一始终必需的字段，每个新字段都是可选加入的，自定义键仍然被保留而非被拒绝，采用 none 新增功能的包与 v0.1 时一样有效。以下所有新增内容都是可选的，但其缺失现在具有含义：未验证的概念与已验证的概念可以区分（尽管不会因差异而被拒绝）。

这些字段属于前置元数据（frontmatter）的原因在于，大多数对某个概念的交互实际上并不会进入文件正文内容的访问阶段。无论是人、确定性代码还是在搜索和发现过程中扫描的代理，首先都需要判断该概念是否相关。概念中的所有内容都应简洁，但前置元数据有更具体的职责——精准提取用于判断相关性和可信度的关键信号，因此可以低成本高频次地生成，无需消耗文本描述的token。必须完整阅读的内容保留在正文中，仅在选定某个概念后才会被访问。可信度成为在投入阅读前就可以进行过滤的属性。

为了使后续内容更具体，以下每个示例均来自我们为本文准备的配套OKF v0.2小规模数据包：acme_retail，这是一个虚构的美国零售公司用于BigQuery人工智能辅助分析的共享知识库：

加载中...

acme_retail/ ├── index.md, log.md ├── tables/ orders.md ├── metrics/ revenue.md, gross-margin.md, gross-margin-legacy.md ├── computations/ revenue-ytd.md, gross-margin-period.md ├── skills/ run-on-bq.md ├── attesters/ sql_equality.py └── policies/ revenue-recognition.md, margin-standard.md

后续每个章节都将展示对应的文件。以下是tables/orders.md，一个包含新信号的概念描述：

--- type: BigQuery Table title: 客户订单 description: 跨网页、移动端和市场渠道的每条已完成客户订单对应一行数据。粒度是订单本身，而非订单条目。 resource: https://bigquery.googleapis.com/v2/projects/acme/datasets/sales/tables/orders tags: [sales, orders, revenue] generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-30T14:00:00Z } verified: - { by: human:kliu@acme, at: 2026-07-01T16:00:00Z } status: stable stale_after: 2026-12-31 sources: - id: warehouse-schema resource: https://wiki.acme.internal/data/warehouse/schemas/sales title: Acme Retail数据仓库架构——销售数据集 author: team:data-platform usage_count: 1240 last_modified: 2026-06-15 - id: revenue-policy resource: policies/revenue-recognition.md title: 收入确认政策（2026财年） author: human:jsmith@acme last_modified: 2026-06-15 --- # Schema | Column | Type | Description | |----------------|---------------|----------------------------------------------------------------------------------------| | order_id | STRING | 全局唯一的订单ID。 [^warehouse-schema] | | order_ts | TIMESTAMP | UTC时区的订单创建时间；决定财年归属。 [^revenue-policy] | | order_status | STRING | 仅在状态为'已发货'且超过30天退货窗口后确认收入。 [^revenue-policy] | | net_amount | NUMERIC(18,4) | gross_amount - discount_amount。根据政策确认的收入金额。 [^revenue-policy] |

每个类别都对应回答五个问题中的一个。

来源追踪：来源信息，而非评分

新的sources字段记录了概念所依赖的材料：外部文档、数据包相对路径，甚至是类似"项目X中所有查询"的范围描述。同时，条目可以携带客观可信度信号：author（作者）、usage_count（使用次数）、last_modified（最后修改时间）。

我们在此刻意选择的是未添加的内容。OKF 记录的是信号，而非可信度评分。评分具有主观性，无法在不同用户间通用，且一旦写入就会立即失效。相反，可信度由信息使用者根据信号进行推断（如需，使用者也可以动态打分），就像你会更信任一个被频繁使用、最近更新、且由权威作者撰写的内容，而不是匿名来源。当正文引用特定来源时，会通过普通 Markdown 脚注以源 ID 进行标注（[^export-schema]），因此归因是针对每个声明的，而不是在底部列出一个悬空列表。

信任：生成与验证

信任通过两个字段建立，这两个字段刻意保持独立，因为撰写内容的人不一定就是验证内容的人：

• generated: { by, at }：当前内容是如何生成的，以及它最后一次有意义更改的时间。
• verified: [ { by, at } ]：对来源或底层资源的独立验证列表；可以是人工确认、夜间财务流程，或两者兼有。

从 verified 字段，使用者可以推导出信任等级：没有 verified 键的内容视为未验证；仅由机器主体确认的内容视为机器确认；由 <id> 人工主体确认的内容视为人工审核。这些等级是建议性信号，而非访问控制机制，但它们允许使用者通过前置过滤器声明“仅在高管仪表板中展示人工审核过的指标”。

在 acme_retail 示例中：metrics/revenue.md 由参考代理编写，由财务副总裁验证，因此属于人工审核等级。配置了信任等级过滤器的高管仪表板使用者会展示该内容；而临时测试环境可以接受较低等级的概念：

type: Metric

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 }

新鲜度与生命周期：stale_after 与 status

OKF v0.2 通过 stale_after 和 status 字段建立新鲜度与生命周期。status 字段将概念从草稿 → 稳定 → 废弃状态进行流转（未指定状态表示稳定）。stale_after 是一个绝对日期。我们特意选择绝对日期而非相对 TTL：陈旧性判断只需与一个普通日期进行比较，无需参考概念被读取的时间，这正是非 LLM 消费者期望的确定性。

在 acme_retail 示例中：metrics/revenue.md 和 metrics/gross-margin.md 的 stale_after 都为 2026-12-31，因为 Acme 的财务团队每年一月会重新审批底层政策。到 2027-01-01，这两个概念在提供服务前都需要根据 FY2027 政策重新验证。

而 metrics/gross-margin-legacy.md 的 status 为 deprecated。Acme 于 2026 年 2 月更改了成本分配标准（旧公式未将运输和履约成本计入其销售成本）。遗留定义为保留历史查询可重复性而存在，但不会在新工作中展示：

type: Metric

status: deprecated

证明：这个数字是按授权方式计算的吗？

溯源回答了声明的来源。证明则回答了一个更关键的问题：当代理报告一个美元数值时，这个数字是否是按我们规定的方式生成的，还是代理自行编写的 SQL？

OKF v0.2 引入了一种新的概念类型：已验证计算（Attested Computation）。它不仅描述了某个值的含义，还定义了计算该值的授权方式，并提供了验证该授权计算实际执行的手段。以下是一个示例文件 acme_retail/computations/revenue-ytd.md：

type: Attested Computation

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

author: human:jsmith@acme last_modified: 2026-06-15

计算

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

代理只能填写声明的参数，不得修改或编写计算逻辑。消费者通过执行器运行计算，执行器返回一个收据（此处包含 BigQuery 的 job_id、实际执行的 SQL 语句和结果）。随后，一个确定性且不依赖 LLM 的验证器会检查该收据并返回判断：执行的查询是否与授权计算绑定的参数一致？显示的值是否与收据的权威来源匹配？由于比较过程是机械的，任何查询重写、计算文件替换或依赖项变更都会导致验证失败。

在 acme_retail 中，验证器 attesters/sql_equality.py 会将两个 SQL 语句标准化（删除注释、合并空白、大写已知关键字），如果标准化后的形式不同，验证器将拒绝返回“通过”结果。表名替换、新增过滤条件或删除 JOIN 操作都会导致验证失败。当验证结果为“失败”时，消费者将拒绝显示该值。

虽然本例使用了 BigQuery（和 SQL），但该抽象设计是刻意保持灵活的。已验证计算可以对应调用语义模型（如 Looker、AtScale 等系统）、查询结构化知识图谱，甚至执行任意 API 调用。

关键的是，OKF 记录了计算方式及验证方法，自身从不执行任何操作。验证（attestation）与确认（verification）是两个独立的概念：verified 确认定义仍符合政策（过程缓慢、文档级、存储在包中）；验证确认单次运行结果正确（实时、调用级、从不存储在包中）。即使定义已过期，仍可正常验证；即使定义刚通过确认，每次运行仍需重新验证。这就是两者并存的原因。

v0.2 版本发布内容

与 v0.1 一样，参考实现是刻意设计为概念验证，OKF 本身并不依赖这些实现。以下是 GitHub 仓库的变更内容：

• reference_agent 现在在生成时会输出溯源信息和信任家族，因此新生成的包会自带 generated 源和已就绪的引用信息。

• 静态可视化工具在概念图中展示信任层级、状态和数据新鲜度，使这些信号不仅可解析，而且清晰可见。

• 更新后的示例数据包（GA4 电商、Stack Overflow、比特币，以及本文博客中使用的 acme 零售示例）均包含 v0.2 字段。

• 知识目录演示展示了数据包如何在 Google Cloud 知识目录（原 Dataplex）中往返传输：磁盘上的 OKF 数据保持干净，信任和出处信号在目录中完整保留并回传。

兼容性

v0.2 是一个次要版本更新，采用向后兼容的增量方式，包含两个有意为之的重命名：timestamp 字段被 generated.at 取代，正文中的 # 引用列表被 sources 取代。在两种情况下，v0.2 的消费者均可回退至 v0.1 格式。v0.1 数据包可直接使用而无需修改。

未来方向

阅读规范（目前仍较简短）。为您的源系统编写一个能生成信任信号的生产者。编写一个能根据这些信号进行过滤的消费者。尝试使用您自己的金融定义进行可信计算。提交问题、发送拉取请求、提出扩展建议。一种通用语言的价值取决于使用它的群体数量，现在这些群体还可以互相验证彼此的工作。

OKF v0.2 规范、示例及参考实现：github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf

发布于

• 数据分析

• 前沿与核心领域