昨天設計完 Todo List Memory，今天迫不及待地來跑實驗看看效果。
理想很豐滿，現實卻有點骨感。

實驗結果

先上圖：

數據顯示：

• 在 hop=3 的任務上，效果還不錯，甚至有追上 GPT-5 的感覺
• 但其他 hop 數的表現就... 有點不如預期
• 整體來看，並沒有達到我原本預期的「大幅提升」

深入追蹤：發現的三大問題

仔細翻了 log 和中間過程後，發現了幾個關鍵問題：

1. 格式不穩定：LLM 不遵守規則

雖然我在 system prompt 裡寫得很清楚：

[todo]: 任務描述
[done]: 任務描述 → result: 結果
[cancel]: 任務描述 → reason: 原因

但實際上 LLM 的輸出經常「自由發揮」：

• 有時候忘記加 → result:
• 有時候把 [done] 寫成 [completed]
• 有時候乾脆自己發明新的狀態標籤

這種隨機性導致我的解析邏輯時常出錯，todo list 就亂掉了。

根本原因：純文字格式對 LLM 來說太「自由」了，沒有強約束。

2. 狀態割裂：action 失敗時缺乏反饋

這是最嚴重的問題。

在原本的 messages append 架構下，如果某個 action 失敗了：

user: 搜尋 "Qst magazine publisher"
assistant: [執行 web_search]
tool_result: 沒找到相關資訊

這樣 LLM 能直接看到工具執行的狀態，並據此調整下一步。

但在 todo list 架構下，我只把 todo list 本身存下來，並沒有把「action 的執行狀態」明確記錄在 list 裡。
結果就是：

• Action state 執行了某個動作
• 但 todo list 更新時，LLM 根本不知道這個動作是成功還是失敗
• 就算失敗了，list 上的那項還是標成 [done]

感覺很分割，像是左手做的事右手不知道。

3. 狀態轉換混亂：規則不夠明確

我的設計是這樣的：

• Action state 執行完 → 呼叫 update()
• Reflection state 反思完 → 呼叫 update()

問題來了：兩個 state 都會改 todo list，但它們的「視角」不同。

Action state 的問題：

• 它只執行了一個 action（例如搜尋），但更新時常常會把其他還沒碰到的任務標成 [cancel]
• 為什麼？因為 LLM 覺得「反正我現在只做了這個，其他的應該取消吧」

Reflection state 的問題：

• 反思階段會重新思考整體策略，但沒有明確的「指示語言」告訴 LLM：
  • 現在應該保留哪些任務？
  • 哪些任務要新增？
  • 哪些任務應該調整狀態？
• 結果就是每次更新都像在「重寫」todo list，而不是「迭代」

Rule 太弱了，缺乏更細緻的狀態管理機制。

可能的解決方向

雖然效果不理想，但我還是想了幾個可能的改善方向：

方向 1：結構化 Todo List

不要用純文字，改用一個結構化的數據格式，例如：

class TodoItem:
    id: str
    description: str
    status: Literal["todo", "done", "cancel"]
    result: Optional[str]
    reason: Optional[str]

然後讓 LLM 只能透過特定的「操作指令」來修改：

• add_task(description)
• complete_task(id, result)
• cancel_task(id, reason)
• update_task(id, new_description)

這樣就能強制 LLM 遵守格式，避免隨機輸出。

方向 2：在 Todo List 中加入「當前任務」與「執行狀態」

讓 todo list 不只是「待辦清單」，而是包含更多上下文資訊：

[current]: Find the founding year of the publisher of Qst magazine
[status]: Searching... (attempt 1/3)
[last_result]: No results found for "Qst publisher"

---
[todo]: Find the founding year of the publisher of Qst magazine
[todo]: Reverse the founding year number
...

這樣即使 action 失敗了，LLM 在下次更新時也能看到「上次做了什麼、結果如何」，避免狀態割裂。

方向 3：引入 Planner State？

或許問題不在 todo list 本身，而是更新時機不對。

現在的流程是：

Reasoning → Action → Reflection → Update Todo

但或許應該有一個獨立的 Planner State：

• 專門負責「規劃任務」和「更新 todo list」
• 在 Reasoning 之前就先規劃好整體策略
• Action 和 Reflection 只是執行和檢驗，不直接改動 todo list

這樣職責更清楚，也能避免多個 state 互相干擾。

後話與下一步

坦白說，這次的實驗讓我意識到：

Todo list memory 不是我想的那麼簡單，用一個 text file 就能搞定的東西。

它需要：

• 更嚴格的格式約束
• 更完善的狀態管理
• 更清晰的更新邏輯

這些都需要時間來打磨。

但現在鐵人賽已經接近尾聲，剩下沒幾天了，我不想在這個地方卡太久。
所以決定：

• 暫時擱置 todo list memory 的優化
• 明天轉向 Agent-Brain 對於 MCP Server 的支援

MCP（Model Context Protocol）是一個更實用的方向，能讓 agent 跟外部工具有更好的整合。
之後如果有時間，再回來把 todo list 這塊補完。