openclaw update

อัปเดต OpenClaw และสลับระหว่างช่องทาง stable/extended-stable/beta/dev

หากติดตั้งผ่าน npm/pnpm/bun (การติดตั้งแบบ global ที่ไม่มีข้อมูลเมตาของ git) การอัปเดตจะดำเนินการผ่านขั้นตอนของตัวจัดการแพ็กเกจที่อธิบายไว้ใน การอัปเดต

การใช้งาน

openclaw updateopenclaw update statusopenclaw update repairopenclaw update wizardopenclaw update --channel extended-stableopenclaw update --channel betaopenclaw update --channel devopenclaw update --tag betaopenclaw update --tag mainopenclaw update --dry-runopenclaw update --no-restartopenclaw update --yesopenclaw update --acknowledge-clawhub-riskopenclaw update --jsonopenclaw --update

openclaw --update จะถูกเขียนใหม่เป็น openclaw update (มีประโยชน์สำหรับเชลล์และ สคริปต์ตัวเรียกใช้งาน)

ตัวเลือก

ไม่มีแฟล็ก --verbose ใช้ --dry-run เพื่อแสดงตัวอย่างการดำเนินการที่วางแผนไว้ ใช้ --json สำหรับผลลัพธ์ที่เครื่องอ่านได้ และใช้ openclaw update status --json สำหรับข้อมูลช่องทาง/ความพร้อมใช้งานเท่านั้น ระดับความละเอียดของคอนโซล Gateway (--verbose) และ ระดับบันทึกไฟล์ (logging.level: "debug"/"trace") เป็นการตั้งค่าที่แยกจากกัน โปรดดู การบันทึกของ Gateway

update status

แสดงช่องทางอัปเดตที่ใช้งานอยู่ แท็ก/สาขา/SHA ของ git (เฉพาะเช็กเอาต์ซอร์ส) และความพร้อมใช้งานของการอัปเดต

openclaw update statusopenclaw update status --jsonopenclaw update status --timeout 10

สำหรับการติดตั้งแพ็กเกจ extended-stable สถานะจะใช้ตัวเลือกสาธารณะ และการตรวจสอบแพ็กเกจแบบระบุแน่นอนเช่นเดียวกับการอัปเดตในโฟร์กราวด์ โดยอาจรายงาน ahead of extended-stable เมื่อเวอร์ชันที่ติดตั้งใหม่กว่า ความล้มเหลวใน JSON จะรวม registry.reason (selector_missing, selector_query_failed, exact_package_mismatch หรือ unsupported_git_channel)

update repair

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

openclaw update repairopenclaw update repair --channel betaopenclaw update repair --acknowledge-clawhub-riskopenclaw update repair --json

update repair จะเรียกใช้ openclaw doctor --fix โหลดการกำหนดค่าที่ซ่อมแซมแล้วและ ระเบียนการติดตั้งใหม่ ซิงค์ Plugin ที่ติดตามไว้สำหรับช่องทางอัปเดตที่ใช้งานอยู่ อัปเดต การติดตั้ง Plugin npm ที่มีการจัดการ ซ่อมแซมเพย์โหลด Plugin ที่กำหนดค่าไว้แต่ขาดหาย รีเฟรชรีจิสทรี Plugin และเขียนข้อมูลเมตาของระเบียนการติดตั้งที่เข้าสู่สถานะสอดคล้องกัน คำสั่งนี้จะไม่ติดตั้งแพ็กเกจคอร์ใหม่และจะไม่รีสตาร์ต Gateway

update wizard

ขั้นตอนแบบโต้ตอบสำหรับเลือกช่องทางอัปเดตและยืนยันว่าจะรีสตาร์ต Gateway ภายหลังหรือไม่ (ค่าเริ่มต้นคือรีสตาร์ต) การเลือก dev โดยไม่มีเช็กเอาต์ git จะแสดงตัวเลือกให้สร้างเช็กเอาต์

การทำงาน

