Google DeepMind 如何跑大規模 Agent：
先解決 quota、skills、shared state

先講結論：規模化 agent 的瓶頸，不只在模型

這支 panel 最有價值的地方，是把 agent 從「單一使用者的聰明工具」拉回「多人、多任務、多資源池的生產系統」。在 DeepMind 內部，就算工程師是重度使用者，也不代表他們可以吃掉所有 token 或 cluster capacity；影片描述裡明確提到，DeepMind 員工的 token quota 甚至比付費客戶更差，因為客戶請求必須優先。

換句話說，agent at scale 的第一課不是 prompt，而是營運：誰有優先權、誰可以尖峰使用、誰在 24/7 盯著 cluster、內部團隊突然暴衝時怎麼被請停。這些聽起來不像 demo，但正是 agent 進 production 後最先撞到的牆。

when internal_team.usage_spikes(cluster):
  monitor_24_7.detect_pressure()
  prioritize("customer traffic")
  call_team("please stop or move workload")

skills_library = darwinian_pool()
for skill in engineer_contributions:
  evaluate(skill)
  keep_only("strongest reusable skills")

deep_research_pipeline.replace(
  old="giant context blobs",
  new="shared file system + artifacts"
)

大規模 agent 不是「讓每個人多開幾個 agent」而已；它需要資源治理、可重用技能、市場式淘汰，以及跨元件共享工作狀態。 — 本頁依 YouTube RSS、watch metadata、oEmbed 與影片描述整理

Quota 是產品承諾，不是內部便利

影片描述中最反直覺的一點是：DeepMind employees have worse token quotas than paying customers。這不是公司內部資源不足的尷尬，而是平台治理的明確選擇。只要 agent 真的進入 production，quota 就會變成 SLA、成本、延遲與信任的交會點。

對工程團隊來說，這意味著內部 AI 平台不能只靠「大家自律」。當 power users、批次研究任務、互動式工具與客戶流量共用底層資源時，必須有優先級、監控、人工介入與成本邊界。否則最熱情的內部使用者，反而可能傷害真正付費的使用場景。

Skills library 需要達爾文式機制

第二個重點是 skills library。DeepMind 的內部情境不是少數平台團隊關起門寫工具，而是大量工程師都能貢獻 skills。這會帶來速度，也會帶來重複、品質不一、命名混亂與長期維護成本。

所以影片描述用 Darwinian skills library 這個說法很關鍵：不是所有 skill 都應該永久留下。真正可規模化的 library 需要觀測哪些 skills 被用、在哪些任務有效、哪些只是一次性 hack，然後讓強者留下、弱者退場。這比單純「開放大家投稿」更接近內部平台工程。

Deep Research 的下一步：不要再把所有狀態塞成巨大 context

KP Sawhney 目前聚焦的方向，是把 Deep Research pipeline 裡的巨大 context blobs，替換成共享檔案系統。這個方向很有工程含義：多個 research components 不應該只透過一大包 prompt/context 交接，而應該像人類研究團隊一樣，在共享工作區裡讀寫中間產物。

這也讓 pipeline 能產生目前架構難以支持的 supporting artifacts。當中間狀態是檔案、摘要、表格、引用、草稿、檢查清單，而不是藏在某一輪上下文裡，後續元件就能獨立協作、追蹤、重跑與審查。

實務啟發：把 agent 平台當 distributed system 管

來源與限制

本頁使用 YouTube RSS、watch 頁 metadata、oEmbed 與影片描述整理；YouTube watch metadata 顯示有英文自動字幕 track，但 timedtext 端點回傳空內容，因此未使用逐字稿。章節時間為依 25:13 影片長度與描述重點整理的內容地圖，非官方 timecode。