Datadog 如何為 Claude Code 打造通用的 machine tool（第 3/3 段） ☕ Buy me a coffee

🧑‍🏫 這段是 Datadog 工程師在介紹他做的工具 TEMPOR 的核心機制。agent 是能自己規劃、呼叫工具完成任務的 AI。在 TEMPOR 裡，agent 不直接寫一大堆程式，而是先寫一份精確的「設計藍圖」，工具檢查過後把它轉成規則表，再直接換上正在運作的系統。這段值得看，因為它回答了一個很實際的問題：AI 寫出來的軟體，要怎麼樣才能放心用在正式環境？

• 20:34 Blueprint 要回答的問題包括：哪些 invariant 必須成立、tool call 失敗時該怎麼處理
  ↳ Blueprint（藍圖）是 agent 動手前寫的設計說明。它得先講清楚兩件事：invariant，也就是無論如何都必須成立的條件；還有呼叫工具失敗時的備案。
• 20:34 agent 通常會經過多輪對話才定出 blueprint，類似它自己的 plan mode；產出的是精確的宣告式產物（declarative artifact），不是 markdown 檔
  ↳ 藍圖不是一次寫好，agent 會跟你來回討論好幾輪，很像 Claude Code 先規劃再動手的 plan mode。最後產出的是格式嚴謹、只寫「要什麼」的宣告式文件，不是隨手記的筆記。
• 20:34 TEMPOR 的角色像編譯器：先驗證 blueprint，再熱部署（hot deploy）進 runtime
  ↳ TEMPOR 的角色像編譯器（把寫好的東西翻成機器能執行的形式）：先檢查藍圖，通過了才熱部署，也就是不停機，直接換進 runtime（程式實際在跑的環境）。
• 21:04 Erlang Beam 也是用這種方式做熱部署的 runtime
  ↳ Erlang 是以穩定著稱的程式語言，Beam 是它的執行環境。Beam 本來就能在系統不停機的情況下換上新程式碼，TEMPOR 走的是同一種路線。
• 21:04 執行起來跟一般 CRUD 形式的 API 沒兩樣，使用者感覺不出差別
  ↳ 對使用的人來說，用起來就跟一般 CRUD API（新增、讀取、修改、刪除資料的標準介面）一樣，完全感覺不出背後換了做法。
• 21:04 agent 不直接產生任意的應用程式碼，而是把抽象層級拉高：它產生結構化描述，再編譯成 runtime 的形態
  ↳ 關鍵是把工作的層級拉高：agent 不寫一行行自由發揮的程式，而是描述「系統有哪些狀態、怎麼切換」，再由工具轉成能執行的形式。
• 21:34 編譯步驟在 LLM 之外進行，就像寫好 Rust 程式碼交給 Rust 編譯器一樣
  ↳ 「轉成可執行形式」這一步不靠 LLM（大型語言模型）去猜，而是交給規則固定的程式處理，結果每次都一樣。就像寫完 Rust 程式，交給編譯器處理一樣。
• 21:34 TEMPOR 把 blueprint 轉成 formal state transitions，這在函數式程式設計和 actor runtime 中很常見；講者說這是最重要的技術細節
  ↳ TEMPOR 把藍圖轉成正式的狀態轉移：系統現在是什麼狀態、遇到什麼事、會變成什麼狀態，全部列清楚。講者說這是整套做法最關鍵的技術點。
• 21:34 這裡的 formal 不代表每個性質都經過證明，而是指應用程式的基本形態用精確的轉移系統來表示，比任意程式碼更容易讓人類和 agent 推理
  ↳ 這裡的「正式」不是說每件事都用數學證明過，而是系統的骨架用精確的規則表來描述。比起一大段自由寫的程式，人和 agent 都更容易看懂它會怎麼跑。
• 22:04 舉例：Helix rollout 的 spec 由 agent 撰寫，內容由 states、actions、triggers 組成
  ↳ 舉例來說，Helix 的 rollout（分批把新版本推上線）規格是 agent 寫的，內容只有三種東西：states（狀態）、actions（動作）、triggers（觸發條件）。
• 22:34 講者看到 cloud managed triggers 的發表後想到，也許 trigger 可以直接在 spec 裡宣告，交給 cloud 執行
  ↳ 講者看到雲端代管觸發器（由雲端服務在指定時機替你啟動動作）發表後，就想到：觸發條件也許可以直接寫進規格，交給雲端去執行。
• 22:34 例子：start rolling 只在 planned 狀態下有效，執行後 entity 進入 rolling，並觸發 side effect，例如 patch 一個 Kubernetes stateful set（這個操作不是 idempotent）
  ↳ 例如「開始推送」只在「已規劃」狀態下能用，執行後進入「推送中」，並修改 Kubernetes（管理伺服器上程式的平台）。這個動作不是 idempotent（做一次跟做多次結果相同），不能隨便重做。
• 23:04 side effect 完成後會有 callback 回來，決定要標記進度還是標記失敗
  ↳ 外部動作做完後會 callback，也就是主動回報給原系統。系統再依結果決定：記一筆進度繼續往下走，或是標成失敗。
