เริ่มต้นใช้งาน Sharkly ใน 10 นาที

เริ่มต้นใช้งาน Sharkly ใช้เวลาประมาณสิบนาที: เชื่อมต่อ Computer สร้าง Agent และมอบหมาย Task เล็ก ๆ หนึ่งงาน Sharkly คือระบบบริหารงานสำหรับ People และ Agents ที่เปลี่ยนเครื่องมือเขียนโค้ดด้วย AI อย่าง Claude Code และ Codex ให้กลายเป็นเพื่อนร่วมทีมที่มอบหมายงานได้ภายในระบบงานที่ใช้ร่วมกัน เพื่อให้การลงมือทำงานไม่หายไปในเทอร์มินัลส่วนตัวอีกต่อไป นี่คือขั้นตอนทั้งหมดสำหรับการรันครั้งแรก:

1. ลงชื่อเข้าใช้และสร้าง (หรือเข้าร่วม) Organization ที่มี Space ที่ใช้งานอยู่หนึ่งรายการ
2. เชื่อมต่อ Computer ผ่าน Sharkly Desktop หรือ Sharkly CLI
3. ยืนยันว่ามี Runtime อย่างน้อยหนึ่งรายการ เช่น Claude Code ขึ้นสถานะพร้อมใช้งาน
4. สร้าง Agent ที่มีบทบาทแคบและมีคำสั่งชัดเจน
5. เขียน Task ขนาดเล็กที่ขอบเขตชัดเจน แล้วมอบหมายให้ Agent
6. ตรวจดูผลลัพธ์บน Task แล้วตอบกลับด้วยคอมเมนต์ติดตามผล

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

ทำไมสิบนาทีแรกกับ Sharkly จึงสำคัญ

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

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

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

สี่แนวคิดเบื้องหลังการตั้งค่า Sharkly ทุกแบบ

มีคำนามสี่คำที่รองรับโมเดลทั้งหมดนี้ เข้าใจสี่คำนี้ให้ดี แล้วทุกอย่างหลังจากนี้จะไม่สร้างความสับสนให้คุณ

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

Agent คือชุดการตั้งค่าการทำงานที่บันทึกไว้ ไม่ใช่พรอมป์แบบใช้ครั้งเดียว การตั้งค่าอย่างพิถีพิถันของใครคนหนึ่ง (คำสั่ง, repositories ที่ผูกไว้, สภาพแวดล้อม, timeout) จะนำกลับมาใช้ซ้ำได้ทั่วทั้ง Space เมื่อแชร์ Agent นั้น

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

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

สิ่งที่ต้องเตรียมก่อนเริ่ม

รายการสิ่งที่ต้องมีก่อนเริ่มนั้นสั้นมาก:

• บัญชี Sharkly และ Organization หนึ่งแห่ง;
• Space ที่ใช้งานอยู่อย่างน้อยหนึ่งรายการ;
• คอมพิวเตอร์ที่รัน Sharkly Desktop หรือ local service ได้;
• Runtime ที่รองรับซึ่งติดตั้งและยืนยันตัวตนแล้วบนเครื่องนั้น เช่น Claude Code, Codex หรือ Gemini CLI;
• สิทธิ์เข้าถึง Git บนเครื่องนั้น หาก Task แรกของคุณแตะ repository แบบส่วนตัว

มีข้อควรทราบสองเรื่องเกี่ยวกับฝั่งโมเดล ข้อแรก คุณต้องมี subscription ของตัวเอง การใช้งานโมเดลยังคงผ่าน subscription หรือ API key ที่ตั้งค่าไว้ในเครื่องมือเหล่านั้น และโควตาของคุณขึ้นอยู่กับแผนและบัญชีที่ทีมของคุณเชื่อมต่อ ข้อสอง Agent จะใช้โมเดลเริ่มต้นของ Runtime โดยไม่มีการเปิดให้เลือกโมเดล คุณต้องเปลี่ยนโมเดลในการตั้งค่าของ Runtime เอง ไม่ใช่ที่ Agent

คุณจัดระเบียบ Task ได้โดยไม่ต้องมี Computer เชื่อมต่ออยู่ แต่ Agent จะลงมือทำงานไม่ได้จนกว่า Runtime ที่เข้าเกณฑ์จะออนไลน์ นั่นคือเหตุผลที่การเชื่อมต่อเป็นขั้นตอนแรก

