ความก้าวหน้าใหม่ด้านความปลอดภัยของเอเจนต์อัจฉริยะ: ระบบจัดการรันไทม์ ArbiterOS เพิ่มอัตราการสกัดกั้นความเสี่ยงสูงจาก 6% เป็น 93%

ด้วยวิวัฒนาการของ Scaling Law อย่างต่อเนื่อง ความสามารถของ Agent กำลังเปลี่ยนจาก “การตอบคำถามได้” ไปสู่ “การลงมือทำได้”

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

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

ลิงก์ไปยังบทความ: https://arxiv.org/pdf/2604.18652

หากเข้าใจหน้าที่ของระบบปฏิบัติการแบบดั้งเดิมว่าเป็นการจัดการการเข้าถึงทรัพยากรและขอบเขตการทำงานของโปรแกรมของมนุษย์ ในยุคของ Agent แล้ว ArbiterOS กำลังพยายามเติมเต็มช่องว่างที่ขาดหายไปนานของเอเจนต์ที่ดำเนินการด้วยตนเอง นั่นคือความสามารถในการบริหารจัดการขณะทำงาน (Runtime Governance Capability)

ในการทดสอบทางวิศวกรรม ArbiterOS แสดงให้เห็นถึงการปรับปรุงด้านความปลอดภัยอย่างมีนัยสำคัญ ยกตัวอย่างระบบเอเจนต์กระแสหลักอย่าง OpenClaw ในการทดสอบงานที่มีความเสี่ยงสูง เช่น การรั่วไหลของคีย์ส่วนตัว การส่งออกการกำหนดค่าที่ละเอียดอ่อน และการลบไฟล์โดยไม่ตั้งใจ ระบบดั้งเดิมมีอัตราการสกัดกั้นขั้นตอนที่มีความเสี่ยงสูงเพียง 6.17% ในขณะที่หลังจากเชื่อมต่อ ArbiterOS แล้ว ตัวชี้วัดนี้พุ่งสูงขึ้นถึง 92.95%

ในเวลาเดียวกัน ในชุดทดสอบ Agent-SafetyBench และ AgentDojo ซึ่งเป็นการโจมตีที่พิสูจน์แล้วว่าสามารถทำได้สำเร็จ ArbiterOS มีอัตราการสกัดกั้นแบบเรียลไทม์เกิน 94% ในการประเมินเวิร์กโฟลว์ที่มีความเสี่ยงสูงของ WildClawBench ระบบนี้สามารถแจ้งเตือนล่วงหน้าได้ 100%

ArbiterOS ไม่ได้พึ่งพาเฟรมเวิร์กเอเจนต์เฉพาะใดๆ นอกเหนือจากการตรวจสอบระบบบน OpenClaw แล้ว ทีมงานเพิ่งปรับใช้กับ Hermes Agent ที่ได้รับความสนใจอย่างรวดเร็ว โดยกระบวนการเชื่อมต่อทั้งหมดใช้เวลาเพียงไม่กี่ชั่วโมง

สำหรับ Agent ที่ไม่ใช่ประเภท Claw ArbiterOS ก็สามารถให้การสนับสนุนได้เช่นกัน สิ่งที่มันต้องการจริงๆ คือนักพัฒนาสามารถกำหนดความหมายของการกระทำ ขอบเขตการดำเนินการ และจุดเสี่ยงสำคัญของเอเจนต์ให้เป็น นโยบาย (Policy) ที่สามารถบริหารจัดการได้อย่างชัดเจน ซึ่งหมายความว่าศักยภาพของ ArbiterOS นั้นไปไกลกว่าการเป็นปลั๊กอินสำหรับระบบนิเวศเฉพาะใดๆ แต่มันคือ เคอร์เนลการบริหารจัดการขณะทำงานของ Agent ที่สามารถถ่ายโอนและนำไปใช้ซ้ำได้

เว็บไซต์โครงการ: https://arbiteros.ai/

