English version: Open and Closed Are Not Fighting the Same War

Agentic Payment 的競爭沒有單一贏家，只有業務場景適配。

偏封閉的路徑，把錢包、協議、軌道、稽核全部打包成一個 API，你接進來就能跑。

而相對偏開放的路徑，介面定義公開、實作可替換、規則第三方可稽核，你自己拼湊。

一條服務想快速驗證或快速交付的團隊，另一條則服務有合規包袱與治理中立要求的組織。短期內兩邊不會互相消滅。

但這個區隔不是發生在某一層。Rye 把整個 Agentic Commerce 的 stack 拆成七層之後，會看到一件值得注意的事：每一層都有開放陣營跟封閉陣營不同的業務邏輯考量。有些層被封閉陣營密集占滿，有些層連一家開放陣營的影子都還沒看到。

這篇我想探討的，就是把鏡頭拉到七層全景，看哪一層的開放陣營還有縫隙，新創還能鑽進去。

先定義什麼叫封閉、什麼叫開放

開放跟封閉不是 binary，是光譜的兩邊。

判斷一個 Agentic Payment 玩家落在光譜哪裡，看四個維度：

1. 規格透明度：介面、協議、資料結構，是寫在公開文件裡讓任何人可以拿來實作，還是埋在某家公司的內部設定檔

2. 治理中立性：規格演進的決定權，在中立組織（FIDO、Linux Foundation、W3C）手上，還是在某家公司董事會手上

3. 實作可替換性：如果今天想換掉這個供應商，介面層的程式碼是不是不用改，遷移成本是不是可控

4. 規則可稽核性：授權邏輯、policy 執行、交易紀錄，能不能被外部稽核獨立驗證

如果四個維度大部分都被嚴格規範了（由單一供應商說了算），就是相對封閉；只有小部分被規範、其他都留給市場跟標準決定，就是相對開放。

封閉的價值主張很清楚：打包、開箱即用、快速上線。 你不用懂底層，接一個 API 就跑得起來。

開放這邊則是：可組合、彈性、no vendor lock-in。你的選擇權永遠在自己手上。

兩種承諾各有 TA。但要看清楚誰在哪一層做哪一種，得先把鏡頭拉開看全景。

把鏡頭拉開：七層全景

Rye 把 Agentic Commerce 的 stack 拆成七層：

• L1 AI Platforms → Agent 行為的起點，使用者下指令的地方

• L2 Protocols / Standards → 機器之間溝通的協議與授權的標準

• L3 Payments / Identity → Agent 專屬的授權引擎、錢包容器、身份驗證

• L4 Card Issuance → 把 Agent 的授權轉成虛擬卡發行，讓商家用熟悉的方式收款

• L5 Checkout Execution → Agent 替人類填表結帳的最後一哩

• L6 Merchant Enablement → 商家把產品結構化讓 Agent 能發現

• L7 Trust / Security → 防詐、Agent 身份驗證、合規護欄

為了方便接下來的分析，我按照四維度來衡量，「約略地」把封閉到開放光譜一刀切下去，每一層分佈的態勢都不相同，機會也不同。

注：ACP 雖為 open source、規格公開，但治理由原始發起方主導，不同於中立組織治理的 x402、AP2 等協議。它在「規格透明度」上開放，但「治理中立性」上偏封閉。

幾個值得單獨拉出來看的觀察：

• L1 流量入口巨頭壟斷，「我有最多用戶」這件事本質就排他

• L2 過去一年內，A2A、MCP、x402、AP2 陸續移入或交由中立組織（Linux Foundation、Agentic AI Foundation、FIDO Alliance）治理。ACP、TAP、Circle Nanopay 雖有公開介面或文件，但治理與採用路徑仍由原始發起方主導

• L3 封閉陣營擠到爆；開放實作整層目前最明確、最完整的代表是 MoonPay OWS

• L4 卡片發行本質上跑在 Visa / Mastercard 卡網上，卡網高度受既有網路規則、風控、清算與監管約束，完整開放的空間有限

• L5 玩家清一色私有 API；唯一沾到開放邊的 AWS AgentCore Gateway，也是靠著串接 L2 的 x402，但它更接近 paid resource / MCP endpoint payment execution，不完全等同於傳統 checkout execution

