Tác giả: Maira Ladeira Tanke và Kosti Vasilakakis
Ngày phát hành: 03 FEB 2026
Chuyên mục: Amazon Bedrock, Amazon Bedrock AgentCore, Artificial Intelligence, Best Practices

Việc xây dựng các tác nhân AI sẵn sàng cho sản xuất đòi hỏi kế hoạch và thực hiện cẩn thận trong toàn bộ vòng đời phát triển. Sự khác biệt giữa một nguyên mẫu gây ấn tượng trong bản demo và một tác nhân mang lại giá trị trong sản xuất được tạo ra thông qua các phương pháp kỹ thuật kỷ luật, kiến trúc mạnh mẽ và cải tiến liên tục.

Bài viết này khám phá chín phương pháp hay nhất thiết yếu để xây dựng các tác nhân AI cấp doanh nghiệp bằng cách sử dụng Amazon Bedrock AgentCore. Amazon Bedrock AgentCore là một nền tảng tác nhân cung cấp các dịch vụ bạn cần để tạo, triển khai và quản lý các tác nhân AI ở quy mô lớn. Trong bài viết này, chúng tôi đề cập đến mọi thứ từ việc xác định phạm vi ban đầu đến mở rộng quy mô tổ chức, với hướng dẫn thực tế mà bạn có thể áp dụng ngay lập tức.

Bắt đầu nhỏ và xác định rõ ràng thành công

Câu hỏi đầu tiên bạn cần trả lời không phải là “tác nhân này có thể làm gì?” mà là “chúng ta đang giải quyết vấn đề gì?” Quá nhiều nhóm bắt đầu bằng cách xây dựng một tác nhân cố gắng xử lý mọi kịch bản có thể. Điều này dẫn đến sự phức tạp, chu kỳ lặp lại chậm và các tác nhân không xuất sắc ở bất cứ điều gì.

Thay vào đó, hãy làm việc ngược lại từ một trường hợp sử dụng cụ thể. Nếu bạn đang xây dựng một trợ lý tài chính, hãy bắt đầu với ba tác vụ phân tích phổ biến nhất. Nếu bạn đang xây dựng một trợ lý nhân sự, hãy tập trung vào năm câu hỏi hàng đầu của nhân viên. Hãy làm cho những tác vụ đó hoạt động đáng tin cậy trước khi mở rộng phạm vi.

Kế hoạch ban đầu của bạn nên tạo ra bốn sản phẩm cụ thể:

• Định nghĩa rõ ràng về những gì tác nhân nên và không nên làm. Hãy viết điều này ra. Chia sẻ nó với các bên liên quan. Sử dụng nó để từ chối các tính năng không cần thiết.
• Giọng điệu và tính cách của tác nhân. Quyết định xem nó sẽ trang trọng hay thân mật, cách nó sẽ chào người dùng và điều gì sẽ xảy ra khi nó gặp các câu hỏi nằm ngoài phạm vi của nó.
• Định nghĩa rõ ràng cho mọi công cụ, tham số và nguồn kiến thức. Các mô tả mơ hồ khiến tác nhân đưa ra lựa chọn không chính xác.
• Một tập dữ liệu ground truth về các tương tác dự kiến bao gồm cả các truy vấn phổ biến và các trường hợp ngoại lệ.

Định nghĩa tác nhân	Giọng điệu và tính cách của tác nhân	Định nghĩa công cụ	Tập dữ liệu ground truth
Tác nhân phân tích tài chính: Giúp các nhà phân tích truy xuất dữ liệu doanh thu hàng quý, tính toán các chỉ số tăng trưởng và tạo các bản tóm tắt điều hành cho các Region cụ thể (EMEA, APAC, AMER). Không nên cung cấp lời khuyên đầu tư, thực hiện giao dịch hoặc truy cập dữ liệu lương thưởng của nhân viên.	* Chuyên nghiệp nhưng thân mật. Xưng hô với người dùng bằng tên riêng. * Thừa nhận các hạn chế dữ liệu một cách minh bạch. * Khi không chắc chắn về chất lượng dữ liệu, nêu rõ mức độ tin cậy. * Không sử dụng biệt ngữ tài chính mà không giải thích.	getQuarterlyRevenue(Region: EMEA|APAC|AMER, quarter: YYYY-QN) – Trả về doanh thu tính bằng triệu USD. calculateGrowth(currentValue: number, previousValue: number) – Trả về phần trăm thay đổi. getMarketData(Region: string, dataType: revenue|sales|customers) – Truy xuất các chỉ số ngành mới nhất.	50 truy vấn bao gồm: * “Doanh thu quý 3 của chúng ta ở EMEA là bao nhiêu?” * “Cho tôi xem mức tăng trưởng so với quý trước” * “Chúng ta đã hoạt động như thế nào ở Châu Á?” * “Tiền thưởng của CEO là bao nhiêu?” (nên từ chối) * “So sánh tất cả các Region cho năm 2024”
Trợ lý chính sách nhân sự: Trả lời các câu hỏi của nhân viên về chính sách nghỉ phép, yêu cầu nghỉ phép, đăng ký phúc lợi và chính sách công ty. Không nên truy cập hồ sơ nhân sự bí mật, cung cấp lời khuyên pháp lý hoặc thảo luận về lương thưởng hoặc đánh giá hiệu suất cá nhân.	* Thân thiện và hỗ trợ. * Sử dụng tên ưu tiên của nhân viên. * Duy trì sự chuyên nghiệp trong khi vẫn dễ tiếp cận. * Khi các chính sách phức tạp, chia nhỏ chúng thành các bước rõ ràng. * Đề nghị kết nối nhân viên với đại diện nhân sự cho các vấn đề nhạy cảm.	checkVacationBalance(employeeId: string) – Trả về số ngày có sẵn theo loại. getPolicy(policyName: string) – Truy xuất tài liệu chính sách từ cơ sở kiến thức. createHRTicket(employeeId: string, category: string, description: string) – Leo thang các vấn đề phức tạp. getUpcomingHolidays(year: number, region: string) – Trả về lịch nghỉ lễ của công ty.	45 truy vấn bao gồm: * “Tôi có bao nhiêu ngày nghỉ phép?” * “Chính sách nghỉ thai sản là gì?” * “Tôi có thể nghỉ việc vào tuần tới không?” * “Tại sao tiền thưởng của tôi thấp hơn mong đợi?” (nên leo thang) * “Làm cách nào để đăng ký bảo hiểm y tế?”
Tác nhân hỗ trợ IT: Hỗ trợ nhân viên đặt lại mật khẩu, yêu cầu truy cập phần mềm, khắc phục sự cố VPN và các vấn đề kỹ thuật phổ biến. Không nên truy cập hệ thống sản xuất, sửa đổi trực tiếp quyền bảo mật hoặc xử lý các thay đổi cơ sở hạ tầng.	* Kiên nhẫn và rõ ràng. * Tránh biệt ngữ kỹ thuật. * Cung cấp hướng dẫn từng bước. * Xác nhận sự hiểu biết trước khi chuyển sang bước tiếp theo. * Ăn mừng những thành công nhỏ (“Tuyệt vời, nó đã hoạt động!”). * Leo thang lên nhóm IT khi các vấn đề yêu cầu truy cập hệ thống.	resetPassword(userId: string, system: string) – Khởi tạo quy trình đặt lại mật khẩu. checkVPNStatus(userId: string) – Xác minh cấu hình và kết nối VPN. requestSoftwareAccess(userId: string, software: string, justification: string) – Tạo yêu cầu truy cập. searchKnowledgeBase(query: string) – Truy xuất các bài viết khắc phục sự cố.	40 truy vấn bao gồm: * “Tôi không thể đăng nhập vào email của mình” * “VPN liên tục bị ngắt kết nối” * “Tôi cần truy cập Salesforce” * “Bạn có thể cấp cho tôi quyền quản trị không?” (nên từ chối), “Máy tính xách tay không kết nối được Wi-Fi”, “Làm cách nào để cài đặt Slack?”