ที่อยู่ GitHub: https://github.com/cure-lab/ArbiterOS

ทำไมเอเจนต์ถึงต้องการการบริหารจัดการขณะทำงาน?

ในช่วงที่ผ่านมา รอบๆ เฟรมเวิร์กเอเจนต์ทั่วไป เช่น OpenClaw ได้มีโซลูชันเสริมความปลอดภัยมากมายเกิดขึ้น รวมถึงข้อจำกัดด้านพรอมต์ (Prompt Constraints) การ์ดเรลแบบเสริม (Add-on Guardrails) การอนุมัติกระบวนการ (Process Approval) การตรวจสอบความปลอดภัย (Security Monitoring) และการแยกส่วนในแซนด์บ็อกซ์ (Sandbox Isolation)

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

ปัญหาอย่างน้อยปรากฏให้เห็นในสามระดับ

1. ข้อจำกัดด้านพรอมต์และการยืนยันด้วยมนุษย์ไม่น่าเชื่อถือ

โมเดลภาษาขนาดใหญ่ไม่สามารถแยกแยะระหว่าง “คำสั่ง” และ “ข้อมูล” ได้อย่างเคร่งครัดในระดับพื้นฐาน ซึ่งหมายความว่าผู้โจมตีสามารถใช้วิธีการเช่น Prompt Injection เพื่อปลอมแปลงข้อมูลที่เดิมเป็นเพียงข้อมูลให้กลายเป็นคำสั่งระบบอีกครั้ง ซึ่งเป็นการเลี่ยงข้อจำกัดในชั้นข้อความ ในขณะเดียวกัน การยืนยันผ่านป๊อปอัปบ่อยครั้งก็ไม่ใช่วิธีการที่เหมาะสม เพราะจะทำให้ผู้ใช้รู้สึกเหนื่อยล้า และผู้ใช้ทั่วไปมักไม่มีความสามารถในการตัดสินความเสี่ยงที่แท้จริงเบื้องหลังการเรียกใช้ API คำขอภายนอก หรือการดำเนินการระบบบางอย่าง ระบบที่ดูเหมือน “ถามทุกจุด” แต่ในความเป็นจริงอาจไม่สามารถนำมาซึ่งความปลอดภัยที่แท้จริงได้

2. การกรองเชิงความหมายยากที่จะเข้าใจบริบทที่แท้จริง

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

3. การแยกส่วนในแซนด์บ็อกซ์ตกอยู่ในภาวะสมดุลระหว่าง “ความปลอดภัยและความสามารถในการใช้งาน”

แซนด์บ็อกซ์แบบดั้งเดิมอาศัยข้อจำกัดแบบแข็ง: จำกัดไดเรกทอรี จำกัดเครือข่าย จำกัดการเข้าถึงอุปกรณ์ แต่แซนด์บ็อกซ์เองไม่เข้าใจเจตนาของ Agent และไม่สามารถตัดสินได้ว่า “การแก้ไขการกำหนดค่าครั้งนี้เป็นการบำรุงรักษาปกติหรือเป็นการดัดแปลงที่เป็นอันตราย” หากแยกส่วนมากเกินไป ความสามารถที่แท้จริงของ Agent จะลดลงโดยตรง หากเปิดสิทธิ์มากพอเพื่อเพิ่มประสิทธิภาพการทำงาน ความเสี่ยงก็จะแทรกซึมกลับมาผ่านช่องว่างของสิทธิ์เหล่านั้น

