มนุษย์เป็นเจ้าของงานที่ Agent ทำ: โมเดลการดำเนินงาน

coding agent เปลี่ยน ticket ให้กลายเป็น pull request ได้ระหว่างที่คุณไปชงกาแฟ ความเร็วขนาดนั้นสร้างคำถามที่เงียบกว่าเดิมขึ้นมา ซึ่งเครื่องมือไม่เคยตอบให้คุณได้: เมื่อ diff ถูกสร้างเสร็จแล้ว ใครเป็นเจ้าของมัน? ไม่ใช่คนที่พิมพ์ เพราะเอเจนต์เป็นคนพิมพ์ ใครต้องรับผิดชอบว่ามันจะถูกปล่อยออกไปหรือไม่ มันเป็นการเปลี่ยนแปลงที่ถูกต้องหรือเปล่า และจะเกิดอะไรขึ้นถ้ามันพังตอนตีสอง การลงมือทำย้ายไปอยู่กับเอเจนต์แล้ว แต่ความเป็นเจ้าของไม่ได้ย้ายตามไปด้วย และย้ายตามไปไม่ได้

ความคลุมเครือจะยิ่งแย่ลงทันทีที่คุณรันเอเจนต์มากกว่าหนึ่งตัว มอบบั๊กหนึ่งตัวให้ Claude Code อีกตัวให้ Codex ตอนนี้คุณมีสองแบรนช์ มีสรุปสองฉบับ และไม่มีคำตอบร่วมกันสำหรับคำถามง่าย ๆ ข้อเดียวว่า ใครมีชื่ออยู่บนงานแต่ละชิ้นเมื่อมันถูก merge เข้าไป ความเป็นเจ้าของที่อาศัยอยู่ใน scrollback ของ terminal ไม่ใช่ความเป็นเจ้าของ มันเป็นแค่การเดาที่อยู่รอดไปจนถึงคำสั่ง git log ครั้งถัดไป

นี่คือปัญหาที่ Sharkly ถูกสร้างขึ้นมาเพื่อแก้ Sharkly วางตัวอยู่เหนือ coding agent ของคุณในฐานะเลเยอร์ที่บันทึกว่าใครมอบหมายงาน เอเจนต์ตัวไหนรันงาน ใครรีวิวผลลัพธ์ และใครรับงาน บทความนี้จะอธิบายโมเดลการดำเนินงานนั้นในรูปของสี่บทบาทกับชุดสถานะ แล้วพาไปดู ticket หนึ่งใบตั้งแต่การมอบหมายจนถึง PR ที่ merge แล้ว สำหรับกลไกการรีวิวที่รองรับอยู่ข้างใต้นั้น คู่มือของเราเรื่อง human-in-the-loop coding agents ครอบคลุมด่านทั้งห้าที่บังคับใช้การตัดสินใจเหล่านี้

สรุปสั้น ๆ

ความเป็นเจ้าของงานของเอเจนต์โดยมนุษย์ หมายความว่าความรับผิดชอบต่อการเปลี่ยนแปลงหนึ่ง ๆ จะไม่ถูกโอนไปให้เอเจนต์ แม้ว่าการลงมือทำจะถูกโอนไปก็ตาม โมเดลการดำเนินงานมีสี่บทบาท: คนเป็นผู้มอบหมาย เอเจนต์เป็นผู้รัน คนที่มีชื่อระบุไว้เป็นผู้รีวิว และคนคนเดียวกันนั้นเป็นผู้รับงาน เอเจนต์ผลัก Task ไปได้ไกลสุดแค่ Ready for review เท่านั้น มีเพียงคนเท่านั้นที่ย้ายมันไปเป็น Done เอเจนต์ค้นคว้า ลงมือทำ ทดสอบ และรายงาน ส่วนคนเป็นผู้กำหนดทิศทาง ให้อำนาจ และรับผลลัพธ์

