ด่านอนุมัติ + hook: ให้ AI agent ทำงานเองได้ โดยไม่พังระบบจริงของ Terminal

agent ที่ต้องถามทุกคำสั่งทำงานยาวไม่ได้ agent ที่ไม่ถามอะไรเลยก็อันตราย ทางออกที่ผมใช้ตอนสร้าง Terminal คือด่าน 3 ชั้น: กฎสิทธิ์ · PreToolUse hook ที่บล็อกก่อนรัน · Stop hook ที่เก็บกวาดตอนจบ — พร้อม hook จริง 10 คำสั่งที่ลงทะเบียนใน 5 จังหวะของ session

โดย วรัญชัย ยิ่งคำนึง (Boom) · เผยแพร่ครั้งแรก 21 กรกฎาคม 2569 · ตรวจทานล่าสุด 27 กันยายน 2569

ตอนเริ่มให้ AI agent ช่วยสร้าง Boom Leverage Terminal ผมเจอทางแยกที่ทุกคนเจอ ถ้าตั้งให้มันขออนุญาตทุกคำสั่ง ผมต้องนั่งกด "อนุญาต" วันละหลายร้อยครั้ง และ agent ทำงานยาวข้ามคืนไม่ได้ แต่ถ้าปล่อยให้ทำเองทั้งหมด มันแตะได้ทั้งไฟล์ความลับ ทั้ง git push ขึ้นของจริง

คำตอบที่ใช้ได้จริงคือ ไม่ต้องให้คนเฝ้าทุกคำสั่ง แต่ให้เครื่องเฝ้าเฉพาะคำสั่งที่พังแล้วกู้ไม่ได้ บทความนี้คือด่านที่ผมใช้จริง ต่อยอดจาก ทำไมผมเลือก Claude Code เพราะ harness ซึ่งด่านเหล่านี้คือชั้น "ด่านกัน" ในภาพนั้น

ทำไมเขียนกฎไว้ใน prompt อย่างเดียวถึงไม่พอ?

เพราะกฎใน prompt คือ คำขอ ไม่ใช่ ข้อบังคับ agent อาจอ่านไม่ครบ ลืมกลางทางเมื่อบริบทยาว หรือเข้าใจผิดว่าเคสนี้เป็นข้อยกเว้น ในงานที่ไม่สำคัญ ความผิดพลาดแบบนี้แค่เสียเวลา แต่ในงานที่แตะเงินลูกค้า ข้อมูลส่วนบุคคล หรือความลับของระบบ "ส่วนใหญ่ทำตาม" ไม่พอ

คนทำ model risk แยกเรื่องนี้ชัด: การควบคุมที่ พึ่งความตั้งใจดี กับการควบคุมที่ บังคับด้วยระบบ เป็นคนละระดับ ผู้ตรวจจะถามเสมอว่า "ถ้าคนลืม จะเกิดอะไรขึ้น" — hook คือคำตอบของคำถามนั้นสำหรับ agent

ด่าน 3 ชั้นหน้าตาเป็นยังไง?

ตามเอกสารของ Claude Code เมื่อ PreToolUse hook คืน exit code 2 จะ "Blocks the tool call" และข้อความใน stderr ถูกส่งกลับไปให้ agent อ่าน (Hooks reference, ตรวจ 27 ก.ย. 2026) — นี่คือกลไกที่ทำให้ agent ไม่ใช่แค่ถูกห้าม แต่ รู้ว่าทำไม และเขียนคำสั่งใหม่ให้ถูกได้เอง

hook จริงที่ใช้มีอะไรบ้าง?

ใน settings ของ repo ที่ใช้คุม agent มี hook ลงทะเบียนไว้ 10 คำสั่ง ใน 5 จังหวะ ของ session:

สังเกตว่าด่านหนาที่สุดอยู่ที่ ก่อนรันคำสั่ง shell เพราะนั่นคือจุดเดียวที่ agent แตะโลกจริงได้กว้างที่สุด — ลบไฟล์ ส่งข้อมูลออก push โค้ด

hook ที่ดีควรบล็อกแค่ไหน?

