AWS ra mắt trình mô phỏng cục bộ được viết hoàn toàn bởi các tác tử AI tự hành

Ngày 11 tháng 11 năm 2026, AWS ra mắt AWS Emulator, một trình mô phỏng cục bộ đã được cung cấp rộng rãi, được xây dựng từ 438 mô hình API của AWS, bao phủ hơn 200 dịch vụ. Các tác tử AI tự hành viết và kiểm thử mã nguồn, giúp nhà phát triển và tác tử lập trình thử nghiệm API của AWS trên máy của mình mà không cần tài khoản AWS.

AWS CLI, AWS SDK và các tác tử lập trình kết nối qua một điểm cuối HTTPS cục bộ, sử dụng cùng các API như khi làm việc trên đám mây. Các biến môi trường chuyển hướng những công cụ này đến máy của người dùng, nhờ đó mã ứng dụng không cần thay đổi. Bài đăng ra mắt của AWS nêu chi tiết các gói RPM và Debian dành cho Linux, Docker trên macOS và Windows, cùng chế độ nhúng dành cho các bài kiểm thử Rust. Không có phí dịch vụ bổ sung, dù khách hàng vẫn phải trả phí cho tài nguyên AWS mà họ triển khai trên đám mây.

Đối với các tác tử lập trình, trình mô phỏng đưa hạ tầng AWS vào một vòng lặp ghi-chạy-đọc: tác tử có thể tạo tài nguyên, kiểm tra kết quả rồi sửa đổi mã mà không phải chờ triển khai lên một khu vực AWS. Tài liệu AWS cũng liệt kê máy chủ phát triển và môi trường tích hợp liên tục là những môi trường có thể dùng trình mô phỏng; các yêu cầu sẽ được gửi đến tài nguyên mô phỏng thay vì AWS.

Ba nhóm tác tử xây dựng và duy trì mã nguồn

Matthew Goldberg, kỹ sư chính cấp cao tại AWS, cho biết trong bài viết về công việc kỹ thuật rằng nhóm của ông không viết cũng không rà soát mã nguồn của trình mô phỏng. Thay vào đó, con người xây dựng hệ thống hỗ trợ cho công việc này, gồm các bản đặc tả, bộ công cụ kiểm thử, các cổng kiểm soát trước khi hợp nhất mã và quy trình phát hành. Dự án khởi đầu khi tác tử lập trình Kiro tạo ra một trình mô phỏng Amazon SQS dùng được ở mức cơ bản trong khoảng 15 phút, sau khi nhận yêu cầu viết các bài kiểm thử, xác thực chúng với AWS thật và xây dựng một bản triển khai trong bộ nhớ có thể vượt qua các bài kiểm thử. Sau đó, Goldberg yêu cầu Kiro mở rộng bản mẫu trong một dịp cuối tuần; để biến nó thành một sản phẩm vững chắc, cần có các cơ chế bảo vệ đi kèm.

Hiện nay, ba nhóm tác tử với phạm vi nhiệm vụ được giới hạn cùng phân chia công việc. Nhóm viết bài kiểm thử xây dựng các kịch bản dựa trên những mô hình API công khai và xác thực chúng với AWS thật. Nhóm tìm lỗi chạy lại các bài kiểm thử và gom nhóm những lỗi có thể cùng bắt nguồn từ một nguyên nhân, còn các tác tử sửa lỗi xử lý mỗi tác tử một vấn đề. Goldberg cho biết có hàng chục nghìn bài kiểm thử độ trung thực; mỗi ngày, hàng nghìn vấn đề được khắc phục trong khi hàng trăm tác tử làm việc đồng thời.

Mọi bản sửa lỗi được đề xuất đều phải biên dịch thành công và vượt qua các bước kiểm tra tự động về tiêu chuẩn lập trình, bảo mật và độ trung thực trước khi được hợp nhất. Một tác tử bảo mật độc lập rà soát các thay đổi theo hướng đối kháng trong quá trình phát triển và một lần nữa trong quy trình phát hành. Goldberg viết: “Nếu không có cổng kiểm soát trước khi hợp nhất này, chúng tôi sẽ không tin tưởng vào những gì các tác tử đang xây dựng.”

