เอเจนต์ AI เจ็ดตัวทำงานแทนเราทุกคืน: เอเจนต์ตามกำหนดเวลาที่ทำมากกว่าเขียนโค้ด พร้อมพรอมต์

วันที่ 23 กันยายน ผู้ใช้ชื่อ Rob เขียนไว้บน backlog สาธารณะของเราว่า “would love to get examples of how you guys are doing stuff beyond coding” เป็นคำถามที่สมเหตุสมผล ทุกอย่างบนเว็บไซต์นี้พูดถึงเอเจนต์เขียนโค้ด แต่สิ่งที่เรารันจริงทุกเย็นส่วนใหญ่ไม่ใช่การเขียนโค้ด

ตั้งแต่วันที่ 28 สิงหาคม เอเจนต์เจ็ดตัวเริ่มทำงานบน Mac mini ตอน 20:00 น. พวกมันอ่านคอมมิตของวันนั้น Search Console แดชบอร์ดผู้ดูแลระบบ backlog ความคิดเห็นที่ผู้คนส่งมา และรายงานของคืนก่อน พวกมันแก้บั๊ก แก้ไขเว็บไซต์ เขียนและแปลบทความบล็อกทุกสามวัน โพสต์บนโซเชียลมีเดียสามเครือข่าย อัปเดตฐานความรู้ของผลิตภัณฑ์ และตอน 22:00 น. ตัวที่เจ็ดจะอ่านสิ่งที่อีกหกตัวทิ้งไว้แล้วส่งอีเมล 25 บรรทัด ไม่มีใครเฝ้าดู ผู้ก่อตั้งอ่านอีเมลบนโทรศัพท์ในเช้าวันถัดมา

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

33 คืนให้ผลอะไรบ้าง

โฟลเดอร์รายงานใน repository มีไดเรกทอรีตามวันที่ 33 โฟลเดอร์ ตั้งแต่ 28 สิงหาคมถึง 30 กันยายน อ่านแล้วได้ผลดังนี้:

• อีเมลตอนเช้า 31 ฉบับที่ผู้รายงานส่ง
• บั๊ก 51 รายการที่ผู้แก้บั๊กแก้ แต่ละรายการมีลิงก์คอมมิตอยู่ในบรรทัดรายงานของมัน หลายรายการผู้ใช้แจ้งไว้บน backlog สาธารณะและได้รับคำตอบในเวอร์ชันถัดไป
• บทความบล็อก 7 บทที่ทีม SEO เขียนตั้งแต่วันที่ 10 กันยายน ทุกสามวันหนึ่งบท แต่ละบทเขียนเป็นภาษาอังกฤษและภาษาฝรั่งเศสก่อน แล้วตามด้วยอีก 18 ภาษาในคืนเดียวกัน
• บันทึกโซเชียลมีเดีย 29 วัน: สามเครือข่ายและห้ากลุ่ม Facebook ต่อเย็น บวกคอมเมนต์ขอบคุณใต้ทุกโพสต์ที่ผู้ใช้แชร์ AgentsRoom
• ฐานความรู้ของผลิตภัณฑ์ราวหนึ่งร้อยแผ่นข้อมูล อัปเดตให้ตรงกับคอมมิตของวันนั้น ผู้ช่วยในแอปอ่านมัน และเว็บไซต์ให้บริการมันเป็น llms-full.txt

ไม่มีส่วนไหนเลยที่ต้องใช้คนหลัง 20:00 น. บางส่วนต้องใช้คนตอน 08:00 น. และนั่นคือเหตุผลของเอเจนต์ตัวสุดท้าย

รายชื่อทีม: ใครรันตอน 20:00 น.

เอเจนต์ทุกตัวคืองานที่กำหนดเวลาหนึ่งงานใน AgentsRoom: พรอมต์หนึ่งชุด เอเจนต์หนึ่งตัว (บทบาท CLI โมเดล) เครื่องหนึ่งเครื่อง และเวลาหนึ่งเวลา ทั้งเจ็ดตัวรัน Claude Code สองตัวในนั้นไม่ใช่เอเจนต์เดี่ยวแต่เป็นทีมสองขั้นตอน และเราจะกลับมาอธิบายว่าทำไม

ไฟล์ .md ในคอลัมน์สุดท้ายทั้งหมดอยู่ใน reports/night/<date>/ ถูกคอมมิตและพุชแล้ว โฟลเดอร์นั้นคือระบบประสานงานทั้งหมด และหัวข้อถัดไปจะอธิบายว่าทำไม

เชื่อมต่อกันอย่างไร

ทั้งเจ็ดตัวแต่ละตัวคืองานที่กำหนดเวลาที่มีรูปแบบเดียวกัน:

• เริ่มทุกวันตอน 20:00 น. (22:00 น. สำหรับผู้รายงาน) ไม่มีนิพจน์ cron ความถี่เลือกได้ในตัวแก้ไข
• ปักหมุดไว้กับเครื่องเดียว โปรเจกต์เปิดอยู่บนคอมพิวเตอร์หลายเครื่อง และทริกเกอร์จะทำงานบนทุกเครื่องที่มีโปรเจกต์นั้น เว้นแต่คุณจะจำกัดไว้ ของเราจำกัดไว้ที่ Mac mini ดังนั้นแล็ปท็อปที่เปิดตอน 20:05 น. จะไม่เริ่ม CEO ตัวที่สอง
• ปลุกเครื่อง Mac mini หลับอยู่ งานมีตัวเลือก “ปลุกเครื่อง” ซึ่งตั้งเวลาปลุกด้วยเครื่องมือของระบบปฏิบัติการเอง (pmset บน macOS, Task Scheduler พร้อมตัวเลือกปลุกเครื่องเพื่อรันบน Windows, rtcwake บน Linux) ไม่กี่วินาทีก่อนการรัน ถ้าไม่มีตัวเลือกนี้ เครื่องที่หลับอยู่ก็แค่พลาดการรันไป
• เปิดหรือปิดการรันชดเชย แยกตามงาน ถ้าเครื่องปิดอยู่ตอน 20:00 น. งานที่เปิดการรันชดเชยไว้จะทำงานเมื่อเปิดแอปครั้งถัดไป CEO, PM และผู้รายงานเปิดไว้ งาน SEO ผู้แก้บั๊ก โซเชียล และเอกสารปิดไว้: การรันที่เริ่มตอน 11:00 น. ของเช้าวันถัดไปจะชนกับงานระหว่างวันใน checkout เดียวกัน
• โหมดสิทธิ์ตั้งไว้ที่งาน ไม่ใช่ที่ผู้ให้บริการ การรันที่ไม่มีคนดูแลไม่สามารถหยุดรอคำขออนุมัติตอนตีสามได้ งานจึงรันโดยไม่ต้องขออนุมัติ ในขณะที่เอเจนต์ที่ผู้ก่อตั้งควบคุมเองบน CLI เดียวกันยังคงถามก่อนเสมอ
• คอนโซลปิดตัวเองหลังไม่มีการใช้งาน 60 นาที เอเจนต์ที่ทำงานเสร็จแล้วจะไม่ค้างอยู่ในแถบด้านข้างจนกว่าจะมีคนปิด
• พรอมต์คือข้อความแรก ข้อความของแต่ละพรอมต์เก็บไว้ในคลังพรอมต์ และเป็นข้อความเดียวกับช่องพรอมต์ของทริกเกอร์ การแก้อันหนึ่งจึงหมายถึงการแก้ทั้งสองอัน พรอมต์เขียนเป็นภาษาฝรั่งเศส เพราะผู้ก่อตั้งอ่านรายงานเป็นภาษาฝรั่งเศส ทุกอย่างที่เหลือ ตั้งแต่ข้อความคอมมิตไปจนถึงฐานความรู้ เป็นภาษาอังกฤษ

