大家好，我是肆〇柒。我看到一篇由香港科技大學（廣州）的研究團隊發表的論文《GasAgent: A Multi-Agent Framework for Automated Gas Optimization in Smart Contracts》。文中介紹了一種創新的多智能體框架，通過Seeker、Innovator、Executor和Manager四個專門化智能體的閉環協作，系統性地解決了智能合約Gas優化中的"不可能三角"問題，即同時滿足兼容現有知識、發現新穎模式和確保安全有效三大需求。該研究對區塊鏈開發者和智能合約安全領域具有重要參考價值與現實意義。所以，有好奇心的你，如果有興趣，下面我們一起來了解一下。

Gas優化的"不可能三角"

在以太坊等區塊鏈平臺上，智能合約的執行需要消耗Gas，這是衡量計算和存儲資源消耗的單位。Gas費用直接關系到用戶交易成本和網絡效率，然而由于開發者對Gas定價模型的不熟悉和非最優編碼實踐，大量已部署的智能合約存在Gas浪費問題。據研究顯示，許多合約包含冗余邏輯，導致Gas消耗遠超必要水平，這增加了用戶成本，還浪費了寶貴的網絡資源。當前的Gas優化方案主要面臨三大困境：

• 手動審計方法：依賴專家經驗發現Gas浪費模式，效率低下且難以規模化。在DeFi等快速發展的領域，手動審計往往跟不上合約迭代速度。
• 基于規則的工具：如GasSaver、GasChecker等，通過預定義模式庫進行檢測，但覆蓋范圍有限，難以適應新的合約結構和編碼風格。
• 單LLM方法：最新研究嘗試使用大型語言模型(LLM)探索新的Gas浪費模式，但這種方法常常產生幻覺(hallucinations，指LLM生成看似合理但實際上錯誤或不存在的信息)和冗余模式，且需要人工驗證和重寫。

這些方法各自只能解決部分問題，卻無法同時滿足三個關鍵需求：兼容現有知識（確保所有已知模式被可靠識別）、發現新穎模式（適應不斷演變的合約結構）和確保安全有效（驗證優化確實有效且不引入新問題）。這三個需求形成了一個"不可能三角"——傳統方法難以兼顧。

為更清晰地理解GasAgent的定位與創新價值，下面系統性地對比了現有Gas優化技術：

GasAgent的突破性創新在于其多智能體架構設計，通過四個專門化智能體的閉環協作，系統性地解決了這一三角難題。GasAgent是首個結合現有模式兼容性和新模式自動發現/驗證的多智能體系統，實現了端-to-end優化（指從原始合約代碼到優化后合約的完整自動化流程，無需人工干預）。這種設計提高了優化效率，確保了結果的可靠性和安全性，為智能合約開發提供了全新的自動化范式。

核心架構：四智能體的精密協作閉環

GasAgent的核心在于其精心設計的四智能體協作架構，每個智能體承擔特定角色，共同形成一個閉環優化工作流。這種模塊化設計借鑒了經驗豐富的合約開發者的工作方式：識別高成本代碼片段、推理其影響，并迭代測試優化方案。

Seeker (探查者) - 確保知識完備性

核心挑戰：預訓練LLM的知識固化問題。LLM的訓練數據截止于特定時間點，無法包含此后發現的Gas浪費模式。研究顯示，即使對訓練數據中存在的模式，預訓練LLM也可能無法完全回憶。雖然微調是一種解決方案，但它需要高質量數據和大量計算資源，且目前缺乏公開的Gas優化數據集。

解決方案："雙檢索機制"（自然語言+代碼）的精妙設計。Seeker通過兩種互補策略從Gas浪費模式庫中檢索相關模式：

1. 代碼檢索：將輸入合約和模式庫中的代碼示例編碼為向量，使用余弦相似度計算代碼相似性。當相似度超過預定義閾值（實驗中設為0.7）時，選擇該模式。

