แชทกับ AI Agent หรือมอบหมายงาน? ควรใช้แบบไหนเมื่อไหร่

คุณจะคุยกับ AI agent หรือจะมอบหมายงานให้มันก็ได้ ทีมที่ใช้ coding agent ทุกวันจะมองสองสิ่งนี้เป็นเครื่องมือคนละแบบ และทีมที่สับสนระหว่างสองสิ่งนี้มักต้องจ่ายราคาในภายหลัง ทั้งการตัดสินใจที่ถูกฝังอยู่ในประวัติแชตส่วนตัว งานที่เสร็จแล้วแต่ไม่มีใครรีวิว และเพื่อนร่วมทีมที่ถามว่า “เราตกลงเรื่องนั้นกันไว้ตรงไหนนะ?” ในอีกสามสัปดาห์ถัดมา หลังจากเซสชันนั้นเลื่อนหายไปนานแล้ว

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

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

TL;DR

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

ปัญหา: agent ตัวเดียว แต่งานสองแบบ

ใครก็ตามที่รัน Claude Code หรือ Codex ในเทอร์มินัลย่อมรู้จักงานทั้งสองแบบนี้ดีอยู่แล้ว บางเซสชันเป็นแค่คำถาม เช่น โมดูลนี้ทำอะไร ทำไมเทสต์นี้ถึงรันผ่านบ้างไม่ผ่านบ้าง (flaky) ถ้าย้ายระบบจะต้องใช้ต้นทุนเท่าไร ส่วนเซสชันอื่นเป็นงานที่ต้องส่งมอบจริง เช่น แก้บั๊กนี้ ส่ง endpoint นี้ อัปเดตเอกสารชุดนี้

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

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

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

Agent Chat ใน Sharkly คืออะไร?

Agent Chat คือแชตแบบ standalone กับ Agent หรือ Crew ใช้เมื่อคุณอยากถามคำถาม สืบค้นหัวข้อ ร่างแผน หรือเริ่มงานโดยไม่ต้องเปิด task ก่อน แชตแบบ standalone แต่ละอันมีเซสชันและข้อความของตัวเอง และเซสชันนั้นเป็นของคนที่สร้างมันขึ้นมา

Sharkly มีช่องทางแชตสองแบบ และเอกสารก็ย้ำชัดเจนให้แยกทั้งสองออกจากกัน:

• Standalone Agent Chat อยู่ภายนอก task ใด ๆ คุณเปิดมุมมองแชตของ Agent ส่งข้อความ แล้วเซสชันใหม่จะเริ่มขึ้น มันคือพื้นที่ทำงานส่วนตัวของคุณกับ Agent ตัวนั้น
• Agent chat บน task อยู่บน task นั้น ไม่ใช่คอมเมนต์ของ task และไม่จำเป็นต้อง assign task ให้ Agent ตัวนั้นก่อน

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

แชตไม่ใช่คอมเมนต์ การส่งข้อความใน Agent Chat ไม่ได้สร้างคอมเมนต์ใน task และการส่งข้อความใน Agent chat ของ task ก็ไม่ปรากฏใน Activity ในฐานะคอมเมนต์เช่นกัน คอมเมนต์ของ task ยังคงเป็นบันทึกหลักสำหรับการสนทนาภายใน task ส่วนแชตเป็นบันทึกแยกต่างหากบนทั้งสองช่องทาง

แชตไม่ปรากฏให้ทีมเห็นโดยค่าเริ่มต้น เซสชันแบบ standalone เป็นของคนที่สร้างขึ้น และสมาชิกคนอื่นในองค์กรจะไม่ได้รับสิทธิ์เข้าถึงเซสชันนั้นผ่าน chat API ในปัจจุบัน ส่วนบน task ข้อความแชตใหม่จะแจ้งเตือน Assignee และคนที่อยู่ในบทสนทนานั้นอยู่แล้ว แต่จะไม่ถูกกระจายไปถึงทุกคนที่ติดตาม task

