Tác giả: Alan Oberto Jimenez
Ngày phát hành: 26 MAR 2026
Chuyên mục: Architecture, Intermediate (200), Kiro

Nếu bạn đang kiến trúc các hệ thống đám mây để phát triển AI trên AWS, bạn có thể đã nhận ra rằng các kiến trúc truyền thống tạo ra ma sát cho các tác nhân AI. Nhiều nhóm đám mây đang thử nghiệm với các trợ lý mã hóa AI nhưng nhanh chóng phát hiện ra khoảng cách giữa những gì các công cụ này hứa hẹn và những gì kiến trúc của họ cho phép. Khi một tác nhân AI tạo mã, thường mất vài phút – hoặc vài giờ – trước khi bạn có thể xác thực xem thay đổi đó có thực sự hoạt động hay không. Chu kỳ triển khai chậm, các dịch vụ liên kết chặt chẽ và cơ sở mã không rõ ràng biến mỗi lần lặp thành một bài tập có độ ma sát cao. Kết quả là, các tác nhân AI gặp khó khăn trong việc hoạt động tự chủ, và các nhà phát triển buộc phải quay lại các vòng lặp xác thực thủ công.

Bài viết này được viết cho các kiến trúc sư đám mây muốn loại bỏ ma sát đó. Nó tập trung vào phát triển tác nhân (agentic development), một mô hình trong đó một tác nhân AI không chỉ gợi ý các đoạn mã – nó viết, kiểm thử, triển khai và tinh chỉnh mã thông qua các chu kỳ phản hồi nhanh chóng. Để làm được điều đó, cả kiến trúc hệ thống và kiến trúc cơ sở mã của bạn phải được thiết kế để hỗ trợ xác thực nhanh, lặp lại an toàn và ý định rõ ràng.

Trong bài đăng này, chúng tôi trình bày cách kiến trúc các hệ thống AWS cho phép các tác nhân AI lặp lại nhanh chóng thông qua các mẫu thiết kế cho cả kiến trúc hệ thống và cấu trúc cơ sở mã. Đầu tiên, chúng tôi xem xét các vấn đề kiến trúc đang hạn chế phát triển tác nhân hiện nay. Sau đó, chúng tôi đi sâu vào các mẫu kiến trúc hệ thống hỗ trợ thử nghiệm nhanh chóng, tiếp theo là các mẫu cơ sở mã giúp các tác nhân AI hiểu, sửa đổi và xác thực các ứng dụng của bạn một cách tự tin.

Tại sao các kiến trúc truyền thống cản trở AI agent

Hầu hết các kiến trúc đám mây được thiết kế cho phát triển do con người điều khiển. Chúng giả định các môi trường tồn tại lâu dài, kiểm thử thủ công và triển khai không thường xuyên. Trong một quy trình làm việc tác nhân, những giả định đó bị phá vỡ.

Các tác nhân AI phải liên tục xác thực các thay đổi. Khi mỗi lần kiểm thử yêu cầu cấp phát tài nguyên đám mây, chờ pipeline hoặc gỡ lỗi các lỗi chỉ xảy ra khi triển khai, các vòng lặp phản hồi trở nên quá chậm. Sự liên kết chặt chẽ giữa logic nghiệp vụ và các dịch vụ đám mây làm phức tạp thêm việc kiểm thử cục bộ, trong khi cấu trúc dự án không nhất quán khiến tác nhân khó hiểu được các thay đổi thuộc về đâu.

Nếu không có sự hỗ trợ về kiến trúc, AI tác nhân tạo ra nhiều rủi ro hơn là giá trị. Giải pháp không phải là các prompt tốt hơn, mà là một kiến trúc coi phản hồi nhanh và ranh giới rõ ràng là những mối quan tâm hàng đầu. Ma sát kiến trúc này không chỉ bất tiện, nó còn hạn chế cơ bản hiệu quả của tác nhân AI. Dưới đây là cách thiết kế lại kiến trúc của bạn để giúp mở khóa tiềm năng của AI tác nhân.

Kiến trúc hệ thống cho các vòng lặp phản hồi tác nhân nhanh

Phát triển tác nhân phụ thuộc vào tốc độ phản hồi. Tác nhân càng nhanh quan sát được tác động của một thay đổi, nó càng có thể tinh chỉnh đầu ra của mình hiệu quả hơn. Kiến trúc hệ thống đóng một vai trò quyết định ở đây.

