เอเจนต์ตัวแรกในทีมเป็นเรื่องของประสิทธิภาพการทำงานส่วนบุคคล ตัวที่ห้าเป็นเรื่องของทั้งองค์กร ระหว่างสองจุดนั้นเอง กลุ่มหนึ่งจะเลิกเป็นแค่ทีมที่ใช้ AI แล้วกลายเป็นทีมแบบเอเจนติก (agentic team) คือมนุษย์และเอเจนต์ทำงานอยู่บนบอร์ดเดียวกัน งานเดียวกัน ภายใต้กฎที่ต้องมีใครสักคนเขียนมันขึ้นมา
จุดเปลี่ยนตรงนั้นคือที่ที่คำถามน่าสนใจส่วนใหญ่อาศัยอยู่ ใครเป็นเจ้าของงานที่เอเจนต์ลงมือทำ สแตนด์อัปจะเหลืออะไรเมื่อบอร์ดอัปเดตตัวเอง คนรีวิวหนึ่งคนรองรับเอเจนต์ได้กี่ตัว คู่มือนี้ครอบคลุมองค์ประกอบของทีมแบบเอเจนติก การแบ่งงานที่ทนทานต่อการปะทะกับงานจริง และข้อตกลงการทำงานที่คุ้มค่าจะลอกไปใช้ Sharkly คือแพลตฟอร์มที่เราสร้างขึ้นสำหรับทีมในรูปแบบนี้ และโหมดความล้มเหลวด้านล่างนี้มาจากการเฝ้าดูทีมรูปแบบนี้พังไป
สรุปสั้น ๆ
ทีมแบบเอเจนติกคือกลุ่มที่ทั้งคนและเอเจนต์ AI ต่างมีงานที่ได้รับมอบหมายอยู่ในระบบร่วมกันระบบเดียว โดยที่มนุษย์ยังคงดูแลทิศทาง อำนาจตัดสินใจ และการยอมรับผลงาน เอเจนต์ค้นคว้า ลงมือทำ ทดสอบ และรายงาน ส่วนคนกำหนดทิศทาง มอบอำนาจ และยอมรับผลลัพธ์ ข้อกำหนดในทางปฏิบัติ ได้แก่ บันทึกงานที่ทั้งสองฝ่ายอ่านได้ ผู้รับผิดชอบฝ่ายลงมือทำที่แยกออกจากผู้รับผิดชอบงาน สถานะรีวิวที่ไปถึงตัวคนจริง ๆ และขอบเขตงานที่เขียนไว้ชัดพอที่เอเจนต์ไม่ต้องเดา
ทีมแบบเอเจนติกประกอบด้วยอะไรบ้าง
ผู้เข้าร่วมมีสามประเภท และการเรียกชื่อแต่ละประเภทให้แม่นยำก็ช่วยได้มาก
คน สร้างและอัปเดตงาน แสดงความคิดเห็น รับรายการในคิว ได้รับมอบหมายงาน รีวิวผลงานของเอเจนต์ และจัดการการตั้งค่าที่บทบาทของตนอนุญาต พวกเขาเป็นผู้เข้าร่วมกลุ่มเดียวที่รับผิดชอบได้จริง
เอเจนต์ คือชุดการทำงานที่บันทึกไว้ ไม่ใช่พรอมป์ต์แบบใช้ครั้งเดียวแล้วทิ้ง ได้แก่ คำสั่ง รันไทม์อย่าง Claude Code หรือ Codex รีโพซิทอรี สภาพแวดล้อม การตั้งค่าการรัน และสกิลที่ผูกไว้ เอเจนต์ใกล้เคียงกับบทบาทที่ถูกจ consign... เอเจนต์ใกล้เคียงกับบทบาทที่บันทึกเป็นเอกสารมากกว่าจะเป็นตัวบุคคล บทความอธิบาย Sharkly Agents ของเราครอบคลุมว่าอะไรบ้างที่ประกอบขึ้นเป็นเอเจนต์หนึ่งตัว
Crews จัดกลุ่มเอเจนต์ไว้ใต้หัวหน้าเอเจนต์หนึ่งตัวสำหรับงานที่ต้องอาศัยการประสานงาน การลงมือทำเริ่มจากหัวหน้าก่อน: หัวหน้าอ่านงานและคำสั่งของ crew จากนั้นจึงลงมือเองหรือดึงสมาชิกตัวที่เฉพาะเจาะจงเข้ามา ลำดับเช่นนี้มีอยู่เพื่อไม่ให้สมาชิกทุกตัวเริ่มทำงานพร้อมกัน รายละเอียดอยู่ในคู่มือ Sharkly Crews ของเรา
สิทธิ์การเข้าถึงเป็นชั้นที่ทับอยู่ด้านบน: บทบาทในองค์กรกำหนดความสามารถด้านการดูแลระบบในภาพกว้าง และการเป็นสมาชิกสเปซกำหนดว่าผู้ใช้เข้าถึงพื้นที่งานใดได้บ้าง เอเจนต์ก็ถูกจำกัดขอบเขตแบบเดียวกัน คือระบุลงไปถึงรีโพซิทอรีและเครื่องที่เจาะจง
การแบ่งงานที่ได้ผลจริง
สัญญาของ Sharkly เองถือเป็นค่าเริ่มต้นที่ดี เพราะแคบพอที่จะบังคับใช้ได้จริง: เอเจนต์ค้นคว้า ลงมือทำ ทดสอบ และรายงาน ส่วนคนกำหนดทิศทาง มอบอำนาจ และยอมรับผลลัพธ์
ความรับผิดชอบสี่อย่างยังคงอยู่กับมนุษย์ ไม่ว่าเอเจนต์จะเก่งขึ้นแค่ไหน
- ทิศทาง ตัดสินว่าอะไรคุ้มค่าที่จะทำ และทำลำดับไหน
- บริบท เขียนขอบเขตที่เอเจนต์ลงมือได้: งานนี้สำคัญเพราะอะไร อะไรอยู่นอกขอบเขต ไฟล์และข้อจำกัดที่เกี่ยวข้อง และจะรีวิวความสำเร็จอย่างไร
- การยอมรับผลงาน อ่านหลักฐานแล้วตัดสินว่างานเสร็จแล้ว การรันที่จบลงไม่เท่ากับผลลัพธ์ที่ได้รับการยอมรับ
- การส่งต่อเรื่อง ตัดสินว่าเกิดอะไรขึ้นเมื่อเอเจนต์ติดขัด ทำผิด หรือเจอคำถามที่ต้องใช้ดุลยพินิจ
ส่วนที่เหลือต่อรองได้ทั้งหมด และขึ้นอยู่กับว่าทีมของคุณเชื่อมั่นในผลงานที่ผ่านมาของเอเจนต์ตัวหนึ่งกับงานประเภทหนึ่งมากแค่ไหน
งานไหลผ่านทีมอย่างไร
วงจรนี้สั้นและคุ้มค่าที่จะเขียนให้ชัด เพราะทีมที่ข้ามขั้นตอนใดไปจะรู้สึกได้ภายในหนึ่งสัปดาห์
- คนหนึ่งคนเขียนงานขึ้นมาหนึ่งชิ้น โดยระบุผลลัพธ์ที่ต้องการและเกณฑ์การยอมรับ
- งานนั้นมีผู้รับผิดชอบที่เป็นคน และมีเอเจนต์หรือ crew เป็นผู้รับผิดชอบฝ่ายลงมือทำ สองฟิลด์นี้แยกจากกัน และการเปลี่ยนอันหนึ่งไม่ได้เปลี่ยนอีกอัน
- การย้ายงานออกจากสถานะพักในแบ็กлогจะเริ่มการรันเมื่อเอเจนต์ที่ได้รับมอบหมายพร้อม
- การรันเกิดขึ้นบนเครื่องที่เชื่อมต่อไว้ ในไดเรกทอรีที่แยกออกมา โดยความคืบหน้าและอุปสรรคจะถูกส่งกลับไปที่งานนั้น
- เอเจนต์จะทิ้งงานไว้ในสถานะรอคำตอบจากคน หรือรอการรีวิวจากคน ซึ่งจะไปอยู่ในกล่องจดหมายเอเจนต์ของผู้รับผิดชอบ
- คนอ่าน trace และ diff แล้วจึงยอมรับ แสดงความคิดเห็นเพื่อให้ทำต่อ หรือมอบหมายใหม่
ความคิดเห็นคือบทสนทนาที่ยั่งยืน ความคิดเห็นในงานที่มีเอเจนต์พร้อมอยู่สามารถเข้าคิวการรันถัดไปได้ ทำให้ฟีดแบ็กตอนรีวิวกับการลงมือทำเป็นการเคลื่อนไหวเดียวกัน ไม่ใช่สองระบบแยกกัน
สามรูปแบบที่ได้ผล
นักพัฒนาที่มีคู่หูเอเจนต์ นักพัฒนาแต่ละคนดูแลเอเจนต์หนึ่งหรือสองตัวสำหรับงานที่เกิดซ้ำของตัวเอง เช่น ความครอบคลุมของเทสต์ การอัปเดต dependency หรือการรีแฟกเตอร์ที่เคยทำมาแล้วยี่สิบครั้ง ประโยชน์ต่อทีมคือคำนิยามของเอเจนต์เหล่านี้ถูกแชร์ไว้ พนักงานใหม่จึงได้ชุดการทำงานที่ใช้งานได้จริงห้าชุดตั้งแต่วันแรก แทนที่จะต้องสร้างของตัวเองขึ้นมา
ทีมย่อยที่มี crew ใช้ร่วมกัน crew หนึ่งตัวดูแลงานประเภทที่ทั้งทีมย่อยต้องพึ่งพา เช่น การเตรียมรีลีสหรือการคัดแยกเหตุการณ์ (incident triage) หัวหน้าเอเจนต์ตัดสินว่าสมาชิกตัวไหนจะช่วยงาน และมีคนหนึ่งคนเป็นเจ้าของงานประเภทนั้น นี่คือรูปแบบที่ขยายได้ไกลที่สุดก่อนที่กำลังการรีวิวจะกลายเป็นคอขวด
ทีมแพลตฟอร์มที่สร้างมาตรฐาน กลุ่มแพลตฟอร์มหรือ developer experience เป็นเจ้าของคำนิยามเอเจนต์ สกิล และการตั้งค่าเครื่องให้กับทีมผลิตภัณฑ์หลายทีม ทีมผลิตภัณฑ์มอบหมายงาน ส่วนทีมแพลตฟอร์มดูแลให้รันไทม์ สิทธิ์ และคำสั่งเป็นปัจจุบัน รูปแบบนี้แลกอิสระบางส่วนกับความสม่ำเสมอ และมักเป็นการแลกที่คุ้มค่าเมื่อทีมมีวิศวกรเกินราวสามสิบคน
ทั้งสามรูปแบบไม่ต้องรื้อโครงสร้างองค์กรใหม่เลย มันเป็นแพตเทิร์นว่าคำนิยามของเอเจนต์ควรมีใครเป็นเจ้าของ ซึ่งเป็นคำถามที่ตัดสินว่าความสามารถของเอเจนต์จะทบต้นไปทั่วทั้งทีม หรือจะยังคงเป็นเรื่องส่วนตัวของใครของมัน
ข้อตกลงการทำงานที่ควรนำไปใช้
งานหนึ่งงานมีคนรับผิดชอบชัดเจนหนึ่งคน แม้ในกรณีที่ crew ของเอเจนต์สี่ตัวเป็นผู้ลงมือทำ และยิ่งต้องเป็นเช่นนั้นเป็นพิเศษ
เขียนขอบเขตก่อนมอบหมาย ถ้าไม่มีใครบอกได้ว่าจะตรวจสอบผลลัพธ์อย่างไร งานนั้นก็ยังไม่พร้อมให้เอเจนต์ทำ กฎข้อนี้ข้อเดียวก็กำจัดการรันที่ล้มเหลวไปได้เกือบทั้งหมด
การรีวิวคือกำลังที่จัดเวลาไว้ ไม่ใช่เวลาว่าง ตัดสินว่าผู้รีวิวแต่ละคนรับงานเอเจนต์ได้วันละเท่าไร แล้วยึดตัวเลขนั้นไว้ กองผลงานเอเจนต์ที่ยังไม่ได้รีวิวและพอกขึ้นเรื่อย ๆ ก็คือหนี้ก้อนเดียวกับ pull request ที่ยังไม่ merge แถมโตเร็วกว่าด้วย
การรันที่ล้มเหลวต้องวิเคราะห์หาสาเหตุ ไม่ใช่กดลองใหม่ เปิดบันทึกการรันแล้วอ่านหัวข้อกับรายละเอียดทางเทคนิคก่อน ข้อผิดพลาดจากผู้ให้บริการที่ดูคล้ายกันบ่อยครั้งต้องแก้ด้วยวิธีที่ตรงกันข้าม การกดลองใหม่โดยอัตโนมัติจึงกลบสาเหตุที่แท้จริงไว้
คำนิยามเอเจนต์ต้องมีเจ้าของและวันทบทวน คำสั่งต่าง ๆ เสื่อมสภาพได้ นักพัฒนาที่เขียนเอเจนต์ migration ลาออก ธรรมเนียมปฏิบัติเปลี่ยนไป แต่เอเจนต์ก็ยังคงนำกฎของไตรมาสที่แล้วมาใช้อย่างมั่นใจ
อะไรพังก่อนเมื่อทีมเติบโต
กำลังการรีวิวคือสิ่งที่พังก่อนเสมอ ทุกครั้ง ข้อจำกัดที่สองคือกำลังของเครื่อง: การรันต้องเข้าคิวรอ concurrency หรือไดเรกทอรีทำงานว่าง และทีมที่เพิ่มเอเจนต์โดยไม่ได้เพิ่มคอมพิวเตอร์จะค้นพบคิวที่มองไม่เห็นจากบอร์ด
ข้อที่สามคือความเป็นเจ้าของที่ค่อย ๆ คลายไป เมื่อเอเจนต์หลายตัวร่วมทำงานที่เกี่ยวข้องกัน และไม่มีใครเปลี่ยนชื่อเจ้าของหลังการส่งงานต่อ คุณจะลงเอยด้วยงานที่ในทางเทคนิคมีผู้รับผิดชอบ แต่ในทางปฏิบัติไม่มีใครเป็นเจ้าของ การไล่ดูงานที่มีเอเจนต์เป็นผู้รับผิดชอบและมีเจ้าของที่เป็นคนค้างเก่า สัปดาห์ละครั้งใช้เวลาสิบนาที และป้องกันไม่ให้เรื่องนี้บานปลายเป็นความวุ่นวาย ถ้าคุณอยากเริ่มจากระบบที่แยกฟิลด์เหล่านี้ไว้ให้แล้ว ดาวน์โหลด Sharkly แล้วลองใช้งานที่ทำซ้ำแบบหนึ่งผ่านระบบนี้สักหนึ่งสัปดาห์
คำถามที่พบบ่อย
นักพัฒนาหนึ่งคนควรมีเอเจนต์กี่ตัวจึงจะเหมาะสม เริ่มที่หนึ่งหรือสองตัว และให้ปริมาณงานรีวิวที่ทำได้เป็นตัวกำหนดเพดาน จำนวนที่เหมาะสมคือจำนวนที่ผลลัพธ์ไม่ต้องรอการตัดสินใจของคนนานเกินหนึ่งวันทำการ
เอเจนต์เข้าร่วมสแตนด์อัปไหม งานของพวกมันเข้าร่วม บอร์ดแสดงสถานะอยู่แล้ว สแตนด์อัปจึงกลายเป็นรายการข้อยกเว้น: ความล้มเหลว การรันที่ติดขัด และผลลัพธ์ที่รอคนอยู่
ควรให้เอเจนต์เป็นผู้รับผิดชอบเพียงคนเดียวได้ไหม ไม่ควร ให้มีคนรับผิดชอบผลลัพธ์เสมอ โดยให้เอเจนต์อยู่ในช่องผู้ลงมือทำ คู่มือการจัดการโปรเจกต์ด้วย AI Agentของเราอธิบายว่าทำไมการแยกแบบนี้จึงยิ่งสำคัญเมื่อปริมาณงานเพิ่มขึ้น
เราจะพาเอเจนต์ตัวใหม่เข้าทีมอย่างไร เหมือนกับการพาคนใหม่เข้าทีม: ให้งานแรกที่แคบ รีวิวอย่างใกล้ชิด แล้วค่อย ๆ ขยายขอบเขต บันทึกสิ่งที่ได้ผลไว้เป็นคำสั่งและสกิลของเอเจนต์ เพื่อให้ทีมถัดไปไม่ต้องค้นพบมันใหม่
