ทุกการคลิกใน UI ของ Sharkly คือการตัดสินใจของคนคนหนึ่ง: สร้าง Task นี้ มอบหมาย Agent นั้น ตรวจดูการรันหนึ่งครั้ง นั่นคืออินเทอร์เฟซที่เหมาะกับการตัดสินใจที่ต้องใช้ดุลพินิจ แต่เป็นอินเทอร์เฟซที่ผิดสำหรับการทำซ้ำครั้งที่พันของคำสั่งเดิม ๆ เมื่อทีมของคุณตัดสินใจว่า build ข้ามคืนที่ล้มเหลวทุกครั้งควรกลายเป็น Task การที่คนคนหนึ่งต้องคอยคลิกผ่านหน้าจอไปเรื่อย ๆ ก็ไม่ใช่เวิร์กโฟลว์อีกต่อไป แต่กลายเป็นงานจุกจิกที่ต้องทำ
นี่คือจุดที่ช่องทางเชิงโปรแกรมเข้ามามีบทบาท Sharkly CLI ทำให้คน, agent และสคริปต์ทำงานกับ Sharkly ได้จากเทอร์มินัล: จัดการทรัพยากรขององค์กร, ลงทะเบียน Computer สำหรับให้ agent ทำงาน, ตรวจสอบ local service และทำเวิร์กโฟลว์ที่ทำซ้ำ ๆ ให้เป็นอัตโนมัติ เบื้องหลังคือ REST API ที่ api.sharkly.ai ซึ่งรับ personal access token ชุดเดียวกับที่ CLI ใช้
เรื่องนี้สำคัญกับ Sharkly มากกว่าเครื่องมือ PM ทั่วไป เพราะ Sharkly ไม่ได้เป็นแค่ที่ที่งานถูกอธิบายไว้เท่านั้น แต่เป็นที่ที่งาน被执行จริง Sharkly เพิ่มชั้นของ task ที่ใช้ร่วมกัน, Computer, context, การควบคุม และการรีวิว เข้าไปรอบเครื่องมือเขียนโค้ดอย่าง Claude Code และ Codex ดังนั้นการสั่ง sharkly task create ผ่านสคริปต์จึงไม่ได้แค่เปิดตั๋วงาน หาก Task นั้นถูกมอบหมายให้ Agent และอยู่ในสถานะพร้อมทำงาน มันก็สามารถเริ่มการรันจริงบน Computer จริงได้ การเขียนสคริปต์ให้กับช่องทางนี้จึงเท่ากับการเขียนสคริปต์ให้กับกำลังคน
TL;DR
Sharkly CLI (คำสั่ง sharkly) ทำให้คน, agent และสคริปต์ทำงานกับ Sharkly ได้จากเทอร์มินัล และยังเป็นวิธีติดตั้ง local service ลงบนโฮสต์ระยะไกลและโฮสต์ Linux เพื่อให้พวกมันเข้าร่วมฟลีตของคุณในฐานะ Computer การยืนยันตัวตนถูกแยกออกจากกันอย่างจงใจ: personal access token (คำนำหน้า shk_) ใช้ล็อกอินในนามของคนหรือสคริปต์, install token แบบใช้ครั้งเดียว (คำนำหน้า sit_) ใช้ลงทะเบียน Computer และการรันของ Agent ใช้ข้อมูลรับรองการทำงานแบบจำกัดขอบเขต (scoped execution credential) ที่ Sharkly จัดหาให้ เมื่อมีโทเคนแล้ว สคริปต์สามารถสร้างและแก้ไข Task, แสดงความคิดเห็นใน Task, ตรวจสอบการรันและล็อก และจัดการ Computer ได้ทั้งหมด โดยใช้ --output json เพื่อให้ Parse ได้ง่าย โทเคน shk_ ตัวเดียวกันนี้ยังใช้เป็น bearer token กับ REST API ได้ และ webhook trigger ของ Automation ทำให้ CI และระบบภายนอกอื่น ๆ เริ่มการรันของ Agent ได้ด้วยคำขอ POST
แพลตฟอร์มเดียว สองช่องทาง
UI ของ Sharkly และช่องทางเชิงโปรแกรมของมันคือทางเข้าสองทางสู่ระบบเดียวกัน Task ที่สคริปต์ของคุณสร้างขึ้นก็คือ Task เดียวกับที่เพื่อนร่วมทีมเห็นบนบอร์ด มีสถานะ, Workflow, ความคิดเห็น และประวัติการทำงานชุดเดียวกัน การเขียนสคริปต์ไม่เคยเลี่ยงไป绕过บันทึกที่ใช้ร่วมกัน เพราะระบบอัตโนมัติป้อนเข้าสู่ระบบบันทึกหลัก (system of record) นั่นเอง
วิธีแบ่งแยกทั้งสองอย่างที่ได้ผลคือดูว่าใครเป็นคนตัดสินใจ ใช้ UI เมื่อมีคนกำลังตัดสินใจที่ต้องใช้ดุลพินิจ: ปั้นความต้องการ, รีวิว diff, ยอมรับผลลัพธ์ ใช้ CLI หรือ API เมื่อการตัดสินใจเกิดขึ้นแล้วและเหลือแค่กลไกที่ต้องทำซ้ำ: ยื่น Task จากระบบมอนิเตอร์, ดึงล็อกการรันเข้าแดชบอร์ด, ตรวจสุขภาพ Computer จาก cron job สคริปต์สามารถสร้าง Task และถึงขั้นทริกเกอร์การรันได้ แต่การยอมรับผลลัพธ์ยังคงเป็นของคน
การติดตั้ง CLI และสิ่งที่มันติดตั้งให้
บน macOS หรือ Linux ตัวติดตั้งอย่างเป็นทางการใช้คำสั่งเดียว:
curl -fsSL https://file-assets.sharkly.ai/download/install.sh | bash
Windows มีตัวติดตั้ง PowerShell อย่างเป็นทางการ ซึ่งตอนนี้รองรับเฉพาะ AMD64 บนแพลตฟอร์มใดก็ตาม ตรวจสอบและดูแลการติดตั้งได้ด้วย:
sharkly version
sharkly update
CLI ยังมีบทบาทที่สองนอกเหนือจากการเป็นไคลเอนต์ เอกสารระบุเส้นทางสองทางในการเชื่อมต่อ Computer: ติดตั้ง Sharkly Desktop บนคอมพิวเตอร์ส่วนบุคคลที่รองรับ หรือติดตั้ง Sharkly CLI และ local service บนโฮสต์ระยะไกลหรือคอมพิวเตอร์ Linux เส้นทางที่สองนี้เองที่ทำให้ build server, เครื่อง Linux ที่ว่างอยู่ หรือคอนเทนเนอร์ กลายเป็นกำลังการประมวลผลให้กับ Agent ของคุณ local service ที่มันตั้งขึ้นจะลงทะเบียน Computer, ตรวจจับ Runtime ที่ติดตั้งไว้, ส่ง heartbeat, รับงานที่เข้าคิวไว้, เตรียมไดเรกทอรีของ task และสตรีมความคืบหน้ากลับมา โดยเป็นฝ่ายเริ่มการเชื่อมต่อเอง จึงไม่จำเป็นต้องมีพอร์ตขาเข้า
หากคุณยังเชื่อมต่อเครื่องแรกผ่าน UI อยู่ คู่มือเริ่มต้นใช้งานอธิบายขั้นตอนนั้นไว้แล้ว
ข้อมูลรับรองสามแบบ สามหน้าที่
Sharkly แยกข้อมูลรับรองสำหรับแต่ละวัตถุประสงค์ และการแยกกันนี้ควรค่าแก่การทำความเข้าใจให้ขึ้นใจก่อนที่คุณจะทำอะไรให้เป็นอัตโนมัติ
personal access token ขึ้นต้นด้วย shk_ และทำให้ CLI, สคริปต์ หรือไคลเอนต์ที่เชื่อถือได้อื่น ๆ ทำงานในนามบัญชีผู้ใช้ของคุณได้ คุณสร้างมันได้ใน Settings เลือกวันหมดอายุ 30 วัน, 90 วัน, 1 ปี หรือไม่หมดอายุ และคัดลอกค่าทั้งหมดได้ครั้งเดียวตอนสร้าง ล็อกอินด้วยโฟลว์แบบมีพรอมต์เพื่อไม่ให้โทเคนไปอยู่ในประวัติเชลล์:
sharkly login --token
sharkly auth status
computer install token ขึ้นต้นด้วย sit_ หมดอายุใน 30 นาที และใช้ได้เพียงครั้งเดียวเท่านั้น หน้าที่เดียวของมันคือลงทะเบียน Computer:
sharkly computer register --install-token sit_...
ข้อมูลรับรองแบบที่สามที่คุณไม่ต้องแตะเลย: การรันของ Agent ที่ทำงานอยู่จะได้รับข้อมูลรับรองการทำงานแบบจำกัดขอบเขตที่ Sharkly จัดหาให้ ซึ่งจำกัดเฉพาะกลุ่มคำสั่งที่ execution context ของมันอนุญาต
เอกสารขีดเส้นแบ่งไว้อย่างชัดเจน: personal access token ไม่ได้ใช้ลงทะเบียน computer และ install token ก็ไม่ได้ใช้สร้างการล็อกอิน CLI ของคน การลงทะเบียนจะสร้างเซสชัน local service แยกต่างหาก ซึ่งเป็นเหตุผลว่าทำไมการเพิกถอน personal token ในภายหลังจึงไม่ทำให้ Computer ที่ลงทะเบียนไว้หลุดออนไลน์ เช่นเดียวกัน sharkly auth logout เพียงล้างโทเคนออกจากโปรไฟล์ในเครื่องของคุณเท่านั้น โทเคนยังคงใช้ได้บนเซิร์ฟเวอร์จนกว่าคุณจะเพิกถอนใน Settings
สำหรับ CI ให้ข้ามขั้นตอนล็อกอินไปเลย CLI จะอ่านโทเคนจากตัวแปรสภาพแวดล้อม SHARKLY_TOKEN ซึ่งมีลำดับความสำคัญเหนือโปรไฟล์ที่บันทึกไว้ ใส่ค่ามันจากที่เก็บความลับที่มีการป้องกัน เช่น GitHub Actions secrets แทนที่จะเขียนลงในไฟล์ workflow และระบุองค์กรให้ชัดเจนด้วย --organization-id
จัดการฟลีตของ Computer จากเทอร์มินัล
เมื่อโฮสต์ต่าง ๆ ลงทะเบียนแล้ว กลุ่มคำสั่ง sharkly computer ก็ครอบคลุมการตรวจสอบและดูแลรักษาโดยไม่ต้องเปิดเบราว์เซอร์:
sharkly computer list --output json
sharkly computer show <computer-id> --output json
sharkly computer usage <computer-id> <runtime-id> --days 30 --output json
sharkly computer ping <computer-id> <runtime-id> --wait --output json
sharkly computer update <computer-id> <runtime-id>
list แสดง Computer ที่ลงทะเบียนไว้สำหรับองค์กรปัจจุบัน, show คืนค่า Computer หนึ่งตัวพร้อม Runtime ของมัน, usage ตรวจสอบ Runtime ที่เจาะจง, ping ตรวจว่า Runtime นั้นสามารถสื่อสารไปกลับได้ครบวงจรหรือไม่ และ update ขอให้อัปเดต CLI สำหรับ Runtime หนึ่ง ๆ เหตุผลที่ ping ต้องมีแยกออกมา: การที่ Computer ออนไลน์อยู่หมายความแค่ local service ของมันกำลังส่ง heartbeat ไม่ได้หมายความว่า Runtime ที่ระบุสามารถรันงานได้ในตอนนี้
บนตัวโฮสต์เอง การวินิจฉัยตามปกติใช้คำสั่งสำหรับผู้ใช้ทั่วไป:
sharkly computer status --output json
sharkly computer logs --lines 100
เนมสเปซ daemon เปิดให้เข้าถึงการจัดการวงจรชีวิตของโปรเซสและการควบคุมดิสก์ รวมถึง sharkly daemon disk-usage และ sharkly daemon cleanup ซึ่งจะเป็นการรันแบบทดลอง (dry run) เว้นแต่คุณจะเพิ่ม --confirm กฎการตัดสินใจตามเอกสาร: ให้ใช้ computer status และ computer logs สำหรับการวินิจฉัยเป็นหลัก และหยิบ daemon มาใช้เฉพาะเมื่อคุณต้องการจัดการวงจรชีวิตของโปรเซส, รายงานการใช้ดิสก์ หรือการล้างข้อมูล อ่านเพิ่มเติมเกี่ยวกับความเป็นเจ้าของ, การมองเห็น และนโยบายการล้างข้อมูลได้ในโพสต์เรื่อง Computersในซีรีส์นี้
เขียนสคริปต์สร้าง Task: งานที่มาถึงโดยไม่ต้องประชุม
Task คือจุดที่ CLI พิสูจน์คุณค่าในไปป์ไลน์ กลุ่มคำสั่งนี้อ่านแล้วเหมือนบอร์ดเวอร์ชันที่เขียนสคริปต์ได้:
sharkly task list --output json
sharkly task search "authentication error" --output json
sharkly task create --title "Investigate authentication error" --output json
sharkly task edit <task-id> --status <status> --output json
sharkly task comment <task-id> --body "Investigation started." --output json
กรณีใช้งาน CI ที่ชัดเจนที่สุดคือการยื่นงานโดยอัตโนมัติ งานที่รันทุกคืนและตรวจพบ release ที่ล้มเหลวไม่จำเป็นต้องมีคนมานั่งกรอกฟอร์ม:
sharkly task create \
--title "Investigate the failed release" \
--body-file ./task-body.md \
--output json
ใช้ --body-file หรือ --body-stdin ทุกครั้งที่เนื้อหาต้องตรงเป๊ะ เพราะรูปแบบย่อ --body จะถอดรหัส escape sequence และเนื่องจาก Task ที่มอบหมายให้ Agent จะเริ่มการรันเมื่ออยู่ในสถานะพร้อมทำงาน คำสั่งเดียวนี้จึงเป็นจุดเริ่มต้นของลูปอัตโนมัติเต็มรูปแบบได้: สคริปต์ยื่น Task, Agent ที่ได้รับมอบหมายรับงานไปทำ และการทำงาน, อุปสรรค และผลลัพธ์จะกลับมาอยู่ใน Task ที่คนจะเข้าไปรีวิวในเช้าวันถัดไป
สคริปต์สำหรับรายงานได้ตัวกรองจริง ๆ แทนที่จะต้องมานั่งกรองฝั่งไคลเอนต์ คุณกรองตามอายุของสถานะได้ด้วย --status-changed-within 7d และกรองตาม custom field ได้:
sharkly task list --space HF --field "Customer Tier=VIP" --output json
แฟล็ก --field ที่ระบุซ้ำจะถูกเชื่อมด้วย AND การจับคู่คำนึงถึงชนิดข้อมูลและต้องตรงเป๊ะ และการกรองเกิดขึ้นบนเซิร์ฟเวอร์ก่อนการแบ่งหน้า ควรนำธรรมเนียมการเขียนสคริปต์ตามเอกสารมาใช้ทั้งหมด: ระบุ --output json อย่างชัดเจน, เพิ่ม --color never และ --quiet, เปิด --organization-id ให้เห็นไว้เสมอ และใช้ set -euo pipefail รหัสออกมีข้อผูกมัดชัดเจน: 0 คือสำเร็จ, 1 คือข้อผิดพลาดจากคำสั่ง, การตรวจสอบความถูกต้อง, การยืนยันตัวตน หรือ remote API และ 2 คือสภาวะชั่วคราวของ local service หรือเครือข่าย ซึ่งทำให้เขียนตรรกะลองใหม่ได้ง่าย
CLI ยังอธิบายตัวเองได้ด้วย sharkly schema task create --format json เปิดเผย command registry ในรูปแบบที่เครื่องอ่านได้ และ sharkly tldr task แสดงสถานการณ์ตัวอย่างที่คัดสรรไว้ ซึ่งสำคัญมากเมื่อสิ่งที่เขียนสคริปต์อยู่นั้นก็เป็น agent เอง
ดูการรันโดยไม่ต้องเปิดแดชบอร์ด
การทำงานสามารถสังเกตได้ผ่านช่องทางเดียวกันนี้:
sharkly run list --task <task-id> --output json
sharkly run view <run-id> --output json
sharkly run log <run-id> --since <sequence> --output json
sharkly run cancel <run-id> --output json
แฟล็ก --since ทำให้การ polling สมเหตุสมผล: สคริปต์มอนิเตอร์จะบันทึกหมายเลขลำดับสุดท้ายที่ประมวลผลไปแล้ว และดึงเฉพาะข้อความใหม่ ๆ ในแต่ละรอบ จับคู่กับ sharkly agent list, sharkly automation view และ sharkly automation runs แล้วคุณก็สร้างหน้ารายงานสถานะสำหรับกำลัง agent ของคุณได้จากเชลล์สคริปต์กับ jq
REST API และ webhook
ทุกอย่างที่ CLI ทำได้ล้วนอยู่บน REST API และเอกสารก็แสดงเส้นทางตรงไว้: ส่ง personal access token ของคุณเป็น bearer token ผ่าน HTTPS
curl -fsS https://api.sharkly.ai/rest/v1/users/current \
-H "Authorization: Bearer ${SHARKLY_TOKEN}"
การเข้าถึงผ่าน API ถูกจำกัดด้วยสิทธิ์ของผู้ใช้ที่เป็นเจ้าของโทเคน โมเดลโทเคนปัจจุบันไม่มีการเลือก scope ต่อโทเคน ซึ่งเป็นเหตุผลที่ดีที่จะสร้างโทเคนแยกสำหรับแต่ละเซอร์วิสพร้อมวันหมดอายุที่กำหนดไว้ เอกสารอ้างอิงของ endpoint อยู่ที่ docs.sharkly.ai และผลลัพธ์ --output json ของ CLI ก็เป็นตัวอย่างรูปร่างข้อมูลที่คุณจะได้ใช้งานจริง
ทราฟฟิกไหลไปในทิศทางตรงข้ามได้เช่นกัน Automation สามารถมี webhook trigger ได้: Sharkly จะสร้าง URL ลับที่รับคำขอ POST และคำขอที่ถูกต้องจะเริ่มการรัน Agent หรือ Crew ของ Automation นั้น URL แบบเต็มจะแสดงให้เห็นเพียงครั้งเดียวและทำหน้าที่เป็น bearer secret โดยค่าเริ่มต้น พร้อมตัวเลือกการตรวจสอบลายเซ็น นี่คือครึ่งขาเข้าของเรื่องราว CI: ไปป์ไลน์ของคุณบอก Sharkly ว่า “มีอะไรบางอย่างเกิดขึ้น รัน triage Agent ได้เลย”
ควรพูดให้ชัดว่าช่องทางนี้ไม่ใช่อะไร Sharkly CLI ไม่ใช่ coding agent อีกตัว และ API ก็ไม่ใช่ endpoint ของโมเดล Runtime อย่าง Claude Code และ Codex เป็นตัวลงมือทำงาน ส่วนช่องทางเชิงโปรแกรมของ Sharkly จัดการชั้นที่อยู่รอบ ๆ พวกมัน ความเป็นกลางนี้เองที่ทำให้มันแตกต่างจากตัวเลือกที่ผูกติดกับระบบนิเวศอย่าง GitHub Agent HQ ซึ่งช่องทางอัตโนมัติและการทำงานจริงอยู่ภายในกำแพงของผู้ขายรายเดียวกัน
เริ่มจากตรงไหน
เริ่มให้เล็กกว่าที่คุณคิด สร้าง personal access token ที่มีอายุ 90 วัน รัน sharkly login --token แล้วเขียนสคริปต์สำหรับการอ่านที่น่าเบื่อที่สุดที่คุณทำทุกวัน เช่น รายการ task ที่ส่งผ่าน jq เข้าไปเป็นสรุปตอนเช้า การอ่านนั้นปลอดภัย และช่วยให้คุณเรียนรู้รูปร่างของ JSON จากนั้นค่อยทำการเขียนหนึ่งอย่างให้เป็นอัตโนมัติด้วยทริกเกอร์ที่ชัดเจน เช่น การสร้าง Task จาก CI job ที่ล้มเหลว ต่อ webhook trigger ก็ต่อเมื่อทั้งสองอย่างกลายเป็นเรื่องปกติแล้ว
รูปแบบที่ควรคงไว้คือรูปแบบที่ทั้งแพลตฟอร์มสร้างขึ้นมา: สคริปต์และ Agent สร้างและลงมือทำงาน ส่วน context, ความคืบหน้า, อุปสรรค, ผลลัพธ์ และการรีวิวโดยคนยังคงมองเห็นได้ตั้งแต่คำขอจนถึงการปล่อยงาน ทำทางเข้าให้เป็นอัตโนมัติ แต่เก็การรีวิวไว้
คำถามที่พบบ่อย
จำเป็นต้องใช้ CLI เพื่อใช้ Sharkly ไหม
ไม่จำเป็น Sharkly Desktop ครอบคลุมการเชื่อมต่อคอมพิวเตอร์ส่วนบุคคล และเว็บแอปก็ครอบคลุมงาน Task ประจำวัน CLI จะจำเป็นเมื่อคุณเชื่อมต่อโฮสต์ระยะไกลหรือคอมพิวเตอร์ Linux เพราะการติดตั้ง Sharkly CLI และ local service เป็นเส้นทางตั้งค่าที่เอกสารระบุไว้สำหรับกรณีนั้น และมันจะมีคุณค่าเมื่อเวิร์กโฟลว์หนึ่งทำซ้ำบ่อยพอที่การคลิกผ่านหน้าจอจะมีต้นทุนตามมา
personal access token กับ install token ต่างกันอย่างไร
personal access token (คำนำหน้า shk_) ยืนยันตัวตนของคนหรือสคริปต์ในนามบัญชีผู้ใช้ของคุณ ใช้สำหรับล็อกอิน CLI, งาน CI และคำขอ API โดยตรง ส่วน computer install token (คำนำหน้า sit_) ใช้ครั้งเดียวและมีอายุสั้น โดยหมดอายุใน 30 นาที และใช้ลงทะเบียน Computer เท่านั้น ทั้งสองอย่างใช้แทนกันไม่ได้
เรียกใช้ Sharkly REST API โดยตรงแทนการใช้ CLI ได้ไหม
ได้ ส่ง personal access token เป็น bearer token ผ่าน HTTPS ไปที่ api.sharkly.ai เอกสารแสดงรูปแบบไว้เป็น curl -fsS https://api.sharkly.ai/rest/v1/users/current พร้อมเฮดเดอร์ Authorization: Bearer โทเคนจะมีสิทธิ์ตามบัญชีผู้ใช้ของคุณ
จะสร้าง Task จาก CI pipeline ได้อย่างไร
เก็บโทเคน shk_ ไว้เป็น CI secret ที่มีการป้องกัน และเปิดให้เข้าถึงในชื่อตัวแปรสภาพแวดล้อม SHARKLY_TOKEN ซึ่ง CLI จะอ่านโดยอัตโนมัติ จากนั้นรัน sharkly task create พร้อม --title, --body-file สำหรับเนื้อหาหลายบรรทัดที่ต้องตรงเป๊ะ, --organization-id ที่ระบุชัดเจน และ --output json เพื่อให้ job จับ ID ของ Task ที่สร้างขึ้นได้
การเพิกถอน personal access token จะทำให้ Computer ที่ลงทะเบียนไว้หยุดทำงานไหม
ไม่ การลงทะเบียน Computer จะสร้างเซสชัน local service แยกต่างหากผ่าน install token ดังนั้นการเพิกถอน personal access token จึงไม่ทำให้ Computer เหล่านั้นหยุดทำงาน แต่การเพิกถอนจะทำให้โทเคนใช้ไม่ได้ทุกที่ที่มีการใช้งานกับ CLI, API และคำขอจาก automation ซึ่งเป็นเหตุผลว่าการหมุนเวียนโทเคนควรอัปเดตสคริปต์ที่พึ่งพามันก่อนที่จะเพิกถอนโทเคนเดิม
