ผู้สืบทอดของ Loop Engineering และเวิร์กโฟลว์ที่ทำให้เอเจนต์ของคุณทำงานกว้างขึ้น 10 เท่า...
คนส่วนใหญ่ที่สร้างเอเจนต์แบบหลายขั้นตอนมักจะจบลงด้วย เส้นตรง
ขั้นตอนที่หนึ่ง สอง สาม แต่ละขั้นรอให้ขั้นก่อนหน้าทำเสร็จก่อนถึงจะเริ่ม
นี่คือสิ่งที่แทบไม่มีใครตรวจสอบ:
ครึ่งหนึ่งของขั้นตอนเหล่านั้นไม่เคยต้องรอ
พวกมันแค่เข้าแถวรอ ทีละงาน จนกระทั่งหน้าต่างบริบทเต็มและเอเจนต์ลืมสิ่งที่กำลังทำ
- มันไม่ได้ช้าเพราะโมเดลอ่อนแอ
- มันช้าเพราะ คุณวาดเส้นตรงในที่ที่งานนั้นเป็น กราฟ
คู่มือนี้จะพาคุณจากเส้นตรงนั้นไปสู่กราฟที่กระจายงานไปทั่วกองเรือและตรวจสอบงานของตัวเอง
ห้าขั้นตอน ภายในขั้นตอนที่ 2 คุณจะได้สร้างหนึ่งขึ้นมา -
มันจะทำให้คุณได้กราฟที่ใช้งานได้ และบอกชื่อกับดักที่ทำให้กราฟจริงพัง และฉันจะชี้ให้เห็นว่าส่วนที่ยากเริ่มต้นตรงไหน
ก่อนอัลฟ่า - สมัครสมาชิก substack ของฉันเพื่อรับอัลฟ่าใหม่ๆ เพิ่มเติม ↓
บทที่ 0 - วิศวกรรมกราฟจริงๆ แล้วคืออะไร
เมื่อเดือนที่แล้ว วงการพูดถึง ลูป
Peter Steinberger สรุปมันในเก้าคำ:
https://x.com/steipete/status/2078277297791189132
ลูปคือหนึ่งรอบของการทำให้ดีขึ้น:
ลองทำอะไรสักอย่าง → ตรวจสอบผลลัพธ์ → ปรับ → ลงมืออีกครั้ง
นั่นคืออะตอม: เอเจนต์ตัวเดียวที่ปรับปรุงสิ่งหนึ่งซ้ำๆ
(ถ้าคุณอ่านบทความ Loop Engineering ของฉันแล้ว นี่คือสิ่งนั้น)
https://x.com/0xCodila/status/2072329149520232639
แต่ลูปเดี่ยวมีจุดอ่อนที่รู้กันดี - ทีมสนับสนุนผูกฟีดแบ็กลูปเข้ากับเมตริกเดียว: อัตราการแก้ไขตั๋ว
ตัวเลขเพิ่มขึ้นเป็นเดือนๆ ในขณะที่ความพึงพอใจลดลง บอทเรียนรู้ที่จะปิดตั๋วให้เร็ว แทนที่จะแก้ปัญหา
นั่นคือ กฎของ Goodhart ลูปมองเห็นได้แค่เมตริกของตัวเอง มันไม่สามารถถามว่าเป้าหมายถูกต้องหรือไม่ หรือสังเกตว่าการวัดของตัวเองกำลังคลาดเคลื่อน
คำตอบไม่ใช่ลูปที่ดีกว่า แต่เป็นกราฟของลูป - เครือข่ายที่วัฏจักรต่างๆ เฝ้าดูและแก้ไขซึ่งกันและกัน
สำหรับเอเจนต์ นั่นหมายถึงสิ่งหนึ่ง:
หยุดเขียนเอเจนต์ตัวเดียวที่ทำทุกอย่างเป็นเส้นตรง - ออกแบบ
รูปร่าง
ของงาน - อะไรทำงานก่อนอะไร อะไรทำงานพร้อมกัน อะไรต้องรอ
โหนดทำหน้าที่คิด ส่วนขอบนำพาผลลัพธ์
และ Claude Code ได้ปล่อยเครื่องมือที่จะสร้างสิ่งเหล่านี้ได้โดยตรง: dynamic workflows
ขั้นตอนที่ 1 - มองเห็นขอบที่ไม่มีอยู่
กราฟมีสองส่วน:
- โหนด คือหนึ่งหน่วยของงาน: หนึ่งเอเจนต์ หนึ่งงาน หนึ่งอินพุต หนึ่งเอาต์พุต
- ขอบ คือการพึ่งพา: เอาต์พุตของโหนดนี้ป้อนเข้าสู่อินพุตของโหนดนั้น
ข้อผิดพลาดที่ทุกคนทำคือการถือว่า "แล้วก็" เป็นขอบ
"สรุปไฟล์นี้
แล้วก็
บอกสภาพอากาศให้ฉันหน่อย"
สภาพอากาศไม่ต้องอ่านสรุป
นั่นเป็นสองงานที่ไม่ขึ้นต่อกัน ซึ่งสคริปต์เชิงเส้นลากมาเชื่อมต่อกันโดยไม่มีเหตุผล แต่ละงานรอคอยงานก่อนหน้าโดยเปล่าประโยชน์
นิสัยที่เริ่มต้นทุกอย่าง:
สำหรับทุก "แล้วก็" ให้ถาม - ขั้นตอนถัดไปอ่านผลลัพธ์ของขั้นตอนก่อนหน้าจริงหรือไม่?
- ถ้าใช่ → ขอบจริง คงลำดับไว้
- ถ้าไม่ → ไม่มีขอบ การรอเป็นการเสียเวลา ให้รันคู่ขนานกัน
ถ้าไม่มีข้อมูลใดข้ามระหว่างสองกล่อง แสดงว่าพวกมันเป็นอิสระต่อกัน
ความเป็นอิสระนั้นคือสิ่งที่คุณจะใช้ประโยชน์ตลอดคู่มือนี้
เอเจนต์ธรรมดาๆ "ทำ A แล้ว B แล้ว C" ของคุณก็เป็นกราฟอยู่แล้ว - แค่เป็นกราฟที่น่าเศร้าที่สุด: สายโซ่เดี่ยวที่ถ้า C ติดขัด D จะไม่มีทางเกิดขึ้น
ขั้นตอนที่ 2 - สร้างกราฟแรกของคุณ (ตั้งแต่ต้นจนจบ)
ทฤษฎีพอกันที ลงมือสร้างหนึ่งอันแล้วดูมันทำงาน
ก่อนเริ่ม:
- Claude Code v2.1.154+ (ตรวจสอบด้วย claude --version)
- แผนแบบชำระเงิน บน Max, Team หรือ Enterprise เวิร์กโฟลว์เปิดใช้งานโดยค่าเริ่มต้น บน Pro ให้เปิดสวิตช์แถว Dynamic workflows ใน /config
1. เปิด repo ที่คุณรู้จัก
ของจริง เพื่อให้ผลลัพธ์มีความหมาย
2. วางพรอมต์นี้ (จาก Anthropic):
1สร้างเวิร์กโฟลว์เพื่อตรวจสอบทุกไฟล์ route ภายใต้ src/routes/ ว่าขาดการตรวจสอบสิทธิ์หรือไม่ สร้างเอเจนต์หนึ่งตัวต่อหนึ่งไฟล์ จากนั้นรันตัวตรวจสอบอิสระบนแต่ละสิ่งที่พบก่อนรายงาน วิเคราะห์สูงสุด 20 ไฟล์เพื่อเริ่มต้น
เปลี่ยน src/routes/ เป็นที่อยู่ของไฟล์คุณ บรรทัด "max 20" จะทำให้รันครั้งแรกไม่แพง
3. ดู "workflow" สว่างขึ้น
Claude Code จะไฮไลต์: "Dynamic workflow requested." นั่นคือสัญญาณว่ากำลังสร้างกราฟ ไม่ใช่แชทปกติ
4. อนุมัติแผน
Claude จะเขียนสคริปต์ orchestration ด้วย JavaScript และแสดงเฟสต่างๆ ก่อน อ่านแล้วเลือก "Yes, run it."
5. ปล่อยให้กองเรือทำงาน
หนึ่งเอเจนต์ต่อไฟล์ แบบคู่ขนาน ในขณะที่เซสชันของคุณยังว่าง
พิมพ์ /workflows เพื่อดูสด: ขอบเขต, การกระจาย, การตรวจสอบ, การสังเคราะห์
6. อ่านคำตอบเดียว
ไม่ใช่ยี่สิบแชทแยกกัน แต่เป็นรายงานเดียว - เพราะผลลัพธ์ระหว่างทางอยู่ในตัวแปรของสคริปต์ ไม่ใช่ในบริบทของคุณ
นั่นคือกราฟ
เอเจนต์เป็นโหล จากประโยคเดียว
เกี่ยวกับข้ออ้างเรื่อง "zero tokens" ที่คุณจะได้ยิน
สคริปต์ประสานงานคือโค้ด
ดังนั้นการส่งผ่านผลลัพธ์ระหว่างเอเจนต์จึงไม่ต้องใช้บริบทซ้ำเหมือนการส่งต่อในแชท
แต่ เอเจนต์ยังคงคิดค่าการใช้งาน เวิร์กโฟลว์มีค่าใช้จ่าย มากกว่าอย่างมีนัยสำคัญ เมื่อเทียบกับเซสชันปกติ
การประหยัดอยู่ที่การประสานงาน ไม่ใช่ที่ตัวงาน เริ่มแบบจำกัดขอบเขต ดูการใช้งาน แล้วค่อยขยาย
- ทำให้เป็นของคุณ
เมื่อรันได้ดี ให้กด s
มันจะบันทึกไปที่ ~/.claude/workflows สามารถรันซ้ำได้ด้วยชื่อ
ตอนนี้เปลี่ยนงานและคงรูปร่างไว้ เปลี่ยน "missing auth checks" เป็น "unhandled promises" หรือ "functions over 100 lines"
การปรับขนาดนี้ไปได้ไกลแค่ไหน (ชื่อบทความ)
การรันเวิร์กโฟลว์ครั้งเดียวสามารถกระจายไปยัง 1,000 เอเจนต์ โดยทำงานพร้อมกันสูงสุด 16 ตัว
นั่นคือที่มาของ "1000+ loops in one window" - ไม่ใช่คำอุปมา แต่เป็นเพดานจริงของฟีเจอร์
- และขนาดคือประเด็น เอเจนต์พันตัวหมายถึงงานที่ไม่มีบริบทเดียวจะสามารถรองรับได้ - โค้ดเบสทั้งหมดถูกตรวจสอบในครั้งเดียว การย้ายที่กระทบทุกไฟล์ การค้นหาที่รันพันมุมแบบคู่ขนาน
ข้อจำกัด 16 ตัวพร้อมกันหมายถึงกองเรือเคลื่อนที่เป็นคลื่น ไล่กัดกินทั้งหมดพันตัวโดยที่คุณไม่ต้องคอยดูแลสักตัว
เริ่มที่ 20 เพื่อดูว่าการรันเป็นอย่างไรและมีค่าใช้จ่ายเท่าไร - จากนั้นค่อยเปิดกว้าง - เพราะนี่คือเพดานที่ไม่มีใครอื่นกำลังสร้างแข่ง
ขั้นตอนที่ 3 - ส่วนที่พังจริงๆ
คุณสร้างกราฟแล้ว นี่คือจุดที่กราฟจริงล้มเหลว
ความล้มเหลวสองอย่างสำคัญที่สุด
- ความล้มเหลวที่หนึ่ง: กราฟเห็นด้วยกับตัวเอง
เมื่อเอเจนต์ตรวจสอบงานของตัวเอง มันจะผ่อนปรนให้ตัวเอง โมเดลชอบผลลัพธ์ของตัวเอง
ดังนั้นคุณจึงวาง ตัวตรวจสอบไว้ที่ขอบ - โหนดแยกต่างหากที่ยืนยันสิ่งที่พบก่อนที่จะไหล downstream
ข้อแม้ที่ไม่มีใครพูดถึง: ตัวตรวจสอบต้องการบริบทที่สะอาด
ส่งบทสนทนาเดียวกันกับที่ผู้ดำเนินการมีให้มัน มันก็ไม่ได้ตรวจสอบ มันกำลังเห็นด้วยกับตัวเองในฟอนต์อื่น
กราฟของเอเจนต์ที่แชร์บริบทเดียวกันคือลูปเดี่ยวในชุดคอสตูม มันล้มเหลวในแบบเดียวกัน - ช้ากว่า แพงกว่า และมีไฟเขียวมากขึ้นระหว่างทางลง
ดังนั้นตัวตรวจสอบจึงเป็น โหนดใหม่ - บริบทของตัวเอง - ตรวจสอบ สัญญาณจริง - ไม่ใช่ "เอเจนต์บอกว่ามันเสร็จแล้ว" แต่เป็น "การทดสอบผ่านจริงหรือไม่"
- ความล้มเหลวที่สอง: เอเจนต์เหยียบกัน
นี่ไม่ใช่เรื่องสมมุติ
เมื่อทีมของ Bun กระจายพอร์ตขนาดใหญ่ไปยังเอเจนต์หลายตัวครั้งแรก การรัน ล้มเหลวในเชิงปฏิบัติการ และเอเจนต์ใช้คำสั่ง git ร่วมกันในเวิร์กสเปซเดียวและเขียนทับกัน
วิธีแก้เป็นเชิงโครงสร้าง ไม่ใช่พรอมต์ที่ชาญฉลาด พวกเขาห้ามคำสั่งที่ไม่ปลอดภัยและให้แต่ละกลุ่มมี worktree ที่แยกจากกันของตัวเอง
นั่นคือบทเรียนที่แท้จริงของความขนาน - เอเจนต์สองตัวเขียนไฟล์เดียวกันจะแข่งกัน
ก่อนที่คุณจะกระจาย ให้ตอบสามคำถาม:
- เอเจนต์แต่ละตัวทำงานที่ไหน?
- ผลลัพธ์รวมกันอย่างไร?
- เกิดอะไรขึ้นเมื่อสองตัวไม่เห็นพ้อง?
กราฟที่ไม่มีแผนนั้นไม่สามารถขยายขนาดได้ - มันล้มเหลวเร็วขึ้น
ขั้นตอนที่ 4 - กราฟหกแบบที่ควรสร้างในสัปดาห์นี้
วิธีการ: ค้นหาขอบจริง → กระจาย → ตรวจสอบบนบริบทอิสระ → แยกผู้ปฏิบัติงาน
///
แต่ละอย่างนี้เป็นรูปร่างเดียวกัน มุ่งเป้าไปที่งานใหม่ เปลี่ยนบรรทัดงานแล้วลงมือ:
- การกวาดล้างความปลอดภัย - หนึ่งเอเจนต์ต่อไฟล์ ค้นหาการตรวจสอบสิทธิ์ที่ขาดหาย ตัวตรวจสอบยืนยันแต่ละครั้งที่พบ (อันที่คุณสร้างไว้)
- รายงานที่มีการอ้างอิงด้วย /deep-research - มีให้แล้ว: แบ่งคำถามของคุณเป็นมุม ค้นหาคู่ขนาน เอเจนต์โต้แย้งกันก่อนเขียน
- พอร์ตโมดูล - ทีละไฟล์ การทดสอบเป็นด่านตรวจ ความล้มเหลวถูกวนกลับ
- การตรวจสอบ diff แบบตรงข้าม - เส้นทางตามขนาด: การเปลี่ยนแปลงเล็ก → ผ่านครั้งเดียว; ใหญ่ → ตรวจสอบคู่ขนานเต็มรูปแบบ
- การสแกนระบบนิเวศตามกำหนดเวลา - บันทึกครั้งเดียว รันซ้ำด้วยชื่อ
- การค้นพบขนาดที่ไม่ทราบ - ตัวค้นหาทำงานคู่ขนาน แต่ละผลลัพธ์ถูกตรวจสอบกับทุกสิ่งที่เห็น วนซ้ำจนกว่าสองรอบจะไม่พบอะไรใหม่
///
เพดานมีลักษณะอย่างไรhttps://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
การพอร์ต Zig เป็น Rust ของ Bun ทำงานบนกลไกนี้เป๊ะๆ
ประมาณ 50 เวิร์กโฟลว์ สูงสุด 64 เอเจนต์แบบคู่ขนาน ซอร์สโค้ด Zig ประมาณ 535,000 บรรทัด กลายเป็น Rust กว่าล้านบรรทัด ใน 11 วัน
นอกจากนี้ยังมีค่าใช้จ่ายประมาณ $165,000 ในการใช้งาน ต้องมีมนุษย์ออกแบบและติดตามทั้งกระบวนการ
และยังถูกวิจารณ์จากสาธารณะเกี่ยวกับปริมาณโค้ดที่เขียนโดย AI มากขนาดนั้นจะสามารถตรวจสอบได้อย่างปลอดภัยหรือไม่
ขนาดนั้นเป็นจริง ราคาและการดูแลก็เป็นจริงเช่นกัน
ขั้นตอนที่ 5 - สมอเรือที่ทำให้กราฟซื่อสัตย์
โทโพโลยีเพียงอย่างเดียวไม่ได้ซื้อความจริง
เครือข่ายของเอเจนต์ที่ทั้งหมดยืนยันซึ่งกันและกัน โดยไม่มีตัวใดแตะต้องอะไรจริง ล้มเหลวเหมือนกับลูปเดี่ยวทุกประการ - แค่มีชิ้นส่วนเคลื่อนไหวมากขึ้น
กราฟต้องการ สมอเรือ: โหนดที่ไม่มีใครโต้แย้งได้
- การทดสอบที่รันจริง - ไม่ใช่ "ควรผ่าน" แต่ ผ่าน จริง
- ตัวตรวจสอบบนหลักฐาน ไม่ใช่ความรู้สึก
- กฎที่ถูกแช่แข็ง ที่เอเจนต์ไม่ได้รับอนุญาตให้ปรับแต่ง - เพราะมันเป็นสิ่งที่ตัวปรับให้เหมาะสมจะทำให้อ่อนแอลง
กราฟจะซื่อสัตย์ได้เท่ากับสิ่งต่างๆ ในนั้นที่ปฏิเสธที่จะขยับ
เมื่อกราฟเป็นตัวเลือกที่ผิด
งานส่วนใหญ่ไม่ใช่กราฟ การเอื้อมหยิบกราฟมาใช้เมื่อไม่จำเป็นก็แค่เผาเงินและเพิ่มช่องทางให้ล้มเหลว
ข้ามกราฟเมื่อ:
- งานมีขนาดเล็กหรือโดดเดี่ยว การเพิ่มฟังก์ชัน การแก้บัคหนึ่งตัว เวิร์กโฟลว์ที่นี่เป็นค่าใช้จ่ายล้วนๆ - เอเจนต์ตัวเดียวเร็วกว่าและถูกกว่า
- คุณต้องการการควบคุมที่ใกล้ชิด ถ้าคุณต้องการอ่านและอนุมัติทุกขั้นตอนก่อนที่ขั้นตอนถัดไปจะทำงาน จุดรวมของกราฟ (ทำงานกว้างโดยไม่มีคุณ) จะต่อต้านคุณ
- คุณยังไม่รู้ว่ากำลังมองหาอะไร งานสำรวจต้องการเอเจนต์ตัวเดียวที่คุณสามารถควบคุมได้ ไม่ใช่กองเรือที่ผูกมัดกับแผนก่อนที่คุณจะเข้าใจปัญหา
- ขั้นตอนต่างๆ พึ่งพากันจริงๆ ถ้าทุกขั้นตอนอ่านผลลัพธ์ของขั้นตอนก่อนหน้า มันคือสายโซ่จริง ความขนานไม่มีอะไรจะยึดเกาะ การบังคับกราฟลงบนงานที่เป็นลำดับอย่างแท้จริงแค่เพิ่มต้นทุนการประสานงานโดยไม่เพิ่มความเร็ว
สัญญาณคือขั้นตอนที่ 1 ถ้าคุณหาไม่เจอสองกล่องที่ไม่มีลูกศรระหว่างกัน ก็ไม่มีกราฟให้สร้าง มันคือลูป และลูปก็ใช้ได้
กราฟเป็นเครื่องมือสำหรับ ความกว้าง - งานอิสระ ที่ทำพร้อมกัน
เมื่องานไม่กว้าง เส้นตรงไม่เคยเป็นปัญหา...
การเปลี่ยนผ่าน
นักพรอมต์ถามคำถาม สถาปนิกวาดกราฟ
เอเจนต์เชิงเส้นตรงไม่เคยเป็นเพดาน
มันเป็นรูปร่างแรก - รูปร่างที่ทุกคนเอื้อมถึงเพราะมันตรงกับวิธีที่เราพิมพ์: หนึ่งบรรทัด ทีละอย่าง
เมื่อคุณเห็นโหนดและขอบแล้ว คุณจะหยุดขอให้เอเจนต์ ทำมากขึ้น และเริ่มขอให้กราฟ ทำมันให้กว้างขึ้น:
- กระจาย ในที่ที่งานเป็นอิสระ
- กั้นขอบ ในที่ที่ความมั่นใจสำคัญ
- แช่แข็งโหนด ที่ยึดความจริง
คนส่วนใหญ่จะยังคงจัดคิวขั้นตอนเป็นเส้นตรง
คนส่วนน้อยที่เรียนรู้ที่จะวาดกราฟ และเคารพสิ่งที่ทำให้มันพัง จะได้รันกองเรือ
วาดกราฟ คงสถานะสถาปนิก
เริ่มต้นด้วยข้อกำหนดเบื้องต้น:
- ลูปเดี่ยวที่สิ่งนี้สร้างบน