• L6 商家想被 AI agent 找到，幾乎只能掛在 Shopify、Stripe Catalog、PayPal 這些封閉聚合器底下；開放陣營有 Orthogonal、Circle Agent Marketplace 等，但各做各的，沒形成有規模的替代

• L7 開放規格有了（IETF Web Bot Auth、FIDO Agentic Authentication WG 已就位），但沒有一份大家共用的開放實作；封閉陣營的 Forter、Signifyd、AmEx 則是成熟可買的反詐黑盒子

把這些觀察擺在一起看，結論才浮出來。

L1 跟 L4 的封閉源自基礎設施本質（用戶壟斷、卡網閉環），新創玩不動。L2 跟 L7 已經有大型組織在搭治理骨架，新創擠不進去。L5 這層沒有自己的開放陣營，所有玩家都是私有 API，唯一沾到開放邊的 AWS AgentCore Gateway 是靠 L2 的 x402 撐起來的。新創要做的話，挑戰不小。

新創最大的機會在 L3。

L3 是 Agentic Payment 的授權層 -- Agent 拿什麼權限、能花多少、誰能稽核 -- 而整個 L3 的開放陣營，目前最明確的代表是 OWS。L6 也還有一些零散機會，但分散到很難形成單一切入點。

L3 的兩個代表：Crossmint 與 OWS

在 L3 這層，Crossmint 跟 OWS，我個人認為，是兩個最具代表性的玩家。因為這兩家都從讓人「無痛接觸 Web3」的支付基礎設施起家。

我刻意把這兩家拉出來對照，不是因為其他玩家不重要。是因為 L3 這層只有這兩家，拿著同一個 Web3 起點，走到了兩個完全相反的商業模式上。Stripe、Mastercard、Fireblocks 各自精彩，但都不是純 L3、也不是 Web3 起家。要看清這層兩條路長什麼樣子，這組對照最乾淨。

Crossmint 2022 年成立，從「讓 NFT 賣家用信用卡收款的 SDK」做起；買家用 email + 信用卡就能完成購買，Crossmint 在背景幫買家開錢包。2024 年初收購 Winter 之後擴展到跨鏈支付。2025 年起把重心轉到 Agent Payment。它的核心技術是 TEE（Trusted Execution Environment，硬體安全隔離區）雙密鑰錢包：owner 跟 agent 各持一把，agent 能簽署交易但 owner 保最終控制權。中間架了一層 Policy Engine 做軟體層過濾。

MoonPay 2019 年成立，本來是 fiat-to-crypto on-ramp，Web3 主流入金通道。它看到 agent 時代錢包介面碎裂，2026 年 3 月發起 OWS。MIT 開源，七大子規範：Storage Format、Signing Interface、Policy Engine、Agent Access、Key Isolation、Wallet Lifecycle、Supported Chains。還有 PayPal、Circle、Ethereum Foundation、Solana Foundation 等 15+ 組織聯盟背書。

同樣的起點，兩種完全相反的商業模式。

Crossmint 的承諾：整合外包

Crossmint 的承諾很清楚：你不用理解底層。一句話：接我們，其他不用管。

單一 API 同時接通穩定幣軌道（USDC，近即時結算）跟卡片軌道（Visa、Mastercard）。x402（Coinbase HTTP 微支付協議）、AP2（Google Agent Payments Protocol）、MPP（Stripe Machine Payments Protocol）、ACP（OpenAI + Stripe 共推的 Agentic Commerce Protocol），這些協議全都被抽象化到 Crossmint 的 API 裡。金鑰鎖進 TEE，Policy Engine 在中間做軟體層過濾，幫你管理消費上限、商家白名單、人工審批閾值。40,000+ 客戶、訂閱成長 1,100% YoY、MiCA CASP 牌照（歐盟加密資產服務提供商牌照，覆蓋 27 國）。

它的價值主張只有一個：整合工作的外包。

你不需要知道 USDC 跟卡片軌道的結算有什麼差別。不需要判斷這個場景該走哪條協議。不需要擔心金鑰怎麼存、怎麼分發、被偷了怎麼辦。Crossmint 全部幫你做完了。

但這筆交易的本質是拿可攜性換速度。接 Crossmint 的那一天，你的 Agent Payment Stack 就長在他們的基礎設施裡。遷移成本從第一天就在累積。