2. 自然語言檢索：生成包含合約源代碼和所有已知模式自然語言描述的提示，發送給LLM，LLM返回基于語義理解匹配的模式ID列表。這兩種檢索結果被合并，形成現有模式報告，為后續優化提供基礎。Seeker的工作流程如圖2所示，它將外部模式庫作為"外部記憶"，確保所有已知模式被可靠召回。

Seeker工作流程圖

為何"雙檢索"比單一檢索更魯棒？代碼檢索能精確匹配結構相似的代碼片段，而自然語言檢索能捕捉語義相似但結構不同的模式。實驗表明，Seeker在100個真實合約上成功檢索到515個已知模式實例中的557個，召回率達到92.5%。同時，通過設置適當的檢索閾值，Seeker將工具調用次數從2,400次減少到1,722次，降低了28.2%的計算開銷，實現了高覆蓋率與高效率的平衡。

Seeker的提示工程設計：Seeker在自然語言檢索中的系統提示和用戶提示經過精心設計，確保LLM能夠準確匹配模式：

### Seeker Prompt in Natural Language-based Retrieval

**System Prompt:**
You are a smart contract analysis expert. Please analyze the given contract code and select relevant patterns from the provided optimization pattern list (no limit on quantity) to optimize the Gas Fee. Only return pattern IDs, separated by commas, e.g., repeated_computation, state_variable_refactoring.

**User Prompt:**
Please analyze the following smart contract and select the patterns that need optimization:
[Contract Source Code Here]

Below are the provided optimization patterns:
[Pattern Descriptions Here]

Please only return pattern IDs, separated by commas.

Seeker的工作流程：在完成模式檢索后，Seeker會"調用相應的Python工具將檢索到的模式應用到原始代碼上并進行細粒度分析"。這些工具是由四位計算機科學博士生實現的，每個模式都被實現為可重用的Python模塊，能夠自動檢測給定Solidity合約中是否存在相應的低效代碼。工具驗證了應用的模式和提取的結構信息是否準確，然后將結果編譯成結構化的"現有模式報告"，供后續智能體使用。

Innovator (創新者) - 在約束中激發創造力

核心挑戰：LLM生成的"幻覺"與"冗余"。當LLM提出新的Gas浪費模式時，其輸出可能包含不切實際或完全錯誤的建議，盲目信任原始輸出進行后續處理存在風險。

解決方案：以Seeker的輸出為"上下文錨點"的提示工程。Innovator的系統提示明確要求LLM基于當前合約代碼和現有建議總結新的Gas優化模式，同時強調"建議應與現有建議不同，不要重復現有建議"，并要求指定匹配新模式的合約代碼部分。關鍵的Innovator提示示例：

### Innovator Prompt

**System Prompt:** Please try to summarize a new Gas optimization pattern based on the current contract code and existing suggestions, with the main goal of reducing Gas fees.
Note: The suggestion should be different from the existing ones. Do not repeat existing suggestions.
Please specify which parts of the current contract code match the new pattern. The generated patterns must be reasonable; if none are found, it’s okay not to generate any. And if there are multiple patterns, please just generate the most important one.

**User Prompt:** Current contract code:
[Contract Source Code Here]
Existing suggestions:
[Seeker’s Suggestions Here]

與單純讓LLM"自由發揮"的本質區別在于，Innovator將LLM的創造力引導到"可驗證"的狹窄通道中。它利用Seeker已確認的模式作為上下文，使LLM的創新建立在堅實基礎上，避免了無約束生成導致的大量無效探索。每個提出的新模式都會先檢查"新模式黑名單"（之前提出但未驗證的模式列表），確保建議的新穎性。這種設計使Innovator既能探索新模式，又能保持與現有知識的一致性，大幅降低了無效探索成本。

