วงจรเอเจนต์ AI: วิธีที่เอเจนต์การเขียนโค้ดที่แก้ไขตัวเองเสร็จสิ้นงาน

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

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

การเปลี่ยนแปลงนั้นไม่ใช่แค่การพูดเกินจริง คนที่สร้างเครื่องมือเหล่านี้พึ่งพามัน Boris Cherny และ Cat Wu, ผู้สร้าง Claude Code, พูดถึงการเขียนโค้ดในลูปของเอเจนต์ Geoffrey Huntley, ผู้ตั้งชื่อ "Ralph loop", รันเอเจนต์ในลูป while ธรรมดาตลอดคืน รูปแบบนี้มีชื่อแล้ว และมันคุ้มค่าที่จะเข้าใจก่อนที่คุณจะคัดลอกสามคำสั่งจาก Instagram

จากการเล่นปิงปองคำสั่งสู่ลูป

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

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

การเล่นปิงปองคำสั่งทำให้คุณอยู่ในลูปในทุกเทิร์น ลูปจริงทำให้เอเจนต์อยู่ในนั้น

ลูปของเอไอเอเจนต์คืออะไรจริงๆ

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

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

ลูปสามคำสั่งที่คุณสามารถคัดลอกได้วันนี้

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

ผู้วางแผน, /spec:

สัมภาษณ์ฉันทีละคำถามจนกว่าคุณจะเข้าใจสิ่งที่ฉันต้องการอย่างเต็มที่
จากนั้นเขียนแผนที่ชัดเจนไปยัง specs/project.md: วัตถุประสงค์, ข้อกำหนดที่แน่นอน,
กรณีขอบเขต, และสิ่งที่อยู่ในขอบเขตกับนอกขอบเขต
ทำให้มันสั้นและเฉียบคม, ไม่ใช่นิยาย

ผู้สร้าง, /build:

อ่าน specs/project.md และสร้างสิ่งที่มันอธิบายอย่างแม่นยำ, ไม่มีอะไรเพิ่มเติม
เมื่อคุณเสร็จสิ้น, ระบุข้อกำหนดทั้งหมดจากแผนและทำเครื่องหมายว่าข้อกำหนดใดที่คุณครอบคลุม

ผู้ตรวจสอบ, /review:

เปรียบเทียบสิ่งที่สร้างขึ้นกับ specs/project.md, ข้อกำหนดต่อข้อกำหนด
สำหรับแต่ละข้อ, บอกว่ามันถูกครอบคลุมหรือไม่ เขียนการแก้ไขที่จำเป็นและส่งกลับไปยัง /build ลงนามเมื่อแผนทั้งหมดถูกครอบคลุม

สามคำสั่ง, หนึ่งลูป: spec เขียนแผน, build นำไปใช้, review ตรวจสอบผลลัพธ์กับแผนและส่งการแก้ไขกลับไปยัง build มันจะวนซ้ำจนกว่าข้อกำหนดทั้งหมดจะถูกตอบสนอง

แผนคือแหล่งข้อมูลที่ถูกต้อง การตรวจสอบวัดการสร้างตามแผน, ไม่ใช่ตามความรู้สึก

นี่คือการเขียนโค้ดที่ขับเคลื่อนด้วยสเปคภายใน: สเปคที่เขียน, ไม่ใช่ประวัติการสนทนา, คือสิ่งที่เอเจนต์ต้องปฏิบัติตาม Spec Kit แบบโอเพนซอร์สของ GitHub ทำให้แนวคิดเดียวกันเป็นทางการด้วย /specify, /plan, /tasks และ /implement, และมันทำงานบน Claude Code, Copilot, Cursor, Codex CLI และ Antigravity CLI ด้วย

ทำไมบริบทใหม่ทำให้ลูปทำงาน: Ralph loop

Geoffrey Huntley ตั้งชื่อเวอร์ชันที่ตรงไปตรงมาที่สุดของสิ่งนี้ในกลางปี 2025: Ralph loop แนวคิดคือการใช้ลูป shell ธรรมดาที่ป้อนคำสั่งเดียวกันกับสเปคที่เขียน, ให้เอเจนต์เลือกงานหนึ่งและส่งมัน, จากนั้นเริ่มเอเจนต์ใหม่ที่มีบริบทสะอาดและป้อนคำสั่งเดียวกันอีกครั้ง

while has_more_todos; do
  agent --prompt "ทำงานในงานถัดไปจาก todo.md" --non-interactive
done

