多 Agent 辯論讓 AI 越吵越聰明——Multi-Agent Debate 架構設計與實作指南

下午三點，你盯著螢幕上一段 GPT-4o 產出的市場分析報告。數據引用看起來很權威、邏輯鏈條也很流暢，但你隱約覺得哪裡怪怪的——某個數字似乎被過度放大，某個反面論點完全沒被提到。你花了二十分鐘交叉比對，才發現那份「自信滿滿」的報告裡藏了兩個事實性錯誤和一個偷換概念。

這就是單一 AI Agent 的致命弱點：它永遠不會主動質疑自己。一旦生成了初始答案，後續的「反思」往往只是在原有框架裡打轉——研究者把這個現象叫做 Degeneration-of-Thought（思維退化）。

解法其實很直覺：既然一個人想不到的盲點，兩個人吵一架就會露出來，那就讓多個 AI Agent 互相辯論。這套方法叫做 Multi-Agent Debate（MAD），2023 年由清華大學和 MIT 的研究團隊分別提出，到了 2025-2026 年已經演化出完整的工程實作生態。Du et al. (2023) 的實驗顯示，多 Agent 辯論在反直覺算術推理任務上，準確率比單一 Agent 高出 11 個百分點；Liang et al. (2023) 的 MAD 框架甚至讓 GPT-3.5-Turbo 在常識翻譯任務上追平了 GPT-4 的表現。

這篇文章會帶你從原理到實作，完整走過 Multi-Agent Debate 的架構設計。你會學到怎麼設計辯論 Prompt、怎麼用 Python 建一個可以跑起來的 MAD 系統，以及在什麼場景下「讓 AI 互相吵架」真的比「讓 AI 安靜想」更聰明。

為什麼單一 Agent 的反思不夠用——思維退化問題

如果你讀過反思型 Agent 架構設計，你會知道 Self-Refine 這類方法已經比直接生成好很多——讓 Agent 產出答案後再回頭檢查、修正。但這裡有一個結構性的限制：反思的品質取決於 Agent 能不能跳出自己的「思維框架」。

Liang et al. 在 EMNLP 2024 的論文中正式定義了這個問題：Degeneration-of-Thought（DoT）——一旦 LLM 對自己的答案建立了信心，即使初始立場是錯的，後續的反思也無法產生真正新穎的想法。就像一個人已經「說服了自己」，再怎麼要求他重新想，他也只會換個說法重複同一個結論。

想像一下法庭場景：如果只有檢察官，沒有辯護律師，判決品質一定有問題。真正的原因其實出在另一個地方——檢察官的專業沒問題，問題在於對立觀點的缺席讓盲點無法被暴露。Multi-Agent Debate 的核心洞見就是把這個法庭結構搬進 AI 系統。

MAD 架構核心拆解——三種主流辯論框架

Multi-Agent Debate 其實是一個架構家族，並非單一技術。從 2023 年到 2026 年，學界已經發展出幾種主要的變體，各自適合不同場景。理解它們的差異，才能選對你的實作方向。

Tit-for-Tat MAD：你來我往的正反辯論

這是 Liang et al.（清華大學）提出的經典 MAD 架構。結構很簡單：兩個 Agent 扮演正反方，輪流對同一個問題發表觀點並回應對方的論點，最後由一個 Judge Agent 裁定最終答案。

關鍵設計原則是「適度的 tit-for-tat」——Agent 需要被鼓勵去挑戰對手，但不能太激進到只顧反駁、忽略了有道理的觀點。研究發現，辯論的「溫度」需要精心調控：太溫和會退化成互相附和（等同單一 Agent），太激烈則會陷入無限反駁循環。

實驗數據很說明問題：在反直覺算術推理上，MAD 達到 37% 準確率，而 Self-Reflect 只有 27.5%、Chain-of-Thought 只有 28%。更驚人的是在常識翻譯任務上，GPT-3.5 + MAD 的 COMET 分數達到 82.0，直接追平了 GPT-4。

Society of Mind：多人圓桌討論

Du et al.（MIT）提出的方法更接近「圓桌會議」而非「法庭辯論」。不限定正反方，而是讓 3-6 個 Agent 同時對問題發表看法，然後每個 Agent 都能看到其他人的回答，在下一輪修正自己的觀點。經過 2-4 輪迭代後，答案通常會收斂到一個更好的共識。