• 23:04 TEMPOR 把 spec 生成轉移表，讓關鍵控制邏輯變成類似資料的形式，而不是寫死在命令式程式碼裡的義大利麵
  ↳ 整份規格會轉成一張轉移表，控制邏輯變得像一張資料表，不再是散落在程式各處、互相纏繞的「義大利麵程式碼」。
• 23:34 類似資料的控制邏輯可以替換、可以檢查，不會藏在臨時拼湊的一串 service method 裡；對 agent 來說更好操作，也能安全地動態修改
  ↳ 規則像資料一樣攤開來，就能整段抽換、逐條檢查，不會藏在一堆臨時拼湊的程式片段裡。agent 改起來更順手，系統運作中也能安全調整。
• 23:34 講者看過有人寫 Erlang script 熱部署進 Beam，認為讓 agent 使用這類在高可靠系統中高度強化的 runtime 是很有創意的做法
  ↳ 講者看過有人寫 Erlang 腳本直接熱部署進 Beam。他覺得讓 agent 去用這種在高可靠系統裡久經考驗的執行環境，是很有創意的點子。
• 24:04 如果 rollout 需要新的狀態或 rollback 路徑，agent 可以針對 spec 做局部修改後 hot reload，不必走 CI 和部署流程，迭代更快
  ↳ 如果推送流程要多一個狀態或一條回退路線，agent 只要改規格裡那一小段，再重新載入就好，不必等 CI（自動測試與建置流程）和整套部署跑完，改得快很多。
• 24:04 讓 agent 跑一整夜，也能在不犧牲安全、PR review 和 code review 的前提下取得不錯的進度
  ↳ 所以就算讓 agent 整晚自己跑，也能有實質進度，同時不放掉安全性，也保留 PR review、code review（別人審核程式修改）這些把關。
• 24:35 Policy gates：因為轉移表是類似資料的形式，TEMPOR 會把狀態轉移和 policy 決策放在一起評估
  ↳ Policy gates（規則關卡）：因為轉移表是資料形式，每次狀態要切換時，TEMPOR 都會同時檢查這次切換合不合規則。
• 24:35 policy 可以規定誰能修改 deployment rollout、operator agent 能做到什麼程度、哪些動作禁止 builder agent 執行（在 dark factory 中）
  ↳ 規則可以規定誰能改推送流程、負責營運的 operator agent 能做到哪、負責建造的 builder agent 不准做什麼。dark factory 原指關燈也能運作的無人工廠，這裡指一群 agent 分工的地方。
• 25:05 人類也可以獨立設定規則，例如已完成的 rollout 能不能再跑一次、tool 回傳失敗後能不能繼續走 rollout 路徑
  ↳ 人也能另外訂規則，例如：已經完成的推送可不可以重跑？工具回報失敗之後，流程還能不能繼續往下走？
• 25:05 Effects 系統：在 TEMPOR 裡，effect 被刻意設計成很小的 typed operation，避免狀態機變成執行任意應用行為的後門
  ↳ Effects 指系統對外真正去做的動作。TEMPOR 刻意把每種 effect 做得很小、格式固定，避免有人借狀態機偷偷執行任意的程式行為。
• 25:35 真的需要任意應用行為時，可以包成 WASM module；LLM 產生的任意程式碼只放在這個很窄的範圍裡，讓除錯更容易
  ↳ 真的需要自由撰寫的邏輯時，就包成 WASM module（一種在隔離環境裡執行的程式格式）。LLM 寫的任意程式碼只關在這一小格裡，出問題比較好查。
• 25:35 TEMPOR 的最後一個組件是 verifier；講者認為驗證是目前幾乎所有事情的瓶頸
  ↳ 最後一個元件是 verifier（驗證器）。講者認為「怎麼確認東西是對的」是現在幾乎所有事情卡住的地方。
• 26:05 verifier 是轉移表載入 runtime 前的關卡，通過它才能判定安全、允許即時載入
  ↳ 轉移表載入執行環境之前，一定要先過 verifier 這一關。通過了才算安全，才允許在系統運作中直接換上。
• 26:05 verifier 分成多個層級，採 Swiss cheese 模式，不是每一層都得把問題找完；Claude 很會判斷要跑全部還是部分層級，就像它判讀編譯器輸出一樣
  ↳ 驗證分好幾層，像瑞士起司片疊在一起：每片都有洞，疊起來就擋得住，所以不必每層都把問題抓光。Claude 會自己判斷要跑幾層，就像它會解讀編譯器的訊息。
• 26:35 Level 1 檢查自動機的代數結構；Level 2 對可達狀態圖做 model checking，確認有沒有路徑能走到壞狀態
  ↳ 第 1 層檢查狀態機本身的結構合不合規則。第 2 層是 model checking：把所有走得到的狀態都走過一遍，確認沒有任何路徑會掉進壞狀態。