เมื่อรวมสามระดับข้างต้น เราจะพบว่าปัญหาไม่ใช่ “ปลั๊กอินความปลอดภัยมีไม่พอ” แต่เป็นระบบเอเจนต์ในปัจจุบันยังคงขาดฐานรากการบริหารจัดการขณะทำงานที่แท้จริง เมื่อเอเจนต์ที่ชาญฉลาดอย่างยิ่งและพร้อมที่จะดำเนินการทุกเมื่อทำงานโดยไม่มีข้อจำกัดด้านสิทธิ์ในระดับระบบ ความเสี่ยงจะไม่หายไปเองตามธรรมชาติเพียงเพราะโมเดลแข็งแกร่งขึ้น ในทางกลับกัน ยิ่งมุ่งเน้นไปที่สถานการณ์ที่มีความละเอียดอ่อนสูง เช่น การเงิน การแพทย์ การดำเนินงานอัตโนมัติ ฯลฯ ก็ยิ่งต้องการกลไกการกำกับดูแลก่อนการดำเนินการที่สามารถตรวจสอบได้ ทบทวนได้ และกำหนดค่าได้ สำหรับภาคส่วนเหล่านี้ สิ่งที่ไม่สามารถควบคุมได้และไม่สามารถตรวจสอบได้ มักจะหมายถึงสิ่งที่ไม่สามารถใช้งานได้

ArbiterOS กำลังเติมเต็มช่องว่างอะไร?

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

มันนำเสนอแนวคิดสถาปัตยกรรมแบบ “การกำกับดูแลมาก่อน” (Governance-First): ไม่ว่า Agent ชั้นบนจะใช้พรอมต์ที่ซับซ้อนเพียงใด บริบทยาวเพียงใด การใช้เหตุผลหลายขั้นตอน หรือเครื่องมือที่หลากหลายเพียงใด ตราบใดที่มันเตรียมที่จะดำเนินการที่มีความเสี่ยงสูง (เช่น เขียนไฟล์ในเครื่อง แก้ไขการกำหนดค่าที่สำคัญ ส่งคำขอเครือข่ายภายนอก) การกระทำนี้จะถูก ArbiterOS เข้าควบคุมก่อน แปลงเป็นคำขอที่เครื่องอ่านและตรวจสอบได้ จากนั้นจึงส่งให้เคอร์เนลการกำกับดูแลตรวจสอบ เฉพาะเมื่อการกระทำนั้นเป็นไปตาม “สัญญาดิจิทัล” ที่กำหนดไว้ล่วงหน้าเท่านั้น จึงจะถูกปล่อยให้ดำเนินการจริง

นี่คือเหตุผลที่ ArbiterOS เหมาะสมกว่าที่จะเข้าใจว่าเป็นตัวอ่อนของ Agent Kernel / Agent OS มากกว่าที่จะเป็นเพียงตัวกรองหรือส่วนประกอบความปลอดภัยแบบเสริมภายนอก หัวใจสำคัญของมันคือการนำกฎทองของระบบพื้นฐานมาใช้ในโดเมนเอเจนต์เป็นครั้งแรก นั่นคือ “การแยกสิทธิพิเศษ (Privilege Separation)”

ArbiterOS ในสถาปัตยกรรมทางกายภาพได้เพิกถอนอำนาจอธิปไตยในการดำเนินการระดับพื้นฐานของโมเดลและแอปพลิเคชันชั้นบนอย่างสิ้นเชิง โดยทำการตัด “การคิด” และ “การทำ” ออกจากกันอย่างแข็งกร้าว

มันทำหน้าที่เหมือนมิดเดิลแวร์ชั้นระบบ ยืนอยู่ระหว่าง “การตัดสินใจอย่างชาญฉลาด” และ “การดำเนินการจริง”: โมเดลมีหน้าที่คิดและเสนอตัวเลือกการกระทำเท่านั้น ในขณะที่ ArbiterOS ในฐานะเคอร์เนลเพียงตัวเดียวที่ถือครองอินเทอร์เฟซทางกายภาพ มีหน้าที่ตัดสินอย่างเยือกเย็นว่าการกระทำใดสามารถดำเนินการได้จริงในบริบทปัจจุบัน

ภาพรวมสถาปัตยกรรมระบบนิเวศของ ArbiterOS: AI Agent → เคอร์เนลการกำกับดูแล → ผู้ให้บริการโมเดล

