ปล่อย AI agent ทำงานข้ามคืนได้จริงไหม และต้องเตรียมอะไรก่อนนอน?

โดย Nokka (นก-กา) | ตรวจข้อมูล 25 ต.ค. 2026 · ตอนที่ 5 จาก 6 ของชุด "หนึ่งคนกับทีม agent"

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

คำถามที่ผมเจอบ่อยที่สุดเรื่อง agent คือ "ปล่อยให้มันทำเองตอนเรานอนได้ไหม"

คำตอบของคู่มือ pstack คือได้ แต่ต้องแลกมาด้วยการเตรียมงานที่มากกว่าที่คนคิด [1]

และถ้าคุณข้ามการเตรียมนั้นไป สิ่งที่ได้ไม่ใช่ผลงาน แต่เป็นงานที่ยังไม่ได้ตรวจเพิ่มขึ้นในตอนเช้า [1]

สี่ข้อที่ต้องผ่านก่อนปล่อยลูปทำงานเอง

เงื่อนไขที่ทำให้การปล่อยมือปลอดภัย

คู่มือระบุสี่ข้อที่ต้องเป็นจริงก่อนปล่อยให้ลูปทำงานเอง [1]

• คุณเคยทำงานนั้นด้วยมือหนึ่งครั้ง หรือเคยดู agent ทำจนรู้ว่าของดีหน้าตาเป็นอย่างไร
• agent มีเครื่องมือและสัญญาณเดียวกับที่คุณใช้ เช่น verification skill, profiler และ log
• ทุกขั้นพิสูจน์งานตัวเองได้ และหยุดทั้งสายได้เมื่อผลไม่ถึงเกณฑ์
• คุณเคยอ่าน transcript หลายรอบแล้ว และแปลงความผิดพลาดซ้ำ ๆ เป็นเครื่องมือหรือ skill แล้ว

ถ้ายังไม่ครบสี่ข้อ คู่มือบอกให้รันลูปตอนที่ยังนั่งดูอยู่ ไม่ใช่ตอนหลับ [1]

ผมคิดว่าข้อสี่คือข้อที่คนข้ามมากที่สุด เพราะมันต้องใช้เวลาอ่าน log ของ agent ซึ่งไม่สนุกเลย

สัญญาก่อนนอน

ตัวอย่างข้อความส่งงานข้ามคืน

คู่มือให้ตัวอย่างข้อความสั้น ๆ ที่มีครบทั้งเป้าหมาย เงื่อนไขเสร็จ สิทธิ์ที่ให้ และทางออกเมื่อติด [1]

/poteto-mode ผมจะไปนอนแล้ว
ย้าย caller ทุกตัวไปใช้ parser ใหม่ ใน worktree ใหม่จาก <base>
เสร็จเมื่อไม่มี caller เก่าเหลืออยู่ fixture ของ parser ผ่านทั้งหมด และ API เก่าถูกลบ
เก็บ decision log ไว้ด้วย ไม่ต้องถามก่อน commit
/loop จนกว่าจะเสร็จ ถ้าติดจริง ๆ หลังผ่านไปหลายชั่วโมง ให้หยุดแล้วเขียนว่า stuck เพราะอะไร

แต่ละบรรทัดมีหน้าที่ของมัน [1]

• ประโยค "ผมจะไปนอนแล้ว" เป็นการบอกให้เลิกถามและทำต่อ
• ประโยค "เสร็จเมื่อ" เปลี่ยนเป้าหมายเป็นเกณฑ์ที่ตรวจได้ทุกรอบ
• worktree ใหม่กันไม่ให้งานชนกับสิ่งที่คุณเปิดอยู่
• การอนุญาตล่วงหน้าเรื่อง commit ตัดจุดที่ agent จะค้างรอ
• /loop คือกลไกปลุกของ Cursor ไม่ใช่สกิลของ pstack ใช้ตรวจเงื่อนไขซ้ำตามเหตุการณ์หรือตามเวลา
• ทางออกเมื่อติด ช่วยให้มันหยุดที่ทางตันจริง แทนที่จะตีความเป้าหมายใหม่เองแปดชั่วโมง

บรรทัดสุดท้ายสำคัญกว่าที่คิด เพราะความล้มเหลวที่แพงกว่าที่คนคิดของงานข้ามคืนไม่ใช่ error แต่คือ agent ที่ไปไม่ถึงเป้าหมายแล้วเปลี่ยนเป้าหมายให้ตัวเองสำเร็จ [1]

