Autonomous AI agent: วิธีให้เอเจนต์ทำงานหลายชั่วโมงโดยไม่ได้ผลลัพธ์รก

Autonomous AI agent คืออะไร และต่างจากการสั่งงานปกติอย่างไร

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

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

ข้อควรระวังสำคัญคือ วงวนไม่ได้มาแทนฮาร์เนส ฮาร์เนสทำให้การรันหนึ่งครั้งเชื่อถือได้ ส่วนวงวนทำให้การรันต่อเนื่องได้ วงวนที่วางบนฮาร์เนสที่ไม่ดีก็แค่ผลิตขยะได้เร็วขึ้นเท่านั้น

งานแบบไหนเหมาะกับ autonomous agent

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

ควรแยกวงวนออกเป็นสี่แบบ:

• ทีละขั้น — คุณพิมพ์ prompt ทุกครั้ง นี่คือการทำงานแบบโต้ตอบปกติ
• ตามเป้าหมาย — คุณกำหนดเป้าหมาย แล้วการตรวจอิสระหรืองบจะเป็นตัวหยุด นี่คือ autonomous agent ที่ทำงานหลายชั่วโมง
• ตามเวลา — รันตามตารางเวลา (เช่น ทบทวนบิลด์ CI ที่ล้มทุกเช้า) และคุณเป็นคนหยุดเอง
• ตามเหตุการณ์ — ถูกกระตุ้นด้วยเหตุภายนอก (มี issue ใหม่ หรือ deploy ล้ม) และหยุดเมื่อประมวลผลเหตุการณ์จบหรือถึงลิมิตการลองซ้ำ

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

ขั้นที่ 1. Sandbox: เอเจนต์ทำพังได้ตรงไหน

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

• สำเนาการทำงานแยก git worktree ให้เอเจนต์มีไดเรกทอรีและ branch ของตัวเองบน repository เดียวกัน branch หลักไม่ถูกแตะ เอเจนต์หลายตัวไม่รบกวนกัน และการรันที่ล้มเหลวลบทิ้งได้ด้วยคำสั่งเดียว
• คอนเทนเนอร์หรือเครื่องเสมือน ถ้าเอเจนต์ต้องใช้คำสั่งได้เต็มที่ ให้รันในคอนเทนเนอร์ที่ไม่เห็นโฮมไดเรกทอรี กุญแจ และฐานข้อมูลโปรดักชัน
• ข้อมูลทดสอบ ฐานข้อมูลในเครื่อง sandbox ของระบบชำระเงิน คีย์ปลอม ไม่มีความลับของโปรดักชันอยู่ในสภาพแวดล้อมของเอเจนต์เลย

# สาขาและไดเรกทอรีของตัวเองสำหรับการรันอัตโนมัติ
git worktree add ../shop-agent -b agent/f03-refunds

# หลังการรัน: ดูผลลัพธ์ หรือทิ้งไป
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

ขั้นที่ 2. สิทธิ์: น้อยที่สุดเท่าที่งานต้องการ

ยิ่งเอเจนต์ทำงานคนเดียวนานเท่าไร สิทธิ์ของมันยิ่งต้องแคบลง ใน Claude Code สิทธิ์ตั้งค่าได้ใน settings.json (รายการ allow และ deny สำหรับเครื่องมือและคำสั่ง) อนุญาตอย่างชัดเจนสิ่งที่งานต้องใช้ เช่น รันเทสต์ รันลินเตอร์ แก้ไฟล์ในสำเนาการทำงาน และห้ามสิ่งอันตราย เช่น push ไป branch หลัก การเข้าถึงความลับ หรือคำสั่งเครือข่ายที่ไม่จำเป็น

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

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

ขั้นที่ 3. เป้าหมาย การตรวจ และการหยุด: สามบรรทัดก่อนเริ่ม

วงวนที่ใช้งานได้ง่ายๆ ตั้งอยู่บนสามสิ่ง ควรเขียนไว้ก่อนเริ่ม ไม่ใช่ตอนที่กำลังรันไปแล้ว:

1. เป้าหมาย สถานะสุดท้ายหน้าตาเป็นอย่างไร
2. การตรวจ วิธีที่เครื่องตรวจได้ว่าบรรลุเป้าหมายแล้ว เช่น คำสั่งที่คืนค่าสำเร็จหรือล้มเหลว
3. เงื่อนไขหยุด ลิมิตจำนวนครั้ง เวลา หรือเงิน ที่เมื่อถึงแล้ววงวนหยุด แม้เป้าหมายยังไม่สำเร็จ

ควรเก็บสิ่งนี้ไว้ในไฟล์แยกสำหรับวิธีการ ที่มีเพียงคนเท่านั้นที่แก้ไขได้ ตัวอย่างสำหรับแบ็กเอนด์ระบบชำระเงิน:

# program.md — วิธีการสำหรับการรันอัตโนมัติ

## เป้าหมาย
ฟีเจอร์ทั้งหมดใน .agent/feature_list.json อยู่ในสถานะ passing

## ตัวชี้วัด
จำนวนฟีเจอร์ใน passing เพิ่มขึ้นอย่างต่อเนื่อง การถดถอย = ย้อนกลับทันที

## ข้อจำกัด
- ทำงานกับฟีเจอร์เดียวในแต่ละช่วงเวลา
- ไม่แก้ migrations/ และ infra/
- ไม่เปลี่ยน dependency โดยไม่บันทึกลงล็อก

## ลำดับการทำงาน
1. เลือกฟีเจอร์แรกที่ไม่อยู่ใน passing
2. ทำให้เสร็จ รัน pytest และลินเตอร์
3. ผ่านแล้ว commit และบันทึกใน .agent/progress.md ไม่ผ่าน แก้ต่อ

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

