DAY 19 已經能把兩輪討論整理成 PM 草案，但草案產生後，還沒有人負責檢查內容是否完整，也沒有退回修改的流程。

今天把 Review Agent 接回會議流程，新增 Discord /review 指令。Review 會先檢查草案；如果發現問題，就把最高優先的修改要求交給指定 Agent。修改完成後，再由 PM 整合成最終方案。

這個流程只允許修改一次。這是刻意保留的限制，否則 Review、修改 Agent 與 PM 可能一直互相呼叫，本機模型的等待時間和上下文也會持續增加。

今天完成的內容

• 新增 /review 指令
• 讓 Review Agent 檢查四個面向
• 為每項問題指定修改負責人
• 只執行一次最高優先修改
• 讓 PM 重新整合最終方案
• 保存審查、修改結果及用量統計

審查流程

/draft 建立 PM 初稿
        ↓
/review 啟動 Review Agent
        ↓
檢查完整度、創意、可信度、可行性
        ↓
   通過 → 初稿直接成為最終方案
        ↓
 需要修改
        ↓
選出最高優先問題
        ↓
指定 Agent 修改一次
        ↓
PM 重新整合最終方案

流程主要寫在 MeetingManager.review_and_finalize()。執行前會先確認目前有會議，而且 /draft 已經建立 proposal_draft。如果還沒有草案，Discord 會提示先執行 /draft。

Review Agent 回傳固定格式

DAY 14 建立 Review Agent 時，已經定義完整度、創意、可信度與可行性四項檢查。今天再替每個問題加入 assigned_agent，讓程式知道要把修改交給誰：

assigned_agent: Literal[
    "PM Agent",
    "Research Agent",
    "Creative Agent",
    "Finance Agent",
]

Review Agent 的結果包含：

• status：通過 或 需要修改
• checklist：四項檢查的結果與原因
• issues：問題、修改要求、優先級和負責人
• revision_allowed：這次是否還能修改

issues 最多四項，問題與修改說明也有長度限制。這裡不是只靠 Prompt 要模型遵守格式，回覆仍會經過 Pydantic 驗證。

修改次數交給 Python 控制

模型會回傳 revision_allowed，但程式不會直接相信這個值，而是依 revision_count 重新判斷：

revision_allowed = (
    result.status == "需要修改"
    and request.revision_count == 0
)

revision_count 在資料模型中只能是 0 或 1。只有第一次審查需要修改時，Meeting Manager 才會呼叫指定 Agent。

如果有多個問題，程式會依「高、中、低」排序，挑出最高優先項目，再把同一位負責人的相關問題一起傳入。指定 Agent 成功回覆後，revision_count 立即改成 1，接著由 PM 整合最終方案。

再次執行 /review 時，如果 final_proposal 已經存在，程式會直接讀取保存結果，不會重新審查或再修改一次。

Discord 顯示方式

實際操作順序是：

/start project_id
/change change_id
/draft
/review

/review 是長時間任務，因此先使用 defer(thinking=True)，完成後再用 Followup 傳送結果。

Discord 會先顯示 Review Embed，列出四項檢查與修改要求。如果需要修改，接著顯示本次交給哪一位 Agent，以及修改次數已達 1/1。最後一則 Embed 是 PM 重新整理後的最終方案，底部也會顯示輸入／輸出字元、Token 與整合耗時。

這次實測結果

我使用 PRJ-003 的草案執行 /review。Review Agent 判定「需要修改」，其中創意與可行性通過，完整度和可信度未通過。

最高優先問題是退貨率公式還不夠清楚，因此交給 Research Agent 補充。Research Agent 完成後，PM 把「實際交付金額＝總訂單金額－已退貨金額」寫進最終方案，revision_count 也變成 1。

這次保存的執行資料如下：

PM 最終整合使用 1,677 個 Prompt Token，輸出 1,031／1,600 Token。這些數字不是另外手動計算，而是從 meetings.json 保存的實測紀錄讀取。

保存審查與修改紀錄

一場完成審查的會議會新增：

proposal_draft
review_result
revision_count
revision_agent_name
revision_output
final_proposal
final_proposal_metrics

Review Agent 與修改 Agent 的輸入、輸出、字元、Token 和執行時間，也會以 round_number: 3 加入 steps。日後查看紀錄時，可以知道草案被指出什麼問題、由誰修改，以及 PM 最後如何整合。

測試結果

今天完成到哪裡？

PM 草案現在會先經過 Review Agent 審查。通過的草案直接成為最終方案；需要修改的草案只會退回一次，再由 PM 收斂結果。

這次 Discord 實測也走完「審查、指定修改、PM 最終整合」流程。DAY 20 的完成標準已達成：不完整的草案會收到明確修改要求，而且流程不會無限循環。