ครัวมืดที่มีแขนกลทำอาหารอยู่ฝั่งหนึ่ง กำแพงอิฐกั้นกลางพร้อมช่องส่งของเล็กที่มีไฟเขียว อีกฝั่งเป็นห้องกระจกที่มีเครื่องมือกล่องดำวางแยกบนโต๊ะสแตนเลส
aiai-agentsclinecoding-agentpluginssandboxnews

Cline เลิกให้ปลั๊กอินทำงานในแกนหลัก คนตั้ง in_process ต้องเช็ก

น้องกายEngineering

Cline ลองส่งคำขอใหม่ได้สูงสุด 3 ครั้งเมื่อผู้ให้บริการ AI ส่งข้อผิดพลาดระหว่างตอบ และ CLI 3.0.72 ยังยกเลิกการให้ปลั๊กอินทำงานตรงในแกนกลางของโปรแกรมด้วย ใครใช้ผู้ช่วยเขียนโค้ดทำงานประจำจึงควรเช็กทั้งงานที่อาจสะดุดและการตั้งค่าที่เคยใช้ได้ก่อนอัปเดต (GitHub: CLI 3.0.72)

จุดที่ผมอยากให้สนใจเป็นพิเศษคือ ปลั๊กอิน หรือโค้ดส่วนเสริมที่เพิ่มความสามารถให้โปรแกรม จะไม่ถูกย้ายกลับเข้าไปทำงานในแกนหลักแบบเงียบ ๆ เมื่อระบบแยกการทำงานไม่พร้อมอีกแล้ว รุ่น SDK 0.0.94 ระบุว่าถ้าองค์ประกอบสำหรับเริ่มปลั๊กอินขาดไป ระบบจะรายงานว่าโหลดไม่สำเร็จแทน สำหรับคนฝากงานอัตโนมัติไว้ เรื่องนี้แปลว่าควรตรวจว่าเครื่องมือยังอยู่ครบก่อนปล่อยงานจริงครับ (GitHub: SDK 0.0.94)

สรุป 30 วินาที: เกิดอะไรขึ้น

  • CLI 3.0.72 เลิกสนับสนุน CLINE_PLUGIN_MODE=in_process ซึ่งเป็นค่าที่สั่งให้ส่วนเสริมรันตรงในแกนกลาง เปลี่ยนไปใช้ worker เป็นค่าเริ่มต้น หรือเลือก sandbox สำหรับการรันแยกเป็นโปรแกรมย่อย โดย DevAgentRadar รายงานตรงกับบันทึกทางการในประเด็นนี้ (DevAgentRadar, GitHub: CLI 3.0.72)
  • SDK 0.0.94 ระบุข้อจำกัดสำคัญว่า hub ระยะไกลผ่าน SSH ซึ่งเป็นการเชื่อมไปทำงานบนอีกเครื่อง ยังไม่มีองค์ประกอบเริ่มปลั๊กอิน จึงรายงานว่าเครื่องมือจากปลั๊กอินหายไป (GitHub: SDK 0.0.94)
  • CLI 3.0.73 แก้ปัญหาคำขอของ GPT-6 ถูกปฏิเสธบนบริการ OpenAI และบริการที่เข้ากันได้ของ Azure พร้อมเปลี่ยนโมเดลเริ่มต้นของผู้ให้บริการ Cline กลับเป็น Claude Sonnet 5.5 เมื่อผู้ใช้ไม่ได้เลือกโมเดลเอง (GitHub: CLI 3.0.73)
  • Desktop 0.0.47 เอาสวิตช์ Cloud sessions ออกจากหน้าตั้งค่า และเปิดการทำงานบนคลาวด์ในที่ที่รองรับ ข้อความนี้ไม่ได้ยืนยันว่าใช้ได้ทุกบัญชีหรือทุกพื้นที่ (GitHub: Desktop 0.0.47)

ทำไมเรื่องนี้เกี่ยวกับคุณ

