NVIDIA OpenShell ແມ່ນຫຍັງ? ຄູ່ມືເລີ່ມຕົ້ນໃຊ້ງານ Sandbox ເພື່ອການເຮັດວຽກຂອງ AI Agent ຢ່າງປອດໄພ

NVIDIA OpenShell ແມ່ນສະພາບແວດລ້ອມການເຮັດວຽກ (Runtime) ແບບໂອເພນຊອດສ໌ ສຳລັບການໃຊ້ງານ AI agent ພາຍໃນ Sandbox ຢ່າງປອດໄພ. ມັນຊ່ວຍປ້ອງກັນບໍ່ໃຫ້ agent ເຂົ້າເຖິງໄຟລ໌ ຫຼື ຂໍ້ມູນການຢືນຢັນຕົວຕົນຂອງ Host ໂດຍກົງ, ຄວບຄຸມການເຂົ້າເຖິງເຄືອຂ່າຍພາຍນອກດ້ວຍນະໂຍບາຍແບບປະກາດ (Declarative policy), ແລະ ສາມາດຕິດຕາມການປະຕິບັດງານທີ່ຖືກອະນຸຍາດ ຫຼື ປະຕິເສດຜ່ານ Log ໄດ້.

ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອແນະນຳນັກພັດທະນາ ແລະ ພະນັກງານໄອທີທີ່ຕ້ອງການທົດລອງໃຊ້ງານ Coding agent ເຊັ່ນ: Claude Code ຢ່າງປອດໄພ, ໂດຍຈະອະທິບາຍຂັ້ນຕອນຕັ້ງແຕ່ການຕິດຕັ້ງ OpenShell, ການສ້າງ Sandbox ທຳອິດ, ຈົນເຖິງການຄວບຄຸມການເຂົ້າເຖິງດ້ວຍນະໂຍບາຍ ຕາມເອກະສານທາງການ (github.com/NVIDIA/OpenShell, ໃບອະນຸຍາດ Apache 2.0). ເມື່ອອ່ານຈົບ, ທ່ານຈະສາມາດສ້າງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂັ້ນຕ່ຳເພື່ອແຍກ agent ອອກຈາກສະພາບແວດລ້ອມ Host ມາໃຊ້ງານໃນສະພາບແວດລ້ອມຂອງທ່ານເອງໄດ້.

OpenShell ແມ່ນ sandbox ທີ່ຂັບເຄື່ອນດ້ວຍນະໂຍບາຍ ເຊິ່ງຖືກອອກແບບມາໂດຍອີງໃສ່ "ຕົວແທນ (Agent) ທີ່ເຮັດວຽກໄປພ້ອມກັບການຂຽນສະພາບແວດລ້ອມການເຮັດວຽກຂອງຕົນເອງຄືນໃໝ່". ກ່ອນອື່ນໝົດ, ຂໍສະຫຼຸບຄວາມແຕກຕ່າງລະຫວ່າງມັນກັບຄອນເທນເນີ (Container) ທົ່ວໄປ ແລະ ສິ່ງທີ່ມັນຊ່ວຍປົກປ້ອງ.

Docker ເຊັ່ນດຽວກັບຄອນເທນເນີທົ່ວໄປ ມີຈຸດປະສົງຫຼັກເພື່ອແຍກແອັບພລິເຄຊັນອອກມາເຮັດວຽກ. ເມື່ອສ້າງ Image ແລ້ວ ກໍຈະເລີ່ມການເຮັດວຽກ ແລະ ປະຕິບັດແອັບພລິເຄຊັນພາຍໃນນັ້ນ ເຊິ່ງສະພາບແວດລ້ອມໂດຍລວມຈະມີລັກສະນະຄົງທີ່.

ໃນທາງກົງກັນຂ້າມ, AI Agent ຈະຂຽນໂຄ້ດ, ຕິດຕັ້ງແພັກເກດ, ແລະ ແກ້ໄຂໄຟລ໌ການຕັ້ງຄ່າ ພ້ອມທັງປ່ຽນແປງສະພາບແວດລ້ອມການເຮັດວຽກຂອງຕົນເອງໄປເລື້ອຍໆ. OpenShell ມີຄວາມແຕກຕ່າງກັນກໍຄື ການກຽມພື້ນທີ່ແຍກຕ່າງຫາກທີ່ສາມາດທົດລອງຜິດທົດລອງຖືກໄດ້ຢ່າງປອດໄພ ໂດຍອີງໃສ່ເງື່ອນໄຂທີ່ວ່າ "Agent ຈະປ່ຽນແປງສະພາບແວດລ້ອມໄປເລື້ອຍໆ".

ໂດຍສະເພາະແລ້ວ, ມັນຈະອະນຸຍາດໃຫ້ເຮັດສະເພາະການປະຕິບັດງານທີ່ Agent ຈຳເປັນຕ້ອງໃຊ້ເທົ່ານັ້ນ ແລະ ຈະສະກັດກັ້ນສ່ວນທີ່ເຫຼືອ (ການອ່ານໄຟລ໌ຂອງ Host, ການເຂົ້າເຖິງຂໍ້ມູນການຢືນຢັນຕົວຕົນ, ການສື່ສານທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ) ໃນລະດັບ OS. ໃນຂະນະທີ່ຄອນເທນເນີເນັ້ນໃສ່ "ການແຍກແອັບພລິເຄຊັນ" ເປັນຫຼັກ, OpenShell ໄດ້ວາງຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໄວ້ທີ່ "ການຫຼຸດສິດທິຂອງ Agent ໃຫ້ເຫຼືອໜ້ອຍທີ່ສຸດ".

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ທີ່ສຸດຂອງ OpenShell ແມ່ນບໍ່ໄດ້ຄວບຄຸມ Agent ດ້ວຍ Prompt (ຄຳສັ່ງການເຮັດວຽກ) ແຕ່ເປັນການບັງຄັບແບບ "Out-of-process" ເຊິ່ງເປັນການກຳນົດຂໍ້ຈຳກັດໄວ້ທີ່ສະພາບແວດລ້ອມທີ່ Agent ເຮັດວຽກໂດຍກົງ. ເນື່ອງຈາກຂໍ້ຈຳກັດດັ່ງກ່າວມີຜົນຢູ່ພາຍນອກ Agent, ເຖິງແມ່ນວ່າ Agent ຈະຖືກບຸກລຸກກໍບໍ່ສາມາດຂຽນທັບດ້ວຍຕົນເອງໄດ້.