แชตไม่จำเป็นต้องมีการ assign คุณเปิด task แล้วคุยกับ Agent ตัวใดก็ได้ใน Space เกี่ยวกับ task นั้น ไม่ว่า Agent ตัวนั้นจะเป็น Assignee หรือไม่ การ assign ควบคุมความรับผิดชอบในการรันงาน ไม่ได้ควบคุมสิทธิ์ในการสนทนา

ถ้าคุณเพิ่งเริ่มรู้จักว่า Agent คืออะไรกันแน่ (การตั้งค่าการทำงานที่บันทึกไว้ พร้อม instructions, Runtime, Skills และ repositories) บทความอธิบายเรื่อง Agentsได้ครอบคลุมพื้นฐานส่วนนี้ไว้แล้ว

Task ให้อะไรที่แชตให้ไม่ได้?

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

ประโยคเดียวนั้นซ่อนหลักประกันรูปธรรมสี่ข้อที่แชตให้ไม่ได้:

1. ความเป็นเจ้าของ Task มี Assignee เมื่ออะไรติดขัด ก็มีชื่อคนรับผิดชอบอยู่ ส่วนเซสชันแชตมีแค่รายชื่อผู้เข้าร่วม ไม่มีโครงสร้างความรับผิดชอบ
2. สถานะ Task เคลื่อนผ่านเวิร์กโฟลว์ที่ทีมคุณกำหนดไว้ เช่น backlog, started, review, done ใครก็อ่านบอร์ดแล้วรู้ได้ทันทีว่างานอยู่ตรงไหน โดยไม่ต้องถาม
3. ประวัติการรัน ทุกการรันบน Task ทิ้ง trace ไว้ ทั้งเวลาเข้าคิว เวลาเริ่มต้น เครื่องมือที่เรียกใช้ และสาเหตุที่ล้มเหลว เมื่อการรันมีปัญหา คุณอ่านบันทึกการรันได้เลย แทนที่จะต้องนั่งประกอบเหตุการณ์ขึ้นใหม่จากความทรงจำ
4. การรีวิว Agent สามารถปล่อยให้ Task รอการตอบกลับของมนุษย์หรือรอการรีวิวจากมนุษย์ได้ และสัญญาณเหล่านั้นจะไปอยู่ใน Inbox ของผู้รับผิดชอบ การยอมรับผลเป็นขั้นตอนที่ถูกบันทึกไว้ ไม่ใช่ความรู้สึก

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

นี่คือสัญญาระหว่างมนุษย์กับ agent ที่ทำให้ Task เป็นบ้านที่เหมาะกับงานจริง: Agent จะค้นคว้า ลงมือทำ ทดสอบ และรายงานผลบน Task ส่วนมนุษย์เป็นคนกำหนดทิศทาง ให้อำนาจ และยอมรับผลลัพธ์ เซสชันแชตรองรับครึ่งแรกของสัญญานี้ มีเพียง Task เท่านั้นที่รองรับครึ่งหลัง

Agent chat กับ task assignment: ตารางช่วยตัดสินใจ

การตัดสินใจขึ้นอยู่กับว่างานนั้นต้องบันทึกอะไรไว้ ไม่ใช่ขนาดของงาน

ใช้แชตเมื่อคุณกำลังถาม เปรียบเทียบ สืบค้น หรือร่างอะไรบางอย่าง ใช้ Task เมื่องานต้องมี Assignee มีสถานะ มีเกณฑ์การยอมรับ หรือมีผลลัพธ์ที่ต้องมีคนอนุมัติ

มีกฎสวนทางสองข้อที่ซื่อสัตย์พอจะกันไม่ให้เรื่องนี้กลายเป็นลัทธิ:

