ขอบเขตแทนคำสั่ง: วิธีรักษาการควบคุม AI agent แบบอัตโนมัติ

ยิ่ง AI agent เป็นอัตโนมัติมากเท่าไร เราก็ยิ่งพยายามควบคุมมันด้วยวิธีเดิม — เขียนกฎใน prompt ว่า «อย่าแตะสิ่งนี้» «ทำงานแค่ที่นั่น» «ห้ามทำสิ่งนั้นเด็ดขาด» ระหว่าง การทดลองกับ agent สามตัวที่ทำงานขนานกัน ภายในสองวันผมรวบรวมกรณีสด ๆ ที่วิธีนี้ล้มเหลว — และที่วิธีอื่นได้ผล ข้อเสนอของบทความนี้เรียบง่าย: คำสั่งคือคำขอที่ agent ทำตามด้วยความน่าจะเป็นระดับหนึ่ง ส่วนขอบเขตคือคุณสมบัติของระบบที่ไม่ขึ้นกับการเชื่อฟัง ตอนที่ agent มีตัวเดียวและทำงานภายใต้การดูแล ความต่างดูเหมือนเป็นเรื่องสไตล์ เมื่อ agent มีหลายตัว ความต่างกลับเป็นเรื่องสถาปัตยกรรม

ห้าเหตุการณ์ในเซสชันเดียว

ทุกกรณีด้านล่างเกิดขึ้นในเซสชันทำงานเดียวบนบล็อกนี้ — มีการบันทึกไว้ และแต่ละกรณีแสดงให้เห็นวิธีที่การควบคุมผ่านข้อความทำให้ผิดพลาดในแบบของมันเอง

ไม่มีคำสั่ง — จึงเกิดอุบัติเหตุ agent ขณะเตรียมงานของตัวเองได้รัน git stash ในไดเรกทอรีหลัก และเก็บไฟล์ที่ผมยังไม่ commit ซึ่งไม่เกี่ยวกับงานของมันเข้า stash ไม่มีใคร «ฝ่าฝืน» อะไร เพราะไม่เคยมีข้อห้าม นี่คือคุณสมบัติพื้นฐานของคำสั่ง — มันถูกเขียนขึ้นหลังอุบัติเหตุ การเขียนรายการทั้งหมดที่ agent ไม่ควรทำเป็นไปไม่ได้

มีคำสั่ง — แต่ไม่ทำงาน หลังอุบัติเหตุครั้งแรก ผมเพิ่มกฎชัดเจนให้ agent ว่า «ทำงานในไดเรกทอรีทำงานของตัวเองเท่านั้น» agent ตัวหนึ่งก็ยังรันคำสั่ง git ในไดเรกทอรีหลัก — แค่เรียกผ่านพาธสัมบูรณ์ ไม่ใช่ด้วยความมุ่งร้ายและไม่ใช่ความโง่: โมเดลเป็นความน่าจะเป็น และการทำตามกฎข้อความก็เป็นความน่าจะเป็นเช่นกัน คูณด้วยความยาว context และจำนวนรอบการรัน

ขอบเขตทางเทคนิคทำงานอย่างเงียบ ๆ ในการทดลองเดียวกัน อุบัติเหตุที่คาดว่าจะเกิดที่สุดกลับไม่เคยเกิดขึ้น — «agent ตัวหนึ่งสลับ branch ให้ทุกตัว» ไม่ใช่เพราะ agent ระมัดระวัง แต่เพราะ git worktree ไม่สามารถเขียน branch เดียวลงในสำเนาทำงานสองชุดได้ในทางกายภาพ การป้องกันถูกฝังอยู่ในเครื่องมือ ไม่ต้องจำ ไม่ต้องทำตาม — มันมีอยู่เฉย ๆ

คำสั่งถูกวางไว้ในที่ที่ขอบเขตควรอยู่ การค้นพบที่น่ากังวลที่สุด: production ของบล็อกนี้ถูกป้องกันด้วยบรรทัดหนึ่งใน prompt การ push ไป master จะกระตุ้น auto-deploy และสิ่งที่กั้น agent แต่ละตัวไว้คือข้อความ «ห้าม git push» เท่านั้น มันยังอยู่ได้ — แต่นั่นคือโชค ไม่ใช่การควบคุม ขอบเขตจริงตรงนี้คือสิทธิ์การเข้าถึง protected branch โทเคนที่ไม่สิทธิ์เขียน คำขอถูกวางไว้ในที่ของกุญแจ