Innovator的黑名單機制：Innovator在生成新模式建議前，會首先檢查"新模式黑名單"（the New Pattern Blacklist），這是一個包含先前提出但未通過驗證的模式列表。這一機制確保了系統不會重復探索已被證明無效的模式，提高了優化效率。

新模式報告的結構：Innovator生成的報告包含四個關鍵要素：提議的模式名稱、描述、相關的代碼片段，以及如何通過該模式降低Gas消耗的解釋。這種結構化的輸出確保了新模式具有可驗證性和可操作性，為Executor的驗證工作提供了清晰的輸入。

Executor (執行者) - 構建堅不可摧的安全防線

核心挑戰：如何自動化驗證一個"模式"是真正有效的？當LLM提出新的Gas浪費模式時，如何確保其改寫不會破壞合約邏輯或引入新安全問題？

解決方案：多維度的"結構化驗證流水線"，包含四個關鍵步驟：

1. 代碼重構：基于Seeker和Innovator的報告對合約進行重寫。

2. 安全審計：使用Slither進行靜態分析，檢測重寫過程中可能引入的漏洞。

3. 一致性檢查：自動生成差異化測試套件，包括單元測試、邊界值測試和模糊測試，確保優化后的合約與原始合約行為等價。測試覆蓋函數范圍、輸入多樣性、隨機模糊、部署初始化、行為等價性和結構容忍度等關鍵方面。

4. Gas成本對比：在Ganache和Hardhat本地測試網絡上交叉驗證Gas成本，確保優化確實降低了Gas消耗。

這個流水線構成了一個"零信任"驗證環境。Executor首先應用Seeker的優化，通過所有驗證后才考慮Innovator的建議。如果任何驗證步驟失敗（安全審計、一致性檢查），重寫的代碼將被丟棄，保留原始合約。只有當新模式通過所有檢查并證明Gas成本嚴格低于第一版優化代碼時，才被視為有效。這種嚴謹的驗證機制確保了只有安全有效的優化才會被保留，構成了整個系統的安全基石。

Executor的兩階段驗證流程：Executor的工作分為兩個明確的階段：

1. 第一階段：應用Seeker的優化建議，生成第一個優化版本，然后進行完整驗證（安全審計、一致性檢查、Gas成本對比）。只有當這個版本通過所有檢查后，才會進入第二階段。

2. 第二階段：在第一個優化版本的基礎上，應用Innovator的新模式建議，生成第二個優化版本。這個版本必須通過與第一階段相同的嚴格驗證，并且Gas成本必須嚴格低于第一優化代碼版本，才能被視為有效。這種兩階段驗證確保了系統只保留真正有效的創新，避免了無效或有害的優化。

Manager (管理者) - 流程控制與決策中樞

核心挑戰：何時停止優化？如何處理迭代？多智能體系統需要一個中央協調器來管理外部交互、監控進度并決定優化循環的終止時機。

解決方案：基于驗證結果的循環終止策略。Manager負責：

• 與用戶或調用系統進行外部交互
• 收集內部智能體的輸出
• 根據Executor的驗證結果決定是否繼續優化循環
• 生成結構化報告，總結各智能體的關鍵行動和決策

Manager的工作機制確保了整個系統不會陷入無限循環。在每次迭代后，它會審查Seeker、Innovator和Executor的結果，包括模式匹配、新建議、驗證結果和測量的Gas節省。如果優化被驗證有效，Manager允許進行新一輪探索；否則，它停止循環并最終確定最后一個驗證過的合約。實驗數據顯示，52%的合約在單輪循環中完成（僅應用Seeker的現有模式），48%需要至少一輪Innovator的新模式發現，最多有四個有效的新模式在某些案例中被發現。Manager確保了整個流程的可控性和透明度，使最終結果對用戶可解釋、可理解。

