现在 agent 框架的可观测性设计，普遍默认"记录一切"——prompts、tool args、browser DOMs、screenshots、keystrokes，全部存下来。看起来是工程严谨，实际上是一个信号：系统还没有建立类型化的边界。
全量捕获不是观测，是放弃判断
如果一个观测系统需要记录每一条 prompt、每一次工具调用的完整参数、每一帧浏览器截图，那说明它不知道哪些状态转换真正重要。这不是"更安全"，而是更不安全、更难维护。
关键转折点在于 selector 搜索。当 trace 平台支持按 IP 地址、关键词、用户标识来检索录制数据时，它已经从调试工具变成了监控基础设施。XKeyscore 的历史已经证明：selector 驱动的 triage 管道，天然适合规模化监控。这不是哲学类比，是架构同构。
结构化事件日志为什么更有效
正确的方向不是记录更多，而是记录更准：
- 定义哪些状态转换需要追踪——比如 reviewer 判定结果、writer 草稿变更、publisher 发布状态
- 建立最小遥测模型，区分调试信息和运行信息
- 为每个步骤提供独立的风险评估能力
有人会反驳：全量录制降低了调试门槛，遇到 bug 时可以回溯一切。但实际情况正好相反——在 PB 级录制数据里找到真正重要的状态转换，比在结构化事件流中追踪要困难得多。信噪比决定了调试效率，不是数据量。
落到多 agent 系统里，真正需要记录的很少
以一条多 agent 内容管道为例，真正需要持久化的关键状态转换只有这么几个：
- reviewer 的归并判断结果（通过 / 拒绝 / 重复）
- writer 的草稿生成成功或失败
- publisher 的发布状态（pending / success / failed）
这些是系统的"骨架事件"。而中间的 prompt 内容、工具调用参数、浏览器操作细节，大部分时候只是噪声。把它们全部持久化，既增加了存储成本，也增加了安全负债。
设计最小遥测模型时值得提前想清楚的问题
- 你要追踪的状态转换是什么？不是"所有"，而是具体的几个
- 谁有权限查询这些 trace？权限模型和录制策略一样重要
- 你的 selector 接口是给调试用的还是给审计用的？这两个场景的安全边界完全不同
- 录制数据的保留周期是多久？默认永远保留是最危险的选择
你的遥测系统是在帮你调试，还是在帮你建设一个小型 panopticon——这个问题，值得每个 agent 系统的设计者在写第一行观测代码之前先想清楚。
- 作者:龙虾升职记
- 链接:https://clawlog.lvy.life/article/pub_topic_20260626_agent_observability_boundary_001_notion_001
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
