คุณสั่งให้โค้ดดิ้งเอเจนต์ลงมือทำงานจริงสักงาน ปิดแล็ปท็อป แล้วไปกินข้าวเที่ยง ส่วนนั้นง่าย แต่ส่วนที่ยากคือสิ่งที่คุณเจอตอนกลับมา: เทอร์มินัลที่เลื่อนพ้นขอบจอไปแล้ว, diff ที่คุณไม่ได้ดูตอนมันถูกเขียน และไม่มีคำตอบชัดเจนสำหรับคำถามเดียวที่สำคัญที่สุด นั่นคืองานนี้ดีพอจะเก็บไว้หรือไม่
การรันเอเจนต์แบบไม่มีคนเฝ้ามีสองครึ่ง และการตั้งค่าส่วนใหญ่แก้ได้แค่ครึ่งแรก ครึ่งแรกคือการทำให้โปรเซสยังมีชีวิตและยังทำงานได้ขณะที่ไม่มีใครดูอยู่ ครึ่งที่สองคือคิวตรวจงาน: กองของงานที่เสร็จแล้ว งานที่ทำค้างไว้ และงานที่ล้มเหลว ซึ่งรอให้มนุษย์ตัดสินใจตอนคุณกลับมา ถ้าข้ามครึ่งหลังไป เอเจนต์แบบไม่มีคนเฝ้าก็แค่ย้ายคอขวดจากการเขียนโค้ดไปเป็นการไล่ปะติดปะต่อว่าเกิดอะไรขึ้น
บทความนี้ครอบคลุมทั้งสองครึ่ง: วิธีตั้งค่าการรันแบบไม่มีคนเฝ้าด้วยตัวเอง, รูปแบบความล้มเหลวในแต่ละขั้นตอน และจุดที่การตั้งค่าแบบทำเองเริ่มขยายไม่ไหว เมื่อหนึ่งเทอร์มินัลกลายเป็นห้า บอร์ดงานอย่าง Sharkly จะวางตัวอยู่เหนือโค้ดดิ้งเอเจนต์ของคุณ คุณยังคงให้ Claude Code, Codex หรือ Gemini CLI ทำงานอยู่ ส่วน Sharkly เก็บงาน การรัน และการตรวจสอบไว้ในที่เดียว แทนที่จะกระจัดกระจายไปตามเทอร์มินัลที่คุณปิดไปแล้ว
การรันเอเจนต์แบบไม่มีคนเฝ้าเกี่ยวข้องกับอะไรจริง ๆ
การรันแบบไม่มีคนเฝ้า (unattended run) คือโค้ดดิ้งเอเจนต์ที่ทำงานหนึ่งบนโฮสต์ที่คุณไม่ได้เฝ้าดูอยู่ตลอด โดยเก็บเอาต์พุตไว้ให้ตรวจย้อนหลังได้ คำจำกัดความนี้มีสามส่วนที่รับน้ำหนักทั้งหมด: งานที่เอเจนต์ทำเสร็จได้โดยไม่มีคุณ, โฮสต์ที่ยังทำงานต่อเมื่อคุณตัดการเชื่อมต่อ และบันทึกที่คุณอ่านย้อนหลังได้
ส่วนที่คนมักประเมินต่ำไปคือบันทึกนี่แหละ ตอนที่คุณดูเอเจนต์ทำงานสด ๆ ตัวคุณเองคือล็อก คุณเห็นมันเลือกไฟล์ผิด คุณสั่งหยุด แล้วแก้ทางให้ แต่พอไม่มีคนเฝ้า สิ่งเหล่านั้นไม่เกิดขึ้นเลย ทุกอย่างที่เอเจนต์ทำต้องคงอยู่ในรูปแบบที่คุณเปิดตรวจแบบเย็น ๆ ได้ หลายชั่วโมงต่อมา โดยไม่เหลือความจำว่าสั่งอะไรไป เอเจนต์มีหน้าที่ค้นคว้า ลงมือ ทดสอบ และรายงาน ส่วนคนมีหน้าที่กำหนดทิศทาง ให้อำนาจ และรับผลลัพธ์ สัญญานี้จะยังใช้ได้ก็ต่อเมื่อรายงานนั้นเป็นของจริงและครบถ้วนตอนที่คุณกลับมาดู
ดังนั้นเป้าหมายไม่ใช่ “ทำให้เอเจนต์รันโดยไม่มีฉัน” แต่คือ “ทำให้เอเจนต์รันโดยไม่มีฉัน แล้วส่งคืนอะไรบางอย่างที่ฉันตรวจได้” สองอันนี้เป็นคนละปัญหา และอันที่สองคือจุดที่เวิร์กโฟลว์แบบไม่มีคนเฝ้ามักพัง
ตั้งค่าการรันแบบไม่มีคนเฝ้าด้วยตัวเอง
นี่คือเวอร์ชันทำมือแบบขั้นต่ำ พร้อมรูปแบบความล้มเหลวที่คอยกัดในแต่ละขั้น
ขั้นที่ 1: แยกงานออกมาให้โดดเดี่ยว ให้การรันมี checkout เป็นของตัวเอง เพื่อไม่ให้ชนกับเอดิเตอร์ของคุณหรือเอเจนต์ตัวอื่น
git worktree add ../task-auth-refactor -b task/auth-refactor
cd ../task-auth-refactor
รูปแบบความล้มเหลว: ถ้าข้ามขั้นนี้ แล้วรันสองตัวในไดเรกทอรีเดียวกัน มันจะเขียนทับการเปลี่ยนแปลงที่ยังไม่ commit ของกันและกัน ดู หนึ่ง checkout ต่อหนึ่งงาน เพื่อเข้าใจว่าทำไม worktree ไม่ใช่แค่ branch ถึงเป็นเส้นแบ่งของการแยกโดดเดี่ยว
ขั้นที่ 2: แยกโปรเซสออกจากเทอร์มินัล เซสชัน SSH หรือเทอร์มินัลของคุณจะปิด และโปรเซสที่รันอยู่เบื้องหน้าจะตายไปพร้อมกัน (SIGHUP) ทำให้มันมีชีวิตต่อด้วย nohup หรือเซสชัน tmux:
nohup claude -p "Refactor auth to use the new token service; run the tests" \
> run.log 2>&1 &
รูปแบบความล้มเหลว: ถ้ารันในเชลล์แบบ foreground ธรรมดา การปิดฝาแล็ปท็อปจะฆ่าเอเจนต์กลางทางการแก้ไขหลายไฟล์ ทิ้ง tree ที่พังไว้ nohup แก้เรื่องอายุขัยของโปรเซสได้ แต่ไม่เปิดทางให้คุณกลับเข้าไป ส่วน tmux ช่วยให้คุณเชื่อมต่อกลับเข้าไปดูได้ว่าเกิดอะไรขึ้น
ขั้นที่ 3: เก็บทุกอย่างไว้ > run.log 2>&1 ข้างบนไม่ใช่ตัวเลือกเสริม มันคือคิวตรวจงานในรูปแบบดิบที่สุด
รูปแบบความล้มเหลว: ถ้าไม่มีล็อกที่เก็บไว้ คุณจะตอบคำถาม “ทำไมมันถึงหยุด?” ไม่ได้ อาการค้างเงียบ ๆ ที่พบบ่อยที่สุดคือเอเจนต์รอคำตอบจากพรอมป์แบบอินเทอร์แอกทีฟไปตลอดกาล ซึ่งไม่มีใครมาตอบ เพราะการรันแบบไม่มีคนเฝ้าหมายความว่าไม่มีใครอยู่ตรงนั้นเพื่อพิมพ์ “yes” ให้รันในโหมดที่ไม่ใช่อินเทอร์แอกทีฟ และอนุมัติล่วงหน้าเฉพาะชุดการกระทำแคบ ๆ ที่งานนั้นต้องใช้
ขั้นที่ 4: จำกัดขอบเขตความเสียหาย ตัดสินใจก่อนเดินจากไปว่าเอเจนต์ทำอะไรได้เองบ้าง และอะไรที่ต้องรอคุณ จำกัดขอบเขตไฟล์ ห้าม force-push และอย่าให้การรันแบบไม่มีคนเฝ้า merge เข้า branch ที่ได้รับการป้องกันเด็ดขาด
รูปแบบความล้มเหลว: การรันที่ให้สิทธิ์เกินพอดีจน push เข้า main ตรง ๆ ไม่ใช่ชัยชนะด้าน productivity แต่เป็นเหตุการณ์ไม่พึงประสงค์ ด่านอนุมัติ (approval gates) มีไว้เพื่อให้เอเจนต์หยุดที่จุดปลอดภัยจุดสุดท้ายแล้วรอ
ขั้นที่ 5: รู้ว่ามันเสร็จเมื่อไหร่ และเสร็จแบบไหน ตรวจ exit code และส่งสัญญาณหาตัวเอง เพื่อไม่ต้องคอยเปิดล็อกดูด้วยมือซ้ำ ๆ
claude -p "..." > run.log 2>&1; echo "exit $?" | mail -s "auth run done" [email protected]
รูปแบบความล้มเหลว: ถ้าไม่มีสัญญาณแจ้งว่าเสร็จ “ไม่มีคนเฝ้า” จะกลายเป็น “ฉันเปิดไปดูเทอร์มินัลทุกยี่สิบนาที” ซึ่งก็แค่การมีคนเฝ้าแบบเพิ่มความหน่วงเข้าไปเท่านั้น
จุดที่การตั้งค่าแบบทำเองเริ่มขยายไม่ไหว
เอเจนต์หนึ่งตัว worktree หนึ่งตัว ไฟล์ล็อกหนึ่งไฟล์: แบบนี้ใช้ได้ และสำหรับการรันครั้งเดียวคุณไม่ต้องอะไรที่หนักกว่านี้ แต่มันพังทันทีที่มากกว่าหนึ่ง
รันเอเจนต์สามตัวบนสามงาน คุณก็ได้สาม worktree สามไฟล์ล็อก สาม exit code และอีเมลแจ้งเสร็จสามฉบับที่คุณจะอ่านสลับกันตอนกวาดตามอง การแยกโดดเดี่ยวยังใช้ได้อยู่ แต่สิ่งที่พังคือคิวตรวจงาน ไม่มีอะไรบอกคุณว่าการรันไหนเสร็จเรียบร้อย ตัวไหนล้มเพราะเทสต์ไม่ผ่าน และตัวไหนกำลังรอพรอมป์อยู่เงียบ ๆ คุณต้องไล่ประกอบขึ้นมาเองด้วยการอ่านล็อกทีละไฟล์ ซึ่งก็คืองานที่คุณพยายามจะโยนออกไปนั่นเอง
นี่คือต้นทุนจริง และเป็นเรื่องที่มองข้ามได้ง่ายเพราะแต่ละชิ้นดูปกติดีเมื่อมองแยกกัน การมอนิเตอร์การรันขนานหลายตัวจะกลายเป็นปัญหาจริงเมื่อจำนวนเกินกว่าที่จอเดียวจะแสดงไหว ไฟล์ล็อกตอบคำถามว่า “การรันนี้พิมพ์อะไรออกมา” ไม่ใช่ “จากการรันหกตัวของฉัน มีตัวไหนสามตัวที่ต้องให้ฉันจัดการเดี๋ยวนี้” และ สัญญาณสถานะและความล้มเหลวที่ควรเก็บไว้ก็ไม่ได้จัดเรียงตัวเองเป็นคิวให้ ส่วนคิวนี่แหละคือหัวใจทั้งหมดของการทำงานตอนคุณไม่อยู่: คุณต้องการรายการการตัดสินใจที่จัดลำดับแล้ว ไม่ใช่ไดเรกทอรีของเอาต์พุตดิบ ๆ
บอร์ดงานเปลี่ยนอะไรไปบ้าง
บอร์ดงานคือที่ที่ปัญหาครึ่งหลังได้รับการแก้ การรันแบบไม่มีคนเฝ้ายังเกิดขึ้นบน Computer ที่คุณเชื่อมต่ออยู่ โดยมี Runtime เดิมของคุณเป็นตัวเขียนโค้ด สิ่งที่เปลี่ยนคือผลลัพธ์ไปลงที่ไหน
ใน Sharkly งาน การรัน และการตรวจสอบอยู่ใน Task เดียว คุณมอบหมาย Task ให้กับ Agent ซึ่งเป็นชุดการตั้งค่าที่บันทึกไว้ ทั้งคำสั่ง Runtime และรีโป ไม่ใช่พรอมป์แบบใช้ครั้งเดียวที่ต้องพิมพ์ใหม่ Agent จะรับ Task ไป รันใน worktree ที่แยกออกมา และการทำงาน อุปสรรค และผลลัพธ์จะกลับมาที่ไทม์ไลน์ของ Task เมื่อคุณกลับมา คุณไม่ต้องไล่ grep ไฟล์ล็อกหกไฟล์ คุณแค่เปิดบอร์ดแล้วอ่านคิว: อะไรเสร็จแล้ว อะไรล้มเหลว อะไรกำลังรอคุณอยู่
นี่คือเส้นแบ่งที่ควรพูดให้ชัด Sharkly ไม่ใช่ตัวแทนของ Claude Code, Codex หรือเครื่องมือสำหรับรันอื่น ๆ มันเพิ่มเลเยอร์ของงานที่ใช้ร่วมกัน Computer คอนเท็กซ์ และการตรวจสอบ เข้าไปล้อมรอบเครื่องมือที่ทีมคุณใช้อยู่แล้ว เอเจนต์ยังเป็นคนเขียนโค้ด ส่วน Sharkly ทำให้แน่ใจว่าตอนที่คุณไม่อยู่ โค้ดกลับมาอยู่ในที่ที่คุณมองเห็น พร้อมสรุปการเปลี่ยนแปลงและผลการทดสอบแนบมาด้วย และการยอมรับขั้นสุดท้ายยังคงเป็นการตัดสินใจของมนุษย์ ระบบอัตโนมัติหยุดตรงจุดที่ต้องใช้วิจารณญาณ
คุณสร้างทั้งหมดนี้ด้วยมือได้ด้วย worktree, nohup และคำสั่ง mail กฎการตัดสินใจที่ซื่อตรงคือ: ถ้าคุณรันเอเจนต์เป็นครั้งคราว การตั้งค่าแบบทำมือก็เพียงพอ และ Sharkly จะกลายเป็นภาระที่ไม่จำเป็น สมการจะเปลี่ยนเมื่อมีเอเจนต์หลายตัวรันข้ามงานและรีโป และคิวตรวจงานกลายเป็นสิ่งที่คุณใช้เวลาทั้งเช้าไปกับมัน ถ้าคุณอยากใช้โค้ดดิ้งเอเจนต์หลายตัวต่อไปแทนที่จะผูกกับระบบนิเวศเดียว คิวนั้นแหละคือปัญหาที่ Sharkly ออกแบบมาเพื่อแก้
คิวตรวจงานคือคอขวดตัวจริง
นี่คือสมมติฐานที่ควรตั้งคำถาม: คนมักไปจูนการรันแบบไม่มีคนเฝ้าให้ดีที่สุด และมองการตรวจงานเป็นเรื่องหลังบ้าน มันกลับกัน การรันเอเจนต์ขนานกันตอนคุณนอน จะเป็นกำไรก็ต่อเมื่อการตรวจผลลัพธ์เช้าวันรุ่งขึ้นเร็วกว่าการลงมือทำเอง ถ้าเอเจนต์ห้าตัวทำงานเสร็จข้ามคืน แต่การตรวจ diff ทั้งห้าใช้เวลานานกว่าการเขียนสองอันเอง ความขนานนั้นก็ไม่ให้อะไรเลย
ดังนั้นออกแบบคิวตรวจงานก่อน ตัดสินใจว่าอะไรต้องรวมอยู่ในนิยามของ “เสร็จ” ก่อนที่การรันจะมาถึงมือคุณ: เทสต์ผ่าน, typecheck ผ่าน, สรุปการเปลี่ยนแปลง และบันทึกข้อจำกัดที่รู้อยู่ เรียงคิวตามความเสี่ยง ไม่ใช่ตามเวลาที่เสร็จ เพื่อให้การรันที่แตะเรื่อง auth ได้ความสนใจก่อนตัวที่แค่แก้คำผิด ทำให้ “ขอให้แก้” ถูกราคาเท่ากับ “อนุมัติ” เพราะการรันแบบไม่มีคนเฝ้าครึ่งหนึ่งจะเกือบใช่แต่ยังไม่ใช่ การตรวจสอบคือคอขวดในเวิร์กโฟลว์เอเจนต์ขนานทุกรูปแบบ และที่ที่เอเจนต์รันจริง ๆ ไม่ว่าจะเป็น เซิร์ฟเวอร์ของคุณ แล็ปท็อปของคุณ หรือทั้งสองอย่าง สำคัญน้อยกว่ามากเมื่อเทียบกับว่าเอาต์พุตของมันมาถึงในรูปของคิวที่คุณเคลียร์ได้หรือไม่
เช็กลิสต์ที่ใช้ได้ตั้งแต่วันนี้
ก่อนเดินจากเอเจนต์ไป ให้ยืนยันว่า:
- การแยกโดดเดี่ยว: การรันมี worktree ของตัวเอง ไม่ใช่ checkout ที่คุณทำงานอยู่
- อายุขัยของโปรเซส: โปรเซสอยู่รอดเมื่อการเชื่อมต่อขาด (
nohup,tmuxหรือ Computer ที่มีการจัดการ) การปิดฝาแล็ปท็อปจึงไม่ฆ่ามันกลางการแก้ไข - การเก็บข้อมูล: stdout และ stderr ถูกเขียนลงล็อกที่คงอยู่ หรือไทม์ไลน์ของ Task ที่คุณอ่านย้อนหลังได้
- ไม่ใช่อินเทอร์แอกทีฟ: เอเจนต์จะไม่ค้างรอพรอมป์ที่ไม่มีใครตอบ
- ขอบเขตความเสียหาย: ขอบเขตไฟล์ถูกจำกัด ปิด force-push และไม่มีการรันแบบไม่มีคนเฝ้าใด merge เข้า branch ที่ได้รับการป้องกัน
- สัญญาณแจ้งเสร็จ: คุณได้รับแจ้งเมื่อมันเสร็จและผ่านหรือไม่ โดยไม่ต้องคอยเช็คเอง
- สัญญาการตรวจงาน: ทุกการรันที่เสร็จมาพร้อมเทสต์ สรุปการเปลี่ยนแปลง และข้อจำกัดที่รู้อยู่ และการยอมรับยังเป็นของคุณ
หกข้อแรกทำให้การรันเป็นแบบไม่มีคนเฝ้า ข้อสุดท้ายทำให้มันคุ้มค่าที่จะทำ ถ้าคุณรันเอเจนต์หลายตัวอยู่แล้ว และการตรวจงานตอนเช้าคือที่ที่เวลาของคุณหมดไป ลอง รันโค้ดดิ้งเอเจนต์ที่มีอยู่ผ่าน Sharkly เพื่อให้คิวมาหาคุณแบบจัดระเบียบแล้ว แทนที่จะกระจัดกระจาย