閉環工作流的循環機制：Manager根據Executor的驗證結果決定是否啟動新一輪優化循環。當Innovator提出的新模式被驗證有效時，Manager會將這些模式納入考慮范圍，啟動新一輪優化。這種循環機制確保了系統能夠持續探索更優的優化方案，直到達到收斂條件。Manager還負責管理各智能體間的精確數據流，確保Seeker→Innovator→Executor→Manager→Seeker的數據傳遞過程順暢，特別是報告格式和內容的一致性。

GasAgent工作流程圖

關鍵技術亮點：模式庫的自進化與閉環價值

GasAgent的真正創新不只是其多智能體架構，還有動態模式庫和閉環工作流設計，這使系統具備了"自學習"和"自進化"的能力。實驗設置：在深入探討技術亮點前，有必要了解評估GasAgent的實驗環境：

• 實現框架：Python + LangGraph（智能體編排）
• LLM配置：GPT-4o-2024-11-20 API
• 檢索參數：jina-v2嵌入模型，閾值0.7
• 編譯環境：solc 0.8.20
• 安全檢查：Slither靜態分析
• Gas測量：Ganache和Hardhat交叉驗證
• 一致性測試：Foundry框架，5參數組合，100次模糊測試
• 模式庫規模：24個經驗證模式（由四位CS博士生實現為Python模塊）

動態模式庫：被Executor驗證為有效的"新模式"會進入"驗證新模式池"，可供選擇性地納入Gas浪費模式庫。這種設計使GasAgent能夠持續進化，不斷擴展其優化能力。與傳統靜態工具不同，GasAgent的模式庫不是一成不變的，而是隨著新合約的優化而不斷豐富。系統在評估100個真實世界合約時自動提出了68個新的Gas浪費模式，其中38個是全新的"原始模式"，30個是對現有模式的細化"子模式"。

模式庫的結構與規模：GasAgent的Gas Waste Pattern Library采用結構化JSON格式組織，每個模式條目包含頂層元數據和詳細示例對象。模式庫的架構包括：

• 頂層字段：name（唯一標識符）、description（Gas浪費場景解釋）、summary（關鍵思想簡述）、tags（快速搜索關鍵詞）、applicableScenarios（適用上下文）和examples（示例列表）
• 每個示例字段：id（示例唯一ID）、title（用例簡短標題）、description（示例說明）、codeBefore（顯示低效實踐的原始Solidity代碼）、codeAfter（推薦改進的優化版本）、codeIssueTags（相關代碼特征標簽）和codeImprovements（具體改進或Gas節省列表）

模式庫實際包含24個從先前研究中明確識別的Gas浪費模式，這些模式由四位計算機科學博士生實現為可重用的Python模塊。每個模塊都能自動檢測給定Solidity合約中是否存在相應的低效代碼。這種結構化的知識庫設計使GasAgent能夠高效地檢索和應用現有優化知識。

閉環工作流：在前文展示的“GasAgent工作流程圖”中，工作流程不僅是信息流的展示，更是一個持續學習和優化的飛輪。每次成功優化都增強了系統本身：

1. Seeker識別已知模式

2. Innovator在已知模式基礎上發現新可能

3. Executor嚴格驗證所有建議

4. Manager決定是否繼續或終止

5. 有效的新模式被納入模式庫，供未來使用

這種閉環設計實現了"經驗積累"——系統越優化越多的合約，其模式庫就越豐富，優化能力就越強。更重要的是，這種自進化能力使GasAgent能夠適應不斷變化的智能合約開發實踐，保持長期有效性。

實證分析：用數據說話

GasAgent在100個真實世界合約上的表現提供了有力證據，證明其多智能體架構的有效性。讓我們深入分析關鍵實驗結果：

Gas優化比例分布

RQ3：消融實驗——證明架構設計的必要性

為了驗證Seeker和Innovator是否對整體Gas優化有實質性貢獻，研究者進行了消融實驗，比較了三種簡化變體：