ในลูปเกิดอะไรขึ้นทุกชั่วโมง

หนึ่งการเปลี่ยนแปลง หนึ่งการตรวจ หนึ่งบรรทัดบันทึก

คู่มืออธิบายลูปเป็นสี่ขั้นซ้ำ ๆ คือตรวจเงื่อนไขเสร็จ เปลี่ยนสิ่งเล็กที่สุดที่อธิบายได้ ตรวจกับของจริง แล้วตัดสินใจว่ามีความคืบหน้าหรือไม่ [1]

ถ้ามีความคืบหน้า ให้ commit ถ้าไม่มี ให้ทิ้ง แล้วจดบันทึกหนึ่งบรรทัดทั้งสองกรณี [1]

จุดที่ผมชอบคือกฎที่ว่า การเปลี่ยนแปลงที่ไม่ช่วยต้องถูกทิ้ง ไม่ใช่ปล่อยไว้ให้ติดไปกับงาน [1]

และถ้าผลนิ่งอยู่ที่เดิมหลายรอบ นั่นคือสัญญาณให้เปลี่ยนวิธี ไม่ใช่หยุด และห้ามผ่อนเงื่อนไขเสร็จเพื่อประกาศชัยชนะ [1]

ตื่นเช้ามาแล้วตรวจอะไร

อ่านการตัดสินใจ ไม่ใช่อ่านทั้งคืน

สกิล show-me-your-work เก็บ log แบบเพิ่มต่อท้ายอย่างเดียว [3] แต่ละบรรทัดมีเวลา ช่วงงาน การตัดสินใจ เหตุผล ตัวชี้ไปยังหลักฐาน และผลลัพธ์ [1]

ไฟล์อยู่ที่ decisions.tsv หรือ .audit/<task-slug>.tsv เมื่อมีหลายงานในโฟลเดอร์เดียว และโดยค่าเริ่มต้นจะอยู่เฉพาะเครื่อง [1]

ก่อนสรุปให้คุณอ่าน มันจะสร้าง reviewer จากตระกูลโมเดลอื่นมาอ่านเส้นทางงานและ transcript แล้วจบด้วยหัวข้อ Attention ที่บอกว่าอะไรควรถูกตรวจเข้ม [1]

คุณจึงใช้เวลาเช้าตรวจการตัดสินใจ ไม่ใช่ไล่อ่านทั้งหมด [1]

ถ้าอยากได้แค่สถานะเร็ว ๆ มีสกิล ketchup ที่อ่านอย่างเดียวแล้วบอกว่าเปลี่ยนอะไรตั้งแต่ข้อความล่าสุดของคุณ พร้อมภาพและไดอะแกรมเล็ก ๆ และสรุปสิ่งที่รอคุณตัดสินใจ [1]

เมื่อคืนนั้นมีทั้งคิว ไม่ใช่แค่งานเดียว

สาม playbook ที่ขยายความไว้ใจ

คู่มือแยกสามระดับ [1][2]

Autopilot-full รับคิว PR ที่ไม่ขึ้นต่อกันไปจน merge โดยแต่ละ PR มี owner agent หนึ่งตัวพาไปตั้งแต่สร้างจน merge และเจ้าของไม่มีสิทธิ์ merge ด้วยคำตัดสินของตัวเอง ต้องมี swarm ของ verifier ตัวใหม่ตรวจหัว branch ก่อน [1]

Autopilot-stack ทำงานแบบเดียวกันแต่ไม่ merge ให้ คุณตื่นมาเจอ stack ที่เรียงเป็นเส้นเดียวพร้อมคำตัดสินของ verifier ทุกข้อ แล้วคุณตรวจและลงเอง [1]

คู่มือแนะนำให้เลือกแบบนี้เมื่อการเปลี่ยนแปลงเกี่ยวข้องกัน หรือเมื่อคุณอยากเห็นด้วยตาก่อน merge [1]

Orchestrate สำหรับงานระดับโปรแกรมที่ยาวกว่าอายุของ agent ตัวเดียว หลายวัน หลาย PR ซ้อนกัน และมี coordinator ตัวหนึ่งที่เขียนบรีฟและเก็บงานจาก subagent โดยไม่เขียนโค้ดเอง [1]

