清單第 7 項「寫入工具後端參數驗證」在程式碼裡具體怎麼實作？有沒有範例？
後端參數驗證的核心是：在你的後端程式碼裡，在真正執行寫入工具之前，加入一個驗證函數，確認 LLM 傳來的參數符合你的安全規則。
以 Python 為例，對一個「執行 DEX 交易」的寫入工具，驗證邏輯應該包含：金額上限檢查（如果 amount > MAX_SINGLE_TRADE_AMOUNT: raise SecurityError）、地址白名單檢查（如果 target_address not in WHITELIST_ADDRESSES: raise SecurityError）、滑點範圍檢查（如果 slippage > MAX_SLIPPAGE_PERCENT: raise SecurityError）、以及代幣白名單（如果 token not in ALLOWED_TOKENS: raise SecurityError）。
這個驗證函數放在工具調用鏈的後端層，不在 LangChain 的 @tool 裝飾器裡（那一層是 LLM 能看到的）。即使 Prompt Injection 攻擊讓 LLM 輸出了一個超出安全規則的工具調用請求，後端的驗證函數會在真正執行前攔截它，並拋出異常，不繼續執行。
一個容易犯的錯誤：把驗證邏輯寫在 System Prompt 裡（「你不能執行超過 $100 的交易」）。這是無效的安全設計——System Prompt 可以被 Prompt Injection 覆蓋，只有在程式碼層面強制執行的驗證才是可靠的。
清單第 9 項「高金額操作獨立確認通道」怎麼在生產環境裡設計？Telegram 通知是個好選擇嗎？
Telegram 通知是目前最常用且實際上相當可靠的獨立確認通道方案之一。設計流程如下：
Agent 在後端判斷操作金額超過閾值後，不直接執行，而是把操作請求暫時存在一個「待確認隊列」裡，同時通過 Telegram Bot 向你的個人帳號發送通知，包含：操作類型、金額、目標地址/協議、Agent 的推理理由（用 Thought 步驟的摘要）。你的 Telegram 通知裡有兩個按鈕：「確認執行」和「拒絕並通知 Agent」。只有當你點擊「確認執行」後，後端才真正執行這個操作。
Telegram 方案的安全邊界：Telegram 帳號本身的安全性很重要——確保你的 Telegram 帳號開啟了雙因素驗證，且通知只發到你的個人帳號，不是一個群組（群組成員都能看到操作詳情）。
更高安全等級的替代方案：如果你管理的資金量較大，可以考慮用硬體安全金鑰（YubiKey）的 TOTP 確認，或者通過帶 MFA 的 AWS 管理後台做確認。這些方案成本更高但安全性也更強。
關鍵設計原則：確認通道必須和 Agent 的推理流程完全獨立——如果確認邏輯是「Agent 問自己該不該做」，這不是獨立確認通道，只是多了一個 Thought 步驟。真正的獨立確認是在 Agent 的控制流程之外，由人類做最終決定。
如果我的 Agent 是多 Agent 架構（Orchestrator + Sub-agent），安全檢查清單有哪些額外的考量？
多 Agent 架構的安全設計比單一 Agent 複雜，因為引入了「信任傳播」的問題——如果 Orchestrator 信任 Sub-agent 的回傳，一個被污染的 Sub-agent 可以把惡意指令傳給 Orchestrator。幾個額外的安全考量：
第一，每個 Sub-agent 應該只持有最小必要授權。Sub-agent 的角色是「分析和建議」，不應該持有鏈上簽署授權——所有的鏈上操作應該由 Orchestrator 通過獨立確認後執行。這讓即使某個 Sub-agent 被 Prompt Injection，攻擊者也無法直接觸發資金轉移。
第二，Orchestrator 對 Sub-agent 的回傳也需要做 Schema 驗證。Sub-agent 的回傳不應該直接進入 Orchestrator 的 LLM Context 而不經過任何驗證——同樣的 Schema 驗證邏輯（確認格式符合預期、沒有奇怪的長文字欄位）應該應用在 Agent 間的通訊上。
第三，多 Agent 系統的日誌應該能追蹤「決策鏈」。一個操作的最終執行，應該能從日誌裡追溯到：哪個 Sub-agent 提供了哪個分析 → Orchestrator 基於哪些 Sub-agent 的輸出做了決策 → 決策通過了哪些確認層 → 最終鏈上執行的詳情。這個追蹤能力在事後審計裡非常重要。
第四，在上線前，設計一個「紅隊測試」——手動嘗試用一個惡意的 Sub-agent 回傳（格式正確但包含惡意指令）來攻擊 Orchestrator，確認你的 Schema 驗證層和讀寫隔離能夠攔截這類攻擊。
安全審計（Security Audit）對加密 Agent 來說是必要的嗎？一個獨立開發者負擔得起嗎？
這個問題取決於你的 Agent 管理的資金規模和商業模式：
如果你是為自己的個人資金開發 Agent：安全審計不是必要的，但你應該完成這份清單裡的所有 12 個項目。清單本身覆蓋了大多數常見的安全漏洞，且是你自己可以驗證的。對個人資金的 Agent，關鍵是「自己理解自己系統的安全設計」，不是找人幫你背書。
如果你的 Agent 管理其他用戶的資金：安全審計幾乎是必要的，不只是為了安全，也是為了用戶信任。主要的安全審計公司費用通常在 $15,000-$100,000 美元，取決於代碼複雜度和審計深度。對早期獨立開發者，有幾個更可負擔的替代方案：Sherlock 的「競爭性審計」（讓白帽黑客競爭找漏洞，費用相對更低）；Code4rena 的 public audit；或者社群的 Peer Review（找幾個有安全背景的開發者互相 review 代碼）。
費用效益分析：如果你的 Agent 管理 $100,000 的用戶資金，$20,000 的安全審計費用只是資管量的 20%，是完全合理的支出。如果你的 Agent 才剛上線且管理 $5,000，$20,000 的審計費用在商業上不合理——先用這份清單覆蓋基本安全，等規模增長後再進行正式審計。
中間方案：在正式審計前，至少讓 2-3 個有安全背景的開發者（不是你自己的隊友）完整 review 你的安全設計，特別是工具調用的驗證邏輯和密鑰管理部分。
一個加密 AI Agent 在主網上線前，有一份不能省略的安全檢查清單。這不是「最佳實踐建議」，而是「如果沒做這些，你的 Agent 不應該接觸真實資金」的底線要求。這篇文章把 12 個必做項目分成四個類別，逐一說明為什麼要做、怎麼驗證它已經被正確實施。
很多開發者的心態是「先上線，等出問題再修」——這在普通 Web 應用裡可以接受，在加密 Agent 裡卻是致命的。原因很簡單：鏈上交易不可逆。一旦資金被轉走，沒有「復原」按鈕。一次安全事故的損失可能遠超整個開發週期的成本。
更重要的是：加密 Agent 的攻擊者是有動機的、有技術能力的，且會在你上線的第一天就開始掃描漏洞。「我們先上線，等有人發現再修」這個策略，給了攻擊者時間窗口。預防性的安全設計成本遠低於事後的損失補救。
清單項目 1：私鑰不存在任何明文位置。檢查所有環境變數、配置文件、代碼倉庫歷史記錄（包括 Git 歷史）——確認沒有任何私鑰、助記詞、或等效的簽署憑證以明文形式存在。使用 git log with grep for private/mnemonic/seed keywords 掃描代碼歷史。已有明文私鑰進入 Git 歷史的，即使後來刪除了，那個倉庫應該被視為已洩漏，需要完整輪換所有密鑰。
清單項目 2：Agent 錢包和主資產錢包完全隔離。Agent 的操作錢包只存放幾天的運作資金，不能和你的主要資產共用同一個錢包。驗證方法：兩個錢包地址完全不同，且操作錢包的資金上限有明確的定期補充機制（例如：操作錢包餘額低於 $X 時，需要從主錢包手動補充，不能自動轉帳）。
清單項目 3：ERC-20 授權設有精確上限。Agent 對每個代幣和每個協議的 approve 都有明確的最大金額，不是「無限授權（type(uint256).max）」。驗證方法：對每個你給 Agent 授權的代幣合約，查詢當前的 allowance，確認是有限值而不是最大值。定期審查並撤銷不再使用的授權。
清單項目 4：Agent 的 System Prompt 不包含任何憑證。LLM 的 System Prompt 可能被 Prompt Injection 攻擊讀取。確認 System Prompt 裡沒有 API Key、私鑰、助記詞、或任何可以用來訪問敏感系統的憑證。
清單項目 5：私鑰存儲使用安全方案。生產環境使用 AWS Secrets Manager、HashiCorp Vault、或 AWS Nitro Enclaves，不是系統環境變數或 `.env` 文件。驗證方法：在部署環境裡搜索 `.env` 文件，確認沒有包含真實私鑰。
清單項目 6：所有讀寫工具嚴格分類。整理所有工具，明確標記哪些是只讀（查詢數據）、哪些是寫入（執行鏈上操作）。確認寫入工具不會在讀取了未驗證的外部數據後被直接調用——在讀取外部數據和觸發寫入工具之間，必須有一個人工確認或參數驗證的環節。
清單項目 7：所有寫入工具有後端參數驗證。不能只依賴 LLM 的推理輸出來決定是否執行寫入操作。在後端程式碼裡，對每個寫入工具的調用做參數驗證：金額是否在設定上限內、目標地址是否在白名單裡、操作類型是否被允許。這個驗證邏輯在 LLM 無法繞過的後端層執行。
清單項目 8：工具回傳數據有 Schema 驗證。所有工具（特別是 MCP Server 或外部 API）的回傳數據，在進入 LLM Context 之前，需要在後端驗證格式是否符合預期 Schema，數值是否在合理範圍內。異常回傳（格式不符、數值異常）應該被截斷並觸發警報，不送進 LLM。
清單項目 9：高金額操作有獨立確認通道。超過你設定閾值（例如 $100）的任何寫入操作，在後端執行前必須通過一個和 LLM 推理層完全獨立的確認通道（例如發送 Telegram 通知給你，等待你回覆確認）。這一層不能被 Prompt Injection 繞過，因為它在 Agent 的推理流程之外。
清單項目 10：每日支出上限熔斷機制。設定 Agent 每日可以觸發的最大總支出（包含 Gas 費、A2A 支付費、轉帳金額）。超過這個上限，所有後續的寫入操作自動暫停並通知你，直到你手動重置。這個熔斷機制在後端程式碼層面執行，不能被 Agent 的推理覆蓋。
清單項目 11：市場異常熔斷機制。設定一組市場條件觸發的熔斷閾值：資產在 15 分鐘內跌幅超過 X%、Gas 費超過正常值的 X 倍、DEX 的滑點超過 X% 等。任何一個觸發，所有寫入操作自動暫停，發送緊急通知，等待人工恢復。
清單項目 12：完整的操作日誌體系。包含四個層次：LLM 推理日誌（Thought 步驟的完整輸出）、工具調用日誌（調用什麼、輸入什麼、回傳什麼）、決策授權日誌（哪些操作被執行、哪些被攔截）、鏈上執行日誌（交易 hash、Gas 費、成交價格）。日誌要加密存儲，且保留期至少 90 天。
完成以上 12 個項目的設計和實作後，按照以下節奏驗證：第一週，在測試網（Sepolia 或 Base Sepolia）跑完整的功能測試，包括主動觸發所有熔斷機制（測試它們是否真的生效）、嘗試用異常的工具回傳數據觸發 Schema 驗證（測試驗證層是否攔截）。第二週，用小額真實資金（$20-$100）在主網做行為驗證，確認測試網和主網行為一致。第三週起，逐步擴大授權金額，每次擴大後觀察至少一週的正常行為再繼續。
任何時候，只要你不確定某個邊界情況下 Agent 會怎麼做，就先回到測試網驗證。主網的「不確定性成本」是測試網的無數倍。
這 12 個項目不是可選的清單，而是「你的 Agent 不應該管理你不能接受損失的資金」之前的最低要求。如果你在時間壓力下想跳過某幾項，問自己這個問題：「如果攻擊者在上線的第一天就發現並利用了這個漏洞，最壞的損失是多少？」如果這個數字超過你可以接受的範圍，那個項目就不是可以跳過的。