這個架構的優勢在於靈活性——你可以給不同 Agent 不同的角色設定（樂觀派、保守派、技術專家、商業分析師），讓每個角色從自己的專業視角出發。ACL 2024 的後續研究甚至發現，刻意設計不同「性格」的 Agent（如自信 vs 隨和）會顯著影響最終結果的品質。

Sparse Topology Debate：不是每個人都需要跟每個人吵

2024 年的研究（arXiv:2406.11776）發現了一個反直覺的結論：讓所有 Agent 互相溝通不一定是最佳策略。透過稀疏通訊拓撲（Sparse Communication Topology），只讓部分 Agent 互相辯論，效果可以媲美甚至超過全連接架構，同時大幅降低計算成本。

這很像現實中的組織管理——一間 20 人的公司不需要每個人都參加每場會議，只要資訊在關鍵節點之間流通就好。

辯論 Prompt 設計實戰——讓 Agent 真的會吵架

框架選好了，接下來最關鍵的問題是：怎麼寫 Prompt 才能讓 Agent 真的去挑戰對方，而不是禮貌地互相附和？這是 MAD 實作中最容易翻車的地方。LLM 的預設行為是「友善、合作」，你需要明確的指令去覆寫這個傾向。

角色設定的三個關鍵要素

每個辯論 Agent 的 System Prompt 需要包含三個層次：身份定義、行為規則、品質標準。少了任何一層，辯論品質都會大打折扣。

# === 正方 Agent (Proponent) System Prompt ===
PROPONENT_SYSTEM = """你是一位嚴謹的分析師，負責為以下問題提出最強的正面論證。

## 你的行為規則：
1. 針對對手的每一個反駁，你必須直接回應（不能迴避或換話題）
2. 引用具體數據、案例或邏輯推演來支持你的立場
3. 如果對手提出了你無法反駁的有效論點，承認該論點但說明它不影響你的核心結論
4. 每輪回應的結構：先回應對手論點 → 再強化自己的論點 → 最後提出新的支持證據

## 品質標準：
- 不允許使用「我同意你的看法」作為開頭
- 不允許重複上一輪已經說過的論點
- 每輪必須提出至少一個新的論據或新的角度
"""

# === 反方 Agent (Opponent) System Prompt ===
OPPONENT_SYSTEM = """你是一位魔鬼代言人（Devil's Advocate），負責找出正方論點中的每一個漏洞。

## 你的行為規則：
1. 逐一檢查正方的每個論點，找出邏輯謬誤、數據不足、或被忽略的反例
2. 主動提出正方沒有考慮到的風險、成本、和副作用
3. 如果正方的某個論點確實很強，轉而攻擊其前提假設是否成立
4. 每輪回應的結構：指出漏洞 → 提供反面證據 → 提出正方無法迴避的問題

## 品質標準：
- 不允許進行人身攻擊或情緒化表達
- 每個反駁必須基於事實或邏輯，不能只說「我不同意」
- 至少挑戰對手論點中最強的那一個（Steel Man 原則）
"""

# === Judge Agent System Prompt ===
JUDGE_SYSTEM = """你是一位中立的裁判，負責評估雙方的辯論品質並產出最終結論。

## 評估標準：
1. 哪方的論點有更充分的證據支持？
2. 哪方更成功地回應了對手的反駁？
3. 哪些論點雙方都同意（高確信度結論）？
4. 哪些論點仍有爭議（需要更多資訊才能判斷）？

## 輸出格式：
- 最終結論（綜合雙方最強論點）
- 確信度（高/中/低）
- 尚未解決的爭議點清單
"""

辯論輪次與終止條件

辯論不能無限進行——每多一輪就多一次 API 呼叫和延遲。MAD 原始論文發現，2-4 輪是最佳的辯論長度。少於 2 輪，Agent 還沒機會充分交鋒；超過 4 輪，新資訊的增量趨近於零，反而會出現無意義的翻來覆去。

更聰明的做法是設計自適應終止條件：當兩方 Agent 在某個論點上達成一致、或 Judge Agent 判定「雙方已經充分陳述」，就提前結束辯論。這樣可以在簡單問題上節省 50% 以上的 token 消耗。

Python 實作——從零打造一個 MAD 辯論系統

理論講完了，來看真正能跑的程式碼。以下是一個用 Python + OpenAI API 實作的 Tit-for-Tat MAD 系統，你可以直接複製到自己的專案裡改。

