雖然現階段專案專注在 Agent 之間的架構與引導流程，但沙盒已明確列入未來的核心升級規劃。這篇就來說說：

光靠 LLM 評測哪裡不好？如何在現階段就把沙盒的未來契約預留好

為什麼光靠 LLM 評測會讓人心虛？因為在真實程式執行的世界裡，有太多的邊界狀況是「用眼睛看」看不出來的：

用 LLM 推測只是一個開發過渡期的折衷方案，它能幫我快速把 Agent 之間的流程圖（Graph）架構搭起來。但要做到 100% 精準判題，系統未來非得引進沙盒來「真正跑一遍」不可。

沙盒預留介面：未來接軌時 Graph 拓樸零改動

為了不讓未來的沙盒升級變成一場「砍掉重練」的災難，我在 LangGraph 架構中將評測節點（grade node）採用了 Closure 工廠與依賴注入模式：

Python

# 第 2 期現行：注入 Gemini API（用眼睛看）
make_grade_node(client)

# 未來升級規劃：注入沙盒 Runner（真正跑一遍）
make_grade_node(runner)

這樣設計的好處是：

1. 拓樸（Topology）零改動：未來引入沙盒時，LangGraph 流程圖裡的邊（Edges）與條件分支完全不需要改。
2. 黑板（Firestore）零遷移：評測結果只活在 LangGraph 的 State 中，黑板只存錯誤觀念，未來沙盒要擴充執行時間、記憶體使用量，都不涉及資料庫遷移。
3. LLM 轉為「解釋者」：未來即使有沙盒「真正跑一遍」，沙盒也只給冷冰冰的 Pass/Fail，我依然需要 LLM 把沙盒吐出的慘烈報錯（Traceback）翻譯成導師能引用的溫柔語意摘要。

提前釘死「可執行的程式碼契約」

這是消除違和感、接軌未來沙盒最重要的一步！LLM 很聰明，光用眼睛看就能理解鬆散的自然語言測試；但未來沙盒拿去「真正跑一遍」時，只認得真正的 Python 程式碼。

如果第 3 期「出題 Agent 」產出的測試題目長這樣：

• ❌ tests: ["輸入 5 要拿到 10", "空字典要回傳 Not Found"]

未來一旦接上沙盒，沙盒執行這段中文會直接爆掉，我就必須把 Prompt、評測 Node、資料庫全部重寫！

因此，我從現在開始就將 tests 欄位釘死為「可獨立執行的 Python assert 程式碼契約」：

Python

# 題目與測試的形狀 (problem schema)
{
    "title": "字典鍵值搜尋",
    "description": "請撰寫一個函式 `find_value(data, key)`...",
    "entry_point": "find_value",
    "tests": [
        "assert find_value({'a': 1}, 'a') == 1",
        "assert find_value({}, 'x') == 'Not Found'",
        "assert find_value({'a': None}, 'a') is None",
    ]
}

這邊已經先暫時搞定了未來如果需要沙盒時的前置作業了，之後就可以安安心心的處裡 Agent 了 : >