Intent-Based Architecture

意圖驅動架構和傳統的「指令驅動」架構有什麼具體差別？用什麼標準判斷哪個更適合你的場景？

最清楚的方式是用一個具體例子對比：

傳統指令驅動（Instruction-Based）：用戶（或 Agent 的上層）指定每個操作的細節：

1. approve(Aave, USDC, 5000)
2. swap(USDC→ETH, amount=5000, slippage=0.5%, dex=Uniswap)
3. deposit(ETH, Aave, amount=全部)

每個步驟都是明確的命令，系統只需要執行。

意圖驅動（Intent-Based）：用戶只說：「我想把我的 5000 USDC 換成 ETH，存入 Aave 賺取利息，希望手續費最小化」。系統負責：找到最優的 USDC→ETH 路徑（考慮多個 DEX 的價格）、計算是否需要分批執行以降低滑點、選擇最好的 Aave 存入時機（Gas 費最低時）、執行完整的操作序列。

選擇標準：

• 用指令驅動：任務邏輯固定、不需要優化、用戶（或 Agent 開發者）清楚知道最優執行路徑；例如固定的套利策略、已知流程的自動化。
• 用意圖驅動：任務目標明確但最優路徑不固定（受市場條件影響）、用戶希望系統自動找到最好的方案；例如最優利率尋找、跨協議路由優化。

意圖驅動架構的代價是「執行路徑的不確定性」——你知道你要什麼，但不完全控制系統怎麼達到它。這在 Onchain Agent 裡帶來安全設計上的額外要求：你需要明確設定「意圖執行的邊界條件」（例如最大可接受的滑點、Gas 費上限）來防止系統以你不接受的方式「實現」你的意圖。

DeFi 的「Solver」機制是什麼？它怎麼和 AI Agent 結合？

Solver（求解者）機制是意圖驅動架構在 DeFi 場景的一個具體實現，代表協議有 CoW Protocol（Coincidence of Wants）和 UniswapX：

Solver 機制的工作流程：

1. 用戶提交意圖（「以最好的兌換率把 USDC 換成 ETH」）並簽署一個「意圖訂單」（不是直接廣播交易，而是簽署一個描述你意圖的授權消息）
2. 多個 Solver（可以是自動化程式或機構）競爭提供滿足用戶意圖的最優執行方案——他們可以使用 DEX、OTC 交易、或把多個用戶的互補意圖撮合在一起（Coincidence of Wants）
3. 最好的方案被選中，Solver 執行並在鏈上結算，用戶收到承諾的最優結果

AI Agent 和 Solver 的結合：Solver 本身就是一種可以由 AI Agent 驅動的角色——AI Agent 可以作為 Solver，實時分析所有待滿足的用戶意圖、計算最優撮合方案或執行路徑、在鏈上提交解決方案並賺取 Solver 費用。另一方面，AI Agent 也可以作為「意圖的提交者」——Agent 代表用戶分析市場狀況，決定什麼時候、以什麼條件提交意圖，讓 Solver 生態為這個意圖找到最優執行方案。

對 Onchain Agent 開發者的實際意義：如果你的 DeFi Agent 需要做大額的代幣兌換，使用基於 Solver 機制的 DEX（CoW Protocol、UniswapX）通常能獲得比直接在 AMM 上執行更好的兌換率，同時降低 MEV 攻擊的風險（因為意圖訂單不立刻在鏈上廣播，減少了被 MEV 機器人搶跑的機會）。

在 Onchain Agent 裡實作意圖驅動架構，最常見的設計陷阱是什麼？

意圖驅動架構聽起來很優雅，但實作時有幾個常見的設計陷阱：

陷阱一：意圖描述不夠精確，導致「合法但不可接受」的執行結果 「以最好的兌換率把 USDC 換成 ETH」這個意圖缺少邊界條件。如果 Solver 或 Agent 為了「最好的兌換率」，選擇了一個需要等待 3 天才能完成、或者把你的 USDC 放入一個你不信任的流動性池的方案，技術上這可能「滿足了」你的意圖，但結果是你不可接受的。解決方案：意圖描述必須包含邊界條件——「在 30 分鐘內、滑點不超過 0.5%、只在 Uniswap 或 Curve 上執行、Gas 費不超過 $X」。邊界條件越清晰，意圖驅動架構的安全性越高。

陷阱二：把「高層意圖」直接傳給 LLM，讓 LLM 自己決定執行路徑 「以最好的利率把資金移入最優協議」這個意圖如果直接交給 LLM 規劃執行路徑，LLM 可能產生幻覺（引用了錯誤的 APY 數字）、或者選擇了一個聽起來合理但實際不存在的執行路徑。正確的設計：LLM 負責把意圖分解成子任務規格（「步驟 1：查詢目標協議清單的 APY，步驟 2：選擇 APY 最高的協議，步驟 3：計算移倉是否划算，步驟 4：如果划算，生成移倉指令」），但每個子任務的執行由確定性的代碼邏輯完成，不讓 LLM 直接決定具體的參數值。

陷阱三：忽略意圖的「有效期」設計 用戶在某個市場狀況下表達了一個意圖（「現在 APY 5% 以上就移倉」），但如果 Agent 在執行過程中遇到延遲（Gas 費太高等待、工具調用失敗重試），等到真正執行時市場狀況已經改變，原來的意圖可能已經不再成立。設計要點：意圖應該包含有效期（「這個意圖只在接下來 2 小時內有效，超時後必須重新評估」），確保 Agent 不會在意圖失效後仍然基於過時的判斷執行操作。

意圖驅動架構和 ReAct（Reason + Act）框架的差別是什麼？它們是互相競爭還是互補？

這兩個概念在 AI Agent 設計裡常常被混淆，但實際上它們描述的是不同層面的架構設計，可以互補而不是競爭：

ReAct 框架描述的是 Agent 的推理-行動循環：ReAct 是 Agent 在每個推理循環裡的工作模式——Thought（推理）→ Action（工具調用）→ Observation（觀察結果）→ 再次 Thought。它描述的是「Agent 怎麼在單個任務裡一步一步做決定」，是 Agent 的微觀執行模式。

意圖驅動架構描述的是任務如何被表達和分配：意圖驅動架構關心的是「用戶（或上層系統）怎麼告訴 Agent 要做什麼」，以及「Agent 怎麼把高層意圖分解成可執行的子任務」。它描述的是 Agent 系統的宏觀任務分配和規劃層。

怎麼結合：一個典型的意圖驅動 Onchain Agent 設計：用戶（或上層 Orchestrator）提交意圖（宏觀層：意圖驅動架構）→ Agent 的 Planner 把意圖分解成子任務序列（仍是意圖驅動架構的範疇）→ 每個子任務由一個使用 ReAct 框架的 Sub-agent 執行（微觀層：ReAct）。意圖驅動架構和 ReAct 框架在不同層面分別工作，組合使用讓 Agent 系統既能處理高層次的任務描述（意圖），又能在執行層有靈活的推理-行動循環（ReAct）。