โมเดลและแพลตฟอร์ม AI
AWS เปิดตัวอีมูเลเตอร์ภายในเครื่องที่เขียนขึ้นทั้งหมดโดยเอเจนต์ AI อัตโนมัติ
เพิ่ม Unite.AI ลงในแหล่งข้อมูลที่คุณต้องการบน Google
AWS เปิดตัว AWS Emulator เมื่อวันที่ 11 พฤศจิกายน 2026 โดยอีมูเลเตอร์ภายในเครื่องนี้พร้อมให้ใช้งานทั่วไป และพัฒนาจากแบบจำลอง API ของ AWS จำนวน 438 แบบ ซึ่งครอบคลุมบริการมากกว่า 200 รายการ เอเจนต์ AI อัตโนมัติเป็นผู้เขียนและทดสอบโค้ด ทำให้นักพัฒนาและเอเจนต์เขียนโค้ดสามารถทดลองใช้ API ของ AWS บนเครื่องของตนเองได้โดยไม่ต้องมีบัญชี AWS
AWS CLI, AWS SDK และเอเจนต์เขียนโค้ดเชื่อมต่อผ่านปลายทาง HTTPS ภายในเครื่อง โดยใช้ API ชุดเดียวกับที่ใช้บนคลาวด์ ตัวแปรสภาพแวดล้อมจะเปลี่ยนเส้นทางเครื่องมือเหล่านั้นไปยังเครื่องของผู้ใช้ โดยไม่ต้องแก้ไขโค้ดแอปพลิเคชัน บทความเปิดตัวของ AWSให้รายละเอียดเกี่ยวกับแพ็กเกจ RPM และ Debian สำหรับ Linux, Docker บน macOS และ Windows รวมถึงโหมดฝังตัวสำหรับการทดสอบ Rust ไม่มีค่าบริการเพิ่มเติม แต่ลูกค้ายังคงต้องชำระค่าใช้จ่ายสำหรับทรัพยากร AWS ที่นำไปใช้งานบนคลาวด์
สำหรับเอเจนต์เขียนโค้ด อีมูเลเตอร์นี้นำโครงสร้างพื้นฐานของ AWS มาไว้ในวงจรเขียน-รัน-อ่าน กล่าวคือ เอเจนต์สามารถสร้างทรัพยากร ตรวจสอบผลลัพธ์ และปรับแก้โค้ดได้โดยไม่ต้องรอให้ติดตั้งใช้งานในรีเจียนของ AWS เอกสารประกอบของ AWSยังระบุว่าอีมูเลเตอร์รองรับการใช้งานในเซิร์ฟเวอร์สำหรับการพัฒนาและระบบผสานรวมอย่างต่อเนื่อง โดยคำขอจะส่งไปยังทรัพยากรจำลองแทนที่จะส่งไปยัง AWS
เอเจนต์สามทีมสร้างและดูแลโค้ด
Matthew Goldberg วิศวกรอาวุโสระดับ Principal ของ AWS กล่าวในบันทึกจากทีมวิศวกรรมว่า ทีมของเขาไม่ได้เขียนหรือตรวจทานโค้ดของอีมูเลเตอร์ มนุษย์เป็นผู้สร้างโครงสร้างรองรับงานดังกล่าว ซึ่งรวมถึงข้อกำหนด เครื่องมือทดสอบ ด่านตรวจสอบก่อนผสานโค้ด และกระบวนการเผยแพร่ โครงการเริ่มต้นขึ้นเมื่อเอเจนต์เขียนโค้ด Kiro สร้างอีมูเลเตอร์ Amazon SQS ที่ใช้งานได้ในระดับหนึ่งภายในเวลาประมาณ 15 นาที จากคำสั่งให้เขียนการทดสอบ ตรวจสอบการทดสอบกับ AWS จริง และสร้างการทำงานในหน่วยความจำที่ผ่านการทดสอบเหล่านั้น จากนั้น Goldberg ให้ Kiro ขยายต้นแบบตลอดช่วงสุดสัปดาห์ แต่การทำให้เป็นผลิตภัณฑ์ที่มีความทนทานจำเป็นต้องมีมาตรการควบคุมและป้องกันรองรับ
ขณะนี้เอเจนต์สามทีมที่มีขอบเขตงานชัดเจนแบ่งหน้าที่กันทำงาน ผู้เขียนการทดสอบจะออกแบบสถานการณ์จากแบบจำลอง API สาธารณะและตรวจสอบกับ AWS จริง ส่วนผู้ค้นหาปัญหาจะเรียกใช้การทดสอบซ้ำและจัดกลุ่มความล้มเหลวที่อาจมีสาเหตุร่วมกัน ขณะที่เอเจนต์แก้ไขปัญหาจะรับผิดชอบปัญหาคนละหนึ่งรายการ Goldberg ระบุว่ามีการทดสอบความเที่ยงตรงหลายหมื่นรายการ และแก้ไขปัญหาหลายพันรายการในแต่ละวัน ขณะที่เอเจนต์หลายร้อยตัวทำงานพร้อมกัน
การแก้ไขที่เสนอทุกครั้งต้องคอมไพล์ได้และผ่านการตรวจสอบอัตโนมัติด้านมาตรฐานการเขียนโค้ด ความปลอดภัย และความเที่ยงตรงก่อนผสานโค้ด เอเจนต์รักษาความปลอดภัยอิสระจะตรวจสอบการเปลี่ยนแปลงในเชิงตั้งข้อสงสัยระหว่างการพัฒนา และตรวจซ้ำอีกครั้งในกระบวนการเผยแพร่ Goldberg เขียนไว้ว่า “หากไม่มีด่านตรวจสอบก่อนผสานโค้ดนี้ เราก็คงไม่ไว้วางใจสิ่งที่เอเจนต์ของเรากำลังสร้าง”
จากนั้นการเปลี่ยนแปลงจะผ่าน AWS CodeCommit และ CodePipeline ก่อนเผยแพร่บน GitHub คลังโค้ดสาธารณะเปิดให้ดูประวัติการคอมมิต รวมถึงโฟลเดอร์แยกสำหรับปัญหาด้านความเที่ยงตรงที่แก้ไขแล้วและที่ยังไม่ได้แก้ไข AWS เผยแพร่โค้ดภายใต้ CC0 ซึ่งเป็นการสละสิทธิ์เข้าสู่สาธารณสมบัติ ยกเว้นโค้ดจากผู้จำหน่ายที่อยู่ภายใต้ Apache 2.0 คลังโค้ดนี้ไม่รับคำขอดึงโค้ด แต่ผู้ใช้สามารถรายงานข้อบกพร่องและช่องว่างด้านความเที่ยงตรงผ่าน GitHub Issues ได้
คะแนนความเที่ยงตรงเป็นตัวกำหนดขอบเขตการใช้งาน
การทดสอบความเที่ยงตรงคือเวิร์กโฟลว์สั้น ๆ ที่ตรวจสอบเทียบกับ AWS จริง อีมูเลเตอร์จะผ่านการทดสอบได้ก็ต่อเมื่อให้ผลลัพธ์ตรงกับทุกคำขอ ทั้งรหัสสถานะ เนื้อหาการตอบกลับ รหัสข้อผิดพลาดและข้อความที่ตรงกันทุกประการ ตลอดจนทรัพยากรและข้อมูลที่เวิร์กโฟลว์สร้างขึ้น การดำเนินการที่ยังไม่ได้ติดตั้งใช้งานจะส่งกลับ HTTP 501 (ไม่ได้ติดตั้งใช้งาน) ทำให้เห็นความล้มเหลวได้ทันที ในแต่ละรุ่นจะระบุจำนวนการทดสอบที่ผ่านแยกตามบริการ และ AWS เตือนว่าการเพิ่มการทดสอบอาจทำให้คะแนนลดลง แม้อีมูเลเตอร์จะพัฒนาขึ้นก็ตาม
การทดสอบทุก项ในชุดทดสอบประเมินผลสาธารณะได้รับการตรวจสอบกับบัญชี AWS แบบแซนด์บ็อกซ์อย่างน้อยสองบัญชี และคลังโค้ดระบุไว้อย่างชัดเจนว่าพฤติกรรมที่ไม่มีการทดสอบรองรับยังไม่ได้รับการยืนยัน
คะแนนเหล่านี้ไม่ได้ทำให้อีมูเลเตอร์เป็นสภาพแวดล้อมสำหรับทดสอบความปลอดภัย อีมูเลเตอร์ไม่ได้ประเมิน AWS Identity and Access Management (IAM) หรือนโยบายที่อิงตามทรัพยากรในแบบเดียวกับ AWS ดังนั้นคำขอที่ AWS ปฏิเสธอาจดำเนินการได้เมื่อใช้งานภายในเครื่อง การใช้งานที่รองรับคือการพัฒนาและการทดสอบ ส่วนเวิร์กโหลดสำหรับใช้งานจริงและการทดสอบความปลอดภัยของแอปพลิเคชันอยู่นอกขอบเขตการรองรับ แต่ละอินสแตนซ์ออกแบบมาสำหรับบัญชีและรีเจียนเดียว โดยเก็บทรัพยากรไว้ในหน่วยความจำและลบออกเมื่อหยุดทำงาน
งานวิศวกรรมเปลี่ยนจุดเน้นไปที่ข้อกำหนดและการทดสอบ
ในบทความเปิดตัว Swaminathan Sivasubramanian อธิบายว่าบทบาทของวิศวกรคือการตัดสินใจว่าควรสร้างอะไร และจัดทำข้อกำหนด การทดสอบ และด่านตรวจสอบก่อนผสานโค้ดเพื่อกำหนดเกณฑ์ความถูกต้อง ขณะที่เอเจนต์เป็นผู้เขียนและตรวจสอบโค้ด
ตัวอย่างเปรียบเทียบของเขากับ Alf ซึ่งเป็นบริการล็อกแบบกระจายของ Amazon ในยุคแรก แสดงให้เห็นภาพอย่างเป็นรูปธรรม การสร้างเอนจินจำลองข้อมูลฉบับดั้งเดิมใช้เวลาประมาณสี่เดือน Sivasubramanian กล่าวว่า การสร้างใหม่ด้วย Kiro ในช่วงแรกใช้เวลาสี่คืนภายใต้การกำกับดูแล เพราะเอเจนต์ไม่มีวิธีตรวจสอบผลลัพธ์ของตนเอง หลังจากเขาจัดเตรียมข้อกำหนดและสภาพแวดล้อมสำหรับทดสอบให้แล้ว การสร้างใหม่ก็ใช้เวลาประมาณสองชั่วโมง
AWS Emulator นำบทเรียนดังกล่าวมาพัฒนาเป็นผลิตภัณฑ์ที่เปิดให้ใช้งานจริง โดยเอเจนต์สร้างและแก้ไขส่วนที่นำไปใช้งาน ขณะที่วิศวกรกำหนดพฤติกรรมที่ยอมรับได้และทำให้การบังคับใช้เป็นไปโดยอัตโนมัติ ขอบเขตการใช้งานจริงในขณะนี้ขึ้นอยู่กับการขยายชุดทดสอบสาธารณะและการอุดช่องว่างด้านความเที่ยงตรงที่ยังเหลืออยู่ ส่วนการตรวจสอบด้านความปลอดภัยและการใช้งานจริงยังคงต้องทำกับ AWS จริง
