เอเจนต์ AI ตัวแรกในทีมช่วยเพิ่มปริมาณงานที่ทำได้ แต่ตัวที่สองกลับสร้างปัญหาด้านการประสานงาน ต้องมีคนตัดสินใจว่าเอเจนต์ตัวไหนรับงานแก้ API ตัวไหนเขียนเทสต์ การรีแฟกเตอร์ควรรอการย้ายสคีมาก่อนหรือไม่ และใครจะตรวจผลลัพธ์ที่รวมกันแล้วก่อนที่มนุษย์จะอนุมัติ ในทีมส่วนใหญ่ คนคนนั้นคือวิศวกรอาวุโสที่ถือเทอร์มินัลคนละมือ และบทบาทนี้ก็ขยายตามไม่ได้
Sharkly Crews ถูกสร้างขึ้นมาเพื่อช่วงเวลานี้โดยเฉพาะ Crew คือกลุ่มของ People และเอเจนต์ที่นำกลับมาใช้ซ้ำได้ ซึ่งประสานงานโดยเอเจนต์หัวหน้าหนึ่งตัว และมันอยู่ภายใน Sharkly แพลตฟอร์มที่เก็บงานของเอเจนต์ไว้ในระบบงานที่ใช้ร่วมกัน แทนที่มนุษย์จะต้องจัดเส้นทางงานย่อยทุกชิ้นด้วยมือ คุณเพียงมอบหมาย Task ให้กับ Crew เอเจนต์หัวหน้าจะอ่านเป้าหมาย ตัดสินใจว่าสมาชิกคนไหนควรมีส่วนร่วม และนำผลลัพธ์ของพวกเขากลับมารวมไว้ในที่เดียวที่ทีมของคุณตรวจสอบได้
คู่มือนี้จะอธิบายว่า Crew คืออะไร เมื่อไหร่ที่เอเจนต์ตัวเดียวเป็นทางเลือกที่ดีกว่า การทำงานแบบหัวหน้าเริ่มก่อนมีพฤติกรรมอย่างไรในแต่ละรอบรัน และจะตั้งค่า Crew อย่างไรให้ทีมของคุณยังใช้งานอยู่แม้ผ่านไปสามเดือน
TL;DR
Crew ใน Sharkly คือกลุ่มของ People และเอเจนต์ที่นำกลับมาใช้ซ้ำได้ ซึ่งประสานงานโดยเอเจนต์หัวหน้าหนึ่งตัว คุณมอบหมาย Task ให้ Crew แล้วหัวหน้าจะเริ่มก่อน ตีความเป้าหมาย มอบหมายงานเป็นส่วน ๆ ให้สมาชิกที่เป็นเอเจนต์โดยการ mention พวกเขา และรวมผลลัพธ์ไว้บน Task เอเจนต์ทำวิจัย ลงมือทำ ทดสอบ และรายงาน ส่วนมนุษย์กำหนดทิศทาง มอบอำนาจ และอนุมัติผลลัพธ์
Crew ใน Sharkly คืออะไร?
Crew คือทีมที่ตั้งชื่อไว้และนำกลับมาใช้ซ้ำได้ ประกอบด้วย People และเอเจนต์ที่รวมตัวกันรอบงานประเภทที่แน่นอน โดยมีเอเจนต์หัวหน้าหนึ่งตัวคอยประสานการทำงาน หากเอเจนต์ตัวเดียวคือการตั้งค่าการทำงานที่บันทึกไว้สำหรับบทบาทหนึ่ง Crew จะบันทึกว่าหลายบทบาททำงานร่วมกันอย่างไร ทำให้ Task ที่ซับซ้อนสามารถมอบหมายให้ทั้งทีมได้ แทนที่จะมอบให้ผู้ลงมือทำเพียงคนเดียว
Crew ทุกตัวประกอบด้วย:
- ชื่อ คำอธิบาย และคำสั่งของ Crew (ไม่บังคับ)
- Owner หนึ่งคน ซึ่งเป็นบุคคลในองค์กรที่ดูแล Crew
- หัวหน้าหนึ่งตัว ซึ่งต้องเป็นเอเจนต์ที่อยู่ใน Space ของ Crew
- สมาชิกที่เป็นเอเจนต์และ People ที่สามารถเข้าร่วมใน Space นั้น
- Space ที่เป็นเจ้าของหนึ่งแห่ง
- การมองเห็นแบบ Personal หรือ Space
- การตั้งค่าไดเรกทอรี Task ที่ใช้ร่วมกัน (ไม่บังคับ)
มีขอบเขตสองอย่างที่สำคัญก่อนสิ่งอื่นใด
Owner ไม่ใช่หัวหน้า Owner คือบุคคลที่ดูแล Crew ทั้งสมาชิก การตั้งค่า และการมองเห็น ส่วนหัวหน้าเป็นเอเจนต์ และยังคงทำหน้าที่ประสานการทำงาน การมองว่า Owner ทำหน้าที่แทนเอเจนต์หัวหน้าคือการเข้าใจผิดทั้งสองบทบาท
การเป็นสมาชิกไม่ใช่การลงมือทำ การเป็นสมาชิกในฐานะ People บันทึกว่าใครมีส่วนร่วมใน Crew แต่มีเพียงสมาชิกที่เป็นเอเจนต์เท่านั้นที่เริ่มการรันของเอเจนต์ได้ คนที่อยู่ใน Crew ยังคงทำงานร่วมกันแบบเดิม คือผ่านคอมเมนต์บน Task การรีวิว และแชต การเข้าร่วม Crew ไม่ได้เปลี่ยนมนุษย์ให้กลายเป็นเป้าหมายของการรันแต่อย่างใด
หัวหน้าจะถูกเพิ่มเป็นสมาชิกโดยอัตโนมัติ ถือบทบาทหัวหน้า และไม่สามารถถูกนำออกได้ในขณะที่ยังนำ Crew อยู่ สมาชิกคนอื่นสามารถมีป้ายกำกับบทบาทที่อธิบายการมีส่วนร่วมของตน เช่น backend, tests หรือ docs ซึ่งทำให้หัวหน้ามีข้อมูลที่ชัดเจนไว้ใช้พิจารณาเวลามอบหมายงาน
เมื่อไหร่ควรใช้ Crew แทนเอเจนต์ตัวเดียว?
หลักการตัดสินใจคู่นี้มาจาก เอกสารของ Sharkly โดยตรง และควรยึดตามนั้นแบบตรงตัว สำหรับงานชิ้นเล็กที่ขอบเขตชัดเจน ให้มอบหมาย Task ตรงไปยังเอเจนต์ตัวเดียว ใช้ Crew เมื่อหัวหน้าจำเป็นต้องตีความเป้าหมาย ให้สมาชิกที่เป็นเอเจนต์ตัวอื่นเข้ามามีส่วนร่วม และนำผลลัพธ์ของพวกเขากลับมารวมไว้ใน Task หรือบทสนทนาเดียว
เอเจนต์ตัวเดียวเป็นคำตอบที่ถูกต้องเมื่อ:
- งานนั้นพอดีกับบทบาทเดียว เช่นการแก้บั๊กในเซอร์วิสเดียว
- ขอบเขตชัดเจนอยู่แล้วและไม่จำเป็นต้องแตกงานออกเป็นส่วน ๆ
- คุณต้องการให้มีชิ้นส่วนที่ต้องขยับน้อยที่สุดระหว่างการมอบหมายถึงการรีวิว
- คุณยังปรับจูนคำสั่งของเอเจนต์แต่ละตัวอยู่และต้องการสัญญาณที่ชัดเจน
Crew คุ้มค่าที่จะมีเมื่อ:
- เป้าหมายคร่อมหลายบทบาท เช่นฟีเจอร์ที่ต้องแก้ทั้ง backend, frontend และเทสต์
- ต้องมีคนตัดสินลำดับของงานที่แต่ละฝ่ายส่งเข้ามา และคุณอยากให้คนนั้นเป็นเอเจนต์ ไม่ใช่มนุษย์ที่เปิดเทอร์มินัลสองจอ
- กลุ่มผู้เชี่ยวชาญชุดเดิม ๆ ถูกจัดตั้งใหม่ซ้ำแล้วซ้ำเล่าในทุกคำขอ
- ผลลัพธ์จากเอเจนต์หลายตัวต้องมารวมบน Task เดียว แทนที่จะกระจัดกระจายไปตามเซสชันส่วนตัว
หากทีมของคุณยังตัดสินใจไม่ว่าการทำงานแบบหลายเอเจนต์คุ้มค่าที่จะจัดโครงสร้างหรือไม่ บทความปูพื้นฐานเกี่ยวกับ AI agent orchestration ได้อธิบายข้อแลกเปลี่ยนตั้งแต่หลักการพื้นฐาน สรุปสั้น ๆ คือ เอเจนต์ตัวที่สองมีต้นทุนต่ำ แต่การประสานงานระหว่างเอเจนต์ที่ไม่มีใครดูแลนั้นไม่ใช่
การทำงานแบบหัวหน้าเริ่มก่อนเป็นอย่างไร
เมื่อคุณมอบหมาย Task ให้ Crew การทำงานจะเป็นไปตามลำดับที่หัวหน้าเริ่มก่อน:
- Task ถูกมอบหมายให้ Crew ผ่านตัวควบคุม Assignee เหมือนกับ Assignee อื่น ๆ
- หาก Task อยู่ในสถานะที่รันได้และหัวหน้าพร้อม เอเจนต์หัวหน้าจะเริ่มก่อน
- หัวหน้าอ่านบริบทของ Task และคำสั่งของ Crew
- หัวหน้าจะลงมือทำงานนั้นเอง หรือ mention สมาชิกที่เป็นเอเจนต์ที่มีคุณสมบัติเหมาะสมให้ทำงานเฉพาะส่วน
- สมาชิกที่เป็นเอเจนต์ซึ่งถูก mention จะรันบน Task เดียวกันและเพิ่มผลลัพธ์ลงในแชตของ Task นั้น
- หัวหน้าประสานงานต่อไปและรวมผลลัพธ์เข้าด้วยกัน
เป้าหมายการออกแบบเบื้องหลังลำดับนี้คือความยับยั้งชั่งใจ การทำงานแบบหัวหน้าเริ่มก่อนช่วยป้องกันไม่ให้สมาชิกที่เป็นเอเจนต์ทุกตัวเริ่มพร้อมกัน อีกทั้งยังเปิดโอกาสให้หัวหน้าค้นหาบริบทที่ขาดหาย เลือกผู้ร่วมงานที่เหมาะสม และควบคุมลำดับของงาน Crew ที่ไม่มีหัวหน้าจะเป็นแค่ปุ่มกระจายงาน แต่เมื่อมีหัวหน้า มันคือทีมที่คิดก่อนจะแบ่งงาน
Backlog มีพฤติกรรมเหมือนกับกรณีของเอเจนต์แต่ละตัว การมอบหมาย Task ใน Backlog จะไม่เริ่มหัวหน้า Backlog คือพื้นที่พักงานที่ใช้เตรียมงาน และการย้าย Task ไปยังสถานะที่รันได้คือการกระทำที่เริ่ม Crew การมอบหมายไม่เคยทำให้งานเริ่มขึ้นโดยไม่คาดคิด
ทุกอย่างที่สมาชิกผลิตออกมานั้นย้อนกลับไปที่ Task ทั้งสถานะการรัน ผลลัพธ์ และการสนทนารอบ ๆ สิ่งเหล่านั้น นั่นคือจุดประสงค์ของการรันทีมไว้ใน Sharkly แทนที่จะกระจายอยู่บนเทอร์มินัลห้าจอ บริบท ความคืบหน้า อุปสรรค ผลลัพธ์ และการรีวิวโดยมนุษย์ ยังมองเห็นได้ตั้งแต่คำขอจนถึงการปล่อยงาน ไม่ว่าจะมีเอเจนต์ตัวเดียวหรือสี่ตัวที่ลงมือทำ
หมายเหตุเชิงกลไกสำหรับทีมที่รันสมาชิกแบบขนาน: การรันของเอเจนต์แต่ละครั้งยังคงได้ไดเรกทอรีทำงานที่แยกออกจากกันโดยค่าเริ่มต้น สมาชิกจึงไม่ก้าวก่ายไฟล์ของกันและกัน โมเดลการแยกนี้เป็นหัวข้อของ วิธีที่ Sharkly รันเอเจนต์แบบขนานโดยไม่เกิด merge conflict
ความเป็นเจ้าของ การมองเห็น และใครใช้ Crew ได้บ้าง
ผู้ที่มีสิทธิ์สร้างทรัพยากรที่ใช้ร่วมกันใน Space สามารถสร้าง Crew ที่นั่นได้ Crew ทุกตัวเป็นของ Space หนึ่งแห่ง และการมองเห็นของมันกำหนดว่าใครค้นหาและใช้งานได้บ้าง:
| การมองเห็น | ใครเข้าถึงและแชตได้ | ใครจัดการหรือมอบหมายได้ |
|---|---|---|
| Personal | Owner สมาชิก Crew ที่เป็นมนุษย์ และเจ้าของสมาชิกที่เป็นเอเจนต์ | มีเพียง Owner เท่านั้นที่จัดการ Crew หรือเลือกมันเป็น Assignee ของ Task ได้ |
| Space | สมาชิกของ Space ที่ Crew สังกัดอยู่ รวมถึง Owner และ Admin ขององค์กร | เป็นไปตามสิทธิ์ของ Space และองค์กร |
การมองเห็นมีผลกับตัว Crew เอง แชตของ Crew และการเลือกเป็น Assignee ของ Task Crew แบบ Personal จะถูกจัดการโดย Owner ของมัน และหลังจากที่ Owner ของ Crew ส่วนตัวเปลี่ยนไป Owner คนเดิมจะสูญเสียสิทธิ์ในการจัดการ กฎการส่งต่อนี้สำคัญเมื่อคนที่สร้าง Crew ย้ายทีม ควรโอนความเป็นเจ้าของอย่างตั้งใจ แทนที่จะมาค้นพบช่องว่างในภายหลัง
เมื่อ Crew ทำหน้าที่ของมันครบถ้วนแล้ว ให้ archive มันแทนที่จะลบประวัติทิ้ง Crew ที่ถูก archive จะหยุดรับการมอบหมายใหม่ แต่ประวัติเดิมยังคงเข้าถึงได้ ก่อนจะ archive ควรตรวจสอบว่า Task หรือ Automation ที่ใช้งานอยู่ยังใช้ Crew นั้นอยู่หรือไม่ และย้ายงานเหล่านั้นไปยัง Assignee อื่นก่อน การตรวจสอบการพึ่งพาแบบเดียวกันนี้ใช้กับการ archive เอเจนต์ที่เป็นสมาชิกของ Crew ด้วย
แชตของ Crew: การประสานงานก่อนที่จะมี Task
ไม่ใช่ทุกการสนทนาที่สมควรกลายเป็น Task ตั้งแต่วันแรก แชตของ Crew มีไว้สำหรับบทสนทนาที่เกิดขึ้นก่อนชิ้นงาน ไม่ว่าจะเป็นการสำรวจปัญหา การหาผู้ร่วมงานที่เหมาะสม หรือการวางแผนให้เป็นรูปเป็นร่าง
แต่ละคนจะได้เซสชันแชตถาวรกับ Crew โดยมีเอเจนต์หัวหน้าเป็นคู่สนทนาเริ่มต้น หัวหน้าสามารถ mention สมาชิกที่เป็นเอเจนต์เพื่อให้คำตอบของพวกเขาปรากฏในแชตเดียวกัน ซึ่งหมายความว่าคุณสามารถดูทั้งทีมช่วยกันคิดได้ก่อนที่จะตัดสินใจทำอะไรลงไป
ขอบเขตนี้ชัดเจนและควรจดจำไว้: แชตของ Crew ไม่ได้สร้าง Task เมื่อการสนทนากลายเป็นงานที่จับต้องได้ ให้สร้าง Task แล้วมอบหมายให้ Crew เพื่อให้สถานะ คอมเมนต์ การรัน และการอนุมัติยังคงผูกอยู่กับชิ้นงาน ข้อสรุปที่อยู่เพียงในเซสชันแชตคือข้อสรุปที่ทีมของคุณจะทำหาย บันทึกที่ใช้ร่วมกันคือ Task และผลลัพธ์จำเป็นต้องกลับมาที่มัน
หน้ารายละเอียดของ Task ยังมี quick chat อยู่บนแถบเครื่องมือส่วนหัว quick chat จะรันเอเจนต์หรือ Crew ที่เลือก โดยใช้ Task ปัจจุบันเป็นบริบท ในมุมมองแบบแบ่งครึ่งข้าง ๆ Task เป็นวิธีที่มีประโยชน์ในการถาม Crew ว่า "คุณจะทำอะไรกับสิ่งนี้" ก่อนจะมอบหมายอย่างเป็นทางการ
เทคนิค Crew ขั้นสูง
เอเจนต์เฉพาะ Crew: ผู้เชี่ยวชาญที่ทำงานที่อื่นไม่ได้
เอเจนต์บางตัวมีเหตุผลที่จะมีอยู่เฉพาะในทีมของมันเท่านั้น ผู้ประสานงาน merge ที่ตั้งสมมติฐานว่ามีสมาชิกอีกสามคนอยู่ หรือผู้รีวิวที่ปรับให้เข้ากับธรรมเนียมของ Crew ตัวใดตัวหนึ่ง ไม่ควรไปโผล่ในตัวเลือกเอเจนต์ทั่วไปขององค์กร ที่ซึ่งอาจมีคนเผลอมอบหมายงานเดี่ยวที่มันไม่ได้ถูกออกแบบมาให้ทำ
การทำเครื่องหมายว่าเอเจนต์เป็นแบบเฉพาะ Crew จะจำกัดขอบเขตของมันไว้ที่ Crew นั้น หลังจากเปิดการตั้งค่านี้:
- เอเจนต์จะถูกเรียกใช้ได้เฉพาะภายใน Crew ปัจจุบันเท่านั้น
- ไม่สามารถใช้สำหรับแชตส่วนตัวหรือถูกมอบหมาย Task ด้วยตัวเองได้
- มันจะหายไปจาก My Agents, directory, รายชื่อเอเจนต์ขององค์กร และตัวเลือก Assignee
ความเป็นเอกสิทธิ์เป็นข้อจำกัดขอบเขตของเอเจนต์ ไม่ใช่บทบาทใน Crew ป้ายกำกับบทบาทอธิบายว่าสมาชิกทำอะไร ส่วนความเป็นเอกสิทธิ์อธิบายว่าเอเจนต์ถูกเรียกใช้ได้ที่ไหน เอเจนต์เฉพาะ Crew จะเป็นสมาชิกของ Crew ได้ไม่เกินหนึ่งตัวในแต่ละช่วงเวลา ดังนั้นหากมันอยู่ใน Crew อื่นอยู่แล้ว ต้องนำมันออกจากที่นั่นก่อน การยกเลิกความเป็นเอกสิทธิ์จะคืนการมองเห็นและการมอบหมายงานตามปกติ และไม่ว่าจะทางไหน Task กับแชตในอดีตก็ยังคงอยู่ สิ่งที่ถูกบล็อกคือแชตส่วนตัวใหม่และการมอบหมายงานเดี่ยวใหม่
ไดเรกทอรี Task ที่ใช้ร่วมกัน: เมื่อสมาชิกต้องต่อยอดจากไฟล์เดียวกัน
โดยค่าเริ่มต้น การแยกออกจากกันคือกฎ การรันที่แยกกันจะได้ไดเรกทอรีแยกกัน Crew สามารถผ่อนกฎนี้ได้อย่างตั้งใจ เมื่อเปิดการตั้งค่าไดเรกทอรี Task ที่ใช้ร่วมกัน การรันของเอเจนต์ใน Crew ครั้งหลัง ๆ สำหรับ Task เดียวกันจะสามารถใช้ไดเรกทอรีล่าสุดที่เข้าเกณฑ์บน Computer เครื่องนั้นซ้ำได้ และรักษาการเปลี่ยนแปลงในเครื่องที่สมาชิกคนก่อนทิ้งไว้
มีข้อจำกัดสองข้อที่ทำให้สิ่งนี้ปลอดภัย มันแชร์เฉพาะสถานะของไฟล์ซิสเทม ไม่ใช่เซสชันผู้ให้บริการของเอเจนต์ตัวก่อน สมาชิกแต่ละตัวจึงยังเริ่มการคิดวิเคราะห์ของตัวเองจากบันทึกของ Task และมันใช้ได้เฉพาะเมื่อการรันเหล่านั้นอยู่ใน Task เดียวกันที่มอบหมายให้ Crew และรันบน Computer เครื่องเดียวกัน
หลักการตัดสินใจ: เปิดการใช้ไดเรกทอรีร่วมกันเมื่อสมาชิกที่ทำต่อเนื่องกันต้องต่อยอดจากการเปลี่ยนแปลงในเครื่องชุดเดียวกัน เช่นเอเจนต์ที่ลงมือเขียนโค้ดตามด้วยเอเจนต์ทดสอบที่รันโค้ดใหม่ ปล่อยให้ปิดไว้เมื่อการแยกออกจากกันปลอดภัยกว่า หรือเมื่อการแก้ไขพร้อมกันอาจขัดแย้งกัน หากคุณเปิดใช้งาน ควรระบุลำดับการทำงานที่ต้องการให้ชัดเจนในคำสั่งของ Crew เพราะไดเรกทอรีที่ใช้ร่วมกันซึ่งมีลำดับกำกวมก็คือ merge conflict ที่สวมเสื้อทีม
การเขียนคำสั่งของ Crew ที่ใช้ได้จริงในระยะยาว
คำสั่งของ Crew คือคู่มือการทำงานของหัวหน้าในเรื่องการประสานงาน เอกสารระบุชัดเจนว่าอะไรควรอยู่ในนั้น ได้แก่ หัวหน้าตัดสินใจว่าจะดึงเอเจนต์ตัวอื่นเข้ามาเกี่ยวข้องอย่างไร มีบทบาทอะไรบ้างที่ใช้ได้ ควรรวมผลลัพธ์อย่างไร และเมื่อไหร่ที่มนุษย์ต้องเป็นคนตัดสินใจ
แยกแต่ละชั้นออกจากกัน ข้อกำหนดเฉพาะของ Task ให้อยู่ในคำอธิบายและคอมเมนต์ของ Task ขั้นตอนที่นำกลับมาใช้ซ้ำได้และเอเจนต์หลายตัวใช้ร่วมกันควรอยู่ใน Skill คำสั่งของเอเจนต์สมาชิกแต่ละตัวรับผิดชอบบทบาทเฉพาะของมัน คำสั่งของ Crew ครอบคลุมเฉพาะกฎการทำงานร่วมกัน ซึ่งทำให้มันสั้นพอที่หัวหน้าจะทำตามได้ในทุกรอบรัน การคัดลอกคำสั่งของสมาชิกทุกตัวเข้าไปใน Crew ซ้ำ ๆ เป็นวิธีที่พบบ่อยที่สุดที่ทำให้การมอบหมายงานคาดเดาไม่ได้
โครงร่างที่ใช้ได้จริง:
# Crew: Checkout Feature Crew
## When to delegate
- API or database changes: mention @backend-agent
- UI changes in web/: mention @frontend-agent
- After any code change lands: mention @test-agent
## Order
Backend before frontend when a contract changes.
Tests run last, against the combined changes.
## Combining results
Summarize each member's outcome on the Task,
list open risks, then set the Task to waiting
for human review.
## Escalation
Any schema migration or public API change stops
here: ask the responsible person on the Task
before proceeding.
บล็อกการส่งต่อปัญหา (escalation) นั้นคือสัญญาระหว่างมนุษย์กับเอเจนต์ที่เขียนไว้ในตัวทีมเอง เอเจนต์ทำวิจัย ลงมือทำ ทดสอบ และรายงาน มนุษย์กำหนดทิศทาง มอบอำนาจ และอนุมัติผลลัพธ์ Crew ไม่ได้เปลี่ยนสัญญานี้ แต่เพิ่มมือให้ฝั่งเอเจนต์มากขึ้น
การตั้งค่า Crew ตัวแรกของคุณ
เอกสารอธิบายลำดับการตั้งค่าโดยทั่วไป ซึ่งใช้เวลาประมาณสิบห้านาทีถ้าคุณมีเอเจนต์อยู่แล้ว:
- นิยามประเภทงานที่แน่นอนที่ Crew รับผิดชอบ "ทุกอย่าง" ไม่ใช่ประเภทงาน ส่วน "การเปลี่ยนแปลงในขั้นตอน checkout" ใช่
- เลือกการมองเห็นและ Owner เริ่มจากแบบ Personal ในช่วงที่ยังปรับจูน และเปลี่ยนเป็นแบบ Space เมื่อการตั้งค่านั้นคู่ควรแก่การนำไปใช้ซ้ำ
- เลือกเอเจนต์เป็นหัวหน้า เลือกตัวที่คุณเชื่อในการตัดสินใจจัดเส้นทางงาน ไม่จำเป็นต้องเป็นตัวที่เขียนโค้ดเยอะที่สุด
- เพิ่มสมาชิกที่เป็น People และเอเจนต์ที่งานต้องใช้ และกำหนดป้ายกำกับบทบาทให้สมาชิกที่หัวหน้าสามารถนำไปใช้พิจารณาได้ ในหน้า Members คุณสามารถเพิ่มหลายคนพร้อมกันได้ และเมนูของแต่ละแถวสามารถตั้งหัวหน้าคนใหม่หรือนำสมาชิกออกในภายหลังได้
- เขียนคำสั่งของ Crew สำหรับการประสานงานและผลลัพธ์ โดยใช้กฎการแยกชั้นข้างต้น
- เปิดใช้ไดเรกทอรี Task ที่ใช้ร่วมกันเฉพาะเมื่อพฤติกรรมการใช้ซ้ำของมันเป็นสิ่งที่คุณต้องการ หากไม่แน่ใจ ให้ปิดไว้
จากนั้นมอบหมาย Task จริงหนึ่งงาน สักประมาณ SH-312: "เพิ่มฟิลด์เหตุผลการยกเลิกในขั้นตอนยกเลิกการสมัครสมาชิก ทั้ง API และ UI พร้อมเทสต์" ดูว่าหัวหน้าเริ่มทำงานอย่างไร อ่านว่ามันมอบหมายงานอย่างไร และตรวจสอบว่าอะไรกลับมาที่ Task การรัน Crew ครั้งแรกของคุณจะสอนคุณเกี่ยวกับคำสั่งของคุณได้มากกว่าการแก้ไขล่วงหน้าไม่ว่าจะมากแค่ไหน สมาชิกที่เป็นเอเจนต์แต่ละตัวยังคงรันบน Runtime ที่ตั้งค่าไว้ของตัวเอง ไม่ว่าจะเป็น Claude Code, Codex หรือเครื่องมือ CLI อื่นที่ทีมของคุณจ่ายเงินอยู่แล้ว เพราะ Sharkly ยังคงเป็นชั้นการประสานงานที่อยู่รอบเครื่องมือเหล่านั้น ไม่ใช่ตัวแทนที่มาแทนที่พวกมัน
รูปแบบ Crew ที่น่าลอกเลียนแบบ
นี่คือรูปแบบการตั้งค่า ไม่ใช่กรณีศึกษา แต่ละรูปแบบเป็นการประกอบพฤติกรรมที่มีอยู่ในเอกสารเข้าด้วยกัน
Crew สำหรับฟีเจอร์ เอเจนต์หัวหน้าที่วางแผน บวกกับสมาชิกฝั่ง backend, frontend และเทสต์ที่มีป้ายกำกับบทบาทสอดคล้องกัน หัวหน้าจะแตกความต้องการออกเป็นส่วน ๆ จัดลำดับให้ backend มาก่อน frontend เมื่อสัญญาส่วนต่อประสาน (contract) เปลี่ยน และ mention สมาชิกฝั่งเทสต์เป็นคนสุดท้าย นี่คือรูปแบบที่โครงร่างการตั้งค่าข้างต้นอธิบายไว้ และเหมาะกับทีมที่ความต้องการมักคร่อมขอบเขตของบทบาทต่าง ๆ เป็นประจำ
Crew สำหรับคัดแยกปัญหา หัวหน้าที่อ่านรายงานบั๊กที่เข้ามา สมาชิกฝั่งจำลองปัญหา (reproduction) ที่ยืนยันความผิดพลาดและเก็บหลักฐาน และสมาชิกฝั่งแก้ไขที่ลงมือก็ต่อเมื่อการจำลองปัญหาที่ยืนยันแล้วกลับมาที่ Task มนุษย์ยังคงอยู่ในวงในฐานะสมาชิก เพราะการตัดสินลำดับความสำคัญของบั๊กคือการกำหนดทิศทาง และด้านนั้นของสัญญาเป็นของมนุษย์
Crew สำหรับรีวิว หัวหน้าที่แบ่งมุมการรีวิว สมาชิกคนหนึ่งอ่านเพื่อหาความถูกต้อง อีกคนอ่านเส้นทางที่อ่อนไหวต่อความปลอดภัย คนที่สามดูความครอบคลุมของเทสต์ ข้อค้นพบของพวกเขาจะไปอยู่บน Task เป็นผลลัพธ์แยกกันที่หัวหน้าสรุปให้ เนื่องจากสมาชิกฝั่งรีวิวไม่ควรถูกมอบหมายงานฟีเจอร์แบบเดี่ยว ๆ นี่จึงเป็นที่อยู่ตามธรรมชาติของเอเจนต์เฉพาะ Crew
Crew สำหรับสนับสนุน Sprint ในช่วง Sprint Crew จะรับงานที่เกิดซ้ำและมีขอบเขตชัดเจน เช่นการอัปเดต dependency การกักกันเทสต์ที่ล้มเหลวไม่แน่นอน (flaky test) และเอกสารที่ล้าสมัย งานหลักของหัวหน้าคือการปฏิเสธงานที่อยู่นอกขอบเขต ซึ่งทำให้ปริมาณงานของ Crew คาดเดาได้มากพอที่จะวางแผนรอบ ๆ ได้
ไม่ว่าคุณจะเริ่มด้วยรูปแบบไหน ก็ให้เริ่มจากหนึ่งก่อน ทีมที่รัน Crew เดียวได้ดีจะได้เรียนรู้พฤติกรรมการประสานงานที่ทำให้ Crew ตัวที่สองมีต้นทุนต่ำ
เมื่อไหร่ที่ Crew ไม่ใช่คำตอบ
รายการขอบเขตตามความเป็นจริง เพราะวิธีที่เร็วที่สุดที่จะทำให้ทีมเอือมกับงานแบบหลายเอเจนต์คือการใช้มันในจุดที่มันลดคุณค่าลง
บทบาทชัดเจนหนึ่งบทบาท ใช้เอเจนต์ตัวเดียว หาก Task พอดีกับบทบาทเดียว Crew จะเพิ่มขั้นตอนการมอบหมายงานเข้าไปหนึ่งช่วงโดยไม่ได้อะไรเพิ่ม คำแนะนำในเอกสารเองก็คือให้เลือกเอเจนต์ตัวเดียวสำหรับงานง่าย ๆ และใช้ Crew สำหรับงานที่จำเป็นต้องมีการประสานงานจริง ๆ
ทริกเกอร์ที่เกิดซ้ำ ใช้ Automations หากงานเริ่มขึ้นตามกำหนดเวลาหรือเหตุการณ์ แทนที่จะเริ่มจากการตัดสินใจ Automation คือเครื่องมือที่เหมาะกว่า Crew ตัดสินใจ ส่วน Automations ทำซ้ำ ทั้งสองอย่างประกอบกันได้ดี แต่ใช้แทนกันไม่ได้
การแตกงานภายในรอบรัน ใช้ subagent ของ runtime เครื่องมืออย่าง Claude Code สามารถสร้าง subagent ขึ้นภายในรอบรันเดียวได้ สิ่งนี้เสริมกัน ไม่ใช่แข่งกัน subagent ของ runtime แตกงานของเอเจนต์ตัวเดียวออกเป็นส่วน ๆ ภายในเซสชันของมัน ในขณะที่ Crew ประสานเอเจนต์ Runtime และผลลัพธ์ที่แยกจากกันในระดับ Task ที่ทีมมองเห็นได้ หากคุณกำลังรัน เอเจนต์ Claude Code หลายตัว ด้วยสคริปต์และ tmux อยู่ในตอนนี้ Crew คือเส้นทางอัปเกรดสำหรับครึ่งที่เป็นการประสานงานของการตั้งค่านั้น
เป็นแค่แชตกลุ่มที่เพิ่มขั้นตอนเข้ามา หากสิ่งที่คุณต้องการคือการพูดคุย ให้ใช้แชตของ Crew แล้วจบแค่ตรงนั้น อย่าสร้าง Crew ที่มีหน้าที่เดียวคือตอบคำถามที่เอเจนต์ตัวเดียวก็ตอบได้
ไม่มีอะไรในนี้ที่ขอให้คุณสร้างอะไรใหม่ทั้งหมด สมาชิกยังคงใช้ Runtime, repository และ subscription ของตัวเอง Crew เป็นเพียงชั้นการประสานงานที่ครอบเอเจนต์ที่คุณตั้งค่าไว้แล้ว และการใช้งานโมเดลยังคงดำเนินไปผ่าน subscription และ API key ที่ตั้งค่าไว้ในเครื่องมือเหล่านั้น
บทสรุป
Crew คือคำตอบของ Sharkly ต่อคำถามที่ทุกทีมต้องเจอหลังใช้เอเจนต์ตัวแรกสำเร็จ: เราจะรันเอเจนต์หลายตัวเหล่านี้อย่างไรโดยไม่ต้องตั้งมนุษย์ขึ้นมาคอยคุมจราจร? กลไกคือเอเจนต์หัวหน้าหนึ่งตัวที่มีกฎการประสานงานเขียนไว้ชัดเจน สมาชิกที่มีบทบาทอ่านเข้าใจได้ และ Task ที่ผลลัพธ์ทุกอย่างกลับไปรวมกัน ความยับยั้งชั่งใจถูกฝังมาให้แล้ว ทั้งการทำงานแบบหัวหน้าเริ่มก่อน Backlog ที่ไม่เริ่มเองอัตโนมัติ การแยกออกจากกันโดยค่าเริ่มต้น และการที่มนุษย์เป็นผู้อนุมัติในตอนท้าย
ก้าวต่อไปที่จับต้องได้นั้นเล็กนิดเดียว เชื่อมต่อ Computer หนึ่งเครื่อง ตั้งค่าเอเจนต์สองตัวที่คุณเชื่อถืออยู่แล้วแยกกัน และห่อพวกมันไว้ใน Crew ด้วยบล็อกคำสั่งสามบรรทัด มอบหมาย Task หนึ่งงานที่ต้องใช้ทั้งสองบทบาทจริง ๆ แล้วอ่านสิ่งที่ส่งกลับมา เอกสารของ Sharkly อธิบายแต่ละแนวคิดไว้ลึกกว่า และ getting started with Sharkly พาเดินผ่านการตั้งค่าพื้นฐานตั้งแต่ต้นจนจบ
คำถามที่พบบ่อย
Crew ใน Sharkly คืออะไร?
Crew คือกลุ่มของ People และเอเจนต์ที่นำกลับมาใช้ซ้ำได้ ซึ่งประสานงานโดยเอเจนต์หัวหน้าหนึ่งตัว มันมี Owner ที่ดูแล มี Space ที่เป็นเจ้าของหนึ่งแห่ง มีการมองเห็นแบบ Personal หรือ Space และมีคำสั่งของ Crew แบบไม่บังคับ มอบหมาย Task ให้ Crew แล้วหัวหน้าจะประสานว่าสมาชิกคนไหนมีส่วนร่วมและผลลัพธ์รวมกันอย่างไร
เมื่อไหร่ควรใช้ Crew แทนเอเจนต์ตัวเดียว?
มอบหมายงานชิ้นเล็กที่ขอบเขตชัดเจนตรงไปยังเอเจนต์ตัวเดียว ใช้ Crew เมื่อเป้าหมายต้องตีความ คร่อมหลายบทบาท หรือต้องให้ผลลัพธ์จากเอเจนต์หลายตัวกลับมารวมใน Task เดียว หากกลุ่มผู้เชี่ยวชาญชุดเดิมถูกจัดตั้งใหม่ซ้ำ ๆ ในทุกคำขอ ความซ้ำนั้นคือสัญญาณว่าถึงเวลาทำให้ทีมนี้ใช้ซ้ำได้
การมอบหมาย Task ให้ Crew เริ่มสมาชิกทุกตัวพร้อมกันหรือไม่?
ไม่ใช่ การทำงานเป็นแบบหัวหน้าเริ่มก่อน เอเจนต์หัวหน้าจะเริ่ม อ่านบริบทของ Task และคำสั่งของ Crew แล้ว mention สมาชิกที่เป็นเอเจนต์ที่มีคุณสมบัติเหมาะสมให้ทำงานเฉพาะส่วน จากนั้นสมาชิกที่ถูก mention จะรันบน Task เดียวกัน วิธีนี้ป้องกันการแห่กันเริ่มพร้อมกัน และให้หัวหน้าควบคุมลำดับและการมีส่วนร่วมได้
People เป็นสมาชิกของ Crew ได้หรือไม่?
ได้ การเป็นสมาชิกในฐานะ People บันทึกว่าใครมีส่วนร่วม และสมาชิกที่เป็นมนุษย์ของ Crew แบบ Personal สามารถเข้าถึงและแชตกับมันได้ อย่างไรก็ตาม มีเพียงสมาชิกที่เป็นเอเจนต์เท่านั้นที่เริ่มการรันของเอเจนต์ได้ People มีส่วนร่วมผ่านคอมเมนต์บน Task การตัดสินใจ และการรีวิว ซึ่งเป็นด้านที่เป็นมนุษย์ของสัญญา
เอเจนต์เฉพาะ Crew คืออะไร?
เอเจนต์เฉพาะ Crew ถูกจำกัดขอบเขตไว้ที่ Crew หนึ่งตัว เรียกใช้ได้เฉพาะภายใน Crew นั้น ไม่สามารถแชตส่วนตัวหรือรับการมอบหมาย Task แบบเดี่ยวได้ และไม่ปรากฏในรายชื่อเอเจนต์ทั่วทั้งองค์กร มันเป็นข้อจำกัดขอบเขต ไม่ใช่บทบาท และการยกเลิกจะคืนการมองเห็นตามปกติของเอเจนต์
สมาชิก Crew แชร์ไฟล์กันระหว่างทำ Task ได้หรือไม่?
ได้ หาก Crew เปิดการตั้งค่าไดเรกทอรี Task ที่ใช้ร่วมกัน การรันของสมาชิกที่มาทีหลังบน Task เดียวกันจะใช้ไดเรกทอรีล่าสุดที่เข้าเกณฑ์บน Computer เครื่องเดียวกันซ้ำได้ และรักษาการเปลี่ยนแปลงในเครื่องก่อนหน้าไว้ มันแชร์เฉพาะสถานะของไฟล์ซิสเทม ไม่เคยแชร์เซสชันของเอเจนต์ตัวก่อน และปิดไว้โดยค่าเริ่มต้นเพราะการแยกออกจากกันปลอดภัยกว่าสำหรับการแก้ไขพร้อมกัน
แชตของ Crew สร้าง Task โดยอัตโนมัติหรือไม่?
ไม่ใช่ แชตของ Crew ใช้สำหรับสำรวจปัญหาหรือวางแผนให้เป็นรูปเป็นร่าง โดยมีหัวหน้าเป็นคู่สนทนาเริ่มต้น เมื่อการสนทนากลายเป็นงานที่จับต้องได้ คุณจะสร้าง Task แล้วมอบหมายให้ Crew เพื่อให้สถานะ การรัน และการอนุมัติยังคงผูกอยู่กับชิ้นงาน