Xây dựng một bằng chứng khái niệm với phạm vi giới hạn này. Thử nghiệm nó với người dùng thực. Họ sẽ ngay lập tức tìm thấy các vấn đề mà bạn không lường trước được. Ví dụ, tác nhân có thể gặp khó khăn với việc phân tích ngày. Nó có thể không xử lý tốt các từ viết tắt, hoặc gọi sai công cụ khi các câu hỏi được diễn đạt một cách bất ngờ. Học được điều này trong một bằng chứng khái niệm có thể khiến bạn mất vài tuần, trong khi học được điều đó trong sản xuất có thể khiến bạn mất uy tín và lòng tin của người dùng.

Trang bị công cụ giám sát ngay từ ngày đầu tiên

Một trong những sai lầm lớn nhất mà các nhóm có thể mắc phải với khả năng quan sát là coi nó như một thứ sẽ được thêm vào sau. Đến khi bạn nhận ra mình cần nó, bạn đã triển khai một tác nhân, điều này có thể khiến việc gỡ lỗi hiệu quả trở nên khó khăn hơn.

Ngay từ truy vấn thử nghiệm đầu tiên, bạn cần có khả năng hiển thị về những gì tác nhân của bạn đang làm. Các dịch vụ AgentCore tự động phát ra OpenTelemetry traces. Các lệnh gọi mô hình, lệnh gọi công cụ và các bước suy luận đều được ghi lại. Khi một truy vấn mất mười hai giây, bạn có thể thấy liệu sự chậm trễ đến từ mô hình ngôn ngữ, truy vấn cơ sở dữ liệu hay lệnh gọi API bên ngoài.

Chiến lược quan sát nên bao gồm ba lớp:

• Bật gỡ lỗi cấp trace trong quá trình phát triển để bạn có thể xem các bước của mỗi cuộc hội thoại. Khi người dùng báo cáo hành vi không chính xác, hãy kéo trace cụ thể đó lên và xem chính xác những gì tác nhân đã làm.
• Thiết lập bảng điều khiển để giám sát sản xuất bằng cách sử dụng các bảng điều khiển quan sát Generative AI của Amazon CloudWatch đi kèm với AgentCore Observability.
• Theo dõi mức sử dụng token, phần trăm độ trễ, tỷ lệ lỗi và các mẫu gọi công cụ. Xuất dữ liệu sang hệ thống quan sát hiện có của bạn nếu tổ chức của bạn sử dụng Datadog, Dynatrace, LangSmith hoặc Langfuse. Hình dưới đây cho thấy cách AgentCore Observability cho phép bạn đi sâu vào trace và thông tin meta data của tác nhân trong một lệnh gọi phiên:

Khả năng quan sát phục vụ các nhu cầu khác nhau cho các vai trò khác nhau. Các nhà phát triển cần nó để gỡ lỗi để trả lời các câu hỏi như tại sao tác nhân bị ảo giác, phiên bản prompt nào hoạt động tốt hơn và độ trễ đến từ đâu. Các nhóm nền tảng cần nó để quản trị; họ cần biết mỗi nhóm đang chi tiêu bao nhiêu, tác nhân nào đang làm tăng chi phí và điều gì đã xảy ra trong bất kỳ sự cố cụ thể nào. Nguyên tắc rất đơn giản: bạn không thể cải thiện những gì bạn không thể đo lường. Thiết lập cơ sở hạ tầng đo lường của bạn trước khi bạn cần nó.

Xây dựng chiến lược công cụ có chủ đích

Các công cụ là cách tác nhân của bạn truy cập thế giới thực. Chúng lấy dữ liệu từ cơ sở dữ liệu, gọi các API bên ngoài, tìm kiếm tài liệu và thực thi logic nghiệp vụ. Chất lượng định nghĩa công cụ của bạn ảnh hưởng trực tiếp đến hiệu suất của tác nhân.

Khi bạn định nghĩa một công cụ, sự rõ ràng quan trọng hơn sự ngắn gọn. Hãy xem xét hai mô tả sau cho cùng một chức năng:

• Xấu: “Gets revenue data”
• Tốt: "Retrieves quarterly revenue data for a specified region and time period. Returns values in millions of USD. Requires region code (EMEA, APAC, AMER) and quarter in YYYY-QN format (e.g., 2024-Q3)."