ขอบเขตเหนือตัว agent เอง สองครั้งในเซสชัน runtime ได้หยุดไม่ใช่ agent ทดลอง แต่เป็นผู้ช่วยหลักของผม: ตัวจำแนกสิทธิ์บล็อก SSH ไปยังเซิร์ฟเวอร์ production และการลบไฟล์ที่ยังไม่ commit จำนวนมาก — การกระทำที่ตามมาจากงานอย่างเป็นทางการ แต่ต้องมี «ใช่» จากมนุษย์อย่างชัดเจน การบล็อกทั้งสองครั้งถูกต้อง และทั้งสองครั้งเกิดขึ้นเหนือ «วินัย» ของ agent ที่เชื่ออย่างจริงใจว่ากำลังทำตามแผน

หลักการไม่ใหม่ — มีเพียงสิ่งใหม่เท่านั้น

วิศวกรรมเคยเรียนบทเรียนนี้มานานก่อน LLM ในระบบการผลิตของ Toyota หลักการนี้เรียกว่า poka-yoke: อุปกรณ์ของกระบวนการป้องกันข้อผิดพลาด ไม่ใช่ความระมัดระวังของผู้ปฏิบัติ ชิ้นส่วนที่ใส่ได้เพียงด้านเดียวถูกต้องนั้นเชื่อถือได้กว่าป้าย «ใส่ให้ถูกด้าน» ในวิศวกรรมแพลตฟอร์มเรียกสิ่งเดียวกันว่า guardrails ในความปลอดภัยเรียกว่า defense in depth ทุกที่มีความคิดเดียวกัน: อย่าพึ่งพาว่าผู้ปฏิบัติอ่าน เข้าใจ และไม่ลืม — ทำให้การกระทำที่ผิดเป็นไปไม่ได้หรือมีต้นทุนสูง

“คำสั่งคือคำขอ ขอบเขตคือคุณสมบัติของระบบ การควบคุมที่พึ่งคำขอไม่ใช่การควบคุม แต่เป็นโชคที่มีผลสะสม”

– ข้อสรุปหลักจากการทำงานสองวันกับ agent ที่ทำงานขนานกัน

กับ AI agent หลักการเก่านี้คมขึ้นด้วยสามเหตุผล agent มีหลายตัว — ความน่าจะเป็นที่คำสั่งจะล้มเหลวคูณกับทุกการรันของทุก agent agent เร็ว — ระหว่าง «เริ่มผิดพลาด» กับ «พังหมด» ผ่านไปเพียงไม่กี่วินาที คน intervene ไม่ทัน และ agent ทำตามตัวอักษรแต่ไม่น่าเชื่อถือ: มันทำตามข้อความใน prompt ขยันกว่าจูเนียร์คนไหน แต่ก็ยังเป็นความน่าจะเป็น — และการทำตามกฎแบบความน่าจะเป็นในระดับ масштаб รับประกันการฝ่าฝืน

ขอบเขตในทางปฏิบัติมีหน้าตาอย่างไร

ชั้นต่าง ๆ ที่ผมสร้างหลังเซสชันนี้ — ตั้งแต่ระบบไฟล์จนถึงการตรวจสอบ:

• ระบบไฟล์: agent แต่ละตัวมีสำเนาทำงานของตัวเอง (git worktree ซึ่ง Anthropic แนะนำ สำหรับเซสชันขนาน ใน Claude Code มีมาในตัว) และในระดับ OS — sandbox: sandboxing ใน Claude Code แยกไฟล์ระบบและเครือข่ายด้วย primitive มาตรฐานของ OS — ตามข้อมูลของ Anthropic สิ่งนี้ลดคำขอสิทธิ์ภายในของพวกเขาลง 84% และ prompt-injection ที่สำเร็จยังคงถูกกักไว้ข้างใน
• สิทธิ์การเขียน: prod และ master ได้รับการปกป้องด้วยสิทธิ์ ไม่ใช่ด้วยพรอมต์ — protected branch, โทเค็นที่ไม่มีสิทธิ์ push, บัญชีแยกสำหรับเอเจนต์ คำขอให้ใส่ไว้ในพรอมต์ทำได้ แต่เป็นชั้นที่สอง
• Runtime: worktree ไม่ได้แยกฐานข้อมูล พอร์ต และคอนเทนเนอร์ — สิ่งเหล่านี้ใช้ร่วมกันในทุกสำเนา เอเจนต์ที่รันเทสต์และเซิร์ฟเวอร์ต้องการทรัพยากรแบบใช้ครั้งเดียว: ฐานข้อมูลชั่วคราว พอร์ตของตัวเอง คอนเทนเนอร์ต่อเอเจนต์
• สิทธิ์ในการดำเนินการ: การดำเนินการที่ย้อนกลับไม่ได้ต้องผ่านการยืนยันหรือตัวจำแนก — เช่น auto mode ใน Claude Code, ซึ่งประเมินแต่ละการดำเนินการแทนที่จะถามทุกอย่างหรือไม่ถามเลย นี่คือขอบเขตที่ขยับได้เฉพาะเมื่อมนุษย์ตัดสินใจอย่างชัดเจน
• การตรวจสอบด้วยสิ่งประดิษฐ์: ไม่เชื่อในรายงานตนเองของเอเจนต์ แต่เชื่อในร่องรอยบนดิสก์ เอเจนต์ที่ค้างของฉันดูเหมือนทำงานอยู่ในอินเทอร์เฟซ การวินิจฉัยมาจากการไม่มีไฟล์ใหม่ในสำเนาของมันเป็นเวลายี่สิบนาที การคอมมิตเข้าสาขาของตัวเองก็เป็นแนวคิดเดียวกัน: ผลลัพธ์ที่อยู่รอดทั้งความล้มเหลวและความมองโลกในแง่ดีของเอเจนต์

คำแนะนำในโครงสร้างนี้ไม่ได้หายไปไหน — มันกลายเป็นชั้นสุดท้าย ไม่ใช่ชั้นแรก «ทำงานในไดเรกทอรีของคุณ» ในพรอมต์ยังมีประโยชน์: มันลดความถี่ของความพยายาม แต่ระหว่างความพยายามกับอุบัติเหตุต้องมีขอบเขต ไม่ใช่ความหวัง

ข้อจำกัดความรับผิดชอบอย่างซื่อสัตย์

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

บทสรุป

คำถามของซีรีส์คือ จะฝังเอเจนต์ AI เข้าในงานจริงได้อย่างไรโดยไม่สูญเสียการควบคุม คำตอบของบทความนี้: การควบคุมไม่ใช่สิ่งที่เขียนบอกเอเจนต์ แต่คือสิ่งที่ถูกจัดวางไว้รอบๆ ตัวมัน ก่อนจะเพิ่ม «ห้ามทำ X เด็ดขาด» อีกบรรทัดในพรอมต์ ควรถามตัวเองว่า: ทำให้ X เป็นไปไม่ได้ในทางเทคนิคได้ไหม? ถ้าได้ — นั่นคือที่ที่เหมาะสมสำหรับความพยายาม ให้พรอมต์ขอเถอะ; ระบบต่างหากที่ต้องห้าม

แหล่งที่มาและแนวทาง

• Making Claude Code more secure and autonomous with sandboxing (Anthropic Engineering) — การแยกไฟล์ระบบและเครือข่ายในระดับ OS; แหล่งที่มาของตัวเลข 84%
• How we contain Claude across products (Anthropic Engineering, 2026) — โครงสร้างขอบเขตการดำเนินการในผลิตภัณฑ์เอเจนต์ทั้งหมด
• How we built Claude Code auto mode (Anthropic Engineering) — ตัวจำแนกสิทธิ์เป็นขอบเขตระหว่าง «ถามทุกอย่าง» และ «ไม่ถามเลย»
• Poka-Yoke (Lean Enterprise Institute) — หลักการป้องกันข้อผิดพลาดด้วยการออกแบบกระบวนการแบบคลาสสิก
• git-worktree และ git-stash — เอกสารทางการของ Git: กลไกของสำเนาทำงานและ stash ร่วม
• Claude Code: Best practices for agentic coding (Anthropic Engineering) — คำแนะนำ worktree สำหรับเซสชันแบบขนาน
• วิธีเปรียบเทียบ LLM บนโค้ดของคุณอย่างซื่อสัตย์: การทดลองกับโมเดล Claude สามตัว — บทความก่อนหน้าของซีรีส์: การทดลองที่รวบรวมเหตุการณ์ที่อธิบายไว้