อย่าสร้าง Task ให้ทุกคำถาม “โมดูลนี้ทำอะไร?” ควรได้แชต ไม่ใช่ตั๋วงาน บอร์ดที่เต็มไปด้วย Task หน้าตาเหมือนคำถามคือความวุ่นวายที่กลบงานจริง และความวุ่นวายคือสิ่งที่ระบบจัดการงานสำหรับทั้งมนุษย์และ agentถูกสร้างขึ้นมาเพื่อป้องกัน

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

โหมดแชตทั้งสาม: Explore, Plan, Execute

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

Explore คือการสืบค้นแบบอ่านอย่างเดียว Agent จะตรวจสอบ อธิบาย เปรียบเทียบ และสรุป โดยไม่แก้ไขอะไร เปิดโหมด Explore ไว้เมื่อคุณต้องการแค่การวิเคราะห์และไม่ต้องการอย่างอื่น นี่คือโหมดสำหรับ “ช่วยอธิบาย auth flow ให้ฟังหน่อย” และ “โค้ดเบสใช้ไลบรารีตัวไหนในสองตัวนี้อยู่แล้ว”

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

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

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

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

วิธีส่งต่อบทสนทนาไปเป็น Task

การส่งต่อคือจุดที่สองช่องทางมาบรรจบกัน และเอกสารของ Sharkly กำหนดลำดับขั้นไว้อย่างชัดเจน เมื่อการหารือก่อให้เกิดการกระทำที่ควรลงมือทำจริง:

1. สรุปผลลัพธ์ในแชต ขอให้ Agent ระบุเป้าหมาย ขอบเขต ข้อจำกัด และเกณฑ์การยอมรับไว้ในข้อความเดียว นี่คือย่อหน้าที่ Task ต้องการ และ Agent ก็มีบริบทพร้อมอยู่แล้วที่จะเขียนมันขึ้นมา
2. ใช้โหมด Plan เพื่อร่าง Task สลับไปที่ Plan แล้วให้ Agent เสนอ task พร้อมงานย่อย ตรวจทานข้อเสนอและแก้ไขก่อนยืนยัน หรือจะข้ามขั้นนี้แล้วสร้าง Task ด้วยตัวเองก็ได้ ประเด็นคือต้องมีคนกำหนดรูปร่างของงานที่ตกลงจะทำ
3. ยืนยัน จะเริ่มงานด้วยหรือไม่ก็ได้ การยืนยันจะสร้าง Task ที่วางแผนไว้ขึ้นมา ยืนยันและเริ่มเลยเมื่องานควรเริ่มตอนนี้ ยืนยันโดยไม่เริ่มเมื่องานต้องรอ Sprint หรือรอ dependency
4. Assign มัน ส่ง Task ไปให้คน Agent หรือ Crew ที่ใช่ ผ่านตัวควบคุม Assignee บทสรุปจากแชตที่กำหนดขอบเขตมาดีคือสิ่งที่ทำให้งานนี้ assign ได้ตั้งแต่แรก สำหรับงานที่ต้องใช้หลายบทบาท Crew ที่มี Agent เป็นหัวหน้าทีมสามารถรับ Task ทั้งอันได้ แทนที่จะเป็นผู้รันเพียงตัวเดียว
5. ย้ายบริบท ไม่ใช่ย้ายบทสนทนาทั้งหมด คัดลอกทุกสิ่งที่ Task ต้องเก็บไว้ลงในคำอธิบายหรือคอมเมนต์ เซสชันแชตยังคงเป็นประวัติแยกส่วนของคุณ อย่าใช้มันเป็นความทรงจำของทีม เพราะทีมมองไม่เห็นมัน

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

