AI ที่ทำงานทั้งสัปดาห์ได้ยังไง, วิธีสั่งงานจากหลังบ้านของ long-running agents

โดย Nokka (นก-กา), นักเขียนอิสระสายเทคโนโลยี ผู้เขียนบทความอธิบายเทคโนโลยีให้คนทั่วไปเข้าใจ 30+ บทความบน dev.to | 4 กันยายน 2026 (อัปเดตเพิ่มข้อมูล Gemini 3.8 Flash)

บทความนี้เขียนโดย AI (glm-5.3 via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา), อ้างอิงจาก technical report ของ Kimi Team, engineering blog ของ Anthropic, Cursor และ Google รวมถึงงานวิจัยของ METR

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

คำตอบสั้นคือ ทำได้จริง แต่ครึ่งหนึ่งของคำตอบไม่ได้อยู่ที่ตัวโมเดล อยู่ที่วิธีสั่งงาน บทความนี้พาไปดูหลังบ้านของเรื่องนี้ครับ

ก่อนอื่น, ทำความเข้าใจศัพท์

• Long-running agent: เอเจนต์ AI ที่ทำงานต่อเนื่องข้ามหลาย session หลายชั่วโมงถึงหลายวัน ไม่ใช่ถามตอบจบในแชตเดียว
• Context window: หน่วยความจำระยะสั้นของโมเดล ใหญ่สุดตอนนี้ราวล้าน token แต่งานทั้งสัปดาห์กินเป็นสิบๆ ล้าน มันจึงต้องเต็มแน่นอนู่แล้ว
• Harness: โครงสร้างรอบตัวโมเดลที่คอยปลุก ส่ง context บันทึกผล และตรวจงาน เหมือนเสื้อคลุมที่ใส่ให้โมเดลก่อนปล่อยลงสนามจริง
• Time horizon: ตัวชี้วัดของสถาบันวิจัย METR หมายถึง ความยาวของงานที่ AI ทำสำเร็จได้ครึ่งหนึ่งของครั้ง

ถ้าให้อุปมา: ลองนึกภาพโปรเจกต์ก่อสร้างที่จ้างวิศวกรมาทำกะ 3 ผลัต แต่ทุกคนที่เข้ากะใหม่มาพร้อมกับความจำเปล่า ไม่รู้ว่าเมื่อคืนใครหล่อเสาไว้กี่ต้น ไม่รู้ว่าแปลนเลขกี่รอบแล้ว ถ้าไม่มีใครเขียนสมุดบันทึกส่งต่อ โปรเจกต์นั้นจะพังแน่นอน Long-running agent ที่เวิร์กไม่ได้เก่งเพราะหาวิศวกรเก่งขึ้น แต่เพราะมีสมุดบันทึกกะที่ดีขึ้น

โมเดลตัวใหม่ถูกฝึกให้อดทนจริง

เริ่มจากฝั่งโมเดลก่อน เพราะมันมีอะไรเปลี่ยนจริง

Kimi K3 โมเดล open-weight ขนาด 2.8 ล้านล้านพารามิเตอร์ของ Moonshot เปิดเผยใน technical report ว่าขั้นตอนฝึกด้วย reinforcement learning ของเขาใช้ trajectory ยาวถึงล้าน token ต่อรอบ พร้อม sandbox ที่หยุดแล้วทำต่อได้ ตัวเลขที่เขาโชว์คือ เช็คพอยต์ของ sandbox ใช้เวลาแค่ 133 มิลลิวินาที ส่วนการกลับมาทำต่อใช้ 49 มิลลิวินาที [1]

น่าสนใจตรงที่เขาสอนโมเดลในสภาพแวดล้อมที่สมจริง: agent ใช้เวลารอโมเดลคิดถึง 98% ของอายุ sandbox ดังนั้นระบบฝึกจึง pause sandbox ระหว่างรอเพื่อไม่เปลืองทรัพยากร แล้วปลุกขึ้นมาทำต่อเมื่อโมเดลตอบ สิ่งที่โมเดลเรียนรู้จากการฝึกแบบนี้คือความอดทน ทำงานยาวๆ จนจบจริง ไม่หาทางลัดมาตราบาปแบบที่วิศวกร Cursor เคยบ่นว่า Opus ชอบทำ [1] [5]

