本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 重點領域 2：設計可編譯性和協同合作
<a name="focus-areas-composability-collaboration"></a>

*待完成的任務：「讓我像建置服務一樣建置客服人員 - 模組化且可測試，以便視需要進行撰寫和協調。」*

許多 AI 工作一開始都是單體、以模型為中心的試驗。它們很有用，但很難跨網域擴展或適應複雜的問題。當這些代理程式設計為互通時的值複合。在技術中，*可編譯性*是結合模組化元件以建立靈活、可擴展的解決方案，以適應變化。如果沒有可編寫性，智慧在特定工作流程中會遭到鎖定。此外，客服人員協同合作引入了傳統自動化團隊可能無法處理的協同運作、狀態管理和通訊協定溝通複雜性。

## 策略
<a name="focus-areas-composability-collaboration-strategy"></a>

接受多代理程式範例。組織部門之類的模型代理程式：模組化、專門和可互通。定義明確的界面、共用內容格式和標準通訊協定，例如[模型內容通訊協定 (MCP)](https://modelcontextprotocol.io/docs/getting-started/intro) 或 [Agent2Agent (A2A)](https://a2aprotocol.ai/)。採用多代理程式協同運作模式，例如扭曲、圖形或階層協調。這些模式可協助客服人員根據任務結構和信任層級，以動態方式從彼此探索功能和請求服務，無論是平行、循序或共識驅動的工作流程。

若要提升可擴展且受管的協同合作，請使用 *仲裁代理程式*。這類代理程式是一種中性授權機構，可根據已知功能和備用策略促進任務委派。雖然 不是集中式控制器，但任意代理程式在信任和合規方面扮演重要角色。它可確保敏感或受管制的任務只會路由至符合身分和政策要求的客服人員。它可做為政策繫結工作流程的 Gatekeeper。它強制執行隔離並啟用可解釋的委派。最重要的是，任意代理程式不是瓶頸；它與以水平peer-to-peer方式操作的自我協調代理程式共存。這些客服人員會委派子任務、共用內容，以及直接解析相依性。

此混合模型支援確定性指派 （透過仲裁代理程式） 和緊急協同合作。它將結構與彈性混合。在此架構中，客服人員可以分類為下列特殊角色：
+ *決策代理*程式，例如政策強制執行者、資源分配器和風險評估者
+ *知識代理*程式，例如內容彙整工具、模式辨識器和異常偵測器
+ *執行代理*程式，例如任務執行器、品質控制器和整合管理員

若要有效協調，多代理程式系統必須支援強大的互動通訊協定，以進行狀態管理、故障復原和衝突解決。即使代理程式獨立運作，這也會提高穩定性和責任。

建立明確的擴展規則，例如負載型代理程式執行個體化、內容感知資源配置，以及自動化功能探索和註冊。這些措施有助於系統動態成長，以回應需求或複雜性。

將代理程式設計為分散式傳訊底線中ready-to-use模組。例如，您可以使用 [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) 搭配 A2A 或 MCP，而非孤立的服務。採用版本控制、CI/CD 管道和代理程式範本，以支援系統穩定性，同時加速內部採用和生命週期演變。鼓勵程式碼重複使用和標準化，以減少整合摩擦並提升彈性生態系統。

協同合作是一種力乘數。它解鎖了跨多代理程式環境的擴展、專業化和彈性。為了支援此動態協同合作，組織應該建構輕量型控制平面以進行客服人員協調。此控制平面包含下列項目：
+ 功能登錄檔，定義每個代理程式可執行的操作，並支援對等探索的版本化中繼資料
+ 使用 arbiter 或主管代理程式根據內容、可用性和政策路由任務的任務仲裁邏輯
+ 啟用即時決策內容和安全交接的生命週期和狀態追蹤

控制平面可確保多代理程式系統保持可擴展性、政策一致且容錯能力，而不會集中授權或減慢操作速度。

不過，多代理程式環境也會帶來營運挑戰。維護客服人員互動之間的內容、管理共用狀態，以及協調動作都可能提高複雜性和成本。如果您在客服人員間通訊期間使用取用權杖的 LLMs，成本可能會增加。這些成本必須與大規模智慧自主的複合商業優勢權衡。

若要解決這些挑戰，請考慮抽象關鍵問題的代理程式平台，例如：
+ 標準化通訊協定和語意格式
+ 內建協同運作邏輯和動態路由
+ 客服人員之間的共用內容和記憶體管理
+ 故障期間的備用處理和正常降級

對於採用多代理程式策略的團隊，最佳方法是從小規模開始並設計規模。從解決實際問題的目標單一代理程式解決方案開始。然後，逐步將這些客服人員組成合作的系統，讓每個客服人員都可以根據共用目標和整個系統的內容來探索、協調和委派。

重要的是，強大的錯誤處理和正常降級必須是主要設計原則。當客服人員無法使用或失敗時，多客服人員系統應該能夠繼續部分工作流程或啟動備份邏輯。這可提升可靠性，無需剛性耦合。

AWS 服務 提供強大的功能來大規模支援此架構。[Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) 和 [EventBridge 管道](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html)為多代理程式訊息提供結構化、事件驅動的骨幹。為了管理模組化行為， [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)可啟用跨代理程式執行個體的安全動態組態切換。若要支援共用內容和記憶體管理，請使用 [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) 進行輕量化的租用戶感知狀態持久性和跨客服人員的快速內容擷取。您可以使用 [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) 來儲存結構化提示歷史記錄、共用成品或代理程式產生的輸出。對於需要有狀態協調的更複雜工作流程， [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)可以使用檢查點和錯誤復原邏輯來協調長時間執行的程序。這些服務共同協助您建立可組合、彈性和語意連線的多代理程式系統，以滿足企業需求。

## 多代理程式系統的商業價值
<a name="focus-areas-composability-collaboration-value"></a>

雖然許多組織使用單一代理程式解決方案開始 AI 旅程，但可透過可擴展的多代理程式系統釋放代理程式 AI 的完整潛力。這些系統是解決複雜、分散式問題，以及建立穩固、彈性 AI 生態系統以因應業務需求的關鍵。

多代理程式系統的核心業務優勢包括下列項目：
+ **可擴展性** – 任務和工作負載可以分散到專門的代理程式，以提高容量和效能。
+ **彈性** – 可以新增、取代或修改代理程式，並將中斷降至最低，從而在動態環境中實現敏捷性。
+ **彈性** – 由於備援角色和智慧型容錯移轉，即使個別客服人員失敗，系統穩定性也會保持。
+ **專業化** – 專門建置的代理程式會以更高的效率和精確度執行任務。
+ **成本效率** – 可重複使用的代理程式元件可加速開發並降低新功能部署的成本。

雖然多代理程式系統需要更預先的規劃，但它們可提供長期的靈活性、速度和創新容量。投資彈性代理程式協同合作架構的企業，可以快速部署新的 AI 功能、適應不斷變化的需求，並在越來越多的代理程式驅動的競爭環境中領導。