Claude Commerce Agents 是 Anthropic 於 2026 年 9 月 2 日公開的 Apache 2.0 參考實作：一個 Agent 面向消費者找商品、組購物車，另一個 Agent 協助商家處理庫存、定價與行銷；付款、身分驗證與正式寫入仍由企業自己的系統負責。
Anthropic 把這套程式碼說成 blueprint，很精準。它提供可執行的骨架、工具契約、安全閘門與評估方式，卻沒有假裝最後一哩已經解決。你可以在幾個小時內看到對話跑起來；要讓它碰真實客戶、價格和訂單，工程才剛開始。
截至 2026 年 9 月 5 日，官方開源貼文累積 194 萬次瀏覽、11,584 個讚與 945 次轉發；GitHub repository 則有 1,921 顆星、318 次 fork。這些數字代表開發者注意力，不等於正式採用，但足以說明為什麼 commerce agent 又成了本週 AI 社群的熱門題目。
Claude Commerce Agents 到底交付了什麼
Repository 內有兩個共享底層元件的 Agent，並附零售、旅遊、電信與娛樂票務四種垂直範例。每個 Agent 都可以透過 Messages API、Claude Agent SDK 或 Claude Managed Agents 執行。
| 角色 | 面向誰 | 已包進 blueprint 的工作 | 正式上線前仍要接上的系統 |
|---|---|---|---|
| Shopping agent | 消費者 | 商品搜尋、比較、購買規劃、購物車、訂單與政策問答、偏好記憶 | 真實商品目錄、庫存、帳號、結帳與付款 |
| Merchant agent | 商家員工 | 銷售分析、商品與庫存維護、定價與促銷建議、活動草稿 | 權限、審批、資料倉儲、正式寫入與稽核 |
Shopping agent 的價值不是多一個聊天視窗。它把商品卡、比較表、行程、購物車等 UI 元件定義成有型別的工具呼叫，伺服器驗證後再交給前端呈現。顧客說「替九歲、喜歡積木與拼圖的孩子找一份 45 美元以下的禮物」，Agent 可以搜尋、比較並組購物車，不必把整份目錄塞進提示詞。
Merchant agent 則坐在另一側。它讀取銷售、庫存與行銷資料，找出缺貨、退貨異常或活動表現，再提出補貨、調價或回覆草稿。每一次會改變商家狀態的動作都先停在 staged change，等待真人或既有政策批准。
Anthropic 的架構賭注：一個 Agent，加上 Skills
這份 blueprint 最有意思的選擇，是沒有替搜尋、購物車、退貨、定價各養一個 subagent。Anthropic 的工程團隊主張，commerce 對話會共享商品、使用者偏好、購物車與歷史訊息；每次把工作丟給另一個 Agent，都可能遺失狀態、增加 token 與延遲。
因此，主 Agent 維持完整會話。高頻規則放 system prompt，長尾流程才放 skills。官方建議，與三分之一以上流量相關的指令可先放 prompt；其餘再按需要載入 skill。真正獨立、會消耗大量上下文的研究工作，才適合交給 subagent。
這個判斷跟社群近幾個月的實作經驗相當接近：讓一個「企業大腦」包辦全部工作，最後通常難以除錯；把規則寫成工具可以拒絕的條件，再把 Agent 範圍縮小，系統反而比較可靠。Claude Commerce Agents 採用單一對話 Agent，並不代表把所有權限都塞給模型。它把複雜度搬到 backend contract 與 approval gate。
三種執行方式，雲端支援並不完全相同
| 執行路徑 | 適合情境 | 支援範圍 | 要注意的限制 |
|---|---|---|---|
| Messages API | 團隊要完全控制 agent loop | Anthropic API、Vertex AI、Bedrock、Microsoft Foundry、內部 gateway | 自己維護 loop、工具調度與狀態 |
| Claude Agent SDK | 想沿用 Claude Code 同類 agent loop | 同樣可接 Anthropic、Google Cloud、AWS、Microsoft 與 gateway | 執行環境與工具生命週期由團隊管理 |
| Claude Managed Agents（beta） | 想用 Anthropic 託管的 Agent 資源 | Anthropic API；內部 gateway 可透過 pass-through | 不直接支援 Vertex、Bedrock 或 Foundry 的對等部署 |
Repository 預設讓 shopping agent 使用 Claude Sonnet 5，merchant agent 使用 Claude Opus 5，記憶抽取則使用 Claude Haiku 4.5。這只是起點。Anthropic 建議以「每個成功完成任務的成本」做模型選擇，因為便宜模型如果多跑幾輪或更常失敗，總成本未必較低。
五分鐘看懂本機啟動方式
官方範例要求 Python 3.11 以上與 Node 22。最短路徑如下：
git clone https://github.com/anthropics/commerce-agents.git
cd commerce-agents
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
(cd examples && npm ci)
python scripts/run_demo.py retail
把 ANTHROPIC_API_KEY 寫進 .env 後，預設會啟動 retail API 與消費者 storefront；加上 --merchant 可改開商家 portal，--all 則同時啟動兩邊。團隊也能安裝隨附的 Claude Code plugin，讓它依現有 backend 建立骨架：
claude plugin marketplace add anthropics/commerce-agents
claude plugin install commerce-builder@claude-commerce-agents
claude
/scaffold-commerce-agent a shopping assistant for our store
看見 demo 成功，只證明 agent loop、範例資料與前端整合可以運作。正式專案還得把 StorefrontBackend 或 MerchantBackend 對接自己的商品、訂單、庫存、分析與審批系統。
安全護欄比提示詞更值得抄
Anthropic 很清楚 commerce 的錯誤可能花掉真錢。參考實作把幾個重要邊界落在程式碼裡：
- 模型只能提出動作。付款、退款、改價與活動上線由 harness 控制。
- 寫入工具只接受伺服器在同一 session 發出的 ID，拒絕幻覺、使用者貼入或商品評論夾帶的 ID。
- 數量、折扣、補貨與活動預算以「寫入後狀態」重算上限，避免平行工具呼叫疊加越權。
- 商品評論、賣家訊息與記憶等第三方文字先消毒、加上 fence，再交給模型閱讀。
- 記憶放在企業自己的資料庫，寫入需驗證，使用者也要能查看、更正與刪除。
官方內部測試顯示，將記憶抽取放到非同步工作後，commerce memory eval 的事實召回率提高 13%，同時不增加顧客當下看到的延遲。另一個實務數字也很有用：典型 commerce 回應約 500 至 700 個 output tokens，若完全等完才渲染，使用者可能盯著 spinner 超過五秒。
護欄做得認真，但官方 README 也直接寫出缺口：範例沒有 authentication，Managed Agents 的 MCP server 只綁 loopback。企業仍要負責帳號身分、session credential、授權、合規、監控與復原。
社群在談什麼：先稱讚骨架，再追問付款
第一波反應大致分成四條線。
第一，開發者普遍認同「有程式碼比有願景好」。兩個 Agent、四種產業、八個前端範例與 Claude Code plugin，讓團隊可以從可執行狀態開始，而非再寫一份概念驗證簡報。
第二，付款邊界立刻成為焦點。Shopping agent 會組購物車與呈現 checkout，但 repository 沒有 charge method；真正扣款要交給商家既有結帳或 agentic payment provider。討論很快延伸到獨立支付工具、商家 allowlist、單筆與每日額度、冪等請求、可撤銷授權及耐久收據。這些限制必須放在模型上下文之外，否則 prompt injection 就可能碰到錢。
第三，有實際營運經驗的人更在意資料與審批。客服 Agent 如果只看信箱，卻不知道 Shopify 訂單狀態與退貨規則，回答仍會自信地出錯。最務實的建議是先做 read-only 或 draft-only 流程，用共享事實來源與硬性 approval gate 跑穩，再逐項開放寫入。
第四，成效數字仍待外部驗證。Anthropic 表示，採用 Claude shopping agents 的零售商曾看到購物車最高增加 35%，購買完成可能性提高 60%。官方沒有公開樣本數、基準組與計算方式，不能把兩個百分比當成每家商店都能複製的 benchmark。
誰現在適合做，誰該先等等
最適合開始試點的團隊，已經有乾淨的商品與政策資料、可呼叫的後端 API、明確的員工權限，以及能承接批准動作的介面。這類公司缺的是 agent harness；Claude Commerce Agents 正好補這一層。
如果商品資料經常互相矛盾、庫存延遲、退貨政策散在文件與客服腦中，先接 Agent 只會把混亂加速。模型不會替企業修好 source of truth。它只會更快暴露缺口。
實作順序可以很保守：
- 先跑官方 demo，確認兩個 Agent 與三種 runtime 的差異。
- 只接商品搜尋、商品詳情與商家唯讀分析。
- 建立 session identity、權限、稽核與記憶資料政策。
- 讓寫入先停在草稿，逐項測試 prompt injection、重複請求與過期資料。
- 最後才接付款、退款、改價或活動上線，而且保留真人或政策批准。
Claude Commerce Agents 值得注意，因為它把「AI 店員」從展示影片拉回工程責任。可 fork 的程式碼很吸引人；真正能不能上線，取決於企業願不願意把身份、資料、權限與金流邊界一條條補齊。
FAQ
Claude Commerce Agents 是可以直接購買的產品嗎
不是。它是 Apache 2.0 授權的開源參考實作，企業 fork 後自行維護。官方明確表示它不是有 SLA 的支援型產品，也不接受外部 contribution。
它可以直接替消費者完成付款嗎
參考實作可以搜尋、比較、組購物車並交接 checkout，但模型本身沒有扣款工具。付款要由商家的既有結帳系統或外部 agentic payment provider 完成。
它只能用在零售嗎
官方附零售、旅遊、電信與娛樂票務四種範例。相同的 prompt、skills、tool contracts 與 gates 可以套到其他有目錄、庫存、價格或預訂流程的商業模式。
可以部署在 AWS、Google Cloud 或 Microsoft Azure 嗎
Messages API 與 Agent SDK 路徑可接 AWS Bedrock、Google Cloud Vertex AI 與 Microsoft Foundry。Claude Managed Agents 目前沒有三者的直接對等路徑，部署前要確認 support matrix。
官方宣稱的 35% 與 60% 可以當成預期成效嗎
不建議。兩者是 Anthropic 對客戶結果的最高值描述，尚無公開研究設計可供外部驗證。試點應先定義自己的 task completion、grounded accuracy、轉換率、p50/p99 latency 與每次成功任務成本。
Author Insight
從架構角度看，這份 repository 最值得帶走的是模型不該擁有最後寫入權，而非哪一段 prompt。把 AI 接進商務流程很容易做出亮眼 demo；把每次改價、退款與扣款變成可追溯、可重試、可拒絕的動作，才是正式系統的分水嶺。
權威來源
- Anthropic：Building commerce agents with Claude
- Anthropic：A guide to the anatomy of effective commerce agents
- GitHub：anthropics/commerce-agents
- Anthropic GitHub：Deployment platforms
- Anthropic GitHub：Safety rules
