วิศวกรรมลูปที่ Three Agents: สิ่งที่เวิร์กโฟลว์ Magpie ของ yetone บอกเกี่ยวกับการรัน Claude Opus 5.5 โดยไม่มีผู้ดูแล

สิ่งที่น่าสนใจที่สุดเกี่ยวกับการตั้งค่าของ yetone ไม่ใช่ตัวโมเดล แต่คือเลขสาม ผู้ดูแล Magpie — เกตเวย์แบบโลคอลที่ให้เอเจนต์เขียนโค้ดรันกับโมเดลอะไรก็ได้ที่คุณชี้ไป — ได้เล่าเวิร์กโฟลว์การดูแลของตัวเองบน X เมื่อวันที่ 2026-10-13 ว่า Claude Code ซึ่งขับเคลื่อนด้วย Claude Opus 5.5ของ Anthropic โดยมีงาน /loopสามงานรันพร้อมกัน แต่ละงานคอยเฝ้าดูคนละด้าน — issue และ pull request บน GitHub ชุมชน Discord และฟีดแบ็กที่เข้ามาทาง X — แล้วแก้ไขสิ่งที่พบเจอ วิศวกรรมลูป (loop engineering) ซึ่งคือแนวปฏิบัติในการปล่อยให้เอเจนต์วนทำงานซ้ำแทนที่จะพรอมป์ทีละเทิร์น ถูกพูดถึงกันมากในปีนี้ สิ่งที่ทำให้ตัวอย่างนี้น่าอ่านคือมันมาพร้อมกับผังองค์กร

Claude Opus 5.5 ไม่ใช่ของใหม่ A​nthropic ปล่อยมันเมื่อวันที่ 22 กันยายน 2026 เมื่อสามสัปดาห์ก่อน ในราคา 4 ดอลลาร์ต่ออินพุต 1 ล้านโทเค็น และ 20 ดอลลาร์ต่อเอาต์พุต 1 ล้านโทเค็น นี่ไม่ใช่เรื่องราวการเปิดตัว มันเป็นเรื่องราวเกี่ยวกับว่าค่าเริ่มต้นของโมเดลบอกเป็นนัยอะไรสำหรับใครก็ตามที่พยายามคัดลอกลูปการบำรุงรักษาแบบสามเอเจนต์ และเกี่ยวกับว่าส่วนไหนของลูปนั้นที่พังในลักษณะที่บทเรียนไม่ได้กล่าวถึง

จริง ๆ แล้วมีอะไรอยู่ในเวิร์กโฟลว์

สัญญาณนี้สั้น ดังนั้นจึงคุ้มค่าที่จะระบุให้ชัดเจนว่าอะไรคือสิ่งที่ถูกกล่าวอ้างและอะไรไม่ใช่ yetone รันสามงานพร้อมกัน/loopใน Claude Code บน Opus 5.5 ตัวหนึ่งเฝ้าดูรีโพซิทอรี — issues และ pull requests ตัวหนึ่งเฝ้าดู Discord ตัวหนึ่งเฝ้าดู X เอเจนต์แก้ไขสิ่งที่มันตัดสินว่าคุ้มค่าแก่การแก้ไข ในลูป โดยไม่มีมนุษย์คอยสั่งการในแต่ละรอบ รูปแบบที่เขาทำให้เป็นอัตโนมัติคือสิ่งที่ผู้ดูแลส่วนใหญ่ทำได้แย่ นั่นคือการคัดกรอง ไม่ใช่การเขียนโค้ด แต่คือการอ่าน การจัดเรียง การตัดรายการซ้ำ และการตอบ ที่กินเวลาวันละหนึ่งชั่วโมง

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

สิ่งที่/loopทำจริง ๆ ในเดือนตุลาคม 2026

ถ้าคุณยังไม่ได้อ่านเอกสารฉบับปัจจุบัน เวอร์ชันที่คุณจำได้น่าจะผิด เพราะ/loopเปลี่ยนรูปแบบไปแล้วในขณะที่วิศวกรรมลูปกำลังเป็นที่นิยม

คำสั่ง /loop แบบเปล่าไม่ต้องการให้คุณระบุช่วงเวลาอีกต่อไป หากไม่ระบุ Claude จะเลือกช่วงเวลาแบบไดนามิก — ระหว่างหนึ่งนาทีถึงหนึ่งชั่วโมง — โดยอิงจากสิ่งที่สังเกตเห็นในรอบก่อนหน้า มันจะรอสั้น ๆ ในขณะที่การ build กำลังเสร็จสิ้นหรือมี pull request ที่ทำงานอยู่ และจะรอนานขึ้นมากเมื่อไม่มีอะไรค้างอยู่ ความล่าช้าที่เลือกและเหตุผลจะถูกพิมพ์ไว้ตอนท้ายของแต่ละรอบ ดังนั้นคุณจึงเห็นการให้เหตุผลของ loop เองเกี่ยวกับจังหวะของมันได้ ให้ระบุช่วงเวลาแทน — /loop 5m check the deploy — แล้วคุณจะได้ตาราง cron แบบคงที่