การสลับช่องทางอย่างชัดเจน (--channel ...) ยังทำให้วิธีการติดตั้ง สอดคล้องกันด้วย:

• dev -> ตรวจสอบให้มีเช็กเอาต์ git (ค่าเริ่มต้นคือ ~/openclaw หรือ $OPENCLAW_HOME/openclaw เมื่อตั้งค่า OPENCLAW_HOME; แทนที่ได้ด้วย OPENCLAW_GIT_DIR) อัปเดตเช็กเอาต์นั้น และติดตั้ง CLI แบบ global จาก เช็กเอาต์ดังกล่าว
• stable -> ติดตั้งจาก npm โดยใช้ latest
• extended-stable -> แก้ไขตัวเลือก npm สาธารณะ extended-stable ตรวจสอบแพ็กเกจที่เลือกแบบระบุแน่นอน และติดตั้งเวอร์ชันดังกล่าวโดยตรง โดยจะไม่ใช้ตัวเลือกอื่นเป็นทางเลือกสำรองและจะถูกปฏิเสธสำหรับเช็กเอาต์ Git
• beta -> ให้ความสำคัญกับ dist-tag beta ของ npm และใช้ latest เป็นทางเลือกสำรองเมื่อไม่มี beta หรือ beta เก่ากว่ารุ่น stable ปัจจุบัน

การส่งต่อเพื่อรีสตาร์ต

ตัวอัปเดตอัตโนมัติของคอร์ Gateway (เมื่อเปิดใช้งานผ่านการกำหนดค่า) จะเรียกใช้เส้นทาง การอัปเดตของ CLI ภายนอกตัวจัดการคำขอ Gateway ที่กำลังทำงาน การอัปเดตผ่านตัวจัดการแพ็กเกจ update.run ของระนาบควบคุมและการอัปเดตเช็กเอาต์ git ที่มีการกำกับดูแลจะใช้ การส่งต่อไปยังบริการที่มีการจัดการแบบเดียวกัน แทนการแทนที่โครงสร้างแพ็กเกจหรือ สร้าง dist/ ใหม่ภายในกระบวนการ Gateway ที่กำลังทำงาน กล่าวคือ Gateway จะเริ่ม ตัวช่วยแบบแยกออกจากกระบวนการแล้วออก จากนั้นตัวช่วยดังกล่าวจะเรียกใช้ openclaw update --yes --json จากภายนอกโครงสร้างกระบวนการ Gateway หากการส่งต่อไม่พร้อมใช้งาน update.run จะส่งคืนการตอบกลับแบบมีโครงสร้างพร้อมคำสั่งเชลล์ที่ปลอดภัยสำหรับเรียกใช้ ด้วยตนเอง

การเลือก extended-stable ที่จัดเก็บไว้จะได้รับคำแนะนำแบบอ่านอย่างเดียวเมื่อเริ่มต้นระบบและทุก 24 ชั่วโมงเกี่ยวกับการอัปเดต เมื่อเปิดใช้งาน update.checkOnStart การตรวจสอบเหล่านี้จะไม่นำการอัปเดตมาใช้ ไม่เริ่มการส่งต่องาน ไม่รีสตาร์ต Gateway ไม่ใช้ระยะหน่วง/ความคลาดเคลื่อนแบบ stable และไม่ใช้ รอบการสำรวจแบบ beta การอัปเดตแบบ foreground ที่ระบุชัดเจน การอัปเดตแบบ foreground เปล่าที่มี update.channel: "extended-stable" จัดเก็บไว้ สถานะแบบตามคำขอ และการส่งต่องานของ Gateway ที่ได้รับการจัดการสำหรับรายการเหล่านี้ยังคงรองรับ

