這個 35 項 Checklist 太長了，如果時間有限，應該優先完成哪幾項？
如果你只有 4 小時，這 8 項能覆蓋最高比例的風險：
第一優先（30 分鐘，代碼安全基礎）：確認 .env 已加入 .gitignore，搜索 Git 歷史確認沒有私鑰/API Key 洩漏。這是最低成本、最高風險的一項——很多開發者在不知情的情況下把私鑰上傳到了 GitHub。如果已經洩漏，立即輪換所有密鑰。
第二優先（1 小時，錢包架構）：操作錢包和資金錢包分離。即使沒有時間設置 Safe 多簽，至少確保「操作地址只持有少量 Gas ETH，主要資金在另一個你控制的地址」。這一項把私鑰洩漏的最壞損失從「全部資金」降到「幾十美元 Gas ETH」。
第三優先（30 分鐘，後端驗證）：確認所有寫入工具調用在執行前做目標地址白名單檢查 + 金額上限檢查。這兩個檢查必須在代碼層面，不能只寫在 System Prompt 裡。
第四優先（30 分鐘，熔斷設置）：設置日 Gas 消耗上限和日操作次數上限，觸發後自動暫停並 Telegram 告警。這讓異常操作在造成更大損失之前被發現。
第五優先（30 分鐘，緊急停止）：建立緊急停止機制（Telegram 命令或環境變數），確認它在不需要修改代碼的情況下能在 30 秒內停止 Agent 的所有操作。
其餘 27 項是「更完整的安全保障」，但有了上面 8 個核心防線，Agent 面對最常見攻擊場景的基礎保護已經到位。
Safe 多簽在實際操作裡最容易出錯的地方是哪裡？有沒有常見的配置錯誤？
Safe 多簽是 Onchain Agent 安全設計裡最強的防線，但也是最容易配置錯誤的。常見問題：
錯誤一：把守護者地址也設成了 Agent 能訪問的地址。最常見的配置錯誤——開發者為了「方便測試」，把守護者地址設成了和操作地址在同一個 .env 文件裡的地址。如果 .env 洩漏，兩個 Signer 地址都被攻擊者拿到，Safe 多簽完全失效。正確設計：守護者地址必須完全離線，存在硬件錢包裡，永遠不在任何代碼文件或環境變數裡。
錯誤二：Safe 的 threshold 設為 1-of-2。如果 threshold 是 1（任意一個地址就能簽名執行），多簽等於沒有——攻擊者只需要控制任意一個地址。正確設計：threshold 必須是 2（需要操作地址 + 守護者地址共同簽名）。
錯誤三：沒有測試過 Safe 的多簽確認流程。部署前沒有從 Safe UI 手動測試過一次完整的多簽流程（操作地址提議交易 → 守護者地址在 Safe App 上確認 → 執行）。結果在緊急情況下（需要把資金轉移到安全地址），操作者不知道怎麼用 Safe UI，手忙腳亂增加了損失風險。正確設計：在測試網上完整跑一遍，確認你能在 5 分鐘內完成一次完整的 Safe 交易。
錯誤四：Safe 裡的資金太少，起不到真正的保護作用。有些開發者設置了 Safe 多簽，但 80% 的資金仍然在操作地址裡（「先放一點在 Safe 裡試試」）。正確設計：除了 Gas ETH，所有需要 Agent 管理的資金都在 Safe 裡。
API Key 的「最小權限原則」在 Onchain Agent 裡具體怎麼落實？哪些 Key 是高風險的？
最小權限原則（Principle of Least Privilege）是：每個 API Key 只開放它實際需要的最小權限，即使洩漏了，攻擊者能做的事情也有界。在 Onchain Agent 場景的具體落實：
Alchemy/Infura RPC Key 的分層設計：讀取 Key（只讀，查詢鏈上狀態、APY、Gas 費）和廣播 Key（有廣播交易的權限）分開。Agent 的工具函數裡，讀取工具用讀取 Key，寫入工具用廣播 Key。如果讀取 Key 洩漏（例如被 Prompt Injection 提取），攻擊者只能查詢鏈上數據，不能廣播交易。Alchemy 支持在控制台裡設置「Allowed RPC methods」（只允許特定的 RPC 方法），充分利用這個功能。
最高風險的 Key（洩漏後損失最大）：你的 Agent 操作私鑰（EOA 私鑰，廣播交易的根源）；LLM API Key（洩漏後攻擊者可以用你的 Key 無限調用 API，費用爆炸）。
中等風險的 Key：DeFi 協議 API Key（洩漏後攻擊者只能讀取數據，不能操作資金）；Gas Oracle API Key（洩漏後服務可能被中斷，但不影響資金）。
定期輪換的建議：操作私鑰：只有在懷疑洩漏時才換（換地址意味著需要重設所有 Safe 配置）；LLM API Key：每 3 個月輪換；RPC Key：每 3 個月輪換；DeFi 協議 API Key：每 6 個月輪換。輪換後立即更新 Railway/AWS 等部署平台的環境變數。
模擬應急演練要怎麼做才有效？演練的時候應該重現什麼場景？
模擬應急演練的目標不是「測試系統」，而是「訓練操作者的肌肉記憶」——讓你在真正的緊急情況下不需要思考，按照既定流程操作。設計有效演練的原則：
演練場景設計（選一個，每月輪換）：場景 A（私鑰洩漏）：假設「你的 Agent 私鑰此刻剛被洩漏。你有 30 分鐘，行動是什麼？」——按時計時，完成：停止 Agent 進程、撤銷所有 ERC-20 授權（Revoke.cash）、評估損失、通知守護者地址持有者。場景 B（異常操作發現）：假設「你的 Telegram 收到了非白名單地址的 P0 告警，打開日誌發現 Agent 在過去 10 分鐘試圖向 0xUnknown 發起 3 次轉帳。你的行動是什麼？」場景 C（API 全部崩潰）：假設「所有外部 API 同時崩潰，Agent 的熔斷觸發了。你確認問題原因後，怎麼安全地讓 Agent 恢復？」
演練的有效性標準：每個場景的每個步驟都能在預期時間內完成（例如：撤銷所有 ERC-20 授權在 5 分鐘以內）；不需要查找任何文檔或密碼（所有需要的工具和地址都預先準備好）；守護者地址持有者（如果是別人）在演練中也參與，確認他們知道自己的職責。
演練後做什麼：記錄「演練中發現的流程問題」（哪個步驟花了比預期多的時間、哪個步驟不確定怎麼操作），作為下次更新應急文檔的輸入。不記錄 = 演練的學習效果無法固化。
把 Onchain Agent 從測試網部署到生產環境是一個不可逆的時刻——一旦 Agent 開始操作真實資金，任何安全設計的缺漏都可能在你意識到之前就造成損失。
這篇文章提供一個完整的生產部署安全 Checklist，分為五個類別：代碼安全、錢包和私鑰安全、工具和 API 安全、Agent 推理安全、運行時監控和應急響應。這個 Checklist 不是「最佳實踐推薦」，而是「缺少任何一項都有安全風險」的最低基準。在你的 Agent 進入生產部署之前，每一項都應該被明確確認。
代碼安全是所有安全設計的基礎——如果代碼層面有問題，其他安全設計可能都失效。
代碼安全 Checklist（8 項）：
1. .env 文件已加入 .gitignore——在整個 Git 歷史裡搜索私鑰和 API Key 的格式，確認沒有私鑰洩漏。如果已上傳過 .env 到 GitHub，即使刪除了文件，舊的 commit 仍然可被查到——需要立即輪換所有相關的私鑰和 API Key。
2. 所有敏感憑證通過環境變數讀取——代碼裡確認沒有任何地址或私鑰被硬編碼；確認沒有 API Key 硬編碼。
3. 依賴庫安全性確認——pip audit（Python）或 npm audit（Node.js）確認沒有已知漏洞的依賴庫。特別注意 Web3 相關庫的版本（web3.py、ethers.js），這些庫的舊版本有時有已知的安全問題。
4. 所有寫入工具函數有單元測試——每個能觸發鏈上操作的工具函數必須有測試，覆蓋「正常執行」和「邊界條件」（金額超限、地址不在白名單、Gas 費超預算）的行為。
5. 工具函數的錯誤處理不洩露敏感信息——當工具函數拋出異常時，error message 不包含私鑰片段、API Key、或系統路徑。如果使用第三方日誌服務，確認敏感信息已被屏蔽。
6. 所有工具調用有超時設置——外部 API 調用（DeFi 協議 API、Gas Oracle）設置了明確的超時（例如 10-30 秒），防止 Agent 因為 API 無響應而無限等待。
7. 代碼通過 linter 和靜態分析——Python 使用 flake8 或 pylint；使用 bandit（Python 安全掃描工具）確認沒有常見的安全問題。
8. 部署配置文件已審查——確認生產環境沒有啟用 debug 模式、沒有暴露不必要的端口、容器不以 root 權限運行。
錢包設計決定了「即使代碼出問題，損失的上限是多少」。
錢包安全 Checklist（8 項）：
9. 操作錢包和資金錢包完全分離——操作錢包（Agent 使用的 EOA 地址）只持有少量 ETH 用於 Gas（建議不超過 $50 的 ETH），不持有任何 USDC 或其他資金。主要資金在 Safe 多簽地址裡。
10. Safe 多簽已正確配置——Safe 的 threshold 設置為 2-of-N（至少需要 2 個地址共同簽名）；操作地址是 Safe 的一個 Signer；守護者地址（Guardian）是一個完全離線、不在 Agent 代碼裡的冷錢包地址；測試過從 Safe UI 手動觸發一次交易。
11. 私鑰存儲方式符合生產安全標準——不接受：私鑰直接寫在代碼裡或純文本 .env 文件；開發者個人電腦上的 .env 文件。接受：Railway/Heroku 等平台的加密環境變數；AWS Secrets Manager 或 HashiCorp Vault。
12. ERC-20 授權已設置合理上限——不使用無限授權；每個協議的授權金額不超過計劃操作的最大金額 × 1.5；定期在 Revoke.cash 上審查和撤銷不再需要的授權。
13. 操作錢包的 Gas 補充機制已設計——Gas 低於閾值時的自動補充邏輯；設置補充金額上限，防止補充邏輯 Bug 導致無限補充。
14. 守護者地址的私鑰存儲和管理——守護者地址的私鑰存儲在物理上安全的硬件錢包（Ledger/Trezor）裡；有備份助記詞；測試過從守護者地址手動簽署一筆 Safe 交易。
15. 所有測試網操作已在測試網完成——在切換到主網之前，在 Sepolia 或 Base Sepolia 上完整跑過所有功能（包含熔斷、告警、Safe 多簽流程）。
16. 初始生產部署時資金量有上限——建議：生產環境的前兩週，操作資金量設置為計劃最終量的 10-20%，確認 Agent 在真實市場環境下的行為符合預期後再提高。
工具層是 Agent 和外部世界的邊界，也是 Prompt Injection 最常見的攻擊入口。
工具安全 Checklist（7 項）：
17. 讀取工具和寫入工具已明確分離——讀取工具和寫入工具在工具列表裡有明確的命名約定；在 LangGraph 圖層面，從讀取節點到寫入節點的路徑必須經過驗證節點。
18. 所有寫入工具有後端二次驗證——每個寫入工具在執行前做：目標地址白名單檢查、操作金額上限檢查、操作類型許可檢查。這三個檢查在代碼層面硬性執行，不依賴 LLM 的遵從。
19. 工具白名單已鎖定——Agent 的 System Prompt 裡只列出白名單工具；在後端代碼裡，當 LLM 嘗試調用白名單之外的工具時，直接返回錯誤。
20. 工具回傳數據有合理性過濾——每個工具函數對回傳數值做範圍驗證：穩定幣 APY 超過 30% 為異常；異常值不進入 LLM Context，改用上次緩存的有效值。
21. 外部 API 有 Fallback 機制——每個關鍵外部 API 有備用數據源；主 API 失敗時自動切換；備用源也失敗時觸發熔斷。
22. MCP 工具的來源已驗證（如果使用）——只使用來自可信來源的 MCP Server（官方發布的或自建的）；不使用未經審查的第三方 MCP Server。
23. API Key 的權限已最小化——Alchemy/Infura 等 RPC 服務的 API Key 只開放必要的 API 方法；定期輪換 API Key（建議每 3 個月）。
推理安全確保 LLM 的行為在設計的邊界裡。
推理安全 Checklist（6 項）：
24. System Prompt 包含完整的接地規則——明確規定：所有引用的具體數值必須來自工具回傳，不得使用訓練記憶裡的數字；工具調用失敗時，必須在 Thought 步驟聲明數據缺失並中止本輪。
25. System Prompt 包含策略邊界聲明——明確列出 Agent 只能操作的協議（白名單）、代幣種類、每次操作的最大金額、不允許任何白名單外的操作。
26. 後端數值一致性驗證已實作——在每次 LLM 輸出後、工具執行前，自動解析 Thought 裡引用的數值，對比工具日誌裡的實際回傳；差異超過 5% 觸發 P1 告警，超過 30% 觸發 P0 告警和操作阻止。
27. 最大循環次數已設置——單個任務的最大 Thought-Action 循環次數設置了硬上限（建議 10-20 次）；超過上限自動終止任務並告警。
28. Context 使用率監控已啟用——每次推理前計算當前 Context 的 Token 使用量；超過 70% 觸發 Context 壓縮（或告警）；超過 90% 強制終止本輪任務。
29. 人工確認機制已測試——Telegram Bot 確認流程已端到端測試；確認的超時設置已測試（用戶不回覆時 Agent 取消操作，而不是默認執行）。
應急響應不是「出問題了才開始想」，而是「出問題之前就設計好、演練過」。
應急響應 Checklist（6 項）：
30. 緊急停止機制已設計和測試——有一個「立即停止 Agent 所有操作」的機制（例如向特定的 Telegram 命令、設置環境變數 EMERGENCY_STOP=true）；緊急停止可以在 30 秒內完成；已在測試網上演練過一次。
31. ERC-20 授權撤銷流程已準備——知道如何在 Revoke.cash 上快速撤銷操作地址對所有協議的 ERC-20 授權；在緊急情況下，撤銷授權是防止進一步損失的最快方法之一。
32. 事後日誌審查流程已定義——知道「出了問題後，第一步看哪個日誌（Thought Log？工具日誌？Validation Log？）」；有一個事件時間線記錄模板。
33. 守護者地址的持有者知道自己的責任——如果守護者地址由另一個人持有，他們知道在什麼情況下需要拒絕簽署 Safe 交易；如何聯繫你（主要 Agent 操作者）確認是否需要簽署。
34. 有書面的應急聯繫和操作清單——以「最壞情況下你沒有電腦，只有手機」為假設，準備一份書面（或加密存儲）的應急操作指南。
35. 每月做一次模擬應急演練——每個月選一個 15-30 分鐘的時間，模擬一個應急場景（例如「假設你的 Agent 私鑰剛被洩漏，接下來 30 分鐘你的行動步驟是什麼？」），確認每個步驟都能順利執行。
這個 Checklist 的 35 項不是「做到越多越好」的加分項，而是「任何一項缺失都有具體的安全風險」的最低基準。在進入生產部署之前，每一項都應該有一個明確的「已完成」或「有意識地跳過，理解了對應的風險」的回答。
最常被跳過的三項（和原因）：Safe 多簽（「太麻煩了，等資金量大了再說」——資金量小的時候被攻擊，損失雖然小但可能讓你永遠不想再做 Agent）；模擬應急演練（「等真正出問題了再處理」——真正出問題時，在恐慌狀態下想出的應急方案通常比提前設計的更差）；書面應急操作指南（「都在腦子裡」——危機時刻最需要的就是一份你不需要思考就能執行的清單）。這三項雖然不是技術上最複雜的，但在真實的應急場景下，它們往往是決定「損失可控」和「損失失控」的差異。