ให้ AI coding agent ทำงานบน VM ที่ลบทิ้งได้

เหตุผลที่ VM แบบใช้แล้วทิ้งปลอดภัยกว่าแล็ปท็อปของคุณ

หากคุณให้สิทธิ์ตัวแทนเขียนโค้ด (coding agent) เข้าถึง VM แบบใช้แล้วทิ้ง สิ่งที่เลวร้ายที่สุดที่อาจเกิดขึ้นคือการทำลายเครื่องที่คุณสามารถสร้างใหม่ได้ภายในสิบนาที ตัวแทนดังกล่าวยังคงได้รับสิทธิ์ root, ติดตั้งแพ็กเกจ และรันชุดทดสอบได้โดยไม่ต้องขออนุญาตในทุกขั้นตอน ความแตกต่างอยู่ที่ขอบเขตของความเสียหาย หากเป็นบนแล็ปท็อป ตัวแทนจะใช้ home directory ร่วมกับ SSH keys, โปรไฟล์เบราว์เซอร์, ไฟล์ .env และ repository อื่นๆ ทั้งหมดที่คุณเคย clone ไว้ แต่บนเซิร์ฟเวอร์แบบใช้แล้วทิ้ง ตัวแทนจะมีเพียง shell, โค้ดที่ checkout มา และไม่มีสิ่งอื่นใดที่มีค่าให้ต้องกังวล

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

ระบุ blast radius ก่อนที่จะถกเถียงกัน

Blast radius หมายถึงชุดของสิ่งที่ process เข้าถึงได้ สำหรับ agent ที่ทำงานในฐานะ user ปกติของคุณบนเครื่องปกติ ชุดดังกล่าวใหญ่กว่าที่คนส่วนใหญ่นึกไว้

ซึ่งรวมถึง ~/.ssh/id_ed25519 ที่โดยปกติไม่ได้เข้ารหัส เพราะคุณเบื่อที่จะพิมพ์ passphrase ซึ่งรวมถึง ~/.aws/credentials และ ~/.config/gh/hosts.yml ที่ออกแบบมาให้เป็น plain text ซึ่งรวมถึง repository อื่นทุกแห่งภายใต้ ~/code รวมถึง repository ที่มี production connection string อยู่ใน local env file ซึ่งรวมถึง shell history ของคุณที่มี token ที่คุณเคยวางไว้ครั้งหนึ่ง นอกจากนี้ยังรวมถึง network ที่ laptop ของคุณเชื่อมต่ออยู่ ซึ่งมักเป็น home หรือ office network ที่มีบริการซึ่งไม่ต้องยืนยันตัวตนอยู่ใน network นั้น

