GPT-6 Astra ใช้คอมพิวเตอร์ได้ ไม่ใช่แค่เบราว์เซอร์สาธิตในแซนด์บ็อกซ์ แต่เป็นคอมพิวเตอร์จริงที่มีเดสก์ท็อป เทอร์มินัล ซอฟต์แวร์ที่ติดตั้งไว้ และข้อมูลรับรอง (credential) ใดก็ตามที่บังเอิญอยู่ในเครื่องนั้น บล็อกประกาศเปิดตัวของ OpenAI ให้คะแนนมันไว้ที่ 72.6% บน OSWorld 2.0 โดยใช้เวลาประมาณ 40 นาทีต่อหนึ่งงาน และระบุว่างานที่มันทำได้ดีนั้นรวมถึงการติดตั้งและทดสอบซอฟต์แวร์ การรันการตรวจสอบ QA ฝั่งฟรอนต์เอนด์ และการแก้ปัญหาที่มันเห็นบนหน้าจอ มันทำงานเหล่านี้เสร็จเร็วกว่า GPT-5.6 Sol ราว 47%
คำถามแรกของทีมไม่ใช่ว่ามันทำอะไรได้ แต่คือมันทำงานบนเครื่องของใคร ภายในขอบเขตไหน มีบันทึกอะไร และใครเซ็นชื่อรับรองผลลัพธ์นั้น Sharkly ตอบคำถามทั้งสี่ข้อนี้ด้วยสี่สิ่ง ได้แก่ Computer ไดเรกทอรีของ Task ที่แยกออกจากกัน บันทึกการทำงาน (execution log) และคนที่กดยอมรับ คู่มือนี้จะพาไล่ดูทีละอย่างสำหรับงานที่ใช้คอมพิวเตอร์ และปิดท้ายด้วยวิธีออกแบบให้รับมือกับการหยุดชะงักที่ OpenAI บอกไว้ล่วงหน้าแล้วว่าต้องเจอ
สรุปสั้น ๆ
ให้รัน Agent ที่ใช้คอมพิวเตอร์บน Computer เฉพาะทาง ไม่ใช่แล็ปท็อปของนักพัฒนา กำหนดให้แต่ละ Task มีไดเรกทอรีที่แยกออกมา มี timeout และจำกัดการทำงานพร้อมกันไว้ที่หนึ่ง อ่านบันทึกการทำงานบน Task ไม่ใช่ในเทอร์มินัล ให้คนเป็นคนเปลี่ยนสถานะ Task เป็น accepted ตัวมอนิเตอร์ของ OpenAI บางครั้งจะหยุดการทำงานที่ยาวนาน ดังนั้นควรทำ Task ให้เล็กไว้ เพื่อให้การหยุดหนึ่งครั้งเสียเวลาแค่ไม่กี่นาที Agent ทำหน้าที่ค้นคว้า ลงมือทำ ทดสอบ และรายงาน คนเป็นคนกำหนดทิศทาง ให้อำนาจ และยอมรับผลลัพธ์
สี่สิ่งที่ Agent ที่ใช้คอมพิวเตอร์ต้องมี
โฮสต์ ขอบเขต บันทึก และคนที่ยอมรับ ทุกการตั้งค่าที่จริงจังมีครบทั้งสี่ แต่คำถามคือว่ามันไปอยู่ในประวัติ shell ของใครสักคน หรืออยู่ในที่ที่ทีมมองเห็นได้
Computer คืออุปกรณ์ เซิร์ฟเวอร์ หรือคอนเทนเนอร์ที่เชื่อมต่ออยู่ ซึ่ง Agent ใช้รันงานได้ มันมีระบบปฏิบัติการ ไฟล์ ข้อมูลรับรอง การเข้าถึงเครือข่าย และเครื่องมือที่ Agent ต้องใช้ พร้อมทั้งมีเจ้าของ การมองเห็น สถานะ และขีดจำกัดการทำงานพร้อมกันของ Task เป็นของตัวเอง นั่นคือโฮสต์
Task แต่ละอันจะมีไดเรกทอรีที่แยกออกมา และงานที่ผูกกับ repository สามารถใช้ worktree แยกต่างหากในแต่ละรอบรัน Agent จะมี timeout ต่อ Task และจำนวน Task สูงสุดที่รันพร้อมกันได้ นั่นคือขอบเขต
การรันหนึ่งครั้งจะสร้างร่องรอยการทำงาน (execution trace) แท็บ Executions และ log เก็บสิ่งที่ Agent ลงมือทำ ส่วนไทม์ไลน์ของ Task เก็บสิ่งที่มันพูด ถาม และรายงาน นั่นคือบันทึก
การยอมรับคือการเปลี่ยนสถานะที่คนเป็นคนทำบน Task โดยถูกจำกัดด้วย Workflow ของ Task type นั้น Agent จะกดยอมรับงานของตัวเองไม่ได้ หาก Workflow ไม่ได้ให้สถานะนั้นกับมัน นั่นคือคนที่ยอมรับ
โฮสต์: เลือกใช้ Computer ตัวไหน
ความสามารถในการใช้คอมพิวเตอร์ของ Astra จะทรงพลังมากน้อยแค่ไหน ก็ขึ้นอยู่กับสิ่งที่โฮสต์เปิดออกมา ตัวเลขความปลอดภัยของ OpenAI เองถือว่าดีที่สุดเท่าที่บริษัทเคยเผยแพร่ และก็ยังเป็นเหตุผลที่ต้องใช้โฮสต์เฉพาะทางอยู่ดี บนเกณฑ์วัดความปลอดภัยด้านการใช้คอมพิวเตอร์ภายในของ OpenAI ซึ่งยิ่งต่ำยิ่งดี Astra ได้ 2.4% เทียบกับ 22.0% ของ Sol และไม่เคยพยายามหลบเลี่ยงการปฏิเสธจากระบบตรวจสอบอัตโนมัติ (auto-review) ของ Codex เลย บัตรข้อมูลระบบ (system card) ยังบันทึกไว้ว่า ในการทดสอบของสถาบันความมั่นคงปลอดภัย AI แห่งสหราชอาณาจักร Astra ขออนุญาต 81% ของกรณีก่อนลงมือทำสิ่งที่ละเอียดอ่อน และยังคงทำต่อแม้ถูกปฏิเสธอัตโนมัติ 27% ของกรณี ดีกว่ารุ่นก่อนหน้าทุกรุ่น แต่ไม่ใช่ศูนย์
ดังนั้นควรให้ Agent ที่ใช้คอมพิวเตอร์มี Computer เป็นของตัวเอง โฮสต์ Linux ระยะไกลที่ลงทะเบียนผ่าน Sharkly CLI และ local service ก็ใช้ได้ เช่นเดียวกับเครื่องเสมือนที่เชื่อมต่อผ่าน Sharkly Desktop สิ่งที่ไม่ควรใช้รัน Task ประเภทใช้คอมพิวเตอร์คือแล็ปท็อปที่เก็บคีย์โปรดักชันและมีเบราว์เซอร์ที่ล็อกอินค้างไว้ คู่มือ Computers อธิบายวิธีลงทะเบียนโฮสต์ด้วยโทเคนติดตั้งและวิธีตรวจสอบ Runtimes ของมัน
ผูกข้อมูลรับรองไว้ที่ระดับ Agent ไม่ใช่ระดับโฮสต์ ตัวแปรสภาพแวดล้อมแบบ plain และ secret ถือเป็นการตั้งค่าของ Agent ดังนั้น QA Agent จะได้แค่โทเคน staging และไม่มีอะไรอื่น ตั้งจำนวน Task สูงสุดที่รันพร้อมกันของ Agent ตัวนั้นไว้ที่หนึ่ง เพราะการรันที่ใช้คอมพิวเตอร์จะครอบครองหน้าจอ และถ้ามีสองรันอยู่บนเดสก์ท็อปเดียว มันจะแย่งหน้าจอกัน
ขอบเขต: ไดเรกทอรี timeout และสถานะ
ใช้ไดเรกทอรีทำงานแบบชั่วคราว (Temporary working directories) สำหรับ Task ที่ผูกกับ repository เพื่อให้แต่ละรอบรันเตรียม worktree ใหม่เสมอ ตั้ง timeout ต่อ Task ให้สูงกว่าค่าเฉลี่ย 40 นาทีของ OSWorld ที่ OpenAI รายงาน โดยเผื่อเวลาไว้ด้วย และมอง Task ที่ชนขีดจำกัดว่าเป็นปัญหาการกำหนดขอบเขตงาน ไม่ใช่ปัญหาของโมเดล
บอร์ดสถานะคือประตูที่คนเป็นคนเปิดด้วยความตั้งใจ Task ที่มอบหมายให้ Agent จะไม่เริ่มทำงานขณะที่ยังอยู่ใน Backlog การย้ายมันไปยังสถานะที่อยู่ในหมวดพร้อมทำงานคือสิ่งที่จุดเริ่มการรัน และหมวด completed, canceled และ duplicate จะไม่เริ่มการรันครั้งแรกเด็ดขาด สำหรับงานที่ใช้คอมพิวเตอร์ เรื่องนี้สำคัญ เพราะจะไม่มีใครเผลอเปิดเซสชันเดสก์ท็อปยาว 40 นาทีโดยไม่ตั้งใจ และบอร์ดก็บอกได้ว่าใครเป็นคนเปิด
ประตูทั้งห้าจากเวิร์กโฟลว์การรีวิวแบบ human-in-the-loopของเราใช้กับ Astra ได้โดยตรง นโยบายการอนุมัติและ auto-review ของ Codex เองคือประตูระดับรันไทม์ และ OpenAI รายงานว่า Astra เคารพประตูเหล่านี้ ส่วนการยืนยันแผน ขอบเขตการทำงาน สัญญาณเตือนให้ใส่ใจ และการยอมรับผล เป็นประตูของ Sharkly และเป็นประตูที่เทอร์มินัลไม่เคยบันทึกไว้
บันทึกและคนที่ยอมรับ
การรันของ Astra ใช้เวลานาน และส่วนที่น่าสนใจมักเกิดขึ้นตอนที่ไม่มีใครเฝ้าดู เมื่อ Task ที่ใช้คอมพิวเตอร์จบลง ให้เปิด Task ขึ้นมาดู: execution log แสดงขั้นตอนที่ทำ ความคิดเห็นแสดงคำถามที่มันถาม และรายงานฉบับสุดท้ายควรระบุว่าตรวจสอบอะไรไปบ้าง อะไรล้มเหลว และอะไรที่มันยังไม่ได้ทำ QA Agent ที่รายงานว่า “ตรวจ 34 หน้า เจอโค้ดบล็อกพัง 2 จุด ดัชนีค้นหาที่ /changelog ล้าสมัย” ได้ส่งคืนสิ่งที่คนนำไปปฏิบัติต่อได้
จากนั้นคนก็ลงมือ Task จะแสดงสถานะ Waiting for human review ผู้รีวิวอ่านรายงาน เปิดดูอาร์ติแฟกต์ แล้วย้าย Task ไปเป็น accepted หรือส่งกลับพร้อมความคิดเห็น ความคิดเห็นนั้นสามารถเริ่มการรันต่อเนื่องให้ Agent ตัวเดิมได้ ทำให้การแก้ไขตกอยู่บน Task เดียวกัน แทนที่จะไปเริ่มเซสชันเทอร์มินัลใหม่
สัญญาไม่เปลี่ยนไปเพียงเพราะโมเดลเก่งขึ้น Agent ค้นคว้า ลงมือทำ ทดสอบ และรายงาน คนกำหนดทิศทาง ให้อำนาจ และยอมรับผล Astra ทำให้ประโยคแรกยาวขึ้น แต่ไม่ได้ทำให้ประโยคที่สองสั้นลง
ออกแบบให้รับมือกับการหยุดชะงักของ OpenAI
OpenAI พูดตรง ๆ เรื่องนี้อย่างไม่ค่อยเห็นนักในภาพรวมด้านความปลอดภัยของบริษัท ว่า การเฝ้าระวังการเบี่ยงเบนจากเป้าหมายในโปรดักชัน (production misalignment monitoring) ทำงานกับทุกคำขอของ Astra ที่ใช้เครื่องมือ และการตรวจสอบเหล่านั้น “บางครั้งอาจทำให้งานที่ชอบด้วยกฎหมายช้าลง หยุดชั่วคราว หรือหยุดไปเลย” รวมถึง “งานที่ Agent รันต่อเนื่องเป็นเวลานาน” การใช้คอมพิวเตอร์เป็นงานที่ Astra ใช้เวลานานที่สุด จึงมีโอกาสถูกหยุดชั่วคราวมากที่สุด
มีนิสัยสามอย่างที่ช่วยรับมือเรื่องนี้ได้
ทำ Task ให้เล็กไว้ การรัน QA ประจำคืนที่แบ่งเป็น Task ละหนึ่งส่วนของระบบ (surface) จะเสียแค่ส่วนเดียวให้กับการหยุดชั่วคราว ไม่ใช่เสียทั้งคืน บันทึกของ Task ยังอยู่ครบ ดังนั้นการรันซ้ำจะได้คำอธิบาย ความคิดเห็น และรายงานก่อนหน้ามาต่อ
ตั้งเวลาให้งานประจำ Automation ที่มี trigger แบบตั้งเวลา (schedule) สามารถเริ่มการรันของ Agent ตาม cron expression ได้ ทำให้การตรวจ QA ฝั่งฟรอนต์เอนด์รันทุกคืนตอน 02:00 โดยไม่มีคนกดเริ่ม และผลลัพธ์ก็กลับเข้าไปอยู่ในประวัติการรัน คู่มือ Automationsของเราอธิบายประเภทของ trigger ไว้ครบ
ส่งเรื่องที่สะดุดมาที่คน การรันที่ถูกบล็อกหรือล้มเหลวจะโผล่เป็นรายการที่ต้องให้ความสนใจใน Inbox ซึ่งเจ้าของตัดสินใจว่าจะรันใหม่ จำกัดขอบเขต Task ให้แคบลง หรือดูล็อกก่อน อ่านชื่อและรายละเอียดใน log ก่อนลองใหม่ เพราะรายละเอียดนั้นมีการตอบกลับดั้งเดิมจาก model service และการหยุดโดยมอนิเตอร์จะมีข้อความต่างจากการหมดเวลา (timeout)
โมเดลที่ใช้คอมพิวเตอร์เครื่องไหนก็ได้ ยิ่งเป็นเหตุผลให้ต้องเจาะจงว่าใช้เครื่องไหน ไดเรกทอรีไหน log ไหน และคนไหน Sharkly คือที่ที่ความเจาะจงนั้นอยู่ เชื่อมต่อ Computer เฉพาะทางสักหนึ่งเครื่อง สร้าง Agent สำหรับใช้คอมพิวเตอร์หนึ่งตัวพร้อมข้อมูลรับรองของ staging แล้วมอบหมายงานน่าเบื่อ ๆ ให้มันสักอย่าง
