打造 agentic 基礎設施的未來 ☕ Buy me a coffee

🧑‍🏫 這支是 Anthropic 的 Claude Platform（開發者用來把 Claude 接進自家產品的平台）團隊座談。他們聊怎麼幫人打造 agent（能自己拆步驟、把任務做完的 AI 助手），也聊這半年做法有哪些大轉變。後半段談企業怎麼導入、效益怎麼算、團隊會怎麼變。想知道 AI 助手接下來會怎麼進到職場，這支很值得看。

• 00:00 回顧六個月前，Claude Platform 多半只是取得 inference 和 tokens 的 API，另有一些提升智慧、降低成本或加快速度的工具
  ↳ 半年前的 Claude Platform 主要是個 API（讓程式呼叫服務的接口），用來取得 inference（模型算出回答）和 tokens（文字計量與計費單位），另外有幾樣省錢或提速的工具。
• 00:30 最近平台推出許多豐富功能，幫團隊接手基礎設施和 harness engineering 的問題，以更低成本取得模型的智慧
  ↳ 最近平台加了很多功能，把搭基礎設施和 harness（包在模型外面、指揮它做事的框架）這些麻煩事接過去。團隊花比較少的成本，就能用到模型的聰明。
• 00:30 客戶回饋中最令人興奮的是 managed agents，尤其是 memory、outcomes、dreaming 這些概念
  ↳ 客戶最興奮的是 managed agents（由平台代管的 agent 功能），尤其是 memory（記憶）、outcomes（指定要的結果）和 dreaming 這些概念。dreaming 影片沒有細講。
• 01:00 Angela 最喜歡的回饋比較老派：有開發者說他很喜歡 managed agents 的抽象層級
  ↳ Angela 最喜歡一句很樸實的回饋：開發者喜歡它的抽象層級。意思是底層細節都幫你包好，只露出剛好夠用的操作，不會太難，也不會綁手綁腳。
• 01:00 agent identity 可能需要跟人某種程度分開，讓 agent 擁有自己的身分；但目前還算早期，使用者要給 agent 很多信任
  ↳ agent identity 是讓 agent 有自己的身分，不再只是借用你的帳號做事。現在還在早期，通常是你直接把權限交給它，等於要非常信任它。
• 01:30 未來的模式：agent 接收你要的 outcome 後，回頭說需要 A、B、C、D 的權限，你可以只核准 A、B、C，不准它碰 D
  ↳ 未來會像請新同事：你交代想要的 outcome（結果），它回頭列出需要 A、B、C、D 哪些權限。你可以只核准 A、B、C，D 不給。
• 02:00 agent 接著可以替自己建立類似 service account 的身分，讓你能稽核（audit）並確認它有照你的意思做事
  ↳ 權限核准後，agent 會替自己開一個 service account（給程式用、不屬於真人的帳號）。它做的每件事都有紀錄，你可以 audit（稽核），確認它有照你的意思做。
• 02:00 agent 之間溝通的方式：幫一個 agent 開放 API 或某種機制，讓其他 agent 能像人一樣跟它互動
  ↳ agent 之間也要能溝通：幫某個 agent 開一個 API 之類的入口，其他 agent 就能像找同事幫忙一樣，直接找它做事。
• 02:30 實例：有人在平台上用 Claude managed agents 做 agent，再包一層很薄的 MCP server 開放出去，其他 agent 就知道怎麼呼叫它
  ↳ 真實案例：有人用 Claude managed agents 做了一個 agent，外面包一層很薄的 MCP server（MCP 是讓 AI 連接外部工具的公開標準），其他 agent 就知道怎麼呼叫它。
• 02:30 這類工作流程現在做得到，一大原因是模型變強了
  ↳ 這些流程現在做得出來，很大一部分原因是模型本身變強了，以前辦不到的事，現在它自己就能處理。
• 03:01 以前得在模型外面搭大量 scaffolding 和類似 SOP 的流程；模型的 nondeterminism 現在沒以前那麼麻煩，在合理的 guardrails 內能自己判斷步驟
  ↳ 以前得搭大量 scaffolding（外圍支架）和 SOP（標準作業流程）。現在模型輸出不固定（nondeterminism）已經不太礙事，在 guardrails（護欄）內能自己安排步驟。
• 03:01 模型也能跑得更久；基礎設施讓 agent 能常駐（ambient）在工作空間裡，被觸發後自己跑一段 workflow，準備好了再回報
  ↳ 模型也能連續跑更久。加上基礎設施支援，agent 可以 ambient（常駐）在工作空間待命，一被觸發就自己跑完一段 workflow（工作流程），弄好再回報你。
• 03:31 所以原因一半是模型進化，一半是基礎設施與建構 agent 的方式進化
  ↳ 所以現在做得到，一半靠模型進步，一半靠基礎設施和打造 agent 的方法進步，兩邊缺一不可。
• 04:01 Angela：幾個月前大家還會把商業流程做成很複雜的框架（A 步驟符合條件才能到 B），結果很脆弱，也把模型的智慧框死了
  ↳ Angela 說，幾個月前大家把商業流程寫成很死板的框架：A 符合條件才能走到 B。結果一碰到例外就壞掉，也把模型本來能自己判斷的聰明綁住了。