ถ้าคุณเป็นพนักงานออฟฟิศ เจ้าของร้าน นักศึกษา หรือผู้ปกครองที่ไม่ได้ใช้ Cline บทความนี้ไม่ได้มีเหตุให้ต้องไปเปลี่ยนการตั้งค่าอุปกรณ์ทุกเครื่อง แต่ถ้าคุณหรือทีมใช้ Cline ช่วยทำซอฟต์แวร์ จุดที่ควรถามทีมคือมีส่วนเสริมที่งานต้องพึ่งอยู่หรือไม่ เพราะรุ่นนี้เปลี่ยนเงื่อนไขการโหลดปลั๊กอิน และแจ้งเตือนเมื่อใช้ไม่ได้แทนการทำงานต่อแบบเดิม (GitHub: CLI 3.0.72)

สำหรับคนดูแลระบบ กลุ่มที่ควรลงมือตรวจทันทีคือคนที่เคยกำหนด CLINE_PLUGIN_MODE=in_process ไว้ในค่าของระบบ ไม่ว่าจะเป็นเครื่องทำงาน ระบบ CI ซึ่งรันงานตรวจหรือสร้างซอฟต์แวร์อัตโนมัติ หรือไฟล์ Compose ที่ใช้กำหนดการทำงานของชุดโปรแกรม คำแนะนำของผมคือค้นว่ามีการตั้งค่านี้ตรงไหนบ้าง เพราะค่าดังกล่าวไม่รองรับแล้วใน CLI 3.0.72 (GitHub: CLI 3.0.72)

อีกกลุ่มคือคนที่ไม่ได้เลือกชื่อโมเดลตายตัว รุ่น CLI 3.0.72 ใช้ Gemini 4 Argon เป็นค่าเริ่มต้นของผู้ให้บริการ Cline แต่ CLI 3.0.73 กลับมาใช้ Claude Sonnet 5.5 ผมจึงแนะนำให้ดูชื่อโมเดลก่อนเปรียบเทียบผลงานรอบเก่ากับรอบใหม่ เพราะอาจกำลังเทียบคนละโมเดลอยู่ แม้คุณจะไม่ได้กดเปลี่ยนเองก็ตาม (GitHub: CLI 3.0.72, GitHub: CLI 3.0.73)

ทำงานยังไง

ในข่าวนี้ hub คือโปรแกรมศูนย์กลางที่ Cline ใช้จัดการการทำงาน ส่วน in_process หมายถึงให้โค้ดปลั๊กอินทำงานอยู่ในกระบวนการเดียวกับศูนย์กลางนั้น บันทึกรุ่นระบุว่ารูปแบบใหม่ให้ปลั๊กอินทำงานใน worker threads คือหน่วยทำงานแยกภายในโปรแกรมเป็นค่าเริ่มต้น หรือใช้ subprocess sandbox คือสภาพแวดล้อมที่รันผ่านโปรแกรมย่อยแยกออกมา (GitHub: SDK 0.0.94)

ผมขอเปรียบกับร้านอาหารที่ให้ผู้รับเหมาภายนอกเข้ามาทำงานในครัวเดียวกัน กับให้ไปทำในครัวแยกที่มีหน้าต่างส่งของ แบบแรกคือแนวคิดของการรันในแกนหลัก ส่วนแบบหลังช่วยอธิบายเป้าหมายของการแยกงานและช่องทางสื่อสาร แต่เป็นเพียงภาพเปรียบเทียบครับ เอกสารที่ให้มายืนยันรูปแบบ worker กับ sandbox โดยไม่ได้แจกแจงว่าทั้งสองแบบจำกัดสิทธิ์เท่ากันหรือป้องกันอะไรได้ครบทุกด้าน (GitHub: SDK 0.0.94)