ใครเป็นเจ้าของงานที่เอเจนต์สร้างขึ้น

ความเป็นเจ้าของกับการลงมือทำเป็นสองงานที่ต่างกัน และการสับสนระหว่างสองสิ่งนี้คือความผิดพลาดที่เป็นรากของปัญหา การลงมือทำคือการสร้างการเปลี่ยนแปลงขึ้นมา ไม่ว่าจะเป็นการอ่านโค้ดเบส แก้ไขไฟล์ รันเทสต์ หรือเปิด PR เอเจนต์ทำสิ่งนี้ได้ดีและรวดเร็ว ส่วนความเป็นเจ้าของคือการต้องรับผิดชอบต่อผลลัพธ์ ว่าการเปลี่ยนแปลงนั้นคุ้มค่าที่จะทำ ว่ามันผ่านเกณฑ์การยอมรับ และว่ามีคนที่ถูกถามถึงมันได้ในอีกสามเดือน ความรับผิดชอบแบบนั้นยังคงอยู่กับคน เพราะเอเจนต์ไม่อาจถูกเรียกให้อธิบายเหตุผลของการแลกเปลี่ยน (tradeoff) ย้อนหลังได้ และไม่ต้องแบกรับผลที่ตามมา

วิธีอธิบายการแบ่งงานนี้ให้ชัดที่สุดคือสัญญาระหว่างคนกับเอเจนต์: เอเจนต์ค้นคว้า ลงมือทำ ทดสอบ และรายงาน ส่วนคนกำหนดทิศทาง ให้อำนาจ และรับผลลัพธ์ ระบบอัตโนมัติหยุดตรงจุดที่ต้องใช้ดุลยพินิจของทีม ทุกอย่างจนถึงขั้น "รับผลลัพธ์" มอบให้เอเจนต์ได้ แต่ตัวการรับงานเองมอบให้ไม่ได้ เช่นเดียวกับการตัดสินใจว่าจะปล่อยงานออกหรือไม่ บทความของเราเรื่อง AI assistants vs AI teammates ลากเส้นแบ่งเดียวกันนี้จากอีกทิศทางหนึ่ง

โมเดลการดำเนินงาน: Assign, Run, Review, Accept

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

รายละเอียดสำคัญอยู่ที่แถวแรกและแถวสุดท้าย: คนคนเดียวกันเป็นเจ้าของทั้งการมอบหมายและการรับงาน นี่คือวิธีที่วงจรปิดลง ใครก็ตามที่ตัดสินใจว่างานนี้สำคัญ คนนั้นคือคนที่ยืนยันว่ามันทำเสร็จแล้ว Sharkly รองรับสิ่งนี้โดยเก็บช่องมอบหมายไว้สองช่องบน Task พร้อมกัน คือ Assignee ที่เป็นมนุษย์และ assignee ที่เป็นเอเจนต์ ความรับผิดชอบและการลงมือทำจึงถูกบันทึกเป็นข้อเท็จจริงแยกกัน แทนที่จะเป็น "assigned to" กำกวม ๆ ช่องเดียว ส่วนงานเดินทางไปถึงเอเจนต์ได้อย่างไรนั้น ดูคู่มือของเราเรื่อง การมอบหมาย ติดตาม และรีวิวงานของเอเจนต์ในที่เดียว

สถานะและด่านตรวจ: เอเจนต์ไปได้ถึง Ready for review แต่คนเท่านั้นที่ย้ายงานไปเป็น Done

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