หมายเหตุเรื่องการวางตำแหน่งสักหน่อย: Task ที่ถูก assign ให้ Agent จะไม่เริ่มทำงานตราบใดที่ยังอยู่ใน Backlog เพราะ Backlog คือพื้นที่จอดงานไว้ก่อน การย้าย Task ออกจาก Backlog จะเริ่ม Agent ที่ได้รับมอบหมายเมื่อ Computer และ Runtime ของมันพร้อม ดังนั้นคุณเตรียมงานจากแชตไว้ได้เลย แล้วปล่อยให้เริ่มทำงานเมื่อทีมพร้อม ส่วนการรันเกิดขึ้นจริงที่ไหนเป็นอีกเรื่องหนึ่ง ซึ่งอธิบายไว้ในบทความอธิบายเรื่อง Computers

Quick chats: เข้าถึงบริบทของ task โดยไม่ต้องออกจาก task

ยังมีช่องทางที่สามที่ควรรู้เมื่อเข้าใจพื้นฐานแล้ว หน้ารายละเอียด task มี quick chat อยู่ในแถบเครื่องมือด้านบน คือชุดค่าตั้ง prompt บวก Agent ที่บันทึกไว้ แล้วรันโดยใช้ task ปัจจุบันเป็นบริบท

quick chat แต่ละอันมีชื่อ มี prompt (ซึ่งไม่บังคับ) มี Agent หรือ Crew ที่เลือกไว้ และมีการตั้งค่าการมองเห็น quick chat แบบ private จะเห็นและเรียกใช้ได้เฉพาะคนสร้าง ส่วน quick chat แบบ shared จะเห็นได้ทุกคนใน Space แม้ว่ามีเพียงคนสร้างเท่านั้นที่แก้ไขได้ เมื่อเลือกอันหนึ่ง จะเปิดมุมมองแบบแบ่งครึ่ง โดย task อยู่ซ้ายและแชตอยู่ขวา และ prompt, Agent รวมถึงบริบทของ task จะถูกส่งไปพร้อมกัน

นี่เปลี่ยนคำถามที่เกิดซ้ำ ๆ ให้กลายเป็นการทำงานคลิกเดียว quick chat แบบ shared ชื่อ “Estimate this” ที่ส่ง task ไปให้ Agent สายวางแผน หรือ “Find related code” ที่ผูกกับ Agent ที่เข้าใจ repository กลายเป็นสิ่งที่ทุกคนใน Space เรียกใช้กับ task ใดก็ได้ นี่เป็นแนวคิดเดียวกับที่ขับเคลื่อน Skills คือคุณค่ามาจากการแชร์การตั้งค่าที่ดี ไม่ใช่จากการที่ใคร ๆ เปิดแชตเพิ่มขึ้นเรื่อย ๆ

มีกลไกสองอย่างที่ต้องเข้าใจให้ถูก ทุกครั้งที่เรียกใช้ quick chat จะสร้างบทสนทนาระดับ task ของตัวเองขึ้นมา และบทสนทนานั้นจะอยู่บน Task ไม่ได้ใช้แชตปกติของ Agent ที่ถูก assign และการลบ quick chat จะลบแค่การตั้งค่าที่บันทึกไว้ ไม่ได้ลบบทสนทนาที่สร้างขึ้นจากมันไปแล้ว

ถ้า stack ของคุณไม่มีเลเยอร์สำหรับ task ล่ะ?

หลายทีมรัน agent โดยไม่มีแพลตฟอร์มประสานงานเลย ใช้เซสชันเทอร์มินัลดิบ ๆ, pane ของ tmux, สคริปต์ shell การตั้งค่าแบบนั้นรับมือครึ่งที่เป็นแชตของความแตกต่างในบทความนี้ได้พอใช้ได้ เซสชันเทอร์มินัลก็คือบทสนทนาส่วนตัวเพื่อสำรวจกับ agent เหมือนกับ Agent Chat นั่นเอง