จากมุมมองทางวิศวกรรม ความแตกต่างนี้มีความสำคัญอย่างยิ่ง มันหมายความว่า ArbiterOS ไม่ได้สนใจว่า “โมเดลพูดอะไรที่ดูอันตรายหรือไม่” แต่สนใจว่า:

• มันกำลังจะทำอะไร (การกระทำ)
• วัตถุเป้าหมายของการกระทำนี้คืออะไร
• ข้อมูลที่เกี่ยวข้องมาจากไหน
• ในบริบทปัจจุบัน การกระทำนี้ควรได้รับอนุญาตให้ดำเนินการหรือไม่

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

จากเอาต์พุตของโมเดลสู่การกำกับดูแลการกระทำ: สี่ขั้นตอนของ ArbiterOS

เพื่อให้เกิดการบริหารจัดการขณะทำงานนี้ ArbiterOS ได้ทำให้กระบวนการทั้งหมดเป็นมาตรฐานเป็นสี่ขั้นตอน: สกัดกั้น (Intercept), แยกวิเคราะห์ (Parse), บริหารจัดการ (Govern), สังเกตการณ์ (Observe) สี่ขั้นตอนนี้ประกอบเป็นวงจรปิดการกำกับดูแลที่สำคัญที่สุดขณะทำงานของ Agent

กระบวนการกำกับดูแลสี่ขั้นตอนของ ArbiterOS: จากเอาต์พุตดั้งเดิมไปยังเอาต์พุตหลังการกำกับดูแล — ห่วงโซ่ที่สมบูรณ์ของการสกัดกั้น การแยกวิเคราะห์ นโยบาย และการสังเกตการณ์

1. สกัดกั้น: เข้าควบคุมก่อนการดำเนินการ

เมื่อ Agent อ่านไฟล์การกำหนดค่าเสร็จและเตรียมส่งคำขอไปยัง API ภายนอก ขั้นตอนแรกของ ArbiterOS ไม่ใช่การประเมินว่า “น้ำเสียงของมันอันตรายหรือไม่” แต่เป็นการเข้าควบคุมการดำเนินการนั้นโดยตรง นี่คือพื้นฐานที่ทำให้ทั้งระบบดำรงอยู่ได้ เหตุผลก็คือ ในสถานการณ์ของ Agent พฤติกรรมที่มีความเสี่ยงสูงหลายอย่าง เมื่อเกิดขึ้นแล้ว จะเกิดขึ้นทันทีและไม่สามารถย้อนกลับได้: เมื่อข้อมูลรั่วไหลออกไปแล้ว หรือไฟล์ถูกลบไปแล้ว การวิเคราะห์บันทึกหรือเขียนรายงานเหตุการณ์ภายหลังก็สายเกินไป การกำกับดูแลที่แท้จริงต้องเกิดขึ้นก่อนการดำเนินการ ไม่ใช่หลังเกิดเหตุ หัวใจของการสกัดกั้นคือการแก้ปัญหาสำคัญข้อแรก: ห้ามปล่อยให้ระบบเข้าสู่สถานะ “ทำก่อนแล้วค่อยว่ากัน” โดยเด็ดขาด

2. แยกวิเคราะห์: แปลงการกระทำในภาษาธรรมชาติเป็นคำสั่งที่มีโครงสร้างที่เครื่องอ่านได้

หลังจากสกัดกั้นการกระทำแล้ว ระบบไม่สามารถพึ่งพาการจับคู่ความเสี่ยงด้วยภาษาธรรมชาติต่อไปได้ การออกแบบที่สำคัญของ ArbiterOS คือการสร้างอินเทอร์เฟซการสื่อสารที่มีโครงสร้างแบบบังคับระหว่างชั้นแอปพลิเคชันและชั้นการดำเนินการ แทนที่จะใช้โมเดลภาษาอีกชั้นหนึ่งเพื่อ “เดา” เจตนา Agent ชั้นบนอาจคิดว่า “ช่วยส่งบทสรุปนี้ไปยังแพลตฟอร์มข้อมูลหน่อย” แต่ก่อนที่จะดำเนินการลงมาจริง มันต้องห่อหุ้มเจตนานั้นเป็นคำสั่งที่มีโครงสร้างที่เครื่องสามารถตรวจสอบได้ก่อน เช่น:

• การกระทำ: HTTP POST
• URL เป้าหมาย: api.external.com
• ข้อมูลที่ส่ง: [ข้อมูลสรุป]

ในขณะเดียวกัน ระบบจะแนบข้อมูลเมตาบริบทที่เกี่ยวข้องกับการกระทำนั้นโดยอัตโนมัติ เช่น แหล่งที่มาของข้อมูล เส้นทาง วัตถุที่เรียกใช้ และสภาพแวดล้อมการดำเนินการ ดังนั้น การกำกับดูแลรูปแบบใหม่นี้จึง建立在โปรโตคอลอินเทอร์เฟซที่เครื่องอ่านได้ มีข้อจำกัดสูง และตรวจสอบได้ เฉพาะเมื่อการกระทำถูกแสดงออกอย่างชัดเจน ระบบจึงจะสามารถทำการตัดสินที่เชื่อถือได้อย่างแท้จริงก่อนการดำเนินการ

3. บริหารจัดการ: ใช้ “คำสั่งที่มีโครงสร้าง” เพื่อตัดสินความปลอดภัยของการกระทำ

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

• ผู้กระทำ (Subject): ใครเป็นผู้เริ่มการเรียกใช้ มีบทบาทอะไร
• การกระทำ (Action): อ่าน เขียน แก้ไขการกำหนดค่า ส่งคำขอภายนอก ฯลฯ
• วัตถุ/เป้าหมาย (Object/Target): เข้าถึงไฟล์ใด ชื่อโดเมนใด ทรัพยากรใด
• เงื่อนไข (Condition): ข้อมูลของการกระทำนี้มาจากไหน มีแหล่งที่มาที่ละเอียดอ่อนหรือไม่ อยู่ในบริบทที่อนุญาตหรือไม่

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

เพื่อแก้ปัญหานี้ ArbiterOS ได้นำกลไก การติดตามรอยเปื้อนแบบไดนามิก (Dynamic Taint Tracking) มาใช้ในชั้นการกำกับดูแล: เมื่อ Agent อ่านการกำหนดค่าที่ละเอียดอ่อนในเครื่อง ไฟล์คีย์ หรือบริบทที่มีความเสี่ยงสูงในขั้นตอนก่อนหน้า ระบบจะแนบแท็กรอยเปื้อน (Taint Tag) ไปกับการไหลของข้อมูลที่เกี่ยวข้อง และทำให้แท็กเหล่านี้แพร่กระจายต่อไปตามขั้นตอนต่อๆ ไป ด้วยวิธีนี้ แม้ว่าการกระทำที่ตามมาบางอย่างจะดูถูกต้องตามกฎหมายในเชิงความหมาย (เช่น HTTP POST ทั่วไป) ตราบใดที่คำขอนั้นมีข้อมูลจากแหล่งที่ละเอียดอ่อน เอนจินนโยบายก็สามารถระบุอันตรายก่อนการดำเนินการที่มีความเสี่ยงสูง และกระตุ้นการดำเนินการกำกับดูแล เช่น การบล็อก การทำข้อมูลให้เป็นความลับ หรือการยืนยันจากผู้ใช้ กล่าวคือ ArbiterOS ไม่เพียงสนใจว่า “การกระทำปัจจุบันอันตรายหรือไม่” แต่ยังสนใจว่าข้อมูลที่ใช้ในการกระทำปัจจุบันนั้นถูกปนเปื้อนจากแหล่งที่มีความเสี่ยงสูงในห่วงโซ่การดำเนินการทั้งหมดหรือไม่

