เวิร์กโฟลว์แบบ Multi-agent ส่วนใหญ่ไม่ได้ล้มเหลวตรงส่วนที่ยาก เพราะ Agent สามารถเขียนโค้ด รันเทสต์ และเปิด pull request ได้อย่างราบรื่น แต่จุดที่มักเกิดปัญหาคือ "รอยต่อ" ซึ่งเป็นจังหวะที่งานออกจาก Agent ตัวหนึ่งและควรจะถูกส่งต่อไปยังอีกที่หนึ่ง ตัวอย่างเช่น backend Agent สร้าง endpoint เสร็จแล้ว แต่ frontend Agent กลับไม่เคยรู้เลยว่าพร้อมใช้งาน หรือโค้ดที่ refactor เสร็จถูกวางไว้ใน worktree และผ่านฉลุย (green) แต่ก็ค้างอยู่อย่างนั้นเพราะไม่มีใครแจ้งให้คนมาตรวจสอบ ตัวงานไม่ได้พัง แต่พังที่กระบวนการส่งต่องาน (handoff) ต่างหาก
AI agent handoff คือการส่งมอบชิ้นงานพร้อมบริบท (context) จากผู้ปฏิบัติงานคนหนึ่งไปยังอีกคนหนึ่ง ไม่ว่าจะเป็นจาก Agent สู่ Agent หรือจาก Agent สู่มนุษย์ เมื่อคุณรัน coding agent ตัวเดียวในเทอร์มินัลเดียว คุณอาจมองไม่เห็นกระบวนการ handoff เพราะมันไม่จำเป็นต้องมี แต่ทันทีที่คุณเริ่มใช้งาน Agent สองตัว หรือมี Agent หนึ่งตัวทำงานร่วมกับผู้ตรวจทาน (reviewer) หนึ่งคน ทุกขั้นตอนที่ทำเสร็จแล้วจะต้องถูกนำไปวางไว้ที่ใดสักแห่งที่ผู้รับช่วงต่อจะมองเห็นและหยิบไปทำต่อได้ ซึ่งจุดส่งมอบงานนี้นี่เองที่เป็นตัวชี้วัดความสำเร็จทั้งหมด
บทความนี้จะพาคุณไปสำรวจรูปแบบการ handoff ที่ใช้งานได้จริงในทางปฏิบัติ โดยใช้ Sharkly เป็นเวิร์กโฟลว์ ซึ่งทำหน้าที่เป็นเลเยอร์ที่อยู่เหนือ coding agent ของคุณ คอยควบคุมให้บริบท, ความคืบหน้า, ปัญหาที่ติดขัด (blockers), ผลลัพธ์ และการตรวจสอบโดยมนุษย์ สามารถมองเห็นได้อย่างชัดเจนตั้งแต่เริ่มคำขอไปจนถึงการ release คุณอาจมี coding agent ใช้งานอยู่แล้ว แต่สิ่งที่จะมาแก้ปัญหาในบทความนี้คือ สิ่งที่เกิดขึ้นใน "ช่องว่าง" ระหว่าง Agent เหล่านั้น
สรุปสั้น ๆ
Handoff คือจุดที่ชิ้นงานและบริบทถูกส่งต่อจากผู้ทำงานหนึ่งไปยังอีกผู้ทำงานหนึ่ง การ handoff ระหว่าง Agent กับ Agent จะส่งมอบ sub-task ที่เสร็จแล้วให้กับ Agent ตัวถัดไป ส่วนการ handoff จาก Agent สู่มนุษย์จะหยุดการทำงานอัตโนมัติไว้ที่จุดตรวจทาน (review gate) กำหนดทั้งสองรูปแบบให้ชัดเจนผ่านสถานะ: Agent จะเปลี่ยนสถานะ Task เป็น Ready for review ส่วนคนจะเป็นผู้เปลี่ยนเป็น Done เมื่อการ handoff เกิดขึ้นผ่านการเปลี่ยนสถานะบน Task ที่แชร์ร่วมกันแทนที่จะเป็นข้อความในเทอร์มินัล ก็จะไม่มีงานชิ้นไหนตกหล่นไปอย่างเงียบ ๆ อีกต่อไป
ทำความเข้าใจให้ชัดเจน: Agent handoff คืออะไรกันแน่
การ handoff ประกอบด้วย 3 องค์ประกอบหลัก ซึ่งหากขาดส่วนใดส่วนหนึ่งไป งานก็จะสูญหายได้ทันที: ชิ้นงานหรือ artifact (เช่น diff, PR, migration), บริบทหรือ context (โจทย์คืออะไร, มีการเปลี่ยนแปลงอะไรไปบ้าง, มีส่วนไหนที่ยังไม่แน่ชัด) และผู้รับมอบงาน (Agent หรือบุคคลที่รับผิดชอบขั้นตอนถัดไป)
เวิร์กโฟลว์ที่ทำงานผ่านเทอร์มินัลมักจะส่งต่อได้เพียงตัว artifact แต่ทำองค์ประกอบอีกสองส่วนหล่นหาย ตัว commit ยังคงอยู่ แต่เหตุผลและที่มาที่ไปกลับฝังอยู่ใน scrollback buffer ที่มีเพียง Agent ตัวเดียวเท่านั้นที่เห็น ส่วน "ใครจะทำต่อ" ก็ขึ้นอยู่กับว่าใครจะบังเอิญเข้ามาเช็ก นี่คือเหตุผลที่การทำ orchestrating agents ไม่ได้เน้นแค่การสั่งรัน Agent เท่ากับการกำหนดเส้นทางส่งต่อผลงานที่พวกมันสร้างขึ้นมา
การ handoff ที่สมบูรณ์แบบจะต้องส่งต่อทั้ง 3 สิ่งไปพร้อมกัน: สิ่งที่เปลี่ยนแปลง, สรุปสิ่งที่ทำไปแล้วและสิ่งที่ยังไม่ได้ทำ รวมถึงสัญญาณที่ชัดเจนว่าถึงคิวของผู้รับมอบงานแล้ว หากเปรียบในระบบของ Sharkly ข้อมูลทั้งการประมวลผล, ปัญหาที่ติดขัด, ผลลัพธ์ และการพูดคุยติดตามผล จะถูกบันทึกกลับเข้ามาที่ Task timeline ทำให้ผู้รับงานคนถัดไปสามารถอ่านบันทึกชุดเดียวได้ครบ โดยไม่ต้องไปปะติดปะต่อข้อมูลจากสามแหล่ง
รูปแบบการ Handoff สองประเภท
ทั้งสองรูปแบบดูคล้ายกันแต่มีการตั้งค่าเริ่มต้นที่ตรงกันข้าม การ handoff แบบ Agent สู่ Agent ควรดำเนินไปอย่างราบรื่นโดยอัตโนมัติ: Agent ตัวถัดไปจะดึง sub-task ที่พร้อมแล้วไปทำต่อทันที ในทางกลับกัน การ handoff แบบ Agent สู่มนุษย์ควรจะหยุดการทำงานโดยเริ่มต้น: เมื่อ Agent ทำงานในส่วนของตัวเองเสร็จแล้วจะต้องหยุดรอ เพื่อให้มนุษย์เป็นผู้ตัดสินใจ
| Agent-to-agent | Agent-to-human | |
|---|---|---|
| Trigger | มี sub-task ที่ถูกระบุว่าพร้อมทำงาน | งานดำเนินมาถึงจุดตรวจทาน (review gate) |
| Default | ดำเนินการต่อโดยอัตโนมัติ | หยุดและรอ |
| Carries | Artifact + บริบท + เกณฑ์การยอมรับ (acceptance criteria) | Diff + สรุปการเปลี่ยนแปลง + ข้อจำกัดที่ทราบ |
| Risk if missing | งานซ้ำซ้อนหรือขัดแย้งกันเอง | โค้ดที่ยังไม่ผ่านการรีวิวถูก merge เข้าไปโดยไม่รู้ตัว |
นี่คือหลักเกณฑ์การตัดสินใจคู่ขนานที่ช่วยให้คุณวางระบบได้อย่างถูกต้อง: ให้ทำระบบอัตโนมัติสำหรับการ handoff แบบ Agent สู่ Agent เมื่อขั้นตอนถัดไปมีความชัดเจนและมีการระบุเกณฑ์การยอมรับ (acceptance criteria) ไว้อย่างครบถ้วนแล้ว เช่น "รันชุดการทดสอบ (test suite)", "สร้าง migration", "อัปเดตสเปก OpenAPI" และให้บังคับใช้การ handoff แบบ Agent สู่มนุษย์ เมื่อขั้นตอนถัดไปจำเป็นต้องอาศัยการตัดสินใจเชิงวิจารณญาณที่ Agent ไม่สามารถรับผิดชอบได้ เช่น การ merge เข้า main, การแก้ไข public contract, การแตะส่วน auth หรือระบบคิดเงิน (billing) รวมถึงการอนุมัติรับรองผลงานว่าเสร็จสมบูรณ์
ข้อผิดพลาดที่พบบ่อยคือการจัดการ handoff ทุกประเภทด้วยวิธีเดียวกัน หากปล่อยให้ทุกอย่างทำงานอัตโนมัติทั้งหมด คุณอาจเผลอ merge โค้ดที่ยังไม่ผ่านการรีวิวเข้ามา แต่ถ้ากั้นทุกขั้นตอนด้วยการตรวจทาน คุณก็แค่สร้างไปป์ไลน์แบบแมนนวลที่เชื่องช้าและมีขั้นตอนหยุมหยิมขึ้นมาใหม่ ซึ่งเรื่องนี้เชื่อมโยงกับการทำความเข้าใจว่า ควรตั้งจุดอนุมัติ (approval gates) ไว้ที่ใด เพื่อให้ Agent หยุดก่อนที่จะเกิดความผิดพลาดที่มีราคาสูง ไม่ใช่หยุดถามทุกครั้งกับเรื่องเล็กน้อยที่ไม่สำคัญ
ใช้สถานะเปลี่ยนการ Handoff ให้เป็นด่านตรวจ ไม่ใช่แค่ความหวังลม ๆ แล้ง ๆ
โมเดลการทำงานนี้สรุปได้ด้วยคำกริยา 4 คำและผู้รับผิดชอบในแต่ละส่วน ได้แก่ ใครเป็นผู้มอบหมาย (assign), ใครเป็นผู้ลงมือทำ (run), ใครเป็นผู้ตรวจทาน (review) และใครเป็นผู้อนุมัติ (accept) โดย Agent จะทำหน้าที่ค้นคว้าข้อมูล, ลงมือทำ, รันการทดสอบ และรายงานผล ส่วนมนุษย์จะกำหนดทิศทาง, มอบหมายสิทธิ์ และตรวจรับผลงาน ระบบอัตโนมัติจะหยุดลงในจุดที่ต้องอาศัยการตัดสินใจของทีม
สถานะคือสิ่งที่จะเปลี่ยนข้อตกลงนี้ให้เป็นกลไกที่ทำงานได้จริง ไม่ใช่แค่ความตั้งใจลอย ๆ ทุก Task จะเคลื่อนผ่านกระบวนการเดียวกันดังนี้:
- Todo: มอบหมายแล้ว แต่ยังไม่เริ่มทำ โดยมีบุคคลหรือ Leader Agent เป็นผู้นำงานมาใส่ไว้ในสถานะนี้
- In progress: Agent ดึงงานไปทำแล้ว และกำลังทำงานอยู่ใน worktree ที่แยกส่วน (isolated worktree)
- Ready for review: ขอบเขตสิ้นสุดของ Agent โดย Agent ได้รัน typecheck, รันเทสต์ และ build เรียบร้อยแล้ว พร้อมแนบสรุปการเปลี่ยนแปลงและข้อจำกัดที่พบ แล้วจึงหยุดการทำงาน
- Done: ขอบเขตการทำงานของมนุษย์ โดยมีผู้ตรวจสอบยอมรับผลงาน และทำการตัดสินใจ merge และ release
กฎสำคัญที่ทำให้ภาพรวมทั้งหมดชัดเจนและตรวจสอบได้ง่ายคือ: Agent จะเปลี่ยนสถานะ Task ไปเป็น Ready for review และคนจะเป็นผู้เปลี่ยนเป็น Done Agent จะไม่มีวันทำเครื่องหมายว่างานของตนเอง Done เด็ดขาด และคนก็ไม่จำเป็นต้องมานั่งเดาว่า Task ที่ขึ้นสีเขียวนั้นปลอดภัยพร้อมใช้งานหรือไม่ สถานะนี่แหละคือหัวใจของการ handoff เมื่อคุณรัน Agent พร้อมกัน 10 ตัว คุณไม่ต้องคอยไล่ดูทีละ 10 เทอร์มินัล แต่สามารถดูจากกระดานงานและเห็นได้ทันทีว่างานไหนกำลังรอคุณตรวจ, งานไหนกำลังรอ Agent ตัวอื่น หรืออันไหนที่ยังอยู่ระหว่างดำเนินการ ความโปร่งใสในการมองเห็นนี้คือความแตกต่างระหว่างการติดตามผลงานที่ Agent ทำเสร็จจริง กับการได้แต่นั่งภาวนาให้ commit log บอกเล่าสิ่งที่เกิดขึ้นในภายหลัง
ตัวอย่างการใช้งานจริง: จาก Ticket สู่ Merged PR
ลองดูตัวอย่าง Task ที่เกิดขึ้นจริงอย่าง SH-312: "เพิ่ม rate limiting ให้กับ public API" โดยให้โฟกัสที่การ handoff ไม่ใช่ตัวโค้ด
เริ่มต้นจากคนอธิบายความต้องการเป็นภาษาธรรมชาติแล้วทำการมอบหมายงาน จากนั้น Leader Agent จะค้นคว้าฐานโค้ดและประวัติ Task เก่า ๆ เพื่อกำหนดขอบเขตและเกณฑ์การยอมรับ (เช่น จำกัดจำนวนครั้งต่อ API key, ส่งกลับสถานะ 429 พร้อม header Retry-After, ครอบคลุม 3 endpoint ที่มีการเรียกใช้งานสูงสุด) แล้วจึงแตกงาน SH-312 ออกเป็น 3 sub-tasks ที่พร้อมนำไปลงมือทำ นี่คือการ handoff ระหว่าง Agent กับ Agent ครั้งแรก: รับเป้าหมายเข้ามา แล้วส่ง sub-tasks ที่พร้อมทำออกไป
Sub-tasks จะถูกส่งต่ออย่างเป็นอัตโนมัติ โดย backend Agent จะดึงงานเขียนลอจิกตัวจำกัดอัตรา (limiter) ไปทำ ส่วน test Agent จะรับหน้าที่เขียนเทสต์ให้ครอบคลุม และเนื่องจากแต่ละตัวทำงานอยู่ใน isolated worktree พวกมันจึงไม่แก้ไขไฟล์ชนกัน และผลลัพธ์ของแต่ละตัวจะถูกส่งกลับมาที่ SH-312 แทนที่จะหายไปในเซสชันส่วนตัว เมื่อ backend Agent ทำงานเสร็จ มันจะไม่ส่งข้อความมารบกวนมนุษย์ แต่จะทำเครื่องหมายว่า sub-task ของมันพร้อมแล้ว และ test Agent ก็จะนำโค้ดที่ทำเสร็จจริงไปใช้ทดสอบแทนที่จะใช้ stub ชั่วคราว
จากนั้น รูปแบบการ handoff จะสลับประเภท เมื่อสร้าง limiter เสร็จเรียบร้อย, ผ่าน typecheck, การทดสอบผ่านทั้งหมด และ build ผ่านฉลุย งานก็จะเข้าสู่จุดตรวจทานจาก Agent สู่มนุษย์ โดย Agent จะย้าย SH-312 ไปที่สถานะ Ready for review พร้อมแนบ diff, สรุปการเปลี่ยนแปลง และข้อจำกัดที่พบไว้หนึ่งข้อ: "ตัวนับที่ใช้ Redis สมมติว่าทำงานบนภูมิภาคเดียว (single region) หากต้องการรองรับแบบหลายภูมิภาค (multi-region) จำเป็นต้องมีงานติดตามผลเพิ่มเติม" คนจะอ่านข้อมูลทั้งหมดนี้ได้จากที่เดียว ตรวจสอบพฤติกรรมการตอบกลับ 429 แล้วจึงเลื่อนสถานะเป็น Done ซึ่งจะเป็นการสั่ง merge โดยอัตโนมัติ ตั้งแต่การเปิด Ticket ไปจนถึงการ merge PR จะมีบันทึกชัดเจนว่าใครทำอะไรที่รอยต่อจุดไหนบ้าง นี่คือรูปแบบเดียวกับการสืบย้อนเส้นทางตั้งแต่ความต้องการไปจนถึงโค้ด (requirements-to-code) แบบครบวงจรตั้งแต่ต้นจนจบ
จุดที่การ Handoff มักพัง และวิธีควบคุมให้อยู่หมัด
การ handoff มักจะล้มเหลวด้วยสาเหตุ 3 ประการที่คาดเดาได้ และแต่ละปัญหามีวิธีแก้ไขเชิงโครงสร้างที่ชัดเจน มากกว่าที่จะใช้แค่การ "พยายามจำเอาเอง"
บริบทเลือนหาย (Context evaporates): Agent รู้ว่าทำไมถึงตัดสินใจเลือกแนวทางนั้น แต่ผู้ตรวจทานไม่รู้ วิธีแก้: การ handoff ต้องพ่วงสรุปการเปลี่ยนแปลงและข้อจำกัดที่พบส่งต่อไปพร้อมกับการเลื่อนสถานะเป็น Ready for review ทันที ไม่ใช่มานึกสรุปทีหลัง ขาดความชัดเจนเรื่องผู้รับผิดชอบ (Ownership blurs): เกิดกรณี Agent สองตัวแย่งกันทำงานชิ้นเดียวกัน หรือไม่มีใครหยิบไปทำเลย วิธีแก้: กำหนด Assignee ในทุก Task และ sub-task เพื่อให้ "ถึงตาคุณแล้ว" เป็นฟิลด์ข้อมูลที่ระบุชัดเจน ไม่ใช่การเดาเอาเองจากความรู้สึก ไม่เคยมีการตรวจทานโค้ด (Review never happens): งานที่ทำแบบอัตโนมัติถูก merge เข้าไปเพราะไม่มีใครบอกให้หยุดตรวจ วิธีแก้: สร้างสถานะที่ Agent ไม่สามารถข้ามผ่านไปได้ด้วยตัวเอง
คุณสามารถสร้างระบบทั้งหมดนี้ขึ้นมาเองได้โดยใช้ worktrees, ข้อตกลงการตั้งชื่อ (naming convention) และวินัยในการทำงาน ซึ่งอาจจะได้ผลดีจนกระทั่งจำนวน Agent, Task และ repository เริ่มเพิ่มสูงขึ้น แล้ววินัยก็จะเป็นสิ่งแรกที่หายไป หากคุณใช้งาน Agent หลายตัวอยู่แล้ว Sharkly จะมอบศูนย์กลางเพียงหนึ่งเดียวในการจัดการงานและผลลัพธ์ของพวกมัน: มี Task ที่แชร์ร่วมกัน, การกำหนด Assignee ราย Task, worktree ที่แยกจากกันอย่างเป็นสัดส่วน และแถบสถานะที่ Agent ทำได้ถึงแค่ Ready for review และให้มนุษย์เป็นผู้ตัดสินใจเลื่อนเป็น Done คุณยังคงใช้ coding agent ตัวเดิมที่มีอยู่ได้ เพียงแค่เพิ่มเลเยอร์ที่ทำให้มองเห็นกระบวนการ handoff ได้อย่างโปร่งใส ดาวน์โหลด Sharkly เมื่อรอยต่อระหว่าง Agent ของคุณเริ่มสร้างต้นทุนและความเสียหายมากกว่าตัวเนื้องานจริง
คำถามที่พบบ่อย (FAQ)
AI agent handoff คืออะไร? คือการส่งต่องาน พร้อมด้วยบริบทที่เกี่ยวข้องและสัญญาณแจ้งเตือนว่าถึงคิวของอีกฝ่ายแล้ว จากผู้ทำงานคนหนึ่งไปยังคนถัดไป โดยแบ่งออกเป็นสองรูปแบบคือ การส่งต่อระหว่าง Agent กับ Agent (sub-task ที่ทำเสร็จแล้วจะถูกส่งต่อไปยัง Agent ตัวถัดไป) และการส่งต่อจาก Agent สู่มนุษย์ (การทำงานอัตโนมัติจะหยุดลงที่จุดตรวจทานหรือ review gate)
การ handoff ระหว่าง Agent กับ Agent แตกต่างจากการ handoff จาก Agent สู่มนุษย์อย่างไร? การ handoff ระหว่าง Agent กับ Agent ควรทำงานต่อโดยอัตโนมัติเมื่อขั้นตอนถัดไปมีการกำหนดเกณฑ์การยอมรับ (acceptance criteria) ไว้อย่างชัดเจนแล้ว ส่วนการ handoff จาก Agent สู่มนุษย์ควรจะต้องหยุดและรอ เพราะต้องอาศัยการตัดสินใจโดยมนุษย์ เช่น การ merge, การปรับเปลี่ยน public contract หรือการตรวจรับผลงาน
Agent ควรทำเครื่องหมายว่างานของตนเสร็จสมบูรณ์ (Done) เองหรือไม่? ไม่ควร ให้ Agent เปลี่ยนสถานะ Task ได้แค่ Ready for review หลังจากที่รันเทสต์และแนบสรุปผลแล้ว และปล่อยให้การเปลี่ยนเป็น Done ตลอดจนการตัดสินใจ merge เป็นหน้าที่ของมนุษย์ การแยกสองขอบเขตนี้ออกจากกันคือสิ่งที่จะป้องกันไม่ให้โค้ดที่ยังไม่ผ่านการตรวจทานถูกนำไป release ศึกษารายละเอียดเพิ่มเติมได้ที่ human-in-the-loop coding agents
การใช้สถานะช่วยป้องกันไม่ให้งานตกหล่นได้อย่างไร? เมื่อการ handoff อยู่ในรูปของการเปลี่ยนสถานะบน Task ที่แชร์ร่วมกัน แทนที่จะเป็นการส่งข้อความในเทอร์มินัล ผู้รับงานคนถัดไปจะเห็นได้อย่างชัดเจนว่ามีอะไรกำลังรอพวกเขาอยู่ โดยไม่ต้องพึ่งพาให้ใครสักคนคอยจ้อง scrollback ให้ถูกจังหวะเวลา นอกจากนี้ agent Inbox ยังช่วยดึงรายการที่ต้องการคุณขึ้นมาแสดงให้เห็นทันที
จำเป็นต้องใช้เครื่องมือช่วยหรือไม่ หรือสามารถทำเองแบบแมนนวลได้? คุณสามารถจัดการด้วยตัวเองได้โดยใช้ worktrees และกระดานบอร์ดที่แชร์ร่วมกัน แต่การใช้เลเยอร์เฉพาะทางจะเริ่มคุ้มค่าอย่างยิ่งเมื่อคุณต้องประสานงาน Agent หลายตัวข้ามหลาย repository และการติดตามงานแบบแมนนวลเริ่มกลายเป็นคอขวด ลองเปรียบเทียบจากบทความ กรอบความคิดแบบผู้ช่วยเทียบกับเพื่อนร่วมทีม (assistant-versus-teammate mental model) เพื่อช่วยในการตัดสินใจ