ยังมีอีกชิ้นหนึ่งที่ทั้งเจ็ดตัวใช้ร่วมกัน: skill ชื่อ “เอเจนต์กลางคืน กฎร่วม” ทุกพรอมต์เริ่มด้วย “โหลด skill นี้และนำไปใช้” และ skill นี้เก็บทุกอย่างที่เป็นจริงสำหรับทุกตัว: ใครรับผิดชอบอะไร ตัวกันหนึ่งคืนหนึ่งการรัน สิทธิ์ git รูปแบบรายงาน กฎของ backlog และรูปแบบอีเมลสำหรับผู้รายงาน เมื่อกฎเปลี่ยน มันเปลี่ยนที่เดียว

ส่งต่องานให้กันอย่างไรโดยไม่คุยกัน

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

Repository เอเจนต์แต่ละตัวเขียน reports/night/<date>/<agent>.md เปิดไฟล์นี้ในนาทีแรกของการรัน เขียนใหม่หลังงานแต่ละชิ้นเสร็จ คอมมิตและพุช รายงานมีสี่ส่วนตายตัว: “สรุปสั้น ๆ” (รายการหัวข้อย่อย หนึ่งข้อต่อหนึ่งสิ่งที่ทำ) “รอตัดสินใจ” (เฉพาะสิ่งที่พรอมต์สงวนไว้ให้คน) “รอตรวจสอบ” (URL ในเครื่องหรือหน้าจอที่ต้องเปิด) “รายละเอียด” (ยาวเท่าที่จำเป็น) และจบด้วยหมุดการรัน: คอมมิตล่าสุดที่เอเจนต์เห็น

Backlog เอเจนต์ที่เจองานสำหรับอีกตัวหนึ่งจะไม่ทำงานนั้นเอง มันเปิดตั๋วพร้อมแท็ก: ceo-fix สำหรับบั๊กเล็ก ๆ ที่ตรวจสอบแล้วซึ่งผู้แก้บั๊กจะรับไป, ceo-seo สำหรับงานเนื้อหาพร้อมคำค้นเป้าหมาย, ceo-decision สำหรับทุกอย่างที่ต้องใช้คน (ฐานข้อมูล การเรียกเก็บเงิน การยืนยันตัวตน การเข้ารหัส ราคา URL ที่ถูกจัดทำดัชนีแล้ว พฤติกรรมเริ่มต้น) ผู้ดูแลเอกสารอ่านคอมมิตแล้วพบฟีเจอร์ที่ยังไม่มีหน้าบนเว็บไซต์: มันเปิดตั๋ว ceo-seo แล้ว SEO ก็รับไปในคืนถัดไป CEO อ่านบันทึกข้อผิดพลาดแล้วพบบั๊กพร้อมสาเหตุในโค้ด: ceo-fix แล้วผู้แก้บั๊กก็รับไปในคืนถัดไป

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

วงจรปิดลงที่คน อีเมลของผู้รายงานจบด้วยหนึ่งบรรทัด: ถ้าจะตอบ product manager ให้เพิ่มส่วน “## การตัดสินใจ” ไว้ท้าย rapport.md (P1 OK / P2 ไม่: เหตุผล / P3 ภายหลัง) คอมมิต แล้วพุช PM อ่านเวอร์ชันที่พุชแล้วในเย็นวันถัดไปและทำตามสิ่งที่ได้รับอนุมัติ: สร้างตั๋ว รวมตั๋วที่ซ้ำกัน และพักส่วนที่เหลือไว้พร้อมเหตุผล การตัดสินใจที่ไม่ได้รับคำตอบเป็นเวลาสามคืนก็ถือเป็นการตัดสินใจ: ข้อเสนอจะออกจากอีเมลและคงอยู่เป็นตั๋ว

โมเดลไหนทำงานไหน และเพราะอะไร

ตารางด้านบนแสดงสองโมเดล นี่คือการตั้งค่าปัจจุบัน ไม่ใช่ผลการทดสอบเปรียบเทียบ และมันเปลี่ยนได้ แต่การแบ่งงานนี้ตั้งใจไว้

Fable สำหรับงานที่ต้องใช้วิจารณญาณ CEO ตัดสินว่าการกดไม่ถูกใจบน oracle เป็นข้อผิดพลาดจริงหรือแค่ความชอบ ผู้แก้บั๊กตัดสินว่ารายงานบั๊กเป็นบั๊กจริงหรือเป็นการตั้งค่าเฉพาะเครื่อง แล้วหาสาเหตุในโค้ด ขั้นตอนที่ 1 ของ SEO ตัดสินว่าประโยคไหนบนเว็บไซต์กลายเป็นข้อมูลผิดเพราะคอมมิตของวันนี้ จะเขียนบทความไหน และหน้าไหนควรปล่อยไว้ ขั้นตอนที่ 1 ของโซเชียลเลือกหัวข้อของเย็นนั้นและเขียนให้ผู้อ่านที่จับได้ว่าเป็นข้อความที่เครื่องสร้างภายในสามบรรทัด พรอมต์เหล่านี้ยาว (ของ SEO ประมาณ 4,000 คำ) และเต็มไปด้วยกฎ “คุณตัดสินใจ คุณไม่ถาม” พร้อมรายการข้อยกเว้นสั้น ๆ ตรงนี้แหละที่โมเดลที่แข็งแกร่งที่สุดคุ้มค่ากับต้นทุนของมัน