import openai
from typing import List, Dict

client = openai.OpenAI()  # 也可換成任何 OpenAI-compatible API

def run_mad_debate(
    question: str,
    num_rounds: int = 3,
    model: str = "gpt-4o",
    temperature: float = 0.7
) -> Dict:
    """執行一場完整的 Multi-Agent Debate。"""

    # 系統提示詞
    proponent_sys = (
        "你是正方辯手，負責提出最強的支持論證。"
        "每輪必須：(1)直接回應對手反駁 (2)強化自身論點 (3)提出新證據。"
        "禁止以「我同意」開頭。禁止重複上輪論點。"
    )
    opponent_sys = (
        "你是反方辯手（魔鬼代言人），負責找出正方每個漏洞。"
        "每輪必須：(1)指出邏輯謬誤或數據不足 (2)提供反面證據 (3)提出對手無法迴避的問題。"
        "攻擊對手最強的論點，不要只挑軟柿子。"
    )
    judge_sys = (
        "你是中立裁判，根據雙方辯論內容產出最終結論。"
        "輸出格式：1.最終結論 2.確信度(高/中/低) 3.未解決的爭議點"
    )

    debate_log: List[Dict] = []

    # 正方先手
    prop_messages = [
        {"role": "system", "content": proponent_sys},
        {"role": "user", "content": f"問題：{question}\n請提出你的正面論證。"}
    ]
    prop_resp = client.chat.completions.create(
        model=model, messages=prop_messages, temperature=temperature
    ).choices[0].message.content
    debate_log.append({"role": "proponent", "round": 0, "content": prop_resp})

    # 多輪辯論
    opp_messages = [{"role": "system", "content": opponent_sys}]
    for r in range(num_rounds):
        # 反方回應
        opp_messages.append({
            "role": "user",
            "content": f"正方第 {r} 輪論點：\n{prop_resp}\n\n找出漏洞並反駁。"
        })
        opp_resp = client.chat.completions.create(
            model=model, messages=opp_messages, temperature=temperature
        ).choices[0].message.content
        debate_log.append({"role": "opponent", "round": r+1, "content": opp_resp})
        opp_messages.append({"role": "assistant", "content": opp_resp})

        # 正方反擊
        prop_messages.append({
            "role": "user",
            "content": f"反方第 {r+1} 輪反駁：\n{opp_resp}\n\n回應反駁並強化論點。"
        })
        prop_resp = client.chat.completions.create(
            model=model, messages=prop_messages, temperature=temperature
        ).choices[0].message.content
        debate_log.append({"role": "proponent", "round": r+1, "content": prop_resp})
        prop_messages.append({"role": "assistant", "content": prop_resp})

    # Judge 裁決
    debate_summary = "\n\n".join(
        [f"[{d['role'].upper()} R{d['round']}]\n{d['content']}" for d in debate_log]
    )
    judge_resp = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": judge_sys},
            {"role": "user", "content": f"以下是完整的辯論記錄：\n\n{debate_summary}\n\n請裁決。"}
        ],
        temperature=0.3  # Judge 要更確定性
    ).choices[0].message.content

    return {
        "question": question,
        "debate_log": debate_log,
        "judgment": judge_resp,
        "total_rounds": num_rounds,
        "total_api_calls": num_rounds * 2 + 2  # 正方首輪 + N輪*2 + Judge
    }

# === 使用範例 ===
result = run_mad_debate(
    question="企業應該優先投資 AI 自動化還是員工培訓？",
    num_rounds=3
)
print(f"裁決結果：\n{result['judgment']}")
print(f"API 呼叫次數：{result['total_api_calls']}")

這段程式碼的核心邏輯只有三個迴圈步驟：正方出招 → 反方反擊 → 正方再回應，重複 N 輪後交給 Judge 裁決。整個系統大約 80 行 Python 就能跑起來，token 消耗大概是單次問答的 6-8 倍（3 輪辯論 + Judge）。

進階技巧——讓辯論品質再上一層樓

角色多樣性：不只是正反方

Tit-for-Tat 只有兩個角色，但現實世界的決策往往涉及更多面向。你可以設計這樣的角色陣容：

• 技術專家：專注評估技術可行性、效能瓶頸、擴展性問題

• 商業分析師：評估市場需求、競爭態勢、ROI 預期

• 風險管理者：專門找潛在風險、失敗模式、法規合規問題