มีขอบเขตสองอย่างที่ช่วยปกป้องเรื่องนี้ อย่างแรก เอเจนต์เลือกสถานะที่ Task Workflow ของตัวเองไม่ได้ให้สิทธิ์ไม่ได้ จึงไม่สามารถทำเครื่องหมายว่างานของตัวเองได้รับการยอมรับได้ มันจะปล่อย Task ไว้รอการรีวิวจากมนุษย์ และสัญญาณนั้นจะไปถึง Inbox ของผู้รับผิดชอบ แทนที่จะตกไปอยู่ในช่องทางที่ไม่มีใครอ่าน อย่างที่สอง การ merge pull request ที่เชื่อมไว้ไม่ได้เปลี่ยนสถานะของ Task การ merge เป็นเหตุการณ์ใน Git ไม่ใช่การตัดสินใจรับงาน และ Sharkly แยกสองสิ่งนี้ออกจากกัน เพื่อไม่ให้ "PR ถูก merge แล้ว" ถูกเข้าใจผิดว่าเป็น "มีคนตัดสินแล้วว่านี่ถูกต้อง" ถ้าคุณกังวลเรื่องกำลังคนสำหรับการรีวิว บทวิเคราะห์ของเราเรื่อง ทำไมการรีวิวโดยมนุษย์ถึงเป็นคอขวดตัวจริง อธิบายวิธีออกแบบรองรับเรื่องนี้ไว้

จาก ticket สู่ PR ที่ merge แล้ว: ตัวอย่างจริงหนึ่งเคส

นี่คือโมเดลที่ทำงานครบวงจรบน Task เดียว คือ SH-312 "Add rate limiting to the public search endpoint"

1. Assign. วิศวกรคนหนึ่งเขียน Task ระบุ endpoint ลิมิตเป้าหมาย และเกณฑ์การยอมรับ (ตอบ 429 เมื่อเกินลิมิต เทสต์เดิมยังผ่าน และมีเทสต์ใหม่สำหรับลิมิตนี้) เธอตั้งตัวเองเป็น Assignee ที่เป็นมนุษย์ แล้วเลือก assignee ที่เป็นเอเจนต์ ตอนนี้ Task อยู่ใน Backlog ยังไม่มีอะไรถูกรัน
2. Run. เธอย้าย SH-312 ไปยังสถานะ Ready for work การเปลี่ยนสถานะนี้เองที่เริ่มการรัน เอเจนต์รับ Task เตรียม worktree ใหม่เพื่อไม่ให้งานชิ้นนี้ชนกับงานอื่น อ่านคำอธิบายและคอมเมนต์ล่าสุด แก้ไข endpoint เพิ่มเทสต์ และรันชุดเทสต์ทั้งหมด
3. Report. เอเจนต์เปิด pull request และโพสต์คอมเมนต์บน Task: สรุปการเปลี่ยนแปลง เทสต์ที่รันและผลลัพธ์ พร้อมบันทึกตามตรงหนึ่งข้อว่ามันไม่ได้ทำ load test ลิมิตนี้ภายใต้ทราฟฟิกจริง แล้วย้าย SH-312 ไปเป็น Ready for review มันหยุดอยู่แค่นั้น ไปต่อไม่ได้
4. Review. สัญญาณรอการรีวิวมาถึง Inbox ของวิศวกรคนนั้น เธออ่านตามลำดับ: เกณฑ์การยอมรับ คอมเมนต์ของเอเจนต์ execution log แล้วจึงดู diff log แสดงให้เห็นว่าทำไมการรันนั้นถูกจัดคิวไว้และเรียกใช้เครื่องมืออะไรบ้าง เธอจึงได้รีวิวตัวการเปลี่ยนแปลง ไม่ใช่เรื่องเล่าเกี่ยวกับมัน ช่องโหว่เรื่อง load test เป็นเรื่องจริง所以她คอมเมนต์ขอให้เพิ่มเทสต์ที่เพดานตามที่บันทึกไว้ คอมเมนต์นั้นจัดคิวการรันต่อเนื่องให้เอเจนต์ตัวเดิม โดยที่เธอไม่ต้องเปิด Task ใหม่
5. Accept. เอเจนต์เพิ่มเทสต์ รายงานอีกครั้ง และส่ง Task กลับไปที่ Ready for review ครั้งนี้หลักฐานตรงกับเกณฑ์ครบ เธอ merge PR และย้าย SH-312 ไปเป็น Done ซึ่งเป็นการกระทำโดยเจตนาสองครั้งของคนที่เป็นเจ้าของงานมาตั้งแต่ต้น