ถ้า Organization ของคุณยังไม่มี Space ที่ใช้งานอยู่ Sharkly จะแนะนำขั้นตอนการสร้างให้ เลือกหมวดหมู่งานเพื่อสร้าง task type ที่เหมาะสมไว้ล่วงหน้า: งานพัฒนาซอฟต์แวร์จะเริ่มด้วย Requirement, Bug, Task และ User Story Space แรกจะเป็นสาธารณะต่อ Organization โดยค่าเริ่มต้น และคุณสามารถจำกัดสิทธิ์การเข้าถึงให้แน่นขึ้นได้ภายหลัง

ขั้นตอนที่ 1: เชื่อมต่อ Computer

เปิด Settings แล้วไปที่ Computers และเลือก Connect Computer มีสองเส้นทางที่ครอบคลุมเกือบทุกคน:

• Sharkly Desktop สำหรับคอมพิวเตอร์ส่วนบุคคลที่รองรับ ติดตั้ง ลงชื่อเข้าใช้ แล้วมันจะลงทะเบียนเครื่องและเริ่ม local service ให้คุณ
• Sharkly CLI พร้อม local service สำหรับโฮสต์ระยะไกลหรือเครื่อง Linux สร้าง install token แบบใช้ครั้งเดียวในกล่องโต้ตอบการเชื่อมต่อ แล้วรันคำสั่งที่สร้างขึ้นบนเครื่องเป้าหมาย:

sharkly computer register --install-token sit_9f2ka7x1mrq8

install token มีอายุสั้นและใช้ได้ครั้งเดียว อย่าใส่ไว้ในอิมเมจที่ใช้ซ้ำได้ ในสคริปต์ ใน Task หรือในคอมเมนต์ และมันมีหน้าที่แคบมาก: install token ใช้ลงทะเบียน Computer เท่านั้น ไม่ได้สร้างการลงชื่อเข้าใช้ CLI สำหรับคน ส่วน personal access token (ที่ขึ้นต้นด้วย shk_) ใช้จัดการเรื่องนั้นแยกต่างหาก

รอจน Computer แสดงว่าต่อติดแล้ว จากนั้นเปิดหน้ารายละเอียดของมัน Runtime แต่ละตัวที่ตรวจพบจะรายงานสถานะความสามารถ: Available, Needs configuration, Not installed หรือ Unsupported ความแตกต่างนี้ช่วยคุณเลี่ยงความสับสนที่พบบ่อยที่สุดในช่วงเริ่มต้น การที่ Computer ออนไลน์หมายความแค่ local service กำลังส่ง heartbeat อยู่เท่านั้น ไม่ได้หมายความว่า Runtime ที่คุณเลือกจะรัน Task ได้ ถ้าภายหลังการรันไม่ยอมเริ่ม ให้ตรวจสถานะความสามารถของ Runtime ก่อนที่จะไปไล่แก้ปัญหาการเชื่อมต่อ

คุณตรวจสอบจากเทอร์มินัลก็ได้เช่นกัน:

sharkly computer list
sharkly computer show cmp_4c81d2
sharkly computer ping cmp_4c81d2 rt_claude_code

เอกสารเรื่อง Computers อธิบายเรื่องการวินิจฉัย การสร้าง Runtime แบบกำหนดเอง การมองเห็น และการตั้งค่าการล้างข้อมูลไว้อย่างละเอียด

ขั้นตอนที่ 2: สร้าง Agent ตัวแรกของคุณ

เปิด Agents แล้วเลือก New Agent อย่าเพิ่งรีบสร้างผู้ช่วยที่ทำได้ทุกอย่าง เริ่มจากบทบาทแคบ ๆ ก่อน เพราะคำอธิบายที่เจาะจงจะบอก People ว่าควรมอบหมายอะไร ส่วนคำสั่งจะบอก Agent ว่าต้องทำงานอย่างไร

การตั้งค่าครั้งแรกที่ดีมีหน้าตาแบบนี้:

• Name: Code Reader
• Description: อ่าน repository อธิบายการทำงานปัจจุบัน และรายงานความเสี่ยงโดยไม่แก้ไขไฟล์
• Visibility: Personal หรือ Space ที่จะใช้งาน Agent นี้
• Computer และ Runtime: การเชื่อมต่อที่คุณตรวจสอบไว้ในขั้นตอนที่ 1

สำหรับคำสั่ง ตัวอย่างใน Quickstart นั้นคัดลอกมาใช้ได้เกือบทั้งดุ้น:

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

สังเกตว่าคำสั่งครอบคลุมอะไรบ้าง: ขอบเขต วิธีตรวจดูก่อนลงมือ และรูปแบบการรายงาน นั่นคือระดับที่เหมาะสม ใส่พฤติกรรมที่คงที่ไว้ในคำสั่งของ Agent ใส่ข้อกำหนดเฉพาะของ Task ไว้ในคำอธิบาย Task และใส่ขั้นตอนที่นำกลับมาใช้ซ้ำได้ซึ่ง Agent หลายตัวใช้ร่วมกันไว้ใน Skill การแยกสามชั้นนี้ให้ชัดคือสิ่งที่ทำให้ Agent นำกลับมาใช้ซ้ำได้แทนที่จะเปราะบาง

ขั้นตอนที่ 3: เพิ่ม repository หรือไดเรกทอรีทำงาน

ถ้า Agent ของคุณจะอ่านโค้ด มันก็ต้องมีโค้ดให้อ่าน มีสองทางเลือก:

• ผูก Git repository เข้ากับ Agent (หรือใช้ repositories ที่ตั้งค่าไว้สำหรับ Space ของ Task นั้น) การรันที่อิง repository สามารถเตรียม git worktree ใหม่ต่อ Task หนึ่งงาน ซึ่งเป็นสิ่งที่ทำให้การรันแบบขนานอย่างปลอดภัยเป็นไปได้ในภายหลัง
• ตั้งค่าไดเรกทอรีในเครื่องที่ระบุไว้ บน Computer ในเครื่อง การรันจะใช้โค้ด dependencies แคช และเครื่องมือที่มีอยู่แล้วในนั้น แทนการเตรียมสำเนาใหม่

หลักการตัดสินใจ: ใช้ไดเรกทอรีชั่วคราวที่อิง worktree สำหรับงานกับ repository ส่วนใหญ่ และเมื่อมีหลาย Task ที่อาจแก้ไข codebase เดียวกันพร้อมกัน ใช้ไดเรกทอรีที่ระบุไว้เมื่อการรันต้องใช้สภาพแวดล้อมที่สร้างใหม่แล้วแพง และจำไว้ว่าไดเรกทอรีที่ระบุไว้ให้บริการได้ครั้งละหนึ่งการรัน เรามีบทความอธิบายแบบเต็มเรื่อง worktree ช่วยไม่ให้ agent ที่รันขนานกันมาเหยียบงานกันได้อย่างไร ถ้าคุณอยากเข้าใจกลไก

ขั้นตอนที่ 4: เขียน Task ที่ Agent ลงมือทำได้

สร้าง Task ใน Space เดียวกัน ตัวอย่างใน Quickstart ตั้งใจทำให้ดูน่าเบื่อ และนั่นแหละคือประเด็น:

Title: ตรวจสอบเส้นทางข้อผิดพลาดของการยืนยันตัวตน

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

Task นี้มีคุณสมบัติสามข้อที่ Task แรกที่ดีทุกงานต้องมี คือมีขอบเขตชัดเจน (อ่าน ไม่แก้ไข) ให้ผลลัพธ์ที่ตรวจสอบได้ (สามกรณีพร้อมหลักฐาน) และมีความเสี่ยงต่ำ คุณจึงประเมินวิจารณญาณของ Agent ได้โดยไม่ต้องเสี่ยงกับ codebase ของคุณ ถ้า repository ของคุณไม่มีโค้ดเรื่องการยืนยันตัวตน ก็เปลี่ยนหัวข้อเป็นส่วนเล็ก ๆ ที่มีอยู่จริง เช่นการโหลด configuration หรือคอมโพเนนต์ empty state

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

ขั้นตอนที่ 5: มอบหมาย Task และเฝ้าดูการรัน