ส่วนที่ไม่ชัดเจนคือการรีเซ็ตบริบท เซสชันที่ยาวนานจะเน่า: หน้าต่างเต็มไปด้วยการคิดเก่า, ทางตันและเนื้อหาของไฟล์ที่ไม่สดใหม่, และโมเดลเริ่มลดการให้คำสั่งอย่างเงียบๆ ทุกการวนซ้ำของ Ralph คือเอเจนต์ใหม่ที่อ่าน repo ปัจจุบันและรายการที่ต้องทำจากดิสก์, ทำงานหนึ่งหน่วย, คอมมิต, และออกอย่างสะอาด Huntley ตั้งชื่อมันตามตัวละครใน Simpsons โดยตั้งใจ, มันดูโง่เกินไปที่จะทำงาน, และมันทำงาน หากคุณเคยดู เซสชันยาวๆ เริ่มหลอน, คุณก็รู้แล้วว่าทำไมหน้าต่างใหม่ถึงดีกว่าหน้าต่างที่บวม

Claude Code's /loop และ /goal

Claude Code ส่งมอบลูปพื้นฐานโดยตรง /goal ตั้งสถานะสิ้นสุดที่คงอยู่, ว่าการ "เสร็จสิ้น" ดูเป็นอย่างไร, และ Claude ประเมินความก้าวหน้าตามนั้นหลังจากแต่ละรอบแทนที่จะเพียงแค่รันขั้นตอนถัดไป /loop ทำซ้ำงานในจังหวะหรือจนกว่าจะมีเงื่อนไขเป็นจริง, ด้วยรูปแบบเช่น /loop every 10m หรือ /loop until: <condition> ใช้ร่วมกันพวกเขาสร้างลูปที่กำกับตนเองและสิ้นสุดตนเอง: Claude ทำงานกับความแตกต่างระหว่างสถานะปัจจุบันและเป้าหมาย, และหยุดเมื่อเป้าหมายถูกตอบสนองหรือคุณกด Ctrl+C

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

ลูปเดียวกัน, ทุกผู้ให้บริการ

ลูปไม่ใช่ฟีเจอร์ของ Claude, มันคือสิ่งที่ทั้งสาขากำลังมุ่งหน้าไป ชื่อแตกต่างกัน, รูปร่างไม่แตกต่างกัน

Codex CLI นำลูปไปไกลที่สุดในที่สาธารณะ ทีมของ OpenAI กำหนด /goal เป็นการตีความของพวกเขาต่อ Ralph loop และ Andrew Chen จาก a16z ปล่อยให้มันทำงานตลอดคืนบนไดรเวอร์อุปกรณ์เป็นเวลา 14 ชั่วโมงติดต่อกันโดยไม่ต้องแทรกแซง เขายังสังเกตว่ามันจะ "ใช้โทเค็น 10,000 เท่า", ซึ่งเป็นต้นทุนที่ตรงไปตรงมาของการให้เอเจนต์ทำงานเป็นเวลาครึ่งวัน

ข้อควรระวัง: ลูปขยายทุกอย่าง

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

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

จุดตรวจของมนุษย์นั้นทำให้เกิดคำถามที่ทุกทีมต้องถกเถียงกัน: คุณควรตรวจสอบโค้ดของเอเจนต์ AI ของคุณหรือไม่, และตามเกณฑ์ใดที่คุณตัดสินว่าเอเจนต์ทำผิด?

การรันลูปข้ามฟลีท

เอเจนต์ที่แก้ไขตัวเองหนึ่งตัวนั้นง่ายต่อการดูแล แต่ความได้เปรียบจะปรากฏเมื่อคุณรันหลายตัวพร้อมกัน, แต่ละตัววนซ้ำในงานของตัวเอง, และนี่คือจุดที่การดูเทอร์มินัลหยุดการขยาย

นี่คือสิ่งที่ AgentsRoom ถูกสร้างขึ้นมาเพื่อ มันคือห้องควบคุมหลายเอเจนต์: เอเจนต์แต่ละตัวมีบทบาท, จุดสถานะสดและสีของตัวเอง, และคุณดูแลฟลีททั้งหมดจากหน้าต่างเดียว วางตั๋วใน backlog และเอเจนต์จะหยิบมันขึ้นมา, รันลูปแผน-สร้าง-ตรวจสอบของมัน, และส่งให้คุณเป็น diff ที่สะอาด นั่นคือ การเขียนโค้ด AI ที่ขับเคลื่อนด้วยสเปค ในทางปฏิบัติ: ตั๋วคือสเปค, เอเจนต์รันลูป, คุณตรวจสอบผลลัพธ์

เนื่องจากลูปที่ยาวนานทำให้บริบทเน่า, AgentsRoom จึงเฝ้าระวังสิ่งนี้ เอเจนต์แต่ละตัวเขียนสถานะหนึ่งบรรทัดที่ท้ายทุกเทิร์น, และเมื่อเอเจนต์หยุดอัปเดตมันเป็นเวลาสองเทิร์นติดต่อกัน, จะมีการแจ้งเตือนปรากฏขึ้นพร้อมการรีสตาร์ทด้วยคลิกเดียวในบริบทที่สะอาด, การรีเซ็ตหน้าต่างใหม่ที่ Ralph loop พึ่งพา อ่านวิธีการทำงานนี้ในหน้า การตรวจจับการลอยของบริบท

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

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