การจัดการงานของ AI Agent: ใครมอบหมาย ใครรับงาน?

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

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

สรุปสั้น

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

งานที่พร้อมให้เอเจนต์ทำ มีองค์ประกอบอะไรบ้าง

คำอธิบายงานคืออินเทอร์เฟซ ทุกอย่างที่เอเจนต์รู้เกี่ยวกับความต้องการของเรา มาจากคำอธิบายงาน บวกกับข้อมูลที่งานนั้นบรรจุอยู่ในฟิลด์ต่าง ๆ

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

• งานนี้สำคัญเพราะอะไร;
• อะไรอยู่ในขอบเขต และอะไรอยู่นอกขอบเขต;
• ไฟล์ ลิงก์ ตัวอย่าง หรือพฤติกรรมที่สังเกตได้ที่เกี่ยวข้อง;
• ข้อจำกัดและการตัดสินใจที่มีอยู่แล้ว;
• วิธีตรวจสอบว่าเสร็จแล้ว

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

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

การมอบหมาย: สองช่อง ไม่ใช่ช่องเดียว

ข้อผิดพลาดด้านการออกแบบที่พบบ่อยที่สุดในการจัดการงานสำหรับเอเจนต์ คือการใช้ฟิลด์ผู้รับผิดชอบเพียงช่องเดียว

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

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

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

สถานะ: ส่วนที่ควบคุมการลงมือทำ

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

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

กฎข้อที่สองคือ สถานะตามวงจรชีวิตของงานกับสถานะการทำงานของเอเจนต์เป็นคนละเรื่องกัน งานอาจอยู่ในสถานะที่เริ่มแล้ว ขณะที่เอเจนต์กำลังทำงาน รอคนตอบ รอคนตรวจสอบ หรือรายงานข้อผิดพลาด สถานะการรันอย่าง queued, dispatched, running, completed, failed และ canceled อธิบายความคืบหน้าของการลงมือทำ และไม่ได้ย้ายสถานะของงานโดยอัตโนมัติ การอ่านอันหนึ่งเป็นอีกอันหนึ่ง คือสาเหตุที่บอร์ดดูสุขภาพดีทั้งที่ผลลัพธ์สามชิ้นนอนไม่มีใครอ่าน

การตรวจสอบ: ทำให้การส่งมอบชัดเจน

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

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

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

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

เทมเพลตงานที่ควรลอกไปใช้

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

Outcome: <what is true when this is done>

Context:
- Why this matters now
- Observed behavior, with the exact error or reproduction steps
- Files, links, or examples that are relevant

Scope:
- In: <the change you want>
- Out: <adjacent work the agent should not touch>

Constraints:
- Decisions already made, conventions to follow, things not to change

Review:
- How completion will be checked, and by whom

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

ห้าความผิดพลาดที่ควรหลีกเลี่ยง

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

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

เอเจนต์เปลี่ยนสถานะของงานได้ไหม ได้ในขอบเขตที่กำหนด workflow ของประเภทงานนั้นจำกัดว่าสถานะใดใช้ได้ ดังนั้นเอเจนต์จึงเลือกได้เฉพาะสถานะที่ workflow อนุญาต

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

ต้องมีประเภทงานแยกสำหรับงานของเอเจนต์ไหม ปกติไม่ต้อง ใช้ประเภทแยกเมื่องานต้องใช้ชุดฟิลด์หรือ workflow ที่ต่างกันอย่างมีนัยสำคัญ และใช้ป้ายกำกับเมื่อต้องการแค่การจำแนกแบบเบา ๆ

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