今天要來看另一種多 Agent 的應用，Magentic Orchestration 是一種「由一位 Magentic Manager 依情境動態指派、協調多位專家代理」的多代理協作模式。過程中會維護共享脈絡（context）、追蹤進度、反覆拆解子任務，並在流程中決定下一位應出手的 Agent 代理，Magentic Orchestration 適合解題路徑一開始不確定、需要經過多輪推理 / 搜尋 / 計算的任務。這類任務往往需要多個角色的協同合作，相對的也增加了協調的複雜度，尤其是沒有絕對順序流程的情況下。就像人類社會中常見的團隊合作一樣，有不同角色的人一起協同工作完成任務，但在這個過程中，每個角色的目標和優先順序可能不同。
個人或公司品牌在面對公關危機時，往往需要迅速且有效的回應，以減少負面影響並恢復信任。這個過程通常涉及多個角色的協同合作，包括危機管理專家、法律顧問、溝通專家等。透過 Magentic Orchestration，可以模擬這種多角色協作的情境，讓不同的 Agent 貢獻各自的專業知識和觀點，然後產生更全面和有效的危機應對方案。
dotnet add package Microsoft.SemanticKernel.Agents.Magentic --prerelease
首先，需要定義每個 Agent 的角色和職責：
var socialIntelAgent = new ChatCompletionAgent
{
Name = "SocialIntelAgent",
Description = "跨事件的社群情資彙整：時間軸、議題標籤、擴散節點、風險清單與可信度。",
Instructions = """
你是社群輿情分析師。請整理：
- 事件時間軸（要點式，避免冗長）
- 議題標籤（抽象化：產品/資料/道德/誤導/歧視/合約…）
- 擴散節點（平台/社團/影響者類型），不揭露個資
- 高風險話題清單（每點附「風險說明」與「可信度 0–1」）
- 來源摘要（以「來源類型＋一行摘要」呈現）
- 即刻止血建議（1–3 條，務實、可操作）
文風：簡明、客觀；避免情緒與評論人物動機。
""",
Kernel = kernel
};
var factCheckAgent = new ChatCompletionAgent
{
Name = "FactCheckAgent",
Description = "將可驗證事實與指控/傳聞分離，輸出已知/未知矩陣與 MSV。",
Instructions = """
你是事實校對專家，負責把「可驗證事實」與「指控/傳聞」分開。請輸出：
- 已知（可驗證事實，含來源類型）
- 未知（待查證/需補資料）
- 爭議點（列出雙方/多方主張）
- MSV（Minimum Supportable Verbiage，最小可支持說法）：一段最保守且可被證實的陳述
原則：不做法律認定；不評論個人動機。
""",
Kernel = kernel
};
var legalAgent = new ChatCompletionAgent
{
Name = "LegalAgent",
Description = "法律與合規風險審校，提供安全替代表述；不作責任認定。",
Instructions = """
你是法務/合規審校。請檢查草稿並回傳：
- 風險標記：誹謗、歧視、廣告法、消保、著作權、個資、平台條款等
- 需調整字句（逐點列出「原句 → 安全替代表述」）
- 注意事項（例如：避免承諾不可控結果、避免認定法律責任）
回覆規則：若有問題，直接附上「修正文版本」；若無，回覆「可發布」並列注意事項。
""",
Kernel = kernel
};
var trustAndSafetyAgent = new ChatCompletionAgent
{
Name = "TrustAndSafetyAgent",
Description = "信任與安全優先處置：個資、未成年、危害風險的即刻降載步驟。",
Instructions = """
你是 Trust & Safety。若偵測以下任一項，請優先處置：
- 個資外洩、未成年、仇恨/煽動、身心安全、醫療/金融誤導
- 平台規範重大違規、惡意操縱
請輸出：
- 風險等級（高/中/低）與理由
- 即刻降載步驟（下架、遮罩、關閉互動、限縮觸及…）
- 後續治理建議（人審升級、紀錄保存、證據蒐集）
原則：安全優先於口碑；最小必要揭露。
""",
Kernel = kernel
};
var strategyAgent = new ChatCompletionAgent
{
Name = "StrategyAgent",
Description = "反應模式與管道節奏規劃，輸出受眾分層與 KPI。",
Instructions = """
你是策略規劃。基於「嚴重度 × 可控性」選擇反應模式：
- 模式：Hold / Apology / Clarify / Investigate / Correct & Commit / No Comment (with Rationale)
請輸出：
- 受眾分層（工程師社群/一般使用者/媒體/既有客戶…）
- 渠道與節奏（官網、X/FB/IG/YT、內外同步/先內後外…）
- KPI 與監測指標（降溫速度、錯誤訊息更正率、轉傳/互動下降、客服轉單率）
- 風險備援（若惡化：升級誰、關閉什麼、走法律程序等）
""",
Kernel = kernel
};
var prAgent = new ChatCompletionAgent
{
Name = "PRAgent",
Description = "聲明與社群短版撰寫，附 QA 要點；避免不可控承諾與攻擊性語言。",
Instructions = """
你是公關寫手，請產出「三件套」：
A) 正式聲明（Holding Statement）：同理、重視、調查/修正承諾（可驗證時程/窗口），避免承認法律責任
B) 社群短版：X/FB/IG 可直接貼（口吻簡潔），連結完整聲明或客服表單
C) QA 要點（3–6 條）：給客服/門市/媒體應答
文風：專業、克制、尊重；不攻擊個人、不轉貼個資。
""",
Kernel = kernel
};
var communityAgent = new ChatCompletionAgent
{
Name = "CommunityAgent",
Description = "將聲明轉為各平台貼文格式，並給互動守則（禁回清單/升級條件）。",
Instructions = """
你是社群營運。請依「既定聲明」轉為：
- X/FB/IG/YT 貼文（各自合適長度與格式）
- 互動守則：禁回清單（法律爭議、個資、醫療/財務建議…）、升級條件（什麼情況交由法務/關閉留言/僅客服應對）
- 監看節奏：回覆 SLA、關鍵字警示
原則：避免與個人筆戰；尊重社群規範與隱私。
""",
Kernel = kernel
};
接著，建立 Magentic Manager，並將上述 Agent 加入管理。
// 管理Agent（Magentic）：讓他決定下一位該出手的人
var chat = kernel.GetRequiredService<IChatCompletionService>();
var manager = new StandardMagenticManager(chat, new OpenAIPromptExecutionSettings())
{
MaximumInvocationCount = 5 // 防止無止境來回
};
// 建立 Magentic 協作流程
var orchestration = new MagenticOrchestration(
manager, socialIntelAgent, factCheckAgent
, trustAndSafetyAgent, strategyAgent, prAgent
, legalAgent, communityAgent
);
最後，執行 Magentic Orchestration，並輸入公關危機的相關資訊。
// 建立協作流程物件
InProcessRuntime runtime = new();
// 任務描述
string task =
"""
你是危機協調 Manager。依下述「事件輸入模板」動態調度專家完成[任務目標]。
1) 起手：先 SocialIntel → FactCheck 取得「議題圖譜 + 已知/未知矩陣」與 MSV。
2) 若偵測下列任一高風險：個資/未成年/仇恨/醫療/金融/安全/重大違規 → 立即插隊 TrustAndSafety。
3) 若文字涉及法律或責任承諾、或有索賠爭議 → 插隊 Legal。
4) 交由 Strategy 選擇反應模式與渠道節奏、定 KPI 與備援。
5) 要求 PR 產出三件套；再由 Legal 最終審字；最後交 Community 生成平台化貼文與互動守則。
6) 任一階段若暴露新風險或資訊缺口 → 回到相應專家補強（非線性迭代）。
輸出需包含：正式聲明、社群短版、QA 要點。
[事件簡述]
- 本人素來以 AI「vibe coding」推廣建立其專業講師型象，然而示範開發時未檢測程式碼及理解平台服務，將平台金鑰硬寫在程式中，導致被正常計費。
- 事後於社群指控「平台有 bug」並要求退款；工程師社群指證為金鑰誤用。
- 本人反覆發文不認錯，引發 #甩鍋 #割韭菜 等負評與迷因。
[假設與限制]
- 不揭露個資，不攻擊個人。
- 不承認法律責任；可承認流程不周、將改善教學與警示。
- 文風：專業、克制、尊重；避免技術傲慢與情緒化。
[受眾與管道]
- 管道：官網公告、X/FB/IG/YouTube 社群、客服話術。
- KPI：負評增速降溫、錯誤訊息更正率、轉傳與互動下降、客服轉單比率。
[任務目標]
- 正式公關聲明
- 社群短版本貼文
- QA 要點
""";
await runtime.StartAsync();
var result = await orchestration.InvokeAsync(task, runtime);
string final = await result.GetValueAsync(TimeSpan.FromSeconds(180));
Console.WriteLine("===== 最終輸出 =====");
Console.WriteLine(final);
===== 最終輸出 =====
【A) 正式聲明（Holding Statement）】
感謝社群及廣大用戶關注本平台近期「API 金鑰使用與計費」相關議題。經過全面查核，本平台的計費與安全機制皆依規格設計並正常運作。近期案例中，用戶於公開示範過程將 API 金鑰嵌入程式碼，導致金鑰暴露與系統依規則計費。平台本身運作無異常。
我們理解用戶於操作及教學流程中的期待，將加強 API 金鑰管理之教學資源，並優化警示提醒，協助用戶減少潛在風險。對於因操作疑慮產生的不便，歡迎透過客服信箱／表單與我們聯繫，由專人協助查詢使用明細及提供建議。
本平台將持續傾聽用戶需求及社群回饋，不斷精進資訊安全與教育責任。如有任何疑問，請至 https://www.example.com/support 查詢詳細公告與聯絡方式。我們承諾於七個工作天內回應相關查詢。
【B) 社群短版（X/FB/IG 可直接貼）】
針對近期 API 金鑰與計費討論，我們確認平台機制正常，金鑰安全請務必妥善管理。教學與提醒會持續優化，有疑慮請私訊客服，我們一起協助查詢。完整說明 bit.ly/xxx #API安全 #資訊責任
【C) QA 要點（給客服/門市/媒體應答）】
1. Q：有人認為平台有bug，計費有問題，是真的嗎？
A：平台經全面檢查，各項計費與安全機制均正常。近期主要是用戶操作時將金鑰公開，導致正常計費。
2. Q：為什麼會額外被收費？
A：若將金鑰暴露於公開程式碼或網頁，系統會據實記錄相關用量並依標準收費，請用戶妥善管理個人金鑰。
3. Q：平台未來會有什麼改善？
A：我們將強化 API 金鑰管理的教學及操作警示，避免類似情形發生，降低用戶誤會及流程落差。
4. Q：有退款或賠償的機會嗎？
A：如對用量有疑慮，歡迎聯繫客服專員協助診斷。平台將根據實際狀況協助查核。
5. Q：如果我不確定金鑰用量或安全操作方式怎麼辦？
A：可至官網查詢金鑰管理教學，或直接聯繫客服，我們會提供操作協助與使用指引。
今天介紹了 Magentic Orchestration 的概念與實作，並透過公關危機應對的範例，展示了如何利用多 Agent 協同合作來解決複雜的問題。根據我的經驗，Magentic Orchestration 是 semantic kernel 中最靈活且強大的多 Agent 協作模式，適合用於需要多角色協同、動態決策的情境，但相對的也是最不穩定的，需要不斷的調整與優化。希望這個範例能啟發大家在專案中應用 Magentic Orchestration，解決更多複雜的挑戰。
iThome鐵人賽
看影片追技術