分钟到天级反馈：可观测性

测试和 CI 回答的是"代码是否正确"。但还有一类问题它们回答不了：代码在真实环境里跑起来之后表现怎么样？

可观测性提供的就是这个层次的反馈。日志、指标、链路追踪构成了运行时信号的三根支柱。日志记录离散事件（发生了什么），指标记录聚合趋势（系统状态如何变化），链路追踪记录因果关系（一个请求经过了哪些服务，在哪里变慢了）。

对 Agent 驱动的开发来说，可观测性补全了反馈光谱中测试覆盖不到的区间。静态分析管毫秒级的语法问题，测试管秒级的逻辑问题，CI 管分钟级的集成问题。可观测性管的是小时到天级的运行时问题：内存是不是在缓慢泄漏？错误率有没有在上升？某个接口的 P99 延迟是不是在劣化？这些信号的延迟最长，但覆盖的问题域也最宽。

可观测性还为 Agent 提供了超越"通过或失败"的反馈维度。测试结果是二元的，要么绿要么红。可观测性信号是连续的：延迟从 50ms 上升到 200ms，不算"失败"，但值得注意。错误率从 0.1% 上升到 0.5%，没有触发告警，但趋势不对。这种连续信号对 Agent 的纠偏能力提出了更高的要求，也提供了更丰富的改进空间。

可观测性中的 Tracing 如果运用得当，可以成为校验程序、服务实现是否满足设计的重要数据来源。 Tracing 与日志不同，互为补充。通过 Tracing 数据，我们可以清晰的获得程序行为，从而验证在测试过程中的覆盖面。有了 Tracing，还可以更容易的将故障链呈现给 Agent 进行根因分析，进而修复。让 Tracing 不仅覆盖 Happy path，还应该覆盖错误链路。当一次集成测试跑完完整的或者分业务的集成测试后，除了可以校验最终结果外，Tracing 产生的调用链路也需要通过验证，确保系统到到达正确状态的路径也是正确的。

在实践中，让 Agent 直接消费可观测性数据还存在挑战。日志往往是非结构化的文本，对人类有意义但对 Agent 来说是噪音。海量的指标数据需要先聚合和过滤，否则 Agent 的上下文窗口会被无关信息淹没。有效的做法是构建一个可观测性的"摘要层"：把原始信号加工成结构化的、可操作的反馈。不是把一百万行日志扔给 Agent，而是告诉它"过去一小时内 payment-service 的 5xx 错误率上升了 300%，以下是五条代表性的错误日志"。

还有一个容易被忽略的问题：静态代码分析无法捕捉运行时拓扑的变化。虚拟机迁移到容器、单机房切换到多活架构，这些变化不反映在代码中，但深刻影响系统的运行时行为。可观测性是感知这类变化的唯一手段。