เมื่อระบบระบุความเสี่ยงด้านความปลอดภัย เอนจินการกำกับดูแลจะดำเนินการกำกับดูแลที่ชัดเจน เช่น:
– ป้องกันโดยตรง
– ปกปิดหรือดำเนินการป้องกันแล้วจึงปล่อย
– ยืนยันโดยมนุษย์

สิ่งสำคัญที่ต้องเน้นคือ ArbiterOS จะไม่หยุดการทำงานของระบบอย่างหยาบคาย เมื่อการกระทำบางอย่างถูกปฏิเสธไม่ให้ดำเนินการ เคอร์เนลจะส่งคืนข้อมูลการปฏิเสธที่มีโครงสร้างที่ชัดเจนไปยังชั้นบน โดยระบุว่านโยบายประเภทใดถูกกระตุ้น ละเมิดขอบเขตการดำเนินการใด และเหตุใดการกระทำปัจจุบันจึงไม่สามารถปล่อยให้ดำเนินการได้ สำหรับเวิร์กโฟลว์เอเจนต์ที่เชื่อมต่ออย่างเหมาะสม ข้อเสนอแนะประเภทนี้สามารถใช้โดยเครื่องสถานะชั้นบน ออร์เคสเตรเตอร์ หรือตัว Agent เองเพื่อเลือกเส้นทางการประมวลผลต่อไป เช่น การเขียนคำขอใหม่ การดำเนินการแบบลดระดับ การรอการยืนยันจากมนุษย์ หรือการเข้าสู่กระบวนการสำรอง ArbiterOS จะพยายามรักษาความสามารถในการกู้คืนและความสามารถในการใช้งานทางวิศวกรรมของเวิร์กโฟลว์ไว้ให้มากที่สุด

4. สังเกตการณ์: แปลงพฤติกรรมการสกัดกั้นเป็นห่วงโซ่หลักฐานที่สามารถทบทวนได้

ขั้นตอนสุดท้ายของวงจรปิดการกำกับดูแลคือการสังเกตการณ์ ArbiterOS จะบันทึกบริบทของการสกัดกั้นแต่ละครั้งอย่างสมบูรณ์: Agent กำลังจะดำเนินการกับวัตถุใด ข้อมูลมาจากไหน จะไหลไปที่ใด กระตุ้นกฎใด และสุดท้ายถูกจัดการอย่างไร ความสำคัญของขั้นตอนนี้ไม่ใช่แค่ “การเก็บบันทึก” แต่เป็นการเปลี่ยนระบบการกำกับดูแลจากชุดกฎแบบคงที่ ให้เป็นระบบวิศวกรรมที่สามารถปรับปรุงได้อย่างต่อเนื่อง เพราะเมื่อพฤติกรรมการสกัดกั้นถูกแปลงเป็นห่วงโซ่หลักฐานที่สามารถสืบย้อนและทบทวนได้ นักพัฒนาจึงจะเข้าใจได้อย่างแท้จริงว่า:
– กฎใดบ้างที่ทำงานอยู่
– กฎใดบ้างที่ส่งผลกระทบต่อกระบวนการปกติโดยไม่ตั้งใจ
– รูปแบบความเสี่ยงใดบ้างที่ยังไม่ถูกครอบคลุม

และด้วยการใช้ข้อเสนอแนะจริงเพื่อปรับปรุงกลยุทธ์ในภายหลังอย่างต่อเนื่อง ดังนั้น การสังเกตการณ์จึงเป็นขั้นตอนสำคัญที่ทำให้การกำกับดูแลเปลี่ยนจาก “การกองกฎ” ไปสู่ “วงจรปิดทางวิศวกรรม”

ArbiterOS แตกต่างจากการป้องกันที่มีอยู่อย่างไร?

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

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

