Flight Recorder 飞行记录仪

要解决的问题 #

事故复盘时，日志散落各处；“读取”与随后的动作之间没有关联；日志可以被同一位管理员，甚至同一个智能体修改。

更根本的是：当一次合并或一条记忆被怀疑受到污染时，没有办法回答“那次运行读过什么”。

工作方式 #

• 两类内容。 事件逐条记录：提交、租约签发与撤销、闸门请求与决定、策略拒绝、派生、遗忘。读清单（read manifest）按运行聚合：读过哪些路径@提交、哪些范围、内容哈希；不记每一次读取调用，也不记内容。
• 每个提交带来源元数据： principal、on_behalf_of、run、lease、purpose 和读清单引用。
• 哈希链（按天），可选签名与外部锚定（第二个节点、带对象锁的桶）。目标是“篡改可以被发现”，而不是“无法篡改”。
• 导出： OpenTelemetry GenAI spans、JSON Lines，或接入 SIEM。
• 隐私： 默认只记元数据，不记内容；记录的保留与内容的删除互相独立；记录本身受访问控制。
• **explain(commit)：** 返回这次提交对应的运行、租约、闸门决定、读清单与输入。
• 先记录，后生效： 有后果的操作必须先写入意图记录。

从小处开始 #

• 一张追加写的 SQLite 表，加上每日哈希。
• 在每个提交信息里写 Run:、Lease: 之类的 Git trailer。
• 导出 OpenTelemetry spans，接入你已有的观测栈。

接口草图 #

仅作示意。字段名在规范 v0.3 之前可能调整。

{
  "seq": 18211,
  "time": "2026-11-12T09:14:22Z",
  "kind": "commit",
  "run": "run_91ab",
  "principal": "agt_cleo",
  "on_behalf_of": "usr_wei",
  "lease": "lse_7Qk3",
  "purpose": "Draft the Q4 release notes",
  "subject": { "path": "/shared/launch/notes.md", "commit": "91ce3a7" },
  "read_manifest": "rm_5d2e",
  "decision": { "effect": "allow", "rule": "r-17" },
  "taint": { "external": true, "sensitivity": "private" },
  "prev_hash": "sha256:b3a0..."
}

规范的要求 #

• 有后果的操作必须在生效之前写入意图记录；写入失败时，操作必须失败。
• 每次运行必须有读清单，记录读过的路径、提交与范围（不含内容）。
• 记录必须哈希链接，并且必须能用公开的命令校验。
• explain(commit) 必须返回运行、租约、闸门决定与读清单引用。
• 记录的保留必须独立于内容的删除。

借鉴与区别 #

下面这些都是现成的零件。真正新的部分是读清单： 把“读”变成一个可追溯的输入集合，使“被污染的合并”和“被投毒的记忆”可以复盘。

• OpenTelemetry GenAI conventions
• Certificate Transparency
• Sigstore Rekor
• Git trailers

坦诚的局限 #

• 没有外部锚定时，拥有 root 的管理员仍然可以毁掉日志。
• 记录本身含有敏感的元数据，必须受控。
• 读清单的粒度是存储成本与可追溯性之间的折中。

开放问题 #

• 高吞吐下读清单的存储成本如何控制？
• 跨节点的记录如何合并与校验？

常见问题 #

相关概念 #

• Capability Lease (能力租约) 发给一次运行的、有期限与预算的窄域授权；子租约只能更窄。
• Trust Labels (信任标签) 来源与敏感度两个小标签，加上会话污点，强制执行 Rule of Two。
• Cascade Forget (级联遗忘) 沿血缘删除派生物，按保留类处理历史，并如实报告做不到的部分。