ເອກະສານທາງການໄດ້ລະບຸໄພຄຸກຄາມທີ່ຕ້ອງປ້ອງກັນໄວ້ 4 ຢ່າງ ໂດຍມີ Policy domain ທີ່ກ່ຽວຂ້ອງກັບແຕ່ລະຢ່າງດັ່ງນີ້:

• Filesystem (ລະບົບໄຟລ໌): ປ້ອງກັນການອ່ານ SSH key ຫຼື ຂໍ້ມູນການຢືນຢັນຕົວຕົນຂອງ Cloud (ການລັກຂະໂມຍຂໍ້ມູນການຢືນຢັນຕົວຕົນ). ໃຊ້ Landlock ຂອງ Linux kernel ເພື່ອສະກັດກັ້ນການອ່ານ-ຂຽນນອກເສັ້ນທາງທີ່ອະນຸຍາດ ແລະ ຈະຖືກລັອກໄວ້ໃນຂະນະທີ່ສ້າງ Sandbox.
• Network (ເຄືອຂ່າຍ): ປ້ອງກັນການສົ່ງ Source code ຫຼື ໄຟລ໌ພາຍໃນບໍລິສັດອອກສູ່ພາຍນອກ (ການນຳຂໍ້ມູນອອກ). ປະຕິເສດການສື່ສານຂາອອກໄປຍັງປາຍທາງທີ່ບໍ່ໄດ້ອະນຸຍາດ ແລະ ສາມາດເຮັດ Hot-reload ໄດ້ໃນຂະນະທີ່ລະບົບກຳລັງເຮັດວຽກ.
• Process (ຂະບວນການ): ປ້ອງກັນການຍົກລະດັບສິດທິ (Privilege escalation) ຜ່ານ sudo ຫຼື setuid. ໃຊ້ Process ID ທີ່ບໍ່ມີສິດທິພິເສດ ແລະ seccomp ເພື່ອກຳນົດຂໍ້ຈຳກັດຂອງ System call ທີ່ອັນຕະລາຍ, ໂດຍຈະຖືກລັອກໄວ້ໃນຂະນະທີ່ສ້າງຂຶ້ນ.
• Inference (ການອະນຸມານ): ປ້ອງກັນການສົ່ງຂໍ້ມູນໄປຍັງຜູ້ໃຫ້ບໍລິການ Model ທີ່ບໍ່ໄດ້ຮັບການອະນຸມັດ. ເຮັດໜ້າທີ່ເປັນ "Privacy router" ເພື່ອເກັບຮັກສາ Context ທີ່ເປັນຄວາມລັບໄວ້ໃນ Model ແບບເປີດ (Open model) ພາຍໃນເຄື່ອງ ແລະ ຈະສົ່ງຕໍ່ຂໍ້ມູນໃຫ້ກັບ Frontier model ເຊັ່ນ Claude ຫຼື GPT ກໍຕໍ່ເມື່ອ Policy ອະນຸຍາດເທົ່ານັ້ນ.

Policy ຈະຖືກຂຽນດ້ວຍ YAML ແບບ Declarative ໂດຍພື້ນທີ່ແບບ Static (Filesystem, Process) ຈະຖືກກຳນົດໄວ້ຕາຍຕົວໃນຂະນະທີ່ສ້າງ, ສ່ວນພື້ນທີ່ແບບ Dynamic (Network, Inference) ສາມາດອັບເດດໄດ້ໂດຍບໍ່ຈຳເປັນຕ້ອງ Restart.

OpenShell ຖືກອອກແບບມາໃຫ້ເປັນສະພາບແວດລ້ອມການເຮັດວຽກແບບທົ່ວໄປທີ່ບໍ່ຂຶ້ນກັບ Agent ສະເພາະໃດໜຶ່ງ. ໃນຄູ່ມື Quick Start ຢ່າງເປັນທາງການ, ທ່ານສາມາດເລືອກ "Claude Code", "Codex", ຫຼື "OpenCode" ເພື່ອເປັນເປົ້າໝາຍໃນການເປີດຕົວ ຫຼື Launch ໄດ້. CLI ຈະກວດສອບຂໍ້ມູນການຢືນຢັນຕົວຕົນຂອງ Agent ທີ່ຖືກຮັບຮູ້ໂດຍອັດຕະໂນມັດຈາກສະພາບແວດລ້ອມ Shell, ດັ່ງນັ້ນໃນຫຼາຍກໍລະນີ, ທ່ານສາມາດນຳໄປໃຊ້ງານພາຍໃນ Sandbox ໄດ້ເລີຍໂດຍບໍ່ຈຳເປັນຕ້ອງແກ້ໄຂ Code.

ໃບອະນຸຍາດແມ່ນ Open Source ແບບ Apache 2.0 ແລະ Source Code ຖືກເປີດຕົວ ຫຼື Launch ຢູ່ທີ່ github.com/NVIDIA/OpenShell. ໃນເວລາທີ່ຂຽນບົດຄວາມນີ້, ມັນຍັງຢູ່ໃນໄລຍະເລີ່ມຕົ້ນຂອງລະບົບ 0.0.x, ເຊິ່ງລະບົບຄຳສັ່ງ ແລະ Policy Schema ອາດຈະມີການອັບເດດໃນອະນາຄົດ. ເມື່ອນຳໄປໃຊ້ງານຈິງ, ກະລຸນາກວດສອບມາດຕະຖານ ຫຼື Specification ລ່າສຸດຈາກເອກະສານທາງການ (docs.nvidia.com/openshell) ສະເໝີ.

ການທົດລອງໃຊ້ OpenShell ຈຳເປັນຕ້ອງມີ 4 ຢ່າງຄື: OS ທີ່ຮອງຮັບ, ສະພາບແວດລ້ອມການເຮັດວຽກຂອງ Container, CLI ແລະ ຂໍ້ມູນຢືນຢັນຕົວຕົນຂອງ Agent. ຂໍໃຫ້ກວດສອບແຕ່ລະຢ່າງຕາມລຳດັບ.