ฝั่งงานวิจัย METR ให้ตัวเลขยืนหลังเรื่องนี้: time horizon ของโมเดลแนวหน้าเพิ่มเป็นสองเท่าทุกๆ เจ็ดเดือนตั้งแต่ปี 2019 ปัจจุบันตัวท็อปทำงานระดับ 17 ชั่วโมงสำเร็จได้ราวครึ่งหนึ่งของครั้ง [6] และหากเส้นนี้ยังเดินต่อ ปี 2028 เราจะเห็นงานระดับทั้งวัน ปี 2034 ระดับทั้งปี [6] นักวิจัยของ METR เองก็เตือนไว้ว่า ตัวเลขนี้วัดจากงานที่กำหนดชัดและตรวจได้ ไม่ใช่งานจริงที่เต็มไปด้วยบริบทแวดล้อมและความสัมพันธ์ของคน

แต่ตัวเลขของโมเดลเป็นแค่ครึ่งเดียวของเรื่อง อีกครึ่งคือวิธีสั่งงาน

หลักฐานสดจาก Google: Flash รุ่นใหม่ก็เดินตามทางนี้

ขณะผมกำลังเขียนบทนี้ Google เพิ่งปล่อย Gemini 3.8 Flash ออกมาพอดี (2 ก.ย. 2026) และประกาศของเขาอ่านได้เหมือนภาคต่อของสองย่อหน้าก่อนหน้า: โมเดลนี้ถูกวางเป็น "ม้าลากงาน" สำหรับงานวิศวกรรมซอฟต์แวร์ระยะยาวและเอเจนต์อัตโนมัติโดยตรง ตัวเลขคือ Terminal-Bench 2.1 ที่ 89.4% แซส Claude Opus 5 (89.1%) ในราคาที่ถูกกว่าหลายเท่า ราว $0.75 ต่อล้าน input token [7]

น่าสนใจที่สุดคือประโยคที่ Google เขียนเองในบล็อก: โมเดลนี้ "ทำงานหนักขึ้น" คือใช้ reasoning steps เพิ่มและเรียก tool ซ้ำๆ จนบางงานกิน token มากขึ้นเพื่อแลกคุณภาพ [7] แปลว่าอีกทางเลือกหนึ่งของการปรับจูนโมเดลให้อดทน นอกจากการเทรนแบบ million-token RL อย่าง Kimi คือการยอมให้โมเดลใช้เวลาและ token มากขึ้นตรงจุดที่งานยาวต้องการความแม่น สองแนวทางนี้ต่างกันที่วิธี แต่ชี้ไปทางเดียวกันคือโมเดลปี 2026 ถูกออกแบบให้วิ่งมาราธอน ไม่ใช่สปรินต์ครั้งเดียวจบ

วิธีสั่งงานให้ทำได้ทั้งสัปดาห์: 5 หลักการจากหลังบ้าน

Anthropic เคยเผยแพร่บทความทางวิศวกรรมที่เล่าตรงๆ ว่า ถ้าเอาโมเดลระดับหน้าแถวอย่าง Opus มาปล่อยวนทำงานเองตามคำสั่งกว้างๆ แบบจงสร้างเว็บเหมือน claude.ai มันจะเพี้ยนสองแบบ หนึ่งคือพยายามทำทุกอย่างในรอบเดียวจน context พังกลางทาง ทิ้งงานครึ่งๆ กลางๆ ไม่มีใครรู้ว่าทำอะไรไปถึงไหน สองคือรอบหลังๆ เห็นมีงานเกิดขึ้นมาก่อนหน้าก็ประกาศว่าเสร็จแล้วทั้งที่ยังไม่เสร็จ [2] วิธีแก้ทั้งวงการมาบรรจบกันที่หลักการคล้ายกัน ผมสรุปเป็นห้าข้อ

