ERC-8219：為 AI 代理設計的智能合約指令標準
本提案引入了一項自我解釋智能合約的標準，透過在鏈上存儲 Markdown 字串，引導 AI 代理理解並執行複雜的合約操作流程。
一個自我解釋型智慧合約的標準。單一函數 instruction() 會回傳一個 Markdown 字串，該字串在合約自身的位元組碼（bytecode）中描述了 AI 代理（Agent）應如何與合約互動以完成完整的運作流程。
interface IInstruction {
function instruction() external view returns (string memory);
}
此指令存在於鏈上，具有與合約邏輯本身相同的不可篡改性和權威性。選擇 Markdown 是因為它是 AI 原生格式，大型語言模型（LLM）無需任何適配層即可理解。
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-8219-smart-contract-instruction/28223)