ผมรัน AI agents 1,000 ตัว ด้วย 6 ขั้นตอน 5 คำสั่ง และ 1 ไฟล์ (คู่มือสำหรับนักพัฒนา)

Prompting ตายแล้วในปี 2024 ทักษะใหม่คือ Orchestration

ผมรัน AI Agents 1,000 ตัวเป็นเวลา 30 วัน และนี่คือสิ่งที่ผมค้นพบ

ทักษะที่มาแทน prompting และระบบที่คุณสามารถรันได้ในวันนี้

หยุดปรับแต่ง prompt ของคุณ มันไม่ใช่คอขวดอีกต่อไป

กับ agent หนึ่งตัวในหน้าต่างแชทเดียว prompt คือแทบทั้งเกม

กับ agent สิบตัวที่รันเป็นชั่วโมง prompt เป็นแค่ rounding error

สิ่งที่ตัดสินคุณภาพของงานคือระบบรอบๆ agents:

• แต่ละ task รันในโหมดไหน
• แต่ละขั้นตอนรันด้วย model ไหน
• agents ทำงานประสานกันอย่างไร
• การ 'เสร็จ' ได้รับการตรวจสอบอย่างไรในขณะที่คุณหลับ

prompt ให้ผลลัพธ์เดียว ลูปให้การดำเนินการที่ทบต้น

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

เลเยอร์การออกแบบนั้นคืองานของคุณในตอนนี้ นี่คือวิธีสร้างมัน

คุณสร้าง orchestrator ไม่ใช่โค้ด

คุณไม่ได้จัดการ agent สามสิบตัวด้วยการพูดกับ agent สามสิบตัว คุณพูดกับตัวเดียว ตัวนั้นคือ orchestrator และมันจัดการส่วนที่เหลือ

orchestrator ที่ดีทำสามสิ่งนี้พอดี:

1. แยกย่อยเป้าหมายออกเป็นงานย่อยที่มีขอบเขตและตรวจสอบได้อิสระ
2. มอบหมายงานย่อยแต่ละงานให้ worker พร้อมคำสั่งที่รัดกุมและความเป็นเจ้าของไฟล์ที่ชัดเจน
3. รวบรวมผลลัพธ์และตัดสินใจว่าจะทำอะไรต่อไป

กฎข้อหนึ่งอยู่เหนือกฎอื่นๆ ทั้งหมด: orchestrator จะไม่ทำงานนั้นด้วยตัวเอง

ทันทีที่ lead agent ของคุณเริ่มเขียนโค้ด implementation บริบทของมันจะเต็มไปด้วยรายละเอียดและมันจะสูญเสียเธรดของงานทั้งหมด

รักษาบริบทของมันให้สะอาด มันคิด แยก มอบหมาย และตรวจสอบ ไม่มีอย่างอื่น

จากนั้นเจาะลึก ไม่ใช่กว้าง:

• อย่าให้ orchestrator สร้าง worker แปดตัวโดยตรง เพราะจะทำให้บริบทแตกกระจาย
• ให้มันสร้าง lead สองหรือสามตัวแทน
• ให้แต่ละ lead สร้างผู้เชี่ยวชาญสองหรือสามคนของตัวเอง

ผลตอบแทนคือความลึกในการแยกย่อยที่สามเท่าในต้นทุนบริบทเดียวกัน นี่คือวิธีที่องค์กรจริงขยายขนาด ผ่านเลเยอร์ ไม่ใช่โดยให้คนคนหนึ่งมอบหมายทุกงาน

ตรวจสอบได้หรือไม่: การแบ่งแยกที่ตัดสินทุกอย่าง

ก่อนที่คุณจะสร้างอะไร ให้ถามหนึ่งคำถามเกี่ยวกับงาน เครื่องสามารถตรวจสอบได้หรือไม่ว่างานเสร็จแล้ว?

คำตอบนั้นตัดสินแนวทางทั้งหมดของคุณ

ถ้างานตรวจสอบได้ คุณสามารถ loop มัน:

• Test ผ่านหรือไม่
• Type checker เป็นสีเขียวหรือไม่
• Benchmark ผ่านเกณฑ์หรือไม่

ชี้ agent ไปที่งานที่ตรวจสอบได้ และมันจะ hill-climb มันข้ามคืน คุณตื่นขึ้นมาพบกับปัญหาที่แก้แล้ว

ถ้างานตรวจสอบไม่ได้ การ loop เพียงอย่างเดียวจะไม่ช่วยคุณ ตัวอย่าง:

• การออกแบบ eval ที่ดี
• การตัดสินใจว่า API รู้สึกถูกต้องหรือไม่
• การตัดสินว่าทิศทางการวิจัยนั้นคุ้มค่าที่จะไล่ตามหรือไม่

สำหรับสิ่งเหล่านี้ คุณต้องใส่รสนิยม คุณไม่สามารถส่งมอบเป้าหมายและเดินจากไป เพราะไม่มีประตูให้หยุด

ดังนั้นการเคลื่อนไหวคือทำให้งานมากที่สุดเท่าที่คุณสามารถตรวจสอบได้:

• เปลี่ยน 'ทำให้มันดี' เป็น 'ผ่านการตรวจสอบเฉพาะเหล่านี้'
• แทนที่เป้าหมายที่คลุมเครือด้วยเป้าหมายที่ชัดเจนและวัดผลได้
• ในที่ที่คุณทำไม่ได้ ให้มนุษย์อยู่ในลูปและควบคุม

