Infinity ให้ AI พักระหว่างรองาน อ้างเก็บ 75,000 เอเจนต์ในแรม 8 GB

AWS อ้างว่า Infinity รองรับเอเจนต์ที่พักรอได้ราว 75,000 ตัวในหน่วยความจำ 8 GB โดยเป็นการประมาณจากผลทดสอบของผู้พัฒนา ไม่ใช่ผลทดสอบอิสระว่ารันงาน AI จริงพร้อมกันทั้งหมดได้บน Raspberry Pi 5 ครับ (AWS Open Source Blog)

เรื่องนี้เกี่ยวกับค่าใช้จ่ายของทีมที่ทำแชตบอตหรือระบบช่วยงานหลังบ้านโดยตรง เพราะปัญหาที่ AWS ยกมาคือ เอเจนต์จำนวนมากเสียเวลาไปกับการรอเครื่องมือทำงาน แต่ระบบเดิมยังจับจองโปรแกรมที่กำลังทำงานและหน่วยความจำไว้ระหว่างรอ Infinity จึงเลือกบันทึกบทสนทนา พักเอเจนต์ แล้วค่อยปลุกเมื่อมีผลกลับมา (AWS Open Source Blog) ผมว่าเรื่องที่ควรอ่านต่อจึงเป็นวิธีคิดเรื่อง “เวลารอ” มากกว่าความตื่นเต้นกับจำนวนเอเจนต์เพียงอย่างเดียว

สรุป 30 วินาที: เกิดอะไรขึ้น

AWS Open Source Blog ประกาศ Infinity เมื่อวันที่ 23 ตุลาคม 2026 ในฐานะโครงการวิจัยระยะแรกของ Hydro ซึ่งเป็นความร่วมมือระหว่าง AWS กับ UC Berkeley และเผยแพร่แบบโอเพนซอร์ส หรือเปิดโค้ดให้ตรวจและนำไปใช้ภายใต้เงื่อนไขใบอนุญาต Apache 2.0 (AWS Open Source Blog)

Infinity เป็นเฟรมเวิร์กภาษา Rust หรือชุดโครงสร้างสำหรับสร้างระบบเอเจนต์ โดยมี runtime ซึ่งเป็นตัวจัดการว่าเอเจนต์จะทำงาน พัก และกลับมาทำงานเมื่อไร เอเจนต์ในที่นี้คือระบบ AI ที่เรียกเครื่องมือไปทำงานต่อได้ ไม่ได้จบแค่ตอบข้อความ ระหว่างรอบการทำงาน Infinity เก็บเอเจนต์ไว้เป็นข้อมูลประวัติสนทนา โดยไม่มีงานค้างในหน่วยประมวลผลหรือการเชื่อมต่อที่ต้องเปิดรอไว้ตามคำอธิบายของโครงการ (GitHub)

จุดขายจึงเป็น concurrency หรือการดูแลงานหลายชุดที่คาบเกี่ยวกัน โดยไม่ต้องให้ทุกชุดยึดทรัพยากรรอเครื่องมือกลับมา โค้ดเอเจนต์ชุดเดียวกันรองรับทั้งโปรแกรมที่รันค้างในเครื่องและระบบ serverless ซึ่งเรียกส่วนประมวลผลขึ้นมาทำงานเป็นครั้ง ๆ เช่น AWS Lambda ตามที่โครงการระบุ (GitHub)

ทำไมเรื่องนี้เกี่ยวกับคุณ

สำหรับคนใช้แชตบอต สิ่งที่ควรสนใจคือเบื้องหลังคำตอบหนึ่งครั้งอาจมีการรอหลายอย่าง AWS ยกตัวอย่างเอเจนต์เขียนโค้ดที่รอสร้างโปรแกรมนานยี่สิบนาที ระบบคัดแยกงานที่รอคำขอแก้ไขโค้ดเข้ามาเป็นชั่วโมง และผู้ช่วยที่รอการอนุมัติถึงเช้าวันถัดไป ระหว่างนั้นระบบที่ทำงานแบบรอทีละขั้นยังอาจถือกระบวนการทำงานและหน่วยความจำอยู่ (AWS Open Source Blog)

