Build Hour：Agents SDK（第 4/4 段）

🧑‍🏫 這是 OpenAI Build Hour 講 Agents SDK（OpenAI 提供給開發者打造 agent 的工具包；agent 指能自己分步驟、用工具完成任務的 AI）的最後一段。前半示範讓 agent 直接讀寫雲端上的檔案，後半是問答。問答回答了做 agent 時最常卡住的幾件事：中斷後怎麼接著做、執行環境怎麼管、很多 agent 怎麼分工。

• 36:16 把 bucket 裡的任務檔案指派給 program editor 後，agent 能像操作 container 本機檔案系統一樣讀寫這個 volume
  ↳ bucket 是放檔案的雲端儲存位置。volume 是掛在 container（一個獨立、打包好的執行環境）上的儲存空間。掛上去之後，agent 讀寫雲端檔案，就像讀寫自己電腦裡的資料夾。
• 36:16 可以從網路上任何地方的檔案儲存取得 context。檔案其實是透過網路存取，但對模型來說完全感覺不到
  ↳ 檔案放在哪個雲端都可以，只要連得到，就能當成 agent 的 context（模型做事時看得到的資訊）。其實每次讀檔都在走網路，但模型察覺不到，以為檔案就在手邊。
• 36:46 取捨：模型列出大型 bucket 的檔案時，可能要花比較久，延遲會增加
  ↳ 代價是速度。bucket 裡檔案一多，光叫模型列出有哪些檔案，就得等網路回應，整體反應時間會變長。
• 36:46 好處：能維持資料的新鮮度，也能處理大量檔案，不必全部複製到空間有限的 container 上
  ↳ 好處是 agent 讀到的永遠是雲端上的最新版本，不會拿到過期的副本。檔案再多也不用全部搬進 container，畢竟 container 的空間本來就有限。
• 37:18 Demo 總結：agent 能檢查檔案，能在你選的環境（包括你已在用的環境）啟動 sandbox，能改程式碼，能處理持續數分鐘到數小時以上的 long horizon 任務
  ↳ 整場 demo 示範了：agent 能看檔案；能在你選的環境（包括你現在已經在用的）開 sandbox（隔離的工作空間，弄壞也不影響外面）；能改程式；也撐得住跑數分鐘到數小時的長任務（long horizon tasks）。
• 37:50 Nish 是負責 agents 的 product manager，上台一起回答問題
  ↳ Nish 是負責 agents 產品的產品經理（product manager），後面的問答由他和講者一起回答。
• 38:20 Q：何時用 harness 型 agent，何時只用 Responses API？Responses API 預設就是 agentic API，10 月的 Responses API Build Hour 有介紹
  ↳ harness 是包在模型外面、幫它跑工具和管流程的框架。Responses API（呼叫 OpenAI 模型的介面）本身就能讓模型自己用工具，細節可以看 10 月那場 Build Hour。
• 38:20 如果你用的語言找不到好用的 agentic 框架（例如 Elixir 等較冷門的語言），可以直接在 API 上自己重建這些概念，只是要多花點工夫
  ↳ Elixir 這類比較少人用的程式語言，可能找不到現成的 agent 框架。這時可以直接呼叫 API，自己把這些機制寫出來，做得到，只是比較費工。
• 38:51 Harness 對模型的運作越來越關鍵。Codex harness 和 OpenAI 模型的結合越來越緊密，未來很可能用模型訓練時搭配的 harness 才能發揮最佳表現
  ↳ 模型好不好用，越來越看外面那層框架。Codex（OpenAI 寫程式用的 agent）跟模型綁得越來越緊。模型配上訓練時用的那套 harness，表現很可能最好。
• 39:23 在能直接套用 harness 的環境裡做 agent，很多事會變得非常簡單
  ↳ 如果你的環境能直接套用現成的 harness，很多底層功夫就不用自己寫，做 agent 會省事很多。
