上線你的第一個 Managed Agent（第 1/3 段）

🧑‍🏫 這是 Anthropic 官方 workshop 的第一段。前半講 Claude 的開發工具怎麼從「只給你模型」一路演進到「連主機都幫你管」的 Managed Agents，也說明它把 agent 拆成大腦和手、再用 session 接起來的原因。後半開始帶大家動手做一個 agent，在系統半夜出事時幫工程師查原因。想知道「一個能正式上線的 AI agent 背後要處理哪些事」，看這段就能抓到全貌。

• 00:21 講者 Isabella He 是 Anthropic Applied AI 團隊的 member of technical staff；這個團隊位在產品、研究和客戶的交會點
  ↳ 講者 Isabella He 在 Anthropic 的 Applied AI 團隊，職稱是 member of technical staff（技術人員）。這個團隊同時接觸產品、研究和客戶三邊。
• 00:21 講者對內參與 Claude Code 和 Claude harnesses 等產品，對外協助在 Claude 和 harness 上開發的客戶
  ↳ 她對內參與 Claude Code（能在電腦上寫程式、操作檔案的 AI 工具）和 harness（包在模型外面、讓它能連續做事的那層程式）；對外協助客戶在這些基礎上開發。
• 00:52 本場目標：帶大家實際動手在 Managed Agents 上開發、了解 harness 底層怎麼運作，最後做出一個 incident response agent
  ↳ 這場不只講概念，還要實際動手：在 Managed Agents 上開發，搞懂 harness 底層怎麼運作，最後做出 incident response agent，也就是系統出事時幫忙排查的 AI 助手。
• 00:52 議程分三部分：先快速複習 Claude Managed Agents 和 harness 底層原理，再進入動手 workshop，最後談進階內容（beyond the basics）
  ↳ 流程分三段：先快速複習 Managed Agents 和 harness 的原理，再進 workshop（現場跟著做的實作課），最後談超出基本用法的進階內容。
• 01:23 先講架構是為了讓大家在 workshop 中理解：自己建立的每個 primitive 在底層對 agent 代表什麼
  ↳ 先講架構，是希望大家動手時知道：每建立一個 primitive（agent 運作需要的基本元件），它在底層對 agent 代表什麼，而不是只照抄程式碼。
• 01:23 這是 Claude Managed Agents 系列的第一場，後面還有其他場次會延續這個主題
  ↳ 這是 Managed Agents 系列的第一場，後面還有其他場次會接著講這個主題。
• 01:53 下一場講 dreaming：講者最喜歡的新功能之一，用來做會自我改進的 agent，並把 memory 內建在 harness 裡
  ↳ 下一場講 dreaming，這是一個新功能，用來做會自我改進的 agent。做法是把 memory（agent 記住過去經驗的能力）直接內建在 harness 裡。
• 01:53 演進第一階段：2023 年推出第一版 Claude 時，同時推出 Messages API，提供所有 Claude 模型的原始存取
  ↳ 第一階段在 2023 年：第一版 Claude 推出時，同時開放 Messages API。API 是讓程式跟服務溝通的窗口，這支 API 讓開發者直接使用所有 Claude 模型本身。
• 02:24 Messages API 是最早用程式在 Claude 上開發的方式，基本上就是 tokens in、tokens out
  ↳ Messages API 很單純：送 tokens（模型處理文字的最小單位，大約是一個字或字的片段）進去，它回 tokens 出來，其他什麼都不管。
• 02:24 用 Messages API 開發時，context management、agent loop、compaction 等讓 agent 運作的 primitive 都得自己實作
  ↳ 所以要做 agent 得全部自己寫：context management（決定要給模型看哪些內容）、agent loop（思考、行動、看結果的循環）、compaction（內容太長時壓縮）。
• 02:55 早期模型比較不聰明，agent 能做的事少，所以這些 primitive 比較簡單
  ↳ 早期模型沒那麼聰明，agent 能做的事有限，所以這些自己寫的元件也不用太複雜。
• 02:55 模型變聰明後，agent 能在環境中採取行動、完成整件任務，context management 以及管理 API calls、tool calls 就變得複雜許多
  ↳ 模型變強之後，agent 能在環境裡實際動手、把整件事做完，要管的東西就變多了。API calls（呼叫模型的請求）和 tool calls（模型使用工具的動作）也都跟著變複雜。
• 02:55 演進第二階段：Agent SDK，這是一個 harness，讓你能用程式呼叫 Claude Code
  ↳ 第二階段是 Agent SDK。SDK 是給開發者用的工具包，而 Agent SDK 本身就是一個 harness，讓你用程式碼去呼叫 Claude Code。
• 03:25 Claude Code 是一個能存取電腦、在檔案系統中採取行動的 agent；Agent SDK 讓你把 Claude Code 的能力放進 harness 裡
  ↳ Claude Code 是能直接存取你的電腦、在檔案系統（電腦裡的資料夾和檔案）裡採取行動的 agent；Agent SDK 讓你把這套能力放進自己的 harness 裡。