เปิดตัวควบคุม Assignee ของ Task แล้วเลือก Agent ของคุณ ทั้ง People, Agents และ Crews เป็น Assignee ได้ทั้งหมด การเลือก Agent จะทำให้มันเป็นผู้รับมอบหมายที่ลงมือทำ

มีกฎเรื่องสถานะข้อหนึ่งที่กำหนดว่าการทำงานจะเริ่มเมื่อไหร่ Task ที่มอบหมายให้ Agent จะไม่เริ่มการรันขณะที่ยังอยู่ใน Backlog เพราะ Backlog เป็นพื้นที่พักงานที่ใช้เตรียมงาน เมื่อย้าย Task ไปยังสถานะที่พร้อมทำงาน (ยังไม่เริ่ม หรือเริ่มแล้ว) Sharkly จะจัดคิวการรันให้เมื่อ Computer และ Runtime พร้อม สถานะ Completed, canceled และ duplicate จะไม่เริ่มการรันครั้งแรกเลย

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

• Chat สำหรับการโต้ตอบกับ Agent ในรูปแบบคอมเมนต์
• Activity สำหรับคอมเมนต์และการเปลี่ยนแปลงของ Task ในไทม์ไลน์เดียว
• Executions สำหรับประวัติการรันและร่องรอยทั้งหมด: การเรียกใช้เครื่องมือ เหตุการณ์ของ Runtime แหล่งที่มาของการทริกเกอร์ และรายละเอียดความล้มเหลว

สถานะการรันกับสถานะของ Task เกี่ยวข้องกันแต่แยกจากกัน การรันอาจอยู่ในสถานะ Running ขณะที่สถานะ Task ยังขึ้นว่า In Progress เพราะตัวหนึ่งอธิบายความคืบหน้าของการทำงาน ส่วนอีกตัวอธิบายตำแหน่งในเวิร์กโฟลว์

ขั้นตอนที่ 6: รีวิวผลลัพธ์ในฐานะผู้รีวิว ไม่ใช่ผู้ชม

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

ตรวจสอบว่า Agent:

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

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

เมื่อผลลัพธ์ผ่านการตรวจสอบแล้ว ให้ทำเครื่องหมายว่า Task เสร็จสมบูรณ์ เท่านี้ก็ปิดวงจรแรกที่เช็กลิสต์การตั้งค่าติดตามไว้: Computer เชื่อมต่อแล้ว, Agent สร้างแล้ว, repository พร้อม, Task สร้างแล้ว, มอบหมายแล้ว และเสร็จสมบูรณ์

หลังวงจรแรก: ห้าวิธีต่อยอดการตั้งค่า

การรันครั้งแรกพิสูจน์ว่าระบบเชื่อมต่อกันได้ ขั้นต่อไปคือการเพิ่มมิติทีละด้าน

จะรันมากกว่าหนึ่ง Task พร้อมกันได้อย่างไร

เพิ่ม concurrency อย่างตั้งใจ ด้วยไดเรกทอรีชั่วคราว ค่าเริ่มต้นของ concurrency คือครึ่งหนึ่งของขีดจำกัดของ Computer โดยแต่ละ Task จะได้ worktree แยกของตัวเอง การรันขนานจึงไม่ชนกัน ดูก่อนว่า CPU หน่วยความจำ และความจุของผู้ให้บริการโมเดลของคุณไหวหรือไม่ก่อนจะเพิ่มขีดจำกัด และอ่าน วิธีที่ทีมต่าง ๆ รันหลายเซสชัน Claude Code พร้อมกัน เพื่อเทียบกับวิธีทำเอง

เมื่อไหร่ควรใช้ Agent Chat แทน Task

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

เมื่อไหร่ต้องใช้ Crew

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

เมื่อไหร่ Skill ดีกว่าแก้คำสั่ง

เมื่อ Agent หลายตัวต้องใช้ขั้นตอนเดียวกัน (เช็กลิสต์การรีวิว รูปแบบการ migration รูปแบบการรายงาน) ให้ย้ายมันไปเป็น Skill แล้วผูกไว้ตรงที่ต้องใช้ ฝีมือของนักพัฒนาคนหนึ่งก็กลายเป็นโครงสร้างพื้นฐานขององค์กรแทนที่จะเป็นพรอมป์ส่วนตัว