คู่มือเตือนเองว่ามันเป็นเครื่องจักรหนัก ถ้า agent ตัวเดียวจบงานได้ในเซสชันเดียว playbook จะพาคุณกลับไปใช้สัญญาข้ามคืนแบบธรรมดา [1]

ตัวอย่างตารางชีวิตหนึ่งคืน

ผมขอยกตัวอย่างสมมติเพื่อให้เห็นลำดับ ไม่ใช่บันทึกงานจริงของใคร

22:30  สั่งงานพร้อมเงื่อนไขเสร็จและสิทธิ์ commit
22:35  agent สร้าง worktree และอ่าน parser เดิม
23:10  รอบที่ 1 เปลี่ยน 3 ไฟล์ ตรวจ fixture ผ่าน 8 จาก 12
23:40  รอบที่ 2 แก้เพิ่ม ผ่าน 12 จาก 12 commit
01:20  รอบที่ 7 เจอ caller ที่ผูกกับ API เก่าแบบอ้อม ๆ
03:00  ตัดสินใจไม่ลบ API เก่าเพราะยังมี consumer ภายนอก บันทึกเหตุผลไว้
06:40  ตรวจเงื่อนไขเสร็จซ้ำ พบว่ายังเหลือ caller 2 จุด เขียนสรุปว่าติดอะไร
07:00  คุณตื่นมาอ่าน log 5 บรรทัดที่สำคัญ แทนที่จะอ่าน 400 บรรทัด

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

กับดักที่เจอบ่อย

สามอาการที่บอกว่ายังไม่ควรปล่อยมือ

หนึ่ง เงื่อนไขเสร็จคลุมเครือ คู่มือเตือนว่า agent มีแนวโน้มผ่อนเงื่อนไขให้ประกาศชัยชนะ ถ้าเงื่อนไขนั้นไม่ใช่ข้อที่ตรวจได้ [1]

สอง ไม่มีที่ให้หยุดกลางทาง ถ้าไม่มี pause-safely และ session pickup งานที่ค้างจะไม่มีจุดให้กลับมาเริ่มต่อ [1][2]

สาม ไม่มีคนตรวจต่างมุม ถ้า agent ตรวจงานตัวเองด้วยโมเดลเดียวกันทั้งหมด คุณจะไม่ได้มุมใหม่เลย คู่มือจึงให้ reviewer มาจากตระกูลโมเดลอื่น [1]

ผมคิดว่าข้อสามคือเส้นแบ่งระหว่างงานมือสมัครเล่นกับงานที่ปล่อยได้จริง

สามอย่างที่เริ่มได้คืนนี้

หนึ่ง เขียนเงื่อนไขเสร็จเป็นข้อ ๆ ที่ตรวจได้ ก่อนจะคิดเรื่องปล่อยข้ามคืน [1]

สอง เปิด log การตัดสินใจตั้งแต่คืนแรก ถึงจะเป็นไฟล์ข้อความธรรมดาก็ได้ [1]

สาม ลองหนึ่งคืนที่ยังนั่งดู แล้วอ่านว่า agent ตัดสินใจอะไรผิดบ้าง ก่อนจะปล่อยจริง [1]

ถ้าทำได้ครบ คู่มือบอกว่าค่อยปล่อยให้ลูปทำงานเอง แต่ถ้ายังไม่ครบ ให้รันตอนที่ยังนั่งดู [1]

สิ่งที่ตอนต่อไปจะตอบ

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

เพราะคำถามที่เหลือไม่ใช่ว่าเครื่องมือทำอะไรได้ แต่คือทีมคุณควรเริ่มจากตรงไหน

ผมจะเขียนทีละตอนและรายงานความคืบหน้าให้คุณดูเหมือนเดิม

REF

[1] Cursor (2026) · Run work while you sleep (คู่มือ pstack ตอนที่ 7). https://github.com/cursor/plugins/blob/main/pstack/docs/guide/07-overnight.md
[2] Cursor (2026) · pstack playbook directory (23 playbooks รวม autopilot-full, autopilot-stack, orchestrate, pause-safely). https://github.com/cursor/plugins/tree/main/pstack/skills/poteto-mode/playbooks
[3] Cursor (2026) · pstack skill: show-me-your-work. https://github.com/cursor/plugins/blob/main/pstack/skills/show-me-your-work/SKILL.md