github.com/ethereum/ERCs

該提案規定了：

• 一個可透過 ERC-165 探索的介面 (IIntentSpec)，用於公開元數據 URI。
• 一個規範的 JSON 模式（Schema），定義了合約級別和函數級別的語義意圖。
• 元數據解析和模式合規性的規範要求。

其目標是提供一個結構化的文件層，使自動化系統能夠在執行前對合約行為進行推理。

此 ERC 是對 ERC-8004 的補充。ERC-8004 為自主代理（Autonomous Agents）標準化了身份、聲譽和驗證原語，而本提案則在合約層級標準化了語義意圖的披露。

討論串：
將在 Ethereum Magicians 上開啟。

我最近提出了 ERC-8174，它定義了將機器可讀的語義清單（Semantic Manifests）附加到智慧合約的標準。雖然 ABI 告訴我們「如何」調用函數，但它並未告訴自主代理其經濟後果或安全風險是什麼。此 ERC 引入了 IIntentSpec 來彌補這一差距。

摘要

本提案規定了：

一個公開元數據 URI 的 ERC-165 介面 (IIntentSpec)。

一個規範的 JSON 模式，描述合約級別和函數級別的語義意圖、前提條件和風險。

目標是超越人類可讀的 NatSpec，提供一個結構化層，供大型語言模型 (LLMs) 和自主代理在執行前推理合約行為。

動機：為什麼我們需要這個？

目前的自動化代理（AI/自主代理）必須根據函數名稱或解析混亂的 NatSpec 註釋來「猜測」意圖。這導致了：

歧義性： swap() 是一個簡單的交易還是複雜的多跳兌換？

風險： 如果沒有深度模擬，代理無法透過程式化方式「得知」一個函數是否具有不可逆的影響。

相容性： 此 ERC 被設計為 ERC-8004（代理身份）的語義對應部分。8004 處理代理「是誰」，而 8174 處理代理正在與「什麼」進行互動。

關鍵特性

鏈下元數據： 為了節省 Gas，清單存儲在 IPFS/Arweave 上，由 getIntentSpecURI() 指向。

標準化模式： 包含意圖、前提條件、效果和風險等欄位。

NatSpec 友好： 我建議使用自定義標籤（例如 @custom:agent-intent），以便開發者在構建過程中自動生成這些 JSON 清單。

社群討論點

我很想聽聽社群對以下幾個特定領域的看法：

模式 (Schema)： 目前的 JSON 模式是否太重，或者我們是否遺漏了代理所需的關鍵欄位？

鏈上 vs 鏈下： URI 指針是最好的方法嗎？或者對於不可升級的合約，我們是否應該考慮基於註冊表（Registry）的方法？

安全性： 我們如何更好地保護代理免受「語義欺騙」（即清單聲稱是一回事，但代碼執行的是另一回事）？

整合： 我們如何最好地將其與現有的開發者工作流（Hardhat/Foundry 插件）對齊？