Cooking with Agents in VS Code：
同一個 codebase，三種 agent 路徑

先講結論：agent workflow 不是「越自動越好」

這支 talk 的價值在於把 coding agent 放回工程流程裡，而不是只展示一個神奇 demo。Liam Hampton 的框架很直接：你要先判斷自己對任務過程的參與程度，再選 local、background 或 cloud。不同任務需要不同的控制感、等待方式與 review 密度。

影片描述的三個 demo 都在同一個 codebase 上進行：local agent 和人一起寫、修 unit tests；background agent 用 git worktree 從 GitHub issue 做前端；cloud agent 在 GitHub Actions 中跑，目標是讓 repo 更適合開源協作。

if task.needs_fast_feedback or task.has_ambiguous_tests:
  run_local_agent(model="Claude Opus", human_in_loop=True)

elif task.is_large and task.can_progress_in_parallel:
  run_background_agent(workspace="git worktree", source="GitHub issue")

else:
  run_cloud_agent(runtime="GitHub Actions", review_when_done=True)

重點不是把所有工作都丟給 agent，而是知道哪一種 agent 路徑符合你此刻需要的控制感、速度與可觀測性。 — 本頁依 YouTube 描述與 AI Engineer schedule 整理

三種路徑的差別

Local agent 是你仍然坐在駕駛座上的模式。適合單元測試、debug、API 邊界、需要即時看 diff 和修 prompt 的工作。它的優勢不是最自動，而是 feedback loop 最短。

Background agent 適合你可以半投入、半切出去的任務。用 git worktree 分隔工作區，agent 可以從 GitHub issue 拉出需求、產出前端，等它跑一段再回來看結果。這個模式的關鍵是任務要能被 issue 描述清楚，並且能承受中途方向不完美。

Cloud agent 則更接近「我只要結果」。它跑在 GitHub Actions 之類的雲端環境，適合把 repo hygiene、開源準備、機械性修補或長時間背景工作交出去。代價是你對過程的即時介入少，必須依賴良好的輸出、log 與 review gate。

VS Code 的角色：把 agent 變成同一個控制平面

影片描述裡很重要的一句是：VS Code 從同一個介面處理三種 agent 路徑，並讓 Copilot、Claude 與第三方 agent 都能進入同一個控制平面。這個方向的產品含義很強：IDE 不只是寫 code 的地方，而是選擇 agent 執行位置、監看進度、切換上下文與收斂 diff 的操作台。

對工程團隊來說，真正需要標準化的可能不是「指定唯一 agent」，而是定義任務進入 local、background、cloud 的條件，並要求每條路徑都能留下可 review 的 artifact。

實務啟發：先設計 routing，再設計 prompt

來源與限制

本頁使用 YouTube RSS/metadata、影片描述、AI Engineer Europe schedule 與 speaker 資料整理。嘗試讀取 YouTube timedtext 字幕清單時未取得可用 track，因此沒有逐字稿；章節時間為依影片描述與 17:03 長度整理的內容地圖，非官方 timecode。