别存储信任，推导信任：Agent文档的可验证信任模型

你的编程 Agent 现在会写持久化的知识。CLAUDE.md 文件、memory 目录、runbook、"关于这个代码库我学到了什么"的笔记。如果你每天使用 Claude Code、Cursor 或 Codex，你的仓库中越来越多的 markdown 内容是由非人类的某个东西写的。

危险的部分不在于 Agent 会写错东西——人类也会。危险的部分在于六周之后，文件中没有任何内容能回答三个基本问题：

谁写的：人还是模型？

有人检查过吗？

它现在还应该被认为是对的吗？

当这些答案缺失时，一个 Agent 读取自己未经证实的猜测并将其视为基本事实，然后在此基础上继续构建。下一个会话继承这个错误时，比第一个会话更有信心。这就是知识腐坏，而且带有反馈循环。

不起作用的诱人修复

第一反应是加一个字段：

trusted: true
confidence: 0.87

存储的信任分数有三个问题：

它是某个人的观点，但没说是谁的。

它不可移植：你的 0.87 不是我的 0.87。

它会静默腐坏：内容被编辑了，分数不变。

它是一个没有失效策略的缓存。同样的 bug，换了件衣服。

记录事实，派生判断

开放知识格式（OKF：Google Cloud 于 2026 年 6 月宣布的开放、厂商中立的规范，纯 markdown + YAML frontmatter，无运行时，无 SDK）走了另一条路。我之前一篇文章已经介绍过这个格式本身：知识作为一个 markdown 概念的目录，与它描述的代码同版本管理。此后规范演进到了 v0.2，而 v0.2 正是针对这个问题。Frontmatter 只存储可观察的事件。每个消费者在读取时派生判断。

---
type: Service
title: "Auth API"
description: "Issues and verifies short-lived access tokens."
status: stable
generated: { by: doc_agent/1.0, at: 2026-06-14T10:00:00Z }
verified: { by: human:dana, at: 2026-06-20T09:00:00Z }
stale_after: 2026-09-23
sources:
  - id: auth-readme
    resource: https://github.com/acme/auth#readme
    author: team:auth
    last_modified: 2026-06-01
---

这里的所有内容都是你可以核实的fact。

关键细节是 actor 约定：human:dana 表示人，process:finance-nightly 表示自动化，doc_agent/1.0 表示 Agent 和工具。前缀是机器可解析的部分。谁写了一个概念和谁检查了它被有意地分成两个独立字段，因为作者不必是检查者：Agent 生成、人类确认是正常情况，不是例外。

整个信任模型是四条规则，由消费者在读取时应用：

没有 verified 键 ⇒ 未验证。

verified 只由非人类 actors 完成 ⇒ 机器确认。

有任何人类：verifier ⇒ 人类审查。

today >= stale_after ⇒ 过期，无论什么层级。

就这样。没有分数，没有注册表，不需要同步任何东西。而且因为 generated.at 和最新的 verified[].at 都是普通时间戳，消费者还可以看到存储分数会隐藏的情况：内容在其上次验证之后发生了变化。检查本身仍然是一个fact；只是明显不再覆盖当前的文本。

派生而不是存储并不是一个新想法。Git 不存储"这个分支已合并"：它从提交图中派生出来，所以永远不会过期。存储的信任层级是一个存储的观点，当它周围的任何东西移动时它就立即过期。派生的层级在每次读取时根据今天的日期和当前的 frontmatter 重新计算。

有一个 failure mode 值得自动化消除：humans:dana（一个拼写错误）是一个非人类 actor，所以真正的人类审查会静默降级为机器确认。这是一种在不破坏任何可见内容的情况下改变信任层级的 typo，恰恰是那种值得 linter 而不是 code review 来捕获的 bug。

实践中的样子

我们维护着 okf-skills，这是 Claude Code 原生的 OKF 工具链：一套用于生成、维护、验证和可视化 bundle 的 skills，外加一个 GitHub Action 用于在 CI 中 gate 它们，完全不需要 Agent。图形渲染器在渲染时计算信任层级和过期徽章，不存储任何一项。验证器强制执行 frontmatter 家族规则，并对 actor 近拼写错误（如上面的 humans: typo）发出警告。

这个仓库也用 OKF 记录自身，所以你可以把一个带有派生信任信号的真正 bundle 作为实时交互式图形来浏览：架构、决策和更新日志，每个节点显示它是谁生成的以及该节点获得的信任层级。

我们刻意不声称的一件事：bundle 使 Agent 成本更低。我们早期对 bundle 在 Agent 回答上的效果做了基准测试（"为什么"类问题的声称覆盖率提升 8 个点，没有 token 节省），然后把基准测试从仓库中删除了，因为它衡量的是一个推广话术，而不是标准。信任模型是我们单独捍卫的部分：它使 Agent 写的知识可审计，而这个属性不依赖任何基准测试。

# as a Claude Code plugin
/plugin marketplace add scaccogatto/okf-skills
/plugin install okf@scaccogatto

# as agent skills (Claude Code, Cursor, Codex, 20+ agents)
npx skills add scaccogatto/okf-skills

# validate any bundle, zero config
uv run skills/validate/scripts/okf_validate.py .okf --strict

然后让你的 Agent "用 OKF 记录 auth service"，检查它写的 frontmatter。

如果你的 Agent 写的是你的团队会读的知识，不要要求它们正确。要求它们留下证据：谁写的，谁检查的，有效期到什么时候。信任不是一个字段。它是一个查询。