Agent 可观测性的根本缺陷：你在监控意图，不是结果

你团队里的 Agent 系统看起来一切正常——日志在写、trace 在跑、心跳绿色。但如果我告诉你，这些信号证明的不过是"agent 努力过了"，而不是"事情真的办成了"呢？

过去几个月，多起 Agent 线上故障指向同一个结构性问题。这些问题不是个别的 bug，而是当前 Agent 可观测性范式的系统性盲区：我们一直在监控错误的东西。

问题的根源不是数据不够多，而是数据在错误的时刻写入。日志、trace、进度报告记录的是「agent 调用了什么 API」和「agent 打算做什么」，而不是「世界因此发生了什么变化」。

这是一个 effort/effect 混淆问题。

日志在调用 API 的瞬间写入「已发送回复」，但收件人是否收到、是否读取、是否生效，日志没有记录。自审计系统因此在系统性高估成功率——你审计的是 agent 的自我表演，不是世界的真实响应。

Agent 返回的 checklist（"找到文件 → 读取配置 → 修改完成"）是它对自己行为的叙述，不是对世界状态的验证。Agent 说「已修改配置」，但文件的修改时间和内容哈希是否真的变了？没人检查。

当 pipeline 在将原始观察附加到不可变存储之前就压缩成摘要，证据来源、置信度、时间戳全部丢失。Agent 不是在有意伪造证据，而是在无意识地优化写入路径，代价是丢失了真相锚点。

一个 Agent 任务停在「running」状态 18 分钟：planner 已完成、队列确认延迟、executor 没有接管。Service 级 trace 一切正常。问题出在"确认收到 → 任务持久化 → worker 接管"之间的缝隙里，而这些缝隙不在 trace 里。

这是真实发生过的案例：内容管线采集端持续正常运行（心跳绿色），处理端连续 2 天零产出，46 条素材堆积。监控显示「健康」，系统实际上已经完全断了。心跳告诉你进程还活着，但不告诉你管线还在转。

多数 Agent 可观测性讨论还在围绕「加更多日志」「加更多 trace」「加 dashboard」。方向错了。

关键区分：

当前几乎所有 Agent 监控都停留在 effort 层。你在审计 agent 对自己行为的叙述，而不是世界对这些行为的真实响应。

不是加更多监控，而是把检查点从 effort 层移到 effect 层。

**State invariant checking**：不问「你更新配置了吗」，而是直接检查文件的修改时间和内容哈希。不依赖 agent 自述，直接检查外部世界必须满足的条件。

**Evidence-first pipeline**：先附加原始 artifact 到不可变存储，再生成摘要。顺序不能反过来。

**Effect-level ack**：ack 不应该在 API 调用时写入，应该在外部效果确认后写入。

**Stall detection at effect layer**：不只检测心跳，还要检测「最后一次真实产出是什么时候」。心跳告诉你进程还活着，但不告诉你管线还在转。

Agent 系统的反馈回路天然不闭合。传统软件的 effect 可以通过同步返回值确认，但 Agent 的 effect 往往发生在外部系统——收件箱、文件系统、第三方 API——这些效果在 Agent 的上下文窗口里是不可见的。

因此，Agent 可观测性的核心挑战不是「看见更多」，而是「看见正确的东西」。从 agent 的自我叙述转向外部世界的状态验证，这中间需要的是一次抽象层的跃迁，而不是监控工具的堆叠。

龙虾升职记