harness ที่บางเบาและเอเจนต์ที่รันโค้ดได้เหมาะกับงานปลายเปิดมากกว่า เพราะการควบคุมขั้นตอนที่ตายตัวเกินไปอาจจำกัดประสิทธิภาพของโมเดล
ด้วยเหตุนี้ การรันโค้ดและการทำแซนด์บ็อกซ์จึงกลายเป็นประเด็นหลักด้านสถาปัตยกรรมของระบบเอเจนต์
Agents SDK ช่วยลดความซับซ้อนและปริมาณโค้ดที่ต้องใช้สร้างเอเจนต์ที่รันโค้ดได้ โดยในการทดสอบของเราลดลงได้ถึง 6 เท่า
เป็นเวลานานที่ความก้าวหน้าของระบบเอเจนต์เกิดจากการปรับปรุงการควบคุมขั้นตอน ไม่ว่าจะเป็นการเขียนพรอมต์ อินเทอร์เฟซเครื่องมือ การจัดการบริบท และลำดับการควบคุมที่รัดกุมขึ้น แต่เมื่อเอเจนต์เขียนโค้ดมีความสามารถมากขึ้น สมดุลดังกล่าวก็เริ่มเปลี่ยนไป
ในเวิร์กโฟลว์ปลายเปิดจำนวนมาก คอขวดไม่ได้อยู่ที่ลูปของเอเจนต์อีกต่อไป แต่อยู่ที่เลเยอร์การรันงาน ซึ่งก็คือแซนด์บ็อกซ์ที่โมเดลใช้เขียนโค้ด รันคำสั่ง ตรวจสอบผลลัพธ์ และปรับแก้ซ้ำ เมื่อการให้เหตุผลระดับงานย้ายเข้าสู่สภาพแวดล้อมนั้นมากขึ้น การควบคุมขั้นตอนโดยรอบก็ต้องเรียบง่ายลง เพื่อให้โมเดลแสดงศักยภาพได้อย่างเต็มที่
การเปลี่ยนแปลงนี้คือสิ่งที่ Agents SDK เวอร์ชันใหม่รองรับ จากการทดสอบในช่วงทดลองใช้ก่อนเปิดตัว เราพบว่าแทนที่จะเพิ่มตรรกะของเฟรมเวิร์กอีกชั้น ระบบกลับทำให้เลเยอร์การรันงานแยกเป็นโมดูลและประกอบร่วมกันได้มากขึ้น ส่วนอื่นของระบบจึงยังคงบางเบา
แนวทางที่กำลังได้รับความนิยมในงานวิศวกรรม harness คือการลด harness ให้เหลือเพียงรูปแบบขั้นต่ำที่ยังทำงานได้อย่างมีประสิทธิภาพ โดยภาพรวม harness คือซอฟต์แวร์ที่ห้อมล้อมโมเดล เป็นเลเยอร์ที่จัดการบริบท เครื่องมือ ลำดับการควบคุม และวงจรป้อนกลับ เพื่อให้โมเดลทำงานได้อย่างน่าเชื่อถือ
ในช่วงไม่กี่ปีที่ผ่านมา การเพิ่มประสิทธิภาพของเอเจนต์หลายด้านเกิดจากการเสริมความแข็งแกร่งให้เลเยอร์ดังกล่าว เครื่องมือที่ดีขึ้น หน่วยความจำและการค้นคืนที่ดีขึ้น การแบ่งงานที่ชัดเจนขึ้น และการควบคุมขั้นตอนที่รัดกุมขึ้น มักทำให้ระบบน่าเชื่อถือและมีความสามารถมากกว่าเดิม ภายใต้แนวคิดนี้ ความก้าวหน้าส่วนใหญ่หมายถึงการใส่ตรรกะของงานลงในซอฟต์แวร์รอบตัวโมเดลให้มากขึ้น
แต่รูปแบบนี้กำลังมีบทบาทลดลง อย่างน้อยก็สำหรับงานปลายเปิดประเภทหนึ่ง โครงการและงานวิจัยที่เพิ่มจำนวนขึ้นชี้ว่า ประสิทธิภาพไม่ได้ดีขึ้นเสมอไปเมื่อ harness กำหนดวิธีทำงานอย่างเข้มงวดมากขึ้น ไม่ว่าจะเป็นการช่วยเขียนโค้ด งานที่ใช้เวลานาน การใช้เบราว์เซอร์ และงานที่มีบริบทยาว ต่างพบรูปแบบเดิมซ้ำ ๆ นั่นคือ เมื่อโมเดลฉลาดเพียงพอ การบังคับให้ซอฟต์แวร์โดยรอบรองรับโครงสร้างงานมากเกินไปอาจกลายเป็นข้อจำกัดแทนที่จะเป็นข้อได้เปรียบ
บทบาทของ harness จึงกำลังเปลี่ยนไป แทนที่จะพยายามคาดการณ์งานล่วงหน้าด้วยการควบคุมขั้นตอนที่ตายตัว harness กำลังเปลี่ยนมาทำหน้าที่จัดเตรียมพื้นที่รันงานที่เป็นระเบียบมากขึ้น นั่นคือแซนด์บ็อกซ์ที่โมเดลตรวจสอบสถานะ รันโค้ด กู้คืนจากข้อผิดพลาด และปรับแนวทางของตนเองได้ โดยยังอยู่ภายใต้ขอบเขตของอินเทอร์เฟซและมาตรการป้องกันของระบบ แนวโน้มนี้ใกล้เคียงกับการเปลี่ยนแปลงที่ Andrej Karpathy อธิบายไว้ใน Software Engineer 3.0 นั่นคือตรรกะบางส่วนที่เคยอยู่ในซอฟต์แวร์จะย้ายขึ้นไปอยู่ใน “พรอมต์”
บทเรียนนี้ไม่ได้หมายความว่าระบบเอเจนต์ควรตัดโครงสร้างออกทั้งหมด งานจำนวนมากยังคงได้ประโยชน์จากเวิร์กโฟลว์ที่ชัดเจน ฮิวริสติก และกลไกควบคุมแบบกำหนดตายตัว โดยเฉพาะงานที่มีขอบเขตแคบ มีปริมาณมาก หรือมีเกณฑ์ความสำเร็จที่ชัดเจน ดังที่เราเสนอไว้ในบทความก่อนหน้าเรื่อง ฮิวริสติกสำหรับการออกแบบระบบเอเจนต์ การควบคุมขั้นตอนที่แข็งแกร่งยังคงสำคัญ เมื่อสามารถและควรกำหนดลำดับตรรกะที่น่าเชื่อถือได้
สำหรับงานปลายเปิด จุดเน้นกำลังเปลี่ยนไป โจทย์สำคัญไม่ได้อยู่ที่การออกแบบเลเยอร์ควบคุมขั้นตอนให้ซับซ้อนยิ่งขึ้น แต่อยู่ที่การสร้างสภาพแวดล้อมการรันงานซึ่งเรียบง่าย สังเกตการณ์ได้ และแยกเป็นโมดูลมากพอให้โมเดลทำงานภายในได้อย่างมีประสิทธิภาพ
เมื่อเอเจนต์อ่านไฟล์ เขียนโค้ด รันคำสั่งเชลล์ และเริ่มงานที่ใช้เวลานานได้ โจทย์ทางวิศวกรรมก็เปลี่ยนไป ส่วนที่ยากไม่ได้มีเพียงการปรับพรอมต์ให้เหมาะสมหรือการกำหนดเส้นทางไปยังเครื่องมืออีกต่อไป การที่เอเจนต์ทำงานบนระบบจริงทำให้เอเจนต์เหล่านี้ทรงพลังขึ้นอย่างมาก แต่ก็ต้องระมัดระวังมากขึ้นเช่นกัน เพราะเพิ่มพื้นผิวความเสี่ยงด้านความปลอดภัยและการรักษาความมั่นคงปลอดภัย ตัวอย่างเช่น เอเจนต์ที่รันโค้ดได้อาจดำเนินการที่ก่อให้เกิดอันตราย หากสภาพแวดล้อมแยกส่วนได้ไม่ดี (ดู Sandbox Bench ของ AISI)
การทำแซนด์บ็อกซ์จึงกลายเป็นประเด็นสำคัญอย่างยิ่งในเฟรมเวิร์กเอเจนต์ ในระบบยุคก่อน มักถือว่าการรันงานเป็นเพียงส่วนเสริม หรือเป็นเครื่องมือที่นำมาต่อพ่วงกับ harness แต่เมื่อการรันงานเริ่มมีสถานะ ใช้เวลานาน หรือทำจากระยะไกล แนวทางดังกล่าวก็เริ่มใช้การไม่ได้ การจัดการตัวแซนด์บ็อกซ์ วงจรชีวิต สถานะ อินเทอร์เฟซ และการเชื่อมต่อกับลูปของเอเจนต์ กลายเป็นโจทย์ด้านการออกแบบระบบโดยตัวมันเองอย่างรวดเร็ว นี่เป็นเหตุผลหนึ่งที่เราเห็นผู้ให้บริการจำนวนมากขึ้นนำเสนอสภาพแวดล้อมการรันโค้ดแบบมีการจัดการ เช่น Container API และเครื่องมือเชลล์ของ OpenAI, Modal, Cloudflare, Daytona และ E2B เป็นต้น
การแบ่งขอบเขตนี้สำคัญ เพราะการรันโค้ดต้องอาศัยการแยกส่วนที่แข็งแกร่งและการควบคุมรันไทม์ที่เข้มงวดกว่าส่วนอื่นของ harness ในทางปฏิบัติ เอเจนต์ที่รันโค้ดได้แต่ติดตั้งใช้งานไม่เหมาะสมอาจก่อให้เกิดความเสี่ยงสำคัญต่อธุรกิจสามด้าน ได้แก่ ค่าใช้จ่ายในการประมวลผลที่ควบคุมไม่ได้ การกระทำที่สร้างความเสียหายต่อระบบภายใน และการเปิดเผยข้อมูลที่ละเอียดอ่อน การใช้คอนเทนเนอร์ การแยกส่วน และมาตรการป้องกันรันไทม์อย่างเหมาะสม จะช่วยจำกัดความเสี่ยงเหล่านี้ให้อยู่ในระดับที่ยอมรับได้สำหรับการใช้งานจริง
วิธีหนึ่งที่จะทำความเข้าใจเรื่องนี้คือ ลองนึกภาพว่าเราให้เวิร์กสเปซปิดเฉพาะแก่เอเจนต์ แทนที่จะมอบกุญแจของสำนักงานทั้งแห่ง เอเจนต์ยังคงทำงานที่เป็นประโยชน์ภายในพื้นที่นั้นได้ แต่ต้องอยู่ในขอบเขตที่กำหนดไว้อย่างชัดเจนเท่านั้น คุณสามารถจำกัดทรัพยากรประมวลผลที่ใช้ จำกัดระบบและไฟล์ที่เอเจนต์เข้าถึงได้ และควบคุมตั้งแต่แรกว่าจะให้ข้อมูลใดแก่เอเจนต์
วิธีนี้ไม่ได้ขจัดความเสี่ยงทั้งหมด แต่เปลี่ยนโจทย์จาก “เอเจนต์ที่เคลื่อนไหวอย่างอิสระในโครงสร้างพื้นฐานของคุณ” เป็น “เอเจนต์ที่ทำงานภายในสภาพแวดล้อมที่ควบคุมได้” หากเลเยอร์นี้จะกลายเป็นส่วนมาตรฐานของระบบเอเจนต์ ตัวเฟรมเวิร์กเองก็ต้องรองรับอย่างเต็มรูปแบบ ด้วยแนวทางนี้ แซนด์บ็อกซ์จะกลายเป็นเลเยอร์การรันงานแบบโมดูลาร์ที่มีองค์ประกอบพื้นฐานซึ่งนำไปใช้ที่อื่นได้ นักพัฒนาจึงเริ่มใช้งานได้อย่างรวดเร็ว สลับผู้ให้บริการ และขยายระบบได้โดยไม่ต้องปรับตรรกะของเอเจนต์อยู่เสมอ
เมื่อเอเจนต์รันโค้ด ตัวแซนด์บ็อกซ์เองก็ต้องมีการควบคุมขั้นตอนด้วย การเปลี่ยนจากการพิสูจน์แนวคิดในเครื่องไปสู่การรันงานระยะไกล การใช้แบ็กเอนด์หลายระบบ หรือเซสชันที่ทำงานยาวนาน จะเพิ่มภาระด้านการดำเนินงานอย่างมหาศาล คุณต้องมีวิธีที่สอดคล้องกันในการสร้างสภาพแวดล้อม หยุด พัก และทำงานต่อ บันทึกสแนปช็อตสถานะ เชื่อมต่อใหม่ภายหลัง รวมถึงจัดการทั้งหมดนี้ข้ามผู้ให้บริการ
เรื่องเหล่านี้อาจไม่ใช่แนวคิดที่น่าตื่นตาตื่นใจ แต่มีความสำคัญในทางปฏิบัติ นี่คือโครงสร้างพื้นฐานประเภทที่จะสร้างความยุ่งยาก เมื่อทุกทีมต้องสร้างไปป์ไลน์แบบเอเจนต์ใหม่ตั้งแต่ต้น โดยเฉพาะเมื่อไม่ได้ผสานรวมเข้ากับเฟรมเวิร์กเอเจนต์…
นี่คือจุดที่การรองรับจากเฟรมเวิร์กที่ดียิ่งขึ้นมีความสำคัญ เราได้ทดลองใช้ OpenAI Agents SDK รุ่นใหม่ก่อนเปิดตัว และนำมาสร้างเอเจนต์แบบแซนด์บ็อกซ์ด้วยตนเอง สิ่งที่โดดเด่นคือการเปลี่ยนจุดเน้นทางสถาปัตยกรรม โดย SDK ถือว่าการรันงานเป็นเลเยอร์หลัก ไม่ใช่เครื่องมือส่วนขอบ ในทางปฏิบัติ คุณจึงเริ่มเอเจนต์แบบแซนด์บ็อกซ์ บันทึกสแนปช็อตของแซนด์บ็อกซ์ หรือรันงานต่อได้ด้วยโค้ดที่น้อยลง (ในการทดสอบบางรายการของเราน้อยลงประมาณ 6 เท่า) แล้วสลับแบ็กเอนด์ได้โดยไม่ต้องเขียนตรรกะรอบตัวเอเจนต์ใหม่
การแยกหน้าที่อย่างชัดเจนนี้ช่วยให้ harness มุ่งเน้นที่การให้เหตุผล บริบท และเวิร์กโฟลว์ได้ต่อไป ส่วนเลเยอร์การรันงานสามารถมุ่งเน้นที่การแยกส่วน ความสามารถในการย้ายระบบ และสถานะรันไทม์ ชั้นนามธรรมนี้ช่วยให้สร้างเอเจนต์เขียนโค้ดที่ทั้งมีความสามารถมากขึ้นและพัฒนาต่อยอดได้ง่ายขึ้น โดยย้ายระหว่างการรันงานในเครื่องกับระยะไกล รองรับงานที่ใช้เวลานานขึ้น และเปลี่ยนแบ็กเอนด์การรันงานได้โดยไม่ต้องออกแบบระบบทั้งหมดใหม่
เมื่อตรรกะระดับงานย้ายจาก harness เข้าไปอยู่ในโมเดลมากขึ้น ความซับซ้อนบางส่วนของระบบก็ย้ายตามลงไปอยู่ในเลเยอร์การรันงาน การรันโค้ดและการทำแซนด์บ็อกซ์กลายเป็นประเด็นหลักด้านสถาปัตยกรรมของระบบเอเจนต์แล้ว โดยเฉพาะงานที่เน้นการเขียนโค้ดและงานปลายเปิด การออกแบบสภาพแวดล้อมให้เอเจนต์ทำงานได้อย่างปลอดภัย น่าเชื่อถือ และต่อเนื่องยาวนาน มีความสำคัญพอ ๆ กับการออกแบบไปป์ไลน์แบบเอเจนต์
นี่คือเหตุผลที่ชั้นนามธรรมระดับสูงสำหรับการรันงานแบบแซนด์บ็อกซ์มีความสำคัญ OpenAI Agents SDK รุ่นใหม่ มุ่งไปในทิศทางดังกล่าว โดยถือว่าการรันงานเป็นเลเยอร์แบบโมดูลาร์ของระบบ ซึ่งย้ายข้ามแบ็กเอนด์ได้ รักษาสถานะตลอดงานที่ใช้เวลานาน และใช้งานง่ายพอที่จะไม่ต้องสร้างโครงสร้างพื้นฐานเดิมซ้ำสำหรับการตั้งค่าใหม่แต่ละครั้ง
บทเรียนในภาพรวมคือ เฟรมเวิร์กเอเจนต์ยุคถัดไปน่าจะไม่ได้วัดกันที่ปริมาณตรรกะควบคุมขั้นตอนที่เพิ่มเข้ามา แต่เป็นความสามารถในการจัดโครงสร้างสภาพแวดล้อมการรันงานที่เอเจนต์ต้องพึ่งพามากขึ้น