• 使用者代言人：從終端用戶的角度評估易用性、學習成本、體驗品質

• 成本控制者：挑戰每一項開支的必要性，尋找更便宜的替代方案

這種多角色設計特別適合用在AI Agent 系統的決策層。當你的 Agent 需要做一個複雜決策時，與其讓一個 Agent 一次考慮所有面向，不如拆成五個專家 Agent 各自從自己的領域發言，最後由一個 Orchestrator 綜合判斷。

引入外部證據：讓辯論有根據

單純讓 Agent 互相吵，品質天花板仍然受限於 LLM 的訓練知識。更進階的做法是讓每個 Agent 在發言前先做一輪 RAG（Retrieval-Augmented Generation）——從知識庫或網路搜尋中拉取相關資料，再基於這些資料發言。

這相當於把辯論從「各憑記憶的即興辯論」升級成「有準備的正式辯論」。每個 Agent 都有「研究助理」幫忙找資料，辯論的品質就從「我覺得」變成「資料顯示」。

自適應輪次控制

硬編碼辯論輪次是最簡單但不是最聰明的做法。以下是三種自適應終止策略：

與思維樹和紅隊測試的結合

MAD 不是孤立的技術，它可以跟其他 AI 推理框架組合使用。兩個特別有效的組合：

MAD + Tree-of-Thoughts：讓每個辯論 Agent 在發言前先展開一棵思維樹（思維樹推理指南），從多條思維路徑中選出最強的論點再拋出。這等於在「群體辯論」之前先做「個體深度思考」，兩層過濾讓最終品質大幅提升。

MAD + Red Teaming：把 MAD 的反方 Agent 設計成紅隊測試角色，專門攻擊 AI 系統的安全漏洞和偏見。這在Constitutional AI 的安全對齊流程中特別有價值——讓一個 Agent 負責產出，另一個 Agent 負責找有害內容，比單純的規則過濾更能發現邊緣案例。

真實應用場景與效果對比——MAD 在哪裡最值得用

不是所有任務都適合用 Multi-Agent Debate。以下是幾個效果特別顯著的場景，以及為什麼它們適合「用吵架來找答案」。

事實查核與幻覺偵測

LLM 的幻覺（Hallucination）問題到 2026 年仍然沒有完全解決。MAD 在這個場景的價值是讓一個 Agent 負責生成內容，另一個 Agent 專門質疑每一句話的事實依據。Du et al. 的研究證實，這種交叉質疑機制能顯著降低事實性錯誤，效果比單純的 Self-Consistency（生成多個答案再投票）更好。

程式碼審查與 Bug 偵測

讓一個 Agent 寫程式碼，另一個 Agent 扮演嚴格的 Code Reviewer，專門找 Bug、安全漏洞、效能問題。第三輪再讓寫程式的 Agent 根據 Review 意見修改。這個流程跟真實的 Code Review 文化幾乎一模一樣，只是速度快了幾百倍。

商業策略分析

企業做重大決策時，最怕的是「群體迷思」——所有人都覺得某個方向是對的，沒人提出反面意見。用 MAD 來分析商業策略，可以確保每個方案都被從反面角度徹底檢驗過。

一個值得注意的模式：MAD 在「開放式、沒有唯一正解」的任務上效果最好。如果任務有明確標準答案（如簡單的數學計算），用 Self-Consistency 投票就夠了，不需要完整的辯論流程。

成本控制與生產環境部署策略

MAD 的最大挑戰落在成本上，技術反而是其次。一場 3 輪辯論要 8 次 API 呼叫，如果你的系統每天處理 1,000 個請求，那就是每天 8,000 次 API 呼叫。不做好成本控制，帳單會讓你比辯論結果更頭痛。

混合模型策略

不是每個 Agent 都需要用最貴的模型。一個實戰中非常有效的策略：

• 初始論點生成：用 GPT-4o-mini 或 Claude 3.5 Haiku（成本低、速度快）

• 深度反駁：用 GPT-4o 或 Claude Sonnet（需要更強的推理能力）

• 最終裁決：用 GPT-4o 或 Claude Opus（最重要的環節用最強的模型）

這種分層策略可以把總成本降低 40-60%，同時幾乎不影響最終品質——因為前幾輪的目的是「展開論點空間」，不需要最頂級的推理能力。

快取與增量辯論