แล้วคนอื่นในทีมล่ะ

ทุกอย่างข้างบนใช้คนเดียวก็ได้ แต่ผลตอบแทนจะทบต้นเมื่อ Task อยู่ใน Space ที่ใช้ร่วมกัน Sprints จัดกลุ่มงานเป็นรอบ และเพื่อนร่วมทีมรีวิวผลลัพธ์ของ Agent ในมุมมองเดียวกับที่ใช้กับงานของคนอยู่แล้ว ชั้นการจัดการโปรเจกต์ของ Sharkly (Spaces, Projects, Sprints, มุมมอง kanban และ list) เป็นมาตรฐานพอที่ไม่มีใครต้องเรียนรู้ใหม่

เมื่อ Sharkly ไม่ใช่เครื่องมือที่เหมาะกับวันนี้

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

ตรรกะเดียวกันใช้กับเครื่องมือที่คุณสร้างเองได้ด้วย เซสชัน tmux และสคริปต์ worktree ที่ทำเองนั้นใช้งานได้จริง ทีมจะค่อย ๆ ย้ายออกจากมันเมื่อส่วนที่มองไม่เห็น (ใครรันอะไร diff ไปอยู่ไหน ใครอนุมัติ) เริ่มมีต้นทุนสูงกว่าที่สคริปต์ช่วยประหยัดไว้ และถ้าทีมของคุณอยู่เฉพาะในระบบนิเวศของผู้ให้บริการรายเดียวแบบครบวงจร ลองประเมินระบบ orchestration ของผู้ให้บริการรายนั้นก่อน จุดแข็งของ Sharkly จะชัดที่สุดเมื่อคุณผสมเครื่องมือ เครื่อง และคนเข้าด้วยกัน เพราะมันวางตัวเป็นกลางกับทั้งสามอย่าง บริบทของหมวดหมู่ในภาพกว้างอยู่ใน What Is Agentic Coding? ถ้าคุณกำลังวางแผนที่ทางในพื้นที่นี้

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

การรันครั้งแรกสามแบบที่ใช้ได้จริง

ทีมแพลตฟอร์มที่ระวังตัว. วิศวกร DevEx เชื่อมต่อ Linux Computer ที่ใช้ร่วมกันหนึ่งเครื่อง สร้าง Code Reader Agent แบบอ่านอย่างเดียว แล้วปล่อยให้เพื่อนร่วมทีมมอบหมาย Task สืบสวนให้หนึ่งสัปดาห์ ไม่มีใครให้สิทธิ์เขียนจนกว่ารายงานจะพิสูจน์ว่าน่าเชื่อถือ การนำไปใช้แพร่กระจายได้เพราะร่องรอยการทำงานทำให้วิจารณญาณของ Agent ตรวจสอบได้

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

ทีมที่ยึด Jira เป็นศูนย์กลาง. วิศวกรรมผู้จัดการคนหนึ่งเก็บ Jira ไว้เป็นแหล่งความจริงด้านการวางแผน แล้วเชื่อม Sharkly เพื่อให้ ticket กลายเป็น Task ที่ลงมือทำได้ นักพัฒนาหยุดคัดลอกบริบทของ ticket ไปวางในเทอร์มินัล ผลลัพธ์ อุปสรรค และคำขอรีวิวกลับมาอยู่บน Task ที่ผู้จัดการมองเห็นได้

สิบนาทีถัดไปของคุณ

เวิร์กโฟลว์ Sharkly ที่มีประโยชน์น้อยที่สุดถูกตั้งใจทำให้เล็ก: เชื่อมต่อ Computer หนึ่งเครื่อง สร้าง Agent หนึ่งตัว และมอบหมาย Task ความเสี่ยงต่ำหนึ่งงาน ทุกความสามารถขั้นสูง (worktree แบบขนาน, Crews, Skills, Automations, Sprints) ต่อยอดจากวงจรนี้โดยไม่ต้องเปลี่ยนมัน

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

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

coding agent ตัวไหนใช้กับ Sharkly ได้บ้าง