Crossmint 賣的是「幫你把整合搞定」。

OWS 的承諾：選擇權保留

OWS 不打包。它定義介面。

OWS 的設計哲學是把規則執行壓（enforce）在錢包端。私鑰不暴露給 agent 或 LLM context，簽章流程在隔離／受保護的執行路徑中完成。Agent 拿的是受 policy 約束的 access capability，而不是主私鑰。每筆簽章前，OWS 規定要先過 Policy Engine 驗證。實作方可以做到單純的金額/白名單核對，也可以做到更深的情境判斷，這是 OWS 留下的擴展空間。

它的價值主張：選擇權的保留。

你的金鑰存在哪裡，你決定！
加密層跑什麼硬體，你決定！
接什麼鏈、換不換錢包供應商，還是你決定，而且介面層的程式碼不用跟著改。

授權規則是寫在公開的標準文件裡，不是埋在某家平台的私有設定檔裡。任何第三方都可以拿這份規格，去檢查實作方有沒有照規矩執行。

但開放的代價是時間。開放標準不會今天接、明天上線。你需要理解那些規範的邊界，你需要等生態成熟。OWS 從來不賣速度。要快，去找封閉平台。

OWS 賣的是「選擇權永遠在你手上」。

不同 TA，不同業務場景

這兩種承諾的核心不只是技術路線不同。它們針對的 TA 根本不在同一個業務場景與採購決策裡。

Crossmint 服務的比較像是想快速驗證或快速交付的團隊：今天接 API，明天上線。他們在做 PoC、在驗證 PMF、在試哪種 Agent 場景有 traction。三年後的遷移成本不是他們現在的問題。

OWS 服務的更傾向是已經有合規包袱與治理中立要求的組織：兩年後換供應商，被合約卡住不是他們的選項。他們跑的市場對稽核與可攜性的要求，不允許把底層交給一個不能換的人。

這兩種 TA 有各自的業務邏輯與考量，自然帶出不同的需求與選擇。

L3 的其他玩家：每家都在光譜上選了位置

Crossmint 跟 OWS 是眾多 L3 玩家中的兩個代表。其他玩家在光譜上都有其定位，每家在四個維度上的選擇都不一樣，當然都有各自的商業考量。

Stripe Agentic Commerce Suite：規格、治理、可替換性全是封閉的，只有可稽核性開了一條縫。

Stripe 把 MPP、ACP、Klarna、Affirm、Visa Agentic Network Tokens、Mastercard Agent Pay 全部包進同一個 SPT（Shared Payment Token，共享支付憑證）。SPT 不是另一個協議，是一個統一的憑證單位。一次發行，綁定特定商家、金額、時間，底下無論走卡片、穩定幣、BNPL、x402 還是 MPP，開發者不用改任何一行程式碼。

這不是「支援多協議」。這是「對開發者進行多協議的統一封裝」。

Stripe Sessions 2026 一次發布 288 個新功能。Agent Guardrails 是授權護欄（指派 agent 身份、強制範圍規則、設定審批流程）。Link Agent Wallet 是面向消費者的錢包產品。Issuing for Agents 是面向 Agent 的發卡產品。Stripe 沒有在押注哪個標準。它押的是：不管你用什麼標準，最終都經過我。

Stripe 比 Crossmint 開放一點點，因為它提供 spend controls、real-time authorization、transaction visibility（可稽核性上開了一條縫）。但本質還是封閉。

Fireblocks：開放治理 + 封閉產品同時做。

Fireblocks 加入了 x402 Foundation。那是 Linux Foundation 旗下的中立治理組織，成員包括 Coinbase、Stripe、AWS、Google、Cloudflare、Visa、Mastercard。Fireblocks 選的不是加入某個商業聯盟，是加入一個中立的標準治理組織。它還在加入時貢獻了 x402 的安全擴展，強化 request integrity 與 spend governance。

同一時間，Fireblocks 賣的是自家封閉的 Agentic Payments Suite。Agentic Payments Gateway 給 PSP（Payment Service Provider，支付服務商）用，Agentic Wallets 給 Fintech 用，Policy Engine 跑在 Fireblocks 自己的基礎設施上。底下是 MPC（Multi-Party Computation，多方安全計算）金鑰管理：agent 只拿可撤銷的範圍限制支出許可，主資產永遠在用戶自保管下。已保護超過 $14T 的數位資產交易。封閉的。