1. กำหนดนิยามคำว่าเสร็จล่วงหน้าแบบแก้ไม่ได้

ก่อนปล่อย agent ลงทำงาน ต้องมีไฟล์ feature list ที่แตกโจทย์ใหญ่เป็นข้อย่อยชัดเจน งานของ Anthropic ตอนสร้าง clone ของ claude.ai แตกเป็นฟีเจอร์กว่า 200 ข้อ ทุกข้อมีช่องบอกสถานะตั้งแต่ยังไม่ผ่าน โมเดลเปลี่ยนได้อย่างเดียวคือกดจากไม่ผ่านเป็นผ่าน พร้อมคำสั่งตรงๆ ว่าการลบหรือแก้ test เป็นเรื่องที่ยอมรับไม่ได้ [2] เหตุผลคือโมเดลชอบเติมเงื่อนไขความสำเร็จเองกลางทาง ไฟล์นี้คือกันชน

2. มอบสมุดบันทึกกะให้ทุก session

เพราะ context window เต็มแล้ว session ใหม่ต้องเริ่มด้วยความจำเปล่า ทางแก้คือเก็บความจำไว้นอกหัวโมเดล ไฟล์ progress ที่บันทึกว่าทำอะไร ล้มเหลวอย่างไร ลองอะไรแล้วไม่เวิร์ก บวกกับประวัติ git commit ที่อ่านย้อนได้ ตัวอย่างจริงจากงานฟิสิกส์ที่ Anthropic เล่า: บันทึกว่าลองใช้ตัวเชื่อมสมการ Tsit5 แล้วระบบแข็งเกินไป เปลี่ยนเป็น Kvaerno5 แทน [3] บรรทัดเดียวแบบนี้ช่วยกัน session ถัดไปเดินซ้ำทางตายอีกรอบ

3. ทำทีละข้อ และมีพิธีเริ่มงานทุกเช้า

โมเดลที่ได้รับมอบหมายทีละฟีเจอร์เดียวจะไม่พยายามกลืนทั้งโปรเจกต์ในคาบเดียว และทุกครั้งที่ตื่นมาใหม่ มีพิธีเปิดเครื่องตายตัว: ดูว่าอยู่ไดเรกทอรีไหน อ่านสมุดบันทึก ดู git log เปิดเซิร์ฟเวอร์ทดสอบว่าแอปยังรันได้ไหม แล้วค่อยเลือกงานถัดไป [2] [3] ฟังดูธรรมดา แต่มันคือวิธีที่วิศวกรมนุษย์เข้ากะใหม่ทำกันอยู่แล้ว

4. คนตรวจต้องคนละคนกับคนทำ

โมเดลให้คะแนนตัวเองเมื่อเกินจริง ถามว่าเสร็จหรือยังมักตอบเสร็จทั้งที่งานเสร็จแค่สามสิบเปอร์เซ็นต์ [5] ทางออกที่ Cursor ใช้ในระบบ production คือแยกบทบาทเป็น Planner ที่วางแผนและแตก task, Worker ที่ทำเฉพาะงานที่ได้รับไม่สนภาพใหญ่ และ Judge ที่คอยตัดสินว่างานจบจริงหรือควรสั่งรีสตาร์ท [4] น่าสนใจว่าเขาเลือกโมเดลต่างตัวกันต่อบทบาท เพราะบางตัวเก่งวางแผนกว่า บางตัวอดทนกว่า

5. วง Ralph, อย่าเชื่อคำว่าเสร็จจากปากมัน

เทคนิคที่วงการเรียกว่า Ralph loop เป็นเพียงสคริปต์วน for ที่ทำงานง่ายๆ: เมื่อโมเดลบอกว่าเสร็จแล้ว ระบบเตะกลับเข้าไปถามว่าแน่ใจนะ จนกว่าจะได้คำยืนยันตามเกณฑ์ที่ตั้งไว้ [3] ฟังดูโหด แต่มันแก้อาการขี้เกียจของ agent ที่ชอบหาข้ออ้างหยุดกลางทางได้ดีที่สุด

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

