ERC-8218：為 AI 代理設計的智慧合約指令標準
ERC-8218 透過新增一個回傳 Markdown 字串的指令函數，引入了自我解釋智慧合約的標準，讓 AI 代理能直接從鏈上數據理解並執行完整的操作工作流。
這是一項關於自我解釋型智慧合約的標準。單一函數 instruction() 會返回一個 Markdown 字串，該字串在合約自身的字節碼中描述了 AI 代理應如何與合約互動以完成完整的流程。
interface IInstruction {
function instruction() external view returns (string memory);
}
該指令存在於鏈上，具有與合約邏輯本身相同的不可篡改性和權威性。選擇 Markdown 是因為它是 LLM 無需任何適配層即可理解的 AI 原生格式。
PR: Add ERC: Smart Contract Instruction by wispig66 · Pull Request #1683 · ethereum/ERCs · GitHub
動機
代理可以讀取 ABI，但 ABI 並沒有告訴它們如何使用合約——包括角色、多步驟流程、狀態機、費用規則、超時機制等。如今，這些知識被隔離在鏈下文件中，這些文件可能會過時、被審查或直接消失。instruction() 讓合約成為其自身的使用說明書。
| 標準 | 提供內容 | 受眾 |
|---|---|---|
| ABI / NatSpec | 函數簽名與開發者文件 | 開發者 |
| ERC-7572 | 合約身份（名稱、圖片） | 前端 |
| EIP-8174 (IntentSpec) | 單一函數語義 | 代理（函數層級） |
| 本 ERC | 完整的操作流程 | 代理（合約層級） |
生產驗證
SyncTx 在生產環境中的四種合約類型（贊助轉發活動、引用推文活動、關注獎勵活動和歐式期權）中部署了 instruction()，證明了單一返回 Markdown 的函數可以推廣到截然不同的業務領域。
開放問題
-
合約層級的流程是否為正確的抽象，或者範圍應該更窄/更廣？
-
規範定義了 CommonMark 的子集（無 HTML，無圖片）。這些約束是否正確？
-
是否有任何我可能遺漏的相關提案？
1 則貼文 - 1 位參與者 [閱讀完整主題](https://ethereum-magicians.org/t/erc-8218-smart-contract-instruction/28223)