รัน Coding Agent จากระยะไกล: บนเซิร์ฟเวอร์ของคุณ บนแล็ปท็อปของคุณ หรือทั้งสองอย่าง

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

Aiden Flux

Aiden Flux

4 พฤศจิกายน 2026

รัน Coding Agent จากระยะไกล: บนเซิร์ฟเวอร์ของคุณ บนแล็ปท็อปของคุณ หรือทั้งสองอย่าง

เอเจนต์เขียนโค้ดจะทำงานได้ก็ต่อเมื่อเครื่องที่มันรันอยู่ยังทำงานอยู่ เริ่มรีแฟกเตอร์ยาว ๆ ด้วย Claude Code หรือ Codex แล้วปิดฝาจอเพื่อไปขึ้นรถไฟ งานก็จะตายไปพร้อมกับเซสชัน SSH ของคุณ เปิดเอเจนต์สองตัวบนแล็ปท็อปเครื่องเดียวกัน พัดลมก็จะหมุนดังขณะที่เอดิเตอร์ของคุณกระตุก ถึงจุดหนึ่ง คำถามก็จะไม่ใช่ "ใช้เอเจนต์ตัวไหน" อีกต่อไป แต่กลายเป็น "เอเจนต์รันอยู่ที่ไหนกันแน่"

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

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

ทำไมคุณถึงควรย้ายเอเจนต์ออกจากแล็ปท็อป

แล็ปท็อปเป็นตัวเลือกเริ่มต้นเพราะเป็นที่ที่คุณพิมพ์งาน แต่มันก็เป็นโฮสต์ที่แย่ที่สุดสำหรับอะไรก็ตามที่รันนานกว่าช่วงสมาธิของคุณ macOS หลับเมื่อปิดฝาจอ โหมดประหยัดแบตเตอรี่ลดความเร็ว CPU VPN องค์กรหลุด ทุกเหตุการณ์เหล่านี้ฆ่าเอเจนต์กลางงาน และเอเจนต์ก็ไม่รู้ตัวว่าถูกขัดจังหวะ คุณจะรู้ก็ต่อเมื่อเปิดเทอร์มินัลกลับมาเจอพรอมป์ที่ตายแล้วและไม่มีสรุปอะไรเลย

โฮสต์ระยะไกลแก้ปัญหาเรื่องฟิสิกส์นี้ได้ คลาวด์ VM หรือเครื่อง Linux สำรองจะเปิดอยู่ตลอด รักษาการเชื่อมต่อเครือข่าย และมีคอร์เหลือสำหรับงานขนาน ราคาที่ต้องจ่ายคือตอนนี้เอเจนต์รันอยู่ที่ที่คุณมองไม่เห็น คุณต้อง SSH เข้าไปเช็ก ไล่ดูบันทึกเพื่อเดาว่ามันไปถึงไหนแล้ว และผลลัพธ์ก็อยู่ในเครื่องนั้นจนกว่าคุณจะคัดลอกออกมา

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

การตั้งค่าระยะไกลแบบทำเอง และจุดที่แต่ละขั้นพัง

เส้นทางทำเองเป็นเรื่องที่เข้าใจกันดีอยู่แล้ว นี่คือเวอร์ชันสั้น พร้อมโหมดความล้มเหลวที่โผล่ขึ้นมาในแต่ละขั้น

จัดเตรียมโฮสต์และเอาเอเจนต์ขึ้นไป:

ssh you@build-server
# install the agent's CLI, e.g. Claude Code or Codex
# authenticate it with your own subscription or API key
git clone [email protected]:your-org/your-repo.git
cd your-repo
claude

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

ทำให้งานรันต่อได้หลังเซสชัน SSH ของคุณจบ:

tmux new -s agent
claude   # start the long task
# Ctrl-b d to detach, close the laptop, reconnect later
tmux attach -t agent

โหมดความล้มเหลว: tmux อยู่รอดหลังการเชื่อมต่อ SSH หลุด แต่ไม่รอดจากการรีบูตเซิร์ฟเวอร์ การถูก OOM kill หรือการที่คุณลืมว่าเซสชันไหนในหกเซสชันบนเซิร์ฟเวอร์สามเครื่องถืองานที่คุณสนใจอยู่ การ detach ไม่เหมือนกับความทนทาน

ดึงผลลัพธ์กลับมาและดูว่าเกิดอะไรขึ้น:

scp you@build-server:~/your-repo/CHANGES.md .
ssh you@build-server 'cd your-repo && git diff'

โหมดความล้มเหลว: diff อยู่ในเครื่อง เหตุผลอยู่ในบัฟเฟอร์ scrollback ที่ถูกตัดทิ้งไปแล้ว และ "ทำไม" ก็หายไป คูณด้วยเอเจนต์สองตัวบนสองโฮสต์ แล้วคุณจะต้องประกอบสถานะขึ้นมาใหม่ด้วยมือทุกครั้งที่เข้าไปเช็ก

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

