题干与适用场景
公司有多个代理持续生成指标定义、运行手册和表结构。请设计一个基于 OKF v0.2 的知识目录，说明如何记录来源、生成者、验证者、过期状态和计算证明，并保证 v0.1 消费者仍能读取。
Google Cloud 于 2026 年 7 月发布 OKF v0.2 介绍。Open Knowledge Format 使用 Markdown 文件和 YAML frontmatter 表达可由人和代理共同维护的知识；v0.2 将 provenance、trust、lifecycle 和 attestation 变成可查询信号，同时保持增量、向后兼容。它是数据格式与治理约定，不是集中式运行时或访问控制系统。
面试官考察点
面试官会关注你是否区分“谁生成”和“谁验证”，是否用来源 ID 做逐条声明归因，能否把 freshness 与 lifecycle 变成可执行筛选，是否理解信任等级是消费方推导的建议信号而非权限控制。还要说明 v0.1 字段回退、写入幂等、版本迁移、恶意内容和计算证明的验证边界。
回答前需要澄清的问题
- 知识包由哪些生产者写入，谁拥有最终人工审核权？
- 消费者需要过滤未验证、过期、弃用还是仅特定信任等级的概念？
sources是否必须支持外部 URL、包内路径和范围描述？- attested computation 的执行环境、输入版本和验算资源是什么？
- v0.1 消费者是否只能读取旧字段，还是需要得到迁移提示？
30 秒回答框架
“我会把 OKF 文件当作可版本控制的知识事实，生产、验证、索引和消费分开。每个概念记录来源、生成者和时间、独立验证记录、状态和过期时间；逐条声明通过稳定的 sources[].id 归因。消费者先在 frontmatter 上按状态、信任等级和 freshness 筛选，再读取正文。v0.2 新字段全部可选，读取器保留未知键，并把 timestamp 回退到 generated.at、正文引用回退到 sources。信任等级由消费者推导，不能替代授权；计算证明必须绑定输入、代码和可复算证据。”
分步骤深入解答
1. 设计最小概念文件
每个文件只表达一个可维护概念，保留 type、标题、描述、资源和标签等基础字段。frontmatter 放需要索引和筛选的元数据，正文放解释、模式和示例查询。目录与 Git 版本控制提供变更、审查和回滚能力，运行时不强依赖中心注册表。
2. 建立来源与逐条归因
sources 记录概念产生所依据的外部文档、包内路径或范围描述，并为来源附加作者、使用次数和更新时间等客观信号。正文声明用脚注引用稳定的来源 ID，而不是 sources[0] 这类位置索引；列表重排时仍能正确归因，消费者也能独立计算可信度。
3. 分离 generated 与 verified
generated 描述当前内容由谁、何时生成；verified 描述谁、何时根据来源或资源确认内容。没有 verified 是未验证，仅机器确认可推导 machine-confirmed，包含人工确认者可推导 human-reviewed。等级是消费方的建议信号，不应直接当作访问控制或合规结论。
4. 管理 freshness 与 lifecycle
用 status 表示稳定、草稿或弃用等生命周期，用 stale_after 或等价时间表达内容何时需要复查。索引器按当前时间、来源更新时间和业务规则计算 freshness；过期不等于错误，消费者应决定是隐藏、降权还是要求重新验证，并保留原因。
source -> generated -> verified -> trust tier
-> status/stale_after -> consumer filter -> body read5. 处理 attested computation
对指标或计算结论，记录计算定义、输入资源版本、执行者、执行时间和验算结果。attestation 证明“按声明的方法得到这个值”，不自动证明输入正确或业务解释完整。执行器和打包方式不由 OKF 规定，团队必须在治理层固定环境、依赖和重放证据。
6. 保持 v0.1 兼容
v0.2 是增量、向后兼容的小版本；未采用新字段的 v0.1 包仍然有效。读取器保留自定义键和未知扩展，优先读取 generated.at，缺失时回退旧 timestamp；正文 sources 不存在时可读取旧的 # Citations 约定，并产生迁移警告。写入器应提供版本化迁移而非静默改写历史。
7. 构建可信消费管道
生产器提交文件，校验器检查 frontmatter、来源 ID 和时间格式，验证器写入独立确认记录，索引器物化可过滤字段，消费者在加载正文前按策略筛选。为重复生成设置概念 ID 和内容哈希，使用幂等写入与审查队列。对远程链接、Markdown、脚注和代理生成内容执行转义、允许列表和审计。
高质量示范回答
我会把 OKF 包当作 Git 中可审查的知识事实，每个文件表达一个概念，frontmatter 放可筛选元数据，正文放解释和示例。来源用带稳定 ID 的 sources 表示，正文脚注按 ID 做逐条归因。generated 与 verified 分开记录生产者和确认者，消费方据此推导未验证、机器确认或人工复核等级，但不把等级当作权限控制。status 与 stale_after 驱动生命周期和 freshness 筛选，过期内容可降权或进入复核队列。计算结论附带输入版本、执行环境、方法和验算证据，明确 attestation 不等于输入正确。v0.2 读取器保留未知键，支持 generated.at 与旧 timestamp、sources 与旧引用的回退，并用迁移警告保护 v0.1 兼容。最后以幂等提交、哈希、审查队列和安全渲染把生产、验证、索引和消费隔离开。
常见错误
- 把验证者和生成者合并 → 无法表达独立确认 → 分别记录
generated与verified。 - 把信任等级当权限 → 建议信号被误用为安全控制 → 授权仍由身份、策略和资源系统决定。
- 使用
sources[0]做归因 → 列表重排会错配来源 → 用稳定的来源 ID 和脚注键。 - 把过期视为错误 → 消费策略过于粗暴 → 由消费者决定隐藏、降权或复核。
- 声称 attestation 证明事实正确 → 忽略输入和业务语义 → 绑定输入版本、方法和验算边界。
- 迁移时静默删除旧字段 → v0.1 消费者失效 → 采用回退、警告和版本化写入。
追问及应对
为什么不在格式里规定统一信任分数？
分数依赖领域、消费者和时间，写入格式后容易失真且不可迁移。格式记录可核验信号，消费者根据作者、更新时间、验证者和使用情况推导本地策略。
一个概念被两个独立验证者确认怎么办？
保留多条 verified 记录及其时间和主体，消费方可按人工、机器、领域或最近确认策略组合；不要覆盖较早证据。
如何避免 stale_after 被任意延后？
限制谁能修改该字段，要求来源或业务负责人批准，并在审计中记录旧值、新值、理由和验证证据；刷新时间不应替代内容复核。
v0.1 消费者看不懂新字段怎么办？
它应忽略未知字段并继续读取基础字段；提供兼容写入、旧字段回退和迁移警告。不要把 v0.2 必填扩展写入所有旧包。
代理生成的指标如何进入高信任层？
先记录生成来源和计算证明，再由独立验证流程确认输入、方法和结果；人工复核或业务流程满足条件后，消费者才可推导更高信任等级。