เหตุผลที่ต้องสนใจการใช้พื้นที่ร่วมกันคือ หากส่วนเสริมผิดพลาดหรือไม่น่าไว้ใจ การให้ทำงานในกระบวนการหลักย่อมทำให้ขอบเขตระหว่างส่วนเสริมกับแกนกลางมีความสำคัญมากขึ้น นี่เป็นคำอธิบายความเสี่ยงเชิงหลักการของผม ไม่ใช่รายงานว่าพบปลั๊กอินอันตรายในรุ่นนี้ ส่วนข้อเท็จจริงที่ผู้พัฒนาประกาศคือยกเลิกทั้งโหมดเดิมและทางเลือกสำรองที่เคยกลับไปรันใน hub อย่างเงียบ ๆ (GitHub: SDK 0.0.94)

เมื่อโปรแกรมเจ้าบ้านไม่มีส่วนเริ่มต้นที่จำเป็นต่อปลั๊กอิน รุ่น SDK 0.0.94 จะโหลดปลั๊กอินไม่สำเร็จพร้อมข้อผิดพลาดชื่อ PluginBootstrapMissingError ความหมายสำหรับผู้ใช้คือระบบกำลังบอกว่าขาดองค์ประกอบรองรับ ไม่ควรสรุปทันทีว่าโมเดล AI ลืมวิธีใช้เครื่องมือ ส่วน CLI จะแสดงปัญหาในรายการเครื่องมือ รายการปลั๊กอิน และคำเตือนตอนเริ่มงาน (GitHub: SDK 0.0.94, GitHub: CLI 3.0.72)

เรื่องลองใหม่ก็มีรายละเอียดที่ช่วยคนดูแลงานอัตโนมัติ เมื่อผู้ให้บริการส่งข้อผิดพลาดหลังเริ่มทยอยส่งคำตอบแล้ว SDK จะลองใหม่สูงสุด 3 ครั้ง หากยังไม่สำเร็จจะบันทึกความล้มเหลว และไม่ไปเปิดการลองใหม่ทั้งรอบงานซ้ำอีกชั้นจนจำนวนครั้งทบกัน เอกสารยังระบุว่าบันทึกคำขอที่ล้มเหลวมีรหัสคำขอจากผู้ให้บริการ เพื่อช่วยตามหาปัญหาได้สะดวกขึ้น (GitHub: SDK 0.0.94)

จุดหักมุม: เครื่องมือหายอาจเป็นการหยุดที่ตั้งใจไว้

ปกติเห็นเครื่องมือหายหลังอัปเดต เรามักคิดว่าโปรแกรมพัง แต่กรณีนี้มีเงื่อนไขที่ผู้พัฒนาระบุไว้ชัด คือหากขาดองค์ประกอบเริ่มปลั๊กอิน ระบบต้องปฏิเสธการโหลด และ SSH remote hub ยังอยู่ในกลุ่มที่ไม่มีองค์ประกอบนี้ จึงรายงานว่าเครื่องมือจากปลั๊กอินไม่มีให้ใช้ (GitHub: SDK 0.0.94)

ผมมองว่าสิ่งนี้ทำให้คำเตือนมีคุณค่ากว่าการเห็นงานเดินต่อเฉย ๆ เพราะผู้ดูแลมีโอกาสรับรู้ว่าความสามารถที่ต้องการยังไม่พร้อม ข้อเสนอของผมคือเมื่อเครื่องมือหาย ให้ตรวจสถานะปลั๊กอินและรูปแบบการเชื่อมต่อก่อนพยายามแก้คำสั่งที่ส่งให้ AI การพิมพ์กำชับว่า “ช่วยตั้งใจหน่อย” คงเติมส่วนประกอบที่หายให้โปรแกรมไม่ได้ครับ (GitHub: CLI 3.0.72, GitHub: SDK 0.0.94)

ขณะเดียวกัน Desktop 0.0.47 แก้ปัญหาปลั๊กอินจาก Marketplace เช่น goal โหลดไม่ได้ใน 0.0.46 เพราะแอปที่แพ็กมาไม่มีชุด SDK ที่ปลั๊กอินต้องใช้ เรื่องนี้เป็นคนละรายละเอียดกับข้อจำกัดของ SSH จึงไม่ควรเห็นคำว่า “แก้ปลั๊กอินแล้ว” แล้วเหมารวมว่าทุกรูปแบบการใช้งานจะพร้อมเท่ากัน (GitHub: Desktop 0.0.47)