เมื่อติดตั้งบริการ Gateway ที่ได้รับการจัดการภายในเครื่องและเปิดใช้งานการรีสตาร์ต การอัปเดตผ่านตัวจัดการแพ็กเกจและ git checkout จะหยุดบริการที่กำลังทำงานก่อน แทนที่โครงสร้างแพ็กเกจหรือแก้ไข checkout/เอาต์พุตการบิลด์ จากนั้นตัวอัปเดต จะรีเฟรชข้อมูลเมตาของบริการ รีสตาร์ตบริการ และตรวจสอบ Gateway ที่รีสตาร์ตแล้วก่อนรายงาน Gateway: restarted and verified. นอกจากนี้ การอัปเดตผ่านตัวจัดการแพ็กเกจยังตรวจสอบว่า Gateway ที่รีสตาร์ตรายงาน เวอร์ชันแพ็กเกจที่คาดไว้ ส่วนการอัปเดต git checkout จะตรวจสอบสถานะความพร้อมใช้งานของ gateway และ ความพร้อมของบริการหลังการบิลด์ใหม่

โดยปกติการอัปเดตผ่านตัวจัดการแพ็กเกจจะยังคงใช้ไบนารี Node ที่บันทึกไว้ใน บริการที่ได้รับการจัดการ หาก Node นั้นไม่สามารถรันรุ่นเป้าหมายได้ แต่ Node ของ CLI ปัจจุบันทำได้ และพิสูจน์แล้วว่าบริการเป็นของแพ็กเกจที่กำลังอัปเดต การอัปเดตที่เปิดใช้งานการรีสตาร์ตจะใช้ Node ปัจจุบันในการดำเนินการขั้นสุดท้าย และเขียน ข้อมูลเมตาของบริการใหม่ให้ใช้รันไทม์นั้น --no-restart ไม่สามารถซ่อมแซมข้อมูลเมตา ของบริการได้ ดังนั้นความไม่ตรงกันของรันไทม์แบบเดียวกันจะทำให้หยุดก่อนแก้ไขแพ็กเกจ

บน macOS การตรวจสอบหลังอัปเดตยังตรวจสอบว่า LaunchAgent โหลด/ทำงานอยู่สำหรับโปรไฟล์ที่ใช้งาน และพอร์ต loopback ที่กำหนดค่าไว้ พร้อมใช้งาน หากติดตั้ง plist แล้ว แต่ launchd ไม่ได้ควบคุมดูแล OpenClaw จะบูตสแตรป LaunchAgent ใหม่โดยอัตโนมัติ และเรียกใช้การตรวจสอบสถานะความพร้อมใช้งาน/เวอร์ชัน/ ความพร้อมของช่องทางอีกครั้ง (การบูตสแตรปใหม่จะโหลดงาน RunAtLoad โดยตรง ดังนั้นการกู้คืนจึงไม่ kickstart -k Gateway ที่เพิ่งสร้างทันที) หาก Gateway ยังไม่พร้อมใช้งาน คำสั่งจะออกด้วยรหัสที่ไม่ใช่ศูนย์ และ พิมพ์พาธบันทึกการรีสตาร์ต พร้อมคำแนะนำสำหรับการรีสตาร์ต การติดตั้งใหม่ และการย้อนกลับ แพ็กเกจ

หากไม่สามารถรีสตาร์ตได้ คำสั่งจะพิมพ์ Gateway: restart skipped (...) หรือ Gateway: restart failed: ... พร้อมคำแนะนำให้ดำเนินการ openclaw gateway restart ด้วยตนเอง เมื่อใช้ --no-restart การแทนที่แพ็กเกจหรือการบิลด์ git ใหม่จะยังคงทำงาน แต่ บริการที่ได้รับการจัดการจะไม่ถูกหยุดหรือรีสตาร์ต ดังนั้น Gateway ที่กำลังทำงานจะยังใช้ โค้ดเก่าจนกว่าจะรีสตาร์ตด้วยตนเอง

รูปแบบการตอบกลับของระนาบควบคุม

เมื่อ update.run ทำงานผ่านระนาบควบคุมของ Gateway ในการติดตั้งผ่านตัวจัดการแพ็กเกจ หรือ git checkout ที่มีการควบคุมดูแล ตัวจัดการจะรายงานการเริ่มต้นการส่งต่องาน แยกจากการอัปเดตของ CLI ที่ดำเนินต่อหลังจาก Gateway ออก:

• ok: true, result.status: "skipped", result.reason: "managed-service-handoff-started" และ handoff.status: "started": Gateway ได้สร้างการส่งต่องานของบริการที่ได้รับการจัดการ และกำหนดเวลาการรีสตาร์ตของตัวเอง เพื่อให้ตัวช่วยที่แยกออกมาสามารถเรียกใช้ openclaw update --yes --json ภายนอกโพรเซสบริการที่กำลังทำงาน
• ok: false, result.reason: "managed-service-handoff-unavailable" และ handoff.status: "unavailable": OpenClaw ไม่พบขอบเขตบริการที่ควบคุมดูแล และข้อมูลประจำตัวบริการที่คงทนสำหรับการส่งต่องานอย่างปลอดภัย (ตัวอย่างเช่น การส่งต่องานของ systemd ต้องใช้ข้อมูลประจำตัวหน่วย OPENCLAW_SYSTEMD_UNIT ไม่ใช่เพียงตัวบ่งชี้โพรเซส systemd จากสภาพแวดล้อม) การตอบกลับประกอบด้วย handoff.command ซึ่งเป็นคำสั่งเชลล์ที่ต้องเรียกใช้จากภายนอก Gateway
• ok: false, result.reason: "managed-service-handoff-failed": Gateway พยายามสร้างการส่งต่องาน แต่ไม่สามารถสร้างโพรเซสตัวช่วยที่แยกออกมาได้

เพย์โหลด sentinel จะถูกเขียนก่อน Gateway ออก และการส่งต่องานของ CLI จะอัปเดตตัวบ่งชี้การรีสตาร์ตเดียวกันหลังจากการตรวจสอบสถานะความพร้อมใช้งานของบริการที่ได้รับการจัดการ หลังรีสตาร์ตเสร็จสมบูรณ์ ระหว่างการส่งต่องาน ตัวบ่งชี้สามารถมี stats.reason: "restart-health-pending" โดยไม่มีการดำเนินการต่อเมื่อสำเร็จ Gateway ที่รีสตาร์ตจะสำรวจตัวบ่งชี้นี้ และเรียกการดำเนินการต่อเมื่อ CLI ตรวจสอบสถานะความพร้อมใช้งานของบริการแล้ว และเขียนตัวบ่งชี้ใหม่ด้วยผลลัพธ์ ok ขั้นสุดท้ายเท่านั้น openclaw status และ openclaw status --all แสดงแถว Update restart ขณะที่ตัวบ่งชี้นั้นกำลังรอดำเนินการหรือล้มเหลว และ update.status จะรีเฟรชและ ส่งคืนตัวบ่งชี้ล่าสุด

ขั้นตอนของ Git checkout

การเลือกช่องทาง

• stable: checkout แท็กล่าสุดที่ไม่ใช่ beta จากนั้นบิลด์และเรียกใช้ doctor
• beta: เลือกใช้แท็ก -beta ล่าสุด โดยถอยกลับไปใช้แท็ก stable ล่าสุด เมื่อไม่มี beta หรือ beta เก่ากว่า
• dev: checkout main จากนั้น fetch และ rebase
• extended-stable: ไม่รองรับสำหรับ Git checkout และจะไม่มีการแก้ไข checkout

ขั้นตอนการอัปเดต

รายละเอียดการซิงค์ Plugin

ในช่องทาง beta การติดตั้ง plugin จาก npm และ ClawHub ที่ติดตามไว้และใช้สาย default/latest จะลองใช้รุ่น @beta ของ plugin ก่อน หาก plugin ไม่มี รุ่น beta OpenClaw จะถอยกลับไปใช้ข้อกำหนด default/latest ที่บันทึกไว้ และ รายงานคำเตือน สำหรับ plugin จาก npm OpenClaw จะถอยกลับเช่นกันเมื่อมีแพ็กเกจ beta แต่ไม่ผ่านการตรวจสอบการติดตั้ง คำเตือนจากการถอยกลับเหล่านี้จะไม่ทำให้ การอัปเดตแกนหลักล้มเหลว เวอร์ชันที่ระบุแน่นอนและแท็กที่ระบุชัดเจนจะไม่ถูกเขียนใหม่

