Mercury：當 Agent 能代表公司花錢
以前的 SaaS 多由人登入、點選、付款。當 Agent 能跨站購買服務，產品不只需要給人看的畫面，還要有可授權、可限制、可對帳的機器介面。
已查核的官方機制
Section titled “已查核的官方機制”查核日期 2026-10-18。Mercury Business 的 Agent card 是人類建立的專用虛擬卡，包含 debit 與 credit。人類設定日、週或月限額；Agent 透過 Vault API／CLI 取用指定卡的付款資料，不能自行建立 Agent card、提高該卡限額或解除凍結。官方 changelog 註明 reveal 當時尚不支援 MCP。卡資料取出後的保管由執行環境承擔；企業仍須對 Agent 交易負責，既有爭議處理另依條款辦理。
來源：Mercury Agent cards 說明、Vault API changelog。
Mercury 的 Vault API 不是 OpenBao。 本課沒有證據顯示 Mercury 採用這四個開源工具，也沒有把「Agent card 限制」推論成所有 API token 都沒有其他能力。實際權限要逐項確認。
從案例推導的架構問題
Section titled “從案例推導的架構問題”以下是本課的設計推論，不是 Mercury 功能清單。
| 問題 | 一種可討論的設計 | 對應本課 |
|---|---|---|
| 誰可以代表公司付款？ | 綁定人、Agent、任務與資源 | OpenFGA 的授權概念 |
| 付款資料放在哪？ | 由受控付款服務取得；不把完整卡資料放進模型上下文 | OpenBao 的機密生命週期概念 |
| 預算和幣別代表什麼？ | 明確定義期間、金額單位與費用歸屬 | OpenMetadata 的語意與責任概念 |
| 為何發生這筆付款？ | 任務 ID、授權結果、付款請求與結算紀錄可對應 | OTel 追蹤加財務對帳 |
| 同一請求被重送？ | 冪等鍵、原子預算保留、狀態機 | 應用與交易設計 |
| Agent 想增加自己的預算？ | 控制變更由人類或獨立角色核准 | 職責分離 |
注意：本課的 OpenBao 實作保管資料庫憑證，不保管支付卡資料。真實支付還需要依支付供應商要求處理敏感資料、付款授權、請款、退款和爭議。
模擬付款實作
Section titled “模擬付款實作”到沙盒的「Agent 支付思考」。每人有 USD 100 模擬預算，單筆超過 USD 30 轉人工核准，未知商家直接拒絕。這些門檻是本課自訂規則。
- 向教學 SaaS 送出 USD 20，請求編號
order-demo-01，應核准。 - 保持同一編號重送，應顯示 duplicate，新增扣款為零。
- 換編號、填 USD 40，應轉人工核准，不自動扣款。
- 換編號、選未知商家，應拒絕。
- 用不同編號累計達 USD 100，再付款應被預算擋下。
模型覺得值得買，不是付款授權。這個沙盒沒有真正的核准者、刷卡、退款或結算，只用來測試控制邏輯。