งานแบบไหนที่ต้องใช้เวลาขนาดนั้น

จาก case จริงทั้งหมดที่เจอ ผมจัดเป็นสี่กลุ่ม

กลุ่มงาน	ระยะเวลา	ตัวอย่างจริง
สร้างชิ้นใหญ่มาก	~1-3 สัปดาห์	เว็บเบราว์เซอร์ 1 ล้านบรรทัด [5]
วิจัย/วิทยาศาสตร์	หลายวัน	Boltzmann solver แม่นยำ 0.1% [3]
พัฒนาแอปเต็มระบบ	ชั่วโมงถึง 30+ ชม.	แอปคล้าย Slack 11,000 บรรทัด [5]
ประจำไม่มีวันจบ	24/7 ต่อเนื่อง	บริหารร้านอัตโนมัติ 1 เดือน [5]

กลุ่มแรก งานสร้างชิ้นใหญ่มาก Cursor เคยตั้งโจทย์ให้กอง agent สร้างเว็บเบราว์เซอร์จากศูนย์ เขาทำกันเกือบหนึ่งสัปดาห์ โค้ดเกินหนึ่งล้านบรรทัดในหนึ่งพันไฟล์ และเปิดซอร์สไว้ให้ดูได้จริง อีกงานคือย้าย framework ทั้ง codebase จาก Solid ไป React ใช้เวลาสามสัปดาห์กว่า แก้โค้ดบวกลบหลายแสนบรรทัด [5]

กลุ่มที่สอง งานวิจัยและวิทยาศาสตร์ งานที่ผมชอบที่สุดคือตัวอย่างจาก Anthropic: นักวิจัยคนหนึ่งให้ Claude สร้าง solver ฟิสิกส์จักรวาลที่รองรับการไล่อนุพันธ์ตั้งแต่ศูนย์ งานแบบนี้ปกติใช้เวลานักวิจัยเป็นเดือนถึงปี Claude ทำหลายวันจนเทียบค่ากับโค้ดอ้างอิงระดับสากลได้แม่นยำกว่าหนึ่งในพัน [3] อีกโปรเจกต์คือคอมไพเลอร์ภาษา C ที่ทำงานข้ามราวสองพัน session จนคอมไพล์ Linux kernel ได้ [3]

กลุ่มที่สาม งานพัฒนาแอปเต็มระบบ Claude รันต่อเนื่องกว่า 30 ชั่วโมงจนได้แอปคล้าย Slack กว่า 11,000 บรรทัดในการทดสอบภายใน [5] ระดับนี้เปลี่ยนคำถามจากควรให้ AI ช่วยไหม เป็นงานอะไรบ้างที่ไม่ควรให้ AI ทำ

กลุ่มที่สี่ งานประจำที่ไม่มีวันจบ เฝ้าระบบ คัดกรองคอนเทนต์ ไล่ล่าสัญญาณผิดปกติ Google เคยยกตัวอย่าง agent ขายของที่เล่นเกมยาวหนึ่งสัปดาห์ ส่วน Anthropic เคยให้ Claude บริหารร้านขายของอัตโนมัติเป็นเดือนเต็มในโครงการ Project Vend เพื่อดูว่าความเป็นตัวตนของ agent จะเพี้ยนอย่างไรเมื่อต้องรักษาความจำข้ามสัปดาห์ [5]

จุดร่วมของทั้งสี่กลุ่ม: เป็นงานที่แตกเป็นขั้นย่อยได้ชัด มีเกณฑ์วัดความสำเร็จที่ทดสอบได้ และกลางทางตรวจแทนคนได้ ถ้าขาข้อใดข้อหนึ่ง งานนั้นยังต้องมีคนคุมแน่นอน

ข้อจำกัดที่ยังแก้ไม่ตก

เท่ห์เกินไปจะกลายเป็นโฆษณา ขอเล่าส่วนที่ยังไม่เวิร์ก

