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 เข้มงวด (อนุญาตแค่ ~20 คำสั่งอ่านข้อมูล) เพราะโมเดล 2B ตัดสินใจไม่แม่นพอจะไว้ใจให้รันคำสั่งอิสระ ส่วน TH ใช้โมเดล 35B ที่ทีมพัฒนาประเมินว่าตัดสินใจได้แม่นยำพอที่จะรันคำสั่งอะไรก็ได้ — bash ของ TH จึงเป็นshell เต็มรูปแบบ ไม่จำกัดรายชื่อคำสั่งเลย
การป้องกันจึงเปลี่ยนจุด: แทนที่จะจำกัด “รันคำสั่งอะไรได้บ้าง” (ชั้น Python) ระบบจำกัด**“เขียนไฟล์ที่ไหนได้บ้าง”** ผ่าน macOS sandbox-exec ทั้งหมด — เป็นชั้น OS-level เท่านั้น ไม่มีชั้น allow-list ของโค้ด Python มาก่อน
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 เสมอ ไม่ว่าโมเดลจะฉลาดแค่ไหนก็ตาม
ความคิดเห็น
กำลังโหลดความคิดเห็น...