Datadog 如何为 Claude Code 构建“通用机床”

发布日期： 2026年7月21日

分类： Claude Code

来源： https://claude.com/blog/how-datadog-built-a-universal-machine-tool-for-claude-code

---

Datadog 的所有工程师都使用 AI 编程工具编写生产代码，其中至少三分之二的工作由 Claude Code 驱动。借助 Claude Code，他们在软件开发生命周期中完成四类不同规模的工作：

• 定向改动：大量棘手 bug 修复、性能优化，以及与既有服务的衔接；
• 大型重构：三天内重构自定义 protobuf parser，三个月内把 metrics control 从 FoundationDB 改写到 Postgres；
• 替换大块系统：重新设计 sharding algorithm 和 autoscaling；
• 构建完整系统：将 MongoDB 换为 Postgres、从零构建 BYOC control plane 和 ingestion pipeline。

但随着工作在这张图谱上流动，他们发现一端的生成越来越复杂，另一端的验证则越来越模糊。

Flow 问题

对工程师而言，过去的 flow 是意图与代码之间的直接关系：理解问题、写代码、测试、审查、发布、运行，再重复。Agent 出现后，这层抽象正迅速改变。

Datadog 工程副总裁 Sesh Nalla 说：“你不再亲自写代码，而是在塑造工作。你决定 Agent 该看到什么、该有哪些工具、什么叫成功、如何发现失败……仿佛每个人都在管理链条里连升三级，但工程师本来并没有报名做这件事。”

借助 Claude Managed Agents 等方式，Datadog 的 session 运行时间更长，有时可达数天。每个 Agent 都会发明自己的工具、glue code 和约定。它们更有用，但仍需要人把 Agent 的执行过程与原本为人类设计的工具连接起来。

制造业中的机床包括夹具、治具、量具和铣床。它们能制造精确、可重复的零件，再把零件组装为发动机、飞机、核反应堆和登月模块等更大、更复杂的机器。工业化之所以能够突破，正是因为零件变得可组合、可检查、可替换。

Sesh 把 Temper 描述为 Datadog 对 Agentic 系统“通用机床”的探索：为 Agent 安全、精确地构建所需能力而提供的最小内核。

他说：“我意识到需要一种更具结构性的东西。如果 Agent 要构建、运行我们系统和数据库中很大一部分关键任务组件，它们也需要相当于机床的概念。Temper 就是 Datadog 的这台机床。”

通向 Temper 的道路

机械化意味着 Agent 承担更多工作；工业化则意味着工作能被重复、验证、控制和扩展。在 Datadog，这并非一蹴而就。通向 Temper 的道路经过了 Courier、BitsEvolve 与 Helix 三个项目；每个项目都暴露了下一步的瓶颈，也使团队能提高目标。

2024 年，他们推出分布式排队系统 Courier，完全从零手写花了一年。Sesh 说，难点不是造出各个部件，而是让部件之间的交互可观测、可测试、可验证。因此团队严格采用 formal modeling 与 simulation，找出错误代价高或难以逆转的地方，并提高这些部分的严谨性。

2025 年 9 月，他们构建 BitsEvolve ，一个闭环 evolutionary optimization harness。多个模型组成的 council 生成代码变体，一系列 benchmarks、测试和生产可观测性决定哪些变体被保留。Sesh 说，这是他第一次看到软件的一部分能像生物体一样被培育：通过变异、反馈和适应不断生长。

但进化效果取决于它所适应的环境，BitsEvolve 的瓶颈正是反馈闭环。后来，他们构建了 Helix，一个可与 Kafka 相比的流服务。Claude Code 在一名人类的引导下完成了大部分构建。

Sesh 说：“令我们难以置信的是，几天内我们就得到一个功能完整、可与 Kafka 比较的系统。它建得很快；我们开始 shadow 它，并发现其成本有机会低 2 到 5 倍。”不过，要进入生产则需要更多时间：运维加固必须在实际使用中逐步赢得，且要经过不止一人的工作，目前仍在逐步推出。

瓶颈再次移动：Agent 已能构建系统的大部分，但人类仍需通过为人类打造的工具和机制协调、把工作发布到生产环境。Datadog 因而需要一种让 Agent 在经过验证、受 policy 驱动的运行环境中自行构建工具的方式，这个 runtime 就是 Temper。

Temper

Agent 产生代码的速度快过任何团队人工审查的速度，但它们仍可能犯错。对 Sesh 来说，Agent 生成的内容与通过验证的内容之间的缺口，正是失效模式累积的地方。仅仅把 Agent 包装在传统 codebase 外面，只是把问题当成吞吐量问题，并没有闭合验证缺口。

Temper 把这个关系倒了过来：Agent 不生成 application code，而是生成 specification。kernel 读取每份 specification，通过四层分析验证它，然后部署该 specification 描述的运行系统。因为 specification 同时是被证明的 artifact 和被执行的 artifact，验证内容与实际运行内容之间不会产生漂移。

