2026/10/30 · Weekly Radar
LangChain 詳拆內部設計 agent Content Studio：每個 Slack thread 一台沙箱、48 個 skill 加確定性品質關卡、非同步 subagent 與雙迴圈記憶，產出逾 3,000 份素材，單次請求中位成本從約 $8 降到 $0.5。
這篇是 LangChain 的 Amal Irgashev 與 Shreya Talegaonkar 撰寫的長文（約 22 分鐘），拆解內部設計 agent Content Studio 的打造過程。它建在 LangChain 的 Managed Deep Agents 上、在 Slack 中使用，早期產出評價很差，如今能產出以程式碼構成的素材，連這篇文章的宣傳影片也是它做的。文章的五個重點：品味取決於脈絡，例如設計師的原則與回饋背後的理由；每個 Slack thread 有自己的沙箱；為模型弱點打的補丁應隨模型進步而刪除；長時間任務需要共享進度視圖與核准關卡；harness 已開源。
LangChain 的發布、webinar 與行銷活動頻繁，小小的設計團隊不堪負荷。團隊需要三件事：把設計師的判斷編碼成 skill 與檢查、帶媒體工具的客製環境，以及適合多小時協作任務的 Slack 介面。Managed Deep Agents 提供沙箱、Slack 整合、託管工具、分範圍的記憶與排程。
產出超過 3,000 份素材，含 80 多份簡報，其中一份用在一支熱門 YouTube 影片；含其作品的 X 貼文約 450 萬次瀏覽；在 LangChain 帳號上，帶它做的視覺的貼文按讚約 2 倍、書籤約 3.7 倍；四分之三的請求來自行銷部以外，75% 的使用者每週回訪；單次請求成本中位數從 9 月中約 $8 降到約 $0.5；遷移到 Managed Deep Agents 後團隊自有程式碼減少約 80%。這些數字皆為自行回報。
作者認為模型執行力不錯，但會預設回到熟悉的模式，也就是 Anthropic 所說的 distributional convergence；他們引用 Stripe 的 Katie Dill 對「zombie UI」的警告——外觀保留了、背後的理由卻不見了。結論是模型需要團隊提供觀點。
團隊把品味定義為察覺什麼有效，而 AI slop 出現在 brief 留白的地方。文中並列比較：一個帶品牌 skill 的本地 coding agent 漏掉 logo 組合、對齊與色彩層級，Content Studio 對同一個 prompt 則做對了。給 agent 的指引包括基本 token（色彩、字重、間距）與原則，例如每個畫面只有一個焦點、反 slop 護欄，以及記錄回饋背後的理由。例子是一支鳥的動態圖：「不要尖角」起初反而做出尖銳邊緣，後來 agent 自己寫了逐格檢查，確保緞帶黏在鳥尾上。大小寫這類可量測問題現在都是自動檢查。
第一版給模型 115 個預製 UI 元件與規則，結果版面重複，還得持續投入工程去修補弱點。換上 Opus 5.5 後品質大躍進，團隊拿掉大部分寫死的規則，只留高層原則，產出的變化也變多。作者稱之為「Bitter Lesson」：補償性規則會過期，周遭的環境才會留下。
每個 Slack thread 配一個 LangSmith Sandbox，是一台隔離的 Linux 機器，檔案在 thread 存續期間持續保留。所有素材都是程式碼（HTML 投影片、圖表 spec、動畫時間軸），所以像「讓鸚鵡晚點進場」這種修改只要改一個時間值，不必重新生成。兩套動態引擎：HyperFrames（HeyGen 的開源框架，把影片當成由 GSAP 時間軸驅動的網頁）用於編輯，自製的 motion-studio canvas 引擎處理動態模糊、光暈與 3D，每格最多混合 16 個子時刻。影格依時間戳渲染，任何時刻都能獨立檢查並平行渲染，音訊也在同一條時間軸上。
知識分成四塊。Skill：48 個 skill（約 1,000 個檔案），依工作而非主題劃分；media-production 路由 skill 把請求類型對應到專門 skill；launch-film skill 負責大型製作，內含一支 88 秒影片以程式碼重建的案例，教會 agent 如何把工作分給 subagent。Wiki：品牌 token、語氣、平台、活動與產品資訊，外加動態 wiki 與 70 支參考影片的拆解，skill 連到 wiki 而不重複內容。關卡：針對可量測品質問題的確定性程式檢查。記憶：累積團隊長期的教導。MCP 工具放在搜尋層後面，agent 需要時才載入工具 schema。
分鏡影格約 50 ms 渲染完成，成片則每秒需 8 到 40 秒，所以探索先在分鏡上便宜地做，agent 也能用影像模型生成風格參考。製作分三階段：分鏡、動態分鏡（對齊音訊）、正式製作。作者把順序的強制從 prompt 指示改成程式碼，組裝會等每一幕都通過審查才進行。
Slack 是線性的，很難給空間性回饋。團隊用 Paper——一個帶 MCP server、agent 可操控的設計畫布——讓人與 agent 在同一個檔案上留言與編輯。由於 Paper 的 agent 工具只能在桌面 App 執行，團隊在一台常駐的 Linux worker 上以虛擬顯示器與驗證過的橋接，無頭執行 Paper Desktop。
subagent 非同步執行，讓人在長任務中途仍能持續給回饋。主 agent 為每個 subagent 寫 brief（角色、脈絡、檔案所有權、驗證方式），並選擇它的模型與 effort 等級。協調工具有 start_task、check_tasks、cancel_task、resume_task、report_progress 與 schedule_wakeup；中途訊息會插在 agent 下一次模型呼叫之前；subagent 透過專案資料夾協調。一次 52 張投影片的換皮任務中，主 agent 跑了約一小時，subagent 則合計工作超過六小時。Slack 介面會顯示計畫與預估時間、即時狀態列（執行中的 subagent、渲染進度、花費）、修改確認，以及任何東西公開前的核准卡片。
快迴圈：團隊規則在同一回合就存進檔案式記憶，分共享與個人兩層；AGENTS.md 索引檔每次呼叫都會載入，在其中一個長到 500K token 後被限制在 200 行。慢迴圈：每個任務結束後，learn_from_job 擷取最多五條有證據支持、綁定某個 skill 的教訓，後續任務會為它們評分，每週由背景 agent 把有用的教訓升級進 skill 與 wiki。
團隊希望 agent 能在一個 thread 裡管理整個行銷活動，從 brief 到各管道素材、排程、擴散，以及依成效調整的後續動作，同時保留人工核准。部分已可運作：經核准者簽核後透過 Buffer 發布公司貼文、草擬員工貼文，以及每日建議可引用的貼文。文末連到開源的 design-agent repo、Managed Deep Agents 部署文件，以及 10 月 28 日的 GTM Engineering Live 直播。
架構、每 thread 一沙箱、skill 與關卡分離、非同步 subagent 協調與雙迴圈記憶都具體、對打造類似系統的工程師有用，作者也坦白了失敗與轉向；但文章同時在推銷自家產品，成效數字皆自行回報、缺乏方法與基線，與本地 agent 的比較也只是單一案例。
全篇最有料的是自我否定：115 個預製元件換來千篇一律，Opus 5.5 一來規則就砍光；AGENTS.md 長到 500K token 才被限成 200 行——寫得像事故報告，反而比 KPI 可信。