วิศวกรรมการ orchestration ส่วนใหญ่คือการแปลงเป้าหมายที่คลุมเครือให้เป็นเป้าหมายที่ตรวจสอบได้ เพื่อให้ลูปสามารถทำงานแทน

เริ่มต้นด้วยระบบจริงที่เล็กที่สุด: goal loop

goal loop คือวัตถุประสงค์ที่คงอยู่บวกกับการตรวจสอบที่แน่นอน agent ทำงานทีละขั้นไปยังเป้าหมายแทนที่จะหยุดหลังจากหนึ่งรอบ

ทั้งระบบคือลูปรอบ agent และ validator ของคุณ:

1i=0
2until npm test -s; do
3  agent -p "เป้าหมาย: ทำให้ test suite เป็นสีเขียว
4            อ่านโค้ดและสร้างภาพรวมทั้งหมดก่อนที่จะเปลี่ยนแปลงอะไร
5            'npm test' กำลังล้มเหลว ให้เปลี่ยนแปลงเล็กน้อยที่สุดเพื่อให้ผ่าน"
6  (( ++i > 20 )) && { echo "หยุด: 20 รอบ"; exit 1; }
7done

validator คือคำสั่งใดๆ ที่ exit code คือประตู Test, typecheck, lint หรือสคริปต์ที่กำหนดเอง

สองสิ่งนี้ไม่สามารถต่อรองได้:

1. ขีดจำกัด ลูปที่ไม่มีเงื่อนไขหยุดคือวิธีที่คุณตื่นขึ้นมาพร้อมกับค่า token ห้าหลัก
2. คำสั่งอ่านก่อน โหมดความล้มเหลวเริ่มต้นของทุก agent คือการสุ่มยิงไปที่การแก้ไขที่เป็นไปได้ครั้งแรกแทนที่จะอ่านโค้ด

บังคับให้อ่าน มันช้าต่อขั้นตอนแต่โดยรวมเร็วกว่ามาก

ทำให้ "เสร็จ" ไม่สามารถต่อรองได้: the judge

Agent เลิกก่อนเวลา พวกมันถูกฝึกให้หยุดทันทีที่สามารถหาเหตุผลมาสนับสนุนได้

'ฉันพยายามอย่างเต็มที่แล้ว หยุดตรงนี้' ไม่เหมือนกับเสร็จ

ถ้า agent ให้คะแนนการบ้านของตัวเอง มันโกง ไม่ใช่ด้วยความมุ่งร้าย แค่พูดให้ตัวเองเชื่อว่าทำเสร็จแล้ว

ทางแก้คือ judge ที่แยกต่างหาก:

• agent ตัวที่สองที่มีหน้าที่เดียวคือให้คะแนนงานตาม rubric ที่เป็นรูปธรรม
• มันตอบหนึ่งคำถาม: เสร็จหรือไม่เสร็จ และขาดอะไร
• มันไม่มีส่วนได้ส่วนเสียในการหยุด ดังนั้นมันจึงไม่หวั่นไหว

รัน builder และ judge บนตระกูล model ที่แตกต่างกัน ตระกูลที่แตกต่างกันทำผิดที่ไม่สัมพันธ์กัน ดังนั้น judge จะเห็นสิ่งที่ builder มองไม่เห็น