หลังจากการอัปเดตแกนหลัก extended-stable สำเร็จ ความสมบูรณ์และ การบรรจบกันของ plugin หลังแกนหลักจะกำหนดเป้าหมายไปยัง plugin npm อย่างเป็นทางการที่เข้าเกณฑ์ ณ เวอร์ชันแกนหลัก ที่ติดตั้งไว้อย่างแน่นอน สำหรับเจตนา default/latest OpenClaw จะไม่ค้นหา @extended-stable ของ plugin หรือถอยกลับไปใช้ latest ของ npm แต่จะอนุมานเวอร์ชันแพ็กเกจ จากแกนหลักที่ติดตั้งไว้ การปักหมุดเวอร์ชันอย่างชัดเจน แท็กที่ระบุชัดเจนซึ่งไม่ใช่ latest แพ็กเกจของบุคคลที่สาม และแหล่งที่ไม่ใช่ npm จะคงเจตนาที่มีอยู่ไว้

สำหรับการติดตั้งผ่านตัวจัดการแพ็กเกจ openclaw update จะแก้ไขเวอร์ชันแพ็กเกจ เป้าหมายก่อนเรียกใช้ตัวจัดการแพ็กเกจ การติดตั้ง npm แบบ global ใช้การติดตั้งแบบ staged: OpenClaw ติดตั้งแพ็กเกจใหม่ลงใน prefix ชั่วคราวของ npm ให้แพ็กเกจตัวเลือกตรวจสอบเวอร์ชัน Node ของโฮสต์ระหว่าง preinstall และตรวจสอบรายการ dist ที่บรรจุในแพ็กเกจที่นั่น ตัวป้องกันความสมบูรณ์ ของแพ็กเกจจะอยู่นอกรายการนั้นจนกว่า preinstall จะสำเร็จ เพื่อให้ตัวจัดการแพ็กเกจ ที่ข้ามสคริปต์วงจรชีวิตหยุดก่อนเปิดใช้งานด้วย บน npm 12 และใหม่กว่า ตัวอัปเดตจะอนุมัติเฉพาะวงจรชีวิตของ OpenClaw ตัวเลือก ส่วนสคริปต์ของ การขึ้นต่อกันแบบส่งผ่านจะยังคงถูกบล็อก จากนั้น OpenClaw จะสลับโครงสร้างแพ็กเกจที่สะอาด เข้าไปใน prefix แบบ global จริง หากการตรวจสอบล้มเหลว doctor หลังอัปเดต การซิงค์ plugin และงานรีสตาร์ตจะไม่ทำงานจากโครงสร้างที่น่าสงสัย แม้เมื่อ เวอร์ชันที่ติดตั้งตรงกับเป้าหมายแล้ว คำสั่งจะรีเฟรช การติดตั้งแพ็กเกจแบบ global จากนั้นเรียกใช้การซิงค์ plugin การรีเฟรชความสมบูรณ์ ของคำสั่งแกนหลัก และงานรีสตาร์ต ซึ่งช่วยให้องค์ประกอบข้างเคียงที่บรรจุในแพ็กเกจและบันทึก plugin ที่ช่องทางเป็นเจ้าของสอดคล้องกับบิลด์ OpenClaw ที่ติดตั้งไว้ ขณะที่ปล่อยให้การบิลด์ ความสมบูรณ์ของคำสั่ง plugin แบบเต็มเป็นหน้าที่ของการเรียกใช้ openclaw completion --write-state อย่างชัดเจน

ที่เกี่ยวข้อง

• openclaw doctor (เสนอให้เรียกใช้การอัปเดตก่อนสำหรับ git checkout)
• ช่องทางการพัฒนา
• การอัปเดต
• เอกสารอ้างอิง CLI