Computer ที่เชื่อมต่อเข้ามาเปลี่ยนอะไร

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

คุณลงทะเบียนโฮสต์ครั้งเดียวแทนที่จะ SSH เข้าไปทุกครั้ง สร้างโทเคนติดตั้งแบบใช้ครั้งเดียวจาก Settings, Computers บนเครื่องเป้าหมาย แล้วรัน:

sharkly computer register --install-token <install-token>

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

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

จากตรงนี้ โหมดความล้มเหลวที่กล่าวมาก็มีที่อยู่ให้จัดการ ข้อมูลรับรองเป็นของโฮสต์และจำกัดขอบเขตไว้ที่มัน งานจะอยู่ต่อได้นานกว่าเทอร์มินัลของคุณเพราะบริการภายในเป็นเจ้าของมัน ไม่ใช่เซสชัน tmux และ diff สรุป และเหตุผลจะกลับมาที่ Task แทนที่จะค้างอยู่ในบัฟเฟอร์ scrollback บนเครื่องที่คุณต้อง SSH เข้าไป

แล็ปท็อป เซิร์ฟเวอร์ หรือทั้งคู่: เลือกอย่างไรจริง ๆ

โฮสต์เยอะขึ้นไม่ได้ดีขึ้นอัตโนมัติ ดังนั้นเลือกตามงาน

ใช้แล็ปท็อป เมื่องานสั้น เป็นแบบอินเทอร์แอกทีฟ และคุณอยากเฝ้าดู ลงทะเบียนมันเป็น Computer ส่วนตัว และใน Sharkly Desktop เปิด Prevent sleep ไว้เพื่อไม่ให้งานสั้น ๆ ถูกตัดจบด้วยการหลับของระบบ สังเกตว่า Prevent sleep จะโผล่เฉพาะบนเครื่องท้องถิ่นในแอปเดสก์ท็อป ไม่มีบน Computer ที่แชร์หรืออยู่ระยะไกล ถ้าทุกอย่างที่คุณรันเสร็จภายในเวลาพักกาแฟและไม่ต้องรอดฝาปิด ก็ยังไม่ต้องมีเซิร์ฟเวอร์ และการเพิ่มหนึ่งเครื่องก็เป็นแค่ภาระดูแลที่คุณจะรู้สึกหงุดหงิดในภายหลัง

ใช้เซิร์ฟเวอร์ระยะไกล เมื่องานรันยาว ต้องการคอร์มากกว่า หรือไม่ควรแย่งทรัพยากรกับเอดิเตอร์ของคุณ โฮสต์ Linux หรือคลาวด์ VM ที่ลงทะเบียนไว้จะตื่นอยู่ตลอดเป็นค่าเริ่มต้น และให้พื้นที่กับเอเจนต์ขนานในการทำงาน นี่ก็เป็นที่ที่ขีดจำกัด concurrency ของงานต่อโฮสต์ และการมองเห็นระดับ Organization หรือ Space ของ Computer คุ้มค่ากับการมีไว้: เครื่องและข้อมูลรับรองของมันถูกออกแบบมาให้แชร์ และ Sharkly ก็ปฏิบัติต่อมันแบบนั้น

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

จุดที่วิธีทำเองไปต่อไม่ได้ และสิ่งที่บอร์ดงานเพิ่มเข้ามา

การตั้งค่าแบบ SSH-และ-tmux ใช้ได้กับเอเจนต์หนึ่งตัวบนโฮสต์หนึ่งเครื่อง แต่มันหยุดทำงานทันทีที่คุณมีเอเจนต์หลายตัวบนหลายเครื่อง เพราะไม่มีคำตอบร่วมกันว่า "เอเจนต์ตัวไหนอยู่บนอะไร อะไรเสร็จ อะไรล้มเหลว และอะไรต้องให้ฉันตรวจ" คำถามนี้คือเหตุผลทั้งหมดที่ควร รันเอเจนต์มากกว่าหนึ่งตัวพร้อมกัน และมันคือสิ่งที่กองเทอร์มินัลตอบไม่ได้เลย

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

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

เช็กลิสต์ที่คุณรันได้วันนี้

ไล่ทำตามรายการนี้บนโฮสต์ที่คุณวางแผนจะใช้:

  • [ ] เลือกโฮสต์อย่างตรงไปตรงมา: แล็ปท็อปสำหรับงานอินเทอร์แอกทีฟ เซิร์ฟเวอร์สำหรับงานยาวหรือขนาน และทั้งคู่ถ้าคุณจำเป็นจริง ๆ
  • [ ] ติดตั้ง Runtime ของเอเจนต์ที่รองรับบนแต่ละโฮสต์ และยืนยันตัวตนด้วยซับสคริปชันหรือ API key ของคุณเอง
  • [ ] ลงทะเบียนแต่ละโฮสต์ครั้งเดียวด้วย sharkly computer register --install-token <token> แทนการ SSH เข้าไปทุกครั้งที่รัน
  • [ ] ยืนยันว่าแต่ละ Computer แสดง Online และ มี Runtime อย่างน้อยหนึ่งตัวรายงานว่า Available เพราะออนไลน์อย่างเดียวยังรัน Task ไม่ได้
  • [ ] ตั้งค่าการมองเห็นของ Computer เป็น Personal สำหรับแล็ปท็อปของคุณ และ Organization หรือ Space สำหรับเซิร์ฟเวอร์ที่แชร์
  • [ ] บนแล็ปท็อป เปิด Prevent sleep สำหรับงานที่ต้องรอดฝาปิด
  • [ ] มอบหมาย Task เล็ก ๆ ธรรมดา ๆ หนึ่งงานให้โฮสต์ระยะไกล และยืนยันว่าผลลัพธ์กลับมาที่ Task ไม่ใช่บัฟเฟอร์ scrollback
  • [ ] ใช้ sharkly computer list และ sharkly daemon disk-usage เพื่อติดตามโฮสต์และเรียกคืนพื้นที่

คุณจะสร้างการตั้งค่าระยะไกลด้วยมือโดยใช้ SSH, tmux และ worktree ก็ได้ หรือจะลงทะเบียนโฮสต์ที่มีอยู่เป็น Computer แล้วให้บริการภายในเป็นเจ้าของการรันก็ได้ ถ้าคุณกำลังรันเอเจนต์เขียนโค้ดหลายตัวข้ามเครื่องมากกว่าหนึ่งเครื่องอยู่แล้ว Sharkly มอบที่เดียวให้คุณจัดการงานและผลลัพธ์ของพวกมัน เชื่อมต่อ Computer สักหนึ่งเครื่อง สร้าง Agent หนึ่งตัว แล้วมอบหมายงานธรรมดา ๆ ให้มันก่อน

สำรวจเพิ่มเติม

GPT-6.1 Terra Agents บน Sharkly: วิธีตั้งค่า ความยากง่าย และค่าใช้จ่าย

GPT-6.1 Terra Agents บน Sharkly: วิธีตั้งค่า ความยากง่าย และค่าใช้จ่าย

รันเอเจนต์ GPT-6.1 Terra บน Sharkly: เพียงตั้งค่า gpt-6.1-terra ใน Agent variant เลือกระดับ effort เริ่มต้น แล้วมาดูกันว่าในราคาเพียงครึ่งหนึ่งของ Sol จะให้อะไรกับ Crew ได้บ้าง

5 พฤศจิกายน 2026

Agent Skills ย้ายสู่ Agentic AI Foundation: มีอะไรเปลี่ยนแปลงบ้างสำหรับทีมที่ใช้งาน Coding Agents

Agent Skills ย้ายสู่ Agentic AI Foundation: มีอะไรเปลี่ยนแปลงบ้างสำหรับทีมที่ใช้งาน Coding Agents

เมื่อวันที่ 22 ตุลาคม Anthropic ได้ส่งมอบ Agent Skills ให้แก่ Agentic AI Foundation โดยรูปแบบของ SKILL.md ไม่ได้เปลี่ยนแปลง สิ่งที่เปลี่ยนไปคือผู้ดูแล และนี่คือความหมายของการเปลี่ยนแปลงดังกล่าวสำหรับทีมที่ใช้งาน Claude Code และ Codex พร้อมตัวอย่าง skill ขนาดเล็กที่ตรงตามสเปก...

5 พฤศจิกายน 2026

Codex ใช้ฟรีไหม? ChatGPT Free ได้อะไรบ้าง (2026)

Codex ใช้ฟรีไหม? ChatGPT Free ได้อะไรบ้าง (2026)

ChatGPT Free ใช้งาน Codex ได้เฉพาะบนแอปเดสก์ท็อป ผ่าน GPT-6 Luna และขึ้นอยู่กับการทยอยเปิดให้ใช้งาน ส่วน Codex CLI, IDE extension และ Codex cloud จะเริ่มต้นที่แพ็กเกจ Plus พร้อมตารางสรุปค่าใช้จ่ายตามรูปแบบการใช้งาน ข้อจำกัดของ Plus ราคา API key และ 3 แนวทางการใช้งานแบบฟรี ($0) ซึ่งรวมถึงการใช้...

5 พฤศจิกายน 2026