• Direct LLM：直接提示GPT-4o重構合約，無顯式模式檢索或多智能體編排
• Without Innovator：運行GasAgent但禁用Innovator，覆蓋已知模式但禁用新模式發現
• Without Seeker：運行GasAgent但禁用Seeker，發現新模式但忽略 curated 模式庫

實驗結果：

• Direct LLM僅能優化100個合約中的71個，平均Gas節省5.93%
• Without Innovator覆蓋72個合約，平均節省5.52%
• Without Seeker覆蓋70個合約，平均節省5.74%
• Full GasAgent優化82個合約，平均節省9.97%

消融實驗結果

關鍵發現是，單個智能體剝離后性能甚至不如直接調用LLM。這證明了GasAgent架構設計的整體性和協同效應——Seeker和Innovator被設計為協同工作，當單獨運行時，它們的提示更窄（僅用于工具調用或模式創新），而直接LLM重寫提示更通用，覆蓋更廣的搜索空間。這凸顯了GasAgent的優勢在于將專用模塊組合在循環中，而非孤立使用任一模塊。

RQ4：LLM生成合約的優化效果深度分析

為了評估GasAgent在LLM輔助開發中的適用性，研究者使用五種代表性LLM生成的500個合約進行測試。Table 3提供了詳細的優化結果，揭示了不同LLM在生成合約時的Gas效率差異：

關鍵發現：

1. LLM間差異顯著：Llama-4在基礎合約上達到13.93%的最高平均節省，且100%優化成功(50/50)；而DeepSeek-R1僅達到5.77%的節省，39/50成功。這表明不同LLM生成Solidity代碼時具有不同的結構傾向性——有些產生更符合已知Gas浪費模式的代碼，更容易被優化；而有些則生成更緊湊或非常規的結構，難以與現有模式匹配。

2. 復雜度影響明顯：隨著任務復雜度增加，所有模型的優化效果都下降。例如：

• Qwen3從7.27%降至5.45%，成功率從43/50降至33/50
• Llama-4從13.93%(50/50)降至8.74%，成功率略微降至46/50
• Gemini-2.5下降更為顯著，從9.24%(40/50)降至4.79%，成功率降至36/50

3. 效果下降原因：研究者分析指出，"更復雜的合約涉及更深的嵌套、更動態的控制流或跨函數狀態依賴，降低了基于模式的靜態匹配的有效性"。在這些情況下，部分殘余低效可能隱藏在GasAgent當前檢測管道中，特別是當冗余操作與必須保持不變的功能邏輯糾纏在一起時。這為未來改進指明了方向——通過結合執行軌跡或更深入的語義流分析來提高對復雜合約的覆蓋能力。

LLM生成合約的優化分布

新發現模式的分類分析

在100個真實合約的評估中，Innovator自動提出了68個新的Gas節省模式，經人工分類為：

• 38個原始模式：完全新穎的優化模式，如"Bitmap Role Management"（使用位圖壓縮角色標志存儲）和"Unchecked Fee Calculations"（在可證明安全的邊界內使用unchecked塊跳過溢出檢查）
• 30個子模式：對現有模式的細化，如"Immutable Metadata Fields"（將代幣元數據聲明為immutable而非storage）和"Constant Multiplications"（緩存常用常量以消除重復乘法）

下表展示了這些模式按優化方法的分類分布：

Figure 5: 新發現模式示例

這些模式幾乎涵蓋了智能合約Gas優化的所有關鍵方面：從高級交易流程優化（批處理與整合），到存儲布局改進（映射與結構數據），再到低級優化（位操作、數據打包和算術邊界）。"批處理與整合"和"映射與結構數據"類別的主導地位反映了現實世界合約中Gas密集型操作通常出現在批處理工作流和數據組織中。具體代碼示例分析：

1. Bitmap Role Management模式：

// Bad Example
mapping(address => bool) public isAdmin;
mapping(address => bool) public isMinter;
// Gas-Efficient Example
uint256 constant ADMIN = 1 << 0;
uint256 constant MINTER = 1 << 1;
mapping(address => uint256) private _roles;