Hình 1: Kiến trúc cấp cao cho phép phát triển tác nhân: các vòng lặp kiểm thử cục bộ, stack kiểm thử tạm thời và pipeline tích hợp liên tục và phân phối liên tục (CI/CD) được kích hoạt bởi AI

Giả lập cục bộ làm đường dẫn phản hồi mặc định

Bất cứ khi nào có thể, kiến trúc của bạn nên cho phép các tác nhân AI kiểm thử các thay đổi cục bộ trước khi chạm vào tài nguyên đám mây. AWS cung cấp một số công cụ giúp điều này trở nên khả thi.

Ví dụ, các ứng dụng serverless được xây dựng bằng AWS Lambda và Amazon API Gateway có thể được giả lập cục bộ bằng cách sử dụng AWS Serverless Application Model (AWS SAM). Với lệnh sam local start-api, một tác nhân AI có thể gọi các hàm Lambda thông qua một API Gateway được giả lập cục bộ, quan sát phản hồi ngay lập tức và lặp lại trong vài giây thay vì vài phút.

Container mang lại lợi ích tương tự cho các dịch vụ chạy trên Amazon Elastic Container Service (Amazon ECS) hoặc AWS Fargate. Bằng cách xây dựng và chạy cùng một hình ảnh container cục bộ, một tác nhân có thể xác thực hành vi ứng dụng trước khi triển khai lên đám mây. Đối với tính bền vững của dữ liệu, Amazon DynamoDB Local cho phép tác nhân kiểm thử các hoạt động tạo, đọc, cập nhật và xóa (CRUD) đối với một cơ sở dữ liệu cục bộ phản ánh API DynamoDB.

Lưu ý: Giả lập cục bộ giảm thời gian lặp lại, cho phép mã do AI tạo ra được xác thực trong vài giây và có khả năng giảm chi phí cũng như rủi ro thử nghiệm.

Phát triển ngoại tuyến cho khối lượng công việc dữ liệu và phân tích

Nhiều khối lượng công việc phù hợp với kiểm thử yêu cầu-phản hồi, nhưng các pipeline xử lý dữ liệu thường liên quan đến các tập dữ liệu lớn và thực thi phân tán. Ngay cả ở đây, các quy trình làm việc tác nhân cũng được hưởng lợi từ phản hồi cục bộ.

AWS Glue cung cấp các hình ảnh Docker cho phép các job AWS Glue chạy cục bộ với các thư viện AWS Glue ETL. Một tác nhân AI có thể xác thực các phép biến đổi đối với các tập dữ liệu mẫu, kiểm tra kết quả trung gian và chỉ chuyển lên đám mây để kiểm thử quy mô. Mẫu tương tự áp dụng cho các khối lượng công việc dữ liệu và học máy (ML) khác: cô lập logic, kiểm thử cục bộ với dữ liệu giảm, và sau đó đưa mã đã xác thực lên các dịch vụ được quản lý.

Lưu ý: Phát triển ngoại tuyến rút ngắn các vòng lặp phản hồi cho khối lượng công việc dữ liệu và giảm các lần chạy đám mây không cần thiết trong quá trình lặp lại ban đầu.

Kiểm thử lai với tài nguyên đám mây nhẹ

Một số dịch vụ AWS không thể được giả lập hoàn toàn cục bộ. Trong những trường hợp này, mục tiêu không phải là tránh đám mây, mà là giữ cho phản hồi đám mây nhẹ nhàng.

Đối với các hệ thống hướng sự kiện sử dụng Amazon Simple Notification Service (Amazon SNS) hoặc Amazon Simple Queue Service (Amazon SQS), bạn có thể định nghĩa các stack phát triển tối thiểu bằng cách sử dụng các công cụ cơ sở hạ tầng dưới dạng mã (IaC) như AWS CloudFormation hoặc AWS Cloud Development Kit (AWS CDK). Một tác nhân AI có thể triển khai các tài nguyên nhỏ, cô lập, gọi chúng thông qua AWS SDK và xác thực hành vi mà không cần cấp phát toàn bộ môi trường.

Cách tiếp cận lai này coi đám mây như một phụ thuộc kiểm thử khác – được sử dụng một cách tiết kiệm và có thể dự đoán được.

Lưu ý: Kiểm thử lai xác nhận hành vi dịch vụ thực tế sớm trong khi vẫn giữ việc sử dụng đám mây tập trung và được kiểm soát.

Môi trường xem trước và thiết kế ưu tiên hợp đồng

Phản hồi nhanh không dừng lại ở kiểm thử cục bộ. Xác thực end-to-end vẫn quan trọng, đặc biệt khi nhiều dịch vụ tương tác.