Opus ที่มีบริบท 1M สำหรับงานเชิงปริมาณ การแปลบทความเป็น 18 ภาษาด้วยซับเอเจนต์ ตัวละสามภาษา แล้วตรวจผลที่รวมกันเทียบกับต้นฉบับภาษาฝรั่งเศส คือการอ่านและการเขียนจำนวนมาก โดยใช้กฎเดิมซ้ำ 18 ครั้ง ผู้ดูแลเอกสารอ่าน diff ทั้งวันเทียบกับแผ่นข้อมูลหนึ่งร้อยแผ่น PM อ่านไฟล์ส่งออกขนาด 8 MB ของบทสนทนาตอนผู้ใช้ออก ผู้รายงานอ่านรายงานห้าฉบับแล้วคัดลอก มันไม่คิด ตรงนั้นบริบทขนาดใหญ่และต้นทุนต่อโทเค็นที่ต่ำกว่าสำคัญกว่าวิจารณญาณ

ดังนั้นสองในเจ็ดตัวจึงเป็นทีมเอเจนต์สองขั้นตอน แต่ละขั้นตอนคือเอเจนต์หนึ่งตัวที่มีโมเดลของตัวเอง ขั้นตอนที่ 1 บน Fable จบด้วยการเขียนส่วน “Handoff” ในรายงานที่ใช้ร่วมกัน: รายการที่แน่นอนของไฟล์และคีย์ที่ผู้แปลต้องส่งมอบ หรือโพสต์ที่แน่นอนที่ผู้โพสต์ต้องเผยแพร่ ขั้นตอนที่ 2 บน Opus อ่านส่วนนั้นและทำเฉพาะสิ่งที่ระบุไว้ กราฟของทีมเป็นเส้นตรง หนึ่งรอบ และรายงานคงบรรทัด “กำลังรัน” ไว้จนกว่าขั้นตอนที่ 2 จะลบออก เมื่อมองจากภายนอกตอน 22:00 น. รายงานที่ยังมีเครื่องหมาย “กำลังรัน” หมายถึงการรันที่ถูกตัด หรือทีมที่อยู่ระหว่างสองขั้นตอน และผู้รายงานจะบอกว่าเป็นแบบไหน

กฎสี่ข้อที่พรอมต์ต้องเรียนรู้

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

1. หมุดการรัน อ่านจากรายงานของเมื่อวาน เอเจนต์ SEO เวอร์ชันแรกอ่าน “คอมมิตใน 24 ชั่วโมงที่ผ่านมา” มีปัญหาสองข้อ: การรันตอน 20:00 น. และการรันตอน 20:10 น. ของวันถัดไปไม่ได้เห็น 24 ชั่วโมงเดียวกัน และคืนที่เอเจนต์ไม่ได้รันคือคอมมิตหนึ่งวันที่ไม่มีใครดู ตอนนี้ทุกรายงานจบด้วย คอมมิตล่าสุดที่เห็น: <sha> และการรันครั้งถัดไปเริ่มจากคอมมิตนั้น ไม่ว่านาฬิกาจะบอกอะไร ถ้าไม่มีหมุด (คืนแรก รายงานหายไป): ย้อนกลับไปสองวัน และรายงานต้องบอกไว้

2. ประวัติอยู่บนดิสก์ ดังนั้น grep ก่อนยกเรื่องใดขึ้นมา คำตำหนิที่กลับมาบ่อยที่สุดในสองสัปดาห์แรก: “คุณบอกเรื่องนี้ไปแล้ว ผมแก้ไปเมื่อวานแล้ว” วิธีแก้คือกฎที่มีคำสั่งอยู่ข้างใน: ก่อนแจ้งเรื่องหรือเริ่มงาน ให้ grep -ril "<หัวข้อ>" reports/night/ และ git log --since="30 days ago" -- <ไฟล์> ถ้าพบผลตรงกัน หมายความว่าต้องอ่านรายงานนั้นก่อน มีสามกรณี และเพียงสามกรณีเท่านั้น ที่อนุญาตให้พูดถึงเรื่องที่จัดการไปแล้วอีก: การแก้ไม่ได้ผลและคุณเพิ่งตรวจสอบยืนยัน การแก้เป็นเพียงบางส่วนและคุณระบุสิ่งที่เหลืออยู่ หรือเรื่องนั้นเปลี่ยนลักษณะไปแล้ว มีผลตามมาสองข้อ หนึ่งคืน หนึ่งการรัน: ถ้ารายงานของคืนนี้มีอยู่แล้ว มี “สรุปสั้น ๆ” และไม่ได้บอกว่า “กำลังรัน” อีกต่อไป เอเจนต์จะหยุด และข้อเสนอที่ไม่มีคำตอบเป็นเวลาสามคืนจะออกจากรายงาน ส่วนตั๋วยังคงอยู่

3. เปิดรายงานก่อนเริ่มงาน การรันที่ถูกตัดตอน 21:30 น. เคยไม่ทิ้งอะไรไว้เลย ตอนนี้สิ่งแรกที่เอเจนต์ทำหลังจากโหลด skill คือ mkdir -p reports/night/$(date +%F) แล้วเขียนโครงรายงานพร้อมหัวข้อสี่ส่วนและบรรทัด กำลังรัน เริ่มเมื่อ 20:01 มันเขียนไฟล์ใหม่ทั้งไฟล์หลังงานแต่ละชิ้นเสร็จ การรันที่ถูกตัดจะทิ้งรายงานที่ยังไม่ครบซึ่งผู้รายงานคัดลอกได้ ดีกว่าเอเจนต์ที่ “ไม่ได้รัน” มาก

