จากโมเดลสู่เอเจนต์: การติดตั้งสภาพแวดล้อมคอมพิวเตอร์ให้กับ Responses API

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

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

แทนที่จะปล่อยให้เป็นภาระของนักพัฒนาในการสร้างสภาพแวดล้อมสำหรับการรันงานเอง เราได้สร้างส่วนประกอบที่จำเป็นเพื่อติดตั้งสภาพแวดล้อมคอมพิวเตอร์ให้กับ Responses API ⁠(เปิดในหน้าต่างใหม่)เพื่อให้สามารถจัดการภารกิจในโลกจริงได้อย่างแม่นยำ

OpenAI ออกแบบ Responses API ให้ทำงานร่วมกับเครื่องมือเชลล์และพื้นที่ทำงานบนคอนเทนเนอร์ เพื่อเข้ามาแก้ปัญหาในทางปฏิบัติเหล่านี้ให้หมดไป โมเดลจะเสนอขั้นตอนและคำสั่งต่าง ๆ จากนั้นแพลตฟอร์มจะรันคำสั่งเหล่านั้นในสภาพแวดล้อมที่แยกส่วน ซึ่งมีระบบไฟล์สำหรับข้อมูลเข้าและออก มีที่เก็บข้อมูลแบบโครงสร้างอย่าง SQLite ให้เลือกใช้ และจำกัดการเข้าถึงเครือข่ายเพื่อความปลอดภัย 

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

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

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

เครื่องมือเชลล์ช่วยเพิ่มขีดความสามารถให้โมเดลได้อย่างมหาศาล โดยโมเดลจะโต้ตอบกับคอมพิวเตอร์ผ่านบรรทัดคำสั่งเพื่อจัดการภารกิจที่หลากหลาย ตั้งแต่การค้นหาข้อความไปจนถึงการส่งคำขอ API บนคอมพิวเตอร์ของคุณ เครื่องมือเชลล์ของเราสร้างขึ้นบนพื้นฐานของเครื่องมือ Unix ที่ทุกคนคุ้นเคย จึงสามารถทำงานทุกอย่างที่คุณคาดหวังได้ โดยมีเครื่องมืออรรถประโยชน์อย่าง grep, curl และ awk พร้อมให้ใช้งานได้ทันที

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

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

Responses API คือวิธีที่นักพัฒนาใช้โต้ตอบกับโมเดลของ OpenAI เมื่อใช้งานร่วมกับเครื่องมือที่ปรับแต่งเอง Responses API จะคืนอำนาจการควบคุมกลับไปที่ฝั่งไคลเอนต์ ซึ่งทางไคลเอนต์จำเป็นต้องมีระบบจัดการ (Harness) ของตัวเองสำหรับรันเครื่องมือเหล่านั้น อย่างไรก็ตาม API นี้ยังสามารถประสานงานระหว่างโมเดลและเครื่องมือที่ระบบโฮสต์ไว้ให้ได้ทันทีโดยไม่ต้องตั้งค่าเพิ่มเติม 

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

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

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

ในกรณีที่มีการจัดการไฟล์หรือประมวลผลข้อมูลปริมาณมาก เอาต์พุตของเชลล์ที่ยาวเกินไปอาจเข้าไปเบียดบังพื้นที่หน่วยความจำบริบทของโมเดล ทั้งที่ข้อมูลเหล่านั้นอาจไม่มีความสำคัญต่อการตัดสินใจ เพื่อควบคุมสิ่งนี้ โมเดลจะกำหนดขีดจำกัดเอาต์พุตต่อคำสั่งหนึ่งรายการ ระบบ Responses API จะจำกัดปริมาณข้อมูลและคืนค่ากลับมาในขนาดที่เหมาะสม ซึ่งวิธีนี้ช่วยให้คุณเห็นทั้งจุดเริ่มต้นและจุดสิ้นสุดของผลลัพธ์ ในขณะที่ส่วนตรงกลางซึ่งถูกตัดออกจะมีการทำเครื่องหมายระบุไว้ ตัวอย่างเช่น คุณอาจจำกัดขนาดเอาต์พุตไว้ที่ 1,000 ตัวอักษร โดยยังคงรักษาข้อมูลส่วนต้นและส่วนท้ายเอาไว้

ข้อความส่วนต้น ... ตัดเนื้อหาออกเหลือ 1,000 ตัวอักษร ... ข้อความส่วนท้าย

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

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

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

ระบบรองรับการบีบอัดข้อมูลทั้งในรูปแบบฟีเจอร์พื้นฐานบนเซิร์ฟเวอร์ และแบบอิสระผ่านเอนด์พอยต์ `/compact` คุณสามารถกำหนดเกณฑ์การทำงานเพื่อให้เซิร์ฟเวอร์จัดการบีบอัดข้อมูลให้โดยอัตโนมัติ ซึ่งวิธีนี้ช่วยตัดภาระในการออกแบบระบบจัดการบริบทที่ซับซ้อนทางฝั่งผู้ใช้งานออกไป ระบบนี้ช่วยขยายพื้นที่หน้าต่างบริบทให้กว้างขึ้นเล็กน้อยเพื่อรองรับข้อมูลที่เกินมาเพียงเล็กก่อนเริ่มการบีบอัด ทำให้คำขvที่เกือบจะเต็มขีดจำกัดยังคงประมวลผลและบีบอัดได้โดยไม่ถูกปฏิเสธ ระบบการบีบอัดข้อมูลในตัวจะก้าวหน้าไปพร้อมๆ กับเทคโนโลยีการเทรนโมเดล เพื่อให้มั่นใจว่า OpenAI ทุกเวอร์ชันที่ปล่อยออกมาจะทำงานร่วมกับระบบนี้ได้อย่างมีประสิทธิภาพ

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

