Solution Graph 的主要功能是什麼？
某企業建置 Agentic AI 系統處理跨部門複雜任務，團隊以解決方案圖譜（Solution Graph）作為規劃框架。下列何者為 Solution Graph 的主要功能？
某企業建置 Agentic AI 系統處理跨部門複雜任務，團隊以解決方案圖譜（Solution Graph）作為規劃框架。
問你：Solution Graph 的主要功能是什麼？
一句話總結
Solution Graph 是一張「任務地圖」，定義 AI 代理在面對複雜任務時可以參考的任務分解方式與決策路徑結構，幫助代理知道「可以怎麼走」。
先感受問題：複雜任務沒有地圖，AI 代理怎麼走？
假設你是「遠見科技」集團的 AI 架構師，老闆交辦一個任務：建立一個 Agentic AI 系統，處理「供應商合約審查到付款完成」這個跨越採購部、法務部、財務部的流程，每個步驟都有多個可能的情況（如：合約有爭議 → 要退回修改、合約通過 → 送審核、金額超過 100 萬 → 需要財務長簽核）。
如果沒有任何規劃框架，AI 代理面對這個複雜任務時，不知道有哪些可能的路徑，也不知道哪些步驟是必要的、哪些是條件性的。它可能跳過法務審查直接付款，或在某個步驟卡死不知道怎麼往下走。
Solution Graph 就是為了解決這個問題：用圖形的方式，把任務的所有可能分解方式和決策路徑畫出來，讓代理有一個「可以參考的地圖」。
沒有 Solution Graph，Agentic AI 會遇到哪些問題
- 任務分解混亂：AI 代理不知道一個大任務應該拆成哪些子任務，可能跳過重要步驟或重複做同樣的事
- 決策路徑不清：遇到分叉（如「合約有爭議怎麼辦」），代理沒有參考框架，只能隨機選擇或卡住
- 跨代理協作困難：多個代理（採購代理、法務代理、財務代理）之間不知道彼此的任務邊界和交接點
- 無法追蹤進度：沒有清晰的任務結構，整個系統不知道現在走到哪一步，做了哪些、還有哪些沒做
- 錯誤難以診斷：如果結果有問題，沒有結構可以回溯，不知道哪個環節出了問題
Solution Graph 怎麼提供「任務地圖」
「遠見科技」的架構師用 Solution Graph 畫出合約審查流程：
節點（Nodes）代表子任務：「收到合約」「法務初審」「修改回傳」「採購審核通過」「財務簽核」「付款執行」，每個節點是一個具體的任務步驟。
邊（Edges）代表決策路徑：「法務初審通過 → 採購審核」、「法務初審有問題 → 退回修改 → 重新提交」、「金額超過 100 萬 → 財務長簽核」，每條邊定義了從一個節點到下一個節點的條件和路徑。
AI 代理在執行任務時，以 Solution Graph 作為參考框架，知道「現在在法務初審節點，如果通過就走 A 路徑，如果有問題就走 B 路徑」。代理有了地圖，執行複雜任務的準確性和連貫性大幅提升。
這就是選項 D 講的：定義代理可參考的任務分解與決策路徑結構。
技術版：Solution Graph 在 Agentic AI 架構中的位置
Solution Graph 的本質：Solution Graph 是一種有向圖（Directed Graph）或有向無環圖（DAG, Directed Acyclic Graph），其中節點代表子任務或決策點，邊代表任務間的依賴關係或決策條件。它是 Agentic AI 系統的「任務規劃層」，介於「整體目標」和「具體執行步驟」之間。
Solution Graph vs 固定流程（Hard-coded Workflow）：固定流程是「你只能這樣走」；Solution Graph 是「你可以這樣走，也可以那樣走，根據狀況選擇」。前者剛性但可預測；後者彈性但需要更複雜的設計。Solution Graph 提供結構但保留代理的自主性。
在 Multi-Agent 系統中的應用：當多個 Agent 協作時，Solution Graph 明確定義每個 Agent 負責哪些節點、交接點在哪裡。這避免了 Agent 之間互相等待、重複工作、或遺漏交接的問題。
為什麼出題者要考這題：Agentic AI 和多代理系統是 2024-2025 年 AI 應用的最前沿，AI 應用規劃師需要理解這類系統的規劃框架。Solution Graph 是其中一個重要概念，考的是對「結構化任務規劃」的理解。
為什麼其他選項是錯的
A取代語言模型推理機制，改以圖形搜尋完成決策
Solution Graph 把 LLM 的推理能力換掉，直接用圖形搜尋演算法做所有決策。
Solution Graph 不是為了「取代」LLM，而是提供給 AI 代理參考的任務結構框架。LLM 仍然負責語言理解、推理和生成；Solution Graph 提供的是「任務路徑的可能性」，兩者是協作關係，不是替換關係。
對 Solution Graph 的技術細節不熟悉，誤以為「用圖形就是不需要語言模型」的人。實際上圖形結構和語言模型是互補的，不是替代關係。
B作為任務知識庫，用於儲存 AI 已完成案例以供檢索
Solution Graph 是個資料庫，把 AI 做過的案例存起來，讓 AI 之後遇到類似任務時可以搜尋參考。
這描述的是「案例庫（Case Base）」或「知識庫（Knowledge Base）」的功能，不是 Solution Graph。Solution Graph 是結構化的任務分解框架，不是用來存儲已完成案例的資料庫。
把「圖譜（Graph）」聯想成「知識圖譜（Knowledge Graph）」的人，以為 Solution Graph 就是一種儲存知識的圖形資料庫。兩者雖然都用圖形，但目的完全不同。
C限制代理（Agent）僅能依固定流程執行，以降低行為不確定性
Solution Graph 鎖定代理只能走一條固定路線，不讓它自由發揮，以控制風險。
Solution Graph 的設計理念是提供「可參考的路徑結構」，而不是「強制鎖定唯一路徑」。Graph（圖）的本質就是有多個節點和多條邊，代表多種可能路徑。限制代理只走固定流程是 Hard-coded Workflow 的做法，不是 Solution Graph 的定義。
把「結構化規劃」等同於「固定流程」的人。提供結構和限制自由度是不同的，Solution Graph 提供的是可能路徑的地圖，不是強制執行路線的鎖鏈。
同個考點下次怎麼變形
Agentic AI 和普通的 AI 助理有什麼本質區別？
都是 AI，Agentic 有什麼特別？
普通 AI 助理回答單一問題；Agentic AI 能自主規劃和執行多步驟任務，包含：分解複雜目標為子任務、呼叫工具取得外部資訊、根據執行結果調整後續步驟。Agentic AI 有「目標導向的自主性」，不只是回應問題，而是主動推進任務完成。
在多代理（Multi-Agent）系統中，不同代理之間如何知道彼此的職責邊界？
多個 AI 代理一起工作，怎麼確保不會互相踩踏或遺漏任務？
透過清晰的任務分工設計，如 Solution Graph 中定義哪個節點由哪個代理負責，以及節點之間的交接條件。每個代理只負責自己的節點，完成後依據 Solution Graph 觸發下一個代理接手。清晰的邊界定義是多代理系統協作成功的關鍵。
Solution Graph 中的「節點」和「邊」分別代表什麼？
圖形結構中節點和邊的定義是什麼？
在 Solution Graph 中，節點（Node）通常代表子任務、決策點或系統狀態；邊（Edge）通常代表任務間的依賴關係、觸發條件或轉換規則。例如：「法務審查節點」→（通過條件）→「採購確認節點」。邊上可以帶有條件，實現條件式的任務路徑選擇。
如果企業只有一個 AI 代理處理所有任務，還需要 Solution Graph 嗎？
只有一個代理，還需要複雜的圖形規劃嗎？
單代理系統仍然可以受益於 Solution Graph，特別是當任務本身複雜、有多個可能路徑時。Solution Graph 幫助單一代理有結構地分解任務、追蹤進度、在多種可能路徑中做出有依據的選擇。任務越複雜，規劃框架就越重要，不論代理數量多少。
Agentic AI 系統的「行為不確定性」問題如何處理？
AI 自主決策聽起來很方便，但萬一做錯怎麼辦？
常見做法包括：透過 Solution Graph 定義可接受的路徑範圍（有結構但保留彈性）、設定人工確認（Human-in-the-loop）檢查點、記錄所有決策過程以便事後審查、設定高風險操作的二次確認機制。不是用固定流程消除所有不確定性，而是在可控範圍內讓代理發揮。
想再往下看，這 5 個
- 多代理系統（Multi-Agent System）多個專門化代理協作完成複雜任務，Solution Graph 在其中定義各代理的任務節點與交接條件，是協作成功的關鍵
- AI 代理（AI Agent）能自主規劃、使用工具、執行多步驟任務的系統，Solution Graph 提供其可參考的任務分解地圖而非固定鎖死路徑
- 人機迴路（Human-in-the-Loop）在 Agentic AI 關鍵決策點加入人工審核，Solution Graph 可標記哪些節點需要人工確認，平衡自動化效率與監督
- 流程協調（Orchestration）協調多個代理或工具按照規劃框架依序執行任務，Solution Graph 是 Orchestration 的視覺化規格依據
- 規劃（Planning）代理將複雜目標分解為可執行子任務並選擇執行路徑的能力，Solution Graph 就是將規劃結果結構化為可參考圖譜