ถ้าทีมในไทยกำลังสร้างผู้ช่วยตอบลูกค้าหรือช่วยงานเอกสาร ผมแนะนำให้เริ่มจากคำถามว่า งานของเรารออะไรอยู่บ้าง ไม่ต้องเริ่มจากคำถามว่าจะเปิดเอเจนต์ให้ได้กี่หมื่นตัว หากงานต้องรอผลจากระบบอื่นหรือรอคนอนุมัติ แนวคิดนี้ก็น่าทดลองกับแบบจำลองงานของตัวเอง แต่ยังสรุปไม่ได้จากข่าวนี้ว่าบิลของทีมใดจะลดลงเท่าไร

คนทำธุรกิจควรแยกความสามารถในการดูแลบทสนทนาที่พักรอ ออกจากความสามารถในการตอบลูกค้าหรือทำงานสำเร็จ ผลทดสอบของ AWS ใช้โมเดลจำลองและเก็บข้อมูลในหน่วยความจำ จึงไม่ได้ให้คำตอบเรื่องคุณภาพคำตอบของโมเดลจริงหรือความเร็วของระบบธุรกิจที่จะนำมาต่อใช้งาน (AWS Open Source Blog) จำนวนเอเจนต์มากขึ้นจึงควรเป็นข้อมูลประกอบการออกแบบ ไม่ใช่เป้าหมายแทนผลลัพธ์ของงาน

ทำงานยังไง

ตามคำอธิบายของ AWS เมื่อเอเจนต์เรียกเครื่องมือ Infinity จะส่งงานออกไป บันทึกบทสนทนา แล้วจบรอบประมวลผลนั้น แต่ละรอบเรียกโมเดลให้สร้างคำตอบหนึ่งครั้ง บันทึกผล และส่งคำสั่งไปยังเครื่องมือได้ไม่เกินหนึ่งครั้ง โดยไม่เปิดรอบนั้นค้างเพื่อรอเครื่องมือ ตัวจับเวลา หรือเหตุการณ์ภายนอกที่อาจใช้เวลานาน (AWS Open Source Blog)

ลองนึกถึง วินมอไซค์ที่ไม่ต้องจอดรอหน้าบ้านลูกค้า แต่รอเรียกจากแอป ครับ ระหว่างยังไม่มีงานรอบถัดไป ระบบเก็บข้อมูลที่จำเป็นไว้ เมื่อมีการเรียกจึงกลับมารับงานต่อ สำหรับ Infinity สิ่งที่เก็บคือประวัติสนทนา ส่วนสิ่งที่ปลุกให้ทำงานอาจเป็นข้อความผู้ใช้หรือผลจากเครื่องมือ ซึ่งเข้ามาทางคิวข้อความ หรือระบบรับข้อมูลรอประมวลผลตามลำดับ (AWS Open Source Blog)

ประวัติของแต่ละบทสนทนาจะแยกจากกัน ข้อความภายในบทสนทนาเดียวถูกประมวลผลตามลำดับทีละรอบ ส่วนคนละบทสนทนาทำงานพร้อมกันได้ เหตุผลคือถ้าสองรอบอ่านและเขียนประวัติเดียวกันพร้อมกัน ข้อมูลอาจเขียนทับกัน การรองรับงานจำนวนมากจึงยังต้องรักษาลำดับของงานแต่ละชุดอยู่ (AWS Open Source Blog)

สำหรับงานบนคลาวด์ โหมดที่ประมวลผลเป็นรอบของ Infinity ไม่เก็บงานให้รันค้างระหว่างการเรียก ตัวอย่างระบบของ AWS ใช้ SQS FIFO เป็นคิวข้อความ เรียก Lambda มาประมวลผล เก็บประวัติใน Aurora DSQL และเก็บสถานะตรวจข้อความซ้ำใน DynamoDB พร้อมมี CDK constructs หรือส่วนประกอบโค้ดสำหรับสร้างทรัพยากรเหล่านี้ให้ในคลังโครงการ (AWS Open Source Blog) นี่จึงเป็นการย้ายภาระการรอไปอยู่ในข้อมูลและคิว ซึ่งทีมต้องออกแบบและดูแลด้วย

อีกส่วนคือ Reactive Agent Protocol หรือ RAP ซึ่งเป็นข้อตกลงให้เครื่องมือส่งผลและเหตุการณ์กลับมาทางเครือข่ายเมื่อพร้อม โดยไม่ต้องเปิดการเชื่อมต่อค้าง โครงการระบุว่ามีชั้นแปลงให้ใช้เซิร์ฟเวอร์ MCP ซึ่งเป็นระบบให้ AI เรียกเครื่องมือที่มีอยู่เดิมได้โดยไม่ต้องแก้เซิร์ฟเวอร์เหล่านั้น (GitHub)