這個策略的精髓是：Fireblocks 沒有在「開放標準 vs 封閉產品」之間二選一。它兩邊都做。

加入 x402 Foundation 確保它在標準制定桌上有話語權。賣封閉產品確保它有營收。這兩件事不衝突。對 Fireblocks 的銀行客戶來說，「協議治理有我們家的人在裡面」本身就是一種合規保證。開放治理成了封閉產品的銷售工具。

把 Fireblocks 放在四維度光譜上：治理這項是混合的，規格與可替換性偏封閉；可稽核性則是平台內較完整、平台外獨立驗證仍有限。光譜上它是個有意義的中間值。

AWS AgentCore Payments：把多個封閉組件並排。

AWS Bedrock AgentCore 上，開發者可以在 Coinbase CDP（Coinbase Developer Platform） Wallet 跟 Stripe Privy Wallet 之間二選一。不是 AWS 幫你決定用哪個錢包。是兩個都支援，你去選。背後還有 x402 Bazaar MCP server，800+ x402 支付 endpoints 直接可用。

AWS 的選擇不是真正的開放。它是「把多個封閉組件並排擺出來給客戶選」。 客戶有選擇權，但選的每個組件本身都是封閉的。在規格透明度跟治理中立性上，AWS 接到了 L2 的開放標準（x402），但可替換性還是有限，換掉 AgentCore 還是有遷移成本。

Mastercard Agent Pay、AmEx ACE、Circle Agent Stack：純封閉。

這些都是傳統金融或穩定幣巨頭把自己的基礎設施往 Agent 場景延伸。Mastercard 卡網閉環、AmEx 發卡 + 卡網 + 收單三位一體、Circle 則是 open, composable building blocks，但仍深度綁定 USDC、Circle Gateway 跟自己的 stack。四個維度大多數都偏封閉。它們的價值不在開放性，在規模跟合規。

把這些玩家擺在四維度光譜上會發現：純開放只有 OWS 一家，純封閉一大堆，中間混合的有 Fireblocks 跟 AWS。

開放陣營在 L3 是孤兒。封閉陣營是擁擠的派對。從小我媽就告訴我，人多的地方不要去。

開放贏治理，封閉贏交付

這些事情同時在發生，不是巧合也符合預期。一個比較合理的解釋正在成形。

開放陣營的勝場在協議治理。

x402 Foundation 在中立組織手上，22+ 創始成員加上 Fireblocks，標準制定權不由任何單一公司掌握。Google 把 AP2、Mastercard 把 Verifiable Intent 都捐給了 FIDO Alliance（制定 Passkey 無密碼登入標準的全球組織，2026 年起延伸至 AI agent 身份驗證），授權格式的演進不再是一家公司產品的 roadmap。這些規格的每個版本、每個變更，都必須在開放治理的桌面上取得共識。

這不是道德選擇。這是結構性結果。 當標準牽涉到競爭對手之間必須互通的基礎設施（你的 Mandate 格式要能被他家的 Agent 驗證），沒有人會接受對手公司當裁判。中立治理是唯一能讓多方同時接受的答案。

封閉陣營的勝場在執行交付。

Stripe Agentic Suite 是商家唯一需要接的單一入口。Crossmint 讓開發者完全不用碰協議細節。Fireblocks 給銀行一條「合規過得了、審計部門會點頭」的路。這些都是執行面上的勝利：誰能把最複雜的整合工作吃掉，誰就能收那筆整合稅。

兩種承諾瞄準的根本是不同的人。企業 CIO 跟獨立開發者不會出現在同一張採購單上。

企業 CIO 看的是：「會不會被綁定？審計能不能獨立驗證？換供應商的成本多大？」他們要的不是最快的方案，是風險最低的方案。

Indie（獨立開發者）看的是：「今天能不能上線？文件能不能看懂？」他們要的不是最好的架構，是好到可以啟動的架構。

開放跟封閉不是你死我活。它們根本不在同一個擂台上。開放贏在需要多方互信的基礎設施層。封閉贏在需要快速交付的應用層。

新創的真正選擇

先講清楚一件事。讀到這裡的創業者其實有兩種。

