本指南提供一個起點，幫助你理解建構 AI 應用程式或 AI 代理的完整生命週期。 在本指南中，「AI agent」是涵蓋生成式 AI 驅動系統的總稱，包括簡單的 LLM 呼叫、AI 函式及基於代理的實作。
開發生命週期概述
1. 了解使用案例、範圍及成功指標
在建立任何東西之前，先釐清 AI 代理的用途。 與利害關係人達成共識，包括那些將簽署部署到生產環境的人。
- 代理會處理哪些類型的輸入（「領域」或「範疇」）？ 哪些使用者會提交輸入？
- 代理人理想上應該如何回應常見輸入？ 應該使用哪些資訊或背景？
- 哪些標準定義了良好的或不好的回應：語氣、準確性、完整性、回應長度、安全性、引用或其他要求？
- 生產環境中有哪些系統需求與限制：成本、延遲與可擴展性？
- 有哪些潛在的失敗模式？客服應該如何處理：錯誤的使用者輸入、資訊不足以回答、使用者反饋顯示錯誤答案，或其他情況？
選擇最簡單且可行的方法。 許多使用情境不需要複雜的代理系統或多代理系統。 在建造前，評估你的問題在複雜度連續體中的位置。 簡單的確定性邏輯或批次 AI 函式會足夠嗎？ 如果需要動態工具呼叫、推理或協調，則可考慮工具呼叫代理或多代理系統。 欲獲得更深入的指引，請參閱代理系統設計模式。
這個基礎讓你能夠：
- 找出你的經紀人所需的資料來源和工具
- 撰寫反映預期行為的初始指令或提示
- 找出能提供代表性範例與早期回饋的領域專家或測試人員
- 建立自動化評審，編碼評量標準並加速迭代
此階段不需要完全清晰，隨著反覆迭代，理解也會逐漸提升。 但更早的一致性，特別是在品質衡量方式及「生產準備」的定義上，會讓後續品質改進和核署速度大幅加快。
2. 建立初始的 AI 代理
當你的使用情境和目標明確後，你就可以開始原型設計你的 AI 代理。 Databricks 提供導引式 UI 導向路由及完全客製化、基於程式碼的 AI 代理建置路徑。
2.1. 準備資料與工具
AI 代理人通常利用資料和工具來提供上下文與能力。 請參閱 AI 代理工具 ，了解如何在 Databricks 上與資料及工具合作。
在建立新資料前，先搜尋現有資料與工具：
- 在 Unity Catalog 或 工作區搜尋 中查看可用的資料，以了解哪些管控中的資產已經存在。 這有助於你在建立新資產前，了解可用的上下文與功能。
- 在 AI Playground 中，你可以查看並選擇代理已可用的工具，例如向量搜尋索引、MCP 伺服器或 UC 函式。
根據需要建立並管理新資產：
- 準備並提供 結構化資料 或 非結構化資料。
- 使用管理型或外部 MCP 伺服器來建立簡單或複雜的工具。
所有這些資料資產與工具皆由 Unity Catalog 管理與版本管理，使其可於 AI 代理與應用程式間被發現並重用。
2.2. 建置初始代理程式
在建立客製化代理前，評估宣告式 Agent Bricks 或現有的 Databricks 解決方案加速器 是否符合您的使用情境。 對於常見模式，這些引導式方法能大幅減少設置、提升預設品質，並加速生產時間。
如果仍需客製化代理，新建商應該從最快的實驗方式開始。 使用 AI Playground 在 不寫程式碼的情況下原型化代理。 AI Playground 讓你能嘗試不同模型、進行提示工程和測試工具，快速了解資料品質、代理人行為以及你方法的潛力。 接著你可以將代理匯出成程式碼，方便進一步客製化和迭代。
如果你已經有代理程式碼，可以 把現有程式碼帶到 Databricks 並部署成 Databricks 應用程式。
在建立代理時，請提前規劃評估與生產環境：
- 使用 MLflow 追蹤 工具為您的客服人員進行監控，以記錄並分析客服人員的行為。
- 此階段，重點在於功能正確性：確保代理端到端運作，並能存取所需的資料與工具。
- Vibe 檢查早期問題，例如工具選擇錯誤、缺乏上下文或幻覺。
- 之後，這些痕跡將用於評估藥劑品質。
- 在實作過程中，請考慮 適合您生產應用程式的正確認證方法。
3. 反覆調整 AI 代理的品質
當有一個可運作的原型存在後，下一階段是一個緊密的循環，持續進行測量、理解與提升品質。 Databricks 將 MLflow 評估 置於此迴圈的中心位置，並由 MLflow 跟蹤、評估數據集及大型語言模型評判支援。
自動化評分器與大型語言模型評審提供規模與一致性，但 人工回饋 對於驗證實際實用性及理解細微失誤至關重要。 人類回饋也指導LLM評審的開發與校準。 隨著代理人的成熟，人類回饋通常分為三個階段：
- 早期開發者與利害關係人驗證
- 更廣泛的領域專家評測
- 最終使用者回饋
3.1. 驗證早期行為
開發者與少數利害關係人或領域專家能提供快速且早期的回饋。 在進行大規模測試和評估之前，先確認代理程式在最明顯的情況下執行正確的操作。
在原型製作過程中，開發者常會透過手動查詢代理程式，進行非正式的「氛圍檢查」，以確認其端對端運行且行為如預期。 透過 MLflow 追蹤介面， 開發者可以直接將回饋或期望附加 於追蹤圖，以標示品質問題、標記成功範例，並記錄筆記以供未來評估與迭代使用。
部署內部原型後， Review App 聊天介面 提供簡單的回饋收集介面。 將你原型的聊天介面分享給一小群開發者或領域專家，讓他們能提出合理或有問題的問題。
MLflow 追蹤記錄互動與回饋，建立初步結果資料集。 利用 MLflow UI 或程式碼分析追蹤 ，以了解代理的效能與行為。 當結果不佳或有非預期結果時，請透過追蹤進行除錯：
- 分析代理人的品質問題，例如工具誤用、幻覺或缺乏上下文。 應用修正，例如提示調整、工具使用或數據。 參見 3.4。修正問題並重新驗證改進。
- 在反覆迭代時，你可以將追蹤資料集作為代表性的使用者輸入，為新原型產生追蹤。
- 重複這個循環：執行、檢查、修正、再執行，直到代理能如預期處理全部或大部分代表性輸入。
- 未來的版本可能會發現並解決更多問題。 品質提升是反覆進行的，並不限於這個早期階段。
完成此步驟後，您可以放心原型在常見情況下表現合理，並達到合理的品質水準，然後再投入更廣泛的測試。
3.2. 擴展測試與回饋
原型在簡單案例中成功運作後，透過擴大測試者陣容並收集更多客製化回饋，擴大品質評估。 此階段揭示盲點，如意料之外的主題、誤解的查詢、工具與檢索缺口，或新興的使用模式。 它也能擴充你的評估資料集。
- 將應用程式推廣給更廣泛的利害關係人與領域專家，或是進行最終用戶的測試。 隨著客服接觸更廣泛的使用模式，納入他們的回饋。
- 利用自訂架構的 Review App 標籤會議 ，收集更詳細的回饋與期望，供專家回饋。
- 透過同步人類回饋與標記痕跡來建立 評估資料集 ，為下一步的系統性評估與監測做準備。
- 為了進一步豐富評估資料集，可以考慮 產生合成評估集。
3.3. 評估品質並系統性除錯
隨著評估資料集越來越大且多元，你需要更有結構且自動化的方法來偵測問題、揭露最重要的故障，並理解根本原因。
實務上，你很可能會將資料分為兩種評估資料集：
- 迴歸測試：具備高品質 AI 回應的資料有助於定義預期行為。 利用這些資料集來驗證新版本代理在廣泛且多元的預期情境下持續良好表現。
- 以問題為中心的除錯：AI 回應品質低劣的資料可能包含各種不受歡迎的行為。 分離出表現出相同低品質行為的痕跡群組，這樣你才能了解根本原因並持續針對性修正。
以下工具有助於建立並分析這兩種評估資料集。
執行迴歸測試
- 透過選擇具有高品質 AI 回應或人類預期的代表性資料子集，建立迴歸測試。
- 利用 內建或自訂的大型語言模型評審與評分工具，定義評估標準。 自動化評估可以僅使用 LLM 來評估回應品質，或是將回應與實際的回應或預期做比較。
- 對新版本的代理執行評估，確保更新不會破壞先前良好的行為。
辨識低品質回應類型
- 利用 自動化評估 與 人工回饋 ，找出客服人員反應不佳的例子。
- 透過評審分數或使用者回饋過濾並分析 MLflow 追蹤，以隔離出有問題的互動。 透過特定的法官和自訂的回饋模式，你可以分離出特定類型的問題，例如幻覺、缺乏上下文或無關的回應。
- 針對代理式除錯，你可以使用 MLflow AI Insights ，或將自己的代理連接到 MLflow MCP 伺服器。
提升自動偵測的準確度
雖然你可以開始以主要的人類回饋來建立評估資料集，但你可以透過自動化偵測來擴展評估。 在反覆迭代時，投資於針對你的應用和領域量身打造的 LLM 評審或基於程式碼的評分器。
- 先從 內建裁判開始，視需要加入 自訂裁判 和 程式碼計分器 。 當你觀察到內建評審無法捕捉到的故障模式時，你可以用專門設計的裁判或評分器自動化未來偵測該類型失效。
- 利用人工回饋，將客製化評審與專家理解對齊 。 調整評審以減少假陽性與假陰性，將提升對自動評估與分流的信任度。
- 你的新評審和評分員既可用於自動評估與監控，也能過濾痕跡以建立除錯資料集。
有效解決根本原因問題
在發現故障後，你需要找出原因。
-
使用 MLflow Tracing 手動檢查代理推理的每個步驟：
- 已選擇的工具有哪些
- 工具輸入與輸出的使用方式
- 檢索是否回傳了相關脈絡
- 模型回應如何影響後續決策
- 運用 MLflow AI 洞察 或代理人 作為評判 來分析痕跡，並指出可能的原因，例如基礎不足、提示結構不佳或工具參數錯誤。
- 在 MLflow 的評估介面中比較不同版本，看看問題是否會倒退或持續存在。
這個步驟理想的結果是對哪些系統失效、為何失效以及如何修正有結構的理解。 自動化和應用專屬判斷工具使你能自信地進行迭代，隨著智能代理變得更強大、測試集越來越複雜。
3.4. 修正問題並重新驗證改進
正如問題是應用程式特定的，修正也必須依你的應用量身訂做。 常見的修復範例包括：
- 提示優化：手動優化代理的指示，或使用 數據驅動的提示優化。 對於更廣泛的代理優化，如調整多步驟推理或工具使用，請使用 DSPy 調整。
- 工具與資料：當痕跡顯示缺失事實或基礎不足時，改善工具或檢索流程。
- 路由：當追蹤記錄顯示工具和子代理呼叫錯誤時，需要改進工具或代理的元資料、提示或路由模型。
- 防護措施：當回應違反安全規範或洩漏資訊時，請在您的代理中使用 AI 閘道防護 或客製化防護措施。
- 備援：透過備援機制（如替代 API 端點或備援回應）優雅地處理極端情況、資料遺失或 API 呼叫失敗。
在反覆修正時，使用 應用程式版本控制 和 提示登錄 檔來記錄版本，方便比較和回歸測試。
每個針對提示、檢索、工具、資料或其他代理部分的修正，都應該像發現時一樣驗證。 請在相同的評估資料集上重新執行新的代理版本，以確認問題已解決且沒有引入迴歸。
4. 在生產前與利害關係人達成共識
在將代理人員投入真實環境之前，團隊需要共同了解其現有能力、限制及品質測量。 要達到這個階段，通常需要多次迭代並在 第三步進行品質提升。 此階段，將技術訊號（如評估指標、系統指標及範例追蹤）轉換成最終決定客服人員是否真正「準備好」的業務情境。
- 將評估結果轉化為明確的商業訊號：摘要準確性、穩定性、安全性及已知限制，並以利害關係人可採取行動的方式呈現。
- 確認標準化品質檢查是否達成：確保候選版本符合所需的評估指標、迴歸檢查及資料集覆蓋門檻。
- 驗證作戰準備並取得批准：檢視監控設置、護欄及部署計畫。 在生產前記錄風險與驗收標準。
5. 投入生產並持續監控品質
達到量產是一個重要的里程碑！ 這代表代理人已經準備好面對真實用戶和真實影響。 同時，生產同時也是新一輪的開始。 代理上線後，進入持續監控與改進階段，因為實際使用會揭露新的行為、邊緣案例與問題。
- 在生產環境中收集終端用戶的回饋。 將使用者回饋連結至特定痕跡，以便與模型行為一併分析。 你可以透過將回饋記錄為附加在原始追蹤上的評估來達成。
- 善用 AI Gateway 進行保護措施、路由與一致的記錄。 確保每個新的代理版本都能與真實流量進行評估，且不會產生操作上的阻礙。
- 透過對抽樣的生產痕跡進行評估，監控即時流量的品質。 確認新版本的效能至少和之前版本一樣好，並隨著使用者提交新類型的查詢，留意是否有新的問題。 持續監控能讓客服人員可靠、安全，並隨著業務需求不斷演進而保持一致。 MLflow 提供監控儀表板，但由於 追蹤可以儲存在 Unity 目錄中，你可以自訂儀表板和警示：
- 建立 自訂儀表板 ，以便監控並與業務利害關係人分享。
- 設定 Databricks SQL 品質警示 ，以偵測故障或新興問題。
- 根據生產洞察採取行動：
- 對於高風險的使用案例，應將監控與自動化或閘控回滾機制連結，以解決關鍵問題。
- 在下一次迭代中運用你的生產洞察。 將現實世界的失敗轉換成新的評估資料，然後回到 評估與除錯循環 ，打造下一個更好的代理程式版本。
下一步
- Azure Databricks 生成式 AI 功能 - 檢視 Azure Databricks 平台對代理與生成式人工智慧的功能
- 代理系統設計模式 - 了解從簡單到複雜的代理
- 入門：使用大型語言模型進行免程式碼的查詢及原型化 AI 代理 - 使用 AI Playground 設計代理原型