จุดสังเกต: ตัวเลข Raspberry Pi เป็นการเทียบขนาดหน่วยความจำ

รายละเอียดที่ควรอ่านให้ครบคือ AWS ทดสอบเอเจนต์ 80,000 ตัวด้วยโมเดลจำลอง บนหน่วยประมวลผล AMD EPYC 9R14 เพียงหนึ่งเธรดหรือหนึ่งสายการประมวลผล และใช้ที่เก็บข้อมูลในหน่วยความจำ ผู้พัฒนารายงานว่าหน่วยความจำเพิ่มราว 100 KB ต่อเอเจนต์ที่ว่างรอ แล้วนำอัตรานี้ไปประมาณว่าเอเจนต์ราว 75,000 ตัวจะอยู่ใน 8 GB ซึ่งเท่ากับขนาดหน่วยความจำของ Raspberry Pi 5 ตัวเลขทั้งหมดนี้เป็นผลและการประมาณที่ AWS รายงานเอง (AWS Open Source Blog)

การทดสอบของผู้พัฒนาให้แต่ละเอเจนต์ทำงานยี่สิบรอบ รวมการสร้างคำตอบ 3.2 ล้านครั้ง โดยคำตอบจำลองที่เรียกเครื่องมือมีขนาดประมาณ 1.2 KB ข้อมูลเหล่านี้ช่วยบอกว่าตัวเลขเกิดจากภาระงานแบบใด แต่ยังใช้แทนการทดสอบบทสนทนายาวหรือเครื่องมือจริงของทุกทีมไม่ได้ (AWS Open Source Blog)

บทสรุปของ DevFeed ก็ระบุว่าตัวเลขหน่วยความจำดังกล่าวเป็นค่าภายใต้ชุดทดสอบ และเป็นการประมาณความจุ ไม่ใช่หลักฐานอิสระเพิ่มอีกชุดหนึ่ง อีกทั้งหน้านี้ระบุเนื้อหาว่าเป็น AI overview หรือบทสรุปด้วย AI จึงควรใช้ประกอบการอ่านและย้อนดูรายละเอียดจากต้นทาง (DevFeed) พูดง่าย ๆ คือแรมยังไม่ใช่พนักงานเพิ่มทั้งบริษัทครับ

เรื่องเงิน / ผลกระทบ

ประโยชน์ด้านค่าใช้จ่ายที่ AWS อธิบายชัดคือ เมื่อเอเจนต์พักรอเครื่องมือ ฟังก์ชันบนระบบ serverless สามารถจบการทำงานได้ แม้เครื่องมือใช้เวลาหลายวัน ก็ไม่จำเป็นต้องมีส่วนประมวลผลของเอเจนต์รันค้างตลอดช่วงนั้น (AWS Open Source Blog) นี่เป็นเหตุผลเชิงโครงสร้างที่น่าสนใจสำหรับงานรอนาน แต่ผมไม่ตีความว่าโครงการทั้งชุดไม่มีค่าใช้จ่าย

คลังโครงการใช้ถ้อยคำว่าเอเจนต์พักได้ฟรีและไม่เสียค่าใช้จ่ายจนกว่าเหตุการณ์ใหม่จะมาถึง ขณะที่ตัวอย่างติดตั้งของ AWS ยังมีคิวข้อความ ฐานข้อมูล และการเรียกโมเดลอยู่ในระบบ (GitHub, AWS Open Source Blog) ดังนั้นคำว่า “ฟรีระหว่างพัก” ควรอ่านว่าหมายถึงการไม่คงงานประมวลผลเอเจนต์ไว้รอ ไม่ใช่ใบเสนอราคาว่าค่าใช้จ่ายรวมเป็นศูนย์ แหล่งข้อมูลที่ให้มายังไม่มีราคาหรือยอดประหยัดเป็นเงินบาทให้ยืนยัน

ผมแนะนำให้ผู้จัดการขอผลวัดจากงานเดียวกันก่อนและหลังทดลอง โดยดูทั้งเวลารอ หน่วยความจำ ขนาดประวัติ จำนวนการเรียกโมเดล งานที่ล้มเหลว และค่าใช้จ่ายรวมของระบบ การวัดแค่จำนวนบทสนทนาที่เปิดไว้จะตอบเรื่องความจุได้บางส่วน แต่ยังไม่ตอบว่าธุรกิจจ่ายน้อยลงเพื่อผลงานเท่าเดิมหรือไม่