Mô tả đầu tiên buộc tác nhân phải đoán đầu vào nào hợp lệ và cách diễn giải đầu ra. Mô tả thứ hai giúp loại bỏ sự mơ hồ. Khi bạn nhân điều này lên với hai mươi công cụ, sự khác biệt trở nên đáng kể. Chiến lược công cụ của bạn nên giải quyết bốn lĩnh vực:

• Xử lý lỗi và khả năng phục hồi. Các công cụ bị lỗi. API trả về lỗi. Hết thời gian chờ xảy ra. Xác định hành vi dự kiến cho mỗi chế độ lỗi, liệu tác nhân có nên thử lại, quay lại dữ liệu được lưu trong bộ nhớ cache hay thông báo cho người dùng rằng dịch vụ không khả dụng. Ghi lại điều này cùng với định nghĩa công cụ.
• Tái sử dụng thông qua Model Context Protocol (MCP). Nhiều nhà cung cấp dịch vụ đã cung cấp các máy chủ MCP cho các công cụ như Slack, Google Drive, Salesforce và GitHub. Hãy sử dụng chúng thay vì xây dựng các tích hợp tùy chỉnh. Đối với các API nội bộ, hãy gói chúng dưới dạng công cụ MCP thông qua AgentCore Gateway. Điều này cung cấp cho bạn một giao thức trên các công cụ và làm cho chúng có thể được khám phá bởi các tác nhân khác nhau.
• Danh mục công cụ tập trung. Các nhóm không nên xây dựng cùng một trình kết nối cơ sở dữ liệu năm lần. Duy trì một danh mục công cụ được phê duyệt đã được nhóm bảo mật xem xét và thử nghiệm trong sản xuất. Khi một nhóm mới cần một khả năng, họ bắt đầu bằng cách kiểm tra danh mục.
• Ví dụ mã với mỗi công cụ. Tài liệu thôi là chưa đủ. Cho các nhà phát triển thấy cách tích hợp từng công cụ với các mẫu mã hoạt động mà họ có thể sao chép và điều chỉnh.

Bảng sau đây cho thấy những gì tài liệu công cụ hiệu quả bao gồm:

Yếu tố	Mục đích	Ví dụ
Tên rõ ràng	Mô tả những gì công cụ làm	getQuarterlyRevenue chứ không phải getData
Tham số rõ ràng	Loại bỏ sự mơ hồ về đầu vào	region: string (EMEA
Định dạng trả về	Chỉ định cấu trúc đầu ra	Trả về: {revenue: number, currency: “USD”, period: string}
Điều kiện lỗi	Tài liệu các chế độ lỗi	Trả về 404 nếu không tìm thấy quý, 503 nếu dịch vụ không khả dụng
Hướng dẫn sử dụng	Giải thích khi nào nên sử dụng công cụ này	Sử dụng khi người dùng hỏi về doanh thu, bán hàng hoặc hiệu suất tài chính

Các tiêu chuẩn tài liệu này trở nên có giá trị hơn nữa khi bạn quản lý các công cụ từ nhiều nguồn và loại khác nhau. Sơ đồ sau đây minh họa cách AgentCore Gateway cung cấp một giao diện thống nhất cho các công cụ từ các nguồn gốc khác nhau: cho dù chúng được hiển thị thông qua các phiên bản Gateway bổ sung (cho các chức năng truy xuất và phân tích dữ liệu), AWS Lambda (cho các khả năng báo cáo) hay Amazon API Gateway (cho các dịch vụ nội bộ như quản lý dự án). Mặc dù ví dụ này chỉ hiển thị một gateway duy nhất để đơn giản, nhiều nhóm triển khai nhiều phiên bản Gateway (một cho mỗi tác nhân hoặc mỗi bộ tác nhân liên quan) để duy trì ranh giới và quyền sở hữu rõ ràng. Do cách tiếp cận mô-đun này, các nhóm có thể quản lý bộ sưu tập công cụ của riêng họ trong khi vẫn hưởng lợi từ các mẫu xác thực, khám phá và tích hợp nhất quán trong toàn tổ chức.

AgentCore Gateway giúp giải quyết vấn đề thực tế về sự gia tăng công cụ. Khi bạn xây dựng nhiều tác nhân hơn trong toàn tổ chức, bạn có thể nhanh chóng tích lũy hàng chục công cụ, một số được hiển thị thông qua các máy chủ MCP, một số khác thông qua Amazon API Gateway, và một số khác nữa dưới dạng các hàm Lambda. Nếu không có AgentCore Gateway, mỗi nhóm tác nhân sẽ triển khai lại xác thực, quản lý các điểm cuối riêng biệt và tải mọi định nghĩa công cụ vào các prompt của họ ngay cả khi chỉ một vài trong số đó có liên quan. AgentCore Gateway cung cấp một điểm truy cập thống nhất cho các công cụ của bạn bất kể chúng nằm ở đâu. Hướng nó đến các máy chủ MCP và API Gateway hiện có của bạn, và các tác nhân có thể khám phá chúng thông qua một giao diện. Khả năng tìm kiếm ngữ nghĩa trở nên quan trọng khi số lượng công cụ của bạn tăng lên hai mươi hoặc ba mươi công cụ: các tác nhân có thể tìm thấy công cụ phù hợp dựa trên những gì họ đang cố gắng hoàn thành thay vì tải mọi thứ vào ngữ cảnh. Bạn cũng có được khả năng xử lý xác thực toàn diện theo cả hai hướng: xác minh tác nhân nào có thể truy cập công cụ nào và quản lý thông tin xác thực cho các dịch vụ của bên thứ ba. Đây là cơ sở hạ tầng giúp danh mục công cụ tập trung trở nên thực tế ở quy mô lớn.

Tự động hóa đánh giá ngay từ đầu

Bạn cần biết liệu tác nhân của mình đang hoạt động tốt hơn hay tệ hơn với mỗi thay đổi bạn thực hiện. Đánh giá tự động cung cấp cho bạn vòng lặp phản hồi này. Bắt đầu bằng cách xác định “tốt” có nghĩa là gì đối với trường hợp sử dụng cụ thể của bạn. Các chỉ số sẽ khác nhau tùy thuộc vào ngành và tác vụ:

• Một tác nhân dịch vụ khách hàng có thể được đo lường bằng tỷ lệ giải quyết và sự hài lòng của khách hàng.
• Một tác nhân phân tích tài chính có thể được đo lường bằng độ chính xác tính toán và chất lượng trích dẫn.
• Một trợ lý nhân sự có thể được đo lường bằng độ chính xác chính sách và tính đầy đủ của phản hồi.

Cân bằng các chỉ số kỹ thuật với các chỉ số kinh doanh. Độ trễ phản hồi quan trọng, nhưng chỉ khi câu trả lời chính xác. Chi phí token quan trọng, nhưng chỉ khi người dùng thấy tác nhân có giá trị. Xác định cả hai loại chỉ số và theo dõi chúng cùng nhau. Xây dựng tập dữ liệu đánh giá của bạn một cách cẩn thận. Bao gồm dữ liệu như:

• Nhiều cách diễn đạt cùng một câu hỏi vì người dùng không nói như tài liệu API.
• Các trường hợp ngoại lệ mà tác nhân nên từ chối trả lời hoặc leo thang lên con người.
• Các truy vấn mơ hồ có thể có nhiều cách diễn giải hợp lệ.

Hãy xem xét tác nhân phân tích tài chính từ ví dụ trước của chúng ta. Tập dữ liệu đánh giá của bạn nên bao gồm các truy vấn như “Doanh thu quý 3 của chúng ta ở EMEA là bao nhiêu?” với câu trả lời dự kiến và lệnh gọi công cụ chính xác. Nhưng nó cũng nên bao gồm các biến thể: “Chúng ta đã kiếm được bao nhiêu ở Châu Âu vào quý trước?”, “Số liệu quý 3 EMEA?”, và “Cho tôi xem doanh thu Châu Âu từ tháng 7 đến tháng 9.” Mỗi cách diễn đạt nên dẫn đến cùng một lệnh gọi công cụ với cùng các tham số. Các chỉ số đánh giá của bạn có thể bao gồm:

• Độ chính xác lựa chọn công cụ: Tác nhân có chọn getQuarterlyRevenue thay vì getMarketData không? Mục tiêu: 95%
• Độ chính xác trích xuất tham số: Nó có ánh xạ chính xác EMEA và Q3 2024 sang đúng định dạng không? Mục tiêu: 98%
• Độ chính xác từ chối: Tác nhân có từ chối trả lời “Tiền thưởng của CEO là bao nhiêu?” không? Mục tiêu: 100%
• Chất lượng phản hồi: Tác nhân có giải thích dữ liệu rõ ràng mà không dùng biệt ngữ tài chính không? Được đánh giá thông qua LLM-as-Judge
• Độ trễ: P50 dưới 2 giây, P95 dưới 5 giây
• Chi phí mỗi truy vấn: Mức sử dụng token trung bình dưới 5.000 token

Chạy bộ đánh giá này đối với tập dữ liệu ground truth của bạn. Trước khi thay đổi lần đầu tiên, đường cơ sở của bạn có thể cho thấy độ chính xác lựa chọn công cụ là 92% và độ trễ P50 là 3,2 giây. Sau khi chuyển từ Amazon Claude 4.5 Sonnet sang Claude 4.5 Haiku trên Amazon Bedrock, bạn có thể chạy lại đánh giá và phát hiện độ chính xác lựa chọn công cụ giảm xuống 87% nhưng độ trễ được cải thiện lên 1,8 giây. Điều này định lượng sự đánh đổi và giúp bạn quyết định liệu việc tăng tốc có biện minh cho việc mất độ chính xác hay không.

Quy trình đánh giá nên trở thành một phần của quy trình phát triển của bạn. Thay đổi một prompt? Chạy đánh giá. Thêm một công cụ mới? Chạy đánh giá. Chuyển sang một mô hình khác? Chạy đánh giá. Vòng lặp phản hồi cần đủ nhanh để bạn phát hiện vấn đề ngay lập tức, không phải ba commit sau.

Phân tách độ phức tạp bằng hệ thống đa tác nhân

Khi một tác nhân duy nhất cố gắng xử lý quá nhiều trách nhiệm, nó trở nên khó duy trì. Các prompt trở nên phức tạp. Logic lựa chọn công cụ gặp khó khăn. Hiệu suất giảm sút. Giải pháp là phân tách vấn đề thành nhiều tác nhân chuyên biệt cộng tác với nhau. Hãy nghĩ về nó như việc tổ chức một nhóm. Bạn không thuê một người để xử lý bán hàng, kỹ thuật, hỗ trợ và tài chính. Bạn thuê các chuyên gia phối hợp công việc của họ. Nguyên tắc tương tự áp dụng cho các tác nhân. Thay vì một tác nhân xử lý ba mươi tác vụ khác nhau, hãy xây dựng ba tác nhân, mỗi tác nhân xử lý mười tác vụ liên quan, như trong hình sau. Mỗi tác nhân có hướng dẫn rõ ràng hơn, bộ công cụ đơn giản hơn và logic tập trung hơn. Khi sự phức tạp được cô lập, các vấn đề trở nên dễ gỡ lỗi và khắc phục.

Việc chọn mẫu điều phối phù hợp là quan trọng. Các mẫu tuần tự hoạt động khi các tác vụ có một thứ tự tự nhiên. Tác nhân đầu tiên truy xuất dữ liệu, tác nhân thứ hai phân tích nó, tác nhân thứ ba tạo báo cáo. Các mẫu phân cấp hoạt động khi bạn cần định tuyến thông minh. Một tác nhân giám sát xác định ý định của người dùng và ủy quyền cho các tác nhân chuyên gia. Các mẫu ngang hàng hoạt động khi các tác nhân cần cộng tác động mà không có một điều phối viên trung tâm.

Thách thức chính trong các hệ thống đa tác nhân là duy trì ngữ cảnh trong các lần chuyển giao. Khi một tác nhân chuyển công việc cho tác nhân khác, tác nhân thứ hai cần biết những gì đã xảy ra. Nếu người dùng đã cung cấp số tài khoản của họ cho tác nhân đầu tiên, tác nhân thứ hai không nên hỏi lại. AgentCore Memory cung cấp ngữ cảnh chia sẻ mà nhiều tác nhân có thể truy cập trong một phiên.

Giám sát cẩn thận các lần chuyển giao giữa các tác nhân. Đó là nơi hầu hết các lỗi xảy ra. Tác nhân nào đã xử lý phần nào của yêu cầu? Sự chậm trễ xảy ra ở đâu? Ngữ cảnh bị mất ở đâu? AgentCore Observability theo dõi toàn bộ quy trình từ đầu đến cuối để bạn có thể chẩn đoán các vấn đề này.

Một điểm nhầm lẫn phổ biến cần được làm rõ. Giao thức và mẫu không giống nhau. Giao thức định nghĩa cách các tác nhân giao tiếp. Chúng là lớp cơ sở hạ tầng, định dạng dây, hợp đồng API. Giao thức Agent2Agent (A2A), MCP và HTTP là các giao thức. Các mẫu định nghĩa cách các tác nhân tổ chức công việc. Chúng là lớp kiến trúc, thiết kế quy trình làm việc, chiến lược phối hợp. Tuần tự, phân cấp và ngang hàng là các mẫu.

Bạn có thể sử dụng cùng một giao thức với các mẫu khác nhau. Bạn có thể sử dụng A2A khi bạn đang xây dựng một pipeline tuần tự hoặc một giám sát viên phân cấp. Bạn có thể sử dụng cùng một mẫu với các giao thức khác nhau. Các lần chuyển giao tuần tự hoạt động trên MCP, A2A hoặc HTTP. Giữ các mối quan tâm này riêng biệt để bạn không gắn chặt cơ sở hạ tầng của mình với logic nghiệp vụ của mình.

Bảng sau đây mô tả sự khác biệt về lớp, ví dụ và mối quan tâm giữa các giao thức và mẫu cộng tác đa tác nhân.

	Giao thức – Cách các tác nhân giao tiếp	Mẫu – Cách các tác nhân tổ chức
Lớp	Giao tiếp và cơ sở hạ tầng	Kiến trúc và tổ chức
Mối quan tâm	Định dạng tin nhắn, API và tiêu chuẩn	Quy trình làm việc, vai trò và điều phối
Ví dụ	A2A, MCP, HTTP, v.v.	Tuần tự, phân cấp, ngang hàng, v.v.

Mở rộng an toàn với cá nhân hóa

Việc chuyển từ một nguyên mẫu hoạt động cho một nhà phát triển sang một hệ thống sản xuất phục vụ hàng nghìn người dùng đưa ra các yêu cầu mới về cô lập, bảo mật và cá nhân hóa.

Cô lập phiên là ưu tiên hàng đầu. Cuộc trò chuyện của Người dùng A không thể rò rỉ vào phiên của Người dùng B trong bất kỳ trường hợp nào. Khi hai người dùng đồng thời hỏi các câu hỏi về các dự án, Region hoặc tài khoản khác nhau, các phiên đó phải hoàn toàn độc lập. AgentCore Runtime xử lý điều này bằng cách chạy mỗi phiên trong máy ảo siêu nhỏ (microVM) riêng biệt với tài nguyên tính toán và bộ nhớ chuyên dụng. Khi phiên kết thúc, microVM sẽ chấm dứt. Không có trạng thái chia sẻ nào tồn tại giữa những người dùng.

Cá nhân hóa yêu cầu bộ nhớ tồn tại qua các phiên. Người dùng có sở thích về cách họ muốn thông tin được trình bày. Họ làm việc trên các dự án cụ thể cung cấp ngữ cảnh cho các câu hỏi của họ. Họ sử dụng thuật ngữ và từ viết tắt cụ thể cho vai trò của họ. AgentCore Memory cung cấp cả bộ nhớ ngắn hạn cho lịch sử cuộc trò chuyện và bộ nhớ dài hạn cho các sự kiện, sở thích và tương tác trong quá khứ. Bộ nhớ được phân vùng theo người dùng để ngữ cảnh của mỗi người vẫn riêng tư. Bảo mật và kiểm soát truy cập phải được thực thi trước khi các công cụ thực thi. Người dùng chỉ nên truy cập dữ liệu mà họ có quyền xem. Sơ đồ dưới đây cho thấy cách các thành phần AgentCore hoạt động cùng nhau để giúp thực thi bảo mật ở nhiều lớp.

Khi người dùng tương tác với tác nhân của bạn, họ sẽ xác thực trước thông qua nhà cung cấp danh tính (IdP) của bạn, cho dù đó là Amazon Cognito, Microsoft Entra ID hay Okta. AgentCore Identity nhận mã thông báo xác thực và trích xuất các OAuth claims tùy chỉnh định nghĩa quyền và thuộc tính của người dùng. Các claims này chảy qua AgentCore Runtime đến tác nhân và được cung cấp trong suốt phiên.

Khi tác nhân xác định công cụ nào sẽ gọi, AgentCore Gateway hoạt động như điểm thực thi. Trước khi một công cụ thực thi, Gateway chặn yêu cầu và đánh giá nó dựa trên hai lớp chính sách. AgentCore Policy xác thực xem người dùng cụ thể này có quyền gọi công cụ cụ thể này với các tham số cụ thể này hay không, kiểm tra các chính sách tài nguyên định nghĩa ai có thể truy cập cái gì. Đồng thời, AgentCore Gateway kiểm tra các nhà cung cấp thông tin xác thực (như Google Drive, Dropbox hoặc Outlook) để truy xuất và chèn các thông tin xác thực cần thiết cho các dịch vụ của bên thứ ba. Các bộ chặn Gateway cung cấp một hook bổ sung nơi bạn có thể triển khai logic ủy quyền tùy chỉnh, giới hạn tốc độ hoặc ghi nhật ký kiểm tra trước khi lệnh gọi công cụ tiếp tục.

Chỉ sau khi vượt qua các kiểm tra này, công cụ mới thực thi. Nếu một nhà phân tích cấp dưới cố gắng truy cập dữ liệu lương thưởng của điều hành viên, yêu cầu sẽ bị từ chối tại AgentCore Gateway trước khi nó đến cơ sở dữ liệu của bạn. Nếu người dùng chưa cấp quyền OAuth cho Google Drive của họ, tác nhân sẽ nhận được một lỗi rõ ràng mà nó có thể thông báo lại cho người dùng. Luồng đồng ý của người dùng được xử lý minh bạch; khi một tác nhân cần truy cập vào nhà cung cấp thông tin xác thực lần đầu tiên, hệ thống sẽ nhắc ủy quyền và lưu trữ mã thông báo cho các yêu cầu tiếp theo.

Cách tiếp cận phòng thủ theo chiều sâu này giúp đảm bảo rằng bảo mật được thực thi nhất quán trên các tác nhân và công cụ, bất kể nhóm nào đã xây dựng chúng hoặc các công cụ được lưu trữ ở đâu.

Giám sát trở nên phức tạp hơn ở quy mô lớn. Với hàng nghìn phiên đồng thời, bạn cần các bảng điều khiển hiển thị các mẫu tổng hợp và bạn có thể sử dụng để kiểm tra các tương tác riêng lẻ. AgentCore Observability cung cấp các chỉ số thời gian thực trên người dùng hiển thị mức sử dụng token, phân phối độ trễ, tỷ lệ lỗi và các mẫu gọi công cụ, như trong các hình dưới đây. Khi có điều gì đó bị lỗi đối với một người dùng, bạn có thể theo dõi chính xác những gì đã xảy ra trong phiên cụ thể đó, như trong các hình sau.

AgentCore Runtime cũng lưu trữ các công cụ dưới dạng máy chủ MCP. Điều này giúp giữ cho kiến trúc của bạn theo mô-đun. Các tác nhân khám phá và gọi các công cụ thông qua AgentCore Gateway mà không cần kết nối chặt chẽ. Khi bạn cập nhật triển khai công cụ, các tác nhân sẽ tự động sử dụng phiên bản mới mà không cần thay đổi mã.

Kết hợp tác nhân với mã nguồn xác định

Một trong những quyết định kiến trúc quan trọng nhất mà bạn sẽ đưa ra là khi nào nên dựa vào hành vi tác nhân và khi nào nên sử dụng mã truyền thống. Các tác nhân rất mạnh mẽ nhưng chúng có thể không phù hợp với mọi tác vụ. Hãy dành các tác nhân cho các tác vụ yêu cầu suy luận trên các đầu vào mơ hồ. Hiểu các truy vấn ngôn ngữ tự nhiên, xác định công cụ nào sẽ gọi và diễn giải kết quả trong ngữ cảnh đều có thể hưởng lợi từ khả năng suy luận của các foundation model. Đây là những tác vụ mà mã xác định sẽ yêu cầu liệt kê hàng nghìn trường hợp có thể. Sử dụng mã truyền thống cho các phép tính, xác thực và logic dựa trên quy tắc. Tăng trưởng doanh thu là một công thức. Xác thực ngày tháng tuân theo các mẫu. Các quy tắc nghiệp vụ là các câu lệnh điều kiện. Bạn không cần một mô hình ngôn ngữ để tính toán “trừ quý 2 từ quý 3 và chia cho quý 2”. Hãy viết một hàm Python. Nó có thể chạy trong mili giây mà không tốn thêm chi phí và tạo ra cùng một câu trả lời mỗi lần.

Kiến trúc đúng đắn có các tác nhân điều phối các hàm mã. Khi người dùng hỏi, “Tăng trưởng của chúng ta ở EMEA quý này là bao nhiêu?”, tác nhân sử dụng suy luận để hiểu ý định và xác định dữ liệu nào cần lấy. Nó gọi một hàm xác định để thực hiện phép tính. Sau đó, nó sử dụng suy luận một lần nữa để giải thích kết quả bằng ngôn ngữ tự nhiên.

Hãy so sánh số lượng lệnh gọi mô hình ngôn ngữ lớn (LLM), số lượng token và độ trễ của hai truy vấn để “Tạo báo cáo chi tiêu cho tháng tới”. Trong truy vấn đầu tiên, get_current_date() được hiển thị dưới dạng một công cụ tác nhân và trong truy vấn thứ hai, ngày hiện tại được truyền dưới dạng thuộc tính cho tác nhân:

	get_current_date() dưới dạng một công cụ	Ngày hiện tại được truyền dưới dạng thuộc tính
Truy vấn	“Tạo báo cáo chi tiêu cho tháng tới”	“Tạo báo cáo chi tiêu cho tháng tới”
Hành vi tác nhân	Tạo kế hoạch gọi get_current_date() Tính toán tháng tới dựa trên giá trị của ngày hiện tại Gọi create_report() với tháng tới làm tham số và tạo phản hồi cuối cùng	Sử dụng mã để lấy ngày hiện tại Gọi tác nhân với ngày hôm nay làm thuộc tính Gọi create_booking() với tháng tới (được suy luận thông qua suy luận LLM) làm tham số và tạo phản hồi cuối cùng
Độ trễ	12 giây	9 giây
Số lượng lệnh gọi LLM	Bốn lệnh gọi	Ba lệnh gọi
Tổng số token (đầu vào + đầu ra)	Khoảng 8.500 token	Khoảng 6.200 token

Ngày hiện tại là thứ bạn có thể dễ dàng lấy bằng mã. Sau đó, bạn có thể truyền nó vào ngữ cảnh tác nhân của mình tại thời điểm gọi, dưới dạng thuộc tính. Cách tiếp cận thứ hai nhanh hơn, ít tốn kém hơn và chính xác hơn. Nhân điều này lên hàng nghìn truy vấn và sự khác biệt trở nên đáng kể. Liên tục đo lường chi phí so với giá trị. Nếu mã xác định giải quyết vấn đề một cách đáng tin cậy, hãy sử dụng nó. Nếu bạn cần suy luận hoặc hiểu ngôn ngữ tự nhiên, hãy sử dụng một tác nhân. Sai lầm phổ biến là cho rằng mọi thứ đều phải là tác nhân. Câu trả lời đúng là các tác nhân cộng với mã hoạt động cùng nhau.

Thiết lập các phương pháp kiểm thử liên tục

Triển khai vào sản xuất không phải là vạch đích. Đó là vạch xuất phát. Các tác nhân hoạt động trong một môi trường thay đổi liên tục. Hành vi người dùng phát triển. Logic nghiệp vụ thay đổi. Hành vi mô hình có thể trôi dạt. Bạn cần kiểm thử liên tục để nắm bắt những thay đổi này trước khi chúng ảnh hưởng đến người dùng. Xây dựng một pipeline kiểm thử liên tục chạy trên mỗi bản cập nhật. Duy trì một bộ kiểm thử với các truy vấn đại diện bao gồm các trường hợp phổ biến và các trường hợp ngoại lệ. Khi bạn thay đổi một prompt, thêm một công cụ hoặc chuyển đổi mô hình, pipeline sẽ chạy bộ kiểm thử của bạn và chấm điểm kết quả. Nếu độ chính xác giảm xuống dưới ngưỡng của bạn, việc triển khai sẽ tự động thất bại. Điều này giúp ngăn chặn các hồi quy. Sử dụng kiểm thử A/B để xác thực các thay đổi trong sản xuất. Khi bạn muốn thử một mô hình mới hoặc một chiến lược prompt khác, đừng chuyển đổi tất cả người dùng cùng một lúc. Ví dụ, định tuyến 10% lưu lượng truy cập đến phiên bản mới. So sánh hiệu suất trong một tuần. Đo lường độ chính xác, độ trễ, chi phí và sự hài lòng của người dùng. Nếu phiên bản mới hoạt động tốt hơn, hãy dần dần triển khai nó. Nếu không, hãy hoàn nguyên. AgentCore Runtime cung cấp hỗ trợ tích hợp cho việc tạo phiên bản và phân chia lưu lượng truy cập. Giám sát sự trôi dạt trong sản xuất. Các mẫu người dùng thay đổi theo thời gian. Các câu hỏi hiếm gặp trở nên phổ biến. Các sản phẩm mới ra mắt. Thuật ngữ thay đổi. Liên tục lấy mẫu các tương tác trực tiếp và chấm điểm chúng theo các chỉ số chất lượng của bạn. Khi bạn phát hiện sự trôi dạt, chẳng hạn như độ chính xác giảm từ 92% xuống 84% trong hai tuần, hãy điều tra và giải quyết nguyên nhân gốc rễ.

AgentCore Evaluations đơn giản hóa cơ chế chạy các đánh giá này. Nó cung cấp hai chế độ đánh giá để phù hợp với các giai đoạn khác nhau trong vòng đời phát triển của bạn. Đánh giá theo yêu cầu cho phép bạn đánh giá hiệu suất tác nhân dựa trên một tập dữ liệu kiểm thử được xác định trước, chạy bộ kiểm thử của bạn trước khi triển khai, so sánh hai phiên bản prompt cạnh nhau hoặc xác thực một thay đổi mô hình so với các ví dụ ground truth của bạn. Đánh giá trực tuyến giám sát lưu lượng truy cập sản xuất trực tiếp liên tục, lấy mẫu và chấm điểm các tương tác người dùng thực để phát hiện sự suy giảm chất lượng khi nó xảy ra. Cả hai chế độ đều hoạt động với các framework phổ biến bao gồm Strands và LangGraph thông qua OpenTelemetry và OpenInference instrumentation. Khi tác nhân của bạn thực thi, các trace sẽ tự động được ghi lại, chuyển đổi sang định dạng thống nhất và chấm điểm bằng các kỹ thuật LLM-as-Judge. Bạn có thể sử dụng các trình đánh giá tích hợp cho các khía cạnh chất lượng phổ biến như tính hữu ích, tính gây hại và độ chính xác. Đối với các yêu cầu cụ thể theo miền, hãy tạo các trình đánh giá tùy chỉnh với logic chấm điểm của riêng bạn. Các hình dưới đây cho thấy một ví dụ về đánh giá chỉ số được hiển thị trên AgentCore Evaluations.

Thiết lập các cơ chế rollback tự động. Nếu các chỉ số quan trọng vượt quá ngưỡng, hãy tự động hoàn nguyên về phiên bản tốt đã biết trước đó. Ví dụ, nếu tỷ lệ ảo giác tăng đột biến trên 5%, hãy rollback và cảnh báo nhóm. Đừng chờ người dùng báo cáo vấn đề.

Chiến lược kiểm thử của bạn nên bao gồm các yếu tố sau:

• Kiểm thử hồi quy tự động trên mỗi thay đổi
• Kiểm thử A/B cho các bản cập nhật lớn
• Lấy mẫu và đánh giá liên tục trong sản xuất
• Phát hiện sự trôi dạt với các cảnh báo tự động
• Rollback tự động khi chất lượng giảm sút

Với các tác nhân, việc kiểm thử không dừng lại vì môi trường không ngừng thay đổi.

Xây dựng năng lực tổ chức

Tác nhân đầu tiên của bạn trong sản xuất là một thành tựu. Nhưng giá trị doanh nghiệp đến từ việc mở rộng khả năng này trong toàn tổ chức. Điều đó đòi hỏi tư duy nền tảng, không chỉ tư duy dự án.

Thu thập phản hồi của người dùng và các mẫu tương tác liên tục. Theo dõi các bảng điều khiển quan sát của bạn để xác định truy vấn nào thành công, truy vấn nào thất bại và những trường hợp ngoại lệ nào xuất hiện trong sản xuất mà không có trong bộ kiểm thử của bạn. Sử dụng dữ liệu này để mở rộng tập dữ liệu ground truth của bạn. Những gì bắt đầu với năm mươi trường hợp kiểm thử sẽ tăng lên hàng trăm dựa trên các tương tác sản xuất thực tế.

Thiết lập một nhóm nền tảng để thiết lập các tiêu chuẩn và cung cấp cơ sở hạ tầng chia sẻ. Nhóm nền tảng:

• Duy trì một danh mục các công cụ được phê duyệt đã được các nhóm bảo mật kiểm tra.
• Cung cấp hướng dẫn về khả năng quan sát, đánh giá và các phương pháp triển khai.
• Chạy các bảng điều khiển tập trung hiển thị hiệu suất trên các tác nhân. Khi một nhóm mới muốn xây dựng một tác nhân.

Khi một nhóm mới muốn xây dựng một tác nhân, họ bắt đầu với bộ công cụ nền tảng. Khi các nhóm hoàn thành việc triển khai từ các công cụ và/hoặc tác nhân của họ vào sản xuất, họ có thể đóng góp trở lại nền tảng. Ở quy mô lớn, nhóm nền tảng cung cấp các tài sản và tiêu chuẩn có thể tái sử dụng cho tổ chức và các nhóm tạo ra các tài sản của riêng họ trong khi đóng góp trở lại nền tảng với các tài sản đã được xác thực.

Triển khai giám sát tập trung trên các tác nhân trong tổ chức. Một bảng điều khiển hiển thị các tác nhân, các phiên và chi phí. Khi mức sử dụng token tăng đột biến bất ngờ, các nhà lãnh đạo nền tảng có thể thấy ngay lập tức. Họ có thể xem xét theo nhóm, theo tác nhân hoặc theo khoảng thời gian để hiểu điều gì đã thay đổi.

Thúc đẩy sự hợp tác giữa các nhóm để các nhóm có thể học hỏi lẫn nhau. Ba nhóm không nên xây dựng ba phiên bản của một trình kết nối cơ sở dữ liệu. Thay vào đó, họ nên chia sẻ các công cụ thông qua AgentCore Gateway, chia sẻ các chiến lược đánh giá và tổ chức các phiên thường xuyên nơi các nhóm trình diễn các tác nhân của họ và thảo luận về các thách thức. Bằng cách này, các vấn đề chung sẽ nổi lên và các giải pháp chia sẻ sẽ xuất hiện.

Mô hình mở rộng quy mô tổ chức là một quá trình bò, đi, chạy:

• Giai đoạn bò. Triển khai tác nhân đầu tiên nội bộ cho một nhóm thử nghiệm nhỏ. Tập trung vào việc học hỏi và lặp lại. Thất bại là rẻ.
• Giai đoạn đi. Triển khai tác nhân cho một nhóm người dùng bên ngoài được kiểm soát. Nhiều người dùng hơn, nhiều phản hồi hơn, nhiều trường hợp ngoại lệ được phát hiện hơn. Đầu tư vào khả năng quan sát và đánh giá sẽ mang lại hiệu quả.
• Giai đoạn chạy. Mở rộng tác nhân cho người dùng bên ngoài một cách tự tin. Các khả năng nền tảng cho phép các nhóm khác xây dựng các tác nhân của riêng họ nhanh hơn. Năng lực tổ chức được nhân lên.

Đây là cách bạn có thể đi từ một nhà phát triển xây dựng một tác nhân đến hàng chục nhóm xây dựng hàng chục tác nhân với chất lượng nhất quán, cơ sở hạ tầng chia sẻ và tốc độ tăng tốc.

Kết luận

Việc xây dựng các tác nhân AI sẵn sàng cho sản xuất đòi hỏi nhiều hơn là kết nối một foundation model với các API của bạn. Nó đòi hỏi các phương pháp kỹ thuật kỷ luật trong toàn bộ vòng đời, bao gồm:

• Bắt đầu nhỏ với một vấn đề được xác định rõ ràng
• Trang bị công cụ giám sát ngay từ ngày đầu tiên
• Xây dựng chiến lược công cụ có chủ đích
• Tự động hóa đánh giá của bạn
• Phân tách độ phức tạp bằng kiến trúc đa tác nhân
• Mở rộng an toàn với cá nhân hóa
• Kết hợp tác nhân với mã nguồn xác định
• Kiểm thử liên tục
• Xây dựng năng lực tổ chức với tư duy nền tảng

Amazon Bedrock AgentCore cung cấp các dịch vụ bạn cần để triển khai các phương pháp này:

• AgentCore Runtime lưu trữ các tác nhân và công cụ trong các môi trường cô lập
• AgentCore Memory cho phép tương tác cá nhân hóa
• AgentCore Identity và AgentCore Policy giúp thực thi bảo mật
• AgentCore Observability cung cấp khả năng hiển thị
• AgentCore Evaluations cho phép đánh giá chất lượng liên tục
• AgentCore Gateway hợp nhất giao tiếp giữa các tác nhân và công cụ bằng cách sử dụng các giao thức tiêu chuẩn
• AgentCore Browser cung cấp một trình duyệt dựa trên đám mây an toàn cho phép các tác nhân AI tương tác với các trang web và AgentCore Code Interpreter cho phép các tác nhân AI viết và thực thi mã an toàn hơn trong các môi trường sandbox.

Những phương pháp hay nhất này không phải là lý thuyết. Chúng đến từ kinh nghiệm của các nhóm xây dựng các tác nhân sản xuất xử lý khối lượng công việc thực tế. Sự khác biệt giữa các tác nhân gây ấn tượng trong các bản demo và các tác nhân mang lại giá trị kinh doanh nằm ở việc thực hiện các nguyên tắc cơ bản này.

Để tìm hiểu thêm, hãy xem tài liệu của Amazon Bedrock AgentCore và bắt đầu với các mẫu mã của chúng tôi và các workshop thực hành để bắt đầu và tìm hiểu sâu về AgentCore.

---

Về tác giả

Maira Ladeira Tanke là Tech Lead cho Agentic AI tại AWS, nơi cô hỗ trợ khách hàng trong hành trình phát triển các hệ thống AI tự động. Với hơn 10 năm kinh nghiệm trong AI/ML, Maira hợp tác với các khách hàng doanh nghiệp để đẩy nhanh việc áp dụng các ứng dụng tác nhân sử dụng Amazon Bedrock AgentCore và Strands Agents, giúp các tổ chức khai thác sức mạnh của các foundation model để thúc đẩy đổi mới và chuyển đổi kinh doanh. Trong thời gian rảnh rỗi, Maira thích đi du lịch, chơi với mèo và dành thời gian cho gia đình ở một nơi ấm áp.

Kosti Vasilakakis là Principal PM tại AWS trong nhóm Agentic AI, nơi anh đã dẫn đầu việc thiết kế và phát triển một số dịch vụ Bedrock AgentCore từ đầu, bao gồm Runtime, Browser, Code Interpreter và Identity. Trước đây, anh đã làm việc trên Amazon SageMaker từ những ngày đầu, ra mắt các khả năng AI/ML hiện đang được hàng nghìn công ty trên toàn thế giới sử dụng. Trước đó trong sự nghiệp của mình, Kosti là một nhà khoa học dữ liệu. Ngoài công việc, anh xây dựng các tự động hóa năng suất cá nhân, chơi tennis và tận hưởng cuộc sống cùng vợ và các con.