ละเว้นพรอมป์ตนั้นด้วย แล้วคุณจะได้พรอมป์ตการบำรุงรักษาในตัวที่ไล่จัดการสามสิ่งตามลำดับในทุก ๆ การทำซ้ำ:

• ทำงานที่ยังไม่เสร็จจากการสนทนาต่อ

• ดูแล pull request ของสาขาปัจจุบัน — ความคิดเห็นจากการรีวิว, การรัน CI ที่ล้มเหลว, ความขัดแย้งในการ merge

• รันการทำความสะอาด เช่น การล่าบั๊กหรือการลดความซับซ้อนเมื่อไม่มีงานอื่นค้างอยู่

คุณสามารถแทนที่ค่าเริ่มต้นนั้นด้วยคำสั่งของคุณเองได้โดยการเขียน loop.md — ไว้ที่ .claude/loop.md สำหรับโปรเจกต์ หรือ ~/.claude/loop.md สำหรับทุกโปรเจกต์ที่ไม่ได้กำหนดไฟล์ของตัวเอง การแก้ไขจะมีผลในรอบถัดไป ดังนั้นคุณจึงปรับปรุงคำสั่งของลูปที่กำลังทำงานอยู่ได้โดยไม่ต้องเริ่มใหม่ ไฟล์จะถูกตัดทิ้งเมื่อเกิน 25,000 ไบต์ ซึ่งมีพื้นที่เหลือเฟือสำหรับกฎการคัดกรอง

กลไกนั้นเป็นส่วนที่รับน้ำหนักของโครงสร้างสามลูป และเป็นส่วนที่แผนภาพเวิร์กโฟลว์มักละไว้ พรอมต์การบำรุงรักษาในตัวแบบทั่วไปไม่ใช่นโยบายการคัดแยก หากคุณต้องการลูปที่อ่าน GitHub issues แบบเดียวกับที่โปรเจกต์ของคุณอ่าน GitHub issues — อะไรนับเป็นรายการซ้ำ อะไรได้ป้ายกำกับแทนการตอบกลับ อะไรที่ไม่มีการตอบกลับเลย — นโยบายนั้นต้องอยู่ใน loop.md ไม่ใช่ในพรอมต์ที่คุณพิมพ์ตอนเริ่มเซสชัน

ขีดจำกัดที่ตัดสินว่าสามเป็นตัวเลขหรือเป็นคำขวัญ

สามลูปที่ทำงานพร้อมกันคือจุดที่ข้อจำกัดเริ่มกัดกิน และคุ้มค่าที่จะแจกแจงไว้ก่อนที่คุณจะคัดลอกการตั้งค่าของใครสักคน

• เพดานการทำงานพร้อมกัน — เซสชันหนึ่งรองรับงานที่ตั้งเวลาไว้ได้สูงสุด 50 งานในเวลาเดียวกัน ดังนั้นสามลูปจึงยังไม่ใกล้ขีดจำกัดเลย ข้อจำกัดที่แท้จริงไม่ใช่จำนวนงาน แต่คือความสนใจ: สามลูปหมายถึงการเรียกเครื่องมือสามสายที่แย่งชิงเซสชันเดียวกัน

• การหมดอายุ — งานที่ทำซ้ำจะลบตัวเองภายในเจ็ดวันหลังการสร้าง โดยจะทำงานอีกครั้งหนึ่งก่อนจะหายไป ลูปการบำรุงรักษาที่หยุดลงเงียบ ๆ ในวันที่แปดคือรูปแบบความล้มเหลวที่พบบ่อยที่สุด และมันล้มเหลวอย่างไม่มีสัญญาณใด ๆ

• คืนค่าความไม่สมมาตร — กลับเข้าสู่เซสชันด้วย --resume หรือ --continue แล้วงานที่ตั้งเวลาไว้ด้วย cron จะกลับมา ยกเว้นงานที่เกิดซ้ำซึ่งหมดอายุไปแล้ว ลูปแบบกำหนดจังหวะเองจะไม่ถูกคืนค่าเลย คุณต้องเริ่มมันใหม่

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

