如果一個 Agent 的回測報告顯示勝率很高，實盤表現卻差很多，最可能是哪一段出問題？
最常見的落差來自感知與決策階段的延遲在回測環境裡被隱藏了。回測通常用歷史數據跑模擬，數據本身沒有「延遲」的問題——你拿到的每一筆歷史價格都是完整、即時可用的。但實盤環境裡，數據來源的延遲、網路壅塞、計算耗時都是真實存在的變數，這些變數在回測階段完全不會出現，導致回測勝率系統性地高估了實際表現。
判斷方式是去看這個 Agent 是否有做過「考慮延遲的模擬回測」（例如故意在回測數據裡加入隨機延遲，模擬真實網路環境），如果開發文件完全沒有提到這一層，這個落差通常會比預期更明顯。
Gas 費用估算過低導致交易卡在 mempool，跟前面提到的三明治攻擊有沒有關係？
有一定關係，但屬於不同的風險來源。三明治攻擊是攻擊者主動利用 mempool 的透明性，針對你的交易插隊獲利；而 Gas 估算過低導致交易卡住，通常是被動性的執行失效——交易本身沒有被針對，只是因為出價太低，在網路壅塞時排不進區塊。但這兩者確實會互相放大：一筆卡在 mempool 裡遲遲未確認的大額交易，本身就是更容易被三明治攻擊鎖定的目標，因為它給了攻擊者更長的觀察與計算時間。
這也是為什麼私有交易池同時能緩解兩種問題——避免交易長時間曝光在公開 mempool，既降低被搶跑鎖定的機率，也能透過跟區塊打包者直接協商，改善單純出價不夠高導致卡單的狀況。
決策階段的計算如果太複雜，是不是乾脆簡化策略邏輯就能解決延遲問題？
簡化邏輯確實能縮短計算時間，但這是用「策略品質」去換「執行速度」，不是免費的解法。過度簡化的決策邏輯可能在市場正常波動時反應夠快，但遇到複雜的多變數情境（例如同時要評估多條鏈的價差、還要納入 Gas 成本比較）時，判斷品質可能明顯下降，導致執行雖然快，但決策本身不夠精準，一樣會虧損，只是虧損原因換了一種。
比較實際的做法不是單純簡化邏輯，而是針對計算流程做工程優化——例如把不需要即時運算的部分預先計算好、只在真正需要即時反應的環節保留複雜運算，或是把運算能力本身升級（更快的硬體、更貼近節點的伺服器位置）。延遲問題的解法通常在工程層面，而不是犧牲策略深度。
身為普通用戶，我根本看不到 Agent 內部的執行速度，該怎麼間接判斷這個環節有沒有問題？
不需要理解程式碼細節，但可以觀察幾個間接指標：這個產品是否公開過「實盤與回測的落差數據」（願意誠實揭露落差的產品，通常代表團隊有認真面對執行延遲這個問題）；查看歷史交易紀錄裡，是否有頻繁出現「已確認但滑點明顯超出預期」的交易（這通常是執行延遲的具體證據）；以及觀察 Agent 在市場劇烈波動期間的表現是否明顯惡化（延遲問題通常在市場快速變動時最容易暴露）。
這些觀察不需要技術背景，只需要願意花時間去看歷史數據，而不是只相信行銷頁面上的平均報酬率數字。
當一個 DeFAI Agent 的策略邏輯本身沒有問題，卻仍然頻繁虧損，問題往往不在「該不該做這筆交易」的判斷上，而是藏在 執行循環 三個階段之間的延遲裡。這篇文章拆解感知、決策、執行各自可能卡住的地方，幫助你判斷一個 Agent 表現不佳，究竟是策略設計的問題，還是執行機制本身出了狀況。
Agent 做出任何判斷之前，第一步是讀取鏈上狀態與市場數據。這一步看似單純，實際上充滿延遲陷阱：如果 Agent 依賴的價格來源是透過中心化 API 拉取，而不是直接讀鏈，中間可能存在數秒的滯後；如果 Agent 監聽的是 mempool 裡的待確認交易來預判價格走勢，網路壅塞時 mempool 本身的傳播速度也會變慢，Agent 看到的「即時狀態」實際上已經落後於鏈上正在發生的事。感知階段的延遲不會讓 Agent 當機或報錯，它只會讓 Agent 用一份看起來正常、實際上過時的數據去做判斷——這是最難被察覺的一類失靈，因為系統表面上運作正常。
就算感知階段的數據夠新鮮，決策邏輯本身如果計算量太大，也可能拖慢整個循環的節奏。越複雜的策略（例如同時比較多個候選路徑、跑機率模型評估期望報酬），計算所需的時間也越長，如果這個計算時間超過市場波動的速度，等 Agent 算出「現在應該執行」的結論時，那個機會視窗可能已經關閉。決策階段的延遲往往是策略設計時被低估的成本——開發者容易只關注「這個邏輯是否正確」，卻沒有同步評估「這個邏輯算出結果需要多久」。
即使感知與決策都又快又準，交易送出後仍然要面對區塊鏈本身的不確定性：Gas 費用估算過低，交易可能長時間卡在 mempool 沒被打包；同一個區塊裡如果有其他交易搶先執行改變了鏈上狀態，原本計算好的滑點與價格可能已經不成立，導致交易失敗或以更差的條件成交。這也是為什麼許多正式產品開始採用私有交易池——不是為了投機取巧，而是為了降低「判斷正確但執行環節失守」這種結構性風險。
實務上這三段延遲往往同時發生、彼此放大：感知階段慢了幾百毫秒，決策階段又花時間跑複雜運算，等交易終於送出，可能已經比理想時機晚了好幾個區塊。評估一個 DeFAI 產品的執行機制時，不能只看「策略邏輯聰不聰明」，更要看這三段的實際延遲總和有沒有被認真優化過，以及產品方是否公開過相關的效能數據。
如果你在使用或評估一個 DeFAI 產品，光看策略邏輯的說明文件不足以判斷實際表現，值得追問的問題包括：這個 Agent 的資料來源是直接讀鏈還是透過第三方 API、決策計算平均需要多長時間、以及交易送出後是走公開 mempool 還是私有交易池。這三個答案能幫你判斷，這個產品的執行機制是不是真的能在市場實際的速度下運作，而不只是在理想條件下的回測報告裡表現良好。