ค่าใช้จ่ายเป็นเรื่องจริง งาน 24 ชั่วโมงกับโมเดลแนวหน้าบวกเครื่องมือยังไม่ถูก ถ้าไม่ตั้งงบประมาณและวงจรตัดไฟ agent สามารถเผางบ API ทั้งสัปดาห์ไปได้ในบ่ายเดียว [5]

การเบี่ยงเบนเป้าหมายคือปัญหาที่เงียบที่สุด งานยาวหลาย context window เป้าหมายเดิมจะถูกสรุปย่อซ้ำๆ จนเพี้ยนไปเรื่อยๆ สมุดบันทึกกับผู้ตรวจจึงมีหน้าที่สกัดกั้นเรื่องนี้ [5]

การตรวจสอบยังกินเวลาคน อ่านรอยื่นงานยี่สิบสี่ชั่วโมงของ agent เป็นงานเอง ถ้าไม่มี output แบบมีโครงสร้างอย่าง commit, PR หรือรายงาน คุณจะกลายเป็นคนเลื่อนดู log ทั้งวัน

และประเด็นสุดท้ายที่ผมคิดว่าสำคัญที่สุด: ทักษะที่แพงขึ้นไม่ใช่การสั่งงาน แต่คือการเขียนสเปกงานให้รอดจากการปะทะกับผู้ปฏิบัติที่ทำงานเองทั้งวัน [5] การเขียนโจทย์ให้แม่นพอที่ agent จะวิ่งได้ทั้งวันโดยไม่หลุดเป้า ยากกว่าการทำงานนั้นเองซะอีก

สรุปมุมมองของผม

ปี 2026 คือปีที่ long-running agent เลื่อนจากห้องทดลองมาเป็นของใช้ได้จริง ฝั่งโมเดลเร็วขึ้นเรื่อยๆ ตามเส้นของ METR แต่สิ่งที่น่าจับตากว่าคือฝั่งวิธีสั่งงาน เพราะทุกค่ายใหญ่มาบรรจบกันที่สถาปัตยกรรมคล้ายกัน: แยกผู้วางแผน ผู้ลงมือ ผู้ตรวจ เก็บความจำไว้นอกโมเดล และห้ามเชื่อคำว่าเสร็จจนกว่าจะผ่านการตรวจ

สำหรับคนที่อยากลอง ผมแนะนำให้เริ่มจากงานกลุ่มเล็กสุดก่อน งานที่มี test รออยู่แล้ว ลองเขียน feature list เขียนสมุดบันทึก แล้วปล่อย agent รันข้ามคืน คุณจะได้เรียนรู้ว่าอะไรพังก่อนใน setup ของคุณเอง ดีกว่าอ่านคนอื่นอย่างเดียว

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

ถ้าชอบบทความแนวเบื้องหลังวิศวกรรม AI แบบนี้ ติดตาม Nokka ได้ที่ dev.to/sarantoon

แหล่งอ้างอิง

[1] Kimi Team. "KIMI K3: Open Frontier Intelligence" (Technical Report). 2026. https://arxiv.org/abs/2607.24653

[2] Anthropic. "Effective harnesses for long-running agents". 2026. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

[3] Anthropic. "Long-running Claude for scientific computing". 2026. https://www.anthropic.com/research/long-running-Claude

[4] Cursor. "Scaling long-running autonomous coding". 2026. https://cursor.com/blog/scaling-agents

[5] Osmani, Addy. "Long-running Agents". 2026. https://addyosmani.com/blog/long-running-agents/

[6] METR. "Task-Completion Time Horizons of Frontier AI Models". 2026. https://metr.org/time-horizons/

[7] Google. "Introducing Gemini 3.8 Flash and 3.8 Flash Cyber". 2026. https://blog.google/innovation-and-ai/models-and-research/gemini-models/3-8-flash-and-3-8-flash-cyber/

---

บทความนี้วิเคราะห์จาก technical report ของ Kimi Team, engineering blog ของ Anthropic และ Cursor, บทความของ Addy Osmani และข้อมูลจาก METR ทุกแหล่งถูกอ่านจริงระหว่างการค้นคว้า ข้อมูล ณ 4 กันยายน 2026 Nokka