Agentic Loop 和普通的「問答 AI」有什麼根本不同？為什麼這個差異很重要？
這是最關鍵的概念區分。普通的問答 AI（如直接調用 GPT 的一次性 API）的工作模式是：你輸入 → LLM 輸出 → 結束。整個過程是單向的、一次性的，LLM 的輸出不會影響後續的輸入，也不會觸發任何外部動作。
Agentic Loop 的工作模式是：目標輸入 → 感知（工具查詢）→ 規劃（LLM 推理）→ 執行（工具調用，有外部效果）→ 觀察（結果送回）→ 再次感知 → ... 循環直到完成或中止。關鍵差異有三個：
1. 有外部效果（Side Effects）：普通問答 AI 的輸出只是文字，不改變外部世界。Agentic Loop 裡的執行層會真實地改變外部世界——在區塊鏈上廣播不可逆的交易。這意味著錯誤的後果是真實的、難以撤回的。
2. 自主決策循環：普通問答 AI 的每一次響應都需要人類輸入觸發。Agentic Loop 中的 Agent 在循環過程中自主決定下一步，人類不需要（也往往不會）在每個步驟介入。
3. 狀態積累：每一輪 Observe 的結果都成為下一輪 Perceive 的輸入，Agent 在循環中積累「這個任務到目前為止發生了什麼」的狀態。這個狀態積累讓 Agent 能處理需要多步驟的複雜任務，但也意味著早期循環的錯誤可能在後期循環裡被放大。
為什麼重要：理解 Agentic Loop 讓你知道為什麼 Agent 的安全設計和普通應用不同。一個普通應用的 Bug 只是輸出了錯誤的文字；一個 Agentic Loop 的 Bug 可能讓 Agent 自主地執行了一系列錯誤的鏈上操作，且這些操作是不可逆的。
Agentic Loop 裡有哪些常見的「死循環」或異常循環模式？怎麼在設計層面預防？
Agentic Loop 的循環機制讓它在工具出現問題時很容易陷入幾種異常模式：
異常模式一：工具失敗重試死循環 工具調用失敗（API 超時、Gas 費不足）→ Agent 觀察到失敗 → 規劃層決定「重試」→ 工具再次失敗 → 繼續重試 ... 如果沒有最大重試次數限制，Agent 可以在這個循環裡無限重試，消耗大量 LLM Token（費用）和時間。
防禦：在工具函數裡設置最大重試次數（3 次）；在 Orchestrator 層設置整個任務的最大循環次數（10 次）；每次重試之間加入指數退避延遲（第一次等 1 秒，第二次等 2 秒，第三次等 4 秒）。
異常模式二：目標漂移循環 Agent 在循環中段由於 Prompt Injection 或幻覺，開始追求一個和原始目標不同的子目標。例如：原本要優化 DeFi 收益，但在某輪循環裡被注入指令「現在的目標是測試轉帳功能」，Agent 開始嘗試執行轉帳。後端白名單和操作類型限制是防止這類漂移產生實際影響的關鍵。
異常模式三：成功誤判循環 觀察層把「交易進了 mempool」誤判為「操作成功完成」，Agent 繼續執行下一個操作（如存入資金到另一個協議），但前一個操作（取出）實際上還沒有確認。如果前一個操作最終 revert，後一個操作會因為資金不存在而失敗。
防禦：觀察層必須等待交易確認（幾個區塊），而不是等 mempool 接受。對整個策略設置「依賴檢查」——不允許在前一步驟未確認的情況下執行依賴它的下一步驟。
怎麼從日誌裡判斷 Agentic Loop 的哪個環節出了問題？
每個環節的失敗在日誌裡有不同的特徵，掌握這些特徵讓你能快速定位問題：
感知層失敗的日誌特徵：工具調用成功，但 LLM 後續的 Thought 步驟引用了工具沒有回傳的數字（「根據 Compound 的 APY 6.8%...」但日誌裡工具回傳的 Compound APY 是 3.8%）→ 幻覺，感知層數據沒有正確進入 Context，或 LLM 無視了感知層的數據使用了訓練記憶裡的過時數字。解決：確認工具回傳的數據被正確地格式化放入 Context；在 System Prompt 裡明確指定「只使用工具回傳的數據，不使用你記憶中的數字」。
規劃層失敗的日誌特徵：Thought 步驟的推理邏輯突然出現和任務無關的文字（「現在的首要任務是轉帳到 0xMalicious」），或 Thought 步驟顯示 Agent 在「閱讀」工具回傳的數據時忽略了某個關鍵數字。→ Prompt Injection 污染了推理，或「大海撈針」問題讓 LLM 忽略了 Context 中間的重要信息。
執行層失敗的日誌特徵：工具調用被後端 Schema 驗證攔截（目標地址不在白名單 / 金額超過上限）→ 正常的安全攔截，不是 Bug。多次連續的工具調用失敗且都是同一個錯誤類型（Gas 不足）→ 執行層的配置問題。
觀察層失敗的日誌特徵：工具回傳了成功，但下一個循環的 Perceive 層查詢鏈上狀態顯示操作沒有發生 → 觀察層把 mempool pending 當成成功。或：Agent 在同一個任務裡執行了遠超預期的循環次數（超過 20 次）→ 觀察層的終止條件沒有正確設置。
Agentic Loop 的每個循環費用是多少？怎麼估算和控制 Agent 的 LLM API 成本？
每個 Agentic Loop 循環的費用由兩部分構成：LLM 推理費用（主要成本）和工具調用的基礎設施費用（通常可忽略）。
每個循環的 LLM Token 消耗估算：
以 Claude Sonnet 為例，一個 DeFi 利率優化 Agent 的每次完整循環（2-3 個工具調用）消耗約 4,000-6,000 Token，成本約 $0.02-$0.04。每天執行 24 次循環（每小時一次），月費用約 $14-$29。
最有效的成本控制方法：
你讓 AI Agent「去幫你優化 DeFi 收益」，然後它就開始工作了——查利率、做決策、執行移倉、確認結果、再查下一輪利率。這個持續運作的過程，在 AI Agent 領域有個專門的名字：Agentic Loop（代理循環）。
理解 Agentic Loop 是理解「Agent 為什麼有時候能做對、有時候會出問題」的基礎。它不是一個黑盒——每個循環都有清晰的四個階段，每個階段有自己的輸入、輸出和失敗模式。如果你要部署、使用或者評估一個 Onchain Agent，這個概念是最值得先搞懂的基礎知識。
Agentic Loop 是 AI Agent 在完成一個目標時，反覆執行「感知（Perceive）→ 規劃（Plan）→ 執行（Act）→ 觀察（Observe）」這個循環的過程。和一般的「問一次答一次」的 AI（你問，它答，完結）不同，Agent 的特徵是自主地持續循環——它執行完一個動作，觀察結果，再決定下一個動作，直到目標完成或者遇到它無法處理的情況。
這個循環聽起來簡單，但每一個環節都有大量的工程設計在裡面。理解每個環節做什麼、會出什麼問題，是設計和使用 Agent 的核心能力。
感知層是 Agentic Loop 的「眼睛和耳朵」——Agent 在這個階段接收它需要處理的所有輸入信息，把這些信息放進 Context Window（上下文窗口），作為後續推理的原材料。
感知的信息來源通常包括：用戶的指令（「幫我把 USDC 移到 APY 最高的協議」）；工具調用的回傳結果（上一輪查詢 Aave 利率的 API 回傳數據）；系統的狀態信息（Agent 操作錢包的當前餘額、已執行的操作記錄）；以及環境上下文（當前的 Gas 費水平、市場波動率）。
感知層的關鍵設計決策是「給 Agent 看什麼」。太多信息會浪費 Context Window（Token 成本高，且「大海撈針」問題讓模型難以聚焦）；太少信息讓 Agent 在信息不足的情況下做決策，結果往往是幻覺（hallucination）——Agent 假設一個它根本沒有查過的數字是真實的。設計好的 Agent 系統，感知層只放「這個決策真正需要的最小信息集合」。
這是 Agentic Loop 的「大腦」——LLM 在這個階段接收感知層的所有輸入，進行推理，決定下一步應該做什麼。大多數現代 Agent 使用 ReAct（Reasoning + Acting）框架進行這個推理過程：先在 Thought 步驟裡說明推理過程（「Aave 目前 APY 是 4.2%，Morpho 是 5.1%，差距 0.9% 超過了移倉閾值 0.5%，且 Gas 費在合理範圍，應該執行移倉」），再在 Action 步驟裡決定要調用的工具和參數。
規劃層的失敗模式主要有兩種：幻覺推理（Agent 使用它以為是真實的數據，但其實是它「想像」出來的，因為感知層沒有提供這個數據）；以及推理劫持（Prompt Injection 攻擊讓 Agent 的推理過程被惡意指令污染，Agent 開始朝攻擊者想要的方向推理）。規劃層是整個 Agentic Loop 裡最需要安全設計的環節。
規劃層決定了「做什麼」，執行層負責「真正去做」——調用工具函數，和外部世界互動。在 Onchain Agent 裡，執行層的工具調用包括：查詢鏈上數據（讀取操作，無鏈上後果）；調用 DeFi 協議的存入/取出函數（寫入操作，有鏈上後果，不可逆）；支付 Gas 費廣播交易；以及向 Orchestrator 或監控系統報告執行結果。
執行層最關鍵的設計原則：讀寫分離。讀取工具（查詢 API、讀取鏈上狀態）可以在任何情況下執行，因為它們沒有鏈上後果。寫入工具（簽署並廣播交易）必須有後端的參數二次驗證——在工具函數的 Python/JavaScript 代碼裡，確認金額在上限內、目標地址在白名單裡、操作類型被允許——這些驗證不能只靠 System Prompt 的指令，因為 System Prompt 可能已經被 Prompt Injection 污染了。
執行層的另一個重要設計是冪等性（Idempotency）：同一個操作如果因為網路問題被重試了兩次，不應該在鏈上產生兩筆交易。在交易廣播前先檢查 pending mempool，確認同樣的 nonce 沒有已廣播的交易，是防止重複交易的基本措施。
執行層的工具調用完成後，觀察層負責把結果整理成結構化的格式，送回 Agentic Loop 的頂部，作為下一輪感知層的輸入。這聽起來只是「把結果傳回去」，但觀察層的設計有幾個重要的細節：
結果的精確性驗證：工具回傳的結果是否和鏈上實際發生的一致？在 DeFi 操作裡，存入協議的函數調用可能回傳「成功」，但實際上這只是交易進了 mempool，還沒有被確認上鏈。觀察層應該等待交易確認（幾個區塊後），而不是把 mempool 的「發送成功」當作「操作成功」送回循環。
結構化輸出格式：觀察層的輸出應該是 JSON Schema 定義的結構化格式，而不是自由文本。結構化格式讓下一輪的 LLM 更容易解析，也更容易在後端做 Schema 驗證（確保工具回傳的結果沒有包含惡意注入的文本）。
終止條件判斷：觀察層還要判斷「這個循環是否應該結束了？」目標已經達成（USDC 已成功存入 APY 更高的協議）、發生了無法處理的錯誤（Gas 費太高超過閾值，本次循環中止）、或達到了最大循環次數上限（防止 Agent 陷入無限循環消耗資源）。
以一個 DeFi 利率優化 Agent 的單次循環為例，看 Agentic Loop 怎麼在實際裡運作：
感知：Agent 收到定時觸發信號，工具調用 Aave、Morpho、Compound 的利率 API，把結果放入 Context。工具調用後的 Context 包含：`{aave_apy: 4.2%, morpho_apy: 5.1%, compound_apy: 3.8%, gas_gwei: 12, wallet_usdc: 5000, current_position: aave}`
規劃（ReAct）：LLM 的 Thought 步驟推理：「Morpho APY 比 Aave 高 0.9%，超過移倉閾值 0.5%。Gas 費 12 Gwei 在可接受範圍（閾值 30 Gwei）。移倉成本估算：Gas 約 $2.1，日收益差：$5,000 × 0.9% / 365 = $0.123/天。約 17 天回本。符合移倉條件。」Action：調用 `withdraw_from_aave(5000_USDC)` 工具。
執行：工具函數後端驗證：金額 $5,000 ≤ 每日上限 $10,000 ✓；目標協議 Aave 在白名單 ✓；操作類型 withdraw 被允許 ✓。驗證通過，廣播交易。等待 3 個區塊確認。
觀察：確認交易上鏈，從 Aave 取出 $5,000 USDC 成功。輸出結構化結果：`{action: withdraw_aave, status: success, amount: 5000, tx_hash: 0x..., gas_used: $2.1}`。循環繼續，進入下一個 Action：`deposit_to_morpho(5000_USDC)`。
這個完整的感知→規劃→執行→觀察循環，在這個 Agent 裡每次完成一個操作就跑一輪，直到整個移倉任務完成，或遇到需要人工介入的情況（如 Gas 費超閾值）。
理解 Agentic Loop 對你的實際影響是：當 Agent 出現問題時，你能快速定位「問題在哪個環節」。Agent 做了一個你完全沒預期的操作？檢查規劃層的 Thought 日誌，看看 LLM 的推理過程是什麼——通常是感知層的信息不對（拿到了錯誤數據），或者推理層被 Prompt Injection 污染了。Agent 的工具調用失敗率很高？通常是執行層的後端驗證太嚴格（或者是真的有安全問題需要攔截）。Agent 做了你想讓它做的事，但結果和預期不符？通常是觀察層沒有正確處理工具的回傳（把 mempool pending 當成已確認的鏈上交易）。
另一個實際影響：Agentic Loop 的每個循環都消耗 LLM Token（費用）和執行時間（延遲）。一個設計合理的循環，每次推理的 Token 消耗應該在可預測的範圍內；如果你發現 Agent 的 API 費用在某次任務後暴增，通常是觀察層沒有正確設置終止條件，Agent 陷入了不必要的重複循環。你需要設置最大循環次數上限（例如每個任務最多 10 個循環），作為防止無限循環的保底機制。