日志不是副产品，日志就是 Agent 本身

Yohei Nakajima 最近发了篇论文，《The Log is the Agent》。读完第一反应是：这个想法太自然了，自然到让人纳闷为什么之前没人这么做。

现在搭一个 Agent 框架，标准流程是先写聊天循环，加工具调用，加规则约束，最后补一层日志看看生产环境发生了什么。日志是副产物，是事后补的审计工件。Nakajima 问了一个很直接的问题：如果日志不是副产品，而是 Agent 本身呢？

他的 ActiveGraph 就是这么干的。目标、规则、工具调用、LLM 响应、产物和它们之间的关系，全部写入同一条追加式事件日志。当前的工作图只是日志回放后投影出来的一张图。行为——不管是一个普通函数、一个类、一个 LLM 驱动的例程，还是附着在类型化边上的逻辑——都只对图的变化做出反应，产生新事件。没有组件直接指令另一个组件。

架构图

状态散落在六个地方，没人在管它们之间的关系

这个反转之所以有意义，得先看看常规架构里 Agent 的状态散落在多少地方。目标在 prompt 里，规则在代码或 system message 里，工具调用在框架内部状态里，推理轨迹在 transcript 里，产物在数据库里，还有一个被压缩过的"记忆"存在向量索引里。这些东西彼此隔离。你想回答"这个事实为什么会出现在 Agent 的工作集里"这种简单问题，得翻好几个系统。更不用说"Agent 在改规则之前相信什么"或者"如果第 42 步选了另一个分支会怎样"了。

ActiveGraph 把这些全塞进同一条日志。规则变更是事件，工具调用和响应是事件，产出的声明是创建对象的事件，声明和证据之间的链接是创建关系的事件。每条事件带 id、类型、payload、产生者、可选的 caused_by 指针和时间戳。论文贴了一段真实运行的开头日志——从 pack 加载、目标创建、行为启动到对象创建，每个对象自带 provenance 块，记录了是哪个行为、哪个事件导致它产生的。没有任何东西是无源之水。那些在传统架构里尴尬的问题，突然变成了对日志的查询或重投影。

行为不是被编排的。它声明一个订阅，当图上出现匹配的变化时，运行时触发执行体。执行体有四种形态：普通函数、类、LLM 驱动的例程、以及附着在类型化边上的关系行为。论文专门解释了为什么需要图而不只是日志——行为的订阅是图结构模式，不只是事件类型过滤器。"一条回应了未回答问题的声明"这种拓扑谓词，在扁平事件流里表达不了。关系行为让计算可以附着在对象之间的关系上，而不只是对象本身。日志让状态可复现，图让响应和比较可表达。

论文有一张对比表。传统 Agent 循环做不到确定性状态重建、不能从历史完整重放、不能在任意点分叉、不能做两次运行的结构化 diff。记忆层系统——MemGPT、Zep、Mem0 这些——能做到跨会话持久，但溯源最多是部分的，重放和分叉也做不到。ActiveGraph 在这七个维度上全部打勾。

671 个事件，没有一行编排代码

最让人意外的不是这些能力本身，而是它们怎么来的。论文的尽调例子，一次运行产生 671 个事件、93 个对象、76 条关系，通过 103 次模型调用和 48 次工具调用——没有一行编排代码。planner 行为响应目标创建公司，question generator 响应公司生成研究问题，researcher 响应问题去查资料。控制流是事件匹配订阅的涌现结果。论文对此说得很克制："协调没有消失，它转移了。"原来写在 workflow 引擎里的显式编排，变成了通过共享图及其订阅的隐式协调。每个协调决策本身是一个事件，不是某个外部程序计数器里的位置——这让每次运行都能统一地重放、分叉和检查。

确定性是重放日志的属性，不是运行 Agent 的承诺

LLM 调用天生不是确定性的，同样的 prompt 可能得到不同结果。ActiveGraph 不假装能解决这个问题——首次执行时正常调模型，把响应记录下来；重放时请求被内容哈希索引，缓存命中就直接返回记录好的响应，不再调模型。重放分两种模式：宽松模式默认使用，哈希匹配走缓存，不匹配走新调用；严格模式逐事件对比，任何偏差都会抛出重放分歧错误，精确到第一个不一致的事件。一次绿色通过的严格重放，就是"这次运行可复现"的证明。