สำหรับทีมเขียนโปรแกรม โครงการยังมี Infinity Code ซึ่งเป็นเอเจนต์เขียนโค้ดที่รันการสร้างโปรแกรมและการทดสอบอยู่เบื้องหลัง พร้อมรับผลต่อเนื่อง แก้ไขงานในหลายสายผ่าน sandbox ซ้อนกันหรือพื้นที่ทำงานแยก และส่ง diff ซึ่งเป็นรายการความต่างของโค้ดให้คนตรวจ (GitHub) ผมแนะนำให้ประเมินเวลาที่คนใช้ตรวจผลควบคู่กับเวลาที่เครื่องทำงาน เพราะการทำงานพร้อมกันมีคุณค่าต่อเมื่อคนยังตรวจรับงานได้ไหว

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

วันที่ต้องแยกให้ออกคือ AWS Open Source Blog และ DevFeed ระบุวันที่ 23 ตุลาคม 2026 ส่วนข้อมูลกำกับของหน้า GitHub ที่ได้รับมาระบุวันที่ 13 เมษายน 2026 แต่ข้อความในคลังโครงการไม่ได้อธิบายว่าวันนั้นหมายถึงเหตุการณ์ใด จึงไม่ควรสรุปว่าเป็นวันออกรุ่นแรกหรือใช้แทนวันประกาศของ AWS (AWS Open Source Blog, DevFeed, GitHub)

ถ้อยคำเรื่อง Raspberry Pi ก็มีระดับความละเอียดต่างกัน หน้า GitHub บอกว่าเบาพอสำหรับเอเจนต์ 75,000 ตัวในหน่วยความจำของ Raspberry Pi ซึ่งเป็นคำกล่าวของผู้พัฒนา ขณะที่บทความ AWS แจกแจงว่าตัวเลขนี้ประมาณจากผลทดสอบบน AMD EPYC ไม่ได้แสดงการทดสอบครบชุดบน Raspberry Pi ในข้อความที่ให้มา (GitHub, AWS Open Source Blog) จึงควรยึดคำอธิบายเงื่อนไขทดสอบที่ละเอียดกว่าเมื่อใช้ตัดสินใจ

เรื่องรุ่นนั้น ยังไม่เห็นเลขรุ่นที่ติดแท็กในแหล่งที่ตรวจ ข้อความคลังโครงการที่ได้รับมาไม่มีรายการรุ่นพร้อมหมายเลขให้ระบุ และ AWS เรียกงานนี้ว่าโครงการวิจัยระยะแรก (GitHub, AWS Open Source Blog) การไม่เห็นในเอกสารชุดนี้ไม่ได้ยืนยันว่าคลังจริงไม่มีแท็กใดเลย

ด้านผู้เขียน แหล่งหลักระบุผู้เผยแพร่เป็น AWS Open Source Blog แต่ข้อความที่ให้มาไม่แสดงชื่อผู้เขียน ส่วน DevFeed มีชื่อ Shadaj Laddad ในข้อมูลกำกับ จึงยังไม่ควรนำชื่อนั้นไปยืนยันว่าเป็นผู้เขียนบทความ AWS จากเอกสารชุดนี้เพียงอย่างเดียว (AWS Open Source Blog, DevFeed)

แล้วเราควรทำอะไร

คนทั่วไปและผู้ใช้แชตบอต

1. ใช้ข่าวนี้เป็นเหตุผลถามผู้ให้บริการว่า ระบบจัดการงานรอนานและข้อมูลสนทนาอย่างไร ไม่ต้องตัดสินคุณภาพบริการจากจำนวนเอเจนต์ที่โฆษณาเพียงตัวเดียว
2. ถ้าจะลองระบบต้นแบบ ให้ใช้ข้อมูลสมมติก่อน และหลีกเลี่ยงข้อมูลส่วนตัวหรือเอกสารงานที่ยังไม่รู้ว่าจะถูกเก็บที่ใด

นักพัฒนาและสถาปนิกระบบ

