Build Hour：用 GPT-5.6 做 Valuemaxxing（價值最大化）（第 5/5 段）

🧑‍🏫 這段是 OpenAI Build Hour 最後的問答，講怎麼用 GPT-5.6 才不會亂燒錢。內容包括：Ultra 模式什麼時候該開、讓 AI 分工要分幾層、什麼時候該開新對話，以及快取和壓縮怎麼用。如果你常用 Codex 或 ChatGPT 做長時間的工作，這段能幫你少花冤枉錢。

• 43:38 希望使用者能掌控自己的 token 花費，所以要在 settings 裡自行開啟這兩個選項
  ↳ token 是 AI 計算用量的單位，用越多花越多。官方希望花多少由你自己決定，所以這兩個選項預設是關的，要你自己到 settings 打開。
• 43:38 Ultra 以最大推理為基礎，本來就會盡量用需要的 token；另外會改 system instruction，鼓勵模型更常使用 subagent
  ↳ Ultra mode 會把推理開到最大，該用的 token 都會用。它還改了 system instruction（給模型的底層指示），鼓勵模型多派 subagent，也就是主 AI 派出去分頭做事、做完回報的小幫手。
• 43:38 5.6 是第一個被訓練成原生使用 subagent 的模型。以前的 Codex 模型要你明確叫它用 subagent 才會用
  ↳ 以前的 Codex（OpenAI 寫程式用的 AI）你沒明講，它就不會分工。5.6 是第一個在訓練時就學會自己找幫手的模型。
• 44:08 5.6 會自己判斷哪裡該用 subagent、哪裡不該用；Ultra 模式則把這個行為推到最大
  ↳ 平常 5.6 會自己看情況，該分工才分工。開 Ultra 等於叫它能分就分，把這個習慣推到最大。
• 44:08 Ultra 的 token 用量確實極高。建議只用在需要動用 subagent 做大量工作的極複雜任務；拿來查信就像用火箭筒打麻雀
  ↳ Ultra 非常燒 token。只有超複雜、真的需要很多幫手一起做的大工程才值得開。查個信也開 Ultra，就是大材小用又浪費錢。
• 44:38 subagent 只會拿到它需要的 context：主 agent 派出 subagent 完成任務後再回來
  ↳ context 是 AI 手上拿到的資訊。agent（能自己動手做事的 AI）派出 subagent 時，只給它做那件事需要的資訊，不給整段對話。做完再把結果交回來。
• 44:38 這跟 Codex 的 side chat 不同，side chat 會拿到當前對話的完整 context
  ↳ side chat 是 Codex 裡開旁支對話的功能，會帶著目前整段對話的內容。subagent 只帶必要資訊，兩者不一樣。
• 45:08 Lorenzo：從開發者角度看，兩種做法都能實作。他沒試過，但想過給 subagent 完整 context，那幾乎等於把 context window 分支出去
  ↳ 對開發者來說兩種都做得到。給 subagent 完整資訊，等於把整個 context window（AI 一次能記住的範圍）複製一份分岔出去。這個做法講者只想過，沒實測。
• 45:38 多數實作是讓 orchestrator agent 整理一份 subagent 需要的摘要，在大多數情況下這可能更有效
  ↳ 多數做法是讓 orchestrator agent（負責分派工作的主 AI）先寫一份重點摘要交給 subagent。大多數情況下，這比整包丟過去更有效。
• 46:08 agent depth（subagent 再建 subagent 的委派層數）對效能的影響，講者表示沒有足夠數據可以給建議
  ↳ agent depth 指委派的層數，幫手再找幫手就多一層。層數會不會影響效果，講者說手上數據不夠，沒辦法給建議。
• 46:08 講者的個人經驗：超過約兩層 subagent 效果就變差，因為一直委派會流失大量 context（他強調純屬主觀）
  ↳ 他個人覺得超過大約兩層效果就變差，因為每轉手一次就漏掉一些資訊。他強調這純屬主觀感受。
• 46:39 subagent 最適合能有效平行化的工作：不太需要共享 state、不會動到同一個檔案，可以替每個 subagent 分配獨立路徑
  ↳ 最適合分給 subagent 的是能 parallelize（同時分頭做）的工作：彼此不太需要共用 state（共同的進度狀態），也不會改到同一個檔案，可以各走各的路。
• 47:09 Pi 的實驗結果：用 3 個月前的模型，完全不用 subagent 在成本、效能和時間上都好得多
  ↳ Pi 做過實驗，用三個月前的模型時，完全不分工反而更省錢、效果更好，也更快。
• 47:09 關鍵在於用的是哪個模型、它的 orchestration 能力有多好；把任務從一個 LLM 委派給另一個 LLM 有點浪費
  ↳ 關鍵在模型的 orchestration（協調分工）能力好不好。能力不夠的話，讓一個 AI 再把事情轉給另一個 AI，常常只是白繞一圈。
• 47:39 任務與方向最好盡量由人類或專家主導。不過新模型出來後情況正在改變，GPT 5.6 的 orchestration 能力好很多
  ↳ 任務怎麼拆、方向往哪走，最好還是由人或專家決定。不過新模型正在改變這點，GPT 5.6 的協調分工能力強很多。