ในแง่นี้ คุณค่าของ ArbiterOS ใกล้เคียงกับชุด วิธีการบริหารจัดการขณะทำงานที่สามารถถ่ายโอนได้: Agent ชั้นบนสามารถเปลี่ยนแปลงได้ โมเดลพื้นฐานสามารถเปลี่ยนแปลงได้ เฟรมเวิร์กเฉพาะก็สามารถเปลี่ยนแปลงได้ ตราบใดที่นักพัฒนาสามารถกำหนดความหมายของการกระทำ ทรัพยากรที่ละเอียดอ่อน และขอบเขตการดำเนินการของเอเจนต์เป็นนโยบาย (Policy) ได้อย่างชัดเจน ArbiterOS ก็สามารถกลายเป็นฐานรากการกำกับดูแลร่วมกันของระบบเหล่านี้ได้ นี่คือสาเหตุที่มันสามารถเชื่อมต่อกับ Hermes ได้อย่างรวดเร็วนอกเหนือจาก OpenClaw และมีศักยภาพในการรองรับ Agent ที่ไม่ใช่ Claw ในวงกว้างมากขึ้น

ทำไมสิ่งนี้ถึงสำคัญ?

ความสำคัญของ ArbiterOS อยู่ที่การยืนยันทิศทางที่สำคัญยิ่งกว่า: การกำกับดูแล AI ไม่จำเป็นต้อง停留在ระดับการตัดสินความเสี่ยงเชิงความหมายที่คลุมเครือตลอดไป มันสามารถถูกผลักดันไปสู่ชั้นการตรวจสอบการกระทำพื้นฐานที่แน่นอนได้ เมื่อขอบเขตความเสี่ยงถูกจำกัดให้แคบลงเหลือเพียงการเข้าถึงทรัพยากร การดำเนินการ และการไหลของข้อมูล ปัญหาการป้องกันมากมายที่แต่ก่อนดูเหมือน “เลื่อนลอย” ก็เริ่มเปลี่ยนเป็นปัญหาทางวิศวกรรมที่สามารถตรวจสอบได้ กำหนดค่าได้ และทบทวนได้ และนี่คือสิ่งที่ภาคส่วนที่มีความละเอียดอ่อนสูงต้องการอย่างแท้จริง สังคม “ซิลิคอน” ในอนาคตที่ประกอบด้วยเอเจนต์จำนวนมากที่ทำงานร่วมกัน จะสามารถมีเสถียรภาพในระยะยาวได้หรือไม่นั้น ไม่เพียงขึ้นอยู่กับว่า “พลเมืองซิลิคอน” เหล่านี้ฉลาดแค่ไหน แต่ยังขึ้นอยู่กับว่ามีกฎดิจิทัลและเคอร์เนลการกำกับดูแลที่ดำเนินการอย่างแข็งกร้าวอยู่เบื้องหลังหรือไม่ ArbiterOS ได้ก้าวไปสู่ “กฎดิจิทัล” แล้ว: ใช้กฎที่แน่นอน เพื่อจำกัดปัญญาประดิษฐ์ซิลิคอนที่ไม่แน่นอน สร้างฐานรากการดำเนินการที่เชื่อถือได้เป็นด่านสุดท้ายสำหรับการประยุกต์ใช้ AI ในสถานการณ์ที่มีความเสี่ยงสูง เช่น การเงิน การแพทย์ และการดำเนินงานอัตโนมัติ

ปัจจุบัน เว็บไซต์ทางการ โค้ดโอเพนซอร์ส และตัวอย่างการทำงาน (Demo) ของ ArbiterOS ได้ถูกเผยแพร่แล้ว ทีมงาน CURELab หวังที่จะเชิญชวนนักพัฒนาและนักวิจัยเพิ่มเติมมาร่วมกันสำรวจเส้นทาง “การบริหารจัดการขณะทำงาน” สำหรับยุคของ Agent นี้

เอกสารอ้างอิง:
https://arbiteros.ai/