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

# 為大規模代理式 AI 業務做好準備
<a name="preparing-business"></a>

正如本指南中所述的[重點領域](focus-areas.md)收斂，代理程式 AI 會從隔離的函數轉移到統一的智慧層，而這些層可以理解為功能平台。此平台不只是執行任務。它跨網域演進、調整和協調。代理程式成為模組化、可重複使用且可探索的服務，可加速創新、降低認知負載，並在整個企業中推動可衡量的結果。此平台檢視會設定階段，以在整個操作模型中嵌入可擴展的智慧。

操作化代理程式 AI 需要的不只是部署智慧型代理程式。它要求在業務如何組織團隊、設計流程和管理技術方面進行基本轉型。與轉移至雲端或 DevOps 重新定義的操作模型一樣，代理式 AI 引入了決策自動化、持續學習和自主協調的新紀元。成功取決於使系統、人員和程序與此新的操作理念保持一致。

**Topics**
+ [協調團隊和擁有權模型](#preparing-business-alignment)
+ [管理變更和組織整備](#preparing-business-change)
+ [架構互通性和協同合作](#preparing-business-collaboration)
+ [將管控建置到代理程式結構](#preparing-business-governance)
+ [採用決策優先的操作思維](#preparing-business-mindset)
+ [使用目的和意圖擴展](#preparing-business-scaling)

## 協調團隊和擁有權模型
<a name="preparing-business-alignment"></a>

成熟度的第一步是跨功能對齊。企業必須建立 AgentOps 團隊，其中包含 AI/ML 從業人員和網域專家，例如分散式系統架構師、軟體工程師、產品擁有者、合規主管和平台架構師。這些團隊共同擁有 代理程式的整個生命週期，從設計和部署到重新訓練和監控。

代理程式佈建和發行應遵循雲端原生實務，例如使用 [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html)和 [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 做為基礎設施的程式碼和自動化部署。此結構促進共同的責任，並加速反覆運算。就像 DevOps 統一開發和操作一樣，AgentOps 會將智慧與控管和執行連線。

為了提高效率，這些團隊也需要共用語言。業務利益相關者必須了解[什麼是客服人員](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-foundations/overview.html)、[他們的操作方式](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-foundations/new-generation.html)，以及[他們推動的結果](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-foundations/purpose.html)。訓練和內部啟用至關重要。透過解密客服人員並將這個心理模型嵌入日常對話中，組織可以釋放更廣泛的參與和更一致的創新。

為了使用 來加速代理程式的開發和整合 AWS 服務，團隊可以採用 [Strands Agents SDK](https://strandsagents.com/) 等架構，該 SDK 提供 CLI 型工具，用於堆疊、設定和封裝代理程式。Strands Agents 旨在順暢地與 AWS 基礎設施搭配使用，例如 [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html)、[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)、[Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) AWS CDK、 和 AWS CodePipeline。它可實現快速原型設計和部署，同時維持生產級標準。

但是，只有結構和工具是不夠的。擴展代理式 AI 需要深思熟慮的文化、教育和領導力準備，以確保採用能根植於整個組織。

## 管理變更和組織整備
<a name="preparing-business-change"></a>

成功擴展代理程式 AI 需要的不只是部署基礎設施或智慧型代理程式。它需要結構化的組織變革方法。這包括文化準備度、技能開發、指標驅動的意見回饋迴圈和執行一致性，以確保採用是有意且永續的。

**促進文化發展**
+ 將客服人員定位為團隊成員，而非替代人員，以減少阻力並建立信任。
+ 透明地傳達客服人員的功能和限制，以設定實際的期望。
+ 為客服人員應將決策呈報給更高權限或將部分程序委派給人工合作者，建立明確的交接通訊協定。

**建立技能開發架構**
+ 為工程師、產品經理、網域主管和合規主管提供量身打造的角色型訓練。
+ 建立卓越中心，以分享最佳實務、工具模式和可重複使用的資產。
+ 透過指導計畫將 AI 專家與領域專家配對，以彌補知識差距。

**定義指標和意見回饋迴圈**
+ 將技術和業務 KPIs 錨定為策略價值，以評估影響。價值的範例包括決策延遲、解析度準確性和成本節省。
+ 系統化且持續地擷取使用者對表面摩擦點和採用挑戰的意見回饋。
+ 執行定期回顧，以評估客服人員效能、用量趨勢和改善機會。

**從頂端調整領導**
+ 將客服人員計畫連結至策略成果和投資報酬率，以取得高階主管的贊助。
+ 組成包含技術和業務領導的跨職能控管委員會。
+ 量身打造溝通策略，以提高所有組織層級的清晰度和參與度。

這種變更管理的系統性方法可確保技術實作符合組織成熟度。它為信任、採用和長期商業價值奠定了基礎。

## 架構互通性和協同合作
<a name="preparing-business-collaboration"></a>

隔離的代理程式部署可提供本機勝利。但是，當客服人員可以動態探索、叫用和協同合作時，企業價值就會出現。這表示定義客服人員註冊、身分驗證和功能交換的標準。在架構上，這反映了從整體到微服務的轉移，這是可組合、可重複使用和鬆耦合的單位，可一起解決複雜的問題。

[A2A](https://a2aprotocol.ai/) 和 [MCP](https://modelcontextprotocol.io/introduction) 等新興通訊協定是基本的。啟用客服人員、工具和記憶體系統的語意互通性。A2A 支援對等層級互動，可讓客服人員交涉任務擁有權、共用內容和協調工作流程。MCP 透過提供共用結構描述來補充這一點，以便在代理程式及其環境之間交換內容資料。它會標準化如何叫用函數、存取 APIs，以及維護狀態。這些通訊協定共同提升了客服人員生態系統的可擴展性、一致性和長期可維護性。

控管仍然至關重要。控制層，例如任意代理程式，可啟用政策感知委派，而不會引入集中式瓶頸。這些代理程式充當信任代理程式。它們強制執行界限，同時讓其他客服人員自行組織。客服人員協作可協助組織同時靈活和信任地擴展其客服人員 AI 生態系統。

## 將管控建置到代理程式結構
<a name="preparing-business-governance"></a>

隨著自主性提高，風險也會提高。管控必須從第一天開始內嵌到代理程式架構中。這包括定義政策界限，以限制允許客服人員執行的動作、強制執行身分模型來判斷他們代表的對象，以及實作可解釋性和可追蹤性。可觀測性系統必須使用 [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 和 等服務擷取代理程式行為的遙測[AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)，這些服務提供跨代理程式工作流程的集中式記錄和分散式追蹤。反射式代理程式可以根據這些遙測饋送持續稽核和評估效能。

控管也必須隨著代理程式生態系統的成熟而發展。隨著客服人員變得更有能力且更自主，監督機制必須變得更適應。政策更新、功能閘道和執行時間行為限制條件需要是動態且可大規模強制執行的。信任不是鎖定功能。它透過架構、行為和程序持續強化。[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) 和 在強制執行安全身分、執行時間許可界限和環境特定行為時[AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)扮演關鍵角色，跨客服人員切換。

## 採用決策優先的操作思維
<a name="preparing-business-mindset"></a>

傳統自動化著重於程序效率，這會更快、更可靠地執行預先定義的指令碼或工作流程。反之，代理式 AI 引進了決策優先自動化。客服人員會即時評估內容、權重選項和調整行為。這種從執行優先轉移到決策優先的思維需要重新考慮成功指標和結果。代理式 AI 的成功不是只透過任務完成來衡量成功，而是透過決策與意圖、政策和不斷變化的條件的一致性來衡量。

組織必須評估決策品質、time-to-action對變革的回應能力，而不是僅測量任務完成或週期時間。KPIs應包含下列指標：
+ **決策品質** – 客服人員對特定使用者或案例的個人化回應有多好？ 它是否做出符合業務目標和使用者內容的細微決策？
+ **Time-to-action** – 客服人員評估情況和回應的速度有多快且多聰明？ 延遲是否低到足以感覺適應性和類似人類？
+ **認知卸載** – 代理程式能夠代表人類處理多少手動分析、分類或例行決策？ 它是否減少工作量或只是轉移工作量？

接受以決策為優先思維的企業可以變得更有彈性、更具適應性，並且能夠以新的複雜性操作。

## 使用目的和意圖擴展
<a name="preparing-business-scaling"></a>

成功擴展代理式 AI 與試驗更多工具無關。這是關於建置耐久的企業智慧層。這需要投資平台基礎設施、營運文化、控管架構和策略一致性。企業必須採用刻意的方法。他們必須將代理程式視為不是實驗，而是其數位操作模型的核心元件。

與 [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) 保持一致有助於您的系統符合可靠性、安全性、效能效率和成本最佳化的企業標準。[Strands Agents SDK](https://strandsagents.com/) 等工具可以透過提供結構化提示、工具註冊和 CI/CD 整備度來加速此旅程。這有助於團隊使用熟悉的 AWS 工作流程，從實驗轉移到可擴展的交付。

代理式 AI 不是工具，而是將智慧嵌入 操作的轉變。相應地準備的組織可以自動化更多、更智慧地操作、更快地適應，並在日益複雜的世界中建立持久的優勢。