• 48:09 多層委派的問題在於第二層 subagent 能否有效協調底下的 subagent。用同類模型或許可以，混用不同模型可能損失效率；整體建議謹慎
  ↳ 多層委派的難處在於中間那層幫手能不能管好底下的幫手。都用同一類模型也許還行，混用不同模型可能掉效率，整體要謹慎。
• 48:40 開新 chat vs 壓縮 context：講者現在不太在意，在 Codex 同一個 thread 可以連續工作好幾天甚至幾週
  ↳ 開新對話，還是讓系統壓縮舊內容繼續聊？講者現在不太在意。他在 Codex 同一個 thread（對話串）可以連續工作好幾天甚至好幾週。
• 48:40 講者一年前還是每件新事都開新 thread／新 chat，以避免 context 雜亂，現在已不太擔心
  ↳ 一年前他每做一件新事就開新對話，怕舊內容混在一起變亂。現在他已經不太擔心這件事。
• 49:10 開新 chat 真正有用的情況：個人設定一開始就載入大量 context，例如很多 plugins、skills 或檔案
  ↳ 真正該開新對話的情況是：你的設定一開始就塞進很多東西，例如大量 plugins（外掛功能）、skills（可重複使用的工作指引）或檔案。
• 49:40 如果這些是模型每次回應都得記住的東西，開新 chat 可能比依賴壓縮更合理
  ↳ 如果這些是 AI 每次回答都得記著的內容，開一個新對話會比靠系統壓縮來騰空間更合理。
• 49:40 有使用者的 chat 超長、什麼都做。例如正在做網站，突然插入一個無關的搜尋；完全不同的任務放在同一個 chat 只是在浪費 token
  ↳ 有人一個對話什麼都做，網站做到一半突然插一個不相關的搜尋。完全不同的任務擠在同一個對話裡，只是在浪費 token。
• 50:10 何時該切換到新 chat 是新的 UX 問題：讓使用者自己決定，還是交給 LLM 判斷？他們仍在思考
  ↳ 什麼時候該換新對話，是新的 UX（使用體驗設計）問題：要讓使用者自己決定，還是交給 AI 判斷？官方還在想。
• 51:10 談過度依賴 caching 的缺點：先對所有請求做基本 audit，檢查 tool call 是否回傳過多 token
  ↳ caching（快取）是把重複用到的內容存起來重用。別一開始就靠它，先做 audit（檢查），看 tool call（AI 呼叫外部工具）有沒有回傳太多 token。
• 51:10 audit 也要檢查：是否把輸出重複塞進 context window，是否逼 agent 做本來寫成程式就能處理的事
  ↳ 檢查時還要看兩件事：有沒有把同樣的輸出一再塞回 AI 的記憶範圍，以及有沒有叫 AI 做其實寫個程式就能處理的事。
• 51:43 做完 80% 的基本工作之後，才能從 caching 得到很大效益
  ↳ 先把這些基本功做完（大約八成的工作），快取才會帶來很大的效益。
• 51:43 caching 是通用概念，通常很有用，但要等準備好、清楚哪些部分會受益時再實作，否則一切會變得脆弱，也可能讓人覺得受限
  ↳ 快取通常很有用，但要等你清楚哪些部分會受益再加。太早做，整個系統會變得容易出錯，也可能讓你綁手綁腳。
• 52:13 壓縮在不同模型與推理等級下，基本 endpoint 的運作應該相同；其中有秘密配方，無法全部公開
  ↳ compression（壓縮）的基本 endpoint（程式呼叫的服務入口）在不同模型和推理等級下應該運作相同。裡面有秘密配方，沒辦法全部公開。
• 52:13 壓縮的本質：把對話歷史轉成模型之後能理解、能使用的表示
  ↳ 壓縮是把聊過的內容轉成 AI 之後讀得懂、用得上的形式，讓對話可以接著往下做。
• 52:43 依模型、推理等級和對話內容不同，編碼進去的東西可能略有差異；機制相同，但每個 chat 的結果可能略有不同
  ↳ 機制都一樣，但模型、推理等級和對話內容不同，壓縮後保留下來的東西會略有差異，所以每個對話的結果可能不完全相同。
• 53:13 整理的資源包括 GPT 5.6 blog、model comparison、agent migration blog 等
  ↳ 官方整理了延伸資料，包括 GPT 5.6 的 blog、模型比較，以及把 agent 換到新模型的 blog 等。
• 53:44 Build Hour 用到的程式碼都放在他們的 repository，可以自行查看
  ↳ 這場用到的程式碼都放在他們的 repository（程式碼存放庫），可以自己去看。
• 53:44 之後會寄出 email 附上所有連結，不必自己抄下來
  ↳ 之後會寄 email，附上所有連結，不用自己抄。
• 53:44 下一場 Build Hour 在 7 月 29 日，主題是 Image Gen 2
  ↳ 下一場 Build Hour 在 7 月 29 日，主題是 Image Gen 2。

講者依個人工作經驗，認為 subagent 超過大約幾層後效果會變差？