การเขียนโค้ดแบบอัตโนมัติกำลังเปลี่ยนจากการใช้พรอมต์ที่ดีขึ้นไปสู่ระบบควบคุมที่ดีขึ้น การเปลี่ยนแปลงที่สำคัญคือวิศวกรกำลังเรียนรู้วิธีสร้างเอเจนต์ให้อยู่ภายใต้เป้าหมาย ผู้ประเมินผล ลูป และสิ่งประดิษฐ์ที่ช่วยให้พวกมันทำงานต่อไปได้หลังจากที่มนุษย์หยุดพิมพ์
เรื่องนี้สำคัญเพราะงานวิศวกรรมที่จริงจังส่วนใหญ่มักกินระยะเวลายาวนาน: ความต้องการที่คลุมเครือ ข้อจำกัดที่ซ่อนอยู่ ความล้มเหลวบางส่วน บริบทที่เปลี่ยนแปลง และการตรวจสอบซ้ำแล้วซ้ำเล่า ขอบเขตใหม่คือการออกแบบระบบรอบๆ เอเจนต์ เพื่อให้มันสามารถวางแผน ดำเนินการ ตรวจสอบงานของตัวเอง กู้คืนจากข้อผิดพลาด และก้าวหน้าต่อไปได้โดยไม่ต้องพึ่งพามนุษย์คอยควบคุมตลอดเวลา
บทความนี้อ้างอิงจาก เซสชัน DAIR.AI Academy เกี่ยวกับเอเจนต์เขียนโค้ดที่ทำงานระยะยาวแบบอัตโนมัติ ซึ่งฉันได้อธิบายโหมด /goal ของ Claude Code* คำสั่ง /loop* ตัวตรวจสอบ สิ่งประดิษฐ์ และรูปแบบการประสานงานในทางปฏิบัติ เขียนร่วมกับ Codex และ Claude Code
จากการใช้พรอมต์สู่การออกแบบเป้าหมาย
แนวคิดหลักเบื้องหลังฟีเจอร์อย่าง /goal ของ Claude Code นั้นง่ายมาก เอเจนต์เขียนโค้ดยังคงเป็นผู้ดำเนินการ แต่มนุษย์ไม่ได้โต้ตอบกับมันแบบทีละรอบอีกต่อไป แต่มนุษย์จะระบุสถานะปลายทางที่ต้องการ หลักฐานที่จำเป็นในการพิสูจน์ความสำเร็จ ข้อจำกัดที่ไม่ควรละเมิด และหากเป็นไปได้ จำนวนรอบและงบประมาณ
เป้าหมายนั้นทำงานเหมือนสัญญามากกว่าพรอมต์ที่ยาวขึ้น เป้าหมายที่อ่อนแอทำให้โมเดลมีช่องว่างที่จะหยุดก่อนเวลา เล่นทางลัด หรือนิยามความสำเร็จใหม่ในแบบที่ดูน่าเชื่อถือในบทสนทนาแต่ล้มเหลวในระบบจริง เป้าหมายที่แข็งแกร่งจะให้เป้าหมายที่เอเจนต์สามารถวัดตัวเองซ้ำๆ ได้
วิจารณญาณทางวิศวกรรมยังคงมีความสำคัญที่นี่ เป้าหมายที่ดีที่สุดจะเข้ารหัสความรู้เฉพาะด้านที่โมเดลอาจเดาเอาเอง สำหรับการทดลองวิจัย อาจหมายถึงคะแนนเกณฑ์มาตรฐานเป้าหมาย การประเมินแบบ held-out เส้นโค้งการสูญเสียที่ต้องการ และกฎว่าผลลัพธ์ต้องดีกว่า baseline เริ่มต้น สำหรับงาน UI อาจหมายถึงภาพหน้าจออ้างอิง ข้อจำกัดด้านเลย์เอาต์ที่เป็นรูปธรรม และขั้นตอนการตรวจสอบผ่านเบราว์เซอร์ โมเดลสามารถดำเนินการได้ แต่มนุษย์ยังคงเป็นผู้กำหนดว่า "เสร็จ" หมายถึงอะไรจริงๆ
ผู้ประเมินผลกลายเป็นส่วนประกอบระดับเฟิร์สคลาส
เอเจนต์ที่ทำงานระยะยาวจำเป็นต้องมีบทบาทที่สองนอกเหนือจากเป้าหมาย ผู้ประเมินผลนั้นอาจเป็นเอเจนต์เขียนโค้ดอีกตัว LLM-as-judge สคริปต์ ชุดทดสอบ ชุดเกณฑ์มาตรฐาน หรือการผสมผสานทั้งหมด ตัวเลือกการออกแบบที่สำคัญคือการจับคู่ผู้ประเมินผลให้เหมาะสมกับงาน เมื่อความสำเร็จชัดเจน การตรวจสอบแบบกำหนดตายตัวจะดีกว่า การตรวจสอบประเภท หน่วยทดสอบ กฎ lint การทดสอบเชิงบูรณาการ และสคริปต์เกณฑ์มาตรฐานควรถูกใช้เมื่อใดก็ตามที่สามารถแสดงเงื่อนไขได้อย่างชัดเจน
เมื่อความสำเร็จคลุมเครือ ผู้ประเมินผลแบบเอเจนต์ก็มีประโยชน์ สคริปต์สามารถบอกได้ว่าการทดสอบผ่านหรือไม่ แต่ไม่สามารถตัดสินได้ง่ายๆ ว่ารายงานการวิจัยที่สร้างขึ้นนั้นสอดคล้องกันหรือไม่ การนำไปปฏิบัติเป็นไปตามบทความอย่างซื่อสัตย์หรือไม่ หรือ UI ตรงกับความตั้งใจในการออกแบบหรือไม่ นี่คือจุดที่ผู้ประเมินผลได้ประโยชน์จากภาษา การตัดสิน และบางครั้งก็รวมถึงการมองเห็น
รูปแบบในทางปฏิบัติใช้การตรวจสอบแบบกำหนดตายตัวเป็นฐาน และใช้การประเมินแบบเอเจนต์เป็นการตรวจสอบระดับสูง การผสมผสานนี้ช่วยลดความสำเร็จที่ถูกกล่าวอ้างเกินจริง ในขณะที่ยังคงให้อิสระในการทำงานที่ไม่สามารถกำหนดเป็นเงื่อนไขทดสอบได้อย่างชัดเจน
ตัวตรวจสอบกำหนดขอบเขตของความเชื่อถือ
ประเด็นที่ลึกกว่านั้นคือ ระบบอัตโนมัติจะทำงานได้ก็ต่อเมื่อมีตัวตรวจสอบที่เชื่อถือได้ เอเจนต์เขียนโค้ดสามารถสร้างแผน นำเสนอฟีเจอร์ และอธิบายว่าทำไมมันถึงเชื่อว่างานเสร็จสมบูรณ์ แต่คำอธิบายนั้นไม่ควรถูกมองว่าเป็นหลักฐาน หลักฐานต้องมาจากการตรวจสอบจากภายนอกที่เอเจนต์ไม่สามารถอ้อมไปได้ง่ายๆ
สำหรับโค้ด ตัวตรวจสอบอาจเป็นชุดทดสอบ ตัวตรวจสอบประเภท เกณฑ์มาตรฐาน การรันเบราว์เซอร์ การเปรียบเทียบภาพหน้าจอ หรือสคริปต์ที่สามารถทำซ้ำได้ สำหรับงานวิจัย อาจเป็นการประเมินแบบ held-out ตารางที่ทำซ้ำ เส้นโค้งการสูญเสีย หรือคะแนนเกณฑ์มาตรฐานที่ดีกว่า baseline สำหรับงานออกแบบ อาจเป็นภาพหน้าจออ้างอิงพร้อมขั้นตอนการตรวจสอบด้วยสายตา ตัวตรวจสอบคือสิ่งที่เปลี่ยนเอเจนต์ที่ทำงานระยะยาวจากเครื่องสร้างข้อความที่มั่นใจ ไปเป็นระบบที่สามารถไว้วางใจให้ทำงานนานขึ้นได้
ทางลัดส่วนใหญ่จะเกิดขึ้นที่ขอบเขตนี้ หากตัวตรวจสอบคลุมเครือ โมเดลมักจะตอบสนองการตีความงานที่ง่ายที่สุด หากตัวตรวจสอบแคบเกินไป โมเดลอาจปรับให้เข้ากับมันมากเกินไปและพลาดเจตนาที่กว้างขึ้น ดังนั้น เวิร์กโฟลว์อัตโนมัติที่ดีจึงต้องมีการตรวจสอบแบบหลายชั้น โดยการตรวจสอบแบบกำหนดตายตัวราคาถูกจะจับความล้มเหลวพื้นฐาน และการตรวจสอบระดับสูงจะจับความล้มเหลวที่ต้องใช้การตัดสิน โมเดลแนวหน้าไม่กี่ตัวสามารถบรรลุการตรวจสอบในระดับหนึ่งได้แล้ว แต่จากงานวิจัยของฉัน ยังคงมีปัญหา OOD ที่ชัดเจน ซึ่งหากงานตรวจสอบที่คุณมอบหมายให้เอเจนต์อยู่นอกการกระจายข้อมูลฝึกฝน โมเดลจะประสบปัญหาอย่างมาก
ตัวตรวจสอบยังคงเป็นพื้นที่การวิจัยที่เปิดกว้าง แต่ฉันคาดว่าบริษัทต่างๆ จะเริ่มลงทุนมหาศาลในพื้นที่นี้ แนวคิดของตัวตรวจสอบที่ผ่านการปรับแต่งอย่างละเอียดก็เป็นที่ต้องการสูงในองค์กรเช่นกัน
ลูปทำให้ระบบอัตโนมัติคงทน
เป้าหมายให้ทิศทางแก่เอเจนต์ แต่ลูปทำให้งานยังคงดำเนินต่อไป ความแตกต่างนี้สำคัญเพราะโมเดลมักจะหยุดก่อนที่งานจริงจะเสร็จสมบูรณ์ พวกมันอาจถึงขีดจำกัดรอบ สูญเสียความมั่นใจ ใช้บริบทหมด หรือตัดสินว่าวิธีแก้ปัญหาบางส่วนนั้นเพียงพอแล้ว
ลูปคือระบบควบคุมภายนอก มันตื่นขึ้น ตรวจสอบความคืบหน้า รันเช็ค เปรียบเทียบผลลัพธ์กับเป้าหมาย และส่งเอเจนต์กลับไปพร้อมคำสั่งถัดไปเมื่อเป้าหมายยังไม่สำเร็จ ในรูปแบบที่ง่ายที่สุด นี่คือรูปแบบ Ralph loop กับเอเจนต์เขียนโค้ดและเงื่อนไขแบบกำหนดตายตัว ในรูปแบบที่ยืดหยุ่นกว่า ลูปจะรวมผู้ประเมินผลแบบเอเจนต์ที่สามารถใช้เหตุผลเกี่ยวกับความคืบหน้าและตัดสินใจว่าควรทำอะไรต่อไป
ระบบอัตโนมัติที่ทำงานระยะยาวคือความพยายามซ้ำๆ ภายใต้การดูแลจากเลเยอร์ควบคุม ไม่ใช่การกระทำทางปัญญาต่อเนื่องครั้งเดียว เอเจนต์ยังคงล้มเหลวได้ แต่ลูปทำให้ระบบมีวิธีสังเกตความล้มเหลวและดำเนินต่อไป แทนที่จะประกาศชัยชนะอย่างเงียบๆ
การวางแผนคือจุดที่ความเชี่ยวชาญเข้ามาเกี่ยวข้อง
หนึ่งในประเด็นที่แข็งแกร่งที่สุดจากเซสชันคือการวางแผนยังคงมีความสำคัญ คุณสามารถขอให้โมเดลแนวหน้าสร้างแผนได้ แต่คุณยังต้องตรวจสอบมัน ท้าทายสมมติฐาน และทำให้เกณฑ์ความสำเร็จชัดเจนยิ่งขึ้นก่อนที่จะส่งมอบงานให้กับลูปอัตโนมัติ
สิ่งนี้นำไปสู่การแบ่งงานที่มีประโยชน์ โมเดลวางแผนที่แข็งแกร่งกว่าสามารถช่วยกำหนดเป้าหมาย ระบุข้อจำกัดที่ขาดหายไป และจัดโครงสร้างการประเมิน จากนั้นโมเดลดำเนินการที่แตกต่างกันสามารถรันการนำไปใช้เมื่อแผนชัดเจนแล้ว ในทางปฏิบัติ หมายความว่าวิศวกรควรหยุดคิดว่า "โมเดล" เป็นทางเลือกเดียว การเลือกโมเดลกลายเป็นการตัดสินใจทางสถาปัตยกรรม
โมเดลบางตัวเป็นนักวางแผนที่ดีกว่า บางตัวเป็นผู้ดำเนินการที่ดีกว่า บางตัวเป็นผู้ประเมินราคาถูกกว่า บางตัวเก่งในการตรวจสอบด้วยสายตา ผู้ประสานงานที่ดีจะช่วยให้คุณสลับบทบาทเหล่านี้ได้ แทนที่จะรอให้ผู้จำหน่ายรายเดียวจัดหาอินเทอร์เฟซเอเจนต์เขียนโค้ดที่สมบูรณ์แบบ
สิ่งประดิษฐ์ที่มองเห็นกลายเป็นพื้นผิวควบคุม
บทสนทนาบนเทอร์มินัลไม่สามารถขยายขนาดได้เมื่อมีเอเจนต์ทำงานจำนวนมาก เมื่อคุณมีเซสชันหลายตัวทำงานพร้อมกัน ข้อความดิบจะไม่ใช่อินเทอร์เฟซที่ดีสำหรับการทำความเข้าใจความคืบหน้า
สิ่งประดิษฐ์แบบสดมีความสำคัญ เพราะแดชบอร์ดที่มีเส้นโค้งการสูญเสีย คะแนนเกณฑ์มาตรฐาน สถานะงาน ภาพหน้าจอ ค่าใช้จ่ายโดยประมาณ และการตัดสินใจล่าสุด ทำให้มนุษย์มีวิธีที่ดีกว่าในการดูแลระบบอัตโนมัติ สิ่งประดิษฐ์กลายเป็นพื้นผิวควบคุมสำหรับตัดสินใจว่าจะเข้าแทรกแซงเมื่อใด แทนที่จะเป็นรายงานที่สร้างขึ้นหลังจากเหตุการณ์เกิดขึ้นแล้ว
รูปแบบที่มีประโยชน์ที่สุดคือการแยกพื้นที่จัดเก็บออกจากการนำเสนอ Markdown หรือ vault สามารถเก็บหลักฐานที่คงทน บันทึก โน้ต แผน และผลลัพธ์ สิ่งประดิษฐ์ HTML สามารถแสดงสถานะนั้นเป็นสิ่งที่มองเห็นและโต้ตอบได้ เอเจนต์สามารถค้นหา Markdown ในขณะที่มนุษย์สามารถตรวจสอบสิ่งประดิษฐ์ได้
สำหรับงาน UI และผลิตภัณฑ์ สัญญาณภาพมีพลังเป็นพิเศษ ภาพหน้าจออ้างอิงสามารถสื่อสารความตั้งใจในการออกแบบได้แม่นยำกว่าร้อยแก้ว และผู้ประเมินผลที่สามารถมองเห็นได้สามารถเปรียบเทียบการนำไปใช้กับภาพอ้างอิงนั้น ซึ่งช่วยลดรูปแบบความล้มเหลวทั่วไปที่เอเจนต์ใช้คอมโพเนนต์ที่ร้องขอได้ในทางเทคนิค แต่พลาดระยะห่าง ลำดับชั้น การจัดตำแหน่ง หรือความรู้สึกของผลิตภัณฑ์
การขุดเซสชันเปลี่ยนการใช้งานให้เป็นความทรงจำ
ข้อมูลเชิงลึกที่สำคัญอีกอย่างคือ เซสชันเอเจนต์ในอดีตเป็นแหล่งข้อมูลเวิร์กโฟลว์ที่อุดมสมบูรณ์ หากเอเจนต์ล้มเหลวซ้ำๆ ในลักษณะเดียวกัน ลืมรันเช็คแบบเดิม ใช้เส้นทางผิด หรือลองคำสั่งที่เสียซ้ำๆ รูปแบบนั้นไม่ควรถูกฝังอยู่ในบันทึก
การขุดเซสชันเปลี่ยนบทสนทนาเหล่านั้นให้เป็นกฎการทำงาน เอเจนต์สามารถสแกนงานในช่วงสามสิบวันที่ผ่านมา หารูปแบบความล้มเหลวที่เกิดซ้ำ และเสนอการอัปเดตคำแนะนำโครงการ ความรู้จาก vault หรือกฎของเอเจนต์ นี่คือวิธีที่ทีมสามารถค่อยๆ ปรับปรุงระบบของตนโดยไม่ต้องจำทุกความผิดพลาดด้วยตนเอง
เป้าหมายคือการทำให้สภาพแวดล้อมในท้องถิ่นฉลาดขึ้นโดยไม่ต้องฝึกโมเดลตั้งแต่เริ่มต้น กฎเล็กๆ ในไฟล์คำแนะนำเอเจนต์สามารถป้องกันความล้มเหลวซ้ำๆ ในเซสชันในอนาคต โดยเฉพาะอย่างยิ่งเมื่อกฎนั้นเฉพาะเจาะจงกับโครงการ
รูปแบบการทำงานในทางปฏิบัติ
สำหรับวิศวกร AI เวิร์กโฟลว์ที่เกิดขึ้นใหม่มีลักษณะดังนี้
- เริ่มต้นด้วยชุดย่อยที่มีขนาดเล็กและราคาถูกก่อนที่จะเริ่มการทำงานอัตโนมัติเต็มรูปแบบ
- เขียนเป้าหมายพร้อมเกณฑ์ความสำเร็จที่วัดได้ ข้อจำกัดที่ชัดเจน และงบประมาณรอบหรือเวลา (ถ้าเป็นไปได้)
- แยกผู้ดำเนินการออกจากผู้ประเมินผล เพื่อให้การดำเนินการและการตัดสินไม่รวมอยู่ในบทบาทเดียว
- กำหนดตัวตรวจสอบภายนอกก่อนที่ลูประยะยาวจะเริ่ม
- ใช้การตรวจสอบแบบกำหนดตายตัวทุกที่ที่ทำได้ จากนั้นจึงเพิ่มการตรวจสอบด้วยเอเจนต์สำหรับเกณฑ์ที่คลุมเครือ
- กำหนดให้มีสิ่งประดิษฐ์ที่เป็นหลักฐาน เช่น บันทึก ภาพหน้าจอ เส้นโค้งเกณฑ์มาตรฐาน หรือไฟล์ที่เปลี่ยนแปลง
- ขุดเซสชันในอดีตและยกระดับบทเรียนที่เกิดซ้ำเป็นคำแนะนำโครงการ
นั่นคือความแตกต่างระหว่างการใช้เอเจนต์เขียนโค้ดกับการออกแบบระบบเขียนโค้ดอัตโนมัติ อย่างแรกให้บทสนทนากับคุณ อย่างหลังให้ระบบควบคุมที่ครบวงจร
สิ่งที่ยังคงพังได้
ไม่มีสิ่งใดที่กล่าวมาช่วยขจัดปัญหาที่ยากได้ เอเจนต์ยังคงใช้ทางลัด ยังคงหยุดก่อนเวลา ยังคงประเมินความสำเร็จสูงเกินไป ยังคงสร้างแผนที่มั่นใจแต่อ่อนแอ โดยเฉพาะกับบทความล่าสุด เกณฑ์มาตรฐานที่ไม่คุ้นเคย หรือระบบที่อยู่นอกการกระจายข้อมูลฝึกฝน
การไว้วางใจพวกมันมากขึ้นจะไม่แก้ปัญหานี้ ระบบควบคุมที่ดีกว่าจะเป็นตัวแก้ เป้าหมาย ลูป ผู้ประเมินผล การตรวจสอบแบบกำหนดตายตัว สิ่งประดิษฐ์ที่มองเห็น และความทรงจำจากเซสชัน ล้วนเป็นวิธีทำให้ระบบอัตโนมัติสามารถสังเกตและแก้ไขได้
ทิศทางชัดเจน อนาคตของเอเจนต์เขียนโค้ดขึ้นอยู่กับการประสานงานที่ดีขึ้นรอบๆ โมเดลที่มีความสามารถมากขึ้น โดยที่วิศวกรออกแบบเงื่อนไขที่เอเจนต์สามารถทำงานได้อย่างปลอดภัยเป็นเวลาหลายชั่วโมงหรือหลายวัน และยังคงผลิตงานที่สามารถตรวจสอบได้