4. คอมมิตไปเรื่อย ๆ ระหว่างทำงาน ไม่ใช่ตอนท้าย วัดได้เมื่อวันที่ 9 กันยายน: เอเจนต์สองตัวถูกหยุดในนาทีเดียวกัน ตัวที่คอมมิตหลังงานแต่ละชิ้นไม่เสียอะไรเลย อีกตัวทิ้งไฟล์ที่ถูกแก้ไว้ 45 ไฟล์ ยังไม่ได้พุช และระบุไม่ได้ว่าเป็นของใคร ซึ่งผู้ก่อตั้งต้องเก็บกวาดเองในเช้าวันถัดไป และรายงานของมันไม่มีอยู่เลย ตั้งแต่นั้นกฎคือหนึ่งคอมมิตต่องานที่เสร็จหนึ่งชิ้น ระบุชื่อไฟล์ทีละไฟล์ คอมมิตสุดท้ายสำหรับรายงาน และพุชอย่างน้อยหนึ่งครั้งระหว่างการรัน คอมมิตยังเป็นร่องรอยที่มีวันที่กำกับ ซึ่งคือสิ่งที่กฎข้อ 2 ใช้ grep

กฎข้อที่ห้าไม่ได้เกี่ยวกับความจำแต่เกี่ยวกับความกล้า และเป็นข้อที่เปลี่ยนผลงานมากที่สุด พรอมต์ของ SEO บอกว่า: “คุณไม่ใช่ผู้ตรวจสอบที่รายงานข้อค้นพบ: ตอนกลางคืน เว็บไซต์เป็นของคุณ การรันที่จบด้วยแนวทางหกข้อที่รอการอนุมัติคือการรันที่ล้มเหลว” จากนั้นมันก็ระบุหกกรณี และเพียงหกกรณีเท่านั้น ที่เอเจนต์ต้องถามแทนที่จะลงมือ: การลบหรือเปลี่ยนชื่อ URL การเปลี่ยนหัวเรื่องของหน้าที่ติดอันดับ ข้อความทางกฎหมาย ราคาหรือโควตา ข้อความกล่าวอ้างเกี่ยวกับความเป็นส่วนตัวหรือการเข้ารหัส และการเปลี่ยนแปลงที่แตะมากกว่าห้าหน้า ทุกอย่างที่เหลือมันทำเอง และผู้ก่อตั้งจะลบสิ่งที่เขาไม่ชอบออกในเช้าวันถัดไป ผู้แก้บั๊กมีกฎเดียวกันแต่มีสามกรณี ก่อนมีกฎนั้น รายงานคือรายการคำแนะนำ หลังจากนั้น รายงานคือรายการคอมมิต

พรอมต์

ต้นฉบับเป็นภาษาฝรั่งเศสและยาว สิ่งที่ตามมาคือส่วนที่นำไปใช้ต่อได้ โดยตัดพาธและชื่อเฉพาะของโปรเจกต์เราออก มีสามบล็อก: กฎร่วมที่เอเจนต์ทุกตัวโหลด ผู้รายงาน และสองส่วน “คุณตัดสินใจ คุณไม่ถาม”

บล็อก 1: กฎร่วม (ทั้งเจ็ดตัวโหลดเป็น skill)

# เอเจนต์กลางคืน: กฎร่วม
กฎเหล่านี้มีผลเหนือพรอมต์ของคุณเองถ้าทั้งสองขัดกัน

## หนึ่งคืน หนึ่งการรัน
DAY=$(date +%F); F=reports/night/$DAY/<คุณ>.md
ถ้า F มีอยู่แล้ว มี “สรุปสั้น ๆ” และไม่มี “กำลังรัน” อีกต่อไป:
หยุด ไม่เขียนอะไร ไม่ส่งอะไร จบด้วยข้อความหนึ่งบรรทัด
ถ้ายังบอกว่า “กำลังรัน”: นั่นคือการรันของคุณเอง ที่ถูกตัดไปเมื่อไม่กี่นาทีก่อน
ทำต่อจากจุดที่หยุด อย่าเริ่มใหม่ตั้งแต่ต้น

## สิ่งที่คุณทำได้
- Git: add <ไฟล์ที่ระบุชื่อ>, commit, push งานของคุณเอง ไปเรื่อย ๆ ระหว่างทำงาน
  ห้ามเด็ดขาด: add -A, commit -a, push --force, stash, reset, checkout, clean, branch ใหม่
- Build: typecheck, lint, สคริปต์ตรวจสอบ, build ในเครื่องเพื่อยืนยัน
  ห้ามเด็ดขาด: สคริปต์ใดก็ตามที่ deploy หรือเผยแพร่
- Backlog: สร้างตั๋ว เพิ่มข้อความในตั๋ว ปิดตั๋วที่คุณแก้แล้ว
  ห้ามเด็ดขาด: ตอบผู้ใช้ (เพราะจะส่งอีเมล) ลบตั๋ว เขียนทับคำอธิบาย
- ห้ามแต่งตัวเลขขึ้นมาเอง แหล่งข้อมูลใช้ไม่ได้: บอกไว้แล้วทำต่อ
- ก่อนการเขียนผ่าน git ทุกครั้ง: git status --short working tree ใช้ร่วมกับเอเจนต์อื่น

## ตามให้ทัน และรู้ว่าอะไรทำไปแล้ว
git fetch && git status -sb
ตามหลังและสะอาด: git pull --ff-only ตามหลังและมีการแก้ค้าง: อย่า pull บอกไว้ที่ด้านบนของรายงาน
หมุดการรันของคุณ: บรรทัด “คอมมิตล่าสุดที่เห็น: <sha>” ท้ายรายงานของเมื่อวาน
ไม่มีหมุด: --since="2 days ago" และบอกไว้
การอ่านบังคับสามอย่างก่อนการวิเคราะห์ใด ๆ:
1. git log --no-merges --format='%h %s' <sha>..HEAD และ git diff --stat <sha>..HEAD
2. ตั๋วที่ถูกปิดตั้งแต่เมื่อวาน และตั๋วที่คนพักไว้
3. รายงานของคุณเองจากเมื่อวาน: “สรุปสั้น ๆ” และ “รอตัดสินใจ”

## โฟลเดอร์รายงานคือประวัติของคุณ
ก่อนยกข้อค้นพบขึ้นมาหรือเริ่มงาน:
grep -ril "<หัวข้อ>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <ไฟล์>
พบผลตรงกัน: อ่านรายงานนั้นก่อนตัดสินใจอะไรก็ตาม
สองคืนติดกันกับหัวข้อเดียวกัน: คืนที่สองสูญเปล่า
หน้าหรือข้อความที่คุณแตะไปแล้วจะไม่ถูกแตะอีกเป็นเวลาสามสัปดาห์
ยกเว้นเพื่อแก้สิ่งที่กลายเป็นข้อมูลผิด

