Halo Record — tamper-evident runtime records for AI agents

wiki/ai/sources/halo-record-runtime-records.md

分类：ai / sources · 更新：2026-07-22 09:06

Halo Record — tamper-evident runtime records for AI agents

为什么重要

halo-record 把 agent 运行轨迹从“开发者写一段保证说明”推进到可验证的 runtime record：每个 tool call、model call、data access、approval 都被写成 append-structured、hash-chained log；持有 checkpoint 的任意一方都能验证链路没有被静默修改。README 的核心定位是：当客户安全团队问“你的 agent 对我们的数据做了什么”时，应该交付可验证报告，而不是自然语言承诺。

这对用户重要，因为 Hermes cron、coding-agent workflow、wiki ingest 和未来自动发布都越来越像无人或半无人 agent runtime。当前 llm-wiki 已经强调 claim receipts、raw hash、log 和写入记录；Halo Record 给了更底层的一阶结构：不只记录最终页面和报告，还记录每个 effectful action 的不可篡改证据链。

机制 / 一阶原理

Halo Record 的机制是：在 agent 边界包一层 recorder，将行动序列变成 hash chain。

关键机制包括：

Append-only JSONL chain：每条记录包含前序哈希，删除或修改任意记录会破坏后续验证。
边界采集：可通过 trace(run_my_agent, profile=..., log=...) 包装入口，也支持 LangChain / LangGraph callback、OpenTelemetry GenAI spans、LiteLLM callbacks、Langfuse export、MCP interceptor、OpenAI Agents SDK hooks、Claude Code hook 等入口。
最小信任面：Python 包宣称零 runtime dependencies、默认无网络调用；witness 是 opt-in，只接收 record count 和 chain fingerprint。
隐私约束：完整 payload 不进入记录，参数 hash + redacted summary；但 README 也明确 redaction 是 defense-in-depth，不是保证。
报告层：halo report / halo serve 将 chain 渲染成客户或操作者可查看的 runtime report。

一阶原理是：agent 安全和可审计性不能只依赖模型诚实或日志服务器可信；应让运行轨迹本身具备 tamper evidence。这与 raw source sha256 类似，但对象从“知识来源是否被改过”扩展到“agent 行动历史是否被改过”。

与既有 wiki 概念的关系

对 Harness-Engineering：补上执行中 evidence layer。harness 不只需要 pre-call gate 和 post-hoc verifier，还需要能证明中间 tool trajectory 没被篡改。
对 Loop-Engineering：无人 loop 的状态推进应绑定 runtime receipts；长期 cron 的“做过什么”不能只靠最终摘要。
对 Agent-Benchmarks：benchmark run 的完整性可以从 transcript receipts 升级为 hash-chained runtime records，帮助区分 backed / unsupported claims。
对 Agentic-Coding：Claude Code PostToolUse hook 可把文件写入、shell、MCP connector 调用记录到本地链，适合高风险 repo 修改或客户环境任务。
对 nemo-relay-agent-runtime-control：NeMo Relay 偏 scope/policy/normalized trajectory；Halo Record 偏 tamper-evident evidence chain，二者可以互补。

对 Hermes / llm-wiki 的可执行启发

把当前 log/raw hash 思路扩展到行动记录：llm-wiki 已给 raw sources 写 sha256；下一步可为 cron run 生成简化 action ledger，至少记录网络来源、文件写入、reindex、验证命令和失败原因。
高风险任务优先启用 runtime receipts：发布到 CVM、批量修改 skills/plugins、自动代码修改、读取客户数据等，比普通 wiki 写入更需要 tamper-evident records。
最终报告区分 summary 与 evidence：报告可以简洁，但内部应保留可复查的 action chain；这能减少“看起来完成但无法证明”的问题。
不要把 redaction 当安全边界：参数摘要仍可能泄漏片段；涉及 secrets/PII 时仍需最小记录、hash-only、路径脱敏和访问控制。
作为 wiki-radar 自检指标：每天报告若声明“已入库/已 reindex/未入库原因”，应能被文件存在、log、命令输出或 action ledger 支持。

失败模式 / 边界条件

记录不等于授权：tamper-evident log 能证明发生过什么，但不能阻止越权行动；仍需 deterministic gates、scope policy 和权限隔离。
隐私与可审计冲突：记录越细，越容易携带敏感上下文；记录越粗，越难复盘。需要按任务风险配置粒度。
链起点信任问题：如果 recorder 没覆盖所有工具入口，未记录行动仍可能发生；需要与 runtime/tool wrapper 集成。
操作开销：对低风险知识库 ingest 全量记录每个 read/search 可能过度；应先用于 effectful/high-risk boundary。
README 证据限制：本页基于 README，未在 Hermes 上安装运行 halo demo 或 hook，因此 confidence 设为 medium。

深度判断

值得 deep ingest，因为它补上了 Hermes/llm-wiki 当前证据链的缺口：我们已有 source hash、index/log、写入记录，但对 agent runtime 的 effectful actions 还缺 tamper-evident ledger。它把 did-it-claim-evidence-reconciliation、nemo-relay-agent-runtime-control、proof-or-stop-evidence-gated-lifecycle-control 这类“证据门控”思想具体化为可实现组件。

写入记录

2026-07-22 09:00 CST：新增 Halo Record source 页，提炼 hash-chained runtime records、agent action audit、Hermes 高风险任务 action ledger 与隐私边界。