为了保证重放可靠，行为作者要遵守一个确定性契约——不能直接读随机数、系统时钟或新 UUID，不能在框架原语之外做 I/O，不能依赖跨触发变化的可变全局状态。有意思的是，这个契约不是静态强制执行的。违反它的行为第一次运行正确，之后在重放或分叉时被捕获，作为发散错误钉在第一个无法复现的事件上。LLM 行为是例外：首次执行时不满足契约，但框架不要求它满足，调用正常发出，响应被记录；重放时从缓存读取，行为精确复现。论文把分工说得很清楚：确定性是重投影已有日志的属性，从来不是声称运行 Agent 是可复现的。

分叉前 149 步免费，因为没人需要为同一段历史付两次钱

重放和确定性契约加在一起，让分叉变得极其便宜。在任意事件处切出一个分支，拷贝父运行的日志直到切点，之后走自己的独立日志。两个运行可以配置不同，各自跑完，用结构化 diff 比较——全程不碰父运行。关键是共享前缀不重新执行，所有模型和工具响应从内容寻址缓存中读取。200 步的运行在第 150 步分叉，前 149 步包括模型调用都是免费的。而且分叉关系不是容易漂移的元数据——分支的前 k 个事件就是父运行的前 k 个事件，event id 直接共享，任何人都能通过读两条日志验证血缘。大多数 Agent 框架根本不能分叉，因为状态不可重建；能分叉的通常得重跑前缀，重新支付每次模型调用。

备忘录不重要，每句话从哪来的才重要

尽调例子真正要展示的不是备忘录本身，而是血缘。一条声明如"Northwind Q3 收入同比增长 28% 至 4200 万美元"携带 provenance 块，记录了创建它的行为、触发事件、以及产生它的具体模型请求事件。它通过类型化关系链接着它回答的问题、来源文档和支持证据。附带录制好的 fixtures，整个运行离线执行，不需要 API key，三十秒内完成，两次运行产生字节相同的日志。对于尽调、科研、合规——任何推理过程和答案同样重要的场景——能从日志中重建从目标到输出的完整因果链，这才是真正的产品。

一个 50 年前的旧想法，被 LLM 救活了

论文在思想来源上很诚实。事件溯源和 CQRS 是数据系统里的成熟模式，增量响应式计算是数据流和电子表格引擎的核心。ActiveGraph 的贡献不是这些机制本身，而是把它们应用到包含非确定性模型调用的 Agent 系统。更有意思的是黑板架构——1970 到 80 年代的系统就围绕共享知识结构组织问题求解，独立的知识源读写共享结构，彼此不直接调用。当年这套模型没规模化，因为知识源得靠人手写，控制逻辑也得人手写。LLM 同时消解了这两个约束。论文甚至说，黑板的共享状态、反应-写回模型可能比对话循环更适合 LLM。ActiveGraph 在这个意义上不是新想法，而是旧想法的验证——加上黑板系统从未有过的事件溯源基座。

论文还讨论了一个作者明确说"没有在本文中评估"的方向：自我改进 Agent。传统架构下 Agent 修改自己的规则之所以危险，恰恰因为它不可见、不可逆。在 ActiveGraph 里，规则和行为是日志状态的一部分，自我修改本身就是一个事件。你可以重放修改前的运行，严格重放会精确揭示行为从哪一刻开始偏离。更关键的是 fork-and-diff 作为评估原语：提议一个改进，在提议点分叉，应用改动，跑完，和父分支做结构化 diff——共享前缀从缓存读取，每次候选改进的评估成本接近于零。

没解决的问题，论文自己先说了

论文也没回避问题。响应式架构可能跑飞或死循环——防御是预算上限，超标就停，但这不是静态的终止保证。重放成本随日志长度线性增长，百万级事件目前只能全量重放，没有 checkpoint 或压缩。外部工具有副作用的，首次执行时该怎样还怎样，只有记录是可重放的。并发写入和多 Agent 争用共享图的问题没解决。确定性契约只在重放时动态检查，写的时候不报错。论文没有报告任务性能的大规模实证评估——这是系统和架构贡献，不是基准研究。

论文最后一段值得全文引用："我们所展示的是，一个单一的反转——将追加式事件日志视为 Agent 本身而非其废气——买到了一组否则难以同时获得的属性：包含模型调用的计算的确定性重放、不需要为共享历史重新付费的反事实分叉、以及从目标到输出的完整血缘。对于那类必须能够解释、复现和修正 Agent 所做事情的长期运行 Agent 系统，这些属性不是便利品。它们就是意义本身。"

开源实现用 Apache-2.0 协议。pip install activegraph，然后 activegraph quickstart 就能跑通完整 demo，不需要 API key，三十秒内完成，两次运行产生字节级一致的日志。

论文地址：https://arxiv.org/abs/2605.21997 开源仓库：https://github.com/yoheinakajima/activegraph 文档：https://docs.activegraph.ai