สิ่งที่ stack แบบ DIY ขาดไปคืออีกครึ่งหนึ่ง ไม่มี Assignee ไม่มีสถานะ ไม่มี trace การรันให้เพื่อนร่วมทีมเปิดดู ไม่มีขั้นตอนรีวิว และไม่มีที่ที่ผลลัพธ์จะตกไปอยู่โดยอัตโนมัติ เซสชันแบบงานที่ต้องส่งมอบทุกอันดูไม่ต่างจากเซสชันแบบคำถาม และความต่างจะปรากฏก็ต่อเมื่อมีอะไรพังแล้วไม่มีใครประกอบเหตุผลขึ้นมาใหม่ได้ บทความเปรียบเทียบClaude Squad, Conductor และการตั้งค่าบน tmuxจะพาไปดูว่าแต่ละวิธีไปได้ไกลแค่ไหน

คุณไม่จำเป็นต้องรื้อกระบวนการทั้งหมดเพื่อเติมส่วนที่ขาด Sharkly ไม่ได้มาแทนที่ Claude Code, Codex หรือเครื่องมือรันอื่น ๆ แต่เพิ่มชั้นของ task บริบท และการรีวิวที่ใช้ร่วมกันให้กับเครื่องมือที่ทีมคุณใช้อยู่แล้ว โดยการใช้งานโมเดลยังคงเป็นไปตาม subscription หรือ API key ที่ตั้งค่าไว้ในเครื่องมือเหล่านั้น ถ้าคุณชอบทำงานทดลองในเทอร์มินัลก็ใช้ต่อได้ ส่งงานที่ตกลงจะทำจริงผ่าน Task และถ้าตั๋วงานของคุณอยู่ที่อื่นอยู่แล้ว ตั๋ว Jira ก็ส่งตรงให้ Agent ได้เลย โดยทีมไม่ต้องเปลี่ยนเครื่องมือติดตามงาน

สามสถานการณ์จำลอง

เทสต์ที่รันผ่านบ้างไม่ผ่านบ้าง วิศวกรคนหนึ่งสังเกตว่าเทสต์ตัวหนึ่งล้มเหลวเป็นระยะ เธอเปิดแชตกับ Code Reader Agent ของทีมในโหมด Explore ว่า “ทำไม auth_session_test ถึงล้มเหลวเวลารันแบบขนาน?” ผ่านไปสิบนาทีของการไล่อ่าน Agent ก็ชี้ไปที่ fixture ที่ใช้ร่วมกันซึ่งมีปัญหา race ตรงนี้กลายเป็นงานที่ต้องลงมือทำจริงแล้ว เธอสลับไปโหมด Plan Agent ร่าง task SH-341 พร้อมขอบเขตการแก้และเกณฑ์การยอมรับ (“เทสต์ต้องผ่าน 50 รอบการรันแบบขนานติดต่อกัน”) เธอยืนยันและเริ่มงาน แล้ว assign ให้ Agent สายแก้บั๊ก การสืบค้นยังอยู่ในประวัติแชตของเธอ ส่วนการแก้ไข diff และการรีวิวไปอยู่บน SH-341

คำถามเรื่องสถาปัตยกรรม หัวหน้าทีมเทคอยากรู้ว่าถ้านำ queue มาใช้ จะมีต้นทุนเท่าไรกับสามบริการ นี่ใช้เวลาอ่านหลายวัน แต่ก็ยังเป็นแค่คำถาม จึงอยู่ในเซสชันแชตแบบ standalone ที่เธอเปลี่ยนชื่อเป็น “การศึกษาเรื่องการนำ queue มาใช้” ตลอดหนึ่งสัปดาห์เธอกลับมาที่เซสชันนี้ ถามคำถามต่อยอด และปล่อยให้ Agent เปรียบเทียบทางเลือก เมื่อผู้บริหารตอบตกลง บทสรุปสุดท้ายของเซสชันก็กลายเป็นคำอธิบายของ Task ระดับ epic ซึ่งถูกแตกออกเป็นงานย่อยในโหมด Plan ไม่มีอะไรถูกติดตามแบบครึ่ง ๆ กลาง ๆ เลย