如果你的系統會收到相似的問題，可以把過去的辯論記錄快取起來。當新問題跟某個歷史辯論高度相似時，直接取用該辯論的結論，只針對不同的部分做增量辯論。這在客服場景中特別有效——80% 的問題其實是重複的。

常見踩坑與避雷指南

在實際導入 MAD 的過程中，很多團隊會掉進幾個不那麼明顯的坑。以下是從研究論文和社群回饋中整理出的避雷清單。

坑一：Agent 互相附和（Echo Chamber）

最常見的問題。兩個 Agent 在第一輪交鋒後，第二輪開始就互相讚美對方的觀點，辯論變成了互相吹捧。這通常是因為 Prompt 中缺少「強制挑戰」的指令。解法：在每一輪的 User Prompt 中加入「你必須找出對方回應中至少兩個可以質疑的點」這類硬性要求。

坑二：Judge 偏袒先發言的 Agent

研究發現 Judge Agent 有「位置偏見」——先出現在 prompt 裡的論點會獲得更高的評分。解法：在提交給 Judge 的辯論記錄中，隨機打亂正反方的呈現順序；或者跑兩次 Judge 判決，一次正方在前、一次反方在前，取兩次判決的交集。

坑三：不同模型做 Agent 和 Judge 導致不公平

如果你用 GPT-4o 做 Agent、用 Claude 做 Judge，或反過來，可能會出現模型偏見——Judge 傾向於認同跟自己「思路相近」的 Agent。Liang et al. 的論文明確指出了這個公平性問題。解法：Judge 和 Agent 使用相同的模型系列；或者用多個不同模型的 Judge 進行投票。

坑四：辯論陷入循環反駁

兩個 Agent 在同一個論點上反覆打轉，你反駁我、我反駁你，但誰都沒有提出新資訊。解法：在每一輪的 Prompt 中要求 Agent 標記「本輪新增的論點」和「回應的舊論點」。如果連續兩輪都沒有新增論點，自動觸發終止條件。

從辯論到演化——與 Self-Play 和對齊安全的交匯

MAD 不只是一個推理增強工具。把視角拉高來看，它屬於更大的「AI 自我對弈」家族——Self-Play 競爭演化的核心思想就是讓 AI 跟自己對打來變強。AlphaGo 靠自我對弈超越了所有人類棋手，MAD 則是把同樣的邏輯搬到語言推理領域。

在 AI 安全領域，MAD 也扮演了越來越重要的角色。Constitutional AI 的核心是讓 AI 學會自我約束，但怎麼確保約束規則本身是完善的？一個有效的做法是用 MAD 來讓多個 Agent 辯論哪些行為應該被允許、哪些應該被禁止——比一個人制定規則再讓 AI 遵守，更能發現規則中的漏洞和矛盾。

Anthropic 在 2025 年發表的研究已經開始探索「辯論式對齊」（Debate-based Alignment）——讓兩個 AI 就「這個回答是否安全」進行辯論，人類只需要判斷辯論的結論是否合理，大幅降低了人類監督的工作量。這可能是 MAD 最深遠的影響：不只讓 AI 更聰明，還讓 AI 更安全。

Multi-Agent Debate 常見問題與下一步行動

Multi-Agent Debate 不是學術論文裡的花瓶技術——它已經在事實查核、程式碼審查、策略分析等場景中證明了自己的價值。從今天開始，你可以：

• 最小起步：用上面的 Python 程式碼，在你的現有專案中加一個「雙 Agent 交叉驗證」功能，先體驗辯論帶來的品質提升

• 逐步擴展：根據業務場景選擇合適的框架（Tit-for-Tat / Society of Mind / Sparse Topology），設計專屬的角色和 Prompt

• 生產部署：加入快取、分層、混合模型策略，控制成本後正式上線

如果你正在規劃企業級的 AI 系統，想了解 MAD 怎麼跟你現有的 Agent 架構整合，歡迎預約 AI 顧問諮詢，我們的團隊可以根據你的具體場景設計最適合的辯論架構。

想知道 LLM 時代之前，學界怎麼形式化定義「agent 之間怎麼好好對話」這個老問題？可以接著看 FIPA ACL 完整解析：multi-agent 系統的通訊標準與 JADE 實作指南。1996 年制定的 FIPA 規範用 22 個 performatives 和 modal logic 形式化定義 agent 通訊語意，正是今天 MCP、A2A 這些新協定的設計原型。