ทีมวิศวกรได้เปิดตัวเลเยอร์เครือข่ายแบบ fail-closed ที่ช่วยให้เอเจนต์ AI อัตโนมัติสามารถทำงานข้ามขอบเขตของคลาวด์ได้โดยไม่สูญเสียความสอดคล้องของข้อมูล ต้นแบบนี้ผ่านการทดสอบรอบการทดสอบความโกลาหล (chaos cycles) ที่จงใจสร้างขึ้นถึง 82 รอบ โดยมีอัตราความสำเร็จ 100% สำหรับเหตุการณ์ที่มีผลลัพธ์เดียว และสามารถกำจัดการอัปเดตที่ซ้ำซ้อนได้แม้ในขณะที่ไฟฟ้าถูกตัด
ทำไมโมเดลการประสานงานแบบใหม่จึงมีความสำคัญ
การปรับใช้เอเจนต์ที่ขับเคลื่อนด้วยโมเดลภาษาบนคลาวด์หลายแห่งทำให้พบจุดอ่อน: การเรียกใช้ RPC มาตรฐานจะล้มเหลวเมื่อเกิดการแยกส่วนของเครือข่าย (network partition) หรือเมื่อบริการใช้งานเกินโควตา ในช่วงเวลาดังกล่าว เอเจนต์อาจดำเนินการตามสมมติฐานที่ยังไม่ได้ตรวจสอบ ซึ่งจะทำให้สถานะที่ใช้ร่วมกัน (shared state) เสียหาย สถาปัตยกรรมใหม่นี้บังคับให้ทุกการกระทำต้องมีหลักฐานทางวิทยาการรหัสลับ (cryptographic proof) ก่อนที่ส่วนประกอบใดๆ จะยอมรับการกระทำนั้น เปลี่ยนจาก "เชื่อใจโดยค่าเริ่มต้น" (trust by default) เป็น "เชื่อใจเมื่อมีการพิสูจน์เท่านั้น" (trust only when proved)
กฎการกำกับดูแล 5 ข้อที่ช่วยให้เอเจนต์ทำงานสอดประสานกัน
- Transactional ingestion – ห่อหุ้มการเปลี่ยนแปลงสถานะทั้งหมดไว้ในธุรกรรม PostgreSQL (PostgreSQL transaction) เพียงหนึ่งเดียวเพื่อรับประกันความเป็นหนึ่งเดียว (atomicity)
- Canonical envelope – ใช้รูปแบบ 10-tuple ที่คงที่สำหรับทุกข้อความ เพื่อให้การแยกส่วน (parsing) และการตรวจสอบความถูกต้องเป็นไปอย่างแน่นอน (deterministic)
- Authority separation – เก็บโค้ดแอปพลิเคชันไว้ใน Git ในขณะที่จัดการเวอร์ชันของการย้ายฐานข้อมูล (database migrations) แยกต่างหาก เพื่อป้องกันการปนเปื้อนข้อมูลโดยไม่ตั้งใจ
- Time-bound locks – ปล่อยให้การอ้างสิทธิ์ในงาน (claims on a task) หมดอายุโดยอัตโนมัติ เพื่อไม่ให้เอเจนต์ที่หยุดชะงักทำให้กระบวนการ (pipeline) ต้องล่าช้า
- Fail-closed default – กำหนดให้การอ้างสิทธิ์ใดๆ ที่ขาดหลักฐานที่ตรวจสอบได้เป็น HOLD เพื่อบังคับให้เอเจนต์ในลำดับถัดไปต้องรอ แทนที่จะคาดเดาเอาเอง
กฎเหล่านี้รวมกันเพื่อสร้างสัญญาแบบ zero-trust: หากคุณไม่สามารถพิสูจน์ทางวิทยาการรหัสลับได้ว่าการกระทำนั้นเกิดขึ้นจริง ระบบจะปฏิเสธที่จะดำเนินการตามนั้น
ซองข้อมูลแบบ 10-tuple ที่บรรจุหลักฐาน
ทุกการส่งต่อบนบัสภายในจะประกอบด้วย:
event_id– ไอดีเฉพาะสำหรับเหตุการณ์ต้นทางeffect_id– ไอดีของการเปลี่ยนแปลงสถานะที่ถูกร้องขอlog_id– การอ้างอิงไปยังรายการบันทึกการตรวจสอบ (audit trail)producer_id– อัตลักษณ์ของเอเจนต์ต้นทางschema_version– เวอร์ชันของโครงสร้างข้อความ (message schema) ที่ใช้งานsession_epoch– นาฬิกาเชิงตรรกะ (logical clock) สำหรับการจัดลำดับภายในเซสชันdestination– เอเจนต์หรือบริการปลายทางroute_status– สถานะการกำหนดเส้นทางปัจจุบัน (เช่น pending, held)issued_at– เวลาที่สร้าง (timestamp)payload_digest– แฮชของ payload ที่ปิดผนึกด้วย HMAC
digest ใช้คีย์ลับที่เก็บไว้นอกโฟลเดอร์พื้นที่ทำงานของคลาวด์ (cloud workspace folder) เพื่อให้มั่นใจว่าโหนดประมวลผลที่ถูกเจาะระบบจะไม่สามารถปลอมแปลงข้อความที่ถูกต้องได้
ประสิทธิภาพของระบบภายใต้สภาวะกดดัน
วิศวกรได้ทำการทดสอบ chaos cycles จำนวน 82 รอบ โดยมีผลลัพธ์ดังนี้:
- ความสำเร็จ 100% สำหรับเหตุการณ์ที่สร้างผลลัพธ์เพียงหนึ่งเดียว โดยธุรกรรมจะถูกบันทึก (commit) ทั้งหมดหรือย้อนกลับ (rollback) อย่างสะอาดหมดจด
- ไม่มีการเปลี่ยนแปลงซ้ำซ้อน ในระหว่างที่ไฟฟ้าขัดข้อง ซึ่งยืนยันว่าขอบเขตของธุรกรรม (transactional boundary) ช่วยป้องกันการเขียนข้อมูลเพียงบางส่วน
- การกู้คืนการล็อกอย่างรวดเร็ว ต้องขอบคุณเอเจนต์ทำความสะอาดอัตโนมัติที่สแกนหาการอ้างสิทธิ์ที่หมดอายุและปลดล็อกโดยไม่ต้องใช้มนุษย์เข้ามาแทรกแซง
คำแนะนำเชิงปฏิบัติสำหรับสถาปนิก
- เปลี่ยนจากการใช้ webhooks ที่ไม่มีการยืนยันตัวตน เป็นการใช้ logs ที่ปิดผนึกด้วย HMAC โดยตราประทับนี้จะทำหน้าที่เป็นหลักฐานทางวิทยาการรหัสลับที่กฎ fail-closed กำหนดไว้
- เก็บรักษาคีย์ลับไว้ใน vault ที่ไม่ได้ถูก mount ไว้ภายในคอนเทนเนอร์หรืออิมเมจ VM ใดๆ
- ติดตั้งเอเจนต์น้ำหนักเบาที่มีหน้าที่เพียงอย่างเดียวคือการล้างการล็อกที่หมดอายุ เพื่อป้องกันไม่ให้ระบบหยุดชะงักเมื่อเอเจนต์หลักเกิดขัดข้อง
สิ่งที่ควรจับตามองต่อไป
แนวทางนี้ขึ้นอยู่กับความลับของคีย์ HMAC ดังนั้นควรเก็บคีย์ลับของคุณไว้นอกโฟลเดอร์พื้นที่ทำงานของคลาวด์
หากชุมชนนักพัฒนาสามารถจัดการกับสองประเด็นนี้ได้ เครือข่ายอัตโนมัติแบบ fail-closed อาจกลายเป็นมาตรฐานสำหรับการปรับใช้แบบ multi-agent ใดๆ ที่ไม่สามารถยอมรับความไม่สอดคล้องของข้อมูลแม้เพียงจุดเดียวได้