• Jitter — งานที่เกิดซ้ำจะจงใจให้เริ่มล่าช้า โดยล่าช้าได้ไม่เกินครึ่งหนึ่งของช่วงห่างถึงรอบถัดไป และไม่เกิน 30 นาที เพื่อให้เซสชันจำนวนมากไม่มาบรรจบกันที่วินาทีเดียวกัน งานที่ทำทุกสิบนาทีอาจเริ่มได้ตั้งแต่ตรงเวลาไปจนถึงสายห้านาที กรณีห้านาทีเป็นข้อยกเว้น: Claude Code จะเลื่อนให้เร็วขึ้น 15 วินาที เพื่อให้แต่ละรอบอยู่ภายในหน้าต่าง prompt-cache

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

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

ทำไมเวิร์กโฟลว์นี้จึงจำเพาะกับ Claude Opus 5.5 และไม่ใช่แค่ "เอเจนต์" ทั่วไป

รันลูปแบบสามเอเจนต์กับโมเดลที่ไม่มีหน้าต่างบริบทขนาดใหญ่ แล้วลูปก็จะใช้เวลาทั้งวันไปกับการอ่านซ้ำ แต่ละรอบจะนำเธรดปัญหา, PR diff และประวัติ Discord กลับมาประมวลผลใหม่; ถ้าหน้าต่างมีขนาดเล็ก ประวัตินั้นจะถูกสรุปจนหายไป และการตัดสินใจของลูปจะเสื่อมลงอย่างเงียบ ๆ เมื่อเซสชันมีอายุมากขึ้น Claude Opus 5.5 มีหน้าต่างบริบทขนาด 1M โทเคน พร้อมเอาต์พุต 128K โทเคน ซึ่งเป็นสิ่งที่ทำให้ลูปคัดแยกสามารถถือ backlog ของปัญหาจริง บวกกับบทสนทนา บวกกับรอบล่าสุดไม่กี่รอบในเวลาเดียวกัน นอกจากนี้ยังมีราคาที่ $4 / $20 ต่อล้านโทเคน และการอ่านแคชของมันอยู่ที่ $0.20 ต่อล้าน — คิดเป็นหนึ่งในห้าของราคาอินพุต — ซึ่งสำคัญกว่าปกติในที่นี้ เพราะลูปเป็นเวิร์กโหลดที่เป็นมิตรกับแคชมากที่สุดเท่าที่มี พรอมต์ระบบเดียวกัน นิยามเครื่องมือเดียวกัน บริบทของ repo เดียวกัน ซ้ำแล้วซ้ำอีก

ความพอดีอย่างที่สองคือค่าตั้งต้นของการคิด และมันให้ผลตรงกันข้ามขึ้นอยู่กับว่าแต่ละลูปกำลังทำอะไรอยู่ Claude Opus 5.5 ทำงานโดยเปิด adaptive thinking ตลอดเวลา โดยมีค่า effort เริ่มต้นที่ ปานกลาง — ต่ำกว่าค่าเริ่มต้นของ Claude Opus 5 อยู่หนึ่งระดับ effort ไม่ได้เปลี่ยนแค่คุณภาพ แต่ยังเปลี่ยนปริมาณการเรียกใช้เครื่องมือด้วย ลูปที่คัดแยกปัญหากับลูปที่แก้ไขโค้ดต้องการการตั้งค่าที่ต่างกัน และการตั้งค่า effort ต่ำสุดก็มีปัญหาการจัดตารางเวลาเป็นของตัวเองเช่นกัน: ในลูปที่กำหนดจังหวะเอง โมเดลจะเลือกเวลาปลุกครั้งถัดไปด้วยตัวเอง ดังนั้นลูปคัดแยกที่ใช้ effort ต่ำกับลูปแก้ไขที่ใช้ effort สูงจะกำหนดจังหวะของตัวเองต่างกันเมื่อเจอรีโพซิทอรีเดียวกัน ไม่มีการตั้งค่าใดที่ทำให้ทั้งคู่สอดคล้องกัน ประเด็นคือต้องรู้ว่าอันไหนเป็นอันไหน เพราะความต่างของจังหวะคือสิ่งที่คุณจะเห็นก่อนเป็นอันดับแรก

ถ้าคุณอยากให้ลูปและ fixer รันกับโมเดลของเจ้าของต่าง ๆ — triage ด้วยอะไรที่ราคาถูก ส่วนงานแก้ไขใช้ Claude Opus 5.5 — นั่นคือการตัดสินใจเรื่อง routing ไม่ใช่เรื่องของ Claude Code และนี่แหละคือเหตุผลที่ต้องมี gateway คั่นหน้า session