1. เริ่มจากต้นแบบในโครงการทิ้งได้หรือบัญชีทดสอบแยก ใช้คู่มือเริ่มต้นจากคลังทางการเป็นจุดตั้งต้น โครงการมีทั้งแนวทางรันในเครื่องและส่วนประกอบสำหรับติดตั้งบน Lambda (GitHub) ห้ามใส่ข้อมูลรับรองสำหรับระบบใช้งานจริงในการทดลองนี้
2. เลือกงานตัวอย่างที่มีช่วงรอชัดเจน แล้ววัดด้วยโมเดล เครื่องมือ และความยาวบทสนทนาที่ใกล้กับงานของทีม อย่านำตัวเลขจำลองของผู้พัฒนามาแทนงบประมาณของตัวเอง
3. ทดลองกรณีผลกลับมาช้า ข้อความถูกส่งซ้ำ และงานขาดตอน เพราะระบบอ้างอิงต้องจัดการคิวที่อาจส่งข้อมูลเดิมซ้ำ โดยใช้สถานะบันทึกว่าข้อความใดผ่านการประมวลผลแล้ว (AWS Open Source Blog)
4. หากลอง Infinity Code ให้คนตรวจ diff ก่อนรับการแก้ไข และตรวจขอบเขต sandbox ด้วยตัวเองก่อนให้สิทธิ์เข้าถึงข้อมูลสำคัญ คำอธิบายคุณสมบัติในคลังโครงการยังไม่ใช่ผลตรวจความปลอดภัยของสภาพแวดล้อมที่ทีมติดตั้ง (GitHub)

ผู้จัดการและเจ้าของธุรกิจ

1. อนุมัติการทดลองที่มีขอบเขตและตัวชี้วัดก่อน ได้แก่ งานสำเร็จหรือไม่ ค่าใช้จ่ายรวม และเวลาที่คนต้องกลับมาแก้ไข
2. ขอให้ทีมแจกแจงส่วนประมวลผล ส่วนเก็บข้อมูล และการเรียกโมเดล เพื่อให้เห็นว่าประหยัดตรงไหนและมีต้นทุนส่วนใดตามมา
3. ยังไม่ย้ายงานหลักเพราะตัวเลขความจุเพียงอย่างเดียว คำแนะนำของผมสำหรับสถานะวิจัยระยะแรกนี้คือใช้ประเมินสถาปัตยกรรมและทำต้นแบบก่อน

หลักฐานความปลอดภัยและความเสี่ยงที่ยังเหลือ

ที่มาซึ่งยืนยันได้จากเอกสารคือคลังโครงการทางการอยู่ภายใต้เจ้าของชื่อ hydro-project และ AWS Open Source Blog ประกาศโครงการเมื่อวันที่ 23 ตุลาคม 2026 ระบุความร่วมมือ AWS กับ UC Berkeley และใบอนุญาต Apache 2.0 แต่ยังไม่เห็นเลขรุ่นที่ติดแท็กในแหล่งที่ตรวจ (GitHub, AWS Open Source Blog) ที่มาชัดช่วยให้รู้ว่าจะตรวจโค้ดและติดตามจากไหน แต่ไม่ใช่หลักฐานว่าทุกส่วนผ่านการตรวจความปลอดภัยแล้ว

ข้อความทั้งบทความต้นทาง คลังโครงการ และบทสรุปที่ได้รับมาไม่ได้แสดงประกาศช่องโหว่หรือรายการคำแนะนำความปลอดภัยเฉพาะรุ่น จึงรายงานได้เพียงว่าไม่พบข้อมูลดังกล่าวในเอกสารชุดนี้ ไม่สามารถสรุปว่าไม่มีช่องโหว่ (AWS Open Source Blog, GitHub, DevFeed)

เรื่องสิทธิ์เริ่มต้นและการขออนุมัติจากคนก่อนใช้เครื่องมือ แหล่งที่ให้มายังไม่ได้ระบุชัดว่าค่าเริ่มต้นอนุญาตอะไรหรือจะหยุดถามเมื่อใด แม้ Infinity Code ระบุว่าจะส่งรายการแก้ไขโค้ดให้ตรวจ ก็ยังใช้ยืนยันไม่ได้ว่าการกระทำทุกชนิดต้องผ่านคนอนุมัติ ส่วนคำกล่าวว่ามี sandbox แยกงานนั้นเป็นคำอธิบายจากโครงการ ซึ่งเราไม่ได้ทดสอบการกักขอบเขตด้วยตัวเอง (GitHub)

