Coding Agent ตัวไหนเหมาะกับงานนี้

สรุปสั้น: การจัดเส้นทางงาน (routing) คือการตัดสินว่าตัวแทนเขียนโค้ด (coding agent) ตัวไหนควรรับงานชิ้นใด ให้จัดเส้นทางตามคุณสมบัติของงาน ไม่ใช่ตามอันดับจากสัปดาห์ที่แล้ว: งานนั้นแก้อะไร ย้อนกลับได้แค่ไหน ทับซ้อนไฟล์ที่ตัวแทนอื่นกำลังแก้อยู่หรือไม่ ต้องทำงานอัตโนมัตินานขนาดไหน และแพ็กเกจ subscription ไหนรองรับงานนี้ จากนั้นจึงจับคู่กับตัวแทนที่มีพฤติกรรมบนโค้ดเบสของคุณเหมาะสมที่สุด วิธีนี้ใช้ได้ในหัวของคุณเมื่อมีตัวแทนหนึ่งหรือสองตัว แต่พอเกินสามตัว การตัดสินใจจัดเส้นทางต้องมีที่เก็บร่วมกัน คู่มือนี้ให้ทั้งกฎและเช็กลิสต์แก่คุณ

คุณมี Claude Code ในเทอร์มินัลหนึ่ง Codex ในอีกอัน บางทีก็มี Gemini CLI ในอันที่สาม งานหนึ่งหลั่งไหลเข้ามา: แก้เทสต์ที่ล้มเหลวไม่แน่นอน เพิ่ม endpoint รีแฟกเตอร์โมดูลที่ไฟล์อื่นอีกสามไฟล์ import อยู่ ตัวแทนตัวไหนควรได้งานนี้? พวกเราส่วนใหญ่ตอบตามความเคยชิน หรือตามหน้าต่างที่โฟกัสอยู่แล้ว วิธีนั้นใช้ได้จนกระทั่งคุณจำไม่ได้ว่ามอบงาน migration ให้ตัวแทนตัวไหน หรือมีสองตัวแก้ไฟล์เดียวกัน

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

Sharkly ถูกสร้างขึ้นโดยยึดการตัดสินใจนี้เป็นศูนย์กลาง Sharkly เป็นแพลตฟอร์มสั่งการและจัดการ Agent แบบครบวงจร: คุณเชื่อมต่อ Computer ของคุณเอง นิยาม Agent ไว้ครั้งเดียวเป็นบทบาทที่ผูกกับ runtime แล้วมอบหมาย Task ให้มัน Sharkly วางตัวอยู่เหนือตัวแทนเขียนโค้ดที่คุณใช้อยู่แล้ว ไม่ใช่เคียงข้างมัน บทความนี้จะพาคุณสำรวจวิธีจัดเส้นทางงานอย่างมีประสิทธิภาพ เริ่มจากกฎที่คุณใช้ด้วยมือ แล้วไปจนถึงจุดที่การตัดสินใจจัดเส้นทางต้องมีที่เก็บร่วมกัน

การจัดเส้นทางคือการตัดสินใจ ไม่ใช่ความชอบ

เริ่มจากนิยามที่ชัดเจน การจัดเส้นทางคือการจับคู่งานกับตัวแทนที่ควรลงมือทำงานนั้น มันไม่เหมือนกับการเลือกตัวแทนที่คุณชอบ และไม่เหมือนกับการเลือกโมเดล โมเดลไหนเหมาะกับงานเขียนโค้ดแบบไหน เป็นคำถามแยกต่างหากที่แคบกว่า และอยู่ต่ำลงไปหนึ่งชั้น ในที่นี้เรากำลังตัดสินว่าตัวแทนตัวไหน (Claude Code, Codex, Gemini CLI, OpenCode และอื่น ๆ) ควรได้รับงานนั้น

งานแต่ละชิ้นมีคุณสมบัติที่กำหนดเส้นทางของมันก่อนที่ความสามารถจะเข้ามาเกี่ยวข้อง:

• งานนั้นแก้อะไร การแก้ไฟล์เดียว การรีแฟกเตอร์ที่พาดผ่านหลายส่วน ฟีเจอร์ใหม่ทั้งหมด เทสต์ เอกสาร แต่ละอย่างมีรัศมีผลกระทบ (blast radius) ต่างกัน
• ย้อนกลับได้แค่ไหน การแก้คำผิดและการ migration ฐานข้อมูลต่างก็สร้าง diff ทั้งคู่ แต่มีแค่อย่างเดียวที่จะทำลายบ่ายวันของคุณถ้าตัวแทนทำพลาด
• การทับซ้อนของไฟล์ งานนี้แตะไฟล์ที่ตัวแทนอื่นกำลังแก้อยู่ตอนนี้หรือไม่
• ขอบเขตความเป็นอัตโนมัติ เป็นการแก้แบบโต้ตอบเร็ว ๆ หรือเป็นการรันอัตโนมัติยาวนานที่ต้องวางแผน ลงมือ และตรวจสอบตัวเอง
• เพดานค่าใช้จ่าย subscription หรืองบ API ตัวไหนควรรับผิดชอบงานนี้

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