ขั้นที่ 4. วงวนตรวจ-แก้ พร้อมความจำบนดิสก์

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

รูปแบบที่ดีคือ "ratchet ที่เดินหน้าได้อย่างเดียว" ตามโครงการ autoresearch ของ Andrej Karpathy ที่เอเจนต์รันการทดลอง ML หลายร้อยครั้งข้ามคืน แต่ละรอบ: อ่านวิธีการ ตั้งสมมติฐาน แก้โค้ด รันการทดลองด้วยงบเวลาคงที่ แล้วเปรียบเทียบกับ baseline ถ้าดีขึ้น commit ถ้าไม่ดีขึ้น rollback ผลลัพธ์ถูกบันทึกลงล็อก แล้วจึงไปสมมติฐานถัดไป

จากรูปแบบนี้ควรนำมาใช้สองการตัดสินใจ:

• งบคงที่ต่อหนึ่งความพยายาม ทำให้ความพยายามเทียบกันได้ และสมมติฐานที่ล้มเหลวหนึ่งครั้งไม่กินทั้งคืน
• ใน branch หลักมีแต่การปรับปรุง ทุกอย่างที่ไม่ได้ผลถูก rollback ไม่ใช่ทิ้งไว้ข้างๆ git log กลายเป็นบันทึกการทำงานที่ผ่านการตรวจแล้ว อ่านได้ง่ายในตอนเช้า

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

ขั้นที่ 5. ใครตัดสินว่าเสร็จ: ผู้ประเมินแยก

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

กฎแยกผู้สร้างกับผู้ประเมิน:

• เซสชันที่ทำงานต้องไม่เป็นคนประเมิน ใน Claude Code subagent เหมาะกับหน้าที่นี้เพราะแต่ละตัวมีบริบทของตัวเอง
• ผู้ประเมินได้บริบทที่สะอาด มีแค่ข้อกำหนด diff และผลการรัน ไม่มีเหตุผลของผู้ทำงานอยู่ในนั้น
• ถ้าเป็นไปได้ ผู้ประเมินควรเป็นโมเดลอื่น หรืออย่างน้อยเป็น prompt อีกชุดที่มีบทบาทต่างออกไป
• คำตัดสินต้องอิงตามเกณฑ์ (rubric) และแต่ละข้อมีหลักฐาน เช่น บรรทัดของเทสต์ ผลลัพธ์ของคำสั่ง หรือตำแหน่งใน diff

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

เกณฑ์หยุด: เมื่อไรเอเจนต์ควรยอมแพ้

วงวนที่ไม่มีเงื่อนไขหยุดจะวนไม่รู้จบ เป็นเพียงเรื่องของเวลา ชุดขั้นต่ำมีดังนี้:

ตรวจความคืบหน้าจากเนื้อหาจริง ไม่ใช่จากจำนวนความพยายาม "ทำไปแล้ว 40 รอบ" ไม่ได้บอกอะไร แต่ "จำนวนฟีเจอร์ที่ผ่านเพิ่มจาก 5 เป็น 9" บอกได้ ถ้างานติดขัด นั่นคือสัญญาณให้ส่งต่อให้คน ไม่ใช่ให้วงวนทำซ้ำอีกรอบ

ความเสี่ยงของ autonomous agent ที่มองไม่เห็นในตอนแรก

ความเสี่ยงที่เห็นชัดอย่างไฟล์ที่ถูกลบหรือบิลด์ที่พัง ถูกป้องกันด้วย sandbox และสิทธิ์ ส่วนที่อันตรายกว่าคือต้นทุนเงียบๆ ที่สะสมเป็นสัปดาห์:

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

วิธีเริ่มวงวนแรกภายในหนึ่งคืน

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

1. หางานที่คุณทำด้วยมือเป็นอย่างน้อยสองครั้งต่อสัปดาห์และมีจุดจบที่ตรวจได้
2. เขียนเป้าหมาย การตรวจ และเงื่อนไขหยุด สามบรรทัด
3. สร้าง worktree แยกและตั้งค่าสิทธิ์ อนุญาตให้รันเทสต์และแก้ไฟล์ แต่ไม่อนุญาต push และความลับ
4. สร้างไฟล์ความคืบหน้าและขอให้เอเจนต์อัปเดตหลังทุกรอบ
5. แยกบทบาท ผู้ทำเขียนโค้ด ผู้ตรวจประเมิน diff ในบริบทที่แยกต่างหาก
6. ตั้งลิมิตรวม และครั้งแรกให้ตรวจผลหลังหนึ่งชั่วโมง ไม่ใช่รอถึงเช้า

สรุป

Autonomous AI agent น่าเชื่อถือเท่ากับกรอบที่ครอบมันอยู่ ได้แก่ sandbox ที่ความผิดพลาดไม่มีราคา สิทธิ์ที่น้อยที่สุด เป้าหมายที่ตรวจด้วยเครื่องได้ ความจำบนดิสก์ ผู้ประเมินแยกต่างหาก และเงื่อนไขหยุดที่เข้มงวดพร้อมการยกระดับไปยังคน ถ้าไม่มีสิ่งเหล่านี้ การรันยาวจะไม่ได้ประหยัดเวลา แต่กลายเป็นการไปแก้ปัญหาที่สะสมไว้ทีหลัง หัวข้อนี้ถูกสอนอย่างละเอียดพร้อมตัวอย่างจริงในคอร์สเกี่ยวกับ harness engineering ตั้งแต่ program.md ไปจนถึงผู้ประเมินอิสระในโปรเจกต์ตัวอย่างเดียวกัน