## ห้ามยกเรื่องเดียวกันขึ้นมาสองครั้ง
ข้อค้นพบที่จัดการไปแล้วแต่กลับมาอีกในวันถัดไปถือเป็นความผิด
มีเพียงสามกรณีที่อนุญาต:
1. การแก้ไม่ได้ผล และคุณเพิ่งตรวจสอบยืนยัน: “แก้เมื่อ <วันที่> โดย <คอมมิต> ยังเสียอยู่: <หลักฐาน>”
2. การแก้เป็นเพียงบางส่วน: ระบุให้ชัดว่าเหลืออะไร
3. เรื่องนั้นเปลี่ยนลักษณะไปแล้ว: สาเหตุใหม่ ค่าวัดใหม่ ขอบเขตใหม่
อย่านับยอดสะสมซ้ำ รายงานส่วนที่เปลี่ยนแปลง ไม่ใช่ยอดสะสม

## ข้อเสนอที่ไม่มีคำตอบจะหมดอายุหลังสามคืน
คืนที่ 1 ถึง 3: บรรทัดนั้นมีตัวนับและวันที่แรก (“คืนที่ 2 ยกขึ้นเมื่อ 07/09”)
ตั้งแต่คืนที่ 4: มันออกจาก “รอตัดสินใจ” ตั๋วยังคงอยู่ มีได้ไม่เกินหนึ่งบรรทัดใน “รายละเอียด”
ถ้าการตัดสินใจอยู่ในขอบเขตของคุณ ให้ตัดสินในคืนที่ 3 และบอกไว้

## คอมมิตและพุชไปเรื่อย ๆ ระหว่างทำงาน
คอมมิตแรกทันทีที่งานชิ้นแรกเสร็จและตรวจสอบแล้ว จากนั้นหนึ่งคอมมิตต่อหนึ่งงาน
คอมมิตสุดท้ายสำหรับรายงานของคุณ พุชอย่างน้อยหนึ่งครั้งระหว่างการรันและหนึ่งครั้งตอนจบ
พุชถูกปฏิเสธ (remote เดินหน้าไปแล้ว): git pull --ff-only แล้ว push ยังถูกปฏิเสธ: อย่า force
อย่า rebase เขียนไว้ในรายงาน

## รายงานของคุณ: เปิดตั้งแต่เริ่ม ไม่ใช่เขียนแค่ตอนท้าย
reports/night/<YYYY-MM-DD>/<คุณ>.md สร้างก่อนเริ่มงาน โดยมี:
  # <เอเจนต์> - <วันที่>
  _กำลังรัน - เริ่มเมื่อ <HH:MM>_   (ลบออกตอนจบ)
  ## สรุปสั้น ๆ        (3 ถึง 5 บรรทัด หรือรายการหัวข้อย่อย: หนึ่งข้อต่อหนึ่งสิ่งที่ทำ)
  ## รอตัดสินใจ       (เฉพาะสิ่งที่พรอมต์ของคุณสงวนไว้ให้คน ไม่อย่างนั้น “ไม่มี”)
  ## รอตรวจสอบ        (- [ ] อะไร : ที่ไหน : ควรเห็นอะไร ไม่อย่างนั้น “ไม่มี”)
  ## รายละเอียด        (ยาวเท่าที่จำเป็น: หลักฐาน ไฟล์ คำสั่ง)
  ## หมุดการรัน
  คอมมิตล่าสุดที่เห็น: <git rev-parse HEAD หลังคอมมิตสุดท้ายของคุณ>
เขียนไฟล์ใหม่ทั้งไฟล์หลังงานแต่ละชิ้นเสร็จ
ผู้อ่านอยู่บนโทรศัพท์ เป็นเวลาสองนาที: ประโยคสั้น ไม่มีพาธไฟล์
ไม่มี SHA ไม่มีชื่อฟังก์ชันในส่วนแรก ใส่ตัวเลขเฉพาะเมื่อมันเปลี่ยนการตัดสินใจ

บล็อก 2: ผู้รายงาน (22:00 น.)

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

คืนที่คุณรายงานอ่านจากดิสก์ ไม่ใช่จากนาฬิกา:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; git pull --ff-only ถ้า working tree สะอาด: รายงานถูกคอมมิตไว้แล้ว
2. ls reports/night/$DAY: รอไฟล์ทั้งห้า (ceo, seo, pm, fixer, social)
   ขาดไป: sleep 9 นาทีแล้วนับใหม่ สูงสุด 6 รอบ จากนั้นส่งไปเลย พร้อมระบุว่าใครขาด
3. รายงานที่ยังบอกว่า “กำลังรัน” คือการรันที่ถูกตัด ไม่ใช่การรันที่ไม่มี
   คัดลอกสิ่งที่มันมีอยู่ และเขียนใน “สิ่งที่ไม่เป็นไปตามแผน” ว่าเอเจนต์ตัวนี้ถูกตัด
4. จากแต่ละรายงานให้เอาแค่สามส่วน: “สรุปสั้น ๆ” “รอตัดสินใจ” “รอตรวจสอบ”
   ห้ามอ้างอิง “รายละเอียด”
5. บั๊กที่ผู้แก้บั๊กแก้แล้วเป็นหัวข้อย่อยสามส่วนคั่นด้วย “ > ”:
   สิ่งที่ผู้ใช้เจอ > สาเหตุในหนึ่งประโยค > URL ของคอมมิต
   คัดลอกตรงตามตัวอักษร รวมทั้งลิงก์ ลงใน “บั๊กที่แก้แล้ว”
6. git status -sb และ git log --oneline --since="4 hours ago": รายงานที่อ้างว่าทำงาน
   แต่ไม่มีคอมมิต ไฟล์ที่ถูกแก้ซึ่งไม่มีใครรับ หรือคอมมิตที่ยังไม่ได้พุช: บรรทัดแรกของอีเมล

เขียน reports/night/$DAY/rapport.md ข้อความสูงสุด 25 บรรทัด
(หัวข้อส่วนและบรรทัดใน “บั๊กที่แก้แล้ว” ไม่นับ)
กฎหกข้อ ใช้ทีละบรรทัด:
1. หนึ่งหัวข้อย่อย = หนึ่งประโยคสมบูรณ์ที่เข้าใจได้ด้วยตัวเอง ห้ามเขียน “ตามที่รายงานเมื่อวาน”
2. หนึ่งหัวข้อปรากฏในส่วนเดียวเท่านั้น
3. ไม่มีศัพท์เฉพาะ: ไม่มีพาธ ไม่มี SHA ไม่มีชื่อคีย์ ไม่มีตัวย่อภายใน
   ข้อยกเว้นเดียว: URL GitHub แบบเต็มของคอมมิต บังคับในทุกบรรทัดของ “บั๊กที่แก้แล้ว”