該模式通過位操作壓縮存儲結構，使用單個"mapping"存儲與地址關聯的所有角色。與Gas效率低下的實現相比，這種方法將每個地址的存儲占用減少了一個槽位，自動生成功能的數量也減少了一個，從而將部署Gas減少了96,516。此外，通過使用uint256位圖共享單個存儲槽，當單個地址對應多個角色時，執行期間的操作Gas成本也降低了。

2. Immutable Metadata Fields模式：

// Bad Example
uint256 public chainId;
uint256 public launchTimestamp;
// Gas-Efficient Example
uint256 public immutable chainId;
uint256 public immutable launchTimestamp;

該模式將元數據字段聲明為immutable而非storage。由于immutable值在部署時確定并在執行期間只讀，它們避免占用持久化存儲槽，其值被嵌入到運行時字節碼中作為常量。結果是，構造函數不需要執行昂貴的SSTORE操作，顯著降低了部署Gas成本（節省36,084）。此外，運行時訪問immutable變量簡化為低成本的常量push操作（如PUSH32），而訪問常規存儲變量需要SLOAD。因此，對于頻繁訪問的值（如高頻率getter、循環或每筆交易計算），使用immutable可以帶來顯著的Gas節省。

3. Aggregate External Calls模式（原始模式）：

// Bad Example
function transferMultiple(address[] calldata recipients, uint256[] calldata amounts) external {
    for (uint i = 0; i < recipients.length; i++) {
        IERC20(token).transfer(recipients[i], amounts[i]);
    }
}
// Gas-Efficient Example
function transferMultiple(address[] calldata recipients, uint256[] calldata amounts) external {
    for (uint i = 0; i < recipients.length; i++) {
        _safeTransfer(token, recipients[i], amounts[i]);
    }
}
function _safeTransfer(address token, address to, uint256 value) private {
    (bool success, bytes memory data) = token.call(abi.encodeWithSelector(0xa9059cbb, to, value));
    require(success && (data.length == 0 || abi.decode(data, (bool))), "Transfer failed");
}

該模式通過減少外部調用開銷優化Gas。與直接調用IERC20.transfer相比，使用自定義_safeTransfer函數可以避免多次外部調用的固定開銷（約700 gas/次），特別是在處理多個接收者時，能顯著降低Gas成本。4. Unchecked Fee Calculations模式：

// Bad Example
function calculateFee(uint256 amount) public pure returns (uint256) {
    return amount * 10 / 100; // 10% fee
}
// Gas-Efficient Example
function calculateFee(uint256 amount) public pure returns (uint256) {
    unchecked {
        return amount * 10 / 100; // 10% fee
    }
}

該模式在可證明安全的邊界內使用unchecked塊跳過溢出檢查。由于fee計算（amount * 10 / 100）在amount < 2^256/10時不可能溢出，添加unchecked可以消除編譯器自動添加的溢出檢查，顯著降低Gas成本。這對于高頻調用的函數尤其有價值。這些細粒度的變體展示了小的實現細節如何產生Gas節省，這些節省可能被一般性指導所忽略，證明了GasAgent發現的新模式如何補充專家知識。

Gas優化效果分布

兼容性測試的深入分析

為了評估GasAgent是否能夠有效整合現有Gas浪費模式，研究者構建了一個包含24個不同模式的測試庫，這些模式來自六項代表性研究（Unearth、GASaVER、Gasaver、GasMet、Gassaver和DPGOE）。每個模式被實現為獨立的Python檢測工具，能夠接受Solidity源代碼作為輸入，并輸出匹配機會和建議的轉換。研究者首先對100個真實世界合約運行所有24個工具，構建"ground truth"：如果工具找到有效匹配，則記錄相應模式存在。然后，運行Seeker的自然語言和代碼相似性檢索管道，檢查它是否正確激活相關工具。如下圖所示，Seeker成功檢索到557個ground truth實例中的515個，召回率達到92.5%。這一結果表明，雖然先前研究各自僅覆蓋實例的子集，但可以在GasAgent的統一框架內有效整合和重用。

模式整合測試結果

重要的是，這個召回率不是上限，而是閾值控制的結果。如果將檢索閾值設為零，GasAgent可以實現100%的召回率，但會增加計算成本。在當前閾值下，Seeker將工具調用次數從2,400次減少到1,722次（減少28.25%），同時保持高覆蓋率。隨著模式庫繼續擴展更多專門化或資源密集型工具，這種效率提升尤其有價值。92.5%召回率的技術意義：這一結果表明GasAgent能夠有效整合先前研究中提出的模式，實現"一站式"優化解決方案。對于實際應用而言，這意味著開發者無需在多個工具之間切換或維護復雜的工具鏈，而是可以依賴GasAgent作為統一的優化層，同時利用現有知識庫和持續擴展的新發現。這種兼容性是GasAgent在實際部署中可行的關鍵因素。

總結

GasAgent代表了一種范式轉變——從單一工具到多智能體協作系統的轉變。它既是一個Gas優化工具，也是一種基于多智能體的自動化軟件工程范式，展示了如何通過精心設計的模塊化架構和智能體間的閉環協作，解決傳統方法無法兼顧的"模式兼容性"、"新穎性探索"與"自動化驗證"三大難題。

實驗數據在一定程度上，證明了其有效性：在100個真實世界合約上，GasAgent成功優化了82個合約，平均部署Gas節省9.97%；在500個LLM生成的合約上，它優化了79.8%的合約，部署Gas節省在4.79%到13.93%之間。更重要的是，它發現了68個經驗證有效的新模式，展示了其持續進化的潛力。

當然，GasAgent也面臨一些局限與挑戰：

• 對復雜、動態邏輯的優化能力有限：在RQ4評估中，隨著任務復雜度增加（從基礎合約到高級合約），平均節省和成功優化的合約比例均下降。例如，Gemini-2.5生成的合約優化率從9.24%降至4.79%，成功優化合約數從40/50降至36/50。這表明更復雜的合約涉及更深的嵌套、更動態的控制流或跨函數狀態依賴，使基于模式的靜態匹配效果降低。具體挑戰在于當冗余操作與必須保持不變的功能邏輯糾纏在一起時，GasAgent可能無法安全地識別和優化這些部分。
• 模式庫的維護成本：雖然系統能夠自進化，但新發現模式的Python工具仍需手動實現，這可能成為擴展的瓶頸。隨著模式庫規模擴大，如何自動化工具實現將成為關鍵問題。優化或發展的方向可以包括：
• 引入動態分析：結合執行軌跡或更深入的語義流分析，提高對復雜合約的覆蓋能力。特別是對于涉及深層嵌套、動態控制流或跨函數狀態依賴的合約，靜態分析可能不足以識別所有優化機會。
• 探索更智能的終止策略：優化Manager的決策邏輯，減少不必要的迭代。當前系統最多進行6輪優化循環，但并非所有合約都需要如此多輪次，智能終止策略可提高效率。
• 擴展到消息調用Gas：目前主要關注部署Gas，但消息調用Gas同樣重要。未來工作可將優化范圍擴展到運行時Gas消耗，提供更全面的Gas優化解決方案。
• 自動化模式工具生成：研究如何自動生成新發現模式的驗證工具，減少人工干預，加速模式庫的擴展。

GasAgent的實驗表明，多智能體系統在解決復雜軟件工程問題方面具有巨大潛力。它不僅適用于Gas優化，其架構思想也可應用于其他需要結合專家知識、創新探索和嚴格驗證的領域。GasAgent"展示了其作為LLM輔助智能合約開發的即插即用優化層的實用性，可在更廣泛的場景中減少Gas浪費。"