Sesh 说：“Temper 改变了系统的中心。Agent 不必为每个局部需求不断发明互不相连的工具；它会输出精确的描述，作为意图和问题领域的 specification。这和机床的含义相同：就像把螺纹需要的规格交给夹具或 CNC machine。它极其可重复，你可以让它们运行，并用它们造飞机及其他复杂事物。”

在这种模式下，Agent 不再每次都即兴构造最终机制。它先产出精确描述，并与 Temper 或类似机制迭代以实现可用结果；随后将其变成可重复、可检查、可复用的组件，从而能够围绕 codebase 建立 software factory。

每项能力都由三份 contract 描述：

• Behavior：必须成立的状态、转移、前置条件与安全属性；
• Data contract：实体类型、属性和各类型支持的操作，以机器可解析形式发布，使 Agent 无需文档即可发现完整 API；
• Authorization：默认拒绝、按 scope 批准；拒绝项会记录为待定决策，人员可批准后将其 hot-load 到 policy engine。

每份 spec 在 kernel 加载前都必须通过四层独立验证。symbolic reasoning 证明每个 guard 可满足、每个 invariant 具归纳性；exhaustive state exploration 遍历每个可达状态。

deterministic simulation 在真实生产代码路径中执行带 seed 的 fault injection，例如丢包、延迟、重排序和崩溃，因此同一个 seed 下可以精确复现故障。

randomized property testing 运行约一千组伪随机动作序列，并把所有违规收缩为最小 counterexample。对于小型 spec，整条验证链远少于一秒即可完成。

Helix 的 dark factory

Simon Willison 推广了 dark factory 一词，指 Agent 能在虚拟“工厂车间”持续工作而无需人留在现场的软件流程。在 Helix 的 dark factory 中，Temper 扮演三种角色：

• 它是 Managed Agents 的 agent control plane，负责 sessions、roles、work queues 和 lifecycle；
• 它是 tool-builder 层，让 Agent 用小型 Temper app 连接 SDLC 工具（Git、CI、部署）；
• 它是 Helix control API，即围绕 data plane、用于驱动工作负载的 lifecycle 接口。

Sesh 说，令人意外的是，Temper 开始显得比 Agent 基础设施更通用。许多软件归根结底都是围绕 database API 的 control logic：状态、mutation policy、lifecycle transition，以及与外部系统的集成。只要软件具备这种形态，Temper 在某种意义上都可以通用。

为什么不直接构建 CRUD 应用？

Sesh 说，Claude Code 能很好地用 TypeScript 或 Python 构建 CRUD 应用。但在普通 CRUD 应用中，control logic 分散在 routes、database constraints、service code、background jobs 和文档里。即使测试和覆盖率不错，其运行模式（通常是一个 state machine）也依旧隐含在 codebase 中。

“Temper 把 state machine 显式化。Agent 生成的是精确描述，不是任意代码。编译步骤在 LLM 之外，正如你把 Rust 代码交给 Rust compiler。transition table 是数据，而不是埋在 service method 里的意大利面式控制流。Agent 可以在安全约束下动态改动它，并且无需经过 CI 就 hot-reload。”

未来方向

Temper 背后的理念是，每个 artifact 都应小到足以被人完整理解。航空和金融系统等高保证软件数十年来已按此方式构建；但在 Agent 出现之前，让人类达到这一严谨度的成本对通用软件而言过高。

工业革命能够发生，是因为机床让零件可组合、可检查和可替换，从而使我们可以制造越来越大、越来越复杂的机器。

Sesh 说：“如果 Agent 能在这种纪律下，在工厂中自主构建软件，也许不必止步于 dark factory。这样构建的软件开始像一个能够通过反馈、选择和适应持续生长、培育和演化的有机体。”

Datadog 团队的最佳实践	建议
真正的瓶颈是生成还是验证？	假设是验证。Agent 产码已快过任何团队的人工审查；失效模式堆积在“生成”与“已证明”之间的缺口。应投入验证，而不是继续追求吞吐量。
Agent 实际应输出什么？	为 control logic 输出 spec，而不是代码；任意代码则应附带 proof。将编译和证明放在 LLM 外，把 spec 交给 deterministic kernel，使被验证的 artifact 就是实际运行的 artifact。
Control logic 是显式的，还是散落在 codebase 中？	把 state machine 从 routes、service methods 和 background jobs 中抽出，作为 data：一张可由 Agent 在 policy 约束下读取、修改并 hot-reload 的 transition table。
人是否能完整理解每个 artifact？	如果不能，就回到了起点。每个生成的片段都应足够小，才能被推理和审查。

观看完整分享，了解 Datadog 如何构建 Temper：一个受约束的框架，能把一次性 Agent 工具转变为安全、可复用且能在 session 与团队之间累积价值的组件。*