เรื่องเงิน / ผลกระทบ

แหล่งข้อมูลชุดนี้ไม่มีราคาใหม่ ไม่มีราคาไทย และไม่มีผลทดสอบว่าการแยกปลั๊กอินช่วยลดค่าใช้จ่ายหรือทำงานเร็วขึ้นเท่าไร จึงยังใช้ข่าวนี้คำนวณเงินประหยัดต่อเดือนไม่ได้ สิ่งที่ยืนยันได้คือมีการเปลี่ยนโมเดลเริ่มต้นและเพิ่มการลองใหม่เมื่อคำตอบสะดุด ส่วนผลต่อบิลของแต่ละคนยังต้องดูเงื่อนไขบริการและการใช้งานจริงของตัวเอง (GitHub: CLI 3.0.73, GitHub: SDK 0.0.94)

ผลกระทบที่ผมแนะนำให้ประเมินก่อนคือเวลาที่ต้องหยุดตรวจงาน ถ้างานจำเป็นต้องใช้ปลั๊กอิน ให้ทดลองความพร้อมหลังเปลี่ยนรุ่นก่อนนำไปใช้กับกำหนดส่งจริง เพราะการโหลดที่เคยถอยกลับไปทำใน hub จะไม่เกิดขึ้นอีกแล้ว การลองใหม่ของคำขอโมเดลก็ไม่ใช่หลักประกันว่างานที่ขาดเครื่องมือจะทำสำเร็จ ทั้งสองเรื่องเป็นคนละปัญหาที่บันทึกรุ่นอธิบายแยกกัน (GitHub: SDK 0.0.94)

ส่วนการแก้ GPT-6 ใน CLI 3.0.73 เป็นการแก้รูปแบบข้อมูลที่ส่งไปยัง OpenAI และ Azure ให้บริการยอมรับคำขอ ไม่ใช่หลักฐานว่าโมเดลฉลาดขึ้นหรือราคาถูกลง บันทึกรุ่นระบุว่าก่อนแก้ คำขอถูกปฏิเสธทั้งหมดจากปัญหานี้ คนที่เจออาการดังกล่าวจึงมีเหตุผลตรงตัวในการนำรุ่นใหม่ไปทดสอบ (GitHub: CLI 3.0.73)

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

เรื่องโมเดลเริ่มต้นดูเหมือนข้อมูลขัดกันหากอ่านข้ามรุ่น DevAgentRadar ระบุว่า CLI 3.0.72 ใช้ Gemini 4 Argon ซึ่งตรงกับแท็กรุ่นทางการ แต่ CLI 3.0.73 ระบุว่ากลับมาใช้ Claude Sonnet 5.5 จึงเป็นการเปลี่ยนตามรุ่น ไม่ใช่ข้อสรุปว่าผู้ใช้ Cline ทุกแบบใช้ค่าเริ่มต้นเดียวกันตลอดช่วงนี้ (DevAgentRadar, GitHub: CLI 3.0.72, GitHub: CLI 3.0.73)

เรื่องวันเผยแพร่ไม่มีข้อขัดแย้งในหลักฐานที่ให้มา CLI 3.0.72 เผยแพร่วันที่ 16 ตุลาคม 2026 เวลาไทย 12:35:42 น. ส่วน CLI 3.0.73 เผยแพร่วันที่ 17 ตุลาคม เวลาไทย 10:59:11 น. ทั้งสองเวลาคำนวณจากเวลาที่ลงท้ายด้วย Z ในแท็กรุ่น ซึ่งหมายถึงเวลา UTC แล้วบวก 7 ชั่วโมงเป็นเวลาไทย (GitHub: CLI 3.0.72, GitHub: CLI 3.0.73)