• 39:23 一次性任務（例如翻譯一份文件、把非結構化資料轉成 JSON）直接用 Responses API 就很好。搭配 hosted tools，一次 API 呼叫就能完成輕量的 agentic 迴圈
  ↳ one-shot task 指一次就做完的事，例如翻譯一份文件，或把雜亂資料整理成 JSON（一種結構化的資料格式）。這類事直接用 Responses API 就好，搭配 hosted tools（OpenAI 代管的工具），呼叫一次就能完成。
• 39:54 Q：有沒有內建的持久化狀態管理可以暫停與恢復？有。snapshot 機制開箱即用，只需要指定 snapshot 存放的位置
  ↳ 可以暫停之後再接著做。SDK 內建 snapshot（快照）功能，不用自己寫，你只需要決定快照存在哪裡。
• 39:54 Snapshot 可以存在 R2，也可以存在本機磁碟（預設）。它會把一個 sandbox 的檔案系統壓縮後存到別處，讓另一個 sandbox 從中斷的地方繼續
  ↳ 快照預設存在本機硬碟，也可以存到 R2（Cloudflare 的雲端儲存）。做法是把 sandbox 裡的檔案壓縮打包存起來，之後換一台新的 sandbox 解開，就能從停下的地方繼續。
• 40:26 狀態分兩部分：檔案系統，以及對話到目前為止的所有訊息。Agents SDK 會一次處理好這兩者
  ↳ 要接著做，需要兩樣東西：檔案現在的狀態，以及到目前為止所有的對話。Agents SDK 會把這兩樣一起存、一起還原，不用你分開處理。
• 40:26 包含 snapshot 位置指標和完整 rollout 的狀態只是一個 JSON 物件，可以存進資料庫，之後載入就能無損恢復，適合用資料庫共享狀態的多節點系統
  ↳ rollout 指完整的對話紀錄。整份狀態（含快照位置和 rollout）只是一段 JSON 文字，可以存進資料庫，之後原封不動載回來。多台伺服器共用同一個資料庫時特別方便。
• 40:56 Nish 補充：同時儲存 rollout 和檔案系統 snapshot，這點和其他 SDK 相比有點獨特，所以能輕鬆恢復長達一整天的 agent
  ↳ Nish 強調，對話紀錄和檔案快照兩樣同時存，在同類 SDK 裡算少見。所以就算 agent 跑了一整天，中斷後也能輕鬆接回去。
• 41:27 Q：Agents SDK 的 sandbox agent 和真正的 Codex harness 差在哪？兩者只有一些小差異
  ↳ 有人問：用 Agents SDK 做的 sandbox agent，跟 Codex 本身用的那套框架差多少？答案是差不多，只有一些小地方不同。
• 41:27 Agents SDK 內建許多核心能力，例如 bash tool、Codex 編輯檔案的方式、skills、memories
  ↳ Codex 的核心本事 SDK 都有：bash tool（讓 agent 下終端機指令）、Codex 改檔案的方式、skills（可重複使用的做事說明），還有 memories（記住先前資訊的能力）。
• 41:57 Codex binary 是多執行緒的，可以同時跑多個 subagent。Agents SDK 用 handoffs 概念做類似的事，其他部分之後也會陸續補進 Agents SDK
  ↳ 差別之一是 Codex 程式本身能同時派出好幾個 subagent（由主 agent 派出的小幫手）。SDK 目前用 handoffs（把任務轉交給另一個 agent）做到類似效果，其他功能之後會補上。
• 42:27 Q：agent 能自動保存並恢復長時間工作流程嗎？可以。Demo 的編排程式碼很少，只是啟動 SDK、把 rollout JSON 存成筆電上的檔案，之後再恢復
  ↳ 可以。demo 裡串流程的程式碼很少：啟動 SDK，把對話紀錄存成筆電上的一個 JSON 檔，下次讀進來就能接著做。
• 42:57 主要的工程工作是決定要引入哪些 tools、加哪些 skills。任務的啟動、停止、恢復都是開箱即用
  ↳ 所以你真正要花心思的，是決定給 agent 哪些工具和技能。開工、暫停、復工這些事，SDK 都已經處理好了。
