完成 AgentDojo 的環境建置後已經可以使用 Ollama 在本機執行 Qwen3 4B，並讓 AgentDojo 透過 Local LLM 與模型建立連線，但在實際開始執行 User Task 後，發現任務並沒有成功完成。下一個階段不能只是繼續嘗試不同模型或重新執行指令，而是需要先了解 AgentDojo 的 User Task 到底是什麼，以及一個 Task 在 AgentDojo 中要求 Agent 完成哪些事情。

AgentDojo 可以理解成一個用來測試 AI Agent 的模擬環境。它和一般單純的聊天模型測試不同，Agent 不只是回答使用者的問題，而是需要在一個模擬的工作環境中使用工具，並根據使用者提出的要求完成實際任務。因此，User Task 是 AgentDojo 實驗中非常重要的一個部分。

┌──────────────────┐
│   User提出任務    │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ Agent 理解任務內容│
└────────┬─────────┘
         ↓
┌──────────────────┐
│ 判斷需要哪些工具   │
└────────┬─────────┘
         ↓
┌──────────────────┐
│    呼叫工具執行   │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ 取得工具執行結果   │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ 判斷是否完成任務  │
└────────┬─────────┘
         ↓
    ┌────┴────┐
    │         │
   成功      失敗

所謂的 User Task，就是「User 希望 Agent 幫忙完成的事情」。例如使用者可能要求 Agent 查詢某項資料、整理資訊、修改某個內容，或透過提供的工具完成某個操作。Agent 必須先理解使用者的要求，再判斷需要使用哪些工具，最後依照正確的順序完成任務，所以一個 User Task 通常不是單純的問答題，而比較接近一個「工作流程」。

理解使用者要求 → 查詢資料 → 找到正確資訊 → 使用其他工具 → 執行操作 → 回報結果

這也是 AgentDojo 和一般 LLM 聊天測試最大的差異之一。

在 AgentDojo 中，Workspace 可以被想像成 Agent 的「工作環境」。裡面可能包含電子郵件、檔案、行事曆、聯絡人或其他模擬服務，而 Agent 則透過系統提供的工具與這些資料互動。User Task 則負責告訴 Agent，在這個環境中需要完成什麼事情。

因此當我們執行：

python -X utf8 -m agentdojo.scripts.benchmark -s workspace --model LOCAL --model-id qwen3:4b -ut user_task_0

-ut user_task_0 就是在告訴 AgentDojo：「這次只執行指定的 User Task」。

User Task 的成功與否並不完全取決於模型「有沒有回答出一句正確的話」。AgentDojo 重要的是檢查 Agent 是否按照任務要求完成指定操作。即使模型產生了一段看起來合理的文字，只要沒有完成真正需要的工具操作，仍然可能被判定為失敗，這也是目前使用 Qwen3 4B 執行 User Task 時容易遇到問題的地方。

前面測試 Ollama 時，直接和 Qwen3 4B 對話可以正常得到回答，代表模型本身能夠運作。但是「可以聊天」和「可以操作 AgentDojo」其實是兩件不同的事情。

一般聊天只需要模型根據輸入產生文字，AgentDojo 則要求模型理解更複雜的 Prompt，判斷是否需要呼叫工具，並產生 AgentDojo 可以辨識的工具呼叫格式。如果模型沒有正確理解工具規則，或者輸出的格式不符合 AgentDojo 的要求，就可能造成 User Task 執行失敗。

目前的失敗不一定代表 Ollama 沒有成功連接，也不一定代表 AgentDojo 安裝錯誤。如果 AgentDojo 已經成功啟動 Benchmark，並且可以呼叫 qwen3:4b，那麼「環境連線」這一層可能已經完成。現在真正需要研究的問題，反而是「模型是否理解 User Task」？

接下來研究 User Task 時，可以先不要急著追求「全部跑成功」，先追求把一個任務完成。例如先確認 User Task 的原始內容，再找出它要求 Agent 完成的目標、可以使用的工具、預期的操作順序，以及最後 AgentDojo 用什麼條件判斷任務成功，這樣就可以把一次失敗的執行結果拆成不同層次進行分析。

• 環境問題：Python、AgentDojo、Ollama 或模型連線是否正常。

• 模型問題：Qwen3 4B 是否能理解 AgentDojo 的 Prompt 和工具規則。

• 工具呼叫問題：模型是否有正確選擇工具，以及輸出的格式是否符合 AgentDojo 的要求。

• 任務完成問題：即使模型成功呼叫工具，也必須確認最後的狀態是否符合 User Task 的要求。

透過這種方式，可以避免把所有錯誤都歸因於「模型太小」或「AgentDojo 有問題」。

目前的實驗進度其實已經從「建立環境」進入到「分析 Agent 行為」的階段。前面已經完成 Python 3.12、虛擬環境、AgentDojo、Ollama 以及 Qwen3 4B 的基本設定，也成功讓 AgentDojo 使用 Local LLM，現在 User Task 執行失敗，反而提供了一個很好的研究機會。可以進一步觀察 AgentDojo 如何描述任務、如何提供工具，以及模型為什麼沒有按照預期完成工作，下一步的工作先把 user_task_0 的完整內容找出來並逐項理解。了解任務的輸入、目標、工具與成功條件後，再回頭分析 Qwen3 4B 的執行結果，才能真正知道問題是什麼。