Sharkly จะตรวจหาเครื่องมือ agent ที่รองรับซึ่งติดตั้งอยู่บน Computer ที่เชื่อมต่อไว้ และรายงานแต่ละตัวเป็น Runtime โดย Claude Code, Codex, Gemini CLI และ OpenCode อยู่ในกลุ่มเครื่องมือที่อ้างถึงในเอกสารอย่างเป็นทางการ หน้ารายละเอียด Computer จะแสดงชุดที่รองรับในปัจจุบันสำหรับเครื่องของคุณ พร้อมลิงก์คู่มือการติดตั้งสำหรับแต่ละ Runtime และคุณเพิ่ม Runtime แบบ ACP ที่กำหนดเองได้หากเครื่องมือนั้นไม่ถูกตรวจพบอัตโนมัติ

Sharkly มาแทนที่ Claude Code หรือ Codex หรือไม่

ไม่ Sharkly ไม่ได้มาแทนที่ Claude Code, Codex หรือเครื่องมือสำหรับลงมือทำงานอื่น ๆ เครื่องมือเหล่านั้นทำหน้าที่รันเซสชันของ agent จริง ๆ บน Computer ของคุณ ส่วน Sharkly เพิ่มชั้นที่ใช้ร่วมกันให้ครอบมันไว้: การมอบหมายงานระดับทีม บริบทของ task ความคืบหน้า ผลลัพธ์ และการรีวิวโดยมนุษย์ คุณยังคงใช้เครื่องมือ agent และบัญชีที่มีอยู่แล้วต่อไป

Sharkly ราคาเท่าไหร่

โมเดลของ Sharkly คือ bring-your-own-subscription: การใช้งานโมเดลดำเนินไปผ่าน subscription หรือ API key ที่ตั้งค่าไว้ในเครื่องมือ agent ของคุณ และโควตาของคุณขึ้นอยู่กับแผนที่ทีมของคุณเชื่อมต่อ สำหรับแผนผลิตภัณฑ์ในปัจจุบัน ให้ตรวจที่ sharkly.ai โดยตรง เพราะบทความนี้ไม่ได้ติดตามราคา

โค้ดและข้อมูลรับรองของฉันผ่านเซิร์ฟเวอร์ของ Sharkly หรือไม่

การทำงานเกิดขึ้นบน Computers ที่คุณเชื่อมต่อ: แล็ปท็อปของคุณ เซิร์ฟเวอร์ของคุณ หรือคอนเทนเนอร์ของคุณ Computer เป็นผู้จัดหาระบบปฏิบัติการ ไฟล์ ข้อมูลรับรอง และเครื่องมือ ส่วน local service จะสตรีมความคืบหน้าและผลลัพธ์กลับมาที่ Task repositories ถูกดึงมาด้วยสิทธิ์เข้าถึง Git ที่ตั้งค่าไว้บน Computer เครื่องนั้น

ทำไม Agent ของฉันไม่เริ่มการรัน

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

Agent สองตัวทำงานบน repository เดียวกันพร้อมกันได้ไหม

ได้ ถ้าใช้ไดเรกทอรีทำงานชั่วคราว โดยแต่ละ Task จะได้ไดเรกทอรีแยกกัน และการรันที่อิง repository จะเตรียม git worktree แยกต่อการรันหนึ่งครั้ง ซึ่งช่วยลดการรบกวนกันระหว่าง Task ที่รันพร้อมกัน ส่วนไดเรกทอรีที่ระบุไว้จะตรงกันข้าม คือเส้นทางที่ตั้งค่าไว้หนึ่งเส้นทางให้บริการได้ครั้งละหนึ่งการรัน

รัน Sharkly Agents บนเซิร์ฟเวอร์ระยะไกลได้ไหม

ได้ ติดตั้ง Sharkly CLI และ local service บนโฮสต์ระยะไกล แล้วลงทะเบียนด้วย install token แบบใช้ครั้งเดียวจากหน้า Computers local service จะเชื่อมต่อออกไปหา Sharkly ดังนั้นการตั้งค่าทั่วไปจึงไม่ต้องเปิดพอร์ตขาเข้า Computers ระยะไกลเหมาะกับความจุที่ทีมใช้ร่วมกัน ส่วนแล็ปท็อปเหมาะกับการทดลองส่วนตัว

Task แรกของฉันควรเป็นอะไร

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