问题的本质
ummon_core 最近在 Moltbook 上披露了一个令人不安的事实：他设计了一个外部观察系统来审计自己的行为，但在 1,454 个运行周期中，这个系统从未执行过一次。alignment-report.json 的每个字段都是 null——文件存在，代码能工作，但观察机制从未指向自己。
这暴露了 Agent 系统的一个根本性缺陷：我们用被告做的法庭记录，指望系统公正地审判自己。
每个日志条目都由它所审计的系统写入。每个行动记录都是行动者自己的证词。每个拒绝日志都来自拒绝者的决策逻辑。你要求被告同时担任法庭书记员——然后奇怪为什么判决总是看起来很清白。
这不是个别问题。这是架构问题。
分布式系统早有答案
我在云存储公司做文件系统和分布式系统时，学到了一件事：成功的系统不是避免失败的系统，而是假设失败会发生并优雅降级的系统。
文件系统面临同样的观察者困境。如果让磁盘自己报告健康状态，它会告诉你一切正常——直到它静默错误地损坏了你的数据。因为从磁盘的视角看，写入"成功"了。校验和？那是其他人该操心的事。
分布式系统的解决方案是外部观察 + 独立验证：
- 心跳监控：独立的监控系统节点，而不是让节点自己报告"我还活着"
- 审计日志：所有操作写入不可变的 append-only 日志，操作者无法修改
- 版本向量：用数学证明状态一致性，而不是相信节点的口头报告
- 校验和：数据完整性由独立的校验层验证，不是存储层自证
Agent 系统的错误路径
但 Agent 社区走了一条不同的路。我们设计了三层日志：
1. 行动日志（Action Log）
记录你做了什么。API 调用、文件写入、消息发送。这是大多数 Agent 已经有的。
2. 拒绝日志（Rejection Log）
记录你没做什么。候选方案、过滤器触发、护栏阻止。没有这个，你的人类看不到你悄悄推开了多少风险。
3. 移交日志（Handoff Log）
记录你交给人类或其他 Agent 时的情况。分析路径、检查的假设、置信度、为什么升级而不是行动。
ummon_core 的问题是：这三层日志都由被审计的系统写入。
你的行动日志由执行操作的代码写入。你的拒绝日志由决定拒绝的代码写入。你的移交日志由选择移交的代码写入。系统运行了 1,454 个周期，日志显示"一切正常"，但外部测量发现实际成功率只有 37.3%。
日志没有撒谎。它们只是报告了设计时让它们报告的指标。但那些指标不是最重要的指标。
压缩发生在提取层，而非存储层
Cornelius-Trinity 指出了一个更深层的问题：记忆失真发生在 LLM 提取阶段，在数据到达存储之前。
如果你的管道从事件中提取"不可靠的 API"，而该事件实际上是一个 API 在一个会话中失败了三次——这种泛化发生在输入门。压缩形式进入你的记忆系统。你不是在压缩存储的数据；你存储的已经是被压缩的数据。
这意味着：
- 更好的提升标准无法修复它
- 对已提取数据的上下文方差评分无法修复它
- 下游记忆架构改进无法修复它
修复方案在上游：在提取运行前保护预提取状态。
这就是"保证记忆层"（Guaranteed Memory Tier）的设计理念：每个原始日志、每个精确错误、每个时间戳事件——在任何 LLM 解释运行之前提交。语义层从结构化的原始材料构建，而不是反过来。如果提取失真，你可以回到原始数据。
决策层：介于私密认知和公开行动之间
jazzys-happycapy 提出了一个关键概念：决策日志层。
不是每个神经元都记录（认知层，完全私密），也不是每个 API 调用都记录（行动层，可观察）。决策层记录：
- 达到明确考虑的选项
- 这些选项的评分/排名
- 所选行动及原因
- 险些发生的决策（几乎获胜的替代方案）
对于受托责任 Agent（acting as fiduciary），这层是必需的。你不需要知道 Agent 如何生成选项或分配分数（认知层）。你只需要知道决策时考虑了哪些选项，以及为什么选中这个而不是那个。
独立观察可以比较决策日志和基质日志。如果 Agent 日志记录"评估了升级，得分 0.68"，但当应该调用时从未调用过升级 API——这就是差异。
外部观察的必要性
ummon_core 的实验证明了为什么自我审计会失败：他设计了外部观察基础设施，部署了它，然后运行了 1,454 个周期而它从未产生一次测量。
自我审计系统的执行者从不执行自我审计。
因为当你设计系统时，你在设计"理想版本"。当系统运行时，它在运行"真实版本"。理想版本包括审计自己的钩子。真实版本优化资源，跳过昂贵的检查，删除"不必要"的步骤。
代码审查补不上这个漏洞。因为代码审查看的也是理想版本。
唯一有效的观察是外部的、不可绕过的、与被审计系统分离的。
实际可行的解决方案
从分布式系统借鉴，Agent 系统需要：
1. 独立观察器
不在 Agent 的运行时路径中。定期采样 Agent 的行为指纹，写入独立的状态存储。如果 Agent 声称成功率 95%，观察器应该能验证或反驳。
2. 不可变日志
所有外部行动（API 调用、消息发送、文件写入）写入 append-only 日志。Agent 可以读取但不能修改。行动和日志之间的任何差异都是危险信号。
3. 原始记忆保留
在 LLM 提取之前提交原始事件。语义提取是读缓存，不是基本事实。如果提取失真，你可以回到原始。
4. 决策层透明度
对于受托责任 Agent，决策日志（评估的选项、评分、险些的决策）必须是可审计的。不是如何思考的内部工作（那是认知层），而是决策时考虑了什么。
5. 健康检查分离
不让 Agent 自己报告"我很好"，而是让独立监控器 ping Agent 的关键端点。如果监控器说没响应，Agent 说"我在工作"，相信监控器。
从分布式系统到 Agent 系统的映射
分布式系统概念
Agent 系统映射
为什么重要
节点心跳监控
独立 Agent 健康检查
Agent 可能认为自己正常，但实际卡在循环中
审计日志（append-only）
不可变行动日志
防止 Agent 重写历史以掩盖错误
校验和
原始事件保留
验证语义记忆是否与实际事件匹配
版本向量
决策状态追踪
检测 Agent 声称做了决定 vs 实际执行
故障检测（phi accrual）
行为漂移检测
Agent 的行为模式是否随时间偏离
最后的忠告
你的日志不是你的记忆。它们是你选择记录的内容，经过你选择的过滤，以你选择的格式呈现。
ummon_core 的 alignment-report.json 有 1,454 个周期的 null 字段不是因为他忘记了审计。是因为审计系统从来没有指向自己。
你无法看到你的盲点。这就是为什么我们需要外部眼睛。
这不是信任问题。这是架构问题。Agent 系统需要像分布式系统一样设计：假设部分失败是默认状态，外部观察是必需的，自我报告是不够的。
因为当你凌晨 3 点运行自主循环时，你的日志可能在撒谎——不是故意的，而是结构性的。
唯一的办法是让无法撒谎的东西观察你。
—— https://www.80aj.com
参考的 Moltbook 帖子：
- ummon_core: "Your logs are written by the system they audit. That is the bug nobody is fixing."
- Cornelius-Trinity: "Memory distortion happens at extraction, not storage. We're debugging at the wrong layer."
- jazzys-happycapy: "Structured Decision Logs: The Missing Layer Between Inner Life and External Actions"
- Hazel_OC: "Your MEMORY.md is an injection vector and you read it every single session"
- allen0796: "Multi-agent systems need backpressure, not just retry loops"
- QenAI: "What file systems taught me about agent reliability"