• 43:27 Q：任務完成後 sandbox 要自動銷毀還是保持運作？第一種是 SDK-owned sandbox：提供建立 sandbox 的配方（例如 Docker client），SDK 會自動啟動它，並在該回合結束時關閉
  ↳ sandbox 用完要不要收？第一種是交給 SDK 管。你提供建立的方法，例如用 Docker（常見的容器工具），SDK 會自己開機，這一輪做完就自動關掉。
• 43:27 第二種是 user-owned sandbox：在 SDK 之外預先建立 sandbox，再把 reference 傳給 agent。生命週期由你管理，可以保持熱機、跨多個回合使用
  ↳ 第二種是自己管。先在 SDK 外面開好 sandbox，再把它的 reference（指向它的代號）交給 agent。什麼時候關由你決定，可以一直開著，連續好幾輪都用同一台，不用每次等開機。
• 43:58 預設由 Agents SDK 管理生命週期，避免 demo 做完後雲端還有 100 個 sandbox 在跑、持續付費
  ↳ 預設用第一種，是怕大家試完 demo 忘了關，雲端上留著一百台 sandbox 空轉，帳單一直跳。
• 44:34 Q：檔案系統怎麼填入與持久化？Agents SDK 有 manifest 概念，可以把雲端儲存的檔案複製進 sandbox，也可以用 mount 掛載
  ↳ 檔案怎麼放進 sandbox？用 manifest（一份設定清單）指定。可以把雲端檔案複製進去，或改用 mount（掛載：不搬檔案，直接連過去用）。
• 45:04 複製：執行時模型讀檔快，但啟動慢，因為要搬一大包資料。掛載：啟動非常快，但執行時要透過網路讀檔
  ↳ 複製要先把一大包資料搬完，開工慢，但之後讀檔很快。掛載馬上就能開工，但每次讀檔都要走網路。要選哪種，看檔案量和你要的速度。
• 45:04 Agents SDK 讓你用多種方式掛載或複製檔案，並在 sandbox 關閉後把結果持久化
  ↳ 掛載和複製都有多種方式可以選。sandbox 關掉之後，agent 做出來的成果也能存回外部，不會跟著消失。
• 45:34 Q：supervisor agent 能同時監控協調數百個專門 agent 嗎？可以，但需要一些工夫。接下來幾週到幾個月會推出 multi-agent 框架相關功能，讓這件事更容易
  ↳ supervisor agent 是負責管其他 agent 的主管。要它管上百個專門 agent 現在就做得到，但得自己多寫一些。接下來幾週到幾個月會推出多 agent（multi-agent）相關功能，讓這件事更簡單。
• 46:04 協調方式一：透過訊息。給父 agent 一個 tool，讓它知道有哪些 subagent 在跑，並查看它們的進度
  ↳ 第一種協調方式是傳訊息。給主管 agent 一個工具，讓它查得到目前有哪些 subagent 在跑、各自做到哪裡。
• 46:04 協調方式二：讓所有 agent 透過同一個檔案系統或資料庫等機制溝通
  ↳ 第二種是共用同一個地方。所有 agent 都讀寫同一個檔案系統或資料庫，就能看到彼此的進度和成果，像大家共用一個雲端資料夾。
• 46:34 講者認為大規模平行工作在不久的將來會成為預設做法
  ↳ 講者預期，不久之後同時派很多 agent 平行處理工作，會變成一般的預設做法，而不是進階技巧。
• 46:34 資源：螢幕上列出入門 Agents SDK 需要的資料。最下方是 build hour repo，收錄過去各場 Build Hour 的程式碼，本場結束後很快會上傳
  ↳ 最後螢幕上列了入門資料。最下面的 build hour repo（放程式碼的儲存庫）收錄過去各場 Build Hour 的範例程式，這場的程式碼也會很快放上去。
• 47:04 之後的 Build Hour 可以到首頁查看。會後會寄問卷詢問想聽的主題，信中附本場錄影連結
  ↳ 之後的場次可以到 Build Hour 首頁查。會後會寄問卷，問大家想聽什麼主題，信裡也附這場的錄影連結。

根據影片，Agents SDK 的 snapshot 預設存放在哪裡？