subagent vs skills 怎麼選？Anthropic 電商 agent 藍圖：一個領域一個 subagent 是錯的

九月二號，Anthropic 開源了一份 commerce agent（電商代理）藍圖，裡面有兩隻做好的 agent：一隻 shopping agent 裝在你的網站或 App 裡面對客人，一隻 merchant agent 給後台同事用來顧店。同一天還丟了一篇工程深度文，作者是 Matthew Koen 跟 Ali Shazal。

十一則客戶證言，Visa、Mastercard、Accenture、Priceline、Intuit、Shopify、Klaviyo、Wix、Zomato、Square 等都在裡面。Wix 說他們工程師十五分鐘內就跑起一隻會接 prompt 的 commerce agent。

大家都在看那十一則證言。

如果你問我，這份藍圖最值錢的東西不在證言，在那篇工程文的第一段。因為它直接否定了現在多數台灣團隊規劃 AI agent 的方式。

你正在照組織圖拆 agent，而那是錯的

你要做電商 AI 助理，開會第一件事通常是拆分工：客服 agent 管退換貨、選品 agent 管推薦、定價 agent 管促銷、庫存 agent 管補貨。畫成一張圖，漂亮、模組化、每個 agent 各司其職，看起來就像一張組織圖。

很直覺對不對？我們做管理的腦袋本來就是這樣長的。

Anthropic 在 A guide to the anatomy of effective commerce agents 裡面說，這樣做在實務上是次佳解。理由很硬：一段購物對話是一個緊密耦合的 session，橫跨很多意圖、很多回合，需要大量共享脈絡。

在 subagent（子代理）架構下，orchestrator（總調度）手上握著購物車、暫存的變更、客人的偏好、整段對話歷史。而每一次交接給 subagent，都是一次 state-lossy（會掉狀態）的操作。

原文講得很白：每次交接常常拉低 subagent 回覆的品質，接著拖累整體回覆，而且可能多花數倍的 token、多出好幾秒的延遲。

三種稅。狀態遺失稅、token 稅、延遲稅。每交接一次收一次。

更麻煩的是，領域根本切不乾淨。

台灣電商最好的例子就是超商取貨退貨。客人在 LINE 上面問「我上禮拜那雙鞋想退」，這一句話同時要碰訂單系統、物流系統、金流系統、庫存系統，還要判斷有沒有超過七天猶豫期、退貨要不要扣運費、超商退回來的貨要不要立刻回補到可售庫存。

你要怎麼叫一隻「退貨 agent」自己處理完？它手上沒有購物車、沒有商品目錄、沒有客人剛剛講過的話。

要嘛你把這些存取權在每一隻 subagent 都複製一份，要嘛你在任務做到一半的時候交接出去。兩條路都難看。

Anthropic 沒有打臉自己，是業界抄錯了作業

這裡要幫 Anthropic 講一句公道話，因為我看到不少人把這件事解讀成「Anthropic 推翻自己的 multi-agent 主張」。

不是這樣。

Anthropic 2025 年那篇《How we built our multi-agent research system》講的是 orchestrator 加三到五隻並行 subagent，在研究任務上贏過單一 Opus 4 達 90.2%，但吃掉大約 15 倍的 token，而 token 用量本身就解釋了 80% 的表現差異。

請注意那兩個數字的適用範圍：90.2% 跟 15 倍都是研究任務測出來的，不是電商場景的數字。

15 倍不能直接外推到電商，但它呼應了深度文提醒的那筆 token 稅。

所以這兩篇文章根本不衝突。同一家公司，先給了一個「深度研究這樣做很讚」的實驗結果，現在把界線畫出來：對話型任務用 skills，只有狹窄、自成一體、值得給它獨立脈絡視窗的任務才用 subagent。

出問題的是中間那段。業界把一個為深度研究量身測出來的結論，誤植成所有 agent 的預設架構。

那 subagent 什麼時候才對？原文只留兩種場合。

第一種，orchestrator 把它當一個 tool 來呼叫的狹窄、自成一體任務，值得有自己的脈絡視窗。典型就是 deep research subagent：搜尋、讀文件、跑程式、撞死路，全部在裡面發生，最後只有一個精簡答案回到主線。

第二種，那個領域本來就有自己專屬的 agent 跟合規面，例如藥局或金融服務。這時候正解是真正的 hand-off，讓那隻 agent 直接對客人、用自己的迴圈把任務做完。

差別在「對話的所有權」。hand-off 是把客人交出去，那隻 agent 變成客人的對話對象；delegation 則是總調度留著所有權，把領域 agent 在同一個回合裡拉進來又推出去，每交換一次就衰減一次。