จัดเส้นทางตามรูปทรงของงาน ก่อนจัดเส้นทางตามความสามารถ

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

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

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

ข้อจำกัดที่ตัดสินการจัดเส้นทางก่อนความสามารถ

มีข้อจำกัดสองข้อที่เอาชนะความสามารถได้ทุกครั้ง และทั้งคู่เกี่ยวกับการประสานงาน ไม่ใช่ทักษะ

ข้อแรกคือการทับซ้อนของไฟล์ ตัวแทนห้าตัวแก้ repository เดียวกันฟังดูมีประสิทธิภาพ จนกระทั่งสองตัวแตะไฟล์เดียวกันแล้วคุณต้องแก้ merge conflict ที่คุณสร้างขึ้นเองโดยตั้งใจ ทางแก้คือการแยกส่วน: ให้แต่ละงานมี checkout ของตัวเองเพื่อให้ตัวแทนชนกันไม่ได้ worktree ของตัวแทนเขียนโค้ด หนึ่ง checkout ต่อหนึ่งงาน อธิบายกลไก และ การรันตัวแทนหลายตัวใน repository เดียว อธิบายว่าอะไรจะพังถ้าไม่มีมัน เมื่อสองงานแตะไฟล์เดียวกัน เส้นทางไม่ใช่ "ตัวแทนที่ดีกว่า" แต่เป็น "ตัวแทนตัวไหนก็ได้ ใน worktree แยกต่างหาก"

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

จุดที่การจัดเส้นทางในหัวของคุณขยายไม่ได้อีกต่อไป

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

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

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

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

เช็กลิสต์การจัดเส้นทางที่คุณใช้ได้ตั้งแต่วันนี้

ก่อนที่คุณจะมอบงานให้ตัวแทน ลองไล่ผ่านรายการเหล่านี้:

1. ระบุรูปทรงของงาน แก้ไฟล์เดียว รีแฟกเตอร์ ฟีเจอร์ใหม่ เทสต์ หรือเอกสาร? สิ่งนี้กำหนดรัศมีผลกระทบ
2. ตรวจความสามารถในการย้อนกลับ ย้อนกลับยากไหม? จัดเส้นทางไปที่การตรวจสอบที่แน่นหนาที่สุดและสิทธิ์ที่แคบที่สุด ไม่ใช่ตัวแทนที่เร็วที่สุด
3. ตรวจการทับซ้อนของไฟล์ มีตัวแทนอื่นอยู่ในไฟล์เหล่านี้แล้วหรือยัง? ถ้ามี ให้แยกงานนี้ไว้ใน worktree ของตัวเองก่อน
4. จับคู่ขอบเขตความเป็นอัตโนมัติ สั้นและมีคนดู หรือยาวและไม่มีคนคอย? จัดเส้นทางไปยังตัวแทนที่พฤติกรรมบน repo ของคุณพอดี
5. ตั้งเพดานค่าใช้จ่าย ตัดสินว่า subscription หรืองบประมาณตัวไหนรับผิดชอบการรันนี้
6. บันทึกเส้นทางไว้ที่ที่แชร์ร่วมกัน พอเกินสองตัว ให้เขียนมันไว้ในที่ที่คุณและทีมมองเห็น: เป็น Task ไม่ใช่เทอร์มินัลที่คุณจะปิดในไม่ช้า
7. ส่งผลลัพธ์กลับไปที่เดียว diff ผลเทสต์ และการตรวจสอบควรกลับไปที่บันทึกงาน ไม่ใช่กระจัดกระจายไปทั่วหน้าต่าง

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

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

คำถามที่พบบ่อย

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

สิ่งนี้ต่างจากการเลือกโมเดลอย่างไร? การเลือกโมเดลเกิดขึ้นต่ำลงไปหนึ่งชั้น ภายในตัวแทน การจัดเส้นทางตัดสินว่าตัวแทนตัวไหนได้งาน ส่วนคำถามเรื่องโมเดลตัดสินว่าอะไรจะรันอยู่ภายในเซสชันของตัวแทนนั้น ดูโมเดลไหนเหมาะกับงานเขียนโค้ดแบบไหนสำหรับการตัดสินใจที่แคบกว่านี้

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

Sharkly มาแทน Claude Code หรือ Codex ไหม? ไม่ Sharkly ไม่ใช่ตัวแทนที่มาแทน Claude Code, Codex หรือเครื่องมือสำหรับลงมือทำงานอื่น ๆ แต่เพิ่มชั้นของงานที่แชร์ร่วมกัน, Computer, บริบทรอบข้าง และการตรวจสอบให้กับตัวแทนเขียนโค้ดที่ทีมของคุณใช้อยู่แล้ว