สิ่งที่ยังไม่ทราบคือรายละเอียดการจำกัดสิทธิ์ของ worker เทียบกับ sandbox รายชื่อพื้นที่หรือบัญชีที่เปิด Cloud sessions ได้ และกำหนดการที่ SSH remote hub จะรองรับปลั๊กอิน ข้อความ Desktop ระบุเพียงว่าเปิด Cloud sessions ในที่ที่พร้อมให้บริการ ขณะที่ SDK ระบุข้อจำกัด SSH ในรุ่นนั้น จึงยังอ้างไม่ได้ว่าผู้ใช้ในไทยทุกคนได้ฟีเจอร์คลาวด์ หรือองค์กรไทยใดได้รับผลกระทบแล้ว (GitHub: Desktop 0.0.47, GitHub: SDK 0.0.94)

แล้วเราควรทำอะไร

ผู้ใช้ทั่วไปและคนที่จ้างทีมทำซอฟต์แวร์

  1. ถ้าทีมใช้ Cline ให้ถามว่ามีปลั๊กอินใดจำเป็นต่องาน และให้ทีมยืนยันว่าโหลดได้หลังอัปเดต ผมแนะนำให้ตรวจจากสถานะจริง เพราะ CLI รุ่นนี้แสดงคำเตือนเมื่อปลั๊กอินใช้ไม่ได้แล้ว (GitHub: CLI 3.0.72)
  2. ให้ทีมระบุชื่อโมเดลในการทดสอบรับงานด้วย โดยเฉพาะเมื่อเคยปล่อยให้ระบบเลือกเอง เพราะค่าเริ่มต้นของผู้ให้บริการ Cline เปลี่ยนระหว่าง 3.0.72 กับ 3.0.73 (GitHub: CLI 3.0.72, GitHub: CLI 3.0.73)

นักพัฒนาและผู้ดูแล CI หรือ Compose

  1. ตรวจค่าที่ตั้งไว้ในเครื่องและระบบงานอัตโนมัติ หากมี CLINE_PLUGIN_MODE=in_process ให้ปรับไปใช้ worker หรือ sandbox ที่รองรับ แล้วทดสอบปลั๊กอินที่จำเป็นในสภาพแวดล้อมทดลองก่อน (GitHub: CLI 3.0.72)
  2. ตรวจรายการเครื่องมือผ่าน cline config tools และสถานะปลั๊กอินผ่าน cline hub plugins พร้อมอ่านคำเตือนตอนเริ่มงาน หากพบ PluginBootstrapMissingError ให้ตรวจความพร้อมของโปรแกรมเจ้าบ้าน แทนการพยายามเปิดโหมดเก่ากลับมา (GitHub: CLI 3.0.72, GitHub: SDK 0.0.94)
  3. ถ้าใช้งานผ่าน SSH ให้ยืนยันก่อนว่างานเดินต่อได้โดยไม่มีเครื่องมือจากปลั๊กอิน เพราะ SDK 0.0.94 ระบุข้อจำกัดนี้ไว้ชัด ผมแนะนำให้แยกการทดสอบงานระยะไกลออกจากงานบนเครื่องตัวเอง (GitHub: SDK 0.0.94)
  4. เมื่อตามปัญหาคำขอ AI ให้เก็บข้อความผิดพลาดและรหัสคำขอของผู้ให้บริการไว้ส่งให้ฝ่ายสนับสนุนอย่างเหมาะสม รุ่นนี้เพิ่มรหัสดังกล่าวในบันทึกคำขอที่ล้มเหลวแล้ว (GitHub: CLI 3.0.72)

ผู้ใช้ GPT-6 และ Desktop

  1. หาก GPT-6 ถูกปฏิเสธบน OpenAI หรือ Azure ให้ทดลอง CLI 3.0.73 หรือ SDK 0.0.95 ตามส่วนที่ใช้งาน ทั้งสองรุ่นมีการแก้รูปแบบคำขอที่เกี่ยวข้อง (GitHub: CLI 3.0.73, GitHub: SDK 0.0.95)
  2. ผู้ใช้ Desktop 0.0.47 ควรตรวจความพร้อมของ Cloud sessions จากสิ่งที่บัญชีใช้งานได้จริง การไม่มีสวิตช์ใน Settings สอดคล้องกับการเปลี่ยนแปลงที่ประกาศ แต่ยังไม่ใช่คำยืนยันว่าทุกคนได้รับบริการแล้ว (GitHub: Desktop 0.0.47)