第一種：你正在做 agent app，只是在選該接誰的付款基礎設施。這種人不用讀這一節。前面 Crossmint 跟 OWS 的對照已經給你答案了。快上線接封閉，怕綁死接開放。

這一節是給第二種人看的：你要做的產品，本身就是 L3 的基礎設施。

對這種創業者來說，L3 的選擇不是「開放還是封閉」的哲學題，而是「哪一邊還有你的位置」。L3 的封閉陣營擠到爆，Crossmint、Stripe Agentic Suite、Mastercard Agent Pay、AmEx ACE、AWS AgentCore Payments，每一家都比你有資源。開放實作整層目前最明確、最完整的代表是 MoonPay OWS。

你是要進入九家公司已經壟斷的紅海，還是進入只有 OWS 的藍海？

答案不在你的信仰。在你可以做最終決策的客戶。

OWS 的 Policy Engine 跟 Agent Access 這兩個子規範，是開放陣營留給新創的填空題。真正會掏錢買「可稽核 + no lock-in」的，不是開發者。是合規官、CIO、法務主管。

他們的問題不是「我有沒有選擇自由」。是「能不能被獨立稽核」。

一個能被稽核的（audit-ready）Policy Engine 需要做到三件事：

第一、授權規則以獨立可驗證的格式定義（不是平台專屬的 config 檔）；
第二、每筆執行決策（通過或拒絕）都留下密碼學可驗證的紀錄；
第三、第三方稽核師不需要登入你的平台就能獨立驗證這些紀錄。

這三件事在目前的封閉平台上很少能被同時做到。封閉平台可以提供平台內稽核，但很難提供平台外、供應商無關、密碼學可驗證的獨立稽核。

Agent Access 則適合走垂直路線。醫療採購的合規模組、金融監管轄區的特定適配，OWS 的架構讓你插入產業特定的驗證邏輯，同時跟錢包端的規則執行機制串在一起。這是「產業深度 ＋ 標準相容性」的組合產品。

「選擇自由」不是功能。「能被稽核」才是。「合規」才是。

很多新創把「在 OWS 上做 Policy Engine」當成技術選題。但實際上它是一個客戶精準度的問題。你做的功能再好，如果賣給只是嘴上說在意可攜性的開發者，沒人要買。真正會付錢的，是合規官、CIO、法務主管。他們的問題不是「我有沒有選擇自由」，是「能不能被獨立稽核」。

認識你的客戶

把 Agentic Payment 拆成七層之後，開放跟封閉的分佈不平均。

L1、L4 高度封閉。L2、L7 的開放陣營已完成治理布局。L5 沒有屬於自己的開放陣營。L6 是機會但分散。

真正的機會在 L3 -- 授權層 -- 而整個 L3 的開放陣營，目前最明確的代表是 OWS。

新創的問題不是猜誰會贏，是搞清楚你的客戶是誰。客戶是誰、需求在哪裡、你賣的東西能不能解決他們的痛點。這些都必須先清楚地回答。

開放贏治理。封閉贏交付。兩條路不會互相消滅。它們的戰場從來就不一樣。

正在做 AI 支付基礎設施，或是正在觀察這個賽道？歡迎留言或私訊，想聽你的第一線觀察。

#AgenticCommerce #AgenticPayment #AIAgent #FintechInfra #OpenStandard

過去一年，幾乎每一場 Agentic Payment 的討論，最後都會繞回同一個問題：

AI Agent 到底要不要自己有錢包？

但我越想越覺得，這其實是錯的問題。

主流辯論的焦點都在錢包：要不要自帶錢包？要不要掌控私鑰？結算走鏈上還是走卡片軌道？這些都是真實的技術問題，但都還停在表面。

底下那件真正在發生的事，目前還沒人認真討論。

過去 60 年，所有支付系統都建立在同一個前提上：

想買東西的人，跟真正執行交易的人，是同一個主體。

你的信用卡是你的。
你的密碼是你的。
按下付款確認的手指也是你的。

Visa、Mastercard、PayPal、SWIFT，整個現代支付基礎設施，每一層都建立在這個假設上。

AI Agent 第一次打破了它。

當你授權一個 Shopping Agent 幫你訂飯店、買軟體、安排採購：

你是授權者。
Agent 是執行者。

