大家好！歡迎來到「Build on Google AI」工程挑戰的第 24 天。

（我知道、我知道，我昨天對天發誓今天要講 Action Confirmations。但是各位工程師，突發狀況來了！我們不得不再次插隊！）

為什麼？因為當我們昨天建立好跨部門產線後，法務部主管立刻要求加入一位 「法務 (Legal) Agent」，專門審核行銷 Agent 寫出來的爆款文案。

結果昨晚的系統測試發生了慘劇：

行銷 Agent 寫了：「保證 100% 解決你所有的 JSON 報錯！」

法務 Agent 審查後退件：「違反廣告法規，不能使用『保證 100%』等絕對字眼。」

行銷 Agent 重寫：「絕對讓你永遠不再看到 JSON 報錯！」

法務 Agent 再退件：「『絕對永遠』依然是誇大不實。」

兩個 Agent 就這樣在雲端吵了一個晚上，陷入了無窮迴圈 (Infinite Loop)，直到把 Google Cloud 的 API 配額全部燒光為止。

在 Multi-Agent 系統中，Agent 之間的「談判與修改迴圈」是非常強大的功能，但如果沒有設定邊界，它就是一顆定時炸彈。今天，我們要用 Google ADK 的 條件路由 (Conditional Edges) 來設計一套防護機制！

第一步：升級 State，加入「談判計數器」
為了解決這個問題，我們必須在昨天定義的「全局白板 (Shared State)」中加入兩個關鍵欄位：is_approved (是否核准) 以及最重要的 revision_count (修改次數計數器)。

from pydantic import BaseModel
from typing import Optional

class CampaignState(BaseModel):
    user_request: str = ""
    marketing_copy: str = ""
    review_feedback: str = ""
    
    # 防止無窮迴圈的關鍵欄位
    is_approved: bool = False
    revision_count: int = 0  # 記錄被法務退件的次數

第二步：定義會「吵架」的兩個 Agent
我們在 ADK 中設定行銷與法務兩個 Agent。特別注意，法務 Agent 的職責不僅是檢查，還要負責更新 is_approved 的狀態。

from google.adk import Agent

# 1. 行銷 Agent (負責寫作與修改)
marketing_agent = Agent(
    name="marketing_agent",
    model="gemini-2.5-pro",
    instruction=(
        "你是行銷總監。請根據需求撰寫文案。"
        "如果收到 review_feedback (審查意見)，請務必根據意見修正文案，切勿重蹈覆轍！"
    )
)

# 2. 法務審核 Agent (負責把關)
legal_agent = Agent(
    name="legal_agent",
    model="gemini-2.5-pro",
    instruction=(
        "你是嚴格的法務審核員。請檢查文案是否誇大不實。"
        "如果合格，請將 is_approved 設為 true；如果不合格，請設為 false，並在 review_feedback 中寫明具體違反原因。"
    )
)

第三步：實作「條件路由」與「防迴圈機制」
在 Google ADK 的圖結構 (Graph) 中，我們可以撰寫一個 Python 函式來決定下一步該往哪裡走。這就是所謂的 條件路由 (Conditional Routing)。

如果法務說 OK，就結束；如果法務退件，我們不是無腦退回給行銷，而是先檢查計數器！

# 3. 條件路由函式 (Router)
def review_router(state: CampaignState) -> str:
    """決定工作流下一步去哪裡的「交通警察」"""
    
    if state.is_approved:
        print("✅ 法務審核通過！流程準備結束。")
        return "END"
        
    if state.revision_count >= 3:
        # 【防迴圈機制】談判破局，強制升級給人類處理！
        print(f"🚨 警告：行銷與法務已來回修改 {state.revision_count} 次，啟動升級機制 (Escalation)！")
        return "human_intervention" 
        
    # 如果還沒超過上限，就退回給行銷 Agent，並增加修改次數
    print(f"⚠️ 法務退件！退回重寫。目前修改次數: {state.revision_count + 1}")
    state.revision_count += 1
    return "marketing_agent"

第四步：組裝會談判的工作流 (Cyclic Graph)
現在，我們把這些節點用 ADK 的 Workflow 連接起來。這不再是一條直線的流水線，而是一個具備「迴圈與例外逃脫能力」的高級圖結構。

from google.adk import Workflow

campaign_workflow = Workflow(
    name="Conflict_Resolution_Workflow",
    state_schema=CampaignState
)

# 定義基本節點
campaign_workflow.add_node(marketing_agent)
campaign_workflow.add_node(legal_agent)

# 定義起點
campaign_workflow.set_entry_point("marketing_agent")

# 定義行銷寫完後，交給法務
campaign_workflow.add_edge("marketing_agent", "legal_agent")

# 【核心魔法】定義法務審核後的動態條件路由
# 它會根據 review_router 函式的回傳值，決定走向 END、重回行銷、或是進入 human_intervention
campaign_workflow.add_conditional_edges(
    source="legal_agent",
    routing_function=review_router,
    path_map={
        "END": "END",
        "marketing_agent": "marketing_agent",
        "human_intervention": "human_intervention_node" # 升級給人類
    }
)

小結
「沒有邊界的自動化，就是一場災難。」

今天，我們透過 ADK 的 State 管理與 Conditional Edges，成功解決了 Multi-Agent 系統中最可怕的無窮迴圈問題。Agent 之間現在可以為了品質進行談判，但當他們「吵不出結果」時，系統懂得踩下煞車，將問題升級 (Escalate) 給人類。