ทุกขั้นตอนย้อนกลับมาที่ Task ไม่ว่าจะเป็นการรัน ลิงก์ PR คอมเมนต์รีวิว หรือการรับงาน ไม่มีอะไรอยู่แค่ใน terminal คู่มือของเราเรื่อง การรีวิวโค้ดที่สร้างโดย AI ด้วยหลักฐานระดับ Task อธิบายลึกกว่านี้ว่าควรอ่านอะไรก่อนตัดสินใจรับงาน

จุดที่ความเป็นเจ้าของพังลงอย่างเงียบ ๆ

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

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

บทสรุป

ความเป็นเจ้าของงานของเอเจนต์โดยมนุษย์ไม่ใช่เบรกที่ฉุดระบบอัตโนมัติ แต่เป็นสิ่งที่ทำให้ระบบอัตโนมัติขยาย規模ได้อย่างปลอดภัย ปล่อยให้เอเจนต์ลงมือทำทั้งหมด เร็วแค่ไหนก็ปล่อยให้เร็วเท่านั้น แต่เก็บการตัดสินใจสี่ข้อไว้กับคน: จะมอบหมายอะไร จะให้อำนาจในการรันหรือไม่ ผลลัพธ์ผ่านเกณฑ์หรือเปล่า และจะปล่อยงานออกหรือไม่ จดการตัดสินใจเหล่านี้ไว้เป็นสถานะบน Task ที่ใช้ร่วมกัน ความรับผิดชอบจึงกลายเป็นข้อเท็จจริงที่ใครก็อ่านได้ แทนที่จะเป็นการเดาใน scrollback ของใครสักคน

ถ้าคุณรัน coding agent หลายตัวอยู่แล้ว Sharkly มอบที่เดียวให้คุณมอบหมายงานของพวกมัน เฝ้าดูการรัน และบันทึกว่าใครรีวิวและรับผลลัพธ์แต่ละชิ้น คุณจะประกอบโมเดลนี้ขึ้นมาเองด้วย worktree กับสเปรดชีตก็ได้ หรือจะ ดาวน์โหลด Sharkly แล้วให้ Task เป็นตัวพาไปทั้งหมดก็ได้ ส่วนภาพรวมเต็ม ๆ ของเลเยอร์นี้ เริ่มจาก การจัดการ coding agent เหนือ Claude Code และ Codex

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

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

เอเจนต์ทำเครื่องหมายว่างานของตัวเองเสร็จได้ไหม? ไม่ได้ เอเจนต์ผลัก Task ไปถึง Ready for review ได้ แต่ Task Workflow ของมันไม่ได้ให้สิทธิ์สถานะที่ถือว่ารับงานแล้ว มีเพียงคนเท่านั้นที่อ่านหลักฐานแล้วย้าย Task ไปเป็น Done

การ merge pull request ถือเป็นการรับงานหรือไม่? ไม่ใช่ การ merge PR ที่เชื่อมไว้เป็นเหตุการณ์ใน Git และไม่เปลี่ยนสถานะของ Task ใน Sharkly การรับงานเป็นการเปลี่ยนสถานะอีกครั้งที่แยกออกไป ซึ่งเจ้าของที่เป็นมนุษย์เป็นคนทำหลังการรีวิว

ใครควรเป็นเจ้าของ Task ของเอเจนต์? คนที่ตัดสินใจว่างานนี้คุ้มค่าที่จะทำ Sharkly เก็บช่อง Assignee ที่เป็นมนุษย์ไว้คู่กับ assignee ที่เป็นเอเจนต์ สัญญาณการรีวิวจึงถูกส่งไปถึงคนคนนั้น และคนคนนั้นเป็นผู้รับงาน

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