這兩件事第一次被拆開了。一旦授權者與執行者不再是同一個人，過去半個世紀所有支付授權邏輯的底層假設，就開始失效了。

所以真正的問題不是 Agent 有沒有錢包。

而是：誰授權它？授權到哪裡？條件變了怎麼辦？出了事誰負責？

Wallet 解決的是 custody。
Mandate 解決的才是 delegation。

這不是錢包問題。

這是授權架構問題。

三種模式，三種不同的缺口

目前市場上，Agent Payment 大致正在往三個方向發展。

每一條都能解決部分問題。

但每一條，都留下了不同的缺口。

1. 自帶錢包模式（Agent-Owned Wallet）

以 Coinbase Agent Kit 為代表。

每個 Agent 擁有自己的鏈上地址，私鑰封存於 TEE（Trusted Execution Environment）安全執行環境，具備完全自主的簽署能力。

對於 DeFi 套利、做市、鏈上高頻交易這種場景，這是合理甚至必要的設計。因為在這些情境下，等人批准，本身就是不可接受的延遲。

問題不在架構，在規模。

500 個 Agent 意味著 500 把私鑰。金鑰一多，管理就會失控。輪換、撤銷、事故應變、風險隔離，每一件事都會變成營運與管理的負擔。

這種模式適合高自主、高頻交易的 Agent。但不太適合大部分企業流程型的 Agent。

2. 共享錢包模式（Shared Treasury Model）

這是目前最普遍的做法。

開發者維護一個共享資金池，Agent 透過 API Key、OAuth Token 或平台帳號取得認證，本身不持有任何金鑰。

對於 Coding Agent、Research Agent，或者所有支出只涉及 API 費用的場景，這個模式其實已經很好用。簡單、可控、容易管理。

但問題是：授權粒度太粗。

API Key 很適合回答：

「這是不是合法服務？」
「有沒有權限呼叫 API？」

但它回答不了另一個更重要的問題：「這個 Agent 現在到底被授權做到什麼程度？」或者更專業一點的問法：「這個 Agent 的授權邊界在哪？」

例如:

• 每天最多能花多少？

• 只能向哪些供應商付款？

• 授權什麼時候到期？

• 超過某個金額是不是要人工批准？

• 部門預算快超支時要不要自動停下來？

「你是誰」（Authentication）和「你被允許做什麼」（Authorization），其實是兩套完全不同的邏輯。但今天很多 Agent 基礎設施，還是把這兩件事混在一起。

3. Mandate 委託模式（Delegated Authorization）

目前我認為架構上最值得注意的方向，是 Google 提出的 AP2（Agent Payment Protocol）。

AP2 的重點不是給 Agent 錢包，也不是發 API Key，而是給它一份可驗證的授權文件：Mandate。

Mandate 本質上是一份帶有密碼學簽章的授權憑證，明確記載：

• 誰授權了這個 Agent（Principal）

• 它被允許執行哪類交易（Scope）

• 約束條件是什麼（Constraints：金額上限、白名單商家、有效期）

• 每一筆操作的密碼學可驗證紀錄（Auditability）

簡單說：Mandate = 誰授權 + 能做什麼 + 限制條件 + 可驗證紀錄

Agent 帶著 Mandate 行動，就像帶著一份可驗證的委託書。交易對手不需要信任任何中間平台說「這個 Agent 是被允許的」，可以自己驗證。

方向是對的。

但 AP2 解決的主要還是「授權格式」與「協議結構」問題。它定義了 Mandate 應該長什麼樣子。真正更困難的部分，其實在後面：

• Mandate 要怎麼大規模發行？

• 授權撤銷如何即時生效？

• 多個平台如何共用同一份授權狀態？

• Constraint 如何跨系統執行？

• 稽核紀錄如何讓第三方獨立驗證？

格式已經有了。但真正能在企業裡大規模運作的執行層，還沒出現。

KYA：AI 時代的新授權問題

目前對這個問題最有用的分析框架之一，來自 a16z crypto 提出的 KYA — Know Your Agent，可以理解為 AI 時代的 KYC。

KYC 問的是「這個人是誰」。

KYA 問的是四件事：

1. 這個 Agent 是誰，它由誰建立？

2. 是誰授權了它，哪個人類主體委託了它的行動？

3. 它被授權做什麼，金額上限、授權範圍、允許的交易對手是哪些？

