本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 不斷發展代理式 AI 的軟體交付
現代軟體交付已透過簡單假設來塑造，您可以控制您運送的系統。您可以定義需求、撰寫邏輯、針對預期結果進行測試，以及部署可預測的服務。即使敏捷和 DevOps 方法仍然依賴於每個衝刺提供決定性、可驗證且主要在人為監督範圍內的原則。
代理式 AI 會提升該基礎。代理程式系統解譯、推理和調整，而不是遵循指令碼。他們的行為取決於您撰寫的程式碼、他們操作的內容、他們獲得的輸入、他們可以存取的工具，以及他們獲指派的目標。簡言之，他們不遵循訂單；他們追求成果。
這使得交付的控制和對齊更少。您必須塑造其行為，而不是提供指示。這表示傳統的軟體開發生命週期 (SDLC) 不再適用，因為它專為邏輯型、人為控制的系統而設計。
**Topics**
+ [代理式 AI 的意圖區域](#software-delivery-zones)
+ [不斷發展代理式 AI 的交付生命週期](#software-delivery-evolution)
+ [為團隊做好客服人員 AI 的準備](#software-delivery-preparation)
## 代理式 AI 的意圖區域
我們需要一個包含自主性、不確定性和出現的模型，而不是*定義*、*建置*、*測試*和*發行*等剛性階段。反之，您可以使用意圖區域。意圖的*zone*定義了邊界空間，其中代理程式可以在限制範圍內以自主性操作。目標是從微管理每個任務轉移到設計環境，讓客服人員可以安全地採取行動、學習和協作。您可以指定什麼 （所需結果）、原因 （意圖） 和護欄 （限制條件、政策和信任界限）。鑑於這些界限和此資訊，客服人員會找出方法。
將環境視為空間，而不是組裝線。您可以控制誰可以輸入、他們可以做什麼，以及他們可以前往何處。但一旦進入，他們就可以視需要自由導覽。這就是代理系統在沒有混沌的情況下擴展的方式。
這不只是哲學上的轉移，而是實際的轉移。無法透過單位測試完整測試以代理程式為基礎的系統的非確定性輸出。它不能像靜態二進位檔一樣進行版本控制。代理程式會隨著時間變更、適應新資料，並以無法預測的方式與其他系統互動。嘗試使用傳統模型交付它們會導致脆弱、無法擴展的架構。最壞的情況是，這會導致對無法實際控管的系統產生錯誤的信心。
當團隊接受以意圖為基礎的交付時，他們獲得兩個優勢：
+ **控制它最重要的位置** – 它們定義界限而不是輸出。
+ **透過委派的可擴展性** – 可讓客服人員處理人類無法硬式編碼的複雜性。
這就是您將隔離原型遷移到實際的生產級代理系統的方式，這些系統可以重複且可靠地交付價值。
## 不斷發展代理式 AI 的交付生命週期
若要支援智慧型自適應行為，SDLC 必須從決定性控制重新建構為自適應意圖。以下是發展客服人員 AI 傳統 SDLC 所需的變更：
+ *規劃*成為*意圖設計*。團隊定義目標、限制條件和預期的客服人員行為。政策和成功條件是以對齊為框架，而不是邏輯。
+ *架構*會變成*堆疊*。團隊專注於定義角色、界面、護欄、備用機制和可觀測性，而不是編寫每個決策路徑的指令碼。
+ *測試*會變成*行為評估*。團隊不會宣告特定輸出，而是驗證客服人員是否保持在可接受的範圍內，並在不同的輸入下實現意圖。
+ *部署*會變成*持續協同運作*。代理程式系統會部署執行時間控制、即時監控和意見回饋管道，以啟用即時調校。
+ *反覆運算*會成為*意見回饋*和*適應*。團隊會觀察客服人員如何進化、在何處成功或何時偏離，而不是傳統的程式碼變更修補程式週期。如有必要，團隊會介入更新的限制、重新訓練，以及新增或修改控制機制。
專注於反覆運算、實驗和快速意見回饋的現有實務位於一半。轉向代理系統並非拒絕敏捷原則。事實上，這是它們的自然演變。敏捷思維強調了剛性計劃的適應性、意見回饋和工作解決方案。這完全符合代理系統的性質，可即時學習、調整和回應內容。如果您已經執行短期週期、快速驗證假設，以及透過持續交付來管理不確定性，您已準備好領導此轉換。
但有一些主要差異。傳統的敏捷方法假設交付的物件是確定性的。其假設在建置之後，物件的行為將一致且可預測，並具有相同輸入的可重複結果。此可重複性可協助您放心地偵錯、測試和重複。代理程式系統破壞了該模型。它們很概率、內容敏感，並且能夠獨立發展。這表示某些敏捷實務變得較不實用，例如根據故事完成的速度追蹤、嚴格的接受條件或確定性衝刺規劃。
傳統 SDLC 的下列層面適用於代理式 AI：
+ 反覆開發和交付
+ 客戶意見回饋做為主要訊號
+ 跨功能協同合作
+ 持續整合和部署
代理式 AI 必須發展下列傳統 SDLC 層面：
+ 按照意圖重新定義*完成*。 **專注於客服人員的行為是否符合其在定義限制內的預期目標。
+ 從接受條件轉移到行為防護機制。
+ 展開*已完成*的定義，以納入執行階段整備，其中包括可觀測性、可解釋性和支援持續學習和信任的意見回饋機制。
+ 排定前期規劃的即時意見回饋迴圈和行為追蹤優先順序
好消息是，您不需要擲出 SDLC 手冊。您只需要將其從管理程式碼發展為塑造行為。在代理程式系統中，成功不僅在於軟體是否執行，還在於其行為。
## 為團隊做好客服人員 AI 的準備
軟體工程不會消失。它正在演變。任務會從撰寫函數轉移到為智慧行為塑造架構和控制機制。在代理式 AI 的世界中，建置不再是困難的部分，管理出現就是。對於大多數工程團隊而言，演變就像是思維轉移，而不是技術飛躍。而不是詢問「系統會做什麼？」 問題變成「我們賦予它追求的能力，以及如何知道它是否繼續？」
對於工程團隊而言，客服人員 AI 的演變需要下列變更：
+ **文化轉移** – 團隊必須適應他們無法完全控制的系統中的不確定性和自主性。
+ **新角色** – 意圖設計人員、行為測試人員和可觀測性工程師成為交付的核心。
+ **共享語言** – 團隊需要明確、共享對目標、護欄和成功訊號的理解，就像他們曾經需要規格和測試案例一樣。
隨著生成式 AI 的成熟，我們將看到更多代理系統與客戶、產品和操作互動。成功的組織不會是具有最佳模型的組織。它將是能夠將客服人員整合到真實工作流程的那些可以放心、控制和速度的工作流程。這表示交付模型和工程團隊必須一起發展。意圖區域可讓您抽象化。它們可協助您操作自主權，而不會放棄責任。他們也提供跨團隊的共用架構，以協助控管無法硬式編碼的系統。
如需準備客服人員 AI 團隊的詳細資訊，請參閱本指南[的大規模準備客服人員 AI 業務](preparing-business.md)一節。