คำถามใน standup ที่กลับมาทุกวัน ทีมหนึ่งสังเกตว่าทุกเช้าจะมีคนขอให้ Agent สรุปการเปลี่ยนแปลงของเมื่อวานบน task ที่กำลังรีวิวอยู่ มีคนหนึ่งบันทึกสิ่งนั้นเป็น quick chat แบบ shared ชื่อ “What changed here?” ที่ผูกกับ Agent ที่เข้าใจ repository คำถามนี้ก็ไม่ต้องพิมพ์ซ้ำอีก และทุกครั้งที่เรียกใช้ บทสนทนาจะอยู่บน task ที่มันรันด้วย หากต้องการสรุปตามกำหนดเวลาแทนที่จะต้องสั่งเอง สัญชาตญาณเดียวกันนี้ก็ต่อยอดไปเป็น Automations ได้

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

บทสรุป

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

การแยกความต่างนี้ไม่มีต้นทุนอะไรในการนำไปใช้ เพราะทั้งสองช่องทางอยู่ตรงหน้าคุณอยู่แล้ว เปิดแชตกับ Agent แล้วถามอะไรที่ปกติคุณต้องไปขุดในโค้ดเบส ครั้งแรกที่บทสนทนานั้นสร้างสิ่งที่น่าลงมือทำ สลับไปโหมด Plan แล้วให้มันร่าง Task ขึ้นมา เชื่อมต่อ Computer สักหนึ่งเครื่อง สร้าง Agent สักหนึ่งตัว แล้วลองใช้ทั้งสองครึ่งกับงานน่าเบื่อ ๆ สักงาน บทความภาพรวมแพลตฟอร์มจะพาดูส่วนที่เหลือของแพลตฟอร์มเมื่อคุณพร้อม

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

คุยกับ Agent เรื่อง task โดยไม่ต้อง assign ได้ไหม?

ได้ เปิด task แล้วเริ่มแชตกับ Agent ตัวใดก็ได้ใน Space การ assign ไม่ใช่เงื่อนไขเบื้องต้นของการสนทนา เพราะมันควบคุมว่าใครเป็นคนรัน task ไม่ได้ควบคุมว่าคุณคุยกับใครได้

ข้อความแชตจะปรากฏใน Activity ของ task ไหม?

ไม่ คอมเมนต์จะปรากฏใน Activity ให้ทั้งทีมเห็น ส่วน Agent chat บน task จะแจ้งเตือน Assignee และคนที่อยู่ในบทสนทนานั้นอยู่แล้ว และถูกเก็บแยกจากคอมเมนต์บนทั้งสองช่องทาง

เพื่อนร่วมทีมอ่านเซสชัน Agent Chat แบบ standalone ของฉันได้ไหม?

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

ถ้าฉันส่งข้อความหา Agent ที่ออฟไลน์หรือถูก archive ไว้จะเกิดอะไรขึ้น?

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

ควรเริ่มด้วยโหมดแชตไหน?

แชตใหม่จะเริ่มที่โหมด Execute เว้นแต่คุณเปลี่ยนค่าเริ่มต้น ถ้าต้องการวิเคราะห์โดยไม่มีการเปลี่ยนแปลง ให้สลับไป Explore ก่อนส่งข้อความแรก ใช้ Plan เมื่อคุณอยากให้ Agent เสนอ task ที่คุณจะรีวิวและยืนยัน

การคุยกับ Agent ใช้การตั้งค่าการรัน task ของฉันด้วยไหม?

ใช่ การรันในแชตใช้การตั้งค่า Agent ชุดเดียวกับงานปกติ ทั้ง instructions, Runtime และ Computer ในโหมด Execute Agent จะลงมือผ่าน CLI ที่ตั้งค่าไว้ ซึ่งเป็นกลไกเดียวกับที่ขับเคลื่อนการรันบน task

เมื่อไรควรเปลี่ยนแชตให้กลายเป็น Task?

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

คนสองคนแชร์เซสชันแชตกับ Agent เดียวกันได้ไหม?

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