LLM 可观测性：来自 Datadog CTO 的 6 条启示

启示 1：AI 打破了旧式代码审查方式

先从一切变化的压力源说起：代码多到没人能读完。

Lê-Quôc 直言不讳：旧模式——人类逐行阅读拉取请求（PR）——无法在 AI 辅助开发中存活。他在行业里听到的焦虑是，审查变得不可能，因为发生的事情太多，仅靠阅读 PR 无法跟上。

他的应对不是让人读得更快，而是把审查迁移到别处。

最后这一点很容易忽略。一旦您编排一个智能体负责规划、一个负责编写、另一个负责测试，您还必须阻止“编写者”利用自动化测试的规则钻空子，而不是解决问题本身。

他的做法超越了测试。Datadog 现在会为 规格是否达标加入半形式化与形式化证明——在没有智能体承担繁重工作前，这样的做法过于耗力而难以普及。它在后端与协调系统中效果最佳，因为这些系统的行为足够“数学化”，便于进行精确推理。

启示 2：生产环境是唯一算数的测试

在 CI 中通过所有测试是必要条件，但远远不够。真正重要的失败发生在后面。

每次发布都建立在无法完全事前验证的假设上，涉及数据形态与用户行为。当这些假设在足够多的真实流量面前经受检验，罕见情形就不再罕见；它们会演变为日常的性能下降与错误，即数据与模型漂移。

LLM 让这更难：在普通代码中，您至少可以穷举每个分支并推理其结果，但没有人能以机械因果解释一个模型为何给出某个返回，因此相同输入也无法保证得到相同输出。偶发的离奇结果无法通过工程手段彻底消除。

因此，您不再试图在发布前证明系统绝对正确。取而代之，您要：

• 为期望的行为编写评估
• 在生产环境中监控
• 为出现问题的发布保留一键停止控制。

问题不再是“是否通过”，而是“这是一次偶发，还是趋势的开始”。

这一实时信号不仅是给人的仪表盘。将其接入部署系统，智能体就能像谨慎的工程师那样滚动发布：先放给 1% 的用户，再到 5%，并依据真实数据判断变更是否达到了预期效果。

启示 3：让智能体承担繁琐工作

Lê-Quôc 为智能体辩护的理由不是取代工程师，而是让它们接手那些最消磨人的工作。

排障意味着针对一个症状不断提出假设，而在持续时间很长的事故中，往往是那个“看似牵强”的假设成真。Datadog 的 Bits AI 智能体会提前并行检查所有假设，而工程师可以据直觉引导它朝向仪表盘难以显露的方向。

更深层的原因是疲劳。值班发布的节奏是瞬间紧张之后的漫长空档，如此反复，直至判断力被磨损。

而智能体不会在意，也不会在盯着数字四小时后变得更糟。压力与疲劳会损害人的表现，这也是团队轮换值班的原因。

把不知疲倦的盯梢交给机器，人就能以更好的状态回到真正需要他们的决策上。安全分流同理，分析师在真假告警中反复筛查也会疲惫不堪。

启示 4：把工作拆成两个闭环

Lê-Quôc 将 Datadog 的智能体工作组织为两个闭环。

开发闭环

大多数工程师都会对第一个闭环感到熟悉：

1. 写代码
2. 发布
3. 验证是否有效
4. 修复
5. 重复

Datadog 的角度是：源于代码的问题，修复通常也在代码中，因此平台会尝试把修复方案直接交到您手中，并结合它对应用的了解——例如归属、近期变更与抛出的错误。

他以数据库查询优化为例。任何模型都能重写一个慢查询；更难的是在进入生产前证明重写更快且安全，因此 Datadog 会先在与生产数据高度相似的副本上进行测试，并附带证据提交一个拉取请求。

运维与安全闭环

另一个闭环并行运行，可能由同一批人也可能由不同团队执行：

1. 检测
2. 调查
3. 处置
4. 重复

在这里，Datadog 的 AI Guard 会对安全事件进行分流，并以快于人工的速度阻断攻击。智能体也能处理工程师日常并不热衷的例行运维事务，比如调整某个 Kubernetes Pod 的大小。

在两个闭环中，Lê-Quôc 对先后次序的态度十分明确。Datadog 不会从“这里有 AI，它能解决什么问题？”出发，而是从客户已经抱怨的问题出发，通常是“我不想做这个重复劳动”的某种版本，然后再反推是否可以放心交给智能体。

启示 5：把控 AI 成本

成本与安全并列为首要约束，控制将大语言模型投入运营的价格，正在成为一门独立学问。Lê-Quôc 在 DASH 给出的答案是 Datadog 的 Agent Console。

问一位开发者需要哪个模型，他们往往会说最强（也最贵）的那个。有时这是对的，但大量工作是样板活，更便宜更快的模型同样胜任。区分两者需要阅读组织内智能体的轨迹、它们调用的工具与成功率，直至出现可识别的模式。

这些模式会形成经验法则而非硬性规则：用最新的 Claude Opus 或 GPT 等前沿模型做规划；用像 Claude Haiku 这类便宜快捷的模型生成测试。

其底层原则关乎决策归属。若把成本汇总为一个数字，就会出现 Lê-Quôc 所说的“操作性极低”：要么大家都停支出，扼杀有用工作；要么大家都继续花，企业难以为继。他更愿意把数据摆在选择模型的开发者与 SRE 面前。

启示 6：学会如何学习

当被问及新工程师该学什么时，Lê-Quôc 给出了一个听起来很“老”却并不老的答案。

模型是有史以来最耐心的导师，能够以任何节奏解释任何事——这种资源以往只属于拥有私人教师的王公贵族。但导师只有在您不断追问时才有用。关键技能在于知道问什么、以及如何验证答案。

他建议分层理解计算机，而不是把它当作魔法。选一个调度器、负载均衡器、沙箱，请模型解释其工作原理，然后不断追问：

• 这个术语是什么意思？
• 如何度量它？
• 它背后的数学是什么？
• 如何判断它工作良好？

以这种方式学习“经典”刻意缓慢。他把这比作学乐器：您可以整天听音乐，但要会弹钢琴，必须把手放在琴键上。

AI 写的代码也是如此。他说，Vibe coding 没问题，只要您会回过头来问它为何有效：为什么这样构建，是否有更好的方法，它以什么为范例。目标不是用 AI 写更少的代码，而是理解如今您能产出更多的这些代码。

结语

Lê-Quôc 的中心信息是：闭环没变，变的是节奏。不同之处在于，没有人类能在 AI 的速度下足够紧密地“看着”，因此“看着”的工作，以及越来越多的“构建”，转移给不会疲倦也不会慌乱的智能体。

他主张把可观测性当作控制平面，而不是一组图表。如果智能体要编写、测试、发布和运营软件，它们需要与优秀工程师相同的现实生产数据作为根基，同时配有人来做判断与掌握“停止按钮”。Datadog 将可观测性定位为让这项权衡变得安全的那一层。

这一框架对工程师提出的要求很明确：通过生产环境中的行为来解读系统，而不只是读源码。如果您想养成这种习惯，我们的 Machine Learning in Production 技能路径是不错的起点。