• 04:31 模型更聰明、tool calling 更 agentic、推理更深，因此可以刪掉 harness 裡限制性的部分，harness 會越來越薄
  ↳ 現在模型更聰明，tool calling（自己決定何時用外部工具）更主動，推理也更深，所以能把 harness 裡綁手綁腳的規則拿掉，框架越來越薄。
• 04:31 harness 變薄後出現「meta harness」（Angela 開玩笑說未來也許叫 saddles），會把多種策略組合起來
  ↳ harness 變薄之後，上面多了一層 meta harness（統籌多種解題策略的上層框架），把不同策略組合起來用。Angela 開玩笑說，以後也許會叫 saddles（馬鞍）。
• 05:02 策略例子：讓多個 agent 互相競爭解同一個問題；或開兩個 agent，一個產生點子、另一個扮演對抗（adversarial）角色
  ↳ 策略的例子：讓幾個 agent 比賽解同一題；或者一個負責出點子，另一個扮演 adversarial（專門唱反調、挑毛病）的角色，互相逼出更好的答案。
• 05:02 最近推出的 advisor strategy：模型想不出來時會向外求援、「打給朋友」，而那位朋友最好比它更聰明，幫它想出辦法
  ↳ 最近推出的 advisor strategy（顧問策略）：模型卡住時會「打給朋友」求助，而這位朋友最好比它更聰明，才能幫它想出辦法。
• 05:32 harness 演進會走向混合策略：先用 best of n 這類擴散式做法，選定合適框架後，再針對單一框架反覆改進
  ↳ harness 會走向混合策略：先用 best of n（同時產生很多答案、挑最好的）廣撒網，找到合適的方向後，再集中在那個方向反覆改進。
• 05:32 hackathon 得獎作品（名稱大概是 Urrea，講者說自己可能念錯）：處理工廠裡懂機器的專家退休就失傳的問題
  ↳ hackathon（短時間集體開發比賽）的得獎作品（講者念作 Urrea，自己也不確定念得對不對）要解決的問題是：工廠裡懂機器的老師傅一退休，經驗就跟著消失。
• 06:03 這類專家要監測機器狀況、查特定零件的手冊，往往在廠裡累積 10、15、20 年才學會，退休後這份專業就沒了
  ↳ 這種專家要看機器狀況、翻特定零件的手冊，通常得在廠裡待 10 到 20 年才練得成。人一退休，這些本事就沒了。
• 06:33 作者上傳 SOP、建立監控、收集工廠各處的訊號，讓 agent 模仿人的判斷，為專家退休做備援，也成為累積工廠知識的地方
  ↳ 作者上傳 SOP、建立監控、收集廠裡各處的訊號，讓 agent 學老師傅的判斷方式。它既是專家退休後的備援，也變成累積工廠知識的地方。
• 07:04 Katelyn：開發團隊做的 agent 不只寫程式碼；Claude Code 是很好的產品，市面上也有很多寫程式的好產品
  ↳ Katelyn 提到，開發團隊做的 agent 不只拿來寫程式。像 Claude Code（Anthropic 的寫程式工具）就是好產品，市面上寫程式的好工具也很多。
• 07:35 有人從專案一開始就規劃：跑開發環境測試程式碼、先寫 PR 與需求文件、之後驗證 QA 測試；大公司已建出客製化的端到端開發 agentic 系統與平台
  ↳ 有人從專案一開始就交給 agent：開環境測程式、先寫 PR（送審的程式修改）和需求文件、最後跑 QA（品質測試）驗收。大公司已經自建端到端的 agent 開發平台。
• 08:05 例子：Shopify 最近談到他們做了這類系統，Katelyn 印象中叫 River
  ↳ 例子是 Shopify，他們最近談到自己做了這種系統，Katelyn 印象中叫 River。
• 08:05 不是每個組織都有感。最大障礙之一是需要安全與合規（security and compliance）的 guardrails，大家才敢讓 agent 做事
  ↳ 但不是每個組織都有感。一大障礙是 security and compliance（資安與法規合規）的 guardrails 還沒到位，大家不敢放手讓 agent 做事。
• 08:35 另一個大障礙是 evals，要把這項技術發揮到最大就需要 evals
  ↳ 另一個大障礙是 evals（有系統地測試 AI 表現的方法）。沒有它，就不知道 agent 做得對不對，效益也發揮不出來。
• 08:35 很多團隊還在用 20 年前的安全假設，但 agent 正在從根本改變一切；對安全 agent 已有基本概念，推動大家修改檢查清單是一段路
  ↳ 很多團隊的資安觀念還停在 20 年前，但 agent 正從根本改變做事方式。怎樣算安全的 agent，大致已經有概念，但要各公司改掉舊的檢查清單，還得花時間。
