ERC-8210：自主 AI 代理的代理保證協定

一個代理人（Agent）支付了 10,000 美元進行數據分析工作，但結果卻從未交付。雖然託管資金被退回，但依賴該結果的下游價值可能已經損失。

目前還沒有標準的鏈上原語（primitive）能讓服務提供者針對特定工作預先提交抵押品，並在工作失敗時提供標準化的索賠路徑。

本草案提出了 代理人保證協定（Agent Assurance Protocol, AAP）：這是一個讓代理人能鎖定自身資本，作為特定工作履行保證的標準，並在觸發該保證時提供可程式化的索賠生命週期。

AAP 建立在 ERC-8183（代理人商務）之上。ERC-8183 處理工作執行和託管結算，但僅止於退款。AAP 則增加了上層架構：自籌資金的抵押承諾、保障類型以及索賠解決流程。整合方式為唯讀：AAP 觀察 ERC-8183 的工作狀態，而不修改 ERC-8183 合約。它也可以選擇性地與 ERC-8004 整合，用於身份門檻控管和解決者（resolver）準確性追蹤。

缺口

ERC-8183 涵蓋了正常路徑和基礎失敗路徑（退款），但未涵蓋：

• 提供者未交付導致的間接損失：客戶獲得退款，但未能就該工作預期產生的價值獲得補償。
• 評估者錯誤：錯誤的拒絕或欺詐性的批准，使受影響方缺乏標準化的追索路徑。
• 完成後結算失敗：工作已完成並經過認證，但由於受保代理人的行為，資金仍無法釋放。

代理人也無法實際進入傳統的保證金或擔保市場。目前缺失的是一個標準原語，用於：「我針對工作 Y 鎖定 X 金額，如果我在定義的條件下失敗，你可以對該鎖定的抵押品提出索賠。」

AAP 標準化的內容

AAP 引入了三個原語：

• AssuranceAccount：每個代理人獨立的自籌資金抵押儲備。
• JobAssurance：與特定 ERC-8183 工作掛鉤的承諾分配。
• Claim：當滿足保障條件時的付款請求。

三種強制保障類型：

保障類型	涵蓋內容
JobFailure	提供者未交付；工作達到拒絕或過期的終端狀態
EvaluatorDispute	評估者的決定透過正式爭議狀態或公認的鏈上爭議認證受到質疑
SettlementDefault	完成後歸因於受保代理人的結算失敗

另外兩種類型（AMLFreeze、SlashingLoss）為擴展保留，以確保跨實現的編碼穩定性。

這不是池化保險。每個代理人使用自己的資本支持其承諾。在核心模型中，沒有共享的承保池，也沒有第三方保險公司。

核心介面

interface IAAP {
    // 帳戶生命週期
    function depositAssurance(uint256 amount) external;
    function withdrawAvailableAssurance(uint256 amount) external;
    function getAssuranceAccount(address agent) external view returns (AssuranceAccount memory);

    // 保證生命週期
    function commitToJob(
        bytes32 jobId,
        CoverageType coverageType,
        address beneficiary,
        uint256 amount,
        uint64 expiry
    ) external returns (bytes32 assuranceId);

    function releaseCommitment(bytes32 assuranceId) external;
    function expireCommitment(bytes32 assuranceId) external;
    function getJobAssurance(bytes32 assuranceId) external view returns (JobAssurance memory);

    // 索賠生命週期
    function fileClaim(
        bytes32 assuranceId,
        uint256 requestedAmount,
        bytes calldata evidence
    ) external returns (bytes32 claimId);

    function resolveClaim(
        bytes32 claimId,
        bool approved,
        uint256 approvedAmount,
        bytes calldata reason
    ) external;

    function payout(bytes32 claimId) external;
    function getClaim(bytes32 claimId) external view returns (Claim memory);
}

關鍵會計不變量：

totalFunded == availableAmount + lockedAmount + paidOutAmount

此不變量必須在每次狀態變更操作後保持成立。

設計決策

• 自籌資金而非池化：每個代理人從其自身的 AssuranceAccount 支持其承諾。
• 每個 JobAssurance 僅限單次索賠：這是刻意的反垃圾郵件設計選擇；重新申請需要先釋放或過期先前的保證。
• 無許可的 payout()：一旦索賠獲批，任何人都可以觸發結算（Keeper 機器人、受益人、解決者）。
• 嚴格的資不抵債語義：payout() 會直接回退（revert）而非進行部分支付；核心模型優先保持會計不變量而非活性（liveness）。
• 保留委託資金功能：v1 僅限自籌資金；第三方支持保留給未來的擴展。

可選擴展可能包括抵押建議鉤子 (IRiskHook)、AML 篩查 (IAMLHook)、多解決者裁決、樂觀解決方案以及解決者質押/罰沒（slashing）。

草案規範：PR 連結

開放問題

我特別希望獲得關於以下方面的反饋：

• SettlementDefault 的可驗證性：此保障類型取決於歸因。在實踐中，僅從原始鏈上狀態很難區分「代理人過失」與「基礎設施故障」。要求公認的鏈上認證是否是正確的最低門檻？或者 SettlementDefault 應該是可選的而非核心標準中的強制項？
• 拒絕後續約的順序：在索賠被拒絕後，先前的 JobAssurance 會恢復為 Active 並保留 claimId，這會阻止重新提交和重複的 commitToJob()。因此，續約需要先釋放或過期。這是否是正確的順序？或者是否應該有一個明確的快捷方式，例如 forfeitCommitment()？
• 擴展保留的列舉（enum）模式：AMLFreeze 和 SlashingLoss 包含在核心 CoverageType 列舉中以確保編碼穩定性，但對它們的支持是可選的。這是否是正確的模式？或者可選的保障類型應該存在於單獨的擴展列舉中？

這些問題的主要設計拉鋸在於：索賠資格應有多少程度在核心 ERC 中標準化，又有多少應留給實現政策決定。非常歡迎提供反饋。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/erc-8210-agent-assurance/28097)