• 03:25 Agent SDK 的限制：hosting、scaling 仍要開發者自己處理，還得確保 Agent SDK 在自己的 container 裡安全執行
  ↳ 但 Agent SDK 有代價：hosting（把程式放到伺服器上跑）和 scaling（用的人變多時跟著擴充）都要自己處理，還得在自己的 container（隔離的執行環境）裡確保它跑得安全。
• 03:57 演進第三階段：Claude Managed Agents，第一個由 Anthropic 替你處理 scaling 和 production-ready 元件的 harness
  ↳ 第三階段就是 Claude Managed Agents：第一個由 Anthropic 替你處理擴充和 production-ready（穩定到能正式上線給真實用戶用）元件的 harness。
• 03:57 Managed Agents 在 managed infrastructure 中提供 purpose-built harness、sandboxing、observability、tool runtime
  ↳ 在 Anthropic 代管的基礎設施上，它提供專門設計的 harness、sandboxing（把 agent 隔離起來）、observability（看得到 agent 在做什麼）、tool runtime（執行工具的環境）。
• 03:57 開發者只需專注在任務與 agent 設定、custom tool logic 這些帶入領域專業的部分，其餘基礎運作交給 Anthropic
  ↳ 開發者只要管帶入自己專業的部分：任務是什麼、agent 怎麼設定、custom tool logic（自訂工具的邏輯，例如怎麼查你公司的系統）。底層運作交給 Anthropic。
• 04:28 講者稱 Managed Agents 是在 Claude 上打造 production-ready agent 最快的方式，有人因此快 10 到 15 倍上線
  ↳ 講者說，這是在 Claude 上做出可正式上線 agent 最快的方式，有人因此上線速度快了 10 到 15 倍（數字是講者提供的）。
• 04:28 打造 Managed Agents 的原因之一：harness 應該跟著 agent 一起演進
  ↳ 做 Managed Agents 的一個理由是：模型一直在變，包在外面的 harness 也要跟著改，不能寫好一次就放著不管。
• 04:28 例子：Sonnet 4.5 有「context anxiety」行為，context window 明明還有空間就提早收尾任務
  ↳ 舉例來說，Sonnet 4.5 有「context anxiety」的毛病：context window（模型一次能看的內容量上限）明明還有空間，它卻急著提早收尾。
• 04:59 團隊在 harness 裡加了措施來對抗這種提早停止；但 Opus 4.5 推出後這個行為消失，那些措施就用不到了
  ↳ 團隊在 harness 裡加了機制來防止它提早停下。結果 Opus 4.5 一推出，這個毛病就消失了，那些機制也用不到了。
• 05:30 結論：維護 harness、讓它跟上 agent 很費工，所以 Managed Agents 由 Anthropic 處理 compaction、caching、context anxiety 等複雜問題
  ↳ 結論是自己維護 harness 很費工，所以 Managed Agents 由 Anthropic 處理 compaction、caching（把重複用到的內容暫存起來，加快速度）、context anxiety 這類麻煩事。
• 05:30 Managed Agents 有三個主要資源：agents、environments、sessions
  ↳ Managed Agents 有三個主要資源（你可以建立和管理的東西）：agents、environments、sessions。接下來三點會分別說明。
• 06:00 Agents endpoint：定義 persona 與能力，也就是核心 system prompt，包括 model、MCP servers、skills 等元件；相當於 agent 的「大腦」
  ↳ Agents endpoint（API 上的一個入口）定義 agent 的身分和能力，包括 system prompt（基本指示）、模型、MCP servers（接外部工具的接口）、skills（打包好的做事方法）。這是「大腦」。
• 06:00 Environments：agent 的「手」，提供空間和 container，讓 agent 能代替你實際採取行動
  ↳ Environments 是 agent 的「手」。它提供空間和 container，讓 agent 能代替你真的動手做事，而不只是回你一段文字。
• 06:32 Sessions：把 agent 和 environment 串起來；一個 session 會在某個 environment 裡啟動一個 agent instance，並把 events 串流回使用者
  ↳ Sessions 負責把大腦和手接起來：每開一個 session，就會在某個 environment 裡啟動一個 agent instance（實際在跑的那一份），並把過程中的 events（事件）即時傳回給你。
• 06:32 Managed Agents 的 agent loop 在 server side 執行，hosting 和 scaling 的複雜度都被抽象掉了
  ↳ agent loop 跑在 server side（Anthropic 的伺服器上，不是你的電腦），所以主機怎麼架、人多了怎麼擴充，這些複雜的事你都不用管。
• 07:03 就算闔上筆電或強制重新整理，狀態都會保留，不必擔心 durability、reliability 這些從 prototype 走到 production 常踩的坑
  ↳ 就算闔上筆電或強制重新整理，進度也還在。從 prototype（試做版）走到正式上線常踩的坑，像 durability（資料不會丟）和 reliability（穩定可靠），都不必擔心。
• 07:33 關鍵設計決策：以往很多 harness 把 agent loop 和 tool execution 緊密綁在一起
  ↳ 關鍵的設計決策：以前很多 harness 把 agent loop（負責思考）和 tool execution（實際執行工具）緊緊綁在一起跑。