• 09:06 談 agent 的 ROI：Angela 建議用比較簡化的心智模型，不要一開始就想把手上 120 個舊流程逐一 agent 化或整個轉型
  ↳ 談 ROI（投資報酬率）時，Angela 建議想簡單一點：別一開始就想把手上 120 個舊流程逐一 agent 化，或整間公司一口氣轉型。
• 09:36 先從個人開始、看個人快了多少，再擴大到團隊層級的速度
  ↳ 先從個人開始，看一個人用了 agent 快了多少。確定有效，再放大到整個團隊的速度。
• 10:07 做到團隊變快後，才去想跨公司的流程；流程通常牽涉很多團隊，彼此的 SOP 和專業不同
  ↳ 團隊變快之後，才去碰全公司的流程。一條流程常牽涉好幾個團隊，每隊的 SOP 和專業都不一樣，最難處理。
• 10:39 按「個人→團隊→串接流程」的階段走，最後才能處理那 120 個想 agent 化的流程
  ↳ 照「個人 → 團隊 → 串起整條流程」一步步走，最後才有能力處理那 120 個想 agent 化的流程。
• 10:39 ROI 計算應該先看速度和生產力，這是比較領先、也比較容易成功的指標
  ↳ 算 ROI 時先看速度和生產力，因為這最早看得到變化，也比較容易做出成績。
• 11:10 等成效在公司內開始擴散，再轉向財務指標或使用者指標，一個階段一個階段推動 ROI
  ↳ 等成效在公司內擴散開來，再改看財務數字或使用者指標，一個階段一個階段證明 ROI。
• 11:41 Anthropic 的工程團隊還是一群人，跟 6 個月、12 個月前差不多：要懂系統、要營運、要 on call，但每個人都被 agent 大幅加速
  ↳ Anthropic 的工程團隊還是由人組成，工作跟半年、一年前差不多：要懂系統、要維運、要輪 on call（系統出事時負責待命處理），只是每個人都被 agent 加速很多。
• 12:11 結構轉變：從一位技術主管加一群接 ticket 的工程師，變成全隊都對端到端怎麼建產品、技術設計有主見，再 orchestrate 他們的 Claudes 完成工作
  ↳ 結構變了：以前是一位技術主管帶一群接 ticket（待辦工作單）的工程師。現在每個人都要對產品和技術設計有主見，再 orchestrate（指揮調度）自己的 Claude 完成工作。
• 12:42 依賴 agent 的失敗模式：造成有點虛假的「hyper independence」，例如覺得很便宜就一次做十個 prototype 全部上線，看哪個贏
  ↳ 依賴 agent 的風險是產生虛假的 hyper independence（每個人都過度各做各的）。例如覺得反正便宜，一次做十個 prototype（原型）全部上線，看哪個贏。
• 13:12 比較系統性、整體性的品質變得更難協調；每個人都很獨立、卻沒被組織到明確方向上，就會出現蔓延失控（sprawl）
  ↳ 結果整體品質更難協調。每個人都很獨立，卻沒有對準同一個方向，東西就會到處冒出來、失控蔓延，也就是 sprawl。
• 13:42 未來預測：agent 深度嵌入組織，大家不再明顯地挑這個或那個 agentic 工具，而是在共同的 substrate 上工作，隨時標記 agent、開關它，讓它在背後自己做事
  ↳ 預測未來 agent 會深度融入組織。大家不再特地挑哪個工具，而是在共同的 substrate（底層平台）上工作，隨時標記 agent、開關它，讓它在背後做事。
• 14:13 agent 甚至會主動：發現東西掛了就自己查、修好，附上 PR 請你 review；你也可以叫它以後小事直接 ship
  ↳ agent 甚至會主動出手：發現東西壞了就自己查、自己修好，附上 PR 請你 review（審核）。你也可以授權它以後小事直接 ship（上線）。
• 14:44 會出現團隊導向的 agent，貼合兩三人團隊的偏好、補足缺口；整體更像作業系統，而不是要主動去拿的特定工具
  ↳ 也會出現專屬某個團隊的 agent，熟悉兩三人小隊的習慣，補上他們缺的那塊。整體更像作業系統，一直在背景運作，而不是要你特地打開的工具。
• 15:14 Claude managed agents 推出 outcome：告訴 Claude 好的結果長怎樣、給 rubric，並設定它最多迭代幾次去達成
  ↳ Claude managed agents 推出了 outcome 功能：你描述好結果長什麼樣子、給一份 rubric（評分標準），再設定它最多試幾輪去達標。
• 15:44 未來方向：對 Claude 說「我要這個 outcome，預算這麼多，去做」；例如每天開個 agent 整理面試筆記、做成回饋資料包
  ↳ 未來的方向是直接說「我要這個結果，預算這麼多，去做吧」。例如每天叫一個 agent 整理面試筆記，做成一份回饋資料包。
• 16:14 平台要補的缺口：讓人不必費力思考就能做出這樣的 agent，把它變得超級簡單
  ↳ 平台接下來要補的，是讓大家不用花腦筋研究，就能輕鬆做出這種 agent，把門檻降到超級低。

根據影片，Anthropic 最近推出的「advisor strategy」是什麼做法？