บทที่ 33
บทที่ 33 — thClaws Remote
เข้าถึง agent บนเครื่องของคุณเองได้จากที่ไหนก็ได้ โดย ไม่ต้องมี public
IP และไม่ต้องเปิดพอร์ต เครื่อง desktop จะเป็นฝ่ายต่อ ออก ไปหา relay
แล้วค้างการเชื่อมต่อนั้นไว้ จากนั้น thclaws.cloud/talk ในเบราว์เซอร์
ตัวไหนก็ได้จะส่งข้อความของคุณลงไปตามอุโมงค์นั้นถึง engine ที่รันอยู่บน
แล็ปท็อป แล้วคำตอบก็ไหลกลับขึ้นมาทางเดิม
งานยังเกิดขึ้นในเครื่องคุณเหมือนเดิม ไฟล์ กุญแจ เครื่องมือ และการตั้งค่า โมเดล ไม่มีอะไรย้ายที่ สิ่งเดียวที่เดินทางคือข้อความแชท
ฟีเจอร์เดียว แต่มีสองชื่อ ชื่อผลิตภัณฑ์คือ thClaws Remote ส่วน ในโค้ดเรียกว่า phone-home — ทั้งชื่อ module, route
/ph/*บน relay และไฟล์ binding บนดิสก์ ล้วนใช้ชื่อนั้น การเปลี่ยนชื่อจะทำให้อุโมงค์ที่ ใช้งานอยู่พังหมดและบังคับให้ทุกคนต้อง pair ใหม่ คุณจะเห็นทั้งสองชื่อ และมันคือสิ่งเดียวกัน
ทำไมไม่ใช้ช่องทางอื่น
thClaws มีหลายวิธีให้เข้าถึงจากที่อื่น แต่ละวิธีตอบคนละคำถาม
| สิ่งที่คุณต้องการ | ใช้ |
|---|---|
| คุยกับ agent บนเครื่อง ของคุณเอง ผ่านเบราว์เซอร์ | thClaws Remote (บทนี้) |
| หน้าแชทที่เน้นมือถือ พร้อม approval แบบปุ่มให้แตะ | Telegram หรือ LINE |
| HTTP API ให้โปรแกรมอื่นเรียก | --serve (บทที่ 3) |
| agent ที่ทำงานต่อได้ตอนแล็ปท็อปปิดอยู่ | hosted workspace — คนละเครื่องกันไปเลย |
ข้อที่ต่างกันมากที่สุดคือข้อสุดท้าย Remote ไม่ได้ รันอะไรบนคลาวด์ ถ้าแล็ปท็อปคุณหลับอยู่ ปลายอีกด้านของอุโมงค์ก็ไม่มีอะไรอยู่ และเบราว์เซอร์ จะบอกคุณตรง ๆ
อีกเรื่องที่ต่างคือตัวตน LINE, Telegram และ Messenger ผูก engine เข้ากับ บัญชีของแพลตฟอร์มแชท — LINE user id, Telegram user id ส่วน Remote ผูก เข้ากับ บัญชี thClaws.cloud ของคุณ จึงไม่มีบุคคลที่สามอยู่ตรงกลางคอย ถือตัวตนไว้ บัญชีที่เป็นเจ้าของอุโมงค์คือบัญชีที่เป็นเจ้าของ agent
การเปิดใช้งาน
ต้องมี CLI token ของ thClaws.cloud บันทึกไว้ก่อน เพราะ Remote ถูก mint ออกมาจากการล็อกอินคลาวด์ของคุณ ถ้าไม่มี ปุ่มจะยังกดไม่ได้ ดูวิธีบันทึก token ได้ที่ บทที่ 27
จากนั้นใน desktop GUI
- เปิด Settings → thClaws.cloud
- เลื่อนลงไปที่ 📡 thClaws Remote
- กด Enable
ปุ่มจะเปลี่ยนเป็น Enabling… เครื่อง desktop จะเอา CLI token ไปแลกกับ relay เป็น binding token บันทึกไว้ แล้วเชื่อมต่อ ถ้ายังไม่เคยบันทึก cloud token ไว้ การชี้เมาส์ค้างที่ปุ่มจะบอกว่า “Save a thClaws.cloud CLI token above first”
เท่านี้จบ ไม่ต้องพิมพ์รหัสอะไรที่ปลายทาง และ ไม่มี slash command
/remote — การ pair เป็น GUI action โดยเจตนา และฝั่ง CLI ไม่มีคำสั่ง
เทียบเท่า (ดูข้อจำกัด)
การเรียกใช้
เปิด thclaws.cloud/talk ในเบราว์เซอร์ ตัวไหนก็ได้ โดยล็อกอินด้วยบัญชีเดียวกัน แล้วพิมพ์ได้เลย ข้อความจะวิ่งตาม อุโมงค์ไปที่ desktop ตัว agent รัน turn นั้นในเครื่องด้วย tool registry เต็มชุด แล้วคำตอบ stream กลับมาทีละโทเคน
คำว่า “เชื่อมต่อแล้ว” มีสองความหมาย
หน้านั้นติดตามการเชื่อมต่อสองเส้นแยกกัน และควรรู้ว่าปัญหาอยู่เส้นไหน
- socket ระหว่างเบราว์เซอร์กับ relay นี่คือสิ่งที่สถานะ connecting / open / closed หมายถึง มันไม่ได้บอกอะไรเกี่ยวกับแล็ปท็อปคุณเลย
- การมีตัวตนของ desktop ที่ relay รายงานแยกอีกตัวหนึ่ง การที่เบราว์เซอร์ ต่อติดไม่ได้แปลว่า desktop ต่อติดด้วย
ดังนั้นอาการ “ต่อติดแต่ไม่มีใครตอบ” คือรูปแบบปกติของ แล็ปท็อปหลับอยู่หรือ ออฟไลน์ ไม่ใช่บั๊ก ปลุกเครื่องแล้วอุโมงค์จะกลับมาเอง
binding อยู่ที่ไหน
การ pair จะเขียนไฟล์เล็ก ๆ ลงในโปรเจกต์ที่คุณ pair จาก
.thclaws/state/phone-home.json
ในนั้นมี binding token, relay override (ถ้ามี) และ machine label ที่จะไป โผล่ในรายการอุปกรณ์บนคลาวด์ (เป็นแค่ของประดับ — binding ผูกกับ token ไม่ใช่ label) การเปิดครั้งถัด ๆ ไปจะอ่านไฟล์นี้แล้วเชื่อมต่อเอง คุณจึงเปิด Remote ครั้งเดียวต่อโปรเจกต์แล้วลืมมันไปได้เลย
binding เป็นระดับโปรเจกต์ เพราะตัวไฟล์เป็นแบบนั้น workspace ที่สองบน
เครื่องเดียวกันคือการ pair คนละครั้ง ต้องเปิดที่นั่นด้วย นี่เป็นผลพลอยได้
จากการที่ไฟล์อยู่ใต้ .thclaws/state/ ไม่ใช่การตัดสินใจเชิงนโยบาย แต่มีผล
ข้างเคียงที่ดีคือ โฟลเดอร์ที่คุณไม่เคย pair จะไม่มีทางถูกเข้าถึงได้ ไม่ว่า
คุณจะ pair โฟลเดอร์อื่นไว้กี่อัน
ไฟล์ phone-home.json ที่เสียหายจะถูกนับว่า “ยังไม่ได้ pair” แทนที่จะเป็น
error ไฟล์ที่พังจึงทำให้ปุ่ม Enable กลับมากดได้ ไม่ใช่ทำให้แอปค้าง
การตัดการเชื่อมต่อ
มีสองความหมายที่คุณอาจตั้งใจ
- หยุดอุโมงค์ไว้ก่อน ปิด thClaws หรือกด disconnect จาก GUI ตัว binding ยังอยู่บนดิสก์ และการเปิดครั้งหน้าจะเชื่อมต่อกลับ
- เลิก pair โฟลเดอร์นี้ ลบไฟล์
.thclaws/state/phone-home.jsonการเปิด ครั้งหน้าจะไม่มีอะไรให้เชื่อมต่อ และ/talkจะรายงานว่า desktop ออฟไลน์
ความปลอดภัยและขอบเขตความเชื่อใจ
- ไม่มีอะไรเปิดรอฟังอยู่บนเครื่องคุณ อุโมงค์คือการเชื่อมต่อขาออกที่ desktop เป็นฝ่ายเปิด ไม่มีพอร์ตให้เปิด ไม่มี firewall rule ให้เพิ่ม และ ไม่มีอะไรให้ scanner หาเจอ
- relay เห็นข้อความแชท ข้อความวิ่งผ่าน
line.thclaws.ai— relay ตัว เดียวกับที่ให้บริการ LINE และ Messenger — เพื่อทำการ route ส่วน prompt ที่คุณส่งไป Anthropic / OpenAI ฯลฯ ไม่ได้ ผ่านตรงนั้น มันวิ่งจาก desktop ไปหา provider ตรง ๆ - กุญแจของคุณไม่ออกจาก desktop relay ถือแค่ binding token เท่านั้น อ่าน provider key, ไฟล์ หรือ KMS ของคุณไม่ได้
- ใครถือบัญชีคลาวด์ของคุณ คนนั้นถืออุโมงค์ นั่นคือประเด็นของการผูกกับ cloud login แทนแพลตฟอร์มแชท และก็เป็นสิ่งที่ต้องปกป้องด้วย ให้ถือว่าการ เข้าถึงบัญชีคลาวด์เทียบเท่ากับการนั่งอยู่หน้าเครื่อง desktop ของคุณ
- approval ยังทำงานเหมือนเดิม turn ที่มาจาก Remote รันภายใต้ permission
mode เดียวกับ turn อื่น (บทที่ 5) ถ้าคุณอยู่ใน
autoข้อความที่พิมพ์จากร้านกาแฟก็จะรัน tool โดยไม่ถาม
การปิดสำหรับทั้งองค์กร
Remote เป็นพื้นผิวที่ deployment ซึ่งอยู่ภายใต้การกำกับดูแลกังวลมากที่สุด
เพราะมันทำให้ agent บนเครื่องทำงานถูกเข้าถึงได้จากนอกเครือข่าย บล็อก
runtime ใน managed policy ปิดมันได้
"runtime": { "enabled": true, "allow_remote": false }
หลังจากนั้นทุกเส้นทางที่จะเปิดอุโมงค์จะปฏิเสธ ทั้ง auto-connect ตอน boot,
ปุ่ม Enable และการ reconnect และ engine จะพิมพ์เหตุผลออกมาโดยระบุชื่อ
policies.runtime.allow_remote = false ผู้ใช้ที่สงสัยว่าทำไมมันไม่ทำงาน
จึงได้รู้ว่านโยบายข้อไหนหยุดไว้ แทนที่จะเห็นแค่ error ทั่ว ๆ ไป
ค่าเริ่มต้นคือ true — นโยบายจะปิด Remote ได้ก็ต่อเมื่อระบุไว้ชัดเจน ไม่ใช่
ด้วยการละฟิลด์ไว้ บทที่ 34 อธิบาย managed build และไฟล์นโยบายไว้ครบ
ข้อจำกัด
- ใช้ได้เฉพาะ GUI อุโมงค์ forward เข้า shared-session worker ซึ่ง
thclaws-cliไม่มีthclaws --cliจึง pair ไม่ได้และให้บริการ Remote session ไม่ได้ - หนึ่ง binding ต่อหนึ่งโปรเจกต์ ตามที่อธิบายไว้ข้างบน
- relay เป็นของเรา การ self-host relay ยังไม่ใช่ configuration ที่
รองรับในตอนนี้ ตัว
THCLAWS_PHONE_HOME_SERVERมีไว้ให้ build ระหว่าง พัฒนาชี้ไป relay ตัวอื่น ไม่ได้มีไว้เป็นทางเลือกสำหรับ deployment - ไม่มีคิวสำหรับตอนออฟไลน์ ข้อความที่ส่งตอน desktop ไม่ได้ออนไลน์จะไม่ ถูกเก็บไว้ให้ทีหลัง
การแก้ปัญหา
| อาการ | สาเหตุ | วิธีแก้ |
|---|---|---|
| ปุ่ม Enable เป็นสีเทากดไม่ได้ | ยังไม่ได้บันทึก CLI token ของ thClaws.cloud | Settings → thClaws.cloud → วาง token, Save แล้วค่อยกด Enable |
| ขึ้นว่า “log in to thClaws.cloud first” | เหมือนกัน — อ่าน token ไม่ได้ตอน pair | เหมือนข้างบน |
/talk ต่อติดแต่ไม่มีใครตอบ |
desktop หลับ ออฟไลน์ หรือไม่ได้เปิด thClaws | ปลุกเครื่องแล้วเปิด thClaws อุโมงค์จะกลับมาเอง |
| pair ไว้ที่โปรเจกต์หนึ่ง แต่อีกโปรเจกต์ไม่ทำงาน | binding เป็นระดับโปรเจกต์ | เปิด Remote จากโฟลเดอร์นั้นด้วย |
| ถูกปฏิเสธพร้อมข้อความเรื่องนโยบาย | policies.runtime.allow_remote = false |
ต้องคุยกับคนที่ดูแลนโยบาย ไม่สามารถ override จากเครื่องได้ |
เปิดไว้แล้วแต่ thclaws --cli ไม่ยอม pair |
ปกติ — ใช้ได้เฉพาะ GUI | ให้ pair จากแอป desktop |
ดูเพิ่มเติม
- บทที่ 27 — บัญชีคลาวด์, CLI token และ hosted workspace (ทางเลือกแบบ “ทำงานต่อได้โดยไม่ต้องมีแล็ปท็อป”)
- บทที่ 21 และ บทที่ 23 — bridge ของแพลตฟอร์มแชท ซึ่งใช้ relay และ transport ชุดเดียวกันนี้
- บทที่ 5 — turn ที่มาจาก remote ทำอะไรได้บ้าง
- คู่มือเทคนิค:
thclaws-remote.mdสำหรับรายละเอียดภายในของอุโมงค์