> ## Content Index > Fetch the complete content index at: https://growthhackers.tw/llms.txt > Use this file to discover other available public pages before exploring further. # subagent vs skills 怎麼選？Anthropic 電商 agent 藍圖：一個領域一個 subagent 是錯的 - URL: https://growthhackers.tw/blog/skills-vs-subagents-commerce-agent-architecture/ - Published: 2026-09-07T13:00:00.000Z - Updated: 2026-09-07T13:00:00.000Z - Description: 業界把「一個領域一個 subagent」當成預設架構，Anthropic 的電商 agent 藍圖說那是錯的。拆解 skills 取代 subagent 的三個理由，以及台灣中小電商該怎麼動。 - Author: Lewis wang - Tags: AI agent, Agent Skills, agentic commerce, Anthropic, 電商 九月二號，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](https://claude.com/blog/the-anatomy-of-effective-commerce-agents?ref=growthhackers.tw) 裡面說，這樣做在實務上是次佳解。理由很硬：一段購物對話是**一個緊密耦合的 session**，橫跨很多意圖、很多回合，需要大量共享脈絡。 在 subagent（子代理）架構下，orchestrator（總調度）手上握著購物車、暫存的變更、客人的偏好、整段對話歷史。而每一次交接給 subagent，都是一次 **state-lossy（會掉狀態）的操作**。 原文講得很白：每次交接常常拉低 subagent 回覆的品質，接著拖累整體回覆，而且可能多花數倍的 token、多出好幾秒的延遲。 三種稅。狀態遺失稅、token 稅、延遲稅。每交接一次收一次。 ![交接稅：購物車在 agent 之間交接的瞬間，狀態、token 與延遲同時流失](https://growthhackers.tw/content/images/2026/09/sv-inline-handoff-tax-v1.png) 交接稅：購物車在 agent 之間交接的瞬間，狀態、token 與延遲同時流失 更麻煩的是，領域根本切不乾淨。 台灣電商最好的例子就是超商取貨退貨。客人在 LINE 上面問「我上禮拜那雙鞋想退」，這一句話同時要碰訂單系統、物流系統、金流系統、庫存系統，還要判斷有沒有超過七天猶豫期、退貨要不要扣運費、超商退回來的貨要不要立刻回補到可售庫存。 你要怎麼叫一隻「退貨 agent」自己處理完？它手上沒有購物車、沒有商品目錄、沒有客人剛剛講過的話。 要嘛你把這些存取權在每一隻 subagent 都複製一份，要嘛你在任務做到一半的時候交接出去。兩條路都難看。 ![一筆退貨請求同時觸及訂單、購物車、商品目錄三個系統，切不成一個領域一隻 agent](https://growthhackers.tw/content/images/2026/09/sv-inline-returns-cross-domain-v1.png) 一筆退貨請求同時觸及訂單、購物車、商品目錄三個系統，切不成一個領域一隻 agent ## 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 反而越不聽話](https://growthhackers.tw/blog/writing-great-agent-skills/)，那個坑是真的。還不清楚 skill 到底是什麼的，可以先看這篇 [Agent Skills 入門整理](https://growthhackers.tw/blog/agent-skills-andrew-ng-course/)。 我自己就在踩這個坑。這個部落格的寫作產線就是用 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 表單搬進程式碼裡。 ![模型只能提案，只有人能按下執行：maker-checker 閘門](https://growthhackers.tw/content/images/2026/09/sv-inline-maker-checker-gate-v1.png) 模型只能提案，只有人能按下執行：maker-checker 閘門 還有兩條，我認為對台灣電商特別重要。 一條是**寫入跟渲染只認 server 真的發過的 ID**。harness 會記錄這個 session 內 server 交給模型的每一個 ID，那是唯一被接受的鑰匙。幻覺生出來的、客人自己貼上的、埋在商品評論裡的 ID，在碰到後端之前就被擋掉。 另一條是**受規管的文案由 server 逐字提供**。模型只能選要揭露哪個商品，每一個字都從核准過的文案來，而且 eval 會逐位元組比對渲染出來的字串。運費、超商取貨手續費、七天猶豫期，這些東西不能讓模型自己改寫。標錯價在台灣電商是會上新聞的，改價幅度、折扣深度、活動預算的上限，全都要當成護欄寫死。 memory 那段也值得一看：Anthropic 建議**非同步寫入**，在每個回合結束後（長對話則每幾個回合）由另一個 thread 讀對話存事實。這樣做在他們內部的 commerce memory eval 上，事實召回率比讓 agent 即時存**高出 13%**，而且完全不佔用客人等待的時間。想多了解 agent 記憶怎麼運作，可以看我之前解碼的[兩個記憶原語](https://growthhackers.tw/blog/anthropic-agent-memory-dreaming/)。 ## 台灣中小電商該怎麼動 先講一件很多人會忽略的事：這份藍圖**不附任何 MCP connector**，你得自己透過 backend interface 去接你的系統。 意思是，如果你是 91APP、Shopline、Cyberbiz 上面的品牌，這份東西不是你今天下載就能用的。你多半會是等平台把這層做進來。但看懂它，你才知道該去問平台什麼問題。 順帶釐清一個定位，免得跟前陣子的新聞搞混：[Shopify 的 UCP](https://growthhackers.tw/blog/shopify-ucp-cli-agent-commerce/) 是跨平台的「協定」層，處理不同家的 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 帳單。 ![同樣的內容換一個順序，就是溫熱快取與整條失效的差別](https://growthhackers.tw/content/images/2026/09/sv-inline-prompt-cache-order-v1.png) 同樣的內容換一個順序，就是溫熱快取與整條失效的差別 ► **第五：檔期凍結要把 agent 算進去。** 雙 11、週年慶、母親節，你本來就會凍結系統上線。agent 是**一個部署單位**，一個壞改動會一次打到所有客人。自建就先滾 canary；用平台的就要求兩件事：檔期前兩週凍結話術與技能變更，以及提供一個不用重新部署就能單獨關掉某個功能的開關。 ## 最後 工程文結尾那句話我很喜歡：這裡面大部分東西都跟模型無關。tool 呼叫的是你已經在跑的系統，skill 編碼的是你已經在遵循的流程，eval 是你的產品需求文件寫成測試。 以前我們評估一個 AI 專案，第一個問題是「模型夠不夠聰明」。現在真正決定成敗的是「你的系統邊界劃在哪裡」。 而且這套東西的射程比聊天視窗遠。再往後看，你店裡的流量會有一部分來自**替客人購物的外部 agent**。到時候，讓你自己的 agent 守規矩的那套暫存與核准規則，剛好就是你敢把 tool 開放給外面 agent 的底氣。 想清楚前台要解什麼任務，可以搭配看[AI 購物助理該解的三種任務](https://growthhackers.tw/blog/retailer-ai-assistant-jobs-to-be-done/)。那篇談客人要什麼，這篇談後面怎麼蓋。 藍圖在 [anthropics/commerce-agents](https://github.com/anthropics/commerce-agents?ref=growthhackers.tw)，四個垂直範例（零售、旅遊、電信、票務）全部用虛構品牌 ACME，不會真的下單也不會扣款，可以放心跑。官方發布稿在 [Building Commerce Agents with Claude](https://claude.com/blog/claude-for-commerce-agents?ref=growthhackers.tw)。 **協作聲明與免責** 這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 `[來源名稱](URL)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。 內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。