ข้อที่ผมจ่ายแพงที่สุดคือ hook ที่บล็อกกว้างเกินไปจะถูกปิดทิ้ง ถ้ามันขวางงานปกติบ่อย คนจะหาทางเลี่ยงหรือถอดออก ด่านที่รอดในระบบจริงจึงต้องแคบและแม่น ตัวอย่างจากหัวไฟล์ hook ตัวหนึ่งที่ใช้จริง:

deterministic guard for the patterns that fail 100% of the time (false-positive ≈ 0)

หลักคิดคือ บล็อกเฉพาะสิ่งที่ ผิดแน่นอน ส่วนเรื่องที่ต้องใช้วิจารณญาณ ปล่อยให้เป็นกฎใน CLAUDE.md หรือให้คนตัดสิน ด่านที่บล็อกผิดบ่อยแม้เพียงเล็กน้อยจะทำลายความเชื่อใจในด่านทั้งระบบ

อีกหลักคือ fail-open อย่างรู้ตัว: hook หลายตัวเขียนให้ถ้าตัวมันเองพัง (อ่าน input ไม่ออก) ให้ปล่อยผ่านพร้อมบันทึก แทนที่จะบล็อกทุกอย่าง เพราะ hook ที่พังแล้วล็อกทั้งระบบคืออีกความเสียหายหนึ่ง — ยกเว้นด่านที่ความเสียหายกู้ไม่ได้ ซึ่งต้องเลือกฝั่งปลอดภัย

ทำไมต้องมีด่านตอนจบ session ด้วย?

เพราะไม่มีด่านไหนกันได้ 100% Stop hook คือชั้นที่ยอมรับความจริงข้อนี้ ตัวอย่างที่ใช้จริงคือ hook ที่ไล่ลบค่าที่หน้าตาเหมือนความลับออกจาก log ที่เพิ่งเขียน หัวไฟล์ของมันอธิบายหน้าที่ไว้ตรงๆ:

Complements pre-bash-secret-guard.sh (which blocks secrets on the way IN); this cleans what slipped through into files on disk.

คู่นี้คือรูปแบบที่ผมแนะนำ: ด่านขาเข้า กันไว้ก่อน + ด่านขาออก เก็บสิ่งที่หลุด เหมือนระบบควบคุมภายในของแบงก์ที่มีทั้ง preventive control และ detective control

ถ้าจะเริ่มทำเอง ควรเริ่มจากตรงไหน?

1. ไล่รายการการกระทำที่กู้ไม่ได้ — ลบไฟล์ · push ขึ้น production · ส่งข้อมูลออกนอกเครื่อง · อ่านไฟล์ความลับ นี่คือที่ที่ต้องมีด่านเครื่อง
2. เริ่มจาก hook เดียวที่แคบที่สุด เช่น บล็อกคำสั่งที่มีค่าความลับติดมา ทดสอบด้วยการป้อน input ปลอมให้ hook ดูว่าคืน exit code 2 จริง
3. ให้ข้อความตอนบล็อกบอกทางแก้ agent จะแก้คำสั่งเองได้ทันที ไม่ต้องรอคน
4. เพิ่มด่านขาออก เมื่อด่านขาเข้าเสถียรแล้ว
5. เรื่องที่ต้องใช้วิจารณญาณ (เช่น "แผนนี้คุ้มไหม") ไม่ใช่งานของ hook — ใช้การวิจารณ์โดยโมเดลอีกตัว ดู ให้ AI โจมตีแผนตัวเองก่อนลงมือ

สรุป

agent ที่ทำงานเองได้จริงไม่ได้มาจากการไว้ใจโมเดลมากขึ้น แต่มาจากการ ย้ายความไว้ใจไปไว้ที่ด่านที่ตรวจสอบได้ ด่าน 3 ชั้น — กฎสิทธิ์, hook ก่อนรัน, hook ตอนจบ — ทำให้ผมปล่อย agent ทำงานยาวได้ ขณะที่การกระทำที่กู้ไม่ได้ยังมีเครื่องเฝ้าอยู่ทุกครั้ง