Halo 开源：给 AI Agent 装上"防篡改"黑匣子

一个专门盯着 Agent"作案现场"的开源项目

7 月初，一个叫 Halo（halo-record） 的项目挂上了 Hacker News 的 Show HN 板块。作者 bkuan001 的定位相当克制——它不是又一个 Agent 框架，也不是新的可观测性 SaaS，而是一个更底层的东西：tamper-evident runtime evidence for AI agents，翻译过来是"AI Agent 的防篡改运行时证据"。

说白了，就是给 Agent 的每一步操作录一份不可抵赖的黑匣子。

这个方向如果放在两年前提，大概率没人搭理。但今天不一样了。Claude Code、Codex、Cursor Agent 这类能自己开终端、写文件、调 API 的东西已经在生产环境里跑起来了，企业里的 CISO 们最近一年被 Agent 的运行时安全折腾得够呛——传统 APM 看不到 Agent 的推理链，SIEM 也不知道该怎么解析一次 tool_call。Halo 瞄的就是这个空档。

为什么"日志"这件事对 Agent 特别难

先把问题讲清楚。传统软件的日志是确定性的：某个函数在某个时间被调用，输入输出都能对得上。出了 bug，翻日志就是了。

Agent 完全是另一码事。它的每一次运行都是一次概率性决策序列：

• 同样的 prompt，两次执行可能选择不同的工具
• 中间的 reasoning token 大部分框架默认不落盘
• MCP 工具调用的返回值经常在 context 里被截断、被总结
• 更麻烦的是，Agent 可以修改自己的运行环境——它写的文件、改的配置，本身就是后续行为的输入

这意味着你事后想复盘"Agent 为什么把生产库的表删了"，光看 stdout 是完全不够的。你需要知道它当时看到的 context 是什么、调用了哪些工具、每个工具返回了什么、下一步的决策依据是什么。而且，这份记录必须没法被 Agent 自己或者攻击者篡改——否则一个被 prompt injection 攻破的 Agent，完全可能一边干坏事一边把日志改干净。

Halo 想解决的就是最后这一步：防篡改。

技术方案：Merkle 链式记录

从仓库代码看，Halo 的核心思路并不新鲜，本质是把区块链领域用烂了的**哈希链（hash chain）**搬到 Agent 运行时上。

每一条运行时事件——一次 LLM 调用、一次工具执行、一次文件读写——都会生成一条结构化记录，包含：

• 事件类型和 payload
• 时间戳
• 前一条记录的哈希值
• 当前记录的哈希值

所有记录构成一条不可回溯修改的链。想改中间任何一条，后面所有的哈希就全对不上了。如果再配合定期把根哈希锚定到外部（比如公开的时间戳服务、甚至真的上链），就能做到第三方可验证的证据链。

这套东西在金融审计、合规日志领域是老技术了。Halo 的价值不在于发明了什么，而在于它把这套范式明确对齐到 Agent 的语义——事件类型是按 Agent 的操作抽象设计的，不是通用日志。

它跟 LangSmith、Langfuse 这些不是一回事

聊到这里可能有人要问：LangSmith、Langfuse、Arize Phoenix 这些 Agent 可观测性平台不是已经在做类似的事了？

不一样。那批工具的定位是调试和性能分析——帮开发者看清 Agent 内部发生了什么，方便迭代 prompt、优化 latency、评估质量。它们的日志是给"善意的开发者"看的，没有假设有人会篡改。

Halo 是审计视角的产物。它假设了一个对抗场景：Agent 可能被劫持、日志可能被伪造、事后可能要出庭作证。这在受监管行业——金融、医疗、政务——是刚需。欧盟 AI Act 已经明确要求高风险 AI 系统必须有可审计的运行日志，美国那边的 NIST AI RMF 也在往这个方向推。

所以别把 Halo 和 Langfuse 放一起比。它俩解决的是不同层次的问题：一个是 dev tool，一个是 compliance infra。

现在的完成度怎么样

实话说，还很早期。仓库里的东西更像是一个参考实现：

• 事件 schema 定义得比较基础，覆盖了主流的 tool_call、llm_call、file_op 场景
• SDK 目前主要是 Python 侧，Node 那边还在坑里
• 没有开箱即用的验证工具（verifier），需要自己写脚本比对哈希
• 存储后端可以自选，SQLite、Postgres、S3 都行，作者没做强绑定

作者在 HN 上的自述也很坦诚：这是他从合规工程背景出发做的一个 proof of concept，希望社区能帮他把 schema 打磨得更通用，最好能沉淀出一份"Agent 审计日志"的事实标准。

这个野心不小，但方向是对的。如果 Agent 要真正进企业生产系统，运行时证据这一层迟早要有人做——要么是开源社区搞出标准，要么就是 AWS、Datadog 这些巨头闭源做进他们的观测栈。开源方案能不能跑出来，取决于生态。

一个更大的判断：Agent 基础设施正在分层

从 Halo 这类项目冒头，能看出一个趋势：Agent 相关的基础设施正在从"大而全的框架"往"专而精的中间件"分化。

2023 年大家还在争 LangChain vs LlamaIndex，2024 年 MCP 出来后工具层被拆走了，今年开始，运行时安全、审计、沙箱、成本管控这些细分层次都在冒出各自的开源项目。这个演进路径跟当年云原生生态几乎一模一样——先是 Docker 一统天下，然后 Kubernetes 抽走编排，再然后 Istio、Prometheus、OPA 各自占领细分领域。

Halo 对应的位置，大概类似于当年的 Falco（云原生运行时安全）或者 Sigstore（软件供应链证据）。它不性感，但如果 Agent 真的要成为企业级基础设施，这一层就必须有。

一点使用建议

如果你现在在做 Agent 相关的东西，Halo 值不值得引入？我的看法：

• 在做内部工具或者 PoC：不用急，overhead 不值得
• 在做面向 C 端的 Agent 产品：可以关注，未来合规压力会到
• 在做金融、医疗、法律这类受监管场景的 Agent：现在就该看，甚至可以参与共建 schema
• 在做多 Agent 协作系统：强烈建议看，多 Agent 之间的责任划分现在基本是黑洞，有一份可验证的运行记录能省很多扯皮

另外一个隐性价值：当你的 Agent 需要调用多家模型 API 的时候，一份统一的、跨 provider 的运行时证据其实很有用。像 OpenAI Hub 这种一个 Key 打通 GPT、Claude、Gemini、DeepSeek 的聚合层，配合 Halo 这样的证据记录，能让你在切换底层模型的时候保留一致的审计轨迹——这在做 A/B 测试或者供应商灾备时是实打实的好处。

最后说一句，这类"看起来不起眼"的项目往往才是生态走向成熟的信号。Agent 圈子过去两年出了太多 demo 级的东西，真正开始有人认真做审计、做证据、做防篡改，说明这个领域正在从玩具期进入工程期。

值得盯着看。

参考来源

• Halo - GitHub 仓库（bkuan001/halo-record） - Halo 项目主页与源码，包含 Show HN 讨论
• HALO - camel-ai/halo - 同名但不同项目：把 Agent 接到智能眼镜的开源桥接层，注意区分