ลองทำแบบนี้โดยไม่เอาระบบโปรดักชันมาเดิมพัน

ข้อโต้แย้งที่สมเหตุสมผลต่อการตั้งค่าแบบสามลูปก็คือ มันเอาเอเจนต์อัตโนมัติไปไว้ตรงหน้า issue ของผู้ใช้ของคุณตั้งแต่บ่ายวันแรก ลูปจะคอมเมนต์ มันจะปิดบางสิ่ง วิธีที่ซื่อตรงในการนำมาใช้คือรันหนึ่งลูปในโหมด dry-run เป็นเวลาหนึ่งสัปดาห์กับโทเคน GitHub แบบอ่านอย่างเดียว แล้วดูว่าการตัดสินใจคัดแยกของมันตรงกับที่คุณทำด้วยมือหรือไม่ — และแยกกันไปส่งตัวโมเดลเองไปยังที่ที่คุณวัดมันได้ก่อนที่คุณจะตัดสินใจใช้

บน OrcaRouteranthropic/claude-opus-5.5ให้บริการในราคาตามที่ Anthropic ประกาศไว้ โดยไม่บวกเพิ่มใด ๆ จากปลายทางเดียวที่รองรับทั้งรูปแบบที่เข้ากันได้กับ OpenAI และรูปแบบ Anthropic Messages — ดังนั้นเซสชัน Claude Code กับสคริปต์ที่คุยกับโมเดลเดียวกันจึงไม่จำเป็นต้องมีสองการเชื่อมต่อ Anthropic ประกาศราคาของตนเองที่ 4 ดอลลาร์ / 20 ดอลลาร์ เมื่อวันที่ 22 กันยายน 2026 หากราคาประกาศนั้นเปลี่ยนแปลง เกตเวย์แบบส่งผ่านก็จะเปลี่ยนตามในวันเดียวกัน ไม่ใช่รอไปถึงรอบบิลถัดไป ซึ่งเป็นแบบที่คุณต้องการเมื่อคุณกำลังประเมินขนาดของลูปที่อาจทำงานต่อเนื่องเป็นเวลาหลายเดือน การสลับผู้ให้บริการโดยอัตโนมัติ (automatic failover) ครอบคลุมกรณีที่เอกสารเตือนไว้แต่ไม่มีใครทดสอบ นั่นคือ ลูปจะไม่หยุดทำงานเพียงเพราะผู้ให้บริการต้นทางรายหนึ่งตอบกลับ 429 ตอนตีสาม การรวมโมเดลและ DSL สำหรับกำหนดเส้นทางมีความสำคัญน้อยลงในกรณีนี้ — ลูปสำหรับคัดแยกต้องการโมเดลเดียวอย่างสม่ำเสมอ เพราะความสม่ำเสมอคือสิ่งที่ทำให้การตัดสินของมันตรวจสอบย้อนหลังได้

จะทำอะไรกับเลขสาม

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

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

พูดกันตรง ๆ ก็ต้องบอกว่า นี่คือการตั้งค่าของผู้ใช้งานจริงคนหนึ่ง ซึ่งเจ้าตัวอธิบายไว้บน X ไม่ใช่แนวทางที่ผู้ขายแนะนำ เอกสารของ Anthropic สำหรับ Claude Opus 5.5 และ /loopของ Claude Code จะบอกคุณว่าเครื่องมือเหล่านี้ทำอะไรได้ แต่ไม่ได้บอกว่าสามคือจำนวนที่เหมาะสม และตอนนี้ก็ยังไม่มีใครบอกเช่นกัน

เมื่อลูปคัดกรองและลูปแก้ไขต้องการโมเดลคนละตัว: รันทั้งลูปและตัวแก้ไขผ่านเอนด์พอยต์เดียว ให้บริการ Claude Opus 5.5 ในราคาตามที่ A​nthropic กำหนด จากเอนด์พอยต์เดียวที่รองรับทั้งรูปแบบที่เข้ากันได้กับ OpenAI และรูปแบบ A​nthropic Messages

การเลือกโมเดลแบบนี้ก็เป็นจุดที่โหมดความล้มเหลวปรากฏขึ้นเช่นกัน: เหตุการณ์ AI และความล้มเหลวของเอเจนต์ที่ได้รับการบันทึกไว้ซึ่งอยู่เบื้องหลังโมเดลในคลาสนี้ถูกรวบรวมไว้ใน the OrcaRouter AI Incident Archive โดยแต่ละรายการมีแหล่งที่มา ระดับความรุนแรง เกรดความเชื่อมั่น และแฟล็กข้อโต้แย้งของตัวเอง