ความเสี่ยงที่ผมเห็นจากโครงสร้างนี้คือ ประวัติสนทนาที่ระบบใช้ปลุกงานต่ออาจมีข้อมูลสำคัญ จึงต้องกำหนดสิทธิ์อ่าน การเก็บรักษา และการลบให้ชัด ส่วนเครื่องมือผ่านเครือข่ายก็ควรจำกัดปลายทางและขอบเขตงานที่อนุญาต ข้อเสนอเหล่านี้เป็นคำแนะนำในการทดลองจากลักษณะระบบที่เก็บประวัติและรับผลผ่านคิวกับเครือข่ายตามเอกสาร ไม่ใช่การกล่าวหาว่าพบข้อมูลรั่วแล้ว (AWS Open Source Blog, GitHub)

DevFeed ยังสรุปประเด็นเปิดไว้ทั้งการที่โมเดลรับเหตุการณ์สลับกัน การจัดลำดับความสำคัญ การย่อประวัติของกลุ่มเอเจนต์ และความแท้จริงของเหตุการณ์ที่รับเข้า ซึ่งเป็นข้อสรุปจากแหล่งรองนี้และยังไม่ใช่คำรับรองว่าปัญหาเหล่านั้นแก้ครบแล้ว (DevFeed) ผมจึงแนะนำให้ลองในโครงการทิ้งได้หรือสภาพแวดล้อมทดสอบก่อนเสมอ และไม่ใช้รหัสผ่าน กุญแจเข้าถึง หรือข้อมูลรับรองของระบบใช้งานจริง

ผมมองว่า…

ผมมองว่า คุณค่าที่น่าลองของ Infinity ไม่ใช่การมีเอเจนต์ให้มากที่สุด แต่คือการเลิกจ่ายทรัพยากรไปกับการยืนรอ นี่เป็นความเห็นของผมจากแนวทางพักงานและกลับมาทำต่อที่โครงการเสนอ โดยเฉพาะทีมที่ระบบต้องรอผลจากเครื่องมือหรือการอนุมัติเป็นช่วงยาว

ผมชอบที่แนวคิดนี้บังคับให้ทีมคิดเรื่องข้อมูลที่จะใช้ทำงานต่อและลำดับข้อความให้ชัด แต่ความน่าสนใจด้านการออกแบบยังไม่พอให้ข้ามการวัดต้นทุนหรือการตรวจสิทธิ์ ถ้าต้นแบบตอบได้ว่าลดเวลาประมวลผลค้างจริง ประวัติไม่สับสน และคนยังตรวจผลได้ นั่นค่อยเป็นเหตุผลที่แข็งแรงสำหรับเดินหน้าต่อ

ปิดท้าย: สิ่งที่ต้องจับตา

สิ่งที่ควรติดตามต่อคือเลขรุ่นที่ตรวจย้อนกลับได้ ผลทดสอบกับโมเดลและเครื่องมือจริง และคำอธิบายขอบเขตสิทธิ์กับการอนุมัติที่ละเอียดขึ้น โดยเฉพาะเมื่อ AWS ระบุเองว่านี่ยังเป็นงานวิจัยระยะแรกที่เปิดรับข้อเสนอแนะ (AWS Open Source Blog) สำหรับทีมไทย ข่าวนี้เป็นจุดเริ่มต้นออกแบบการทดลองได้ดี ส่วนคำตอบว่าจะคุ้มเงินและเหมาะกับงานของเราหรือไม่ ต้องมาจากผลวัดของเราเองครับ

Recap

• Infinity เป็นโครงการวิจัยระยะแรก อ่านสถานะให้ครบก่อนเลือกใช้
• ตัวเลข 75,000 เอเจนต์ใน 8 GB เป็นคำอ้างและการประมาณของผู้พัฒนา
• แยกจำนวนเอเจนต์ที่พักรอออกจากจำนวนงาน AI จริงที่ประมวลผลพร้อมกัน
• ยังไม่เห็นเลขรุ่นที่ติดแท็กในแหล่งที่ตรวจ
• วัดค่าใช้จ่ายรวม ทั้งโมเดล คิว ข้อมูล และส่วนประมวลผล
• ตรวจสิทธิ์เครื่องมือ การเก็บบทสนทนา และพฤติกรรมขออนุมัติก่อนทดลอง
• ใช้โครงการทิ้งได้หรือบัญชีทดสอบ ห้ามใช้ข้อมูลรับรองของระบบจริง
• ตรวจ diff และขอบเขต sandbox ก่อนรับงานจากเอเจนต์เขียนโค้ด