คุณเริ่มรีแฟกเตอร์โค้ดตอนสี่โมงเย็น แล้วพับจอแล็ปท็อปตอนหกโมงเย็น เช้าวันรุ่งขึ้น การทำงานนั้นอาจจะเสร็จสิ้นไปแล้ว หรืออาจจะยังรันอยู่ หรือหยุดชะงักไปตั้งแต่สามทุ่มสี่สิบเพื่อรอถามคำถามที่ไม่มีใครอยู่ตอบ ทั้งสามสถานการณ์นี้แตกต่างกันโดยสิ้นเชิง แต่ถ้ามองจากภายนอก ตลอดทั้งคืนมันกลับดูเหมือนกันไม่มีผิดเพี้ยน
Anthropic ระบุว่า Claude Opus 5.5 สามารถทำงานต่อเนื่องตามเป้าหมายได้ยาวนานถึง 18 ชั่วโมงขึ้นไป และคุณควรเชื่อตามนั้นจริง ๆ งานที่สั่งรันไว้ตอนหมดวันทำงานจะไม่จบลงเมื่อคุณเริ่มงานในวันถัดไป ตัวโมเดลได้ทำการตัดสินใจแทนคุณไปแล้วถึง 11 ชั่วโมงเต็ม และสิ่งเดียวที่คอยขวางไม่ให้มันตัดสินใจพลาด ก็คือสิ่งที่คุณเขียนกำกับไว้ก่อนจะกลับบ้านเท่านั้น
งานรันที่เสร็จทันในวันทำงานคือสิ่งที่เรายังคอยดูแลได้ แต่งานรันที่ยาวข้ามวันคือสิ่งที่คุณต้องกลับมาตรวจสอบ ทั้งสองอย่างนี้เป็นระบบคนละแบบกัน และทีมส่วนใหญ่ก็ยังคงใช้วิธีการแบบแรกอยู่
สรุปใจความสำคัญ (TL;DR)
การทำงานของเอเจนต์ที่รันต่อเนื่องยาวนาน (Long-running agent run) คือการทำงานที่ดำเนินต่อไปแม้จะไม่มีใครคอยเฝ้าหน้าจอ ดังนั้นทุกการตัดสินใจที่เอเจนต์ทำเองไม่ได้ จะต้องถูกพักไว้ในรูปของสถานะที่บันทึกไว้ (recorded state) แทนที่จะค้างเป็นข้อความพรอมต์ในเทอร์มินัลที่ไม่มีใครเปิดอ่าน และระบบจะปลอดภัยได้ก็ต่อเมื่อมี 3 สิ่งนี้ครบถ้วน: เงื่อนไขการหยุดทำงานที่เอเจนต์นำไปใช้ได้เองโดยไม่มีคุณ, สถานะ "รอคนตอบ" ที่มองเห็นและแยกแยะได้ชัดเจนจากสถานะกำลังทำงานหรือสถานะล้มเหลว, และกล่องข้อความ (Inbox) ที่มีบุคคลผู้รับผิดชอบชัดเจนเปิดดูในตอนเช้า หน้าที่ของเอเจนต์คือการค้นคว้า ลงมือทำ ทดสอบ และรายงานผล ส่วนคนมีหน้าที่กำหนดทิศทาง มอบสิทธิ์ และตรวจรับผลลัพธ์ โดย Sharkly ได้รวบรวมทั้งสามสิ่งนี้ไว้บน Task อย่างครบครัน
มีอะไรเปลี่ยนไปบ้างในวันที่ 22 กันยายน 2026
ห้องวิจัย AI สองแห่งได้ปล่อยโมเดลใหม่ออกมาในวันเดียวกัน ซึ่งส่งผลกระทบต่อทั้งระยะเวลาในการรันและราคาไปพร้อม ๆ กัน
| Claude Opus 5.5 | GPT-6 Sol | GPT-6 Luna | |
|---|---|---|---|
| API id | claude-opus-5-5 |
gpt-6-sol |
gpt-6-luna |
| Input / output per million tokens | $4 / $20 | $2 / $10 | $0.10 / $0.50 |
| Cached input | อ่าน $0.20, เขียน $5 | ลดค่าอ่าน 90% | ลดค่าอ่าน 90% |
| Context | 1M | 872k | 1M |
Anthropic ระบุว่า Opus 5.5 มีต้นทุนในการรันถูกกว่า Opus 5 ถึง 40% สร้างเอาต์พุตได้เร็วกว่าเดิมราว 30% รองรับเอาต์พุตสูงสุด 128k และเกาะติดงานได้ต่อเนื่อง 18 ชั่วโมงขึ้นไป ด้าน OpenAI ก็ระบุว่า Sol และ Luna ต่างมีราคาถูกกว่าราคาโปรโมชันของ GPT-5.6 ถึง 50% ซึ่งคำว่า “โปรโมชัน” เป็นคำของ OpenAI เอง ดังนั้นจึงเป็นการเทียบกับราคาที่ลดแล้ว ไม่ใช่ราคาเต็ม นอกจากนี้ OpenAI ยังรายงานส่วนลด 90% สำหรับการอ่าน cached input ของ GPT-6 และระบุว่าการปรับเปลี่ยน reasoning effort หรือเครื่องมือที่เปิดใช้งานจะไม่ทำให้แคชเสีย (invalidate) อีกต่อไป ซึ่งสำคัญอย่างยิ่งต่องานที่ต้องรันต่อเนื่องตลอดทั้งคืน
ดังนั้น ตอนนี้การรันงานจึงทำได้ทั้งยาวนานและประหยัดไปพร้อมกัน ทว่าชั่วโมงการทำงานในแต่ละวันไม่ได้ขยายตาม และขีดความสามารถในการอ่านตรวจผลลัพธ์ของใครก็ไม่ได้เพิ่มขึ้นตามไปด้วย
มุมมองการรีวิวที่กลับด้าน
เวลาที่คุณนั่งดูการทำงานของเอเจนต์ คุณคือตัวจัดการข้อผิดพลาด (error handler) ให้มัน เมื่อคุณเห็นมันเปิดไฟล์ผิด คุณก็สั่งหยุดกลางคัน การแก้ไขปัญหานั้นไม่เคยต้องบันทึกลงในล็อก เพราะคุณจัดการได้ทันที
แต่ในเวลากลางคืน สิ่งเหล่านี้ไม่มีอยู่จริง การแก้ไขใด ๆ ที่คุณเคยทำได้จะกลายเป็นเพียงสองทางเลือกเท่านั้น: ไม่เป็นกฎที่เอเจนต์มีอยู่แล้ว ก็ต้องสั่งหยุด ไม่มีทางเลือกที่สาม เอเจนต์ที่รันยาวนานไม่ใช่เอเจนต์ที่ปล่อยทิ้งไว้แล้วทำงานจนเสร็จสมบูรณ์ หากแต่เป็นเอเจนต์ที่จะไปถึงจุดตัดสินใจสำคัญ ซึ่งมีเพียงคุณเท่านั้นที่ตัดสินใจได้ในขณะที่คุณกำลังหลับ จงออกแบบระบบเพื่อรองรับการหยุด ไม่ใช่เพื่อรองรับการทำงานจนเสร็จ
Anthropic ยังรายงานด้วยว่า ความพยายามในการแหกกฎเกณฑ์ (boundary-circumvention) บน Opus 5.5 สำเร็จลดลงถึง 85% แต่อัตราความเป็นไปได้ที่ลดลงนี้ไม่ใช่เงื่อนไขในการหยุด โมเดลที่โน้มน้าวให้หลุดจากคำสั่งได้ยากขึ้น ก็ยังคงต้องการพื้นที่สำหรับวางคำถามทิ้งไว้ตอนตีสองอยู่ดี
3 องค์ประกอบที่ต้องมีให้ครบ
1. เงื่อนไขการหยุดที่เอเจนต์ตัดสินใจได้เองโดยไม่มีคุณ
แบ่งออกเป็นสองส่วน: เพดานขั้นสูงสุด (hard ceiling) ที่แพลตฟอร์มเป็นผู้บังคับใช้ และเงื่อนไขที่เป็นลายลักษณ์อักษรที่เอเจนต์นำไปปรับใช้เอง
เพดานขั้นสูงสุดคือเรื่องของการตั้งค่า Sharkly Agent จะจำกัดจำนวน Task ที่รันขนานกันได้สูงสุด และมีระยะเวลา timeout ต่อหนึ่ง Task ซึ่งกำหนดไว้ที่ระดับ Agent แทนที่จะเป็นต่อการรันแต่ละครั้ง ให้คุณตั้งเวลา timeout สูงกว่าระยะเวลาการรันที่นานที่สุดที่คุณต้องการ แต่ต่ำกว่าระยะเวลาการรันสูงสุดที่คุณยินดีจะจ่าย เพราะนี่คือระบบตัดวงจร (circuit breaker) ไม่ใช่การกำหนดตารางเวลา
เงื่อนไขที่เป็นลายลักษณ์อักษรคืออีกครึ่งหนึ่งที่หลายทีมมักมองข้าม เอเจนต์ที่ไม่เคยหยุดพักไม่ใช่เอเจนต์ที่ขยัน แต่เป็นเอเจนต์ที่ไม่มีใครคอยควบคุมต่างหาก
Stop and wait for a human when:
- a change would touch a file outside the paths named in the Task;
- a check that passed at the start of the run still fails after two attempts;
- the Task description and the code disagree about intended behavior;
- you are about to run a command that writes outside the working directory.
When you stop, leave one comment: what you did, what you need, and the single
question that unblocks you. One question per stop.
ควรตั้ง timeout ไว้ยาวนานขึ้นเมื่อ Task นั้นเป็นการแก้ไขที่มีขอบเขตชัดเจนและมีชุดการทดสอบคอยบอกเอเจนต์ได้ว่างานเสร็จสิ้นแล้วหรือไม่ แต่ควรจำกัดไว้เพียงหนึ่งหรือสองชั่วโมงเมื่อ Task นั้นเป็นงานเชิงสำรวจ เมื่อเกณฑ์การยอมรับ (acceptance criteria) ยังเป็นเพียงประโยคที่อาจมีข้อโต้แย้ง หรือเมื่อการรันอาจแตะต้องส่วนที่คุณไม่อยากให้แก้ไขโดยไม่ผ่านการตรวจสอบ ทั้งนี้ ด่านอนุมัติ (Approval gates) จะช่วยครอบคลุมจุดที่เอเจนต์ต้องหยุด แม้ว่าตัวมันจะมั่นใจก็ตาม
2. สถานะรอคอยที่ไม่ใช่สถานะกำลังทำงาน
ใน Sharkly สถานะวงจรชีวิตของ Task และสถานะการทำงานของ Agent จะถูกบันทึกแยกจากกัน Task สามารถอยู่ในสถานะ In Progress ได้ในขณะที่ Agent กำลัง Working, Waiting for human reply, Waiting for human review หรือ Error ส่วนกระบวนการรันเบื้องหลังก็มีสถานะของตัวเองเช่นกัน: Queued, Dispatched, Waiting for local directory, Running, Completed, Failed, Canceled
สิ่งนี้อาจฟังดูเหมือนเป็นแค่การบันทึกข้อมูลทั่วไป จนกระทั่งคุณต้องรันงานทิ้งไว้ข้ามคืนถึงแปดงานพร้อมกัน หากไม่มีระบบนี้ บอร์ดการทำงานตอนเก้าโมงเช้าจะแสดงสถานะ In Progress ทั้งกับเอเจนต์ที่กำลังแก้ไขโค้ดอยู่จริง ๆ และเอเจนต์ที่หยุดรอคำตอบมานานถึงสิบเอ็ดชั่วโมงแล้ว คุณจึงต้องมานั่งไล่เปิดดูทีละงานจนครบทั้งแปดงานเพื่อดูว่าอันไหนเป็นอันไหน
| สิ่งที่คุณเห็น | ความหมาย | สิ่งที่ต้องแลกหากละเลย |
|---|---|---|
| Working | Runtime กำลังดำเนินการกับ Task อยู่ | ยังไม่มีความเสียหายใด ๆ |
| Waiting for human reply | เอเจนต์หยุดทำงานและถามคำถาม | เสียเวลาและทรัพยากรไปเปล่า ๆ ทุกนาที |
| Waiting for human review | งานเสร็จสิ้นแล้วแต่ยังไม่ได้รับการตรวจรับ | การเปลี่ยนแปลงยังไม่ได้ถูกส่งมอบ (ship) |
| Error / Failed | การรันจบลงด้วยข้อผิดพลาด | งานรันใหม่ที่คุณยังไม่ได้เริ่มกดเสียที |
Execution log จะช่วยให้เข้าใจสาเหตุของการหยุดทำงานได้อย่างชัดเจนในเช้าวันถัดไป: เหตุใดงานจึงถูกจัดเข้าคิว, เริ่มต้นและสิ้นสุดเมื่อใด, การเรียกใช้เครื่องมือและเหตุการณ์ต่าง ๆ ของ Runtime, แหล่งที่มาของทริกเกอร์ ตลอดจนรายละเอียดความล้มเหลวหรือการยกเลิก นี่คือสิ่งที่คุณเปิดอ่านได้ทันทีแม้จะจำไม่ได้แล้วว่าตัวเองสั่งอะไรไป ดูเพิ่มเติมที่ สถานะ บันทึกการทำงาน และสัญญาณความล้มเหลว เพื่อดูว่าควรจัดเก็บข้อมูลอะไรบ้างหากคุณสร้างระบบนี้ขึ้นมาเอง
3. กล่องข้อความที่ระบุตัวผู้เปิดตรวจชัดเจน
สถานะรอคอยที่ไม่มีเจ้าของย่อมต้องรอไปตลอดกาล การรันงานข้ามคืนมักล้มเหลวอย่างเงียบเชียบในแบบที่การรันตอนกลางวันไม่เป็น เพราะไม่มีใครอยู่คอยสังเกตเห็นความเงียบนั้น
Inbox ของ Sharkly เป็นคิวความเคลื่อนไหวของงานส่วนบุคคล โดยแท็บ Primary จะรวบรวมสัญญาณแจ้งเตือนที่ต้องอาศัยคนเข้ามาจัดการ: รอคำตอบจากคุณ, รอการรีวิวจากคุณ, งานที่ล้มเหลวหรือติดขัด, การกล่าวถึงโดยตรง และงานที่มอบหมายให้คุณ ข้อผิดพลาดจากการรันและสัญญาณติดขัดจะถูกส่งไปยังผู้รับผิดชอบงานนั้น ๆ โดยตรง แทนที่จะส่งหาผู้ติดตามทุกคน ดังนั้น งานที่ล้มเหลวตอนตีสามจึงตกถึงมือคนรับผิดชอบ แทนที่จะส่งหาทุกคนซึ่งมีค่าเท่ากับไม่มีใครรับผิดชอบเลย
มุมมองที่บันทึกไว้ (Views) สองมุมมองที่จะช่วยคุณเคลียร์งานยามเช้า ได้แก่: งานที่รอการรีวิว และงานที่มอบหมายให้ Agent ซึ่งกำลังติดขัดอยู่ จงระบุชื่อบุคคลที่จะต้องเปิดดูให้ชัดเจน เพราะ "ทีม" ไม่ได้มาเปิดกล่องข้อความด้วยตัวเอง
ลำดับการตรวจงานยามเช้า
ลำดับก่อนหลังมีความสำคัญ และไม่ใช่ลำดับตามที่แสดงบนบอร์ด
- งานที่รอคนตอบ (Waiting for human reply) ต้องมาก่อนเป็นอันดับแรก การตอบคำถามช่วยให้เอเจนต์ที่หยุดอยู่กลับมาทำงานต่อได้ ในขณะที่การตรวจรีวิวไม่ได้เริ่มการทำงานใหม่ หาก SH-312 คอยคำตอบมาตั้งแต่สามทุ่มสี่สิบ สิ่งที่เร็วที่สุดที่คุณทำได้ในวันนั้นคือการตอบกลับในคอมเมนต์ ซึ่งจะส่งงานต่อเนื่องเข้าคิวใน Task เดิมทันที
- งานที่ล้มเหลวและติดขัด (Failed and blocked) เป็นอันดับสอง ควรอ่านหัวข้อของ execution log และรายละเอียดทางเทคนิคก่อนกดเริ่มใหม่ เพราะรหัสสถานะ HTTP เพียงตัวเดียวเป็นแค่เบาะแส ไม่ใช่ข้อสรุปของการวินิจฉัยปัญหา
- งานที่รอการตรวจรีวิว (Waiting for review) เป็นอันดับสาม นี่คือคิวงานที่แท้จริง และเป็นคิวที่จะสะสมเพิ่มขึ้นเรื่อย ๆ เมื่อต้นทุนการรันถูกลง
- งานที่ยังคงรันอยู่ (Still running) ไว้ท้ายสุด ปล่อยให้มันทำงานต่อไปหรือกดยกเลิก แม้งานที่ถูกยกเลิกจะไม่สามารถรันต่อจากจุดเดิมได้ แต่ตัว Task และประวัติการทำงานจะยังคงอยู่ ดังนั้น หากเห็นว่าทิศทางไม่ถูกต้องก็กดยกเลิกได้ทันทีโดยไม่ต้องลังเล แต่ควรอ่านล็อกดูก่อนเสมอ
สิ่งที่วิธีนี้ไม่ได้ช่วยแก้ปัญหา
การรันงานที่ยาวนานขึ้นไม่ได้ช่วยลดภาระการตรวจรีวิว หากแต่เป็นการรวมศูนย์ภาระนั้นให้เข้มข้นขึ้น การรันงาน 18 ชั่วโมงจะส่งมอบผลลัพธ์เดียวที่รวบรวมการตัดสินใจตลอดทั้งคืนเอาไว้ และมนุษย์ก็ยังต้องอ่าน พิจารณา และตรวจรับงานนั้นอยู่ดี แม้แต่นักวิจัยของ OpenAI เองก็ชี้ให้เห็นว่าปลายทางจะไปจบลงที่ใด: นักวิจัยระดับมัธยฐาน (median) ใช้งานค่า inference ตามราคา API มากกว่า 600 ดอลลาร์ต่อวัน และที่เปอร์เซ็นไทล์ที่ 90 สูงกว่า 7,000 ดอลลาร์ต่อวัน ในขณะที่จำนวนคนที่จะมาอ่านตรวจผลลัพธ์ยังคงเท่าเดิม เราได้ลองคำนวณตัวเลขดูแล้วตั้งแต่ตอนที่ OpenAI เผยแพร่ข้อมูลดังกล่าว และการเปิดตัวโมเดลใหม่ในครั้งนี้ก็ไม่ได้ทำให้ตัวหารเปลี่ยนแปลงไปเลย
การรันที่ถูกลงและยาวนานขึ้นช่วยให้เราทดลองทำหลายสิ่งขนานกันได้มากขึ้น แต่ไม่ได้ทำให้การตัดสินใจลดลงเลย การรีวิวโดยมนุษย์คือคอขวดที่แท้จริง และการลดราคาลงก็ยิ่งทำให้ปัญหานี้รุนแรงขึ้นก่อนที่จะดีขึ้น ระบบอัตโนมัติจะหยุดทำงานเมื่อถึงจุดที่ต้องอาศัยวิจารณญาณของทีม และเมื่อหยุด มันจะส่งมอบงานพร้อมบริบทที่ครบถ้วนและหลักฐานที่สามารถตรวจสอบได้เสมอ
คำถามที่พบบ่อย (FAQ)
ควรตั้งค่า timeout ต่อ Task ไว้นานแค่ไหนสำหรับโมเดลที่ทำงานได้ 18 ชั่วโมง? ให้ตั้งไว้นานกว่าเวลาการรันที่คุณต้องการ แต่สั้นกว่าเวลาการรันที่คุณจะรู้สึกเสียดายเงินภายหลัง เริ่มต้นที่สองสามชั่วโมงสำหรับงานทั่วไป และค่อยปรับเพิ่มขึ้นตามแต่ละ Agent สำหรับ Task ที่จำเป็นต้องใช้เวลาข้ามคืนจริง ๆ ทั้งนี้ การตั้ง timeout มีไว้เพื่อหยุดการรันที่วนลูปไม่รู้จบ ไม่ได้เป็นตัวกำหนดว่างานที่ดีต้องใช้เวลานานเท่าใด
จะเกิดอะไรขึ้นกับคำถามที่เอเจนต์ถามตอนตีสอง? คำถามนั้นควรจะเปลี่ยนเป็นสถานะ waiting-for-human-reply และกลายเป็นรายการแจ้งเตือนใน Inbox ของผู้รับผิดชอบงาน ไม่ใช่เป็นเพียงข้อความบรรทัดหนึ่งที่เลื่อนหายไปในเทอร์มินัลบัฟเฟอร์ หากระบบของคุณทำคำถามเหล่านี้หล่นหาย ให้รีบปิดช่องโหว่นั้นก่อนที่คุณจะขยายเวลา timeout ใด ๆ
บทสรุปและการนำไปปรับใช้
ไม่มีผู้ให้บริการรายใดสร้างส่วนสำคัญตรงนี้มาให้คุณ เพราะสิ่งที่สำคัญจริง ๆ คือเมื่อระบบหยุดแล้วเรื่องไปตกอยู่ที่ไหน และใครเป็นผู้รับผิดชอบในเช้าวันใหม่ คำถามนี้เหมือนกันทุกประการไม่ว่าจะบน Claude Code, Codex หรือเครื่องมืออื่นใด นั่นคือเหตุผลที่การเป็นเจ้าของงานต้องอยู่ที่ระดับ Task ไม่ใช่ฝังอยู่ภายในเซสชันของแพลตฟอร์มใดแพลตฟอร์มหนึ่ง
หากคุณสั่งให้เอเจนต์รันงานข้ามคืนอยู่แล้ว วิธีทดสอบก็ง่ายนิดเดียว: เปิดดูกระดานงานของคุณตอนเก้าโมงเช้า แล้วดูว่ามันแยกความแตกต่างระหว่างเอเจนต์ที่กำลังประมวลผลอยู่จริง ๆ กับเอเจนต์ที่หยุดรอคำตอบมาตั้งแต่เมื่อคืนได้หรือไม่ ถ้าแยกไม่ได้ นั่นคือสิ่งแรกที่คุณต้องแก้ไข และนี่คือเลเยอร์การทำงานของ Sharkly โดยที่ Task จะเป็นศูนย์กลางเก็บบันทึกทั้งเป้าหมาย, สถานะการรัน, อุปสรรคที่ติดขัด, ผลลัพธ์ที่ได้ ตลอดจนการตัดสินใจของมนุษย์ ตั้งแต่ขั้นตอนการร้องขอไปจนถึงการปล่อยงาน (release)