ต่อไปมาดูเรื่องสถานะและทรัพยากรต่างๆ ที่เกี่ยวข้อง คอนเทนเนอร์ไม่ได้เป็นเพียงแค่พื้นที่สำหรับรันคำสั่งเท่านั้น แต่ยังทำหน้าที่เป็นบริบทการทำงานหลักของโมเดลด้วย ภายในคอนเทนเนอร์ โมเดลสามารถอ่านไฟล์ สอบถามฐานข้อมูล และเข้าถึงระบบภายนอกได้ภายใต้การควบคุมของนโยบายเครือข่าย

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

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

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

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

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

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

คำสั่งเชลล์มีประสิทธิภาพสูงมาก แต่งานหลายอย่างมักจะมีรูปแบบการทำงานหลายขั้นตอนที่ซ้ำซากจำเจ เอเจนต์ต้องค้นหาขั้นตอนการทำงานใหม่ทุกครั้งที่รัน ทั้งการวางแผนใหม่ ส่งคำสั่งซ้ำ และเรียนรู้ข้อกำหนดใหม่ ซึ่งทำให้ผลลัพธ์ไม่แน่นอนและเสียเวลาในการประมวลผลโดยเปล่าประโยชน์ ทักษะของเอเจนต์⁠(เปิดในหน้าต่างใหม่) ช่วยรวบรวมรูปแบบการทำงานเหล่านั้นให้กลายเป็นโมดูลพื้นฐานที่นำกลับมาใช้ใหม่และปรับแต่งร่วมกันได้ หากพูดให้เห็นภาพ ทักษะคือชุดโฟลเดอร์ที่รวม ‘SKILL.md⁠(เปิดในหน้าต่างใหม่)’ ไว้ด้วย (ซึ่งบรรจุข้อมูล Metadata และคำแนะนำในการใช้งาน) พร้อมด้วยทรัพยากรสนับสนุนอื่นๆ เช่น รายละเอียด API และส่วนประกอบ UI

โครงสร้างนี้สอดรับกับสถาปัตยกรรมการทำงานที่เราอธิบายไว้ก่อนหน้านี้ได้อย่างลงตัว คอนเทนเนอร์ทำหน้าที่จัดเตรียมไฟล์ที่จัดเก็บถาวรและบริบทการประมวลผล ส่วนเครื่องมือเชลล์รับหน้าที่เป็นส่วนประสานงานสำหรับการสั่งการ เมื่อมีทั้งสองอย่างพร้อมแล้ว โมเดลจะสามารถค้นหาไฟล์ทักษะได้โดยใช้คำสั่งเชลล์ (`ls`, `cat`, ฯลฯ) เมื่อจำเป็น พร้อมตีความคำสั่ง และรันสคริปต์สกิลทั้งหมดภายในเอเจนต์ลูปเดียวกัน

เรามี APIs⁠(เปิดในหน้าต่างใหม่) เพื่อจัดการทักษะบนแพลตฟอร์ม OpenAI นักพัฒนาสามารถอัปโหลดและจัดเก็บโฟลเดอร์ทักษะในรูปแบบชุดข้อมูลที่มีการระบุเวอร์ชัน ซึ่งสามารถเรียกกลับมาใช้งานภายหลังได้ด้วยรหัส ID ของทักษะ ก่อนที่จะส่งคำสั่งไปยังโมเดล Responses API จะดึงข้อมูลทักษะขึ้นมาและบรรจุรวบรวมไว้ในบริบทของโมเดล ลำดับขั้นตอนนี้ให้ผลลัพธ์ที่แน่นอน:

1. ดึงข้อมูล Metadata ของทักษะ ทั้งในส่วนของชื่อและรายละเอียดเบื้องต้น
2. ดึงชุดทักษะ ก่อนที่จะคัดลอกลงในคอนเทนเนอร์ แล้วแตกไฟล์
3. อัปเดตบริบทของโมเดลด้วยข้อมูล Metadata ของทักษะและเส้นทางที่อยู่ของคอนเทนเนอร์

ในการตัดสินใจว่าทักษะใดมีความเกี่ยวข้องหรือไม่ โมเดลจะค่อยๆ สำรวจคำแนะนำการใช้งาน และรันสคริปต์ต่างๆ ผ่านคำสั่งเชลล์ภายในคอนเทนเนอร์

หากรวมทุกส่วนเข้าด้วยกันจะเห็นว่า Responses API ทำหน้าที่เป็นผู้ควบคุมการทำงาน เครื่องมือเชลล์เป็นตัวขับเคลื่อนคำสั่ง คอนเทนเนอร์แบบโฮสต์ทำหน้าที่เก็บรักษาบริบทการทำงาน ทักษะช่วยจัดการเวิร์กโฟลว์ซ้ำๆ และการบีบอัดข้อมูลช่วยให้เอเจนต์รันงานต่อเนื่องได้โดยไม่ขาดบริบทสำคัญ

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

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

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

เราตื่นเต้นอย่างยิ่งที่จะได้เห็นเหล่านักพัฒนาสร้างสรรค์ผลงานใหม่ๆ จากชุดองค์ประกอบพื้นฐานเหล่านี้ เรามองว่าโมเดลภาษาทำอะไรได้มากกว่าการผลิตข้อความ ภาพ หรือเสียง โดยเราจะพัฒนาแพลตฟอร์มอย่างต่อเนื่อง เพื่อรองรับงานในโลกจริงที่ซับซ้อนและมีขนาดใหญ่ได้อย่างมีประสิทธิภาพ