那不用 subagent 用什麼？用 skills

Skills 給你很接近的 per-domain 模組化跟脈絡控制，但沒有交接稅。

你知道為什麼嗎？因為 skill 的指令是直接載入那隻已經握有全部歷史的主 agent。沒有人被交接出去，購物車一直在手上。

這就像從「把客人在部門之間轉來轉去」進化到「同一個櫃哥，需要哪本作業手冊就翻哪本」。我以前在百貨做專櫃的時候最怕的就是把客人交給別櫃，一轉手，客人剛剛講的尺寸、預算、要送誰，全部要重講一次，成交率當場掉一截。AI agent 的交接，掉的東西一模一樣。

Anthropic 說在多個企業部署的比較裡，單一 agent 加 skills 在品質上一貫勝過「一個 prompt 包全部」跟 subagent 兩種設計，而且往往每個任務的成本跟延遲還更低。

那要怎麼決定一段指令放 system prompt 還是放 skill？原文給了一條很好用的起點：佔三分之一以上流量的功能放 prompt，其餘放 skill。因為載入一個 skill 要花掉一個 model turn。

安全規則、法務規則、品牌限制、關鍵客人事實（例如過敏），一律放 system prompt，不准放 skill。

照這條規則，商品搜尋會放在 prompt 裡，因為幾乎每個 session 都會用到；而退貨客服、活動企劃這種長尾功能就各自打包成 skill。merchant agent 那邊是一個營運領域一包，銷售分析、庫存、定價促銷各自獨立。

看到這裡如果你覺得「skill 聽起來很好，那我多加幾包」，先等一下。我之前寫過為什麼 skill 越加越多、AI 反而越不聽話，那個坑是真的。還不清楚 skill 到底是什麼的，可以先看這篇 Agent Skills 入門整理。

我自己就在踩這個坑。這個部落格的寫作產線就是用 Claude Code 搭的，裡面同時有 skills 也有 subagent。什麼時候該讓 subagent 去跑、什麼時候該讓主線自己拿著 skill 做完，我試錯過很多次。體感非常一致：只要任務需要「記得前面講過什麼」，交接出去就會掉東西，回來的東西你還得再對一次。

順便戳破一個省錢的迷思

講到成本，多數老闆的直覺是「換一隻便宜的模型」。

原文這段的判斷剛好相反。

第一，在 agentic 介面上，真正推動留存、互動、客單的是結果品質，也就是答案切不切題、任務有沒有真的完成。這件事比省下那零點幾秒的延遲重要得多。

第二，成本要算每個完成任務的成本，不是每次呼叫的成本。

你知道為什麼嗎？一隻比較笨的模型，可能要多跑好幾個回合才做得完同一件事，或者乾脆失敗讓客人重問一次。單次呼叫便宜，總帳更貴。原文甚至指出，更聰明的配置有時候連延遲都贏，因為它把 tool call 規劃得更好、需要的輪次更少。

所以選模型要用整套 eval 掃過去（原文建議 merchant agent 從 Opus 起跳，面對消費者的 agent 從 Sonnet 起跳），拿數字決定，不要拿感覺決定。

上線之後真正會燒到錢的那條

架構決定一次就好。真正會讓你半夜接到電話的是第三段。

原文的核心主張一句話：prompt 是安全行為的起點，但在電商不能是安全的執行點。

因為電商的失誤是財務性的、而且常常不可逆。一條 prompt 規則距離被繞過，只差一次注入攻擊或一個壞樣本。

所以藍圖的做法是：模型只能提案，執行由人或政策決定。

下單、付款、退款、改價、活動上線，全部收束到 harness（外框程式）控制的動作。消費者端做得很絕：checkout tool 只負責把購物車跟一顆下單按鈕渲染出來，而 agent 呼叫的那個後端介面根本沒有扣款方法。它想扣也扣不了。

商家端每個寫入 tool 都只產出一筆暫存變更，要有人在真實介面按下核准才會生效。而且護欄是在核准的當下拿最新的限制重查一次，不是沿用暫存當時的限制。

翻成台灣電商聽得懂的話：這就是你本來就在跑的「行銷提案，主管核准」。藍圖只是把這個 maker-checker 流程從 Google 表單搬進程式碼裡。

還有兩條，我認為對台灣電商特別重要。