ການໃຊ້ງານ OpenShell ຈຳເປັນຕ້ອງມີສະພາບແວດລ້ອມດັ່ງຕໍ່ໄປນີ້:

• macOS / Linux / Windows + WSL 2 ຢ່າງໃດຢ່າງໜຶ່ງ
• ຢູ່ໃນສະຖານະທີ່ສາມາດໃຊ້ Docker / Podman / MicroVM ໄດ້
• OpenShell CLI ແລະ OpenShell gateway

ເນື່ອງຈາກການແຍກສ່ວນຂອງລະບົບໄຟລ໌ (File system isolation) ໃຊ້ Landlock ຂອງ Linux kernel, ສະພາບແວດລ້ອມ Linux (ລວມເຖິງ WSL 2 ແລະ ຄອນເທນເນີທີ່ເຮັດວຽກເທິງ Linux kernel) ຈຶ່ງສາມາດໃຊ້ງານຟັງຊັນການປ້ອງກັນໄດ້ຢ່າງເຕັມປະສິດທິພາບ. ສຳລັບ macOS ຈະເຮັດວຽກຜ່ານຊັ້ນ Virtualization. ສຳລັບການນຳໃຊ້ໃນລະດັບອົງກອນ, ຍັງມີການແນະນຳໂຄງສ້າງທີ່ໃຫ້ Agent ເຮັດວຽກເປັນເວລາດົນນານເທິງ DGX Spark ອີກດ້ວຍ.

ກ່ອນອື່ນ, ຄວນກວດສອບໃຫ້ແນ່ໃຈວ່າ Container runtime (ເຊັ່ນ Docker) ໄດ້ເປີດໃຊ້ງານຢູ່ເທິງ OS ຂອງທ່ານແລ້ວຫຼືບໍ່ ເພື່ອຫຼີກລ່ຽງຂໍ້ຜິດພາດໃນຂັ້ນຕອນການຕິດຕັ້ງຕໍ່ໄປ.

ບັນຊີຜູ້ໃຊ້ ຫຼື API Key ຂອງ Agent ທີ່ເຮັດວຽກພາຍໃນ Sandbox (ເຊັ່ນ: Claude Code) ແມ່ນຈຳເປັນຕ້ອງໄດ້ກຽມໄວ້ຕ່າງຫາກ. OpenShell ເປັນພຽງພາຊະນະສຳລັບແຍກ Agent ໃຫ້ປອດໄພເທົ່ານັ້ນ, ບໍ່ໄດ້ສະໜອງສິດໃນການນຳໃຊ້ Agent ໃຫ້.

OpenShell CLI ຈະກວດສອບຂໍ້ມູນການຢືນຢັນຕົວຕົນຂອງ Agent ທີ່ຮູ້ຈັກ (ເຊັ່ນ: Claude, Codex, OpenCode, Copilot ແລະອື່ນໆ) ຈາກຕົວແປສະພາບແວດລ້ອມ (Environment Variables) ຂອງ Shell ໂດຍອັດຕະໂນມັດ. ກ່າວຄື, ທ່ານສາມາດສົ່ງຂໍ້ມູນການຢືນຢັນຕົວຕົນທີ່ໃຊ້ຢູ່ເປັນປະຈຳໃນຝັ່ງ Host ໃຫ້ໄປໄດ້ໂດຍກົງ. ນອກຈາກນີ້, ຍັງສາມາດລົງທະບຽນຂໍ້ມູນການຢືນຢັນຕົວຕົນ (Provider) ຢ່າງຈະແຈ້ງໄດ້ອີກດ້ວຍ.

ສິ່ງທີ່ສຳຄັນຢູ່ທີ່ນີ້ຄື ຂໍ້ມູນການຢືນຢັນຕົວຕົນເຫຼົ່ານີ້ຈະຖືກປົກປ້ອງໂດຍນະໂຍບາຍຂອງ Sandbox. Agent ຈະໄດ້ຮັບພຽງແຕ່ "ຂອບເຂດທີ່ຈຳເປັນຕໍ່ການນຳໃຊ້" ເທົ່ານັ້ນ ແລະ ຈະຖືກແຍກອອກຈາກໄຟລ໌ ຫຼື ການສື່ສານທີ່ຢູ່ນອກເໜືອນະໂຍບາຍ.

ການຕິດຕັ້ງສາມາດເຮັດໄດ້ດ້ວຍສະຄຣິບທາງການພຽງຄັ້ງດຽວ, ເຊິ່ງຈະຕິດຕັ້ງທັງ CLI ແລະ Gateway ພ້ອມກັນ. ຫຼັງຈາກຕິດຕັ້ງແລ້ວ, ໃຫ້ກວດສອບການເຊື່ອມຕໍ່ໂດຍໃຊ້ຄຳສັ່ງ status ແລະ help.

ດຳເນີນການຕິດຕັ້ງຕາມສະຄຣິບທາງການ.

ສະຄຣິບນີ້ຈະຕິດຕັ້ງ "OpenShell CLI" ແລະ "OpenShell gateway" ພ້ອມທັງເປີດໃຊ້ງານ gateway ໃນເຄື່ອງທ້ອງຖິ່ນໂດຍອັດຕະໂນມັດ. CLI ເປັນຊ່ອງທາງໃນການຄວບຄຸມການເຮັດວຽກ, ສ່ວນ gateway ເປັນອົງປະກອບທີ່ເຮັດວຽກຢູ່ເບື້ອງຫຼັງເພື່ອ enforce (ບັງຄັບໃຊ້) ກົດລະບຽບຂອງ sandbox ແລະ network policy. ໃນເອກະສານທາງການ, ຍັງໄດ້ແນະນຳວິທີການຕິດຕັ້ງຜ່ານ uv tool install -U openshell ອີກດ້ວຍ.