4. 這份授權現在還有效嗎，有沒有被撤銷，有沒有被超出？

這裡真正重要的轉變是：未來的支付與商務系統，不再只需要驗證「身份」。

而是需要持續驗證「授權狀態」。

Skyfire 的 KYAPay 是目前落地最具體的 KYA 實作之一。它設計了三種 JWT Token：

• KYA Token：記錄 Agent 身份與背後的人類擁有者

• PAY Token：記錄這筆交易被授權了什麼

• KYAPay Token：兩者合一，讓商家一次驗證就能確認身份與支付授權

所有 Token 以 ES256 橢圓曲線數位簽章簽署，含有效期、受眾綁定、唯一 ID。Skyfire 透過公開的 JWKS endpoint 發佈驗證公鑰，商家、支付服務商或稽核師都可以自己抓公鑰、本地驗證 Token 的真偽，不需要回頭打 Skyfire 的 API。

但這還不夠。

知道 Agent 是誰，和知道它被允許做什麼，是兩件事。後者需要 AP2 Mandate 這樣的授權範圍層來補上。KYAPay 與 AP2 目前是各自獨立的提案，並沒有整合實作。現有方案解決了部分問題，但完整的信任鏈還沒有人真正建起來。

我對這個方向的評估是：架構思路是對的，但它解決的是「在某個時間點發行一份格式良好的授權憑證」。

但真正困難的地方，其實是「授權生命週期管理」。因為 Agent 不是簽完一次就結束。它會一直跑。

今天的市場條件、明天的預算狀況、下週公司政策的調整，都會影響一個 Agent「現在還能不能做這件事」。

真正需要的，不是一張靜態的授權書。

而是一套能夠隨著環境變化即時更新的授權系統：

條件變了，授權跟著調整。
超出範圍了，立刻停下來。
情境改變了，人可以隨時介入修改規則。

這個動態調整的能力，目前沒有任何一個方案真正做到好。

缺的那一層：Mandate Engine

這也是我認為整個 Agentic Payment 生態裡，現在最關鍵、但仍然空缺的一層。

MoonPay 推動的 Open Wallet Standard（OWS），其實已經非常接近正確方向。它的 Policy Engine 處理了基本需求：單個 Agent 的每日消費上限、地址白名單、時間綁定的授權窗口、簽署前檢查。

OWS 的設計者只定義大框架，而在 Policies 子規格裡預留了一個擴展介面：Optional Custom Executables。

意思其實很明顯。

真正的企業授權邏輯，不可能只靠幾個靜態規則解決。因為真實世界的企業授權，根本不是「每日限額」這麼簡單。

真實的案例可能是：

• 採購 Agent 提交超過 $500 的訂單時，不應該直接失敗，而是停下來等主管批准。

• DeFi 套利 Agent 不該只會「允許／拒絕」，它應該知道 gas fee 太高時先等待、條件到了再執行。

• 同一個部門可能同時有十幾個 Agent 在跑，每一個 Agent 只看得到自己這筆交易，不知道其他 Agent 今天已經花了多少。沒有共用的預算上限，等月底帳單出來才發現超支，已經太晚了。

• 所有授權與執行歷史，最後都需要能被外部稽核師獨立驗證，而不依賴平台運營者的內部記錄。

這些不是邊緣需求。這就是企業世界真正的運作方式。

這種「授權生命週期管理」的東西，在別的領域早就成熟了。

HashiCorp Vault 管的是密碼學金鑰和 API 憑證：誰能存取、什麼條件、何時撤銷；
Okta 管的是企業員工身份：誰能登入哪些系統、權限什麼時候到期。
兩個都解決了同一類問題：誰可以做什麼、什麼時候、規則變了怎麼辦。

現在我們需要的是同等級的工具，只是這次管的不是人，是 Agent。

AP2 的 Mandate 格式，最終需要一個 Engine。

一個真正的 Mandate Engine，需要做到什麼?

我認為至少有四件事。

1. 可驗證的授權執行

授權規則不能只存在平台內部。

第三方必須能獨立驗證：這個 Agent 是否真的依照授權範圍執行。

不能只靠平台自己說「我們有做到」。

2. 即時撤銷（Real-Time Revocation）