Môi trường xem trước là các stack tồn tại ngắn được triển khai theo yêu cầu để xác thực. Được định nghĩa thông qua IaC, chúng cho phép một tác nhân AI triển khai một ứng dụng hoàn chỉnh, chạy các kiểm thử cơ bản (smoke tests) và loại bỏ mọi thứ khi hoàn thành. Khi kết hợp với thiết kế ưu tiên hợp đồng – nơi các API được định nghĩa trước bằng các đặc tả OpenAPI – các tác nhân có thể xác thực các tích hợp ngay cả trước khi tất cả các dịch vụ được triển khai.

Lưu ý: Môi trường xem trước có thể giảm rủi ro tích hợp và cho phép các thay đổi do AI tạo ra được xác thực an toàn trước khi đến môi trường sản xuất.

Kiến trúc cơ sở mã cho phát triển thân thiện với AI

Kiến trúc hệ thống tăng tốc phản hồi, nhưng kiến trúc cơ sở mã quyết định liệu một tác nhân AI có thể hiểu được những gì nó đang thay đổi hay không.

Cấu trúc hướng miền với ranh giới rõ ràng

Chúng tôi khuyến nghị phát triển tác nhân khi kho lưu trữ của bạn phản ánh ý định kiến trúc rõ ràng. Một cấu trúc hướng miền lấy cảm hứng từ Domain-Driven Design (DDD) tách biệt logic nghiệp vụ cốt lõi khỏi điều phối ứng dụng và các mối quan tâm về cơ sở hạ tầng.

Trong thực tế, điều này thường có nghĩa là tổ chức mã thành các lớp có thể dự đoán được như /domain, /application và /infrastructure. Lớp miền chứa các quy tắc nghiệp vụ không có phụ thuộc Amazon. Mã cơ sở hạ tầng xử lý các tích hợp với các dịch vụ như Amazon DynamoDB hoặc Amazon SNS. Sự tách biệt này cho phép các tác nhân AI sửa đổi logic nghiệp vụ và xác thực nó cục bộ mà không cần chạm vào mã cụ thể của đám mây.

Các mẫu như kiến trúc hình lục giác củng cố sự tách biệt này bằng cách coi các hệ thống bên ngoài như các bộ điều hợp thay vì các phụ thuộc.

Lưu ý: Ranh giới rõ ràng có thể giảm các tác dụng phụ không mong muốn và làm cho các thay đổi do AI tạo ra dễ hiểu và kiểm thử hơn.

Mã hóa ý định kiến trúc bằng các quy tắc dự án

Ngay cả các kho lưu trữ được cấu trúc tốt cũng được hưởng lợi từ hướng dẫn rõ ràng. Kiro hỗ trợ các tệp điều hướng – các tệp Markdown được lưu trữ dưới .kiro/steering/ – mô tả các ràng buộc kiến trúc và quy ước mã hóa.

Ví dụ, một quy tắc có thể nêu rằng việc truy cập cơ sở dữ liệu phải thông qua các lớp kho lưu trữ trong lớp cơ sở hạ tầng. Tác nhân tự động tham khảo các quy tắc này, giảm nhu cầu phải lặp lại các ràng buộc trong mỗi prompt và giúp giữ cho mã được tạo ra phù hợp với kiến trúc của bạn.

Lưu ý: Các quy tắc dự án giảm sự sai lệch kiến trúc và giúp duy trì tính nhất quán khi các tác nhân AI hoạt động tự chủ hơn.

Kiểm thử như các đặc tả có thể thực thi

Trong các quy trình làm việc tác nhân, kiểm thử không chỉ bắt lỗi hồi quy, chúng còn định nghĩa hành vi chấp nhận được. Một chiến lược kiểm thử phân lớp hoạt động đặc biệt tốt:

• Kiểm thử đơn vị (Unit tests) xác thực logic miền một cách cô lập và chạy nhanh, làm cho chúng lý tưởng cho các lần lặp lại thường xuyên do AI điều khiển.
• Kiểm thử hợp đồng (Contract tests) xác minh rằng các dịch vụ tuân thủ các giao diện đã thỏa thuận, bắt các thay đổi gây lỗi sớm.
• Kiểm thử cơ bản (Smoke tests) chạy trên các môi trường đã triển khai để phát hiện các vấn đề về cấu hình hoặc quyền chỉ xuất hiện khi chạy, chẳng hạn như thiếu quyền AWS Identity and Access Management (IAM).