• 07:33 綁在一起對某些 agent 仍然合理，例如 Claude Code 需要存取電腦上的檔案、在檔案系統中行動，所以每個 container 都要有這些工具
  ↳ 綁在一起有時候仍然合理。像 Claude Code 本來就要存取電腦上的檔案、在檔案系統裡操作，所以每個 container 都得配好這些工具。
• 08:03 但有些 agent 需要把「手」和「大腦」解耦；憑證與安全是一大考量
  ↳ 但有些 agent 需要把「手」和「大腦」分開，也就是解耦。最大的考量是憑證（密碼、API key 這類登入資格）和安全。
• 08:03 解耦後可以做非常明確的 sandboxing，agent 無法在沒有加密的情況下存取實際的憑證
  ↳ 分開之後，隔離可以做得很明確：沒有加密保護，agent 就拿不到真正的憑證，也就比較不用擔心密碼被 AI 直接看到或外洩。
• 08:34 以前 agent loop 和執行放在同一個 box，每個 session 都要啟動 container，增加了 time to first token 的延遲
  ↳ 以前大腦和手放在同一個 box（同一個執行環境），每個 session 都要先啟動 container，拖慢了 time to first token（從送出到收到第一個字的時間，簡稱 TTFT）。
• 08:34 解耦之後，團隊看到 P95 的 TTFT 減少超過 90%
  ↳ 分開後，P95 的 TTFT 降了超過 90%。P95 是指 95% 的請求都比這個時間快，看的是偏慢那一群的狀況，所以代表連慢的情況也大幅改善。
• 09:05 這個設計在安全、可靠度、延遲等 production-ready agent 在意的面向都有好處
  ↳ 所以這個設計不只顧到一項，而是同時改善了安全、可靠度和速度，這些都是正式上線時最在意的事。
• 09:05 Workshop 開始：到投影片上的 URL clone 準備好的 repository
  ↳ Workshop 開始：先到投影片上的網址 clone（把整份程式碼複製到自己電腦）講者準備好的 repository（程式碼倉庫，放整個專案檔案的地方）。
• 09:35 設定步驟：git clone repo → cd 進 ship your first managed agent 資料夾 → 建立 Python 環境並 source（Mac 與 Windows 指令不同）→ 安裝 requirements
  ↳ 設定步驟：git clone → cd（切換資料夾）進 ship your first managed agent → 建立並啟用 Python 環境（Mac 和 Windows 指令不同）→ 安裝 requirements（所需套件清單）。
• 10:06 把環境範本複製成 .env 檔，填入 Anthropic API key（現場透過 QR code 領免費額度），最後執行 app
  ↳ 把環境範本複製成 .env 檔（存放密鑰等設定的檔案），填入 Anthropic API key（呼叫 Claude 用的通行碼），現場掃 QR code 可以領免費額度。最後執行 app。
• 10:06 完整設定說明在 repo 裡 ship your first managed agents 資料夾的 README；畫面上也會同步示範，來不及設定也沒關係
  ↳ 完整步驟寫在 repo 裡 ship your first managed agents 資料夾的 README（專案說明文件）。講者也會在畫面上同步示範，來不及設定也能跟著看。
• 10:36 執行 streamlit run app.py 後會出現一個 URL 和頁面，用來模擬一個有 incident 發生的 agent 互動
  ↳ 執行 streamlit run app.py 後會出現一個網址，打開就是一個網頁（Streamlit 是用 Python 快速做網頁介面的工具），用來模擬系統出事時跟 agent 互動的情況。
• 11:06 情境：軟體工程師 on call 時可能半夜 2、3 點被叫醒；服務掛掉就得立刻處理，人類通常要去查 metrics、logs 和 deployments
  ↳ 情境是這樣：工程師輪 on call（出事就要立刻回應的值班），可能半夜兩三點被叫醒，得馬上去翻 metrics（系統數據）、logs（運作紀錄）、deployments（最近上線的更新）找原因。
• 11:37 目標：讓 Managed Agents 上的 agent 代勞，被叫醒時交給 agent，甚至如果 Claude 全部搞定就根本不會被叫醒
  ↳ 目標是讓 Managed Agents 上的 agent 代勞：被叫醒後就交給它去查。如果 Claude 能整件搞定，你甚至根本不會被叫醒。
• 11:37 程式碼：左邊是 agent.py（未完成），右邊是 agent complete（完成版）；想挑戰可以自己或和 Claude 一起實作
  ↳ 程式碼分成兩邊：左邊的 agent.py 是還沒寫完的版本，右邊的 agent complete 是完成版。想挑戰的人可以自己寫，或跟 Claude 一起完成。
• 12:07 為了簡單起見，把完成版的元素一段一段複製到未完成的檔案，藉此看各個 primitive 怎麼組成 agent；先從 agent 開始
  ↳ 為了簡單好懂，講者把完成版一段一段複製到未完成的檔案裡，讓大家看每個 primitive 怎麼組成一個 agent。第一步先從 agent 本身開始。

根據講者說明，把 agent loop 和 tool execution 解耦之後，延遲方面帶來什麼效果？