「我想建一個 DeFi Agent」——這句話說起來很容易，但真正坐下來開始時，很多人不知道從哪裡開始：用哪個框架？錢包怎麼設置？私鑰放在哪？第一個工具應該寫什麼？
這篇文章給你一個可以直接執行的路線：從零開始建第一個 Onchain Agent 的最小可行架構，包含技術棧選擇、架構設計、和部署前的安全 Checklist。目標是讓你在兩天內有一個可以在測試網上運行的 Agent，而不是讓你先讀完所有的文檔再開始。
在寫第一行代碼之前，有三個問題你應該能清楚回答，因為它們的答案決定了你的技術選型：
問題一：你的 Agent 要在哪條鏈上運行？
這是最重要的第一個決定。以太坊主網的 Gas 費對初學者來說太高——一次測試性的移倉操作可能花掉 $5-20，這讓調試成本變得非常昂貴。強烈建議：第一個 Onchain Agent 先在 Base 或 Sepolia（以太坊測試網）上建構。Base 是以太坊的 L2，Gas 費是主網的 1/100，DeFi 協議生態足夠豐富（Aave、Compound 都有 Base 版本），非常適合初學者的第一個 Agent。Sepolia 是以太坊的公共測試網，可以用水龍頭獲得免費的測試 ETH，完全免費但 DeFi 協議生態較少。
問題二：你的 Agent 要做什麼具體的事情？
「DeFi 策略 Agent」太模糊。第一個 Agent 應該有一個非常具體、範圍很窄的任務。推薦的第一個任務：「每 30 分鐘查詢 Aave 和 Morpho 的 USDC 利率，如果利差超過 0.5%，發送 Telegram 通知（不自動執行移倉）」。這個任務：只有讀取操作（無鏈上風險）；有可驗證的輸出（Telegram 通知）；能讓你練習工具函數設計、Context 管理、和 Agent 框架使用，但不會因為 Bug 而損失資金。建議：先把「讀取 + 通知」版本做好，再逐步加入「自動執行」功能。
問題三：你的安全邊界是什麼？
在你的 Agent 加入自動執行功能之前，決定：最大單次操作金額是多少（建議從 $50-100 USDC 開始，確認 Agent 行為符合預期後再提高）；哪些協議在白名單裡（建議只有 1-2 個你熟悉且有審計的協議）；觸發自動執行的條件是什麼（利差多大才執行）；是否需要人工確認（強烈建議第一個版本加入 Telegram 人工確認機制）。帶著這三個問題的答案去設計你的 Agent，能避免大多數初學者的常見錯誤。
對第一個 Onchain Agent，推薦以下技術棧（Python 為主）：
Agent 框架：LangChain + LangGraph。LangChain 提供了工具封裝、Memory 管理、和 LLM 集成的基礎設施；LangGraph 提供了有向圖的 Agent 執行流程控制，讓你能精確定義「讀取 → 分析 → 確認 → 執行」的步驟分隔。LangGraph 的學習曲線比其他框架稍高，但它對 Onchain Agent 的安全設計（可以在圖的設計層面阻止直接的讀取到執行跳轉）最為友好。安裝：`pip install langchain langgraph`。
LLM：Claude Sonnet 或 GPT-4o mini。對第一個 Agent 的任務（利率比較 + 決策），Claude Sonnet 是性能和成本的均衡選擇（$3/百萬輸入 Token）；如果預算更緊，GPT-4o mini 也夠用（$0.15/百萬輸入 Token）。Anthropic API Key 和 OpenAI API Key 都可以在各自的開發者控制台申請，免費有一定的初始額度。
區塊鏈交互：Web3.py。Python 的標準以太坊庫，提供讀取鏈上數據、構建交易、簽署廣播的完整功能。安裝：`pip install web3`。對 Base 鏈，RPC 節點可以用 Alchemy（免費層每天 300 個請求）或 Base 官方 RPC（`https://mainnet.base.org`，完全免費但有速率限制）。
部署環境：Railway。Railway 提供了最簡單的 Python 應用部署體驗（GitHub 倉庫直接部署，5 分鐘搞定），有免費的 Starter 方案（$5 的免費額度），支持環境變數（用來存 API Key 和私鑰，不硬編碼在代碼裡），內置日誌系統。對第一個 Agent，Railway 是最低摩擦的選擇。
通知系統：Telegram Bot。用 `python-telegram-bot` 庫建一個 Telegram Bot，幾行代碼就能讓 Agent 把利率比較結果和決策推送到你的 Telegram。相比 Email 通知，Telegram 的延遲更低、更容易設置雙向交互（讓 Bot 等待你回覆「確認執行」）。
以「USDC 利率監控 + Telegram 通知 Agent」為例，描述最小可行架構：
目錄結構：
defi-rate-agent/ ├── main.py（主程序，啟動 Agent 循環）├── tools/ │ ├── get_rates.py（查詢 Aave 和 Morpho APY 的工具函數）│ └── notify.py（發送 Telegram 通知的工具函數）├── agent/ │ └── graph.py（LangGraph 圖定義）├── .env（API Keys，不提交到 Git）└── railway.toml（Railway 部署配置）
核心流程設計（LangGraph 圖）：
圖有三個節點：`fetch_rates`（調用 get_rates 工具，獲取 Aave 和 Morpho 的當前 USDC APY）→ `analyze`（LLM 推理：計算利差、判斷是否值得通知）→ `notify`（如果利差超過閾值，調用 notify 工具發 Telegram 消息）。
在 `analyze` 節點的 System Prompt 裡加入接地規則：「所有引用的利率數字必須來自 fetch_rates 工具的回傳數據，不得使用任何訓練記憶中的數字。如果 fetch_rates 返回失敗，輸出 ABORT 並終止本次循環。」
工具函數設計（get_rates.py）：
工具接受的 Input：無（利率查詢不需要參數）。工具做的事：調用 DeFiLlama 的 API（免費，無需 API Key）獲取 Aave 和 Morpho 在 Base 上的 USDC 供應 APY；做數值合理性驗證（APY > 30% 視為異常，使用上一次緩存值）；返回格式化的結果字符串：「Aave USDC APY: 4.2%，Morpho USDC APY: 5.1%，利差: 0.9%（查詢時間: 2026-06-29 03:12:44 UTC）」。注意：返回自然語言字符串而不是 JSON，減少 LLM 的解析錯誤風險。
主程序設計（main.py）：
用 Python 的 `schedule` 庫設定每 30 分鐘運行一次 Agent 圖；加入最大循環次數限制（每次運行最多 5 個循環，防止無限循環）；把每次運行的結果（包括 LLM 的完整 Thought 輸出）記錄到日誌文件（用 Python `logging` 模塊）。
在把 Agent 部署到任何環境之前，逐一確認以下清單：
代碼安全：
`.env` 文件已加入 `.gitignore`（確認你的私鑰和 API Key 不會被上傳到 GitHub）；所有 API Key 和私鑰都通過環境變數讀取，沒有硬編碼在代碼裡；在代碼裡搜索「0x」——確認沒有任何地址或私鑰被硬編碼。
工具函數安全：
讀取工具的返回值裡沒有任何能觸發鏈上操作的函數；工具返回值有合理性驗證（APY 超出 0-50% 範圍的記錄為異常，不進入 LLM Context）；所有工具調用都有超時設置（防止 API 無響應導致 Agent 卡住）。
Agent 行為：
System Prompt 有「數據接地規則」（要求 LLM 引用工具數據，工具失敗時中止）；設置了最大循環次數上限（防止無限循環）；有日誌記錄，能回答「Agent 最後一次運行做了什麼」。
第一次部署前的測試：
先在本地運行一次，確認 Agent 能正常查詢 API 和發送 Telegram 通知；把 LLM 的完整 Thought 輸出打印出來，確認它引用了工具回傳的數字而不是其他數字；測試「API 超時」場景（把 API 地址改成一個不存在的地址），確認 Agent 的行為是「記錄失敗日誌 + 停止」而不是「繼續推理並用記憶填充」。
第一個 Onchain Agent 不需要很複雜，但它需要對的架構——一個從第一天就對讀取/寫入隔離、數據接地、和日誌記錄有正確設計的 Agent，在之後加入自動執行功能時，安全擴展的成本遠低於一個「先快速做出來再說」的 Agent。
「先讀取 + 通知，再逐步加入自動執行」的路線不只是安全考量，也是最快速達到「有用的 Agent」的方式——一個能準確判斷「現在利差是多少」並即時推送到你的 Telegram 的 Agent，從第一天起就有真實的使用價值，而不是等到所有功能都完善後才能用。從這個最小可行版本開始，每週加一個功能，3-4 週後你就有一個完整的 DeFi 策略 Agent。