一條是寫入跟渲染只認 server 真的發過的 ID。harness 會記錄這個 session 內 server 交給模型的每一個 ID，那是唯一被接受的鑰匙。幻覺生出來的、客人自己貼上的、埋在商品評論裡的 ID，在碰到後端之前就被擋掉。

另一條是受規管的文案由 server 逐字提供。模型只能選要揭露哪個商品，每一個字都從核准過的文案來，而且 eval 會逐位元組比對渲染出來的字串。運費、超商取貨手續費、七天猶豫期，這些東西不能讓模型自己改寫。標錯價在台灣電商是會上新聞的，改價幅度、折扣深度、活動預算的上限，全都要當成護欄寫死。

memory 那段也值得一看：Anthropic 建議非同步寫入，在每個回合結束後（長對話則每幾個回合）由另一個 thread 讀對話存事實。這樣做在他們內部的 commerce memory eval 上，事實召回率比讓 agent 即時存高出 13%，而且完全不佔用客人等待的時間。想多了解 agent 記憶怎麼運作，可以看我之前解碼的兩個記憶原語。

台灣中小電商該怎麼動

先講一件很多人會忽略的事：這份藍圖不附任何 MCP connector，你得自己透過 backend interface 去接你的系統。

意思是，如果你是 91APP、Shopline、Cyberbiz 上面的品牌，這份東西不是你今天下載就能用的。你多半會是等平台把這層做進來。但看懂它，你才知道該去問平台什麼問題。

順帶釐清一個定位，免得跟前陣子的新聞搞混：Shopify 的 UCP 是跨平台的「協定」層，處理不同家的 agent 怎麼跟不同家的店溝通；Anthropic 這份是單一供應商的「架構實作」層，處理你自己那隻 agent 內部怎麼蓋。兩件事互補，不衝突。

► 第一：先把「agent 能不能自己執行」這題答完，再談模型選哪個。 開會第一個問題不該是用 Opus 還是 Sonnet，而是「下單、改價、發折扣碼這三件事，有沒有寫在程式碼裡擋住？」寫在 prompt 裡不算。

► 第二：從小開始，而且是真的很小。 藍圖自己建議 shopping pilot 只實作搜尋跟商品詳情、其餘全部先擺著；merchant pilot 只實作八個唯讀方法，寫入一律拒絕。翻成白話：先讓 agent 會查商品、查訂單、查物流、查庫存、查活動報表，但一筆資料都不准改。報表跟每日摘要照樣能跑。先讓它「會看不會動」。

► 第三：把 LINE 官方帳號當第一個落地點，但先做唯讀。 查訂單、查物流、查退貨政策，這三件事就能吃掉大量客服工單，而且完全不碰寫入，出事的上限很低。

► 第四：prompt caching 這題要去問，不要自己猜。 快取讀取只要新 token 的十分之一，最好的部署跑在 90 到 99% 的 cache hit rate。最常見的錯誤是把時間戳記或當前頁面放在 system prompt 最前面，那會讓快取每一個請求都無聲失效。自建團隊照 Global、Session、Volatile 的順序排；用平台的就直接問平台商一句：「你們的 cache hit rate 多少，有沒有報表可以看？」這一題直接決定你的 AI 帳單。

► 第五：檔期凍結要把 agent 算進去。 雙 11、週年慶、母親節，你本來就會凍結系統上線。agent 是一個部署單位，一個壞改動會一次打到所有客人。自建就先滾 canary；用平台的就要求兩件事：檔期前兩週凍結話術與技能變更，以及提供一個不用重新部署就能單獨關掉某個功能的開關。

最後

工程文結尾那句話我很喜歡：這裡面大部分東西都跟模型無關。tool 呼叫的是你已經在跑的系統，skill 編碼的是你已經在遵循的流程，eval 是你的產品需求文件寫成測試。

以前我們評估一個 AI 專案，第一個問題是「模型夠不夠聰明」。現在真正決定成敗的是「你的系統邊界劃在哪裡」。

而且這套東西的射程比聊天視窗遠。再往後看，你店裡的流量會有一部分來自替客人購物的外部 agent。到時候，讓你自己的 agent 守規矩的那套暫存與核准規則，剛好就是你敢把 tool 開放給外面 agent 的底氣。

想清楚前台要解什麼任務，可以搭配看AI 購物助理該解的三種任務。那篇談客人要什麼，這篇談後面怎麼蓋。

藍圖在 anthropics/commerce-agents，四個垂直範例（零售、旅遊、電信、票務）全部用虛構品牌 ACME，不會真的下單也不會扣款，可以放心跑。官方發布稿在 Building Commerce Agents with Claude。

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。