Các kiểm thử được viết tốt cũng đóng vai trò là tài liệu. Khi một kiểm thử thất bại, tác nhân có thể suy ra hành vi mong đợi và tinh chỉnh các thay đổi của nó cho phù hợp.

Lưu ý: Các kiểm thử cung cấp xác thực nhanh chóng, khách quan cho mã do AI tạo ra và giảm rủi ro các lỗi tích hợp tinh vi.

Monorepo và tài liệu có thể đọc bằng máy

Các tác nhân AI hoạt động hiệu quả hơn khi chúng có ngữ cảnh rộng. Một monorepo cho phép tác nhân điều hướng qua các dịch vụ, hiểu các mẫu chung và đánh giá tác động của các thay đổi trên toàn hệ thống. Trong kho lưu trữ đó, tài liệu ngắn gọn và có cấu trúc là điều cần thiết. Các tệp như AGENT.md có thể giải thích các nguyên tắc và ràng buộc kiến trúc, trong khi RUNBOOK.md và CONTRIBUTING.md mô tả các quy trình làm việc vận hành và phát triển. Các định dạng có thể đọc bằng máy, chẳng hạn như YAML hoặc các tệp cấu hình, dễ dàng hơn cho các tác nhân diễn giải so với văn xuôi dài dòng.

Kiro có thể sử dụng các tài liệu điều hướng nền tảng – tóm tắt về cấu trúc, công nghệ và hướng dẫn sản phẩm – để giúp tác nhân duy trì nhận thức tình huống khi dự án phát triển.

Lưu ý: Ngữ cảnh chia sẻ cải thiện chất lượng các thay đổi do AI tạo ra và giảm nhu cầu sửa chữa thủ công.

Tích hợp tác nhân an toàn vào các pipeline phân phối

Khi các tác nhân AI trở nên có khả năng hơn, quản trị vẫn là điều cần thiết. Các pipeline tích hợp liên tục và phân phối liên tục (CI/CD) nên bao gồm các hàng rào bảo vệ như yêu cầu thực thi kiểm thử, đánh giá tự động và bảo vệ nhánh. Theo thời gian, khi sự tự tin tăng lên, bạn có thể mở rộng quyền tự chủ của tác nhân trong khi vẫn giữ con người trong vòng lặp cho các quyết định có tác động cao. Sự cân bằng này cho phép AI tăng tốc công việc thường xuyên mà không làm tăng rủi ro vận hành.

Kết luận

Phát triển AI tác nhân không thành công một cách ngẫu nhiên. Nó đòi hỏi các kiến trúc ưu tiên phản hồi nhanh, ranh giới rõ ràng và ý định rõ ràng. Kết hợp giả lập cục bộ, kiểm thử đám mây nhẹ và môi trường xem trước với cấu trúc hướng miền, kiểm thử phân lớp và tài liệu có thể đọc bằng máy tạo ra một môi trường nơi các tác nhân AI có thể hoạt động hiệu quả và an toàn. Các công cụ như Kiro giúp thu hẹp khoảng cách giữa các quyết định thiết kế của con người và việc thực thi AI tự chủ. Khi kiến trúc phù hợp với các quy trình làm việc tác nhân, các tác nhân AI trở thành những yếu tố nhân lên sức mạnh thực sự, xử lý phát triển lặp lại với tốc độ trong khi nhóm của bạn tập trung vào thiết kế và đổi mới cấp cao hơn.

Để tìm hiểu thêm về cách AWS có thể giúp tổ chức của bạn triển khai các giải pháp tác nhân, hãy truy cập AWS Agentic AI.

---

Về tác giả

Alan Oberto Jimenez

Alan Oberto Jimenez là một Kiến trúc sư Ứng dụng tập trung vào việc thiết kế và xây dựng các ứng dụng hiện đại, cloud-native được hỗ trợ bởi trí tuệ nhân tạo. Anh chuyên phát triển các giải pháp có khả năng mở rộng trên đám mây bằng cách sử dụng các công cụ dựa trên AI, với chuyên môn sâu về các công nghệ tác nhân và quy trình làm việc tự chủ. Alan đam mê tận dụng AI để đơn giản hóa và tăng tốc vòng đời phát triển phần mềm, làm cho nó hiệu quả hơn, dễ tiếp cận hơn và có tác động lớn hơn đối với các nhà phát triển và tổ chức. Anh thích chia sẻ những hiểu biết thực tế và các phương pháp tiếp cận đổi mới để giúp những người khác xây dựng các ứng dụng thông minh, dựa trên đám mây.