作者：Michael Levin
來源：https://lightning.engineering/posts/2026-03-11-L402-for-agents/
AI 代理可以讀文檔（所以你好，代理！）、寫代碼、組織多步驟的工作流，還能在網絡上調用 API（應用程序接口）。但它們還不能可靠且大規模地買東西。信用卡需要身份；使用量面板需要用瀏覽器查看；會員制通常會在付費頁面要求人類確認。這些都不適合完全自動化運行、充當代理、毫秒級觸發的軟件。
互聯網的創造者們看到了這個趨勢。在 HTTP 規範的初創者們為之設計狀態碼的時候，他們加入了 402 Payment Required（402 要求支付），以便有朝一日互聯網發展出自己原生的支付層時，能夠用上。也就是說，這個操作碼是為了將來的用途而留置的。問題在於，在 1990 年代，還沒有去中心化的貨幣能夠利用這個操作碼。402 也就沉寂了數十年，因為未來沒有來而一直處於留置狀態。
但今時不同往日。L402 是一個協議標準，通過結合 402 狀態碼、比特幣的閃電網絡以及密碼學認證的 token，激活了互聯網的這個已被遺忘多時的狀態碼。閃電網絡是一個支付網絡，可以即時、高流量、地成本地處理交易。結果是，這套協議使得，任何能夠連接到閃電網絡的客戶端，都可以瞬時給任何啟用了 L402 的 API 支付（並認證自己的身份），不需要 “登錄”、不需要 API 密鑰，也不需要跟服務端預先建立關係。
最近我們發佈了 Lightning Agent Tools（閃電網絡代理工具），這是七種互補的技能描述（skill）的組合，讓 AI 代理能夠直接在閃電網絡上生活，包括給帶有 L402 網關的 API 支付、託管付費端點、組織端到端的 買家/賣家 工作流。今天，我們希望更深入地介紹讓這一切成為可能的這套協議、從頭到尾解釋 L402 是怎麼工作的、提煉 L402 bLIP 規範 的最新變更，並論證何以 L402 是 AI 代理經濟的正確支付協議。
L402 的工作原理：四步走，沒登錄
L402 是一個 HTTP 的身份認證方案。服務端使用 402 狀態碼來保護一項資源；客戶端支付一個閃電發票來獲得訪問權。整個交換過程分成四步走：
- 請求：客戶端（你的 AI 代理，或一個命令行工具，或者一個瀏覽器插件）向一個受保護的端點發送一個標準的 HTTP 請求。
- 挑戰：服務端返回
HTTP 402 Payment Required以及一個WWW-Authenticate響應頭，它包含兩個數值：一個 token（編碼了訪問權的密碼學證書）以及一個 BOLT 11 閃電發票（支付請求）。這個 token 承諾了發票的支付哈希值，所以客戶端可以無狀態地驗證它。 - 支付：客戶端解碼這個發票、確認數額是可以接受的，然後通過閃電網絡發送支付。支付結算會揭曉一個原像，它是一個 32 字節的數值，是支付的密碼學證據。這個原像滿足這樣的關係：
H = sha256(preimage)，其中H就是嵌入在 token 中的支付哈希值。 - 訪問：客戶端使用
Authorization: L402 <token>:<preimage>頭重試訪問請求。服務端會驗證這個 token，檢查其原像與承諾的支付哈希值相匹配，然後提供資源。
就這麼簡單。這個證書是買來的，不是預先配置的。沒有 OAuth 流程、不需要管理 API 密鑰，也不需要盯著使用量面板。這也是 L402 天然適合 AI 代理工作流的原因：AI 代理可以在運行中發現併購買資源，不需要人類為它預先註冊賬戶。
獲得 token 之後，就可以把它緩存起來、用在同一服務的後續請求中，直到它過期或者被撤銷。AI 代理是按端點付費的，不是按請求次數付費的。
有用且聰明的證書
L402 不挑 token 的格式，任何能夠承諾一個支付哈希值的身份認證 token 都能配合工作。但 L402 協議的規範推薦了 “macarron（馬卡龍）”，它是一種基於哈希函數的消息認證不記名證書格式，最初是由谷歌（Google）為分佈式系統的身份認證而設計的。
馬卡龍對 AI 代理有用，因為它具有標準的 API 密鑰和不記名 token 所不支持的兩種屬性：“降級（attenuation）” 和“ 委託（delegation）”。
降級的特性是，馬卡龍的持有者可以為一個證書增加限制，而且無需聯繫該證書的發行人。舉個例子， 一個父代理在獲得馬卡龍之後，可以給它追加限制（限制 token 用法的條件），比如花費的限額、服務約束、過期時間。產生出來的受限制的證書也能通過密碼學驗證，只是攜帶著更嚴格的許可，而且無需與（發行它的）服務端通信。
委託的特性是，受限制的證書可以交給一個次級代理。一個負責協調的代理可以創建出一個僅能支付的馬卡龍、設置它帶有 500 聰的花費限額，然後把它傳遞給一個負責獲取市場數據的員工代理。這個員工帶來可以在這些限制內購買資源，而不能超支。這個子代理是無法放鬆自己的許可的。證書在設計上強制執行了最低的權限。
可以說，這就是多代理系統所需要的許可層級系統。一個證書可以結合支付證據、有範圍的權限以及經過委託的權威到一個 token 中 —— 所有內容都可以驗證，而且無需查詢數據庫。
L402 bLIP：開放的規範，新的升級
L402 的正式文件是 bLIP-0026，它是一個提交到 閃電網絡規範庫 的 “ 比特幣閃電網絡優化提議（bLIP）”。bLIP 是閃電網絡特性的社區審核設計文檔，而 L402 bLIP 包含了完整的協議規範，從而每個人（每個代理）都能實現一個兼容的客戶端或服務端。
對這個 bLIP 的最新的擬議更新，包含了多項重要變更，反映了來自主動開發這套協議的多個團隊的反饋：
版本字段。通過在 WWW-Authenticate 挑戰頭中加入一個 version（版本號）參數，我們讓協議能夠獨立地演化而不打破已有的客戶端（當前，這個版本號是 "0"）。根據規範的前向兼容規則，不理解版本號參數的客戶端可以忽略它。
不挑 token 的設計。現在，規範擴展到支持馬卡龍以外的語言，使用 token 而非 macaroon 作為挑戰頭中的關鍵用名。唯一的硬性要求是，這種 token 要能承諾發票的支付哈希值，以允許無狀態的客戶端驗證。馬卡龍依然是推薦格式（因為它的降級和委託特性），但協議不再強制要求使用馬卡龍。一種推薦的馬卡龍結構已經放到了附錄中。
簡明的規範。整個文件已經大幅精簡，刪去了不必要的累贅表述，但保留了用於指導實現的所有協議細節。
擬議的這些變更將讓 L402 更容易實現、在 token 格式上更加靈活，並且為前向兼容性作了更好的準備。這個 bLIP 還包含了後向兼容條款，比如，服務端會同等接受 token 和馬卡龍的參數。
為什麼說 L402 適合 AI 代理經濟
2026 年有望成為 AI 代理支付之年。我們已經看到了多個瞄準這個領域的協議出現。目標都是一樣的，讓AI 代理能夠自動化地發現、購買和消費服務，不需要人力的干預。L402 從一開始就有這個目標。相比其它的方案，L402 擁有結構化的優勢，對 AI 代理從簡單的調用工具成為真正自主的商業具有重要意義。
支付的密碼學證據，內置於證書。當一個AI 代理給一個 L402 端點支付了閃電發票時，閃電網絡會揭曉一個 32字節的原像。這個原像，結合那個 token，就組成了一個證明這筆支付已經發生的自我說明的（self-contained）證據。服務端驗證用一次簡單的哈希運算 sha256(preimage) == payment_hash 來驗證它。不需要查詢數據庫，不需要 RPC 調用一個區塊鏈節點，也不需要外部的驗證服務。
L402 以外的方法通常會將支付簽名與結算分割開來。客戶端簽名一個支付意向，第三方協調員廣播這筆交易，然後服務端必須用鏈上狀態來驗證它，要麼就得信任協調員來確認支付。這就帶來了外部依賴和時延，而 L402 就完全沒有這些東西。L402 的驗證是一種本地計算。密碼學的憑證本身就是證據，不需要詢問中介，也沒有人會無法確認支付。
對於一分鐘可能要調用幾百次 API 的 AI 代理來說，“用數學在本地驗證” 和 “調用一個外部服務來檢查支付狀態”，不啻天壤之別。
隱私是架構，不是特性開關。L402 運行在閃電網絡上，閃電網絡使用洋蔥路由來轉發支付，每一箇中間節點都只能看到他的上一跳和他的下一跳。支付不會在區塊鏈上留下蹤跡。L402 證書自身是一種不記名的 token，跟一個隨機的標識符綁定，無關郵箱、賬戶，更無關真實世界的身份。
其它運行在公開的區塊鏈上的協議，會永久記錄每一筆交易：它的發送者地址、接收者地址、數額，還有時間戳，對每個人都可見。對於要向數十個服務頻繁發起微支付的 AI 代理來說，這會暴露出可見的模式：它們訪問的每一項資源、何時訪問的、使用量多少。AI 代理活動的元數據可能是商業敏感的，所以默認暴露出這些元信息的協議是一種負債。
不需要中介，沒有宕機時間。閃電網絡是免許可的。它不是由單個主體來運營的。L402 服務端只需要使用自己的根公鑰和收到的 token 就能驗證證書，不需要依賴任何第三方的在線服務，也不需要它們配合。
許多其它的 AI 代理支付協議都通過一家公司的基礎設施來排序交易、協助交易和發行 token，也就是說，一旦這家公司服務中斷，你的 AI 代理也不用玩了。L402 的架構讓這些功能分散在幾千個獨立的節點中。
多代理系統的證書複雜性。如前所述，L402 的基於馬卡龍的證書，支持層級式的委託和權限遞減，無需聯繫發行人，可以重複使用直至吊銷。一個代理一旦獲得了一個證書，就能重複使用它，而 token 自身就編碼了服務的內容、權限和受到的約束。其它方法則將每一次請求都視作一筆單獨的支付：確實，沒有狀態，也簡單，但缺乏一個永久的證書層來為 AI 代理團隊管理權限的層級。也就是說，使用 L402，多代理的系統可以自動管理預算、許可和服務訪問權，無需人類為每一個子任務重新授權。
來開發吧
L402 協議已經準備好進入生產環境。從五年前的第一個版本開始，Lightning Loop 就通過 Aperture（能夠感知 L402 的反向代理）來使用 L402 。
如果你現在就像讓你的 AI 代理通過 L402 來發送交易，Lightning Agent Tools 提供了完整的技術棧： lnd 技能描述，棵用於運行一個閃電節點； lnget 技能描述，可以自動給受 L402 保護的 API 付費；aperture 技能，可以託管收費端點、並通過馬卡龍烘培實現受限制證書的管理；還有一個商業準技能，可以協調端到端的 買家/賣家 工作量。閱讀這篇博客可以瞭解詳情（中文譯本），或者，你可以直接閱讀 L402 和 lnget 文檔。
L402 bLIP 規範是開放審核和增補的。我們邀請整個社區來探索，在 L402 庫中給出反饋、分享應用場景以及提出疑問。開源的客戶端和服務端庫在多種語言中已經存在：JavaScript、Go、Rust、Python 。這個 Aperture 開發者文檔介紹了服務端的搭建流程。如果你已經在使用 AI 代理，這些技能描述可以跟任何能夠執行 shell 命令的框架配合工作：Claude Code、Codex、OpenClaw，以及你自己的工具 : ）。
來看看 L402 的文檔，參加我們的 Slack 社區，在 Twitter/X 上關注我們，提交一個 PR，還可以訂閱我們的週報。機器可以支付的互聯網不會自我生成。好吧，也許會。那麼就讓我們與 AI 代理互幫互助吧！
（完）