授權一旦被取消，所有正在執行的 Agent 都必須立刻停止。

不能依賴「下一次同步再更新」。

因為在 Agent 世界裡，幾分鐘的延遲，就可能代表真實金錢風險。

3. 可稽核的歷史紀錄

真正麻煩的時刻，是合規部門開始進場的時候。

銀行、企業法務、監管機構，最後一定會問同一件事：

「請證明過去六個月每一筆交易，都在授權範圍內。」

未來真正重要的，不只是支付成功。而是整條授權鏈能不能被驗證。

4. 協議中立（Protocol Neutral）

這層系統不能只綁定單一平台。

AP2、OWS、x402、卡片網路、銀行軌道，甚至未來新的 Agent 協議，都應該能接進同一套授權執行層。

否則每個平台最後都會變成自己的封閉授權孤島。

Stripe 的答案，以及它的邊界

Stripe Sessions 2026 剛剛落幕。它給出了目前最清晰的封閉式商業平台解方。

Stripe 這次在 Agentic Payment 推出三件事：

• Agentic Network Tokens（與 Visa、Mastercard 合作的 Agent 專用數位憑證）

• Issuing for Agents（程式化為 Agent 發行單次性虛擬卡）

• Agent Guardrails（指定 Agent 身份、設定可執行範圍、設置人工確認關卡）

邏輯非常完整。

Stripe 的優勢也很真實。支付世界最困難的事情之一，本來就是整合。Visa、Mastercard、Klarna、Affirm，每一套都有自己的規格與授權流程。過去要分別整合，現在接 Stripe 一次，全部搞定。

這個價值是具體的，不是行銷說辭。

但它也代表另一種取捨。

Stripe 的答案，本質上是：「把 Agent 的授權問題交給我處理。」

在 Stripe 生態裡，這件事成立。

但 Stripe 的 Guardrails 與授權邏輯，主要存在 Stripe 的盒子內。你可以設定規則，但無法獨立驗證規則有沒有被確實執行。

更重要的是：一旦你的 Agent 跑到 Stripe 不覆蓋的場景、協議、或平台，你的約束設定就不存在了。

這不是在批評 Stripe 的設計選擇。

這是任何封閉平台在授權基礎設施上的結構性限制。提供可以獨立稽核的密碼學審計，在架構上意味著把內部控制邏輯暴露給外部驗證，但這樣做，平台就失去了它最核心的護城河。

Stripe 的答案是「信任我來管理你 Agent 的授權」。

在 Stripe 的覆蓋範圍內，這個答案有效。

超出它的範圍，問題還在。

為什麼這個缺口最終必須被填上

真正麻煩的時刻，不是 demo。

是 AI Agent 真的開始進入企業財務流程的時候。

那時候，合規、法務、稽核、銀行、監管機構都會開始進場。他們問的問題不會是「這個 Agent 用哪個錢包」。

他們真正會問的是：

• 誰授權它？

• 它的授權範圍是什麼？

• 有沒有超出授權？

• 系統怎麼偵測和阻止違規行為？

• 出事的時候誰負責？

今天，大部分系統其實都還沒有完整答案。

封閉平台提供的是「平台信任」。
協議標準提供的是「資料格式」。
但真正跨平台、可驗證、可撤銷、可稽核的「授權執行層」，現在還是空白。

法規壓力是這個問題最終被解決的強制力。不是因為有人覺得「應該做」，而是因為當 AI Agent 開始在企業財務流程中承擔真實責任，合規要求會逼著企業重新檢視「信任某家平台的黑盒子」這個答案。

這一層最終會出現。

問題是它以什麼形態出現：

各大平台自己的封閉授權系統，彼此不互通，每個都只在自己的邊界內有效；

還是一層開放的、密碼學可稽核的 Mandate Engine，讓整個生態系的信任不依賴於信任任何單一的運營者。

我的判斷是：監管壓力和企業採購決策會最終推向後者。

封閉版本已經有了。Stripe 給出了它的答案。

真正還沒出現的，是開放、可稽核、跨平台的那一版。

所以接下來要問的是：

1. 開放版的 Mandate Engine 誰會先做出來？

2. 開放路線跟封閉平台，最後是並存還是取代？

如果你正在 Agentic Payment 領域建設，或者正在研究這層基礎設施，我很想聽聽你的看法。