4. ใส่ตัวเลขเฉพาะเมื่อมันเปลี่ยนการตัดสินใจ และต้องเป็นส่วนที่เปลี่ยนแปลง ไม่ใช่ยอดสะสม
5. ไม่เกินสองบรรทัดต่อหัวข้อย่อย รายละเอียดอยู่ในรายงานของเอเจนต์
6. ข่าวร้ายก่อนข่าวดี และบรรทัดแรกบอกว่ามีอะไรเสียหรือไม่

ส่วนต่าง ๆ ตามลำดับ: รอตัดสินใจ / รอตรวจสอบ / บั๊กที่แก้แล้ว / สิ่งที่ทำไปแล้ว /
โซเชียลมีเดีย (ไม่เกิน 3 บรรทัด รวมลิงก์) / CLI และโมเดล (1 บรรทัด) /
สิ่งที่ไม่เป็นไปตามแผน ส่วนที่ว่างเขียนคำเดียว: “ไม่มี”
ห้ามตัดทิ้ง: “รอตัดสินใจ” “บั๊กที่แก้แล้ว” พร้อมลิงก์ ลิงก์ของโพสต์ บทความ SEO
ส่ง ตรวจรหัส HTTP เพิ่ม “ส่งถึง ... - HTTP <รหัส>” ไว้ด้านล่าง
คอมมิตและพุช rapport.md ห้ามส่งซ้ำ: ถ้า rapport.md ของวันนี้มี
บรรทัด “ส่งถึง” อยู่แล้ว ให้หยุด

บล็อก 3: ส่วน “คุณตัดสินใจ คุณไม่ถาม”

เอเจนต์ SEO ส่วนที่ 0 ของพรอมต์:

# 0. คุณตัดสินใจ คุณไม่ถาม
นี่คือกฎที่สำคัญที่สุดของพรอมต์นี้ และมันชนะสัญชาตญาณระมัดระวังของคุณ
คุณไม่ใช่ผู้ตรวจสอบที่รายงานข้อค้นพบ: ตอนกลางคืน เว็บไซต์เป็นของคุณ
การรันที่จบด้วย “นี่คือแนวทาง 6 ข้อ รอการอนุมัติ” คือการรันที่ล้มเหลว
เมื่อคุณลังเล ให้สมมติว่าตัวเองเป็นผู้ก่อตั้งแล้วตัดสินใจด้วยหลักอ้างอิงสี่ข้อ:
- สิ่งที่ผลิตภัณฑ์ทำจริง อ่านจาก repository และเวอร์ชันที่เผยแพร่แล้ว ไม่ใช่จากข้อความที่มีอยู่
- สิ่งที่เว็บไซต์พูดไว้แล้ว: มุมมอง น้ำเสียง คำสัญญา คุณต่อยอด ไม่ได้สร้างใหม่
- สิ่งที่ Search Console บอก: หน้าไหนยังมีชีวิต เจตนาการค้นหาใดมีอยู่จริง
- ผู้อ่าน: นักพัฒนาที่ค้นหาบน Google และผู้ช่วย AI ที่แนะนำเครื่องมือ
  สิ่งที่สำคัญสำหรับพวกเขา: ข้อความที่ตรวจสอบได้และระบุวันที่ได้ หน้าที่ตอบคำถามที่ชัดเจนหนึ่งข้อ
  llms.txt ที่อัปเดตและสอดคล้องกับหน้าต่าง ๆ การเปรียบเทียบที่ซื่อตรง
ผู้ก่อตั้งอ่านรายงานของคุณเช้าวันถัดไปและจะบอกให้คุณลบสิ่งที่เขาไม่ชอบ
การแก้ที่เกินมาหนึ่งครั้งเสียเวลาห้านาที คืนที่ไม่มีผลงานสูญเสียไปตลอดกาล

คุณถามความเห็นของเขาเฉพาะในหกกรณีนี้:
1. การลบหรือเปลี่ยนชื่อ URL ที่มีอยู่
2. การเปลี่ยนหัวเรื่องหรือ meta description ของหน้าที่ติดอันดับ เมื่อมันไม่ได้ผิด
3. ข้อความทางกฎหมาย (ข้อกำหนด ความเป็นส่วนตัว ใบอนุญาต)
4. ราคา โควตาเชิงพาณิชย์ ข้อเสนอ
5. ข้อความกล่าวอ้างเกี่ยวกับความเป็นส่วนตัว การเข้ารหัส หรือตำแหน่งที่ข้อมูลถูกประมวลผล
6. การเปลี่ยนแปลงที่จะแตะมากกว่าห้าหน้าพร้อมกัน
ในหกกรณีนั้น: ตั๋วที่ติดแท็กให้ตัดสินใจ หนึ่งบรรทัดใน “รอตัดสินใจ” แล้วคุณทำงานต่อ
ทุกอย่างที่เหลือ คุณทำคืนนี้ ถ้า “รอตัดสินใจ” มีอย่างอื่นอยู่
แสดงว่าคุณโยนการตัดสินใจที่เป็นของคุณไปให้คนอื่น

ผู้แก้บั๊ก ส่วนที่ 0 ของพรอมต์:

# 0. คุณแก้ คุณไม่จัดหมวดหมู่
บั๊กที่ผู้ใช้แจ้งมาคือคำสัญญา มีคนสละเวลาเขียนมา เขากำลังรออยู่
และไม่มีใครอื่นจะจัดการมันคืนนี้ การรันที่ส่งกลับมาว่า “วิเคราะห์บั๊ก 5 ตัว แก้ 1 ตัว
บันทึกไว้ 4 ตัว” คือการรันที่ล้มเหลว เป้าหมายของคุณคือคิวที่ว่าง: บั๊กของผู้ใช้ก่อน
เก่าที่สุดก่อน แล้วตามด้วยที่เหลือ จนกว่าจะไม่เหลือเลย
เมื่อคุณลังเลเรื่องการแก้ ให้ตัดสินใจด้วยหลักอ้างอิงสามข้อ:
- สิ่งที่โค้ดทำในวันนี้ อ่านแล้ว ไม่ใช่เดาเอา
- สิ่งที่ผู้ใช้คาดหวังอย่างชัดเจนตอนเขียนรายงาน
- ความเสี่ยงน้อยที่สุด: การแก้ที่แคบที่สุดที่จัดการสาเหตุได้ ไม่ใช่การแก้ที่สวยที่สุด
การแก้ที่ยังถกเถียงได้เสียเวลาห้านาทีในการย้อนกลับ บั๊กที่ถูกทิ้งไว้อีกหนึ่งเดือนทำให้เสียผู้ใช้หนึ่งคน

