終於還是來到了這一步 ，今天要把 Agent 通通搞定並且接起來
今天的主角就是我昨天有提到的出題 Agent 啦，昨天只是大致上講解它的功能以及小小總結目前整個專案的走向，並沒有真的實裝。
今天就來把他加進去吧！！！

出題 Agent 的五步流程

當學生點擊「換一題」或「程式碼全部通過」時，系統會觸發出題流程：

學生按「換一題」(或程式碼全部通過)
        ▼
① 讀黑板      Firestore → students/{學號}/misconceptions
             [loop ×5, dict-access ×2, indentation ×1]
        ▼
② 取前三名    只挑次數最多的弱點（避免模型出一題想涵蓋所有弱點的怪題）
        ▼
③ 問 Gemini   主題 + 前三名觀念 (含次數與最近一次的描述)
             要求回 JSON：title / description / entry_point / tests / targets
        ▼
④ 嚴格檢查   檢查是否存在 tests 與 entry_point
             缺一就整題拒收 → 保留原本那題，只回報錯誤
        ▼
⑤ 換上新題   新題目進 State，同時重置：階梯歸零、對話清空、舊評測作廢

三個設計關鍵

1. 職責分離：Agent 不碰 Firestore

agents/setter.py 本身不直接連線資料庫，只接收「已經讀好的」錯誤觀念清單。

2. 嚴格拒收：寧可不出題，也不出評不了的題

如果生成的題目缺少 tests，系統後續就無法進行評測；缺少 entry_point，評測 Agent 就不知道該呼叫哪一個函式。

這種「殘缺的題目」一旦進入系統，會直接導致後續兩個 Agent 功能失效。因此第四步採取嚴格防禦：只要欄位不完整就直接拒收，系統留用原題並記錄錯誤，絕不硬塞壞題目給學生。

3. targets 隔離：不混入題目 Prompt

targets 代表「這題在訓練哪些觀念」，屬於出題的背後意圖。

如果將 targets 混入 problem 物件中，這段資訊會一路被傳遞給評測 Agent 與導師 Agent，變成 Prompt 裡的無效雜訊。它的正確用途是留在 UI 畫面上呈現提示（例如：🎯 這題針對你的：迴圈），讓學生明確知道系統並非隨機抽題，而是針對其弱點進行強化訓練。

結果如下圖：

Agent 可以正常出題、評測(未實裝沙盒) 以及導師可以給予意見
單純 Agent 的功能都有接上沒有什麼 BUG 但弱點依舊明顯：

• 評測是推測，不是執行會漏掉執行時才出現的錯誤（例外、無限迴圈），也可能誤判。真實執行需要沙箱隔離，屬於獨立子系統。介面已預留替換點，測試契約也為此而定。
• 免費方案每個模型每天 20 次請求一次送出吃兩次呼叫，換一題吃一次。開發期間很容易用完，這也是上一節那次事故的根因。
• lite 模型的推理品質下降一次觀察中，評測抓對了失敗數量，摘要卻在解釋一個實際會通過的案例，導師接著順著錯誤的方向提問。單一樣本不足以定論，但與 lite 的預期代價一致，而且錯誤會經由摘要傳染給導師。
• checkpointer 是記憶體的MemorySaver 在程序重啟後清空，對話與卡關輪數不跨重啟保存。跨進程持久化不在本次範圍。

接下來會一一的改進以上的缺點以及增加我想要的功能。