• 26:35 Level 3 執行排程並注入故障，檢查 invariant 能否撐住，例如應用程式的時序失敗；Level 4 用 property test
  ↳ 第 3 層會模擬各種執行順序，並故意製造故障，看 invariant 還守不守得住，例如事情發生的先後順序亂掉的時候。第 4 層是 property test。
• 26:35 講者強烈建議學習 property test，也就是用隨機動作序列做測試
  ↳ 講者強烈推薦學 property test：不是只測幾個你想得到的案例，而是隨機產生一長串操作，檢查某些性質是不是永遠成立。
• 27:05 驗證一開始不會面面俱到，但每補上一個漏洞都會讓 verifier 更強；在正式環境或模擬中發現的缺漏條件，會補進模型或測試集，效果持續累積
  ↳ 驗證一開始一定有漏洞，但每補一個就更強。在正式環境或模擬中發現沒考慮到的情況，就補進模型或測試裡，效果會一直累積。
• 27:05 講者提到 Boris 也講過這種累積效應：找到測試、持續修補缺口
  ↳ 講者提到 Boris 也談過這種累積效應：持續找出該補的測試，把缺口一個個補上。
• 27:35 理想是每個 temper app 或 bundle 的產物都很精簡、行數很少，能整個記在腦中
  ↳ 理想上，每個 temper 應用或套件（bundle）的產出都很精簡、行數很少，小到一個人能整個記在腦子裡。
• 27:35 講者在 Datadog 負責關鍵任務基礎設施，過去三、四年半夜被叫醒上千次；他認為複雜的關鍵邏輯沒辦法全記在腦中來維運
  ↳ 講者在 Datadog 負責不能出錯的核心基礎設施，過去三、四年半夜被叫起來上千次。他的體會是：複雜的關鍵邏輯記不進腦子，系統就很難顧好。
• 27:35 就算是銀行、金融這類複雜的業務領域，也應該用這種方式把業務邏輯寫成人類讀得懂的形式
  ↳ 就算是銀行、金融這種業務規則超複雜的領域，也應該用這種方式，把業務邏輯寫成人看得懂的形式。
• 28:05 如果產出的是上千行糾纏的程式碼，就又回到原點；講者也還不確定 LLM 能否完整審查並簽核這種程式碼
  ↳ 如果 agent 產出上千行互相糾纏的程式，就又回到老問題了。講者也還不確定 LLM 能不能把這種程式完整審完，並替它掛保證。
• 28:05 用幾個小而角色明確的產物，人類和 agent 都能修改系統而不影響周邊；講者認為這本來就是好的系統工程
  ↳ 把系統拆成幾個小而職責清楚的部分，人或 agent 改其中一塊都不會波及旁邊。講者認為這本來就是好的系統設計。
• 28:05 航空、金融等高可靠軟體幾十年來都這樣打造，但靠人力維持這種嚴謹度成本太高，一般軟體負擔不起；agent 正在改變這個算盤
  ↳ 航空、金融這類不能出錯的軟體，幾十年來都是這麼嚴謹地做，但靠人力維持太貴，一般軟體負擔不起。有了 agent，這筆帳開始算得過來了。
• 28:35 回到製造業比喻：關鍵不在單一工匠做出傑出的機器，而是用工具機造出可組合、可檢查、可替換的零件，才能蓋出更大的機器
  ↳ 回到製造業的比喻：重點不是某個老師傅手工做出一台好機器，而是用工具機做出能組合、能檢查、能替換的零件，才蓋得出更大的機器。
• 29:05 講者主張 agent 打造的軟體需要這種嚴謹度才能繼續擴展，尤其是真的要打造資料庫並上線到正式環境時
  ↳ 講者主張，agent 做的軟體要繼續放大規模，就需要這種嚴謹度，尤其是真的要讓 agent 做資料庫、正式上線的時候。
• 29:05 如果 agent 能在工廠中以這種紀律自主打造軟體，或許不必停在 dark factory（講者覺得 dark 這個字聽起來有點悲傷）
  ↳ 如果 agent 能在「工廠」裡守著這套紀律自己造軟體，也許不必只停在 dark factory 那種想像。講者也說，dark 這個字聽起來有點悲傷。
• 29:35 這樣打造的軟體就像有機體，可以透過回饋、選擇和適應來培育、演化，類似農業或定向演化
  ↳ 這樣造出來的軟體像生物，可以靠回饋、篩選、適應慢慢養大和演化，比較像種田，或是刻意挑選想要的特性、一代代培育的定向演化。
• 29:35 例子：因為較多客戶把 Kafka 當 FIFO queue 用，就讓 Kafka 朝 queue 的方向演化，可能需要更多 buffer，不需要那麼多 broker
  ↳ 例如很多客戶把 Kafka（處理大量訊息傳遞的系統）當成先進先出的排隊佇列用，那就讓它往佇列的方向演化：可能多一點緩衝空間，少一點 broker（收發訊息的伺服器）。

在 TEMPOR 的 verifier 中，「Level 2」負責做什麼？