Tool: bash — shell เต็มรูปแบบที่ป้องกันด้วย sandbox ระดับ OS แทน allow-list

bash ให้ LOCAL AGENT TH ตรวจสอบไฟล์ โฟลเดอร์ และสถานะของโปรเจกต์ผ่านคำสั่ง shell ที่อนุญาต เหมาะกับงานสำรวจข้อมูลก่อนตัดสินใจแก้ไขไฟล์
Tool นี้คืออะไร
รันคำสั่ง bash บนเครื่องจริง (cwd = workspace) — ใช้สำหรับ system operations, รัน script, เช็ค process/disk/memory และค้นไฟล์ทั้งเครื่อง
จุดต่างสำคัญจาก AGENT LITE: ไม่มี allow-list คำสั่ง
นี่คือความแตกต่างที่ชัดเจนที่สุดเมื่อเทียบกับ bash ของ AGENT LITE — LITE ใช้ allow-list เข้มงวด สำหรับคำสั่งที่เปิดให้โมเดลเรียก ส่วน Agent TH ออกแบบ bash ให้ยืดหยุ่นกว่าตั้งแต่ระดับสถาปัตยกรรมและย้าย safety boundary ไปอยู่ที่ OS sandbox + workspace policy แทน จึงไม่ผูกความสามารถนี้กับการต้องใช้ 35B อีกต่อไป; ตั้งแต่ Qwen3.5-9B บน Mac RAM 16GB ไปจนถึง Qwen3-14B/35B ใช้ tool surface เดียวกัน
การป้องกันจึงเปลี่ยนจุด: แทนที่จะพึ่งความสามารถของ model ว่า “ควรระวังเอง” ระบบจำกัด**“เขียนไฟล์ที่ไหนได้บ้าง”** ผ่าน macOS sandbox-exec และ policy ของ tool โดยตรง ทำให้ safety invariant อยู่ที่ code/OS layer ไม่ว่ากำลังใช้ 14B หรือ 35B
Sandbox profile: deny ก่อน แล้ว allow ทับทีหลัง
Profile ที่สร้างขึ้นใช้กติกา (allow default) เป็นฐาน (ต่างจาก LITE ที่ deny แทบทุกอย่างแล้วค่อย allow เฉพาะจุด) จากนั้น:
(allow default)
(deny file-write* /etc /usr /System /Library ~/Desktop ~/Documents ~/Downloads
~/.ssh ~/.aws ~/.config ~/.gnupg ~/Library ...)
(deny file-read* ~/.ssh ~/.aws ~/.gnupg)
(allow file-write* <workspace> /private/tmp) ← เขียนได้ทับ deny เพราะมาทีหลัง
(allow file-read* <workspace>)
macOS sandbox-exec ใช้กติกา last-match-wins — บรรทัดที่มาทีหลังชนะเสมอเมื่อขัดกัน ระบบใช้หลักการนี้ตั้งใจ: deny การเขียนไปยังโฟลเดอร์อันตราย/ส่วนตัวก่อน แล้วค่อย allow การเขียนใน workspace + /tmp ทีหลังสุด เพื่อoverride deny เฉพาะจุดที่ต้องการ ผลคือ: อ่านได้เกือบทุกที่ (ยกเว้น credential path), แต่เขียนได้เฉพาะ workspace และ /tmp เท่านั้น
กันข้อความ echo กลายเป็น step announcement ปลอม
มีรายละเอียดเล็กแต่จริงที่แก้ปัญหาที่สังเกตได้: โมเดลบางครั้งใช้ bash('echo "กำลังทำขั้นที่ 2...") เป็นการประกาศขั้นตอนให้ผู้ใช้เห็น ไม่ใช่คำสั่งที่ต้องรันจริง ระบบจึงบล็อก echo แบบเปล่าๆ (ไม่มี redirect/pipe/variable/backtick) ไม่ให้เสียเวลารันจริง — แต่คง echo "x" > file.txt, echo $PATH, echo "x" | grep ไว้ตามปกติเพราะเป็นการใช้งานจริง ไม่ใช่แค่ประกาศ
System prompt สอน “ค้นไฟล์ยังไงให้เร็ว”
docstring ของ tool มีคำแนะนำเรื่องการค้นไฟล์ที่เจาะจงมาก: mdfind (Spotlight) ก่อนเสมอ เพราะค้นทั้งดิสก์เร็วที่สุด, find ~ -iname เป็น fallback เมื่อ mdfind พลาดไฟล์ที่ยังไม่ index, grep -rl เมื่อรู้เนื้อหาแต่ไม่รู้ชื่อไฟล์ — และมีpath ของไฟล์ตัวเองฝังไว้ในคำอธิบาย (เช่น logs/memory.md, developer/PROJECT_MEMORY.md) สำหรับตอบคำถามที่ผู้ใช้ถามเกี่ยวกับสถาปัตยกรรมของ agent เอง
ทำไมเรื่องนี้ถึงสำคัญ
การเปรียบเทียบ bash ของ LITE กับ TH แสดงให้เห็นชัดเจนว่าระดับความสามารถของโมเดลกำหนดจุดที่ควรวางการป้องกัน — โมเดลเล็กที่ตัดสินใจไม่แม่น ต้องจำกัดที่ “จะรันคำสั่งอะไรได้บ้าง” ตั้งแต่ต้น โมเดลใหญ่ที่ไว้ใจการตัดสินใจได้มากกว่า สามารถเปิดอิสระในการรันคำสั่ง แต่ยังต้องล็อกผลกระทบที่แก้ไขไม่ได้ (การเขียนไฟล์นอกขอบเขต) ไว้ที่ระดับ OS เสมอ ไม่ว่าโมเดลจะฉลาดแค่ไหนก็ตาม
ความคิดเห็น
กำลังโหลดความคิดเห็น...