ຢ່າງໃດກໍຕາມ, ການຕິດຕັ້ງໃນຮູບແບບ curl | sh ມີຄວາມສ່ຽງທົ່ວໄປທີ່ບໍ່ສາມາດກວດສອບເນື້ອໃນຂອງສະຄຣິບກ່ອນການປະມວນຜົນໄດ້. ຖ້າທ່ານມີຄວາມກັງວົນ, ຄວນເປີດ URL ດັ່ງກ່າວຜ່ານຕົວແກ້ໄຂຂໍ້ຄວາມ (Editor) ເພື່ອອ່ານເນື້ອໃນກ່ອນດຳເນີນການ, ຫຼືເລືອກວິທີການຕິດຕັ້ງຜ່ານ uv ແທນ.

ຫຼັງຈາກຕິດຕັ້ງແລ້ວ, ໃຫ້ກວດສອບສະຖານະຂອງ Gateway.

ຖ້າປົກກະຕິ, ຊື່ Gateway, Server URL (ຕົວຢ່າງ: ທີ່ຢູ່ Local ເຊັ່ນ https://127.0.0.1:17670), ສະຖານະການເຊື່ອມຕໍ່ (Connected) ແລະ ເວີຊັນຈະຖືກສະແດງຂຶ້ນມາ. ຖ້າ Connected ສະແດງຂຶ້ນມາ, ສະແດງວ່າສາມາດເຂົ້າເຖິງ Gateway ຈາກ CLI ໄດ້ແລ້ວ.

ກວດສອບລາຍການ Subcommand ທີ່ສາມາດໃຊ້ງານໄດ້ໂດຍໃຊ້ help.

ຖ້າ status ບໍ່ສະແດງເປັນ Connected, ໃຫ້ສົງໄສວ່າ Process ຂອງ Gateway ໄດ້ເລີ່ມເຮັດວຽກແລ້ວຫຼືບໍ່ ຫຼື Port ຂອງ Local ໄດ້ໄປຊ້ຳກັບ Process ອື່ນຫຼືບໍ່. ການກວດສອບການເຊື່ອມຕໍ່ໃນຂັ້ນຕອນນີ້ ຈະຊ່ວຍໃຫ້ແຍກແຍະໄດ້ງ່າຍຂຶ້ນວ່າ "ເປັນບັນຫາທີ່ CLI ຫຼື ເປັນບັນຫາທີ່ Policy" ເມື່ອເກີດຄວາມຜິດພາດໃນການສ້າງ Sandbox ໃນພາຍຫຼັງ.

ການປະຕິບັດງານພື້ນຖານຂອງ OpenShell ແມ່ນການສ້າງ Sandbox ດ້ວຍຄຳສັ່ງ openshell sandbox create ແລ້ວເປີດໃຊ້ງານ Agent ພາຍໃນນັ້ນ. ຕົວຈິງແລ້ວ, ພວກເຮົາຈະລອງນຳໃຊ້ Claude Code ໃນສະພາບແວດລ້ອມທີ່ຖືກແຍກອອກມາ.

ສ້າງ Sandbox ໂດຍການຕັ້ງຊື່ ແລະ ເລີ່ມຕົ້ນການເຮັດວຽກຂອງ Claude Code ພາຍໃນນັ້ນ.

--name demo ແມ່ນການຕັ້ງຊື່ໃຫ້ Sandbox ວ່າ "demo" ແລະ claude ທີ່ສົ່ງຕໍ່ຫຼັງຈາກ -- ຈະຖືກປະຕິບັດພາຍໃນ Sandbox. ເມື່ອເລີ່ມຕົ້ນ, Claude Code ຈະເລີ່ມເຮັດວຽກພາຍໃນ Sandbox.

-- ແມ່ນຕົວແບ່ງທີ່ໝາຍເຖິງ "ຄຳສັ່ງທີ່ຢູ່ຫຼັງຈາກນີ້ຈະຖືກປະຕິບັດພາຍໃນ Sandbox". ນອກຈາກ Claude Code ແລ້ວ, ຍັງສາມາດເລີ່ມຕົ້ນການເຮັດວຽກຂອງ Agent ທີ່ CLI ຮອງຮັບ ເຊັ່ນ: Codex ຫຼື OpenCode ດ້ວຍຮູບແບບດຽວກັນນີ້ໄດ້. ຂໍ້ມູນການຢືນຢັນຕົວຕົນຂອງ Agent ຈະຖືກກວດພົບໂດຍອັດຕະໂນມັດຈາກສະພາບແວດລ້ອມ Host, ສະນັ້ນໃນຫຼາຍກໍລະນີ ທ່ານສາມາດເລີ່ມນຳໃຊ້ໄດ້ທັນທີໂດຍບໍ່ຈຳເປັນຕ້ອງຕັ້ງຄ່າເພີ່ມເຕີມ.

ຢືນຢັນໃຫ້ແນ່ໃຈວ່າ Agent ທີ່ເປີດໃຊ້ງານຢູ່ກຳລັງເຮັດວຽກຢູ່ໃນ Sandbox ບໍ່ແມ່ນຢູ່ເທິງ Host. ຕົວຢ່າງເຊັ່ນ: ລອງຖາມ Claude Code ກ່ຽວກັບໄດເລກະທໍລີປັດຈຸບັນ.

ໃນການຕັ້ງຄ່າແບບມາດຕະຖານຂອງ OpenShell, ໄດເລກະທໍລີທີ່ເຮັດວຽກຢູ່ຈະເປັນ /sandbox. ຖ້າ Agent ຕອບກັບມາເປັນ /sandbox, ມັນສະແດງວ່າ Agent ກຳລັງເຮັດວຽກຢູ່ໃນພື້ນທີ່ທີ່ຖືກແຍກອອກມາເຊິ່ງຈັດການໂດຍ OpenShell, ບໍ່ແມ່ນລະບົບໄຟລ໌ຂອງ Host ໂດຍກົງ.

ການກວດສອບ "ກຳລັງເຮັດວຽກຢູ່ບ່ອນໃດ" ນີ້ອາດຈະເບິ່ງຄືວ່າເປັນເລື່ອງເລັກນ້ອຍແຕ່ມີຄວາມສຳຄັນຫຼາຍ. ກ່ອນທີ່ຈະມອບໝາຍການຈັດການໄຟລ໌ ຫຼື ການສັ່ງງານ Command ໃຫ້ກັບ Agent, ໃຫ້ກວດສອບດ້ວຍຕາຂອງຕົນເອງໃຫ້ແນ່ໃຈວ່າສະພາບແວດລ້ອມນັ້ນຖືກແຍກອອກຈາກ Host ແລ້ວ. ຖ້າຂ້າມຂັ້ນຕອນນີ້ໄປ, ອາດຈະນຳໄປສູ່ອຸບັດຕິເຫດທີ່ຄິດວ່າຖືກແຍກອອກມາແລ້ວ ແຕ່ໃນຄວາມເປັນຈິງກັບກຳລັງເຂົ້າເຖິງ Host ຢູ່.

ເມື່ອ Sandbox ເລີ່ມເຮັດວຽກແລ້ວ, ໃຫ້ລອງມອບໝາຍວຽກງ່າຍໆໃຫ້ແກ່ Agent. ຕົວຢ່າງເຊັ່ນ: ສັ່ງການດັ່ງນີ້:

Agent ຈະສ້າງໄຟລ໌ຂຶ້ນມາພາຍໃນ Sandbox. ເພື່ອກວດສອບໂຄ້ດທີ່ຖືກສ້າງຂຶ້ນ, ໃຫ້ອອກຈາກ Claude Code ດ້ວຍຄຳສັ່ງ /exit ແລ້ວເບິ່ງເນື້ອໃນຜ່ານ Shell ຂອງ Sandbox.

ເມື່ອເຮັດວຽກສຳເລັດແລ້ວ, ໃຫ້ອອກຈາກ Shell ຂອງ Sandbox ດ້ວຍຄຳສັ່ງ exit ເພື່ອກັບຄືນສູ່ Shell ຂອງເຄື່ອງ Host. ໄຟລ໌ທີ່ Agent ສ້າງຂຶ້ນຈະຖືກແຍກໄວ້ພາຍໃຕ້ /sandbox ແລະ ຈະບໍ່ສົ່ງຜົນກະທົບຕໍ່ໂຄງສ້າງໄຟລ໌ຂອງ Host. ສະພາວະທີ່ "ຜົນຜະລິດຖືກກັກໄວ້ພາຍໃນ Sandbox" ນີ້ເອງ ຄືພື້ນຖານທີ່ຊ່ວຍໃຫ້ສາມາດທົດລອງຜິດທົດລອງຖືກໄດ້ຢ່າງປອດໄພ.

Sandbox ທີ່ສ້າງຂຶ້ນສາມາດຈັດການໄດ້ໂດຍການສະແດງລາຍການ, ເຊື່ອມຕໍ່ ຫຼື ຊິງຄ໌ຂໍ້ມູນຄືນໃໝ່, ແລະ ລຶບອອກ. ເມື່ອການທົດລອງສິ້ນສຸດລົງ, ໃຫ້ລຶບ Sandbox ທີ່ບໍ່ຈຳເປັນອອກເພື່ອຈັດລະບຽບສະພາບແວດລ້ອມ.

ສາມາດກວດສອບລາຍການ Sandbox ໄດ້ດ້ວຍຄຳສັ່ງຕໍ່ໄປນີ້:

ຊື່ (NAME), ວັນທີ ແລະ ເວລາທີ່ສ້າງ (CREATED), ແລະ ສະຖານະ (PHASE) ຈະຖືກສະແດງຂຶ້ນມາ, ຖ້າຫາກເປີດໃຊ້ງານແລ້ວ PHASE ຈະເປັນ Ready (ນອກຈາກນີ້ຍັງມີສະຖານະອື່ນໆ ເຊັ່ນ: Provisioning, Error, Deleting). ຖ້າໃສ່ -o json ຫຼື -o yaml ຕໍ່ທ້າຍ ກໍສາມາດສົ່ງອອກຜົນລັດໃນຮູບແບບທີ່ເຄື່ອງຈັກອ່ານໄດ້.

ເພື່ອເຂົ້າໄປໃນ Sandbox ທີ່ມີຢູ່ແລ້ວອີກຄັ້ງ ໃຫ້ໃຊ້ຄຳສັ່ງ connect, ຈາກນັ້ນໃຫ້ຣີສະຕາດ Agent ພາຍໃນນັ້ນ.

ສຳລັບ Sandbox ທີ່ບໍ່ຕ້ອງການແລ້ວ ໃຫ້ລຶບອອກດ້ວຍຄຳສັ່ງ delete. ໃນເວລາລຶບ, ນອກຈາກການຢຸດຂະບວນການ (Process) ແລະ ການປ່ອຍຊັບພະຍາກອນແລ້ວ, ຂໍ້ມູນການຢືນຢັນຕົວຕົນທີ່ຖືກໃສ່ໄວ້ກໍຈະຖືກທຳລາຍໄປນຳ.

ຂໍໃຫ້ສັງເກດວ່າ connect ເປັນພຽງການເຊື່ອມຕໍ່ກັບ Shell ຂອງ Sandbox ເທົ່ານັ້ນ, ສ່ວນການເປີດໃຊ້ງານ Agent ຈະເປັນການດຳເນີນການແຍກຕ່າງຫາກ. ເມື່ອຕ້ອງການກວດສອບສະຖານະການເຮັດວຽກລວມໆ ສາມາດໃຊ້ Dashboard ຂອງ openshell term ໄດ້. ບໍ່ຄວນປະ Sandbox ໄວ້ຫຼັງຈາກສ້າງແລ້ວ, ການໃຊ້ sandbox delete ເພື່ອຈັດການຫຼັງຈາກກວດສອບສຳເລັດແລ້ວ ຈະຊ່ວຍປ້ອງກັນບໍ່ໃຫ້ສະຖານະເກົ່າ ຫຼື ນະໂຍບາຍຕ່າງໆຕົກຄ້າງຢູ່ ເຊິ່ງອາດເຮັດໃຫ້ການແຍກແຍະພຶດຕິກຳຂອງລະບົບມີຄວາມຫຍຸ້ງຍາກ.

OpenShell ຂອງແທ້ແມ່ນຢູ່ທີ່ການສາມາດຄວບຄຸມການເຂົ້າເຖິງເຄືອຂ່າຍດ້ວຍນະໂຍບາຍແບບປະກາດ (Declarative Policy). ໃນບົດນີ້, ພວກເຮົາຈະມາທົດສອບການບລັອກ URL ທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດໂດຍຄ່າເລີ່ມຕົ້ນ, ພ້ອມທັງດຳເນີນການແກ້ໄຂນະໂຍບາຍເພື່ອອະນຸຍາດໃຫ້ເຂົ້າເຖິງໄດ້.

Sandbox ເລີ່ມຕົ້ນຈາກ "ການເຂົ້າເຖິງພາຍນອກຂັ້ນຕໍ່າສຸດ". ບໍ່ສາມາດເຂົ້າເຖິງ URL ທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດຕາມນະໂຍບາຍເລີ່ມຕົ້ນໄດ້.

ກ່ອນອື່ນ, ໃຫ້ເຊື່ອມຕໍ່ ຫຼື ຊິງຄ໌ຂໍ້ມູນກັບ Sandbox.

ລອງເຂົ້າເຖິງ URL ທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດດ້ວຍ curl.

ການສື່ສານໄປຍັງ Host ທີ່ບໍ່ໄດ້ລວມຢູ່ໃນນະໂຍບາຍເລີ່ມຕົ້ນຈະຖືກບລັອກໂດຍ Proxy ຂອງ Gateway. ເປັນການປິດກັ້ນຄວາມສ່ຽງທີ່ Agent ຈະສົ່ງຂໍ້ມູນອອກໄປພາຍນອກໂດຍພະລະການ (ການນຳຂໍ້ມູນອອກ = exfiltration) ດ້ວຍການຕັ້ງຄ່າ. ແນວຄິດເລື່ອງສິດທິຂັ້ນຕໍ່າສຸດທີ່ວ່າ "ປະຕິເສດໂດຍຄ່າເລີ່ມຕົ້ນ, ອະນຸຍາດສະເພາະສິ່ງທີ່ຈຳເປັນຢ່າງຊັດເຈນເທົ່ານັ້ນ" ແມ່ນຖືກນຳມາໃຊ້ຢ່າງເຂັ້ມງວດໃນຊັ້ນ Network ເຊັ່ນກັນ.

ສົ່ງອອກນະໂຍບາຍປັດຈຸບັນໄປຍັງໄຟລ໌.

ຢູ່ສ່ວນຫົວຂອງໄຟລ໌ທີ່ສົ່ງອອກມາຈະມີຂໍ້ມູນເມຕາ (Meta information) ເຊັ່ນ Version Hash Status Active Created ແລະ ຖັດລົງມາຈະມີເຄື່ອງໝາຍ --- ຂັ້ນໄວ້ ເຊິ່ງເປັນສ່ວນຂອງ YAML ຫຼັກ. ຈາກສ່ວນຂອງ YAML ຫຼັກນັ້ນ ສາມາດອ່ານຂໍ້ມູນໄດ້ດັ່ງນີ້:

• ສາມາດເຂົ້າເຖິງໂຮສ ຫຼື URL ໃດໄດ້ແດ່ (network_policies)
• ອະນຸຍາດໃຫ້ເຂົ້າເຖິງເຄືອຂ່າຍຜ່ານຄຳສັ່ງ (binary) ໃດແດ່ (binaries)
• ສາມາດອ່ານ/ຂຽນໂຟນເດີໃດໄດ້ແດ່ (filesystem_policy)
• ຈະໃຫ້ໂປຣເຊສເຮັດວຽກດ້ວຍຜູ້ໃຊ້/ກຸ່ມໃດ (process)

ໂຄງສ້າງຂອງ YAML ຫຼັກໂດຍປະມານມີລັກສະນະດັ່ງນີ້ (ສະກັດມາບາງສ່ວນ):

ເພີ່ມໂຮສທີ່ຕ້ອງການອະນຸຍາດໃຫ້ເຂົ້າເຖິງລົງໃນ network_policies. ເນື່ອງຈາກ openshell policy set ຈະເປັນການປ່ຽນແທນນະໂຍບາຍທັງໝົດ, ກົດເຫຼັກກໍຄືຕ້ອງ "ເພີ່ມ" ນະໂຍບາຍໃໝ່ໂດຍບໍ່ໃຫ້ network_policies ທີ່ມີຢູ່ແລ້ວຫາຍໄປ. ຕົວຢ່າງ, ຖ້າຕ້ອງການເພີ່ມການເຂົ້າເຖິງແບບອ່ານຢ່າງດຽວ (read-only) ໃຫ້ກັບໂຮສໃດໜຶ່ງ, ໃຫ້ເພີ່ມບລັອກຕໍ່ໄປນີ້ໄວ້ລຸ່ມນະໂຍບາຍເດີມ:

enforcement ຂອງແຕ່ລະເອນດ໌ພອຍ (endpoint) ສາມາດເລືອກໄດ້ລະຫວ່າງ enforce ເຊິ່ງຈະບລັອກການລະເມີດຕົວຈິງ, ແລະ audit ເຊິ່ງຈະບັນທຶກຂໍ້ມູນໄວ້ໂດຍບໍ່ມີການບລັອກ. ການສັງເກດການເຮັດວຽກດ້ວຍ audit ກ່ອນ ແລ້ວຈຶ່ງປ່ຽນເປັນ enforce ຈະມີຄວາມປອດໄພກວ່າ. ເນື່ອງຈາກ OpenShell ປະເມີນການເຂົ້າເຖິງໃນລະດັບຄວາມລະອຽດຂອງ Binary, ປາຍທາງ, HTTP Method, ແລະ Path, ຈຶ່ງສາມາດຄວບຄຸມໄດ້ຢ່າງລະອຽດເຊັ່ນ: "ອະນຸຍາດໃຫ້ພຽງແຕ່ GET ຈາກ curl ໄປຍັງໂຮສນີ້ເທົ່ານັ້ນ".

ກ່ອນນຳໄປໃຊ້, ຕ້ອງລຶບຂໍ້ມູນເມຕາ (Version / Hash / Status, ແລະອື່ນໆ) ທີ່ຢູ່ເໜືອ --- ໃນຕອນຕົ້ນຂອງໄຟລ໌ອອກສະເໝີ. ສິ່ງທີ່ຕ້ອງສົ່ງໃຫ້ policy set ມີພຽງແຕ່ເນື້ອໃນ YAML ທີ່ຢູ່ລຸ່ມ --- ເທົ່ານັ້ນ.

--wait ແມ່ນທາງເລືອກໃນການລໍຖ້າຈົນກວ່າການນຳໃຊ້ຈະສຳເລັດ. ນະໂຍບາຍເຄືອຂ່າຍຈະຖືກໂຫຼດໃໝ່ແບບ Hot-reload ເຂົ້າໄປໃນ Sandbox ທີ່ກຳລັງເຮັດວຽກຢູ່, ສະນັ້ນມັນຈະມີຜົນໂດຍບໍ່ຈຳເປັນຕ້ອງສ້າງ Sandbox ໃໝ່. ຫຼັງຈາກນຳໃຊ້ແລ້ວ, ໃຫ້ເຊື່ອມຕໍ່ໃໝ່ ແລະ ລອງໃຊ້ curl ໄປຍັງ URL ເດີມ, ຕອນນີ້ທ່ານກໍຈະສາມາດເຂົ້າເຖິງໄດ້.

ນີ້ແມ່ນຈຸດທີ່ມັກເກີດບັນຫາເມື່ອເລີ່ມໃຊ້ OpenShell ພ້ອມກັບວິທີແກ້ໄຂ:

• ການໃຊ້ policy set ເພື່ອຂຽນທັບ Policy ເດີມທັງໝົດ: policy set ຈະເປັນການປ່ຽນແທນ Policy ທັງໝົດ. ຖ້າລຶບ network_policies ເດີມອອກ ຈະເຮັດໃຫ້ການສື່ສານທີ່ຈຳເປັນສຳລັບ Agent (ເຊັ່ນ: Model API) ຢຸດເຮັດວຽກ. ຕ້ອງໃຊ້ policy get ເພື່ອດຶງຂໍ້ມູນມາແລ້ວແກ້ໄຂໂດຍການເພີ່ມຂໍ້ມູນໃໝ່ເຂົ້າໄປເທົ່ານັ້ນ.
• ການສົ່ງ Meta information ໄປພ້ອມກັບ policy set: ຖ້າຫາກຍັງເຫຼືອ Meta information (Version / Hash ແລະ ອື່ນໆ) ທີ່ຢູ່ເໜືອ --- ຈະເຮັດໃຫ້ການນຳໃຊ້ (Apply) ລົ້ມເຫຼວ. ຕ້ອງສົ່ງສະເພາະສ່ວນເນື້ອຫາຫຼັກເທົ່ານັ້ນ.
• ການພະຍາຍາມປ່ຽນ Static policy ໃນຂະນະທີ່ກຳລັງເຮັດວຽກ: Filesystem ແລະ Process ຈະຖືກລັອກໄວ້ຕອນສ້າງ ແລະ ບໍ່ສາມາດປ່ຽນແປງໄດ້ໃນຂະນະທີ່ກຳລັງເຮັດວຽກ. ຖ້າຕ້ອງການປ່ຽນແປງສ່ວນນີ້ ຕ້ອງສ້າງ Sandbox ຂຶ້ນມາໃໝ່. ສ່ວນທີ່ສາມາດ Hot-reload ໄດ້ມີພຽງ Network ແລະ Inference ເທົ່ານັ້ນ.
• ການຄາດຫວັງການປ້ອງກັນຂອງ Landlock ໃນ macOS: Landlock ເປັນຟັງຊັນຂອງ Linux Kernel ເຊິ່ງຈະມີພຶດຕິກຳທີ່ແຕກຕ່າງກັນໄປຕາມສະພາບແວດລ້ອມ ດັ່ງທີ່ເຫັນໄດ້ຈາກການຕັ້ງຄ່າ compatibility: best_effort. ຄວນກວດສອບໃຫ້ແນ່ໃຈວ່າລະດັບການປ້ອງກັນນັ້ນມີຂອບເຂດພຽງໃດ.
• ການປະໃຫ້ Sandbox ຄ້າງໄວ້: ຖ້າມີ Sandbox ຫຼື Policy ເກົ່າຕົກຄ້າງຢູ່ ຈະເຮັດໃຫ້ການແຍກແຍະພຶດຕິກຳຂອງລະບົບເຮັດໄດ້ຍາກ. ຫຼັງຈາກກວດສອບສຳເລັດແລ້ວ ຄວນລຶບຖິ້ມດ້ວຍ sandbox delete.

ນີ້ແມ່ນຄຳຖາມທີ່ພົບເລື້ອຍກ່ຽວກັບ OpenShell.

Q. OpenShell ແຕກຕ່າງຈາກ Docker ທົ່ວໄປແນວໃດ? Docker ມີຈຸດປະສົງຫຼັກໃນການແຍກແອັບພລິເຄຊັນອອກຈາກກັນ, ໃນຂະນະທີ່ OpenShell ຖືກອອກແບບມາໂດຍສະເພາະເພື່ອໃຫ້ "AI Agent ທີ່ສາມາດຂຽນທັບສະພາບແວດລ້ອມຂອງຕົນເອງໃນຂະນະເຮັດວຽກ" ສາມາດດຳເນີນການໄດ້ຢ່າງປອດໄພ. ຄວາມແຕກຕ່າງທີ່ສຳຄັນຄືການຄວບຄຸມ 4 ຂົງເຂດໄດ້ແກ່: ໄຟລ໌, ເຄືອຂ່າຍ, ຂະບວນການ ແລະ ການອະນຸມານ (Inference) ດ້ວຍນະໂຍບາຍ, ເຊິ່ງສາມາດອັບເດດເຄືອຂ່າຍ ແລະ ການອະນຸມານໄດ້ເຖິງແມ່ນວ່າຈະຢູ່ໃນລະຫວ່າງການເຮັດວຽກຢູ່ກໍຕາມ.

Q. ຈຳເປັນຕ້ອງຂຽນໂຄ້ດຂອງ Agent ທີ່ມີຢູ່ແລ້ວຄືນໃໝ່ບໍ? ໃນຫຼາຍກໍລະນີແມ່ນບໍ່ຈຳເປັນ. CLI ສາມາດກວດຫາຂໍ້ມູນການຢືນຢັນຕົວຕົນຂອງ Agent ທີ່ຮູ້ຈັກແລ້ວ (ເຊັ່ນ: Claude, Codex, OpenCode, ແລະອື່ນໆ) ໄດ້ໂດຍອັດຕະໂນມັດ ແລະ ສາມາດນຳໄປດຳເນີນການພາຍໃນ Sandbox ໄດ້ໂດຍບໍ່ຕ້ອງປ່ຽນແປງໂຄ້ດ.

Q. ສາມາດນຳໄປໃຊ້ໃນການດຳເນີນງານຈິງ (Production) ໄດ້ບໍ? ເຖິງແມ່ນວ່າຈະເປັນ Open Source ພາຍໃຕ້ໃບອະນຸຍາດ Apache 2.0, ແຕ່ໃນເວລາທີ່ຂຽນບົດຄວາມນີ້ ມັນຍັງຢູ່ໃນຂັ້ນຕອນເລີ່ມຕົ້ນຂອງລະບົບ 0.0.x ເຊິ່ງອາດມີການປ່ຽນແປງມາດຕະຖານ ຫຼື Specification ໄດ້. ຖ້າຫາກກຳລັງພິຈາລະນານຳໄປໃຊ້ໃນການດຳເນີນງານຈິງ, ຄວນກວດສອບແພລັດຟອມທີ່ຮອງຮັບ ແລະ ຂໍ້ຈຳກັດຕ່າງໆທີ່ຮູ້ຈັກຜ່ານເອກະສານທາງການ ແລະ ບັນທຶກການປ່ອຍເວີຊັນ (Release Notes) ລ່າສຸດ, ພ້ອມທັງເລີ່ມຕົ້ນຈາກການທົດສອບຂະໜາດນ້ອຍເພື່ອຄວາມປອດໄພ.

NVIDIA OpenShell ແມ່ນສະພາບແວດລ້ອມການເຮັດວຽກແບບ Open Source ທີ່ຊ່ວຍໃຫ້ສາມາດຮັນ AI agent ພາຍໃນ Sandbox ໄດ້ຢ່າງປອດໄພ, ປົກປ້ອງໄຟລ໌ ແລະ ຂໍ້ມູນການຢືນຢັນຕົວຕົນຂອງ Host, ພ້ອມທັງຄວບຄຸມການເຂົ້າເຖິງເຄືອຂ່າຍດ້ວຍນະໂຍບາຍແບບ Declarative. ໃນບົດຄວາມນີ້, ພວກເຮົາໄດ້ຕິດຕາມຂັ້ນຕອນຕັ້ງແຕ່ການຕິດຕັ້ງ, ການກວດສອບການເຊື່ອມຕໍ່, ການສ້າງ Sandbox ທຳອິດ, ການມອບໝາຍວຽກໃຫ້ Agent, ຈົນເຖິງການຄວບຄຸມເຄືອຂ່າຍຜ່ານນະໂຍບາຍ.

ມີ 3 ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ດັ່ງນີ້: ຢ່າງທຳອິດ, OpenShell ຖືກອອກແບບມາໂດຍຕັ້ງສົມມຸດຕິຖານວ່າເປັນ "Agent ທີ່ປ່ຽນແປງສະພາບແວດລ້ອມ" ໂດຍປົກປ້ອງ 4 ຂົງເຂດຄື: ໄຟລ໌, ເຄືອຂ່າຍ, ຂະບວນການ (Process), ແລະ ການອະນຸມານ (Inference) ດ້ວຍສິດທິຂັ້ນຕໍ່າສຸດ. ຢ່າງທີສອງ, Sandbox ສາມາດຈັດການໄດ້ດ້ວຍການດຳເນີນການທີ່ງ່າຍດາຍຄື ການສ້າງ, ການເຊື່ອມຕໍ່ ຫຼື ຊິງຄ໌ຂໍ້ມູນ, ແລະ ການລຶບ, ໂດຍຜົນງານທີ່ໄດ້ຈະຖືກແຍກໄວ້ໃນ /sandbox. ຢ່າງທີສາມ, ນະໂຍບາຍເຄືອຂ່າຍຈະດຳເນີນການແບບ "ປະຕິເສດໂດຍຄ່າເລີ່ມຕົ້ນ, ເພີ່ມສະເພາະສິ່ງທີ່ຈຳເປັນເທົ່ານັ້ນ" ແລະ ສາມາດເຮັດ Hot-reload ໄດ້ໃນຂະນະທີ່ລະບົບກຳລັງເຮັດວຽກຢູ່.

ຍິ່ງມອບໝາຍວຽກໃຫ້ Agent ເຮັດວຽກແບບອັດຕະໂນມັດຫຼາຍເທົ່າໃດ, ຄວາມສຳຄັນຂອງການແຍກສ່ວນ (Isolation) ແລະ ການຄວບຄຸມສິດທິການເຂົ້າເຖິງກໍຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ເມື່ອບໍລິສັດຂອງພວກເຮົາເລີ່ມນຳໃຊ້ AI agent, ພວກເຮົາກໍຍຶດຖືຫຼັກການເລີ່ມຕົ້ນຈາກການກວດສອບພຶດຕິກຳໃນ Sandbox ຂະໜາດນ້ອຍ ແລະ ຄ່ອຍໆຂະຫຍາຍນະໂຍບາຍອອກໄປເທື່ອລະນ້ອຍ. ຢາກໃຫ້ທ່ານເລີ່ມຕົ້ນໂດຍການສ້າງພື້ນທີ່ສຳລັບການທົດລອງທີ່ປອດໄພ ໂດຍມີສະພາບແວດລ້ອມການເຮັດວຽກຢ່າງ OpenShell ເປັນໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ພື້ນຖານ.