生成式協調流程是 Copilot Studio 的智慧大腦,它讓代理程式能夠自動判斷「該找誰幫忙」來回答使用者問題——就像一位經驗豐富的客服主管,能快速決定該查知識庫、呼叫工具、還是轉給專業團隊處理。
想像一下,傳統的客服機器人就像「按關鍵字查字典」,當使用者說「天氣」就翻到「天氣」那一頁,使用者說「訂單」就翻到「訂單」那一頁。
但生成式協調流程不一樣,它更像一位真正理解對話的助理,能夠進行以下幾點的事情
理解上下文:當使用者問「柯克蘭的商店營業時間」後接著問「那裡的天氣如何」,系統會知道「那裡」指的是柯克蘭。
智慧組合資源:可以同時查詢知識庫、呼叫天氣 API、觸發庫存檢查主題,然後把所有訊息整合成一個完整回答。
自動補充訊息:如果發現缺少必要參數(例如地址、日期),會自動生成問題向使用者詢問,而不需要製作者預先設計每個問答流程。
生成式協調流程建立在 Microsoft Copilot Studio 的 AI 協調引擎之上,這個引擎與 Microsoft 其他 Copilot 產品(如 Microsoft 365 Copilot)共享相似的技術基礎。
參考來源
三層協調架構:
計劃生成層(Planning Layer):系統分析使用者查詢後,檢視所有可用的主題(Topics)、工具(Tools)、其他代理程式(Agents)和知識來源(Knowledge Sources)的名稱、描述、輸入和輸出元資料,然後建立一個執行計劃。
執行層(Execution Layer):按照計劃的順序執行每個步驟,可能包括搜尋知識來源、呼叫 API、觸發主題或委派給其他代理程式。
回應生成層(Response Generation Layer):將所有執行結果彙整後,生成一個符合上下文、自然流暢的回應給使用者。
參考來源
與傳統協調的差異:傳統協調流程(Classic Orchestration)依賴「觸發短語匹配」——製作者必須為每個主題預先定義大量觸發短語範例,系統透過自然語言模型找到最匹配的主題。而生成式協調流程則是基於語義理解與意圖推理,透過描述來判斷哪些資源最適合處理當前任務。
操作步驟
代理程式現在會切換到傳統協調流程模式,依賴觸發短語來匹配主題。
開啟方式為以下三個步驟
測試流程
1.在測試面板的輸入框輸入問題(例如「如何運用設計思維提升 Copilot Studio 的使用效益?」)
2. 發送訊息後,Activity Map 立即顯示系統生成的執行計劃
3. 每個步驟會以**節點(Node)**呈現在視覺化圖表中
另外一種類型的提問法,這時候生成式協調的特色同樣會拆解成多步驟的查詢,接著再統整所有資訊後提供最終版本的答案。
我要了解如何從 Copilot Studio 的 Lite 版升級成 Full Experience,並整合進 Teams。
請以「複雜查詢分解」的方式分析這個問題,拆解出涉及的子領域(授權、環境設定、整合、測試),並依序回答。
在 Copilot Studio 的協調式生成架構中,描述(Description)已成為新時代的「宣告式程式碼」,不僅只是系統理解意圖的唯一入口,更是決定 AI 協調精準度的關鍵變數。
傳統程式碼定義「如何執行」,而描述則定義「為何選擇」。
所以隨著這樣概念的功能逐漸成熟發展的過程中,我們要做的事情就是在定義指令或者是輸入問題時,都需要把目標描述清楚以及越抽象的資訊要更主動補充更多的背景資訊。