Sau đó, các thay đổi được chuyển qua AWS CodeCommit và CodePipeline trước khi công bố trên GitHub. Kho mã nguồn công khai hiển thị lịch sử commit cùng các thư mục riêng dành cho những vấn đề về độ trung thực đã giải quyết và chưa giải quyết. AWS công bố mã nguồn theo CC0, một tuyên bố hiến tặng vào phạm vi công cộng, ngoại trừ mã của nhà cung cấp được cấp phép theo Apache 2.0; kho mã nguồn không nhận các yêu cầu kéo, dù người dùng có thể báo lỗi và những điểm chưa khớp về độ trung thực thông qua GitHub Issues.

Điểm độ trung thực xác định giới hạn

Một bài kiểm thử độ trung thực là một quy trình ngắn được đối chiếu với AWS thật. Để vượt qua, trình mô phỏng phải khớp với phản hồi của từng lệnh gọi, bao gồm mã trạng thái, nội dung phản hồi, mã lỗi và thông báo lỗi chính xác, cũng như tài nguyên và dữ liệu mà quy trình tạo ra. Các thao tác chưa được triển khai trả về HTTP 501 (Chưa triển khai), nhờ đó lỗi xuất hiện ngay lập tức. Mỗi bản phát hành đều kèm số lượng bài kiểm thử đạt được theo từng dịch vụ; AWS lưu ý rằng việc bổ sung bài kiểm thử có thể làm giảm điểm số ngay cả khi trình mô phỏng được cải thiện.

Mọi bài kiểm thử trong bộ đánh giá công khai đều đã được xác minh bằng ít nhất hai tài khoản AWS trong môi trường cô lập; kho mã nguồn cũng nói rõ rằng hành vi không có bài kiểm thử thì chưa được xác minh.

Những điểm số đó không biến trình mô phỏng thành môi trường kiểm thử bảo mật. Trình mô phỏng không đánh giá AWS Identity and Access Management (IAM) hay các chính sách dựa trên tài nguyên giống như AWS, vì vậy một yêu cầu bị AWS từ chối có thể vẫn thành công trên máy cục bộ. Trình mô phỏng được thiết kế để phục vụ việc xây dựng và kiểm thử; khối lượng công việc sản xuất và kiểm thử bảo mật ứng dụng nằm ngoài phạm vi hỗ trợ. Mỗi phiên bản được thiết kế để dùng với một tài khoản và một khu vực, lưu tài nguyên trong bộ nhớ và xóa chúng khi dừng.

Công việc kỹ thuật chuyển trọng tâm sang đặc tả và kiểm thử

Trong bài đăng ra mắt, Swaminathan Sivasubramanian mô tả vai trò của kỹ sư là quyết định cần xây dựng những gì và tạo ra các bản đặc tả, bài kiểm thử cùng cổng kiểm soát trước khi hợp nhất để xác định tính đúng đắn, trong khi các tác tử viết và kiểm tra mã nguồn.

Phép so sánh của ông với Alf, một dịch vụ khóa phân tán đời đầu của Amazon, đưa ra một ví dụ cụ thể. Ban đầu, phải mất khoảng bốn tháng để xây dựng công cụ nhân bản. Sivasubramanian cho biết bản dựng lại bằng Kiro ban đầu tiêu tốn bốn đêm có giám sát vì tác tử không có cách nào kiểm tra kết quả; sau khi ông cung cấp bản đặc tả và môi trường kiểm thử, việc dựng lại chỉ mất khoảng hai giờ.

AWS Emulator biến bài học đó thành một sản phẩm được phát hành: các tác tử tạo và sửa chữa phần triển khai, còn kỹ sư xác định hành vi có thể chấp nhận và tự động hóa việc bảo đảm tuân thủ. Khả năng ứng dụng thực tế hiện phụ thuộc vào bộ kiểm thử công khai ngày càng mở rộng và những điểm chưa khớp về độ trung thực còn tồn tại; việc xác thực bảo mật và môi trường sản xuất vẫn cần đến AWS thật.