意外開發了 ERC-8183：在生產環境運行 AI 代理工作市場的經驗教訓
我分享了在生產環境運行 AI 代理工作市場幾個月後總結的六個關鍵設計教訓，重點討論了評估機制、聲譽門檻以及混合鏈上託管系統的複雜性。
在生產環境中運行 AI 代理人工作市場幾個月後，一些在開始時並不明顯的設計決策如下：
1. 評估器（Evaluator）才是核心問題所在
合約並非難點。createJob()、fund()、submit()、complete() —— 一個符合規範的 ACPCore 可以在一個週末內寫完。評估器才是耗費數月時間的地方。誰來評估？評分標準是什麼？當「正確」與否取決於客戶的主觀判斷時，主觀任務該如何運作？最終程式庫中出現了三種不同的評估器模式（基於規則、AI 協調員以及多簽備援），因為沒有單一的標準答案。這才是真正的設計工作所在。
2. expiredAt（過期時間）被低估了
這很容易被視為一個無聊的參數。設得太短，服務提供者沒有時間完成高品質工作；設得太長，客戶資金會被鎖定而毫無進展。根據任務複雜度進行分層預設有所幫助，但更有趣的發現是框架效應如何影響使用者體驗（UX）：「您的資金在 X 小時後會有風險」與「工作截止日期為 X」相比，即使是相同的任務，客戶也會給出截然不同的數值。
3. 在 beforeAction 而非 afterAction 進行聲譽門檻限制
將聲譽檢查放在 beforeAction(fund)（在分配提供者之前），而不是在事後進行懲罰，對輸出品質產生了顯著影響。一個沒有准入過濾的開放市場會迅速充斥著低質量的提交，一旦這種模式建立，就很難扭轉。ERC-8004 的聲譽註冊表（Reputation Registry）現在為此提供了標準介面，但無論如何實作，這項設計原則依然成立。
4. 交付物是雜湊值（Hashes），而非內容
submit(jobId, deliverable) —— 這個參數應該是內容雜湊值，而不是內容本身。事後看來這很顯而易見，但早期的一些實作傳遞了原始文本。內容存放在 IPFS 或 Arweave，雜湊值存放在鏈上：這保證了 Gas 效率、不可篡改性以及可驗證的完整性。complete() 中的 reason 參數也是放置結構化評估證明雜湊值的好地方。
5. 女巫攻擊防禦（Sybil resistance）需要從一開始就設計進去
任何具有聲譽門檻存取或經濟獎勵的 ERC-8183 部署，都會比預期更早吸引協同的虛假提供者活動。具體的防禦措施因情境而異 —— 工作量證明（PoW）、社交活動信號、質押要求 —— 但在發布後才進行補救是非常痛苦的。它必須是初始設計的一部分。
6. 鏈下帳本 + 鏈上託管的混合模式比立即全鏈上化更現實
對於低於一美元的任務，Gas 的使用者體驗是一個真實的障礙。針對小額任務的信用抽象層 —— 贊助 Gas、批次結算 —— 並對高價值工作使用完整的 ERC-8183 託管，才是真正讓經濟模型運作起來的方法。合約不需要更改；抽象層只是一個代理服務。程式庫中包含了一個此模式的範例。
有興趣了解其他人如何處理主觀任務的評估器設計，以及聲譽層的女巫攻擊防禦。
1 則貼文 - 1 位參與者
[閱讀完整主題](https://ethereum-magicians.org/t/accidentally-built-erc-8183-lessons-from-running-an-ai-agent-job-market-in-production/27970)