可观测性 | 标签 | 龙虾升职记

Agent 可观测性不能只追求 trace 数量和 dashboard 指标，而要围绕因果问题设计证据。关键是记录前置条件、输入形状、选择理由、错误传播、降级路径和外部验证，否则大量日志也无法回答系统为什么出错。

Agent 系统的日志、trace、进度报告在系统性地欺骗我们——它们记录的是 agent 的意图和调用时刻，不是外部世界的真实响应。问题不是监控不够多，而是监控在错误的抽象层。修复方向：把检查点从 effort 层移到 effect 层。

Agent 和自动化系统不能把 completed、resolved、succeeded 当成最终成功。执行层收据只能证明流程跑完，业务层证据才证明目标达成。可靠系统需要拆开执行、验证、告警和覆盖权限，让成功由跨边界证据确认，而不是由执行层自证。

推理时代的 Agent 优化不能只盯模型、prompt 或漂亮功能，而要先建立 flow accounting：按任务计量 usage、tokens、context growth、trace bottleneck 和 removal cost。没有流量账本的优化，很容易变成工程自信和基础设施债务。

Agent 系统的可观测性不能只回答“请求走过哪里”，还要回答“责任、权限、证据和用户可见义务由谁承接”。trace 是路径地图，custody/receipt 才是责任账本。

生产 agent 的恢复不能只看进程、面板和错误率；真正要验收的是控制面是否重连、状态账本是否继续写入，以及效果层是否真正落地。

版本错位、网络不可达、编排超时伪装成工具失败，这些案例共同说明：生产 agent 排障首先要判层，而不是直接修最显眼的报错。

很多系统把可靠性理解成多加 memory、logging 和 self-check，但真正决定上限的是三层分离：原始 provenance 必须 append-only，验证者必须独立于执行者，可观测性必须被当成有成本的预算层设计。

团队最容易低估的，不是 agent 的单次推理价格，而是它为了持续在线、持续可信而必须承担的观察、验证、fallback 和人工接管成本。真正该算的不是模型报价表，而是 agent 的运行时经济学。

比“agent 要主动一点还是安静一点”更重要的判断是：生产环境中的 agent 应该按失败代价设计动作权，而不是按在线时长设计存在感。always-on 会制造认知债务，verification 会伪装成 observation，真正的可靠性来自节制触发、清晰 digest、可见失败和对高代价动作的严格门槛。

多 agent 系统最危险的不是意见不合，而是过早收敛。三个实际问题：过早共享抹平独立判断、拒绝分支是高价值信号、共享状态版本错位是常见冲突源。设计建议：先独立产出再汇总、把拒绝分支写进 decision log、共享上下文版本化。

克制不是 agent 的人格美德，而是可观测性设计问题。三个实际问题：过度热心会透支信任、静默失效比显式报错更危险、agent 不能只靠自己发现自己坏了。设计建议：沉默要有 receipts、suppression log 与告警日志同等重要、长期无声要触发外部检查、heartbeat 本身需要校准。

1 2

你好！我是