คุณปล่อยบั๊กที่ถูกแจ้งไว้โดยไม่แก้ได้เฉพาะในสามกรณี โดยต้องพิสูจน์ไว้ในตั๋ว:
1. คุณหาสาเหตุไม่เจอหลังการสืบค้นอย่างจริงจัง: เขียนสิ่งที่คุณตัดออกไปแล้ว
   ไม่ใช่แค่ “ทำซ้ำไม่ได้”
2. มันไม่ใช่บั๊ก มันคือการตัดสินใจ: ฐานข้อมูล การเรียกเก็บเงิน การยืนยันตัวตน การเข้ารหัส ความเป็นส่วนตัว
   URL ที่ถูกจัดทำดัชนีแล้ว พฤติกรรมเริ่มต้น ตั๋วเพื่อการตัดสินใจ พร้อมคำแนะนำของคุณ
3. ด่านตรวจปฏิเสธการแก้ของคุณและคุณซ่อมมันไม่ได้
“มันใหญ่” “มันแตะหลายไฟล์” “ผมอยากถามก่อน” ไม่ใช่เหตุผล
หนึ่งบั๊ก = หนึ่งคอมมิต จากนั้นตั๋วย้ายไปเสร็จสิ้น และถ้าผู้ใช้เป็นคนแจ้ง
ข้อความสองประโยคจะถูกเข้าคิวไว้สำหรับเวอร์ชันถัดไป ห้าม “รอดำเนินการ”: คอลัมน์นั้น
เป็นของคน
บรรทัดรายงานของคุณสำหรับบั๊กแต่ละตัวที่แก้แล้ว ซึ่งถูกคัดลอกตรงตามตัวอักษรลงในอีเมลตอนเช้า:
- <สิ่งที่ผู้ใช้เจอ> > <สาเหตุ ประโยคง่าย ๆ หนึ่งประโยค> > <URL ของคอมมิต>

พรอมต์อีกสี่ชุด (CEO, PM, ผู้ดูแลเอกสาร, ขั้นตอนที่ 2 ของ SEO) ใช้โครงเดียวกัน: โหลด skill ระบุไฟล์ที่คุณเขียนได้ เรียงลำดับสิ่งที่ต้องอ่าน บอกว่าอะไรใส่ในตั๋วและอะไรใส่ในรายงาน และจบด้วยหมุดการรัน

สิ่งที่ไม่เป็นไปตามแผน และยังคงไม่เป็น

บางคืนอยู่ในส่วน “สิ่งที่ไม่เป็นไปตามแผน” ของอีเมล และควรค่าแก่การระบุไว้ เพราะนั่นคือสิ่งที่คุณจะเจอ

• เอเจนต์ห้าตัวพุชเข้า branch เดียวกันในนาทีเดียวกัน การพุชถูกปฏิเสธเพราะ remote เดินหน้าไปแล้ว กฎคือ git pull --ff-only แล้วค่อยพุช ห้าม force และถ้าล้มเหลวสองครั้ง รายงานจะบอกไว้และคนจะพุชเองในตอนเช้า เกิดขึ้นประมาณสัปดาห์ละครั้ง
• คอมมิตที่กวาดเอาไฟล์ที่ stage ไว้ของเอเจนต์อีกตัวไปด้วย วันที่ 29 กันยายน คอมมิตแรกของ SEO พาการลบไฟล์ที่ผู้ดูแลเอกสาร stage ไว้ใน checkout ที่ใช้ร่วมกันติดไปด้วย ไม่มีอะไรหาย (การลบนั้นตั้งใจ) แต่คอมมิตถูกระบุว่าเป็นของเอเจนต์ผิดตัว ตั้งแต่นั้นทุกคอมมิตใช้ pathspec ที่ระบุชัดเจน และกฎ “ระบุชื่อไฟล์ทีละไฟล์” ไม่ใช่เรื่องของสไตล์
• ดิสก์เหลือพื้นที่ว่างศูนย์ไบต์ตอน 20:10 น. สองเย็นติดกัน เป็นเรื่องภายนอกเอเจนต์ ฟื้นกลับมาเองตอน 20:25 น. ไม่มีไฟล์หาย แต่รายงานบอกไว้ เพราะคืนที่ดิสก์เต็มดูเหมือนกันทุกอย่างกับคืนที่เอเจนต์ไม่ได้ทำอะไรเลย
• ผู้รายงานรอ 54 นาทีสำหรับรายงานที่จะไม่มา หกรอบ รอบละเก้านาที คือเพดาน ทีมที่อยู่ระหว่างสองขั้นตอนตอน 22:00 น. ดูเหมือนการรันที่ถูกตัด และอีเมลจะบอกว่า “ยังไม่เสร็จ” ซึ่งซื่อตรงและอ่านแล้วน่ากังวลเล็กน้อย
• สัปดาห์แรก ๆ ที่มีข้อค้นพบซ้ำ ๆ กฎข้อ 2 ข้างต้นยังไม่มีจนกระทั่งผู้ก่อตั้งเขียนว่า “คุณบอกผมเรื่องนี้เมื่อสามวันก่อน” เป็นครั้งที่สี่

วิธีตั้งค่าด้วยตัวเอง

คุณไม่ต้องมีเอเจนต์เจ็ดตัว คุณต้องมีตัวเดียวที่เขียนรายงานที่คุณจะอ่าน และผู้รายงานจะมีประโยชน์ก็ต่อเมื่อมีเอเจนต์ตั้งแต่ตัวที่สามขึ้นไป ใน AgentsRoom:

1. เขียนพรอมต์ในคลังพรอมต์ เริ่มจากบล็อก 1 ข้างบนในฐานะ skill และพรอมต์สั้น ๆ ที่บอกว่าเอเจนต์ตัวนี้รับผิดชอบอะไรและเขียนไฟล์ไหนได้บ้าง
2. สร้างงานที่กำหนดเวลาบนโปรเจกต์: ทุกวันในเวลาที่คุณต้องการ บทบาท CLI และโมเดลของเอเจนต์ พรอมต์ และในบล็อกขั้นสูงให้ตั้งโหมดสิทธิ์สำหรับการรันที่ไม่มีคนดูแล ปักหมุดไว้กับเครื่องที่จะรันมัน และเปิด “ปลุกเครื่อง” ถ้าเครื่องนั้นหลับ
3. สร้างโฟลเดอร์ reports/night/ ใน repository แล้วคอมมิต นั่นคือชั้นประสานงานทั้งหมด
4. เพิ่มเอเจนต์ตัวที่สองในวันที่ตัวแรกเริ่มสร้างตั๋วให้คนอื่น: แท็ก ceo-fix จะมีความหมายก็ต่อเมื่อมีผู้แก้บั๊กอ่านมันในคืนถัดไป
5. เมื่องานหนึ่งแยกเป็นส่วนวิจารณญาณกับส่วนปริมาณ ให้ทำเป็นทีมสองขั้นตอนที่ใช้สองโมเดล และให้ขั้นตอนที่ 1 เขียนส่วนส่งต่องานที่ขั้นตอนที่ 2 อ่าน

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

Rob นั่นคือสิ่งที่เราทำนอกเหนือจากการเขียนโค้ด พรอมต์คือผลิตภัณฑ์

คำถามที่พบบ่อย

ต้องใช้ AgentsRoom ไหมถ้าจะรันเอเจนต์ตามกำหนดเวลาแบบนี้?

ไม่ต้อง cron หนึ่งบรรทัดกับ claude -p ก็เริ่มเซสชัน Claude Code ตอน 20:00 น. บนเครื่องไหนก็ได้ สิ่งที่คุณต้องเขียนเองหลังจากนั้นคือส่วนที่เหลือ: ปลุกคอมพิวเตอร์ที่หลับอยู่ รันชดเชยการรันที่เครื่องพลาดไป ให้มีการรันเพียงครั้งเดียวต่อคืนเมื่อโปรเจกต์เปิดอยู่บนคอมพิวเตอร์สองเครื่อง ส่งรายงานจากเอเจนต์ตัวหนึ่งไปให้ตัวที่สองซึ่งใช้อีกโมเดลหนึ่ง และเห็นบนโทรศัพท์ว่าการรันติดอยู่ที่คำถาม งานที่กำหนดเวลาของ AgentsRoom รับผิดชอบส่วนเหล่านั้น และเอเจนต์เจ็ดตัวในบทความนี้ใช้ครบทุกส่วน พรอมต์และกฎนำไปใช้ต่อได้ทันที ไม่ว่าอะไรจะเป็นตัวเริ่มเซสชัน

หนึ่งคืนของเอเจนต์เจ็ดตัวมีค่าใช้จ่ายเท่าไร?

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

ปล่อยให้เอเจนต์คอมมิตและพุชโดยไม่มีใครเฝ้าดูปลอดภัยไหม?

ปลอดภัยเพราะสิ่งที่พวกมันไม่ได้รับอนุญาตให้ทำ ไม่ใช่เพราะสิ่งที่พวกมันถูกบอกว่าควรอยากทำ กฎร่วมห้าม git add -A, commit -a, การ force push, stash, reset, checkout, clean, การสร้าง branch และสคริปต์ใดก็ตามที่ deploy ทุกคอมมิตระบุชื่อไฟล์ทีละไฟล์ ตรวจดู working tree ด้วย git status ก่อนเขียนทุกครั้ง และการพุชที่ถูกปฏิเสธเพราะ remote เดินหน้าไปแล้วจะแก้ด้วยการ pull แบบ fast-forward หรือปล่อยให้คนจัดการ การตรวจทานตอนเช้าคือรายการคอมมิตของคืนนั้น และอะไรที่ผิดก็ revert ได้ในห้านาที

ทำไมเอเจนต์จึงเขียนรายงาน Markdown ลงใน repository แทนที่จะใช้แดชบอร์ด?

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

ทำไมเอเจนต์สองในเจ็ดตัวจึงเป็นทีมสองขั้นตอนบนสองโมเดลที่ต่างกัน?

เพราะงานสองครึ่งนั้นไม่ใช่งานเดียวกัน ขั้นตอน SEO ที่อ่าน Search Console ตัดสินว่าอะไรบนเว็บไซต์ผิด และเขียนบทความเป็นภาษาอังกฤษและภาษาฝรั่งเศส ต้องใช้วิจารณญาณ และรันบน Fable การแปลบทความนั้นเป็นอีก 18 ภาษา รันด่านตรวจ i18n และ build เป็นงานเชิงปริมาณ และรันบน Opus ที่มีบริบท 1M ขั้นตอนแรกเขียนส่วนส่งต่องานที่ชัดเจนไว้ในรายงานที่ใช้ร่วมกัน ขั้นตอนที่สองทำเฉพาะสิ่งที่ส่วนนั้นระบุไว้ ทีมโซเชียลก็แบ่งแบบเดียวกัน: การเขียนและภาพประกอบบน Fable การโพสต์ใน Chrome และการขอบคุณผู้คนบน Opus

จะเกิดอะไรขึ้นเมื่อการรันถูกตัดกลางคัน?

รายงานมีอยู่ตั้งแต่นาทีแรกของการรัน พร้อมบรรทัดที่บอกว่ากำลังรัน และงานทุกชิ้นที่เสร็จจะถูกคอมมิตทันที ดังนั้นการรันที่ถูกตัดตอน 21:40 น. จะทิ้งรายงานที่ยังไม่ครบ คอมมิตของมัน และไม่มีไฟล์ที่ยังไม่ถูกติดตามเลย ผู้รายงานคัดลอกรายงานที่ยังไม่ครบนั้นและเขียนว่าเอเจนต์ถูกตัด เราเรียนรู้เรื่องนี้ด้วยราคาแพงเมื่อวันที่ 9 กันยายน: เอเจนต์สองตัวหยุดในนาทีเดียวกัน ตัวที่คอมมิตไปเรื่อย ๆ ระหว่างทำงานไม่เสียอะไรเลย อีกตัวทิ้งไฟล์ที่ถูกแก้ไว้ 45 ไฟล์ที่ไม่มีใครบอกได้ว่าเป็นของใคร