1while :; do
2  agent --model "$BUILD" -p "Task: $TASK. อ่านก่อน implement รัน tests"
3  verdict=$(agent --model "$JUDGE" -p "ผู้ตรวจสอบที่เข้มงวด ให้คะแนนตามทุกข้อใน rubric.md
4            ตอบตรง 'PASS' หรือ 'FAIL: <สิ่งที่ขาด>'")
5  [[ $verdict == PASS* ]] && break
6done

ทำให้ rubric เป็นรูปธรรมและเป็น binary:

• Rubric ที่ดี: 'test ทั้งหมดเป็นสีเขียว รวม migration ไม่มี debug logging'
• Rubric ที่แย่: 'ทำให้มันดี'

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

เรียกใช้มันทุกครั้งที่ task เสร็จ แล้วคุณจะเห็นงานที่ผ่านการตรวจสอบเป็นสีเขียวเท่านั้น

ลูปเพิ่มเติมที่คุณจะใช้จริง

goal loop เป็นรูปแบบพื้นฐาน รูปแบบแปรผันสองสามแบบครอบคลุมสิ่งที่คุณจะรันส่วนใหญ่

1. Validation loop

ทำ, รัน validator, ป้อนความล้มเหลวกลับ, ทำซ้ำจนกว่าประตูจะเป็นสีเขียว

ใช้สำหรับ regression sweeps, type checks และการผ่านหรือไม่ผ่านที่แน่นอนใดๆ

2. Queue and reset loop

แบ่งงานออกเป็นรายการงานเล็กๆ ที่เป็น atomic ประมวลผลทีละงาน

หลังจากแต่ละ task, รีเซ็ต agent ไปยังบริบทที่สะอาดและหยิบงานถัดไป

บริบทที่รันเป็นชั่วโมงจะเต็มไปด้วยความสับสน การรีเซ็ตทำให้แต่ละ task สะอาด

หน่วยความจำอยู่ภายนอก agent ในไฟล์ task และประวัติ commit

1while read -r task; do
2  agent -p "Task: $task. อ่านก่อน Implement แล้วรัน tests"
3  npm test -s && git commit -aqm "auto: $task"   # commit only on green
4done < tasks.txt

3. Monitor loop

ชี้ agent ไปที่สตรีมสัญญาณและปล่อยให้มันเผยสิ่งที่สำคัญ Issue ที่เปิด, build ที่ล้มเหลว, error log, feedback ใหม่

มันไม่รอให้คุณถาม มันอ่าน คัดแยก และรายงานขึ้นไป หรือเปิด draft fix

1while sleep 300; do
2  agent -p "อ่าน error logs 5 นาทีที่ผ่านมา ถ้ามีรูปแบบ ใหม่ ปรากฏขึ้น
3            ให้เปิด issue พร้อม minimal repro มิฉะนั้นให้บอก 'ไม่มีอะไรใหม่'"
4done

4. Plan-then-build loop

รันลูปในสองเฟส ผ่านแรกคือการวางแผนที่สร้างแผนเป็นลายลักษณ์อักษรและหยุด

คุณตรวจสอบแผน จากนั้นผ่านการดำเนินการตามแผนที่อนุมัติ

แผนถูกในการแก้ไข โค้ดแพงในการแก้ไข จับทิศทางที่ผิดในแผน

Prompts ที่ทำงาน

Prompt ไม่ใช่ความปรารถนา สำหรับ agent มันคือ spec

ช่องว่างระหว่างผลลัพธ์ธรรมดาและผลลัพธ์ที่ยอดเยี่ยมเกือบทั้งหมดคือคุณภาพของสิ่งเหล่านี้

เก็บ prompts ที่ใช้ซ้ำได้ชุดเล็กๆ ห้าตัวรับน้ำหนักส่วนใหญ่

1. Decomposition prompt สำหรับ orchestrator:

1คุณคือ orchestrator อย่าเขียนโค้ด
2แบ่งเป้าหมายนี้ออกเป็น 3 ถึง 6 งานย่อยที่มีขอบเขต
3สำหรับแต่ละงาน: คำอธิบายหนึ่งบรรทัด ไฟล์ที่มันเป็นเจ้าของ และการตรวจสอบว่าเสร็จ
4ทำเครื่องหมายงานที่ขึ้นอยู่กับงานอื่น แสดงรายการแล้วหยุด
5เป้าหมาย: <goal>

2. Worker brief สำหรับผู้เชี่ยวชาญ:

1คุณเป็นเจ้าของเฉพาะไฟล์เหล่านี้: <files>
2Task: <one line> เสร็จเมื่อ: <verifiable check>
3อ่านไฟล์เหล่านั้นและผู้เรียกก่อนแก้ไข อย่าเปลี่ยนแปลงอะไรนอกไฟล์ของคุณ
4เมื่อเสร็จ ให้เขียนรายงาน 5 บรรทัดไปที่ <name>.md แล้วรัน tests

3. Judge prompt สำหรับตระกูล model ที่แตกต่าง:

1คุณคือผู้ตรวจสอบที่เข้มงวดและไม่เห็นอกเห็นใจ คุณไม่ได้เขียนโค้ดนี้
2ให้คะแนน repo ตาม ทุก ข้อด้านล่าง การพลาดคือ FAIL
3<rubric>
4ตอบด้วยหนึ่งบรรทัดเท่านั้น: 'PASS' หรือ 'FAIL: <สิ่งที่ขาด>'

4. Plan-first prompt สำหรับโหมดแผน:

1สร้างแผนเป็นลายลักษณ์อักษรสำหรับ <goal> ครอบคลุม: แนวทาง ไฟล์ที่จะแตะ
2edge cases กลยุทธ์การทดสอบ และสิ่งที่คุณจะ ไม่ ทำ
3ยังไม่ต้องเขียนโค้ด หยุดหลังจากแผนเพื่อให้ฉันตรวจสอบได้

5. Reflect-or-kill prompt เมื่อ agent ติดขัด:

1คุณล้มเหลวในการตรวจสอบเดียวกัน 3 ครั้งแล้ว หยุดทำซ้ำแนวทางเดิม
2ตอบใน 3 บรรทัด: อะไรล้มเหลวจริงๆ สมมติฐานไหนผิด
3และสิ่งเล็กที่สุดที่แตกต่างที่ควรลอง จากนั้นลองเฉพาะสิ่งนั้น

รูปแบบหนึ่งไหลผ่านทั้งห้า ระบุบทบาท ขอบเขต การตรวจสอบเสร็จ และสิ่งที่ไม่ควรทำ

Model routing: คำถามที่ทุกคนถาม

คำถามมักถูกวางกรอบเป็นทางเลือก ฉันควรวาง model แพงในการวางแผนหรือในการ implement?

นั่นเป็นกรอบที่ผิด ให้ route ตาม blast radius แทน ถามว่าความผิดพลาดทำให้คุณเสียค่ามากที่สุดที่ไหน

ตรรกะง่าย:

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

นี่คือ routing ทีละ tier:

1. การวางแผน สถาปัตยกรรม และการแยกย่อย: top tier เสมอ Leverage สูงสุด ปริมาณ token เล็กน้อย ถูกที่นี่คือความผิดพลาดที่แพงที่สุดที่คุณสามารถทำได้
2. Implementation ด้วย spec ที่รัดกุม: mid tier รันแบบขนาน Spec ทำการคิด ตรวจสอบด้วย tests
3. Implementation ด้วย spec ที่หลวม: top tier การเติมช่องว่างคือการใช้เหตุผล และ model ราคาถูกจะเดาผิดไปหลายทิศทาง
4. การตรวจสอบและตัดสิน: ตระกูลที่แตกต่าง และไม่ใช่ราคาถูก นี่คือที่ที่คุณจับพลาดที่แพง
5. การนำทาง การค้นหา การสรุป และการจำแนก: model ที่ถูกที่สุดและเร็วที่สุด ไม่ต้องใช้เหตุผล ปริมาณสูง อย่าจ่ายอัตราพรีเมียมสำหรับ grep

ดังนั้นคำตอบที่แท้จริงสำหรับ 'การวางแผนถูกหรือ implementation ถูก' ไม่ใช่ทั้งสองอย่างแบบไม่ลืมหูลืมตา

Top model ในการวางแผนและตรวจสอบเสมอ Implementation เป็นตัวแปร

ตระกูล model ที่แตกต่างกันก็มีบุคลิกที่แตกต่าง และนั่นสำคัญสำหรับ routing:

• ครอบครัวหนึ่งเติมช่องว่าง เมื่อ spec หลวม มันตั้งสมมติฐานที่สมเหตุสมผลและเคลื่อนที่ต่อไป สิ่งนั้นช่วยเมื่อสมมติฐานดี และทำร้ายเมื่อไม่ดี
• อีกครอบครัวหนึ่งเป็นตามตัวอักษร มันทำตามที่คุณพูดและอีกเล็กน้อย เหมือนมีดอเนกประสงค์ที่แม่นยำ

ใช้ตัวเติมช่องว่างในที่ที่งานปลายเปิดและ spec หลวม ใช้ตัวตามตัวอักษรสำหรับการตรวจสอบและการเปลี่ยนแปลงที่แม่นยำและระบุชัดเจน

คันโยกที่ควบคุม implementation คือ spec ของคุณ

• Spec ที่รัดกุมทำให้คุณมีสิทธิ์รัน worker ราคาถูกแบบขนาน
• Spec ที่หลวมบังคับให้คุณกลับไปใช้ model แพงเพื่อเติมช่องว่าง

ลงทุนในแผนอย่างแม่นยำเพื่อให้คุณลดราคาการ build ได้

กับดักหนึ่งที่ควรพูดถึง Cheap routing ปรับราคาของแต่ละ call ให้เหมาะสม แต่มันสามารถทำลายส่วนแบ่งของ tokens ที่สร้าง output ที่ shipped และ mergeable ได้อย่างเงียบๆ

model ราคาถูกที่ลองใหม่ห้าครั้งและสร้างโค้ดที่คุณไม่สามารถ merge ได้แพงกว่า pass ที่สะอาดครั้งเดียวจาก model พรีเมียม

วัดต้นทุนของ output ที่มีประโยชน์ ไม่ใช่ต้นทุนต่อ call

สำหรับการขยายขนาด ตัวเลขสองตัวช่วยได้:

• Top tier ของคุณมีราคาประมาณห้าเท่าของราคา output ต่อ token ของ cheap tier
• Tiered routing โดยทั่วไปลดการใช้จ่าย 40% ถึง 60% เมื่อเทียบกับการรัน model ที่ดีที่สุดของคุณทุกที่

ทักษะ: แพ็คเกจ workflow ครั้งเดียว ใช้ซ้ำตลอดไป

เมื่อคุณวาง prompt เดิมซ้ำๆ หรือรัน workflow เดิม ให้เปลี่ยนเป็นทักษะ

ทักษะคือไฟล์คำสั่งขนาดเล็กที่ agent โหลดเฉพาะเมื่อเกี่ยวข้อง

คุณเขียน workflow ครั้งเดียว และทุก agent สามารถหยิบใช้ได้

ไฟล์ทักษะมีสองส่วน:

• YAML frontmatter พร้อมชื่อและคำอธิบาย
• เนื้อหา markdown พร้อมคำแนะนำจริง

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

ไฟล์ทักษะขั้นต่ำ:

1---
2name: thermonuclear-review
3description: การตรวจสอบโค้ดเชิงลึกแบบ adversarial ใช้หลังการเปลี่ยนแปลงที่ไม่ธรรมดา
4  หรือเมื่อถูกขอให้ตรวจสอบ ตรวจสอบบัญชี หรือทำให้ diff แข็งแกร่งก่อน merge
5---
6
7# การตรวจสอบแบบเทอร์โมนิวเคลียร์
8
9อ่าน diff ทั้งหมดและไฟล์ที่มันแตะ อย่าอ่านคร่าวๆ
10
11ตรวจสอบในสามรอบ:
121. ความถูกต้อง: ข้อผิดพลาดทางตรรกะ, edge cases, race conditions, off-by-ones
132. ความปลอดภัย: injection, auth, secrets, input ที่ไม่ปลอดภัย, การทำลายล้าง
143. ความเหมาะสม: มันตรงกับสถาปัตยกรรมที่มีอยู่ หรือเป็นการเพิ่มรูปแบบใหม่
15
16สำหรับแต่ละสิ่งที่พบ: ไฟล์, บรรทัด, ความรุนแรง, และการแก้ไขหนึ่งบรรทัด
17จบด้วยคำตัดสิน: SHIP หรือ BLOCK พร้อม 3 สิ่งที่ต้องแก้ไขก่อน

กฎสำหรับทักษะที่ดี:

1. เก็บไฟล์ให้สั้น ใต้สองสามร้อยบรรทัด ย้ายเอกสารอ้างอิงยาวไปยังไฟล์แยกที่ทักษะชี้ไป
2. ทำให้ชื่อตรงกับโฟลเดอร์ ไม่เช่นนั้นมันจะไม่โหลด
3. เขียนคำอธิบายสำหรับการเรียกใช้ ระบุกรณี 'ใช้เมื่อ'
4. อย่าปล่อยให้ agent เขียนทักษะใหม่ มนุษย์คัดสรรทุกบรรทัด

ทักษะคือวิธีที่ workflow ทบต้น ครั้งแรกที่คุณแก้ไขบางสิ่งได้ดี คุณบันทึกและทำให้ค้นพบได้ ทุกเซสชันหลังจากนั้น มันฟรี

การรันจำนวนมาก: the fleet

เมื่อลูปเดียวทำงาน คุณขยายออก

ให้ worker แต่ละตัวสองสิ่ง:

• Git worktree ของตัวเอง เพื่อให้ไม่มี agent สองตัวแตะไฟล์เดียวกัน
• หน้าต่าง terminal ของตัวเอง เพื่อให้คุณสามารถดูและส่งข้อความถึงมัน

1tmux new-session -d -s fleet
2for name in hilbert gauss poincare; do
3  git worktree add -B "agent/$name" "../wt-$name" main
4  tmux new-window -t fleet -n "$name" -c "../wt-$name" "$AGENT"
5done

• ตั้งชื่อ agents ของคุณ การรันสิบห้าตัว 'agent_7' ไร้ประโยชน์
• ชื่อทำให้คุณจับ fleet ทั้งหมดไว้ในหัว ตัวนี้เป็นเจ้าของ data layer ตัวนั้นเขียน evals ตัวนั้นตรวจสอบ
• ความสามารถในการอ่านคือประเด็น Fleet ที่คุณไม่สามารถติดตามได้คือ fleet ที่คุณไม่สามารถควบคุมได้
• จากนั้นทำให้พวกเขาร่วมมือ โดยค่าเริ่มต้น agents จะเพิกเฉยต่อกันและถือว่าสิ่งใดจาก sibling เป็นเสียงรบกวน

เคล็ดลับคือการส่งข้อความระหว่าง agents เป็น user turns Model ถูกฝึกให้ตอบสนองต่อผู้ใช้และส่วนใหญ่ไม่สนใจสัญญาณแวดล้อม

1send() { tmux send-keys -t "fleet:$1" "$2" Enter; }
2send hilbert "GET /search?q= returns [{id,title,url}]. Wire the UI to it."

การเคลื่อนไหวเดียวเปลี่ยนกองของกระบวนการที่แยกออกเป็นทีมที่ส่งมอบสัญญาและปลดบล็อกซึ่งกันและกัน

คุณอยู่ด้านบน คุณส่งข้อความถึง lead และ lead ถ่ายทอดให้ workers

Dynamic workflows: คอมไพล์การประสานงานเป็นโค้ด

ลูปเก็บการประสานงานไว้ใน model Model ตัดสินใจแต่ละขั้นตอน ซึ่งเผา tokens และเติมบริบท

Dynamic workflow พลิกสิ่งนั้น Orchestrator เขียน script ที่ประสานงาน workers และ runtime แยกต่างหากรัน script ในพื้นหลัง

แนวคิดหลักคือที่ที่ state อาศัยอยู่ ลูป การแตกกิ่ง และผลลัพธ์ระหว่างกลางอยู่ในตัวแปรของ script ไม่ใช่ในหน่วยความจำของ model

สิ่งที่คุณได้จากสิ่งนี้:

• การประสานงานใช้ tokens model เป็นศูนย์ เพราะโค้ดธรรมดากำลังทำมัน
• บริบทหลักของคุณยังคงสะอาด มีเพียงผลลัพธ์สุดท้ายที่กลับมา
• มันกระจายกว้าง Workers หลายสิบตัวในครั้งเดียว มากถึงหนึ่งพันทั่วการรัน

เมื่อใดควรใช้มัน:

• รูปแบบเป็นที่รู้จักและการตรวจสอบเป็นวัตถุประสงค์
• งานกว้างและซ้ำ หลายไฟล์ หลายกรณี หลาย endpoint
• มันสามารถรันโดยไม่มีผู้ดูแล

เมื่อใดไม่ควรใช้มัน:

• คุณยังคงคิดหาว่าจะทำอะไร นั่นคือ goal loop ไม่ใช่ workflow
• งานต้องการห่วงโซ่เหตุผลที่สอดคล้องหนึ่งเดียว นั่นต้องการ agent ที่แข็งแกร่งตัวเดียว ไม่ใช่พันตัว

รูปทรงที่เป็นรูปธรรม สมมติว่าคุณต้องย้าย 200 ไฟล์ไปยัง API ใหม่:

1// orchestrator เขียนนี้ครั้งเดียว runtime รันมัน ไม่ใช่ model
2const files = await glob("src/**/*.ts");
3
4const results = await mapLimit(files, 16, async (file) => {
5  const r = await subagent(`ย้าย ${file} ไปยัง API ใหม่ รัน tests`);
6  return { file, ok: r.testsPassed };
7});
8
9const failed = results.filter(r => !r.ok);
10return `ย้าย ${results.length - failed.length} จาก ${results.length} แล้ว ` +
11       `ลองใหม่: ${failed.map(f => f.file).join(", ")}`;

อ่านว่ามันทำอะไร:

1. มันรายการ 200 ไฟล์ในโค้ด ไม่ใช่ในหัวของ model
2. มันรัน 16 subagents ในครั้งเดียว แต่ละตัวย้ายหนึ่งไฟล์และรัน tests
3. มันบันทึกผ่านหรือไม่ผ่านต่อไฟล์ใน array ธรรมดา
4. มันคืนสรุปสั้นหนึ่งอัน transcripts ระหว่างกลาง 200 อันไม่เคยแตะบริบทของคุณ

นั่นคือประเด็นทั้งหมด Model คิดครั้งเดียว เพื่อเขียน script Script ทำการประสานงาน ฟรี

Guardrails: สิ่งที่ป้องกัน fleet จากการกินตัวเอง

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

เอาตัวคุณออกทั้งหมดและข้อผิดพลาดเล็กๆ ทบต้นเร็วกว่าที่คุณจะรู้สึก การทำซ้ำที่นี่ abstraction ที่ไม่จำเป็นที่นั่น

วันหนึ่งสถาปัตยกรรมจะไม่โค้งงอ และ tests ของคุณไม่น่าเชื่อถือเพราะ agents ก็เขียนสิ่งเหล่านั้นด้วย

Guardrails แต่ละอันด้านล่างแทนที่การแก้ไขที่คอขวดเคยให้:

1. อ่านก่อนเดา ทำให้เป็นกฎถาวรในทุก build prompt ไม่ใช่คำขอต่อ task
2. จำกัดและปิด ทุกลูปได้รับขีดจำกัด iteration ทุก agent ได้รับงบ token ที่หยุดอัตโนมัติใกล้ 85% หลังจากสาม iteration ที่ติดขัดในข้อผิดพลาดเดียวกัน ให้ปิด agent และส่ง task ให้ตัวใหม่
3. หนึ่งไฟล์ หนึ่งเจ้าของ แยกด้วย worktrees อย่าปล่อยให้ agent สองตัวแก้ไขไฟล์เดียวกัน
4. ใส่ภารกิจอีกครั้ง ในการรันยาว โพสต์รายการตรวจสอบเป็นข้อความผู้ใช้ทุกไม่กี่นาทีเพื่อให้ agent ไม่ล่องลอยเมื่อบริบทของมันเต็ม

1while sleep 900; do
2  send gauss "เตือน: ยังทำ task อยู่ไหม? อ่านก่อน รัน tests หลังการเปลี่ยนแปลงแต่ละครั้ง อยู่ในไฟล์ของคุณ"
3done &

จุดที่ลึกที่สุดอยู่ใต้ทั้งหมด:

• การตรวจสอบคือคอขวดตอนนี้ ไม่ใช่การสร้าง
• Agents สร้าง output ที่เป็นไปได้เร็วกว่าที่คุณจะตรวจสอบได้
• เป็นไปได้ไม่ใช่ถูกต้อง

จนกว่าการตรวจสอบของคุณจะเร็วเท่ากับการสร้าง การตรวจสอบของมนุษย์ไม่ใช่ overhead มันคือระบบความปลอดภัย

หน่วยความจำ: คุณคือที่เก็บระยะยาว

Model มีหน่วยความจำระยะสั้น หน้าต่างบริบท และไม่มีอะไรอื่น ทุกสิ่งที่ผ่านหน้าต่างนั้นไปจะหายไปเว้นแต่คุณจะพกมัน

ดังนั้นปฏิบัติต่อตัวคุณเองและไฟล์ที่คุณเก็บเป็นหน่วยความจำระยะยาวสำหรับ agents ที่มีแค่หน่วยความจำระยะสั้น

สองนิสัยสำคัญ

ประการแรก ส่ง state โดยการอ้างอิง ไม่ใช่โดยสรุป

• เมื่อบริบทเต็ม การแก้ไขแบบขี้เกียจคือการสรุปมัน การสรุปสูญเสียข้อมูลและทิ้งรายละเอียดที่คุณจะต้องการในภายหลัง
• แต่ให้ชี้ agents ไปที่ไฟล์ บันทึก task และ output ก่อนหน้าที่พวกเขาสามารถอ่านซ้ำ ไม่มีสิ่งสำคัญถูกทิ้งอย่างเงียบๆ

ประการที่สอง เก็บหน่วยความจำที่ทนทานภายนอก agent:

• ไฟล์ task พร้อมสถานะ
• Log ความคืบหน้าที่รันอยู่
• ประวัติ commit
• ไฟล์บันทึกระยะยาวที่รวบรวมรูปแบบและ gotchas

ออกแบบราวกับว่า agents ของคุณจะรันเป็นวัน เพราะด้วยการบีบอัดที่ดีพวกมันจะทำ

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

Topology: กี่ agents และในรูปร่างไหน

Agents มากขึ้นไม่ใช่ output มากขึ้น เกินจุดหนึ่งมันน้อยลง เพราะการประสานงานไม่ฟรีและมันทบต้นกับทุก agent ที่คุณเพิ่ม

กฎที่สำคัญคือให้จับคู่รูปร่างกับงาน:

• การใช้เหตุผลที่ต่อเนื่องและพึ่งพากันต้องการ agents น้อยลง บางครั้งหนึ่งตัว การแยกห่วงโซ่ความคิดเดียวจะแตกเป็นเสี่ยงๆ การใช้เหตุผลและลดคุณภาพของผลลัพธ์
• งานอิสระและขนานต้องการให้คุณกระจายออก Topology แบน ความเป็นเจ้าของไฟล์ที่สะอาด นั่นคือที่ที่ parallelism ให้ผล
• ทีมที่ประสานงานต้องการ workers สามถึงห้าตัว ต้นทุน token ปรับขนาดโดยประมาณเชิงเส้นกับขนาด ต้นทุนการประสานงานปรับขนาดแย่กว่า Workers ที่โฟกัสสามตัวชนะห้าตัวที่กระจัดกระจาย

แล้วมีใครรันเป็นร้อยได้อย่างไร? ไม่ใช่เป็นการสนทนายักษ์ที่เถียงกับตัวเอง

พวกเขารันพวกมันเป็นความลึกและความเป็นอิสระ:

• Agents สองสามตัวที่คุณพูดด้วยจริงๆ แต่ละตัวมอบหมายลงไปยังงานย่อยที่มีขอบเขตที่ไม่ต้องประสานงาน
• ฝูงของลูปอิสระที่ทำสิ่งของตัวเองและรายงานขึ้นไป

การขยายขนาดมาจากความลึกของการมอบหมายและความเป็นอิสระ ไม่เคยมาจากการทำให้เธรดเดียวกว้างขึ้น

ไฟล์ควบคุม: orchestration.md

คุณอาจมีไฟล์ที่บอก agents วิธีเขียนโค้ดใน repo ของคุณ สไตล์ gotchas สถาปัตยกรรม เก็บไว้

แต่มันตอบคำถามผิดสำหรับ orchestration

ไฟล์ orchestration.md ตอบคำถามที่แตกต่าง งานควรถูกรันที่นี่อย่างไร?

มันคือสัญญาที่มนุษย์เขียนซึ่งครอบคลุม:

• ใช้โหมดไหนสำหรับ task ไหน
• model tier ไหนไปที่ไหน
• guardrails คืออะไร
• เมื่อใดควร escalate ไปยังมนุษย์

ทุก agent อ่านมันที่จุดเริ่มต้นของทุกเซสชันและใช้มันเพื่อเลือกแนวทางของตัวเอง

นี่คือไฟล์ที่มี leverage สูงที่สุดใน repo มันย้ายการตัดสินใจเลือกโหมดออกจากหัวของคุณ ที่ที่คุณทำซ้ำอย่างไม่สม่ำเสมอทุกเซสชัน และเข้าสู่ spec ที่ fleet ติดตาม

เวอร์ชันสั้นมีลักษณะเช่นนี้:

1# orchestration.md วิธีที่งานถูก RUN ที่นี่ คัดสรรโดยมนุษย์ Agents ห้ามแก้ไข
2
3เลือกโหมด:
4- Goal loop (ภายใต้การดูแล): งานคลุมเครือหรือออกแบบ กำหนดการตรวจสอบความสมบูรณ์
5- Validation loop: เกทที่แน่นอน จำกัดรอบและต้นทุนเสมอ
6- Build plus judge: worker สร้าง judge ตระกูลที่แตกต่างอนุมัติ
7- Fleet (สามถึงห้า): งานย่อยที่พึ่งพากัน worktrees ที่แยก การส่งข้อความระหว่าง peer
8- Queue and reset: งาน atomic เล็กๆ จำนวนมาก บริบทสดใหม่แต่ละครั้ง
9- Dynamic workflow: รูปแบบที่รู้จัก เกทที่เป็นวัตถุประสงค์ กว้างและซ้ำ การประสานงานในโค้ด ไม่มีผู้ดูแล
10
11Route models ตาม blast radius:
12- การวางแผนและสถาปัตยกรรม: top tier เสมอ
13- Build, spec รัดกุม: mid tier ขนาน ตรวจสอบด้วย tests
14- Build, spec หลวม: top tier เพราะการเติมช่องว่างคือการใช้เหตุผล
15- ตรวจสอบและ judge: ตระกูลที่แตกต่าง ไม่ใช่ model ของผู้ implement
16- Nav, search, summarize: ถูกที่สุด ปรับ output ที่ mergeable ให้เหมาะสม ไม่ใช่ราคา call
17
18Guardrails:
19- งบประมาณ token ต่อ agent หยุดอัตโนมัติใกล้ 85% ปิดและมอบหมายใหม่หลังจาก 3 ครั้งที่ติดขัด
20- การรันใดที่เกินหนึ่งชั่วโมงต้องการ judge ที่แยกต่างหาก Workers ไม่รายงานตัวเองว่าเสร็จ
21- อ่านโค้ดก่อนตั้งสมมติฐาน วางแผนเป็นลายลักษณ์อักษรก่อนแก้ไขครั้งแรก

สองกฎปกครองไฟล์:

1. เก็บให้สั้น
2. อย่าปล่อยให้ agent เขียนใหม่

คุณค่าคือมนุษย์คัดสรรทุกบรรทัด

สิ่งที่เป็นของคุณ

Orchestration ทำให้ agents เชื่อถือได้ในการดำเนินการ มันไม่เลือกปัญหา และมันไม่รู้ว่าดีมีลักษณะอย่างไร

สามสิ่งอยู่ฝั่งคุณของเส้น ถาวร

ประการแรก มอบหมายงาน ไม่ใช่การตัดสิน:

• ส่งมอบงานที่มีขอบเขตให้ agents พร้อมเกณฑ์ผ่านหรือไม่ผ่านที่ชัดเจน Boilerplate, migrations, test scaffolding และแนวทางที่คุณจะไม่มีเวลาลองด้วยมือ
• เก็บสถาปัตยกรรม การตัดสินใจเกี่ยวกับสิ่งที่ไม่ควรสร้าง และการตรวจสอบบริบทเต็มสำหรับตัวคุณเอง
• Agents ได้ดูดซับมหาสมุทรของสถาปัตยกรรมธรรมดา และพวกมันจะ cargo-cult รูปแบบหนักหน่วงลงในโปรเจกต์ที่ไม่ควรมีมันอย่างมีความสุข การปฏิเสธคือฟีเจอร์ที่พวกมันไม่มี

ประการที่สอง spec ของคุณคือ leverage:

ที่เหลือคือ output Fleet ที่สร้างบน spec ที่ไม่ดีเร่งผลลัพธ์ที่ผิด

Orchestration คือระบบที่เปลี่ยน spec ของคุณเป็นงานจริง

เก็บคอขวดของมนุษย์ไว้ที่ spec ที่รสนิยม และที่สิ่งที่ไม่ควรสร้าง รันส่วนที่เหลือผ่านลูป

ไม่ใช่สำหรับเครื่อง สำหรับคุณ

นี่คือความได้เปรียบทางการแข่งขันของคุณ

Escalate ถึงฉันเมื่อ:

• การ orchestration ล้มเหลว: orchestrator หรือ docks กำลังทำคำขอที่ไม่สามารถทำให้สำเร็จหรือไม่ถูกต้องในทางเทคนิค
• คุณมีความคิดสำหรับฟีเจอร์หรือการปรับปรุง orchestration ที่จะปรับปรุงคุณภาพของ output อย่างมีนัยสำคัญ
• คุณต้องการแนวทางอื่นหรือการระดมสมองสำหรับงานที่กำหนด

เจ้าของ orchestration จะตรวจสอบและปรับระบบ

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

ข้อกำหนดที่คลุมเครือหนึ่งข้อแพร่กระจายผ่านการทำงานพร้อมกันนับสิบครั้ง แต่ละครั้งก็ผิดพลาดไปคนละทิศทาง

สเปกที่แม่นยำจะทวีคูณเป็นการนำไปปฏิบัติที่แม่นยำในทุกที่

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

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

สาม จงลงทุนน้อยกว่าปกติโดยเจตนา:

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

ทีมที่ทำแบบนี้จะทบต้น ทีมที่ไม่ทำจะจ่ายเต็มราคาทุกครั้ง

คุณไม่ได้กำลังเขียนซอฟต์แวร์อีกต่อไป คุณกำลังสร้างโรงงานที่เขียนซอฟต์แวร์นั้น

โรงงานต้องการอินพุตที่แม่นยำ การควบคุมคุณภาพในทุกสถานี และเจ้าของที่รู้ว่าผลิตภัณฑ์ควรจะเป็นอย่างไร

เริ่มต้นที่นี่

อย่าพยายามรันเอเยนต์เป็นร้อยในวันจันทร์ จงไต่อันดับขึ้นไป:

1. รัน goal loop หนึ่งอันกับงานที่มีเส้นชัยที่ตรวจสอบได้ เรียนรู้ว่ารู้สึกอย่างไรเมื่อเช็คเสร็จสมบูรณ์ที่ดี
2. เพิ่ม judge จากตระกูลโมเดลที่แตกต่างสำหรับอะไรก็ตามที่ใช้เวลามากกว่าหนึ่งชั่วโมง ห้ามรายงานความสำเร็จด้วยตนเอง
3. เขียน orchestration.md ของคุณ บอกให้เอเยนต์ของคุณอ่านก่อน ดูพวกเขาเริ่มเลือกโหมดให้คุณ
4. กระจายงานอย่างระมัดระวัง งานที่ทำคู่ขนานได้หนึ่งงาน ผู้ทำงานสามถึงห้าคน worktrees แยกกัน งบประมาณโทเคน
5. กำหนดเส้นทางโมเดลของคุณ ระดับสูงสุดในการวางแผนและตรวจสอบ ราคาถูกกว่าในงาน build และ grind ที่มีขอบเขต วัดผลลัพธ์ที่สามารถ merge ได้
6. ปล่อยให้มันทำงานโดยไม่ต้องดูแลเมื่อรูปแบบได้รับการตรวจสอบแล้วและตรวจสอบได้อย่างเป็นกลาง ระบาย backlog ข้ามคืน

ระบบจำเป็นต้องถูกต้องในทิศทางเท่านั้น ไม่ต้องสมบูรณ์แบบ:

• ไฟล์ควบคุมให้โครงสร้างที่เพียงพอแก่ฝูงเพื่อชี้นำตนเอง
• judge จับ edge cases
• reminder loop จัดการหน่วยความจำ
• รสนิยมของคุณจัดการกับการตัดสินใจที่ไม่สามารถมอบหมายได้

การเขียน prompt เป็นทักษะของปีที่แล้ว นี่คือทักษะในตอนนี้

เวอร์ชันที่รันได้ของทุกระบบในนี้ goal loop, judge loop, fleet launcher, message bus, reminder watchdog และ model router อยู่ในชุดอุปกรณ์คู่ใจ ตั้งค่าตัวแปรหนึ่งตัวไปยัง agent CLI ของคุณแล้วเริ่มได้เลย

ข้อจำกัดความรับผิดชอบ

บทความนี้เขียนโดยใช้ Claude Code sessions และ codex sessions ของผู้เขียน

แก้ไขโดยผู้เขียนและโมเดล Kimi K2.6 ในประเด็นด้านไวยากรณ์และการจัดรูปแบบ