ไม่มีข้อใดจำเป็นต้องเกิดจาก agent ที่มีเจตนาร้าย สิ่งที่ต้องมีคือคำสั่งหนึ่งคำสั่งที่ผิดอย่างมั่นใจ เช่น rm -rf "$BUILD_DIR"/* โดยที่ BUILD_DIR ไม่ได้กำหนดค่า ซึ่งขยายเป็น /* และหลุดผ่านการปฏิเสธตามค่าเริ่มต้นของ GNU rm ที่ไม่ยอมลบ / เอง หรือ git clean -xfd ที่อยู่ใน directory ผิด หรือ docker system prune -af --volumes ที่ลบ local database ของคุณไปด้วย หรือ chmod -R 777 ที่ทำงานกับ home directory ด้วยความหวังดี Agents ได้รับการฝึกจาก Internet เดียวกับที่สอนคำสั่งเหล่านั้นแก่คนอื่นทั้งหมด

กลไกที่ช่วยปกป้องคุณไม่ใช่การตัดสินใจของ agent แต่คือเครื่องที่เก็บความเสียหายนั้นเป็นเครื่องที่คุณยอมเสียไปได้

การคำนวณต้นทุนเป็นเรื่องน่าเบื่อ ซึ่งนั่นคือประเด็นสำคัญ

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

ลองคำนวณด้วยตัวเลขของคุณเอง ใช้อัตราค่าจ้างรายชั่วโมงของคุณ คูณด้วยจำนวนชั่วโมงที่จะต้องใช้ในการติดตั้งระบบปฏิบัติการใหม่ การกู้คืน home directory การเปลี่ยน SSH key การเปลี่ยน personal access token และการ clone repository ใหม่จำนวน 20 รายการ เปรียบเทียบตัวเลขนี้กับค่าใช้จ่ายรายปีของเซิร์ฟเวอร์ขนาดเล็กที่สุดที่ผู้ให้บริการของคุณมี จุดคุ้มทุนจะอยู่ที่เหตุการณ์เพียงครั้งเดียวในรอบหลายปี และเหตุการณ์นั้นไม่จำเป็นต้องเป็นหายนะร้ายแรงก็เกินจุดคุ้มทุนนี้แล้ว การเสียเวลาเพียงช่วงบ่ายเดียวให้กับสภาพแวดล้อมการทำงานในเครื่องที่เสียหาย ก็เพียงพอที่จะครอบคลุมค่าใช้จ่ายของทั้งปีแล้ว

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

ภาพรวม ณ เดือน October 2026

คำตอบที่ตรงไปตรงมาสำหรับคำถามว่า “ควรให้ agent ทำงานที่ใด” มี 3 แนวทาง และทุกแนวทางต้องแลกกันระหว่าง 2 ปัจจัยเดียวกัน คือความแข็งแกร่งของขอบเขตการแยก และระดับการตั้งค่าที่คุณยอมรับได้

local micro VM เครื่องมือในกลุ่มนี้จะ boot virtual machine จริงบนฮาร์ดแวร์ของคุณ mount repository เข้าไป แล้วให้ agent มีสิทธิ์ root ภายในเครื่องนั้น clawk เป็นตัวอย่างปัจจุบัน และแนวคิดหลักของเครื่องมือนี้ตรงกับข้อเสนอของบทความนี้ คือให้ coding agent ใช้ Linux VM ที่ทำลายทิ้งได้ แทนการใช้ laptop ของคุณ ณ เดือน October 2026 เครื่องมือนี้รองรับ macOS 14 ขึ้นไปบน Apple silicon และรองรับ Linux ผ่าน Firecracker ในระดับทดลอง โดยติดตั้งด้วย brew install clawkwork/tap/clawk คุณใช้ clawk ภายใน repository เพื่อ boot sandbox และเชื่อมต่อ agent ใช้ clawk down เพื่อหยุด และใช้ clawk destroy เพื่อลบ ขอบเขตการแยกใช้ hypervisor ซึ่งมีความแข็งแกร่ง ข้อจำกัดคือ VM ทำงานอยู่บนเครื่องที่คุณพกติดตัว จึงใช้ memory ร่วมกับงานอื่น และจะหยุดเมื่อคุณปิดฝาเครื่อง

container Docker เป็นคำตอบที่คนส่วนใหญ่ติดตั้งไว้แล้ว และมีประโยชน์จริง

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm จะลบ container เมื่อออกจากการทำงาน และ --network none จะไม่ให้ container เข้าถึง network เลย ซึ่งเป็นค่าเริ่มต้นที่เหมาะสมสำหรับการ build หรือการทดสอบ ต้องเข้าใจว่าสิ่งนี้ไม่ได้ป้องกันทุกกรณี: container ใช้ kernel ร่วมกับ host ดังนั้น kernel bug อาจเป็นช่องทางหลบออกจากขอบเขตได้ และขอบเขตจะแทบไม่มีความหมายทันทีที่คุณเพิ่ม --privileged หรือ mount /var/run/docker.sock เพื่อให้ agent “ใช้ Docker” การ mount Docker socket เข้าไปใน container เทียบเท่ากับการให้ container มีสิทธิ์ root บน host

plain VPS ที่คุณ rebuild ได้ ไม่ต้องใช้เครื่องมือใหม่ มีขอบเขตระดับ kernel จริง มี snapshot จาก provider และยังทำงานต่อเมื่อคุณปิด laptop นี่คือรูปแบบที่คู่มือนี้จะอธิบายต่อ และเป็นรูปแบบที่รองรับ agent ที่ทำงานเป็นเวลานานได้ เพราะ job ที่ใช้เวลา 4 ชั่วโมงไม่สนใจว่าคุณกลับบ้านแล้ว

รูปแบบ VPS: กำหนดผู้ใช้แยกให้ agent

เริ่มจากเครื่องที่ผ่านการเสริมความปลอดภัยแล้ว 10 นาทีแรกบน VPS ใหม่ ครอบคลุมส่วนที่ไม่เกี่ยวกับ agent โดยเฉพาะ ได้แก่ การอัปเดต, การเข้าสู่ระบบด้วยบัญชีที่ไม่ใช่ root, SSH ที่ใช้เฉพาะ key และ firewall

จากนั้นสร้างบัญชีที่มีไว้สำหรับ agent เท่านั้น เพื่อให้ความผิดพลาดภายในบัญชีนี้ไม่กระทบส่วนอื่นของเซิร์ฟเวอร์

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password หมายความว่าไม่มี password ให้เดา และคุณจะเข้าสู่บัญชีนี้ด้วย sudo -u agent หรือ SSH key โปรดสังเกตว่า agent ไม่ได้อยู่ในกลุ่ม sudo โดยเจตนา agent ที่มี sudo จะมีสิทธิ์ root และ root สามารถอ่านไฟล์ของผู้ใช้รายอื่นทุกคนได้ ดังนั้นการแยกสิทธิ์ที่เพิ่งสร้างขึ้นจึงไม่มีประโยชน์ หาก agent จำเป็นต้องติดตั้ง package จริง นั่นเป็นเหตุผลให้ใช้เซิร์ฟเวอร์ทั้งเครื่องที่จัดสรรให้ agent ไม่ใช่มอบ sudo ให้ agent บนเซิร์ฟเวอร์ที่ใช้ร่วมกัน กฎทั่วไปอยู่ใน หลัก least privilege สำหรับผู้ใช้ Linux บน VPS

ตรวจสอบขอบเขตก่อนที่จะไว้วางใจ agent ในฐานะผู้ใช้ agent ให้ลองแสดงรายการไดเรกทอรี home ของบัญชีตนเอง:

sudo -u agent ls /home/you

คุณควรเห็น ls: cannot open directory '/home/you': Permission denied หากเห็นรายการไฟล์แทน แสดงว่าผู้ใช้รายอื่นสามารถอ่านไดเรกทอรี home ของคุณได้ และ agent สามารถอ่านไฟล์ใดก็ตามในนั้นที่ไม่ได้จำกัดสิทธิ์แยกต่างหาก เช่น ไฟล์ .env ที่ทุกคนอ่านได้ แก้ไขด้วย sudo chmod 700 /home/you private SSH key ของคุณไม่ใช่สิ่งที่การทดสอบนี้ป้องกัน: ssh จะไม่ใช้ไฟล์ private key ที่ผู้ใช้รายอื่นเข้าถึงได้ ดังนั้น key ใดก็ตามที่ใช้งานได้สำหรับคุณจะอ่านไม่ได้โดย agent อยู่แล้ว ไม่ว่าไดเรกทอรี home ของคุณจะมี mode ใดก็ตาม

เก็บข้อมูลรับรองไว้ภายนอกเครื่องทั้งหมด

จุดประสงค์ของการใช้เครื่องแบบใช้แล้วทิ้งจะหมดไปหากคุณคัดลอกความลับของระบบงานจริง (production secrets) ลงไป กฎนั้นเรียบง่ายคือ ห้ามมีข้อมูลรับรองใดๆ บนเครื่องนั้นที่คุณจะต้องกังวลหากต้องเปลี่ยนใหม่ในบ่ายวันนี้

สำหรับ git ให้ใช้วิธี forward SSH agent แทนการคัดลอก key ไปไว้ที่เครื่อง private key จะยังคงอยู่บนแล็ปท็อปของคุณ และมีเพียงคำขอลงลายมือชื่อเท่านั้นที่ส่งผ่านการเชื่อมต่อ

ssh -A agent@203.0.113.10
ssh -T git@github.com

คำสั่งที่สองควรแสดงผลเป็น Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. ซึ่งเป็นการพิสูจน์ว่า git push จะทำงานได้โดยไม่ต้องมีไฟล์ key อยู่บนเซิร์ฟเวอร์ ให้รัน ls -la ~/.ssh บนเครื่องหลังจากนั้นเพื่อยืนยันว่าไม่มี private key หลงเหลืออยู่

การทำ agent forwarding มีข้อควรระวังที่สำคัญประการหนึ่งคือ ในขณะที่คุณเชื่อมต่ออยู่ ใครก็ตามที่มีสิทธิ์ root บนเซิร์ฟเวอร์นั้นสามารถใช้ socket ที่ถูก forward มาเพื่อยืนยันตัวตนในนามของคุณได้ หากเป็นเซิร์ฟเวอร์ที่มีเพียงคุณเป็นผู้ใช้งานคนเดียวถือเป็นความเสี่ยงที่ยอมรับได้ แต่หากเป็นเครื่องที่ใช้งานร่วมกันถือว่าไม่ปลอดภัย และการใช้ deploy key ที่จำกัดสิทธิ์เฉพาะ repository หนึ่งๆ จะเป็นทางเลือกที่ดีกว่า โดยรายละเอียดของทางเลือกต่างๆ ได้อธิบายไว้ใน พื้นฐานการจัดการ SSH key

สำหรับ API key ให้สร้าง key แยกต่างหากสำหรับ agent โดยเฉพาะพร้อมกำหนดวงเงินการใช้งาน และเก็บไว้ในไฟล์ที่ผู้ใช้ agent เป็นเจ้าของด้วยโหมด 600 เมื่อเครื่องถูกทำลาย ให้เพิกถอน key นั้นทิ้งแทนที่จะต้องมาคอยกังวลว่าข้อมูลจะรั่วไหลหรือไม่ การติดตามค่าใช้จ่ายของโมเดลแยกตาม key ยังเป็นวิธีที่ช่วยให้ตัวเลขใน การควบคุมค่าใช้จ่าย AI agent บน VPS สามารถคาดการณ์ได้แม่นยำ

จำกัดปลายทางที่ agent เข้าถึงได้บนเครือข่าย

การแยกระบบไฟล์เป็นเพียงครึ่งหนึ่งของขอบเขตการควบคุม อีกครึ่งหนึ่งคือ egress หรือปลายทางที่ process ได้รับอนุญาตให้สื่อสารด้วย Linux สามารถกรอง traffic ขาออกตาม user ที่สร้าง traffic นั้นได้ ซึ่งตรงกับรูปแบบนี้พอดี

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

ระบบจะอ่าน rules ตามลำดับ ดังนั้น REJECT ที่อยู่ท้ายสุดจะครอบคลุมทุกกรณีที่บรรทัดก่อนหน้าไม่ได้อนุญาต ทดสอบโดยใช้สิทธิ์ของ agent:

sudo -u agent curl -sS -m 5 http://example.com

คำสั่งนี้ควรล้มเหลวทันทีด้วย error curl: (7) Failed to connect to example.com ตามด้วยข้อความที่แตกต่างกันไปตาม version ของ curl เนื่องจาก rule ที่ reject ตอบกลับทันที แทนที่จะปล่อยให้ connection ค้าง การส่งคำขอ HTTPS ไปยัง host เดียวกันควรยังทำงานได้

มีข้อจำกัดที่ต้องระบุอย่างตรงไปตรงมา 2 ข้อ ประการแรก rules เหล่านี้จะหายไปเมื่อ reboot ครั้งถัดไป เว้นแต่จะบันทึกไว้ด้วย sudo apt install -y iptables-persistent แล้วจึงใช้ sudo netfilter-persistent save ประการที่สอง rules เหล่านี้กรอง port และ address ไม่ใช่ชื่อ การอนุญาต port 443 เท่ากับอนุญาต HTTPS ไปยังทุก host บนอินเทอร์เน็ต ซึ่งเพียงพอสำหรับเข้าถึง model API และเพียงพอสำหรับเข้าถึง pastebin ด้วย หากต้องการ domain allow-list อย่างแท้จริง traffic ต้องผ่าน proxy ที่อ่าน hostname ที่ร้องขอ ซึ่งเป็นกลไกเพิ่มเติมมากกว่าที่การตั้งค่าของนักพัฒนารายเดียวส่วนใหญ่ต้องการ ระบุเฉพาะสิ่งที่คุณควบคุมได้จริง: การควบคุม egress ระดับ port บนเครื่องที่คุณเตรียมใจไว้แล้วว่าอาจสูญเสียได้

การรีเซ็ตสู่สถานะสะอาดระหว่างงาน

การมีสถานะที่สะอาดในแต่ละงานเป็นประโยชน์ที่มักถูกมองข้าม เอเจนต์ที่ใช้เวลา 3 ชั่วโมงกับตั๋วใบก่อนหน้าอาจทิ้งแพ็กเกจที่ติดตั้งไว้, การทำ migration ที่ค้างคา, node_modules ที่ล้าสมัย และ git working tree ที่มีการเปลี่ยนแปลงซึ่งไม่มีใครตรวจสอบ งานถัดไปจะรับช่วงต่อสิ่งเหล่านี้ทั้งหมด และคุณจะต้องเสียเวลาตรวจสอบเพื่อแยกแยะว่าความยุ่งเหยิงใดเป็นของรอบการทำงานไหน เอเจนต์ที่ทำงานในขอบเขตแคบจะทิ้งสิ่งตกค้างไว้น้อยกว่าตั้งแต่แรก ดังนั้นการจับคู่เครื่องที่ใช้แล้วทิ้งเข้ากับ ทักษะที่ผลักดันให้เอเจนต์สร้างการเปลี่ยนแปลงที่เล็กที่สุดเท่าที่ใช้งานได้ จะช่วยให้ทั้งส่วนต่าง (diff) และสถานะที่เหลืออยู่มีขนาดเล็กพอที่จะตรวจสอบได้

วิธีที่ประหยัดที่สุดคือการ checkout ใหม่ทุกครั้งสำหรับแต่ละงาน

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

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

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

หากคุณต้องการสภาพแวดล้อมที่แยกจากกันหลายชุดโดยไม่ต้องจ่ายเงินสำหรับเซิร์ฟเวอร์หลายเครื่อง VPS ขนาดใหญ่หนึ่งเครื่องสามารถโฮสต์ guest VM ได้โดยตรง Nested virtualisation บน VPS อธิบายถึงวิธีการทำงาน รวมถึงวิธีตรวจสอบว่าผู้ให้บริการของคุณอนุญาตหรือไม่ การแยกส่วน (isolation) มีผลทั้งสองด้าน และหากคุณต้องการให้เอเจนต์สองตัวบนเครื่องเดียวกันประสานงานกันแทนที่จะถูกแยกออกจากกัน เซสชัน Claude Code หนึ่งสามารถส่งข้อความตรงไปยังอีกเซสชันหนึ่งได้ แทนที่จะต้องส่งต่องานผ่านตัวคุณทุกครั้ง

เมื่อแล็ปท็อปที่มีมาตรการรัดกุมเพียงพอ

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

หากคุณตรวจสอบทุก command ก่อนที่จะทำงาน แล็ปท็อปก็เพียงพอ prompt ขอสิทธิ์เป็นกลไกควบคุมที่ใช้งานได้จริง และ การรัน Claude Code อย่างปลอดภัยบนเซิร์ฟเวอร์จะแสดงว่าแต่ละระดับบล็อกอะไรได้จริง หากงานของคุณอยู่ใน repository เดียว และไม่มี production credentials อยู่ที่ใดบนเครื่อง blast radius ก็มีขนาดเล็กอยู่แล้ว หาก session ของ agent ใช้เวลาสั้นและมีผู้ควบคุมดูแล exposure window ก็สั้นเช่นกัน

คำตอบจะเปลี่ยนทันทีเมื่อคุณข้าม prompt ซึ่งควรพิจารณาตั้งแต่ตอนนี้ เพราะ auto mode เป็นค่าเริ่มต้นของ Claude Code และการติดตั้งใหม่จะไม่ถามคุณก่อนแก้ไขไฟล์หรือรัน command อีกต่อไป การรันแบบไม่มีผู้ดูแล งานที่ทำข้ามคืน และ workflow ใดก็ตามที่คุณอนุมัติแผนแล้วเดินออกไป ล้วนเอาการตรวจสอบโดยมนุษย์ซึ่งเคยช่วยจำกัดขอบเขตออกไป นั่นคือจุดที่เครื่องต้องทำหน้าที่ดังกล่าวแทน เช่นเดียวกันกับทุกสิ่งที่ขยายขอบเขตการเข้าถึงของ agent รวมถึง การรัน coding agent บน VPSพร้อมกันหลาย repository

การตัดสินใจไม่ได้ขึ้นอยู่กับว่าคุณเชื่อถือ model มากเพียงใด แต่ขึ้นอยู่กับสิ่งที่อยู่ถัดจาก model เมื่อ model ทำงานผิดพลาด

FAQ

Container ให้การแยกสภาพแวดล้อมเพียงพอสำหรับ coding agent หรือไม่

สำหรับงานส่วนใหญ่ เพียงพอ โดยมีเงื่อนไข 2 ข้อ Container ต้องไม่ทำงานด้วย --privileged และต้องไม่ mount /var/run/docker.sock เข้าไปภายใน เพราะแต่ละกรณีเปิดทางให้ process เข้าถึง root บน host ได้ Container ใช้ kernel ร่วมกับ host ดังนั้นขอบเขตการแยกจึงอ่อนกว่า virtual machine หาก agent กำลังรันโค้ดที่ไม่น่าเชื่อถือซึ่งดึงมาจาก Internet ให้เลือก VM จริงหรือเซิร์ฟเวอร์แยกต่างหาก

Agent จำเป็นต้องมี sudo บนเซิร์ฟเวอร์หรือไม่

ไม่จำเป็น และการให้ sudo จะยกเลิกการแยกสภาพแวดล้อมที่คุณสร้างไว้ เพราะ root สามารถอ่านข้อมูลของ account อื่นทุก account บนเครื่องได้ สร้าง user สำหรับ agent โดยไม่ให้ sudo และให้สิทธิ์เขียนเฉพาะ work directory ของ user นั้น หากงานจำเป็นต้องติดตั้ง package จริง ๆ ให้ agent ใช้ทั้งเครื่องที่ agent เป็นผู้ดูแล แทนการให้ root บนเครื่องที่ใช้ร่วมกับผู้อื่น

จะให้ agent push ไปยัง git โดยไม่วาง SSH key ของฉันไว้บนเครื่องได้อย่างไร

Forward SSH agent ด้วย ssh -A เมื่อเชื่อมต่อ คำขอลายเซ็นจะส่งผ่าน connection ขณะที่ private key ยังคงอยู่บน laptop ของคุณ ดังนั้น ssh -T git@github.com จึง authenticate ได้ และ git push ทำงานได้โดยไม่มี private key บนเซิร์ฟเวอร์ ข้อควรระวังคือ root บนเซิร์ฟเวอร์นั้นสามารถใช้ socket ที่ forward ไว้ได้ขณะที่คุณเชื่อมต่ออยู่ ดังนั้นให้ใช้ deploy key ที่จำกัดขอบเขตไว้เฉพาะ repository บนเครื่องใดก็ตามที่คุณใช้ร่วมกับผู้อื่น

Agent ต้องใช้ VPS ขนาดเท่าใด

งานของ agent ส่วนใหญ่คือการแก้ไขไฟล์, รัน build และรัน test ดังนั้นให้กำหนดขนาดเครื่องตาม build ไม่ใช่ตาม model Hosted model ทำงานบน hardware ของ provider ซึ่งเพิ่ม network traffic และแทบไม่เพิ่มภาระบนเครื่อง local Agent เองยังมีข้อกำหนดขั้นต่ำอยู่: ณ วันที่ October 20, 2026 ข้อกำหนดระบบของ Claude Code ระบุว่า RAM ขั้นต่ำคือ 4 GB เริ่มต้นที่ 4 GB แม้เป็นงาน scripting และเพิ่มเป็น 8 GB หาก repository สร้าง container หรือ compile งานที่มีขนาดมาก

ควรทำลายและสร้างเครื่องขึ้นใหม่บ่อยเพียงใด

ให้สร้างเครื่องขึ้นใหม่เมื่อไม่สามารถอธิบาย state ได้อีกต่อไป และอย่างน้อยทุกครั้งที่ credential บนเครื่องอาจถูกเปิดเผย การทำ fresh checkout ระหว่างงานช่วยจัดการ drift ที่เกิดขึ้นในแต่ละวัน และ snapshot ที่สร้างไว้ก่อนการรัน agent ครั้งแรกจะให้ system image ที่สะอาดสำหรับย้อนกลับไปใช้ หากการสร้างเครื่องใหม่มีค่าใช้จ่ายสูง นั่นเป็นสัญญาณว่ามีบางสิ่งสำคัญกำลังอยู่บนเครื่องที่คุณเรียกว่า disposable