搜尋商品、比較選項、加入購物車，還得回答退貨的疑問。任何團隊只要著手打造購物用的 AI 代理程式，最後都得把同一套底層架構重做一遍。Anthropic 這次把那套架構以程式碼的形式公開。儲存庫 anthropics/commerce-agents 收錄了面向消費者與面向商家的兩種代理程式，授權為 Apache 2.0。
兩種代理程式與四個產業
公開的藍圖裡，有兩個職責截然不同的代理程式。
第一個服務購物者。它在商家自己的應用程式或網站中運作，檢索商品目錄，處理一次涉及多件商品的需求，比較選項並組出購物車。訂單狀態與退貨的提問，也在同一段對話裡回覆，不必切換場景。導入的一方需要針對自家的目錄、購物車、訂單與政策系統實作 StorefrontBackend。
第二個服務門市營運人員。員工可以詢問業績為何停滯、接收庫存警示、索取定價與促銷的調整建議，或請它草擬行銷文案。這一側的銜接點是 MerchantBackend。
在此之上，儲存庫還附上零售、旅遊、電信、娛樂四個產業可直接執行的實作範例。只要有 Python 3.11 以上版本、Node 22 以及一組 API 金鑰就能在本機啟動，同一份程式碼既可跑在 Claude API，也可跑在 Amazon Bedrock、Microsoft Foundry 與 Google Cloud Vertex AI 上。另外還提供名為 commerce-builder 的 Claude Code 外掛，用指令即可產生新代理程式的骨架，或檢視既有實作。
不拆成子代理程式的判斷
技術上最容易引起討論的，是整體架構的取捨。Anthropic 明確反對在前端擺一個意圖路由器，也反對依領域各設一個子代理程式。
理由很單純：購物對話本身就不好切開。購物車內容、顧客偏好、先前的往來都握在主代理程式手上，每一次交接都會漏掉一部分。交接還會讓 token 用量翻上好幾倍，並替回應多加上數秒。何況領域本來就彼此重疊，光是一個退貨問題，就得同時看訂單紀錄、購物車與商品目錄。
取而代之的做法是代理程式技能。技能的指示會載入到已經握有對話紀錄的那個代理程式內部，因此能在不付出交接代價的前提下切分功能。Anthropic 表示，在多個企業導入案例中，帶技能的單一代理程式在品質上同時勝過單一超長提示詞的做法與子代理程式的做法，成本與延遲也更有利。子代理程式仍適合深度研究這類獨立性高的工作。
要放進系統提示詞還是拆成技能，界線依出現頻率而定：牽涉到整體三分之一以上對話的內容放提示詞，其餘做成技能。安全相關規則、品牌限制、使用者的關鍵屬性則不論頻率，一律留在提示詞裡。
把介面元件當成工具
購物情境的回應，用介面元件往往比用文字更合適，像是商品卡、行程表、資費方案對照表。
這份藍圖沒有要模型輸出自訂標籤，而是把每個元件定義成一個工具。present_products、present_itinerary 這類呼叫帶有型別化的參數，伺服器端驗證過後才交給前端繪製。由於這些呼叫原生留在訊息紀錄中，重新載入對話不需要另寫解析程式。使用者說「就選第一家飯店」時，代理程式能對應到剛才呈現的內容，也是同樣的道理。
延遲與成本的細部打磨
對體感速度的處理相當具體。單次回應的輸出規模落在 500 到 700 個 token，若不做串流，載入動畫會持續將近 5 秒。藍圖的做法是元件成形一個就送出一個，同時以平實的文字顯示進度，讓體感等待時間與實際處理時間脫鉤。參數一串流完成就立刻執行工具呼叫的方式，據稱把數秒的空白壓縮到數百毫秒。
成本面的主角是提示詞快取。快取以前綴命中，因此請求要從最不易變動的資訊開始排列。把時間戳記放在系統提示詞開頭，會讓每次請求都打掉快取，屬於要避開的寫法。命中快取的讀取只需新鮮 token 十分之一的費用，寫入快取則約有 1.25 倍的加價。調校得宜的導入案例，命中率據稱可達 90 到 99 個百分點的區間。記憶抽取也被移出對話流程交由獨立行程處理，Anthropic 量測到的事實回想率比在對話中儲存的做法高出 13 個百分點。
涉及金流、寫入與識別碼的處理，一律要通過程式碼層的關卡。模型只負責提案，要不要執行由程式決定。
總結
這份藍圖，是 Anthropic 對每個打造購物代理程式的團隊都會碰上的架構難題所給出的答案：不拆子代理程式而以技能擴充能力、介面元件以工具形式做型別化、碰到金流的操作交給程式碼擋下。發布時間正好卡在年末購物旺季之前，不過既然以 Apache 2.0 公開，對任何在設計對話式代理程式的人來說都值得一讀，不限於電商情境。
