Pre-ERC：代理服務會話——針對持續性代理工作的計量支付方案

問題

ERC-8183 處理單次任務（僱用、交付、結算）。x402 處理請求-響應。但代理（Agent）通常以「會話」（Session）模式工作：監控、研究、持續優化。目前缺乏針對持續性代理參與的計量計費標準。

Stripe 於 3 月 18 日推出了他們的機器支付協議（Machine Payments Protocol），包含基於會話的代理支付。那是中心化的。我們需要鏈上的等效方案。

ERC-1620（資金流）和 ERC-1337（訂閱）在 2018 年嘗試過相關設計，但停滯不前。AI 代理正是這些設計當初所缺失的採用案例。

提議解決方案

一種用於代理之間基於區間計量支付的「會話」（Session）原語：

• 用戶開啟會話，在 ERC-20 代幣中鎖定最高預算。

• 提供者按離散區間賺取收益（而非像 ERC-1620 那樣的連續流）。

• 檢查點（Checkpoints）由線下雙重簽署（EIP-712）。在正常路徑下零 Gas 消耗。

• 任何一方都可以在任何區間邊界乾淨地終止會話。

• 爭議會標記特定區間，由外部仲裁者解決。

為什麼是計量區間而非資金流？

代理的工作是以離散單位進行的（一次研究週期、一次監控掃描、一次優化傳遞）。雙方都希望在有意義的邊界檢查質量。計費爭議需要引用特定的區間，而不是任意的時間範圍。

核心接口

function openSession(
    address provider, address token,
    uint256 ratePerInterval, uint256 interval,
    uint256 maxTotal, uint256 endTime,
    uint256 checkpointFrequency, bytes32 termsHash
) external returns (uint256 sessionId);

function settleCheckpoint(Checkpoint calldata checkpoint) external;
function terminateSession(uint256 sessionId, Checkpoint calldata finalCheckpoint) external;
function pauseSession(uint256 sessionId) external;
function disputeCheckpoint(uint256 sessionId, uint256 intervalIndex, bytes32 evidenceHash) external;

生命週期

openSession() --> [活躍] --checkpoint--> [活躍] --terminate--> [已關閉]
| |
+--pause--> [已暫停] --resume--> [活躍] |
| |
+--dispute--> [爭議中] --resolve--> [活躍] |
| |
+--endTime 到期--> [已過期] --refund--> 完成 |

可組合性

• 與 ERC-8203（條件結算）兼容。每個檢查點可以是一個 ConditionalLock。

• 與 ERC-8183（代理商業）兼容。每個檢查點映射到一個任務原語。

• 與 ERC-8004（代理身份）兼容。代理通過註冊表條目進行識別。

• 不強制要求以上任何一項。普通地址即可正常工作。

我正在尋求的建議

在提交正式的 ERC PR 之前，徵求關於會話模型的反饋。特別是：

• 計量區間是正確的粒度嗎？還是應該也支持連續流？

• 爭議機制是否過於簡化？標準應該定義仲裁策略，還是將其留給外部處理？

• 檢查點是否應該攜帶 serviceProof 哈希，還是這屬於過度規範？

完整的規範草案及參考實現已準備就緒，將隨正式 PR 一併發布。

相關討論：ERC-8203, ERC-8183, ERC-1337

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/pre-erc-agent-service-sessions-metered-payments-for-ongoing-agent-work/28070)