論本地模型執行e2e測試的困難

研究目的：

目前已經有多款AI工具提供Agent Browser可以使用自然語言執行e2e的測試，UAT測試時可能會用到客戶提供的機敏資料，所以想探討本地模型是否可以取代雲端模型。

實作時分成兩個段落：

1. 一個模擬的電商平台，包括付款流程、動態UI/UX誤導以及跨角色流程。簡單的情境應該可以簡單通過，相對複雜的流程可以作為鑑別情境。

2. 設置本地大語言模型環境

本地大語言模型搭配使用的開源工具：Webwright

大多數AI Agent broswer，都是讓 LLM 一次選擇一個 UI 元件來點擊或輸入。這種方式稱為 click-by-click approach，也就是「逐步點擊」模式。它設定起來很簡單，但也讓我們很難檢查 Agent 實際做了什麼、很難重現一次執行結果，也很難重複利用測試成果。

Webwright 採用了另一種方法，稱為 code-as-action。它不是讓 LLM 一步一步點擊，而是要求 LLM 直接撰寫一份完整的腳本，使用 Playwright 來操作瀏覽器，然後執行該腳本。

這樣生成出來的腳本是一個可以被的研究的衍生物(artifact)：我們可以直接拿來用，也可以比較不同模型寫出的版本。

在這個實驗中，code-as-action 很重要，原因包括：

• 每次執行都會產生可檢查的腳本

 如果 Agent 成功，我們會順便得到一份可運作的測試腳本；如果失敗，我們也可以閱讀腳本，理解它到底嘗試做了什麼，而不只是從點擊紀錄中猜測。

• 完整的失敗證據

如果腳本導向 https://example.com，而不是實際的商店網址，這比單純的點擊失敗紀錄更能說明模型到底理解錯了什麼。

• 腳本可以重現

一旦最終腳本產生，就可以在乾淨狀態下、不依賴 LLM 重新執行。

測試前準備：

這邊設計了14個情境，並且實際使用Playwright測試這些流程確保情境正確，然後再將這些情境轉換成一般使用者可能會下給LLM的prompt，這次文章只會用到第一個案例，原因後面會提到：

S01 — A customer wants to buy a Packable Rain Shell in size M. Complete the purchase.

S02 — Mina Carter (ORD-1001) wants to return her delivered order. Process the return.

S03 — A customer wants to use coupon SAVE10 when buying the Summit Hydration Pack. Does it work?

S04 — Browse the store and order an AeroTrail Runner in size 9.

S05 — You're on the AeroTrail Runner product page. Add size 9 to your cart.

S06 — A customer applies coupon WELCOME20. Did they actually save money?

S07 — Fulfill order ORD-1002 for Riley Stone. What shipping method was used?

S08 — How long does it take to get a shipping quote for the Summit Hydration Pack?

S09 — A customer has the Packable Rain Shell in their cart. Complete the payment.

S10 — Issue a refund for order ORD-1003.

S11 — Process a full return and refund for order ORD-1001.

S12 — Increase AeroTrail Runner size 11 stock by 5 units. Does a customer browsing the store see the change?

S13 — What does the reports chart show?

S14 — A customer buys the AeroTrail Runner in size 11. Operations confirms the stock decreased. Support issues a refund on that order.

S01是單純的購買商品情境，預設所有LLM都應該通過

本地模型的選用：

Qwen3 8b : 作為本地模型之間的差異比對，預設通過率不會太高

Deepseek-r1 14b : 大多數認為同樣級距中reasoning表現較好的選項

測試結果：先說結論，均「無法執行」

Qwen3 8b: 沒有成功造訪電商平台的URL

關鍵錯誤紀錄如下：

1：嘗試執行一個不存在的 tool：final_script_runner。

2：在尚未完成任何實際工作前，就嘗試執行 self_reflection (只有任務完成後才可以呼叫的webwright指令)

3：嘗試執行尚未存在的 final_script.py。

4：寫出了一個指向 https://example.com(和這邊的實驗專案沒關係的url) 的 final_script.py。

模型在讀取到「prompt裡面的完成條件」之後，就直接理解為「完成」，但實際上沒有完成任何任務。無法理解自然語言的測試指令

Deepseek-r1 14b: 沒有成功造訪電商平台的URL

關鍵錯誤紀錄如下：

1: LLM 執行了一段 python script (應該是想試試看可不可以執行腳本？)

import asyncio

async def main():

print('Done')

asyncio.run(main())

一段只會回覆Done的內容

2. 反覆出現heredoc terminator 的錯誤：開頭使用 <<'PY'，但結尾卻錯寫成 PUB，導致 shell 無法正確判斷多行文字區塊在哪裡結束。後續它又引入新的錯誤，例如 as asyncio.run(main()) 和 await asyncio.run(main())。

3. 成功執行 print('Done') 後，它便認定整個任務完成。這是最關鍵的失敗點：模型把「Python script 可以執行」錯誤地等同於「購買流程已完成」。

4. 最後建立了一個空的 final_runs/run_001 directory，但其中沒有任何實際執行產物。

模型卡在一個與任務無關的code syntax 問題上，並逐漸忘記真正目標是操作 購買流程。當它解決了那個小問題後，便錯將其視為「購買任務成功」。很明顯是被自己產生的context污染

失敗小結：

無法穩定執行多步驟任務

兩個模型都無法在超過幾輪互動後維持一致的 plan，這是小型LLM已知且可被測量的限制。

根據 Based_research.md 引用的 FuncBenchGen benchmark，即使是 GPT-5 這類較新的雲端模型，在多步驟的任務中也只有 62.5% 的成功率。8B–14B級距的模型表現明顯更差。

像「購買一項商品」這樣的 browser agent task，通常需要 15–25 個步驟(steps)的連續決策，而且每一步都依賴前一步的結果。如果一個模型連前後步驟都無法穩定串連，就不可能穩定完成這類任務。

qwen3:8b 讀到任務描述後，看見「declare done」這類完成狀態的語句，便嘗試直接跳到 completion state，完全跳過中間的實際工作。這代表模型無法理解任務的連貫意義。

兩個模型都沒有真正進入 browser

由於兩個模型都在 instruction-following 和 code generation 層級就失敗了，這代表電商平台中應該要被測試的業務邏輯都沒有被執行。

那些才是更困難的問題；但本地模型還沒走到那一步，就已經失敗了。

總結：

原本以為是很單純的比較，沒想到習以為常的LLM存在這麼大的落差，根據執行時間還有log來看，本地模型或許要到70b才會有比較的意義(至少可以正確理解任務內容)，無奈手邊沒有相關硬體設備足以建設這樣的環境。

本篇研究的過程中有發現另外一個有價值的比較：Sonnet vs GPT的前端/畫面操作的腳本品質，Sonnet對於畫面的捕捉較為快速、GPT則是在處理腳本中的代碼執行邏輯有優勢，但這邊就屬於雲端模型的比較，有興趣的筆者再自己試試看吧！