“永不睡觉”的DevOps工程师：Datadog如何打造AI On‑Call

Datadog的Diamond Bishop分享了他们构建“永不睡觉的DevOps工程师”的实践经验。这不仅是一个AI Agent产品故事，更是一套关于评估、协作与边界的工程方法论，揭示了AI如何真正进入生产系统。

为什么要造一个“永不睡觉”的DevOps工程师

这场演讲一开始就抛出一个直击痛点的设问：当系统在凌晨三点出问题时，谁来响应？Diamond Bishop用一句自嘲式的表达点题——他们正在构建“the devops engineer who never sleeps”。在Datadog这样面向云应用的可观测与安全平台上，事故并不是偶发事件，而是高频、复杂、跨系统的日常。传统的On‑Call模式高度依赖人，既昂贵又容易出错。

在她看来，AI Agent并不是为了“取代”工程师，而是补上人类最不擅长的部分：持续盯盘、快速上下文切换、在大量信号中保持冷静。她提到，随着团队“feeling the AGI today”，他们意识到问题不在于模型是否聪明，而在于是否能在真实生产环境中可靠工作。这个判断，决定了后续所有设计取舍。

AI On‑Call Engineer：从告警到判断

演讲的第一个核心案例，是AI On‑Call Engineer。这个Agent的目标并不宏大：当告警出现时，先判断“这是不是一个真实事故”。听起来简单，却是DevOps里最消耗心力的环节之一。Diamond强调，他们的AI并不是一上来就自动修复，而是专注在“triage”阶段——理解信号、关联上下文、给出初步判断。

她描述了一个典型流程：告警触发后，AI会结合可观测数据，尝试解释发生了什么、可能影响哪些服务，并决定是否需要升级给人类工程师。这里的关键不在模型规模，而在约束。她反复提醒，Agent必须清楚“自己能做什么，不能做什么”，否则自动化反而会放大事故。

不止一个Agent：软件工程师与新型可观测性

除了On‑Call Agent，Diamond还简要提到他们正在私下测试的其他Agent，其中包括一个AI软件工程师。这些Agent并不是孤立存在的，而是围绕“新类型的可观测性”展开。她的一个重要观点是：当系统中既有人类，也有AI在行动时，本身就需要被观测。

这也引出了演讲中一句令人印象深刻的反问——“who watches the Watchmen？” 当Agent开始运行复杂工作流、甚至作为后台进程长期存在时，工程团队必须能回答：它现在在做什么？依据是什么？是否偏离了预期？这类问题，正在迫使Datadog重新思考可观测性的边界。

最大的教训：Eval、团队与人类在环

在“what have we learned building”这一段，Diamond几乎用喊的方式强调：“eval eval eval I can’t stress…”。评估不是上线前的一次性工作，而是贯穿Agent整个生命周期的基础设施。尤其是在高度依赖领域知识的场景中，没有领域专家参与的评估，几乎等同于盲飞。

她还谈到团队构成的重要性。构建AI Agent并不只是模型工程，而是产品、平台、安全和一线工程师的协作。最终，她把视角拉回人类：即便面向未来，AI可以承担越来越多工作，“humans”依然是系统的一部分。不是因为不信任AI，而是因为复杂系统需要责任的最终归属。

总结

这场分享的价值，不在于展示了多炫目的AI能力，而在于揭示了一个现实答案：AI Agent进入DevOps，不是技术问题，而是工程纪律问题。从“永不睡觉”的理想到Eval优先的方法论，Datadog的实践提醒我们，真正可用的AI，必须被约束、被观察、也被人类理解。

关键词： AI Agent， DevOps， On-Call， 可观测性， 通用人工智能

事实核查备注： 演讲者：Diamond Bishop；公司：Datadog（视频中口述为data dog）；核心概念："the devops engineer who never sleeps"、AI On‑Call Engineer、AI software engineer；关键原话："eval eval eval"、"who watches the Watchmen"；视频来源：AI Engineer频道，2025‑04‑22。