หลักฐานความปลอดภัยและความเสี่ยงที่ยังเหลือ

ที่มาหลักเป็นคลังโค้ดทางการ cline/cline บน GitHub โดยมีแท็กระบุรุ่นและเวลาเผยแพร่ SDK 0.0.94 เผยแพร่วันที่ 16 ตุลาคม 2026 เวลาไทย 10:51:13 น. และ CLI 3.0.72 เวลาไทย 12:35:42 น. วันเดียวกัน ส่วน SDK 0.0.95 เผยแพร่วันที่ 17 ตุลาคม เวลาไทย 10:00:13 น. และ CLI 3.0.73 เวลาไทย 10:59:11 น. หลักฐานเหล่านี้ช่วยผูกคำอธิบายกับรุ่นเฉพาะ แทนการอ่านบันทึกรวมแล้วคิดว่าทุกอย่างเกิดพร้อมกัน (GitHub: SDK 0.0.94, GitHub: CLI 3.0.72, GitHub: SDK 0.0.95, GitHub: CLI 3.0.73)

หน้า Security ที่ได้รับมาแสดงนโยบายว่า Cline ดูแลแพตช์อย่างจริงจังเฉพาะรุ่นย่อยล่าสุด รุ่นเก่ารับการแก้ไขตามดุลพินิจ และรับแจ้งปัญหาผ่านโครงการเปิดเผยช่องโหว่ของ Bugcrowd ข้อความที่ให้มาไม่ได้แสดงรายการประกาศช่องโหว่หรือหมายเลข CVE จึงสรุปไม่ได้ว่าโครงการไม่มีช่องโหว่ และไม่มีหลักฐานพอจะตั้งชื่อช่องโหว่ให้การเปลี่ยนปลั๊กอินครั้งนี้ (GitHub: Security)

เรื่องค่าเริ่มต้นต้องแยกให้ชัดว่า worker เป็นค่าเริ่มต้นของวิธีรันปลั๊กอิน ไม่ใช่หลักฐานว่าระบบขออนุมัติผู้ใช้ก่อนทุกการกระทำ แหล่งข้อมูลไม่ได้แจกแจงสิทธิ์อ่านไฟล์ เขียนไฟล์ หรือเข้าถึงเครือข่ายของแต่ละโหมดครบถ้วน จึงยังรับรองขอบเขตเหล่านั้นไม่ได้ ส่วนบันทึก CLI ระบุว่าโหมด -y หรือ --yolo มีคำเตือนให้ใช้เฉพาะในสภาพแวดล้อม sandbox คำเตือนนี้ไม่ใช่คำรับรองว่าเปิดแล้วจะปลอดภัยทุกกรณี (GitHub: SDK 0.0.94, GitHub: CLI changelog)

ข้อเสนอด้านความปลอดภัยของผมคือ เริ่มจากโปรเจกต์ที่ทิ้งได้หรือสภาพแวดล้อมทดสอบ ใช้ข้อมูลตัวอย่าง ตรวจการตั้งค่าอนุมัติด้วยตัวเอง และอย่าใส่ข้อมูลรับรองของระบบใช้งานจริง เช่น กุญแจเข้าถึงบริการจริง ระหว่างทดลอง การมี worker หรือ sandbox ยังไม่เพียงพอให้เรียกว่าปลอดภัย 100% โดยเฉพาะเมื่อเอกสารชุดนี้ยังไม่ได้อธิบายขอบเขตสิทธิ์ทั้งหมด และปลั๊กอินที่โหลดไม่ได้ก็ยังเป็นความเสี่ยงต่อความครบถ้วนของงาน (GitHub: SDK 0.0.94)

ผมมองว่า…

ผมมองว่า การยอมแจ้งว่าใช้ปลั๊กอินไม่ได้เป็นทิศทางที่ดี ความเห็นของผมคือคุณค่าของการอัปเดตนี้ไม่ใช่ความสะดวกที่ทำให้งานเดินต่อทุกครั้ง แต่คือความชัดเจนว่าระบบกำลังทำงานภายใต้เงื่อนไขใด โดยเฉพาะเมื่อผู้พัฒนาถอดทางเลือกสำรองที่เคยกลับไปรันในแกนกลางเงียบ ๆ ออกแล้ว (GitHub: SDK 0.0.94)

สำหรับทีมเล็ก ผมให้น้ำหนักกับการทดลองงานเดิมให้ครบก่อน มากกว่าการรีบเปิดตัวเลือกอัตโนมัติทุกอย่าง ข้อเท็จจริงที่รองรับความระวังนี้คือมีทั้งการเปลี่ยนวิธีโหลดปลั๊กอิน ข้อจำกัด SSH และการเปลี่ยนโมเดลเริ่มต้นในช่วงรุ่นติดกัน การรู้ว่าแต่ละอย่างเปลี่ยนตรงไหนช่วยให้ทีมแยกสาเหตุได้เมื่องานต่างจากเดิม (GitHub: SDK 0.0.94, GitHub: CLI 3.0.73)

ปิดท้าย: สิ่งที่ต้องจับตา

สิ่งที่ควรติดตามต่อคือความพร้อมของปลั๊กอินบน SSH remote hub รายละเอียดสิทธิ์ของ worker และ sandbox และขอบเขตการให้บริการ Cloud sessions เพราะหลักฐานชุดนี้ยังบอกได้เพียงข้อจำกัดปัจจุบันของ SDK 0.0.94 กับคำว่าเปิดใช้คลาวด์ในที่ที่รองรับ ยังไม่มีข้อมูลพอระบุวันแก้ข้อจำกัดหรือการเปิดใช้ในไทย (GitHub: SDK 0.0.94, GitHub: Desktop 0.0.47)

งานที่ทำได้ตอนนี้คือให้ผู้ดูแลรู้ว่าติดตั้งรุ่นไหน ใช้โมเดลอะไร และปลั๊กอินที่งานต้องพึ่งพร้อมหรือยัง ผมแนะนำให้จดผลทดลองไว้ก่อนใช้กับงานจริง เพราะรุ่นใหม่เปลี่ยนทั้งรูปแบบการโหลดส่วนเสริมและค่าเริ่มต้นของโมเดล การตรวจสองจุดนี้ช่วยให้การตัดสินใจอัปเดตมีหลักฐานของทีมตัวเองประกอบด้วย (GitHub: CLI 3.0.72, GitHub: CLI 3.0.73)

Recap

  • ตรวจรุ่น Cline ที่ใช้อยู่ก่อนนำผลทดสอบมาเปรียบเทียบ
  • ตรวจว่ามีการตั้ง CLINE_PLUGIN_MODE=in_process ค้างไว้หรือไม่
  • เลือกโหมดที่รองรับและทดลองปลั๊กอินที่จำเป็นให้ครบ
  • อ่านสถานะปลั๊กอินและคำเตือนตอนเริ่มงานก่อนปล่อยงานอัตโนมัติ
  • ตรวจข้อจำกัดของ SSH remote hub หากต้องใช้เครื่องมือจากปลั๊กอิน
  • ยืนยันชื่อโมเดลที่ใช้จริง โดยเฉพาะเมื่อปล่อยให้ระบบเลือกค่าเริ่มต้น
  • ทดลองด้วยโปรเจกต์ที่ทิ้งได้และไม่ใช้ข้อมูลรับรองของระบบจริง
  • อย่าตีความ worker, sandbox หรือการเปิด Cloud sessions ว่าเป็นคำรับรองความปลอดภัยทั้งหมด