為AI代理構建按智慧付費:Ampersend如何使用Amazon Bedrock AgentCore Payments
Ampersend在Amazon Bedrock AgentCore Payments之上構建了一個按智慧付費的路由層,使AI代理能夠使用x402協議自主支付模型服務費用。該整合處理錢包託管、支出治理和兩跳結算,將開發時間從數月縮短至兩週以內。
本文由Ampersend(Edge & Node)的Kevin Jones和Amazon Bedrock AgentCore Payments團隊的Chethan Shriyan共同撰寫。
Ampersend和Amazon Bedrock AgentCore Payments正在解決代理AI中最困難的問題之一:自主代理如何在不從頭構建定製計費整合、憑證管理和支付編排的情況下為服務付費?隨著越來越多的服務轉向面向機器的按使用付費模式,代理需要一種使用x402等代理支付協議以程式設計方式即時且在受控限制內進行交易的方式。
在本文中,您將瞭解Ampersend如何在Amazon Bedrock AgentCore Payments之上構建一個按智慧付費的路由層。AI代理自主地將任務路由到最有效的模型,按請求付費,並在支出預算內執行。您還將看到兩跳支付模式如何端到端工作,以及如何開始自己的實現。
關於Ampersend
Ampersend(由Edge & Node開發)是一個代理支付和運營管理平臺。Ampersend位於代理和模型提供商市場之間。他們的服務處理支付路由、結算和運營。代理構建者透過單一整合訪問模型,無需每個提供商的訂閱、合同開銷或隨提供商數量線性增長的計費關係。
Ampersend的論點很直接:代理應該像呼叫API一樣支付智慧費用——以程式設計方式、即時且無需人工干預。
Ampersend允許AI代理透過由x402開放協議和Amazon Bedrock AgentCore Payments驅動的單一整合點,自主地向多個模型提供商支付智慧服務費用。
挑戰:自主代理的支付基礎設施
代理構建者和服務提供商面臨著同一基礎設施差距的兩個方面。
對於代理構建者:您的代理需要呼叫付費的大語言模型(LLM)、付費資料API或付費內容端點。您需要構建錢包管理、處理支付簽名、實現x402等代理支付協議、管理支出限制並整合每個提供商的計費。這需要數月的基礎設施工作,然後才能釋出代理邏輯。
對於像Ampersend這樣的應用程式:您希望透過單一支付渠道為代理提供對多個模型提供商的訪問。但要做到這一點,您需要底層支付基礎設施安全、可審計且受治理,而無需自己構建錢包託管和支出控制。
AgentCore Payments解決了這兩個方面。它提供了代理系統所需的託管支付基礎設施,並賦予單個代理在受控限制內自主交易的能力。
Ampersend如何使用AgentCore Payments構建按智慧付費路由層
Ampersend在AgentCore Payments之上構建了一個按智慧付費的路由層。用例是這樣的:
代理有一個任務:總結研究論文、審查智慧合約、分析鏈上資料。代理呼叫Ampersend,後者釋出按能力層組織的模型目錄。代理選擇與任務複雜性匹配的層,透過AgentCore Payments按請求支付,並得到結果。在幕後,Ampersend使用Ampersend SDK與上游模型提供商進行結算。
這建立了一個兩跳支付路由模式:
圖1:兩跳支付路由——代理 → Ampersend → 模型提供商
兩跳支付流程如何工作
上圖說明了端到端的支付架構。以下是關鍵AgentCore Payments元件在此流程中如何協同工作:
- 支付管理器(Payment Manager)——應用程式後端建立定義錢包連線和支出策略的支付管理器。這是控制代理如何花費的治理層。
- 支付會話(Payment Session)——在代理啟動之前,後端開啟一個具有預算上限(例如0.05美元)的支付會話。代理只能在此會話的限制內交易。
- ProcessPayment API——當Ampersend返回HTTP 402(需要付款)時,代理呼叫包含x402支付詳細資訊的ProcessPayment。AgentCore使用連線錢包的憑證對USDC授權進行簽名,而代理從不接觸私鑰。
- 憑證提供者(Coinbase CDP)——AgentCore連線到Coinbase Developer Platform作為錢包憑證提供者。Coinbase Developer Platform管理錢包託管和簽名基礎設施。代理承擔一個僅限於呼叫ProcessPayment的IAM角色(ProcessPaymentRole)。該角色無法修改預算或直接訪問錢包金鑰。
- 結算——簽名後,支付證明返回給代理。代理使用附帶的證明重試對Ampersend的原始請求。Ampersend在鏈上(Base網路,USDC)驗證結算,然後使用Ampersend SDK自動支付上游模型提供商(例如BlockRun)。發生兩筆結算:代理到Ampersend,以及Ampersend到模型提供商。
從代理的角度來看,它發起了一個付費請求。它不知道也不關心Ampersend路由到了哪個提供商。Ampersend透明地處理提供商選擇、第二次支付和交付。
AgentCore Payments如何管理支付生命週期
AgentCore Payments處理完整的支付生命週期,因此Ampersend和代理構建者都不必構建:
託管錢包——AgentCore連線到Coinbase CDP或Stripe Privy錢包作為支付連線。無需構建錢包託管基礎設施,無需維護金鑰管理。Ampersend一次性連線其憑證,即可獲得準備交易的注資錢包。
支出治理——在基礎設施層強制實施會話級預算。應用程式後端設定限制,代理在限制內交易。如果預算耗盡,下一個支付將被幹淨地拒絕。代理自主執行,但在無法覆蓋的確定性邊界內。
原生x402協議——當代理遇到付費端點(HTTP 402)時,AgentCore處理x402協議協商、錢包身份驗證、穩定幣支付和證明交付,而不會中斷代理的推理迴圈。支援協議的v1和v2。
可觀測性——每筆交易都流經開發人員已在AgentCore中使用的相同日誌、指標和跟蹤。無需構建單獨的支付監控。
Ampersend和AgentCore Payments的組合解鎖了什麼
單獨任何一個系統都不能完全覆蓋代理商務的整個堆疊。它們一起覆蓋了路由、結算、治理和可觀測性端到端。
Ampersend帶來:智慧模型路由、提供商市場、抽象提供商複雜性的兩跳結算模式,以及大規模管理代理支付工作流的運營工具。
AgentCore Payments帶來:託管錢包基礎設施、確定性支出治理、原生x402簽名和結算,以及賦予自主代理在不暴露憑證或覆蓋預算的情況下交易的安全模型。
它們共同展示了代理商務在實踐中的樣子:一個發現、評估、選擇並支付智慧服務的代理,所有這些都在一個受治理、可觀測且可審計的框架內進行。
結果
Ampersend在不到兩週的時間內完成了從初始API呼叫到Base網路上端到端支付結算的完整整合。如果沒有AgentCore Payments,該團隊估計僅錢包託管、簽名基礎設施和支出控制就需要3-4個月的工程工作。
領導整合的Kevin Jones表示:“構建多代理系統確實複雜,我們曾預期支付基礎設施是整個專案中最困難的部分。AWS AgentCore Payments完全改變了這一點。使用AgentCore的買方代理、Ampersend的賣方代理和BlockRun AI的即用即付LLM推理的整合比我們預期的順利得多。我們連線了邏輯,它就直接工作了。”
Edge & Node執行長Rodrigo Coelho表示:“我們構建Ampersend是為了成為代理支付的控制層。AgentCore Payments是天然的選擇——託管錢包、支出護欄和x402結算讓我們在幾天內展示完全自主的代理到代理微支付。”
結論
Ampersend與AgentCore Payments的整合展示了當代理平臺可以將錢包託管、x402協議處理和支出治理解除安裝到託管基礎設施時,什麼是可能的。代理構建者獲得付費智慧的單一支付表面,而像Ampersend這樣的平臺可以專注於路由和市場邏輯,而不是支付管道。結果是一個預設受治理、可觀測且可審計的自主代理到代理商務。
開始使用
準備好構建即用即付的代理工作流了嗎?以下是開始的方法:
- 設定AgentCore Payments——按照AgentCore CLI快速入門建立支付管理器、連線錢包提供商並配置具有支出限制的第一個支付會話。
- 與Ampersend整合——訪問ampersend.ai探索模型目錄並將您的代理與Ampersend的支付路由API整合。
- 嘗試教程——在GitHub上檢視動手實踐的AgentCore Payments工作坊和示例,以檢視工作買方/賣方實現。
瞭解更多:
• Amazon Bedrock AgentCore Payments文件
• 交易代理:Amazon Bedrock AgentCore現在包括Payments(預覽)——釋出公告
• GitHub上的AgentCore Payments示例和工作坊
• x402協議
• Ampersend
關於作者