昨天把 Agent 的輸出整理成共享會議內容後，今天要測試另一個更接近真實工作的情況：如果討論到一半，需求突然改了，Agent 能不能接著調整，而不是把整場會議重新跑一次？

這次先把範圍控制在一輪變更。第一輪完成後，可以套用一次新需求，再讓 PM、Research、Creative、Finance 各回應一次。Review Agent 暫時不加入，留到後面的審查流程再處理。

今天要完成的內容

• 準備 5 筆需求變更案例。
• 新增 Discord /change 指令。
• 保存第一輪與第二輪的 Agent 輸出。
• 要求 Agent 針對新限制補充、反對或修正。
• 避免第二輪 Prompt 越疊越長。

準備需求變更案例

我先在 projects.json 加入 5 筆測試資料，例如：

每筆變更都包含所屬專案、修改內容與原因。執行時除了要確認 ID 存在，也要確認它屬於目前正在討論的專案。

用輪次區分 Agent 的發言

原本每位 Agent 只會執行一次，現在同一位 Agent 可能同時有第一輪與第二輪資料，因此我在會議步驟加上：

round_number: int = 1

會議紀錄則保存實際套用的需求變更：

applied_requirement_change: RequirementChange | None = None

這個欄位除了留下紀錄，也用來防止同一場會議重複套用第二筆變更。舊的 meetings.json 沒有 round_number 時，程式會把它視為第一輪，不需要重建既有資料。

第二輪怎麼開始

Discord 指令很簡單：

/change CHG-002

Bot 找到變更後，會交給 MeetingManager.start_second_round()。它先確認第一輪已完成、變更屬於目前專案，而且這場會議還沒進行過第二輪，接著建立四個 round_number = 2 的步驟：

PM → Research → Creative → Finance

第二輪 Prompt 會多放兩組資料：

{
  "requirement_change": {
    "id": "CHG-002",
    "description": "新增退貨率圖表"
  },
  "response_rules": {
    "required_action": "至少補充、反對或修正一項內容",
    "forbidden_response": "不得只回覆我同意"
  }
}

只有提示詞還不夠，所以程式也會檢查輸出。如果整份回覆只有「同意」、「我同意」、「贊成」或「沒有意見」，就直接判定這次回應沒有實質內容。

實測時遇到的問題：Finance 還沒執行就失敗

第一次從 Discord 測試第二輪時，前三位 Agent 都正常，到了 Finance 卻顯示：

第二輪討論失敗：Finance Agent 執行失敗。

一開始我以為是 Ollama 回覆格式錯誤，查看保存的步驟後，發現 input_text 與 output_data 都是空的，代表程式根本還沒呼叫模型。

真正原因是 Finance 的第二輪 Prompt 有 7,359 字元，但專案上限只有 6,000 字元。原本輸入同時放了：

• previous_outputs
• suggestions
• round_summaries

這三部分有不少重複內容，而且越晚發言的 Agent 收到的資料越多，最後在組合 Prompt 時就先被長度檢查擋下。

精簡第二輪上下文

修正後，第二輪只保留各 Agent 真正需要的 previous_outputs：

if current_step.round_number == 2:
    shared_context = {
        "previous_outputs": previous_outputs,
    }

例如 Research 只讀第二輪 PM 的目標與限制；Creative 接著讀 Research 的分類結果；Finance 再取得 PM、Research、Creative 中和成本、限制及方案有關的欄位。第一輪原本的摘要與建議保存方式不變，只是不再重複塞進第二輪 Prompt。

Finance 的輸出也一起縮小，每個分類最多 2 項、每項最多 80 字。提示詞負責告訴模型規則，Pydantic Schema 再做一次實際驗證，避免模型忽略限制。

測試結果

今天的結果

DAY 18 完成了需求變更與第二輪討論的基本流程，也實際碰到多 Agent 系統很常見的問題：上下文不是放得越多越好。重複資料不只增加推論負擔，甚至可能讓模型在收到請求前就失敗。

下一步會讓 PM 整理兩輪內容，把分散的討論收斂成一份可執行的草案。