Prompt Injection กับ Guardrails ของ Agent: ทำไม Claude Opus 5.5 จึงแทนที่ Review Gate ของคุณไม่ได้

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

Claude Opus 5.5 เก่งขึ้นอย่างวัดผลได้ในการไม่ทำตามคำสั่งเหล่านั้น Anthropic รายงานว่าความพยายามหลบเลี่ยงขอบเขตที่สำเร็จลดลง 85% นี่คือความก้าวหน้าจริง และคุ้มค่าที่จะอัปเกรดด้วยคุณสมบัติของมันเอง แต่มันก็ยังไม่ใช่การ์ดเรล และสัปดาห์ที่มันเปิดตัวก็เป็นสัปดาห์ที่ความแตกต่างนี้ยิ่งสำคัญขึ้น ไม่ใช่ลดลง

TL;DR

การ์ดเรลคือขีดจำกัดที่ยังคงอยู่ไม่ว่าเอเจนต์จะตัดสินใจทำอะไร การปฏิเสธของโมเดลไม่นับเป็นเช่นนั้น เพราะมันคือการตัดสินใจ และการตัดสินใจก็เปลี่ยนได้ด้วยอินพุตที่ใช่ Opus 5.5 ตัดสินใจในจุดนี้ได้ถูกต้องบ่อยกว่ารุ่นก่อนมาก และมันไม่ได้เปลี่ยนสิ่งที่การรันหนึ่งครั้งได้รับอนุญาตให้แตะต้อง ใครถือข้อมูลรับรอง หรือใครเป็นคนอ่านดิฟฟ์ ในขณะเดียวกัน ค่าใช้จ่ายในการรันก็ต่ำกว่า Claude Opus 5 อยู่ 40% และ GPT-6 Sol กับ GPT-6 Luna ก็เปิดตัววันเดียวกันในราคา $2/$10 และ $0.10/$0.50 ต่อล้านโทเคน อัตราความล้มเหลวต่อการรันลดลง ปริมาณการรันของคุณกำลังจะเพิ่มขึ้น จงออกแบบโดยคำนึงถึงผลคูณของทั้งสองอย่าง

ตอนที่ GPT-6 Astra เปิดตัว เราเขียนถึงสี่สิ่งที่เอเจนต์ที่ใช้คอมพิวเตอร์ต้องมี ได้แก่ โฮสต์ ขอบเขต บันทึก และผู้อนุมัติ บทความนั้นพูดถึงว่าการรันเกิดขึ้นที่ไหน บทความนี้พูดถึงว่าเกิดอะไรขึ้นเมื่อการรันไปอ่านอะไรที่มุ่งร้าย

ตัวเลขนั้นคืออัตราส่วน และปริมาณของคุณไม่ได้คงที่

เหตุการณ์ผิดพลาดคืออัตราคูณด้วยจำนวนการรัน มีเพียงหนึ่งในสองพจน์นี้เท่านั้นที่ดีขึ้นเมื่อวันที่ 2026-09-22

อีกพจน์กลับทิศอย่างแรง Opus 5.5 ตั้งราคาที่ $4 ต่อล้านโทเคนอินพุต และ $20 ต่อล้านโทเคนเอาต์พุต เทียบกับ $5 และ $25 ของ Opus 5 โดยการอ่านจากแคชอยู่ที่ $0.20 และ Anthropic ระบุว่าต้นทุนรวมในการรันต่ำกว่า Opus 5 อยู่ 40% ในอีกด้านของวันเปิดตัวเดียวกัน OpenAI ตั้งราคา GPT-6 Sol ที่ $2/$10 และ GPT-6 Luna ที่ $0.10/$0.50 และรายงานว่า Sol ที่ระดับการให้เหตุผลสูงพิเศษทำคะแนนได้ 33.2% บน AutomationBench 1.0.6 ที่ต้นทุน $0.27 ต่องาน ซึ่ง OpenAI ระบุว่าอยู่ที่ประมาณ 9% ของต้นทุนต่องานของ Claude Opus 5 ที่ระดับการให้เหตุผลสูงสุด ทั้งที่ได้คะแนนต่ำกว่า

ลองคูณเลขในทีมของคุณเองแทนที่จะคูณบนเบนช์มาร์ก ถ้าอัตราความล้มเหลวต่อการรันลดลง 85% และคุณรันเอเจนต์มากขึ้นสิบเท่าเพราะแต่ละครั้งตอนนี้มีต้นทุนแค่เศษเสี้ยวของเมื่อก่อน คุณจะลงเอยที่จำนวนเหตุการณ์ผิดพลาดจริงประมาณ 1.5 เท่าของเดิม นั่นไม่ใช่การวัดอะไรทั้งสิ้น มันคือเลขคณิต และมันคือรูปร่างของอีกไม่กี่เดือนข้างหน้า โมเดลที่ถูกกว่าและปลอดภัยกว่าคือเหตุผลให้มอบหมายงานมากขึ้น การมอบหมายงานมากขึ้นคือสิ่งที่ทำให้ตัวเลขกลับขึ้นไป

การหลบเลี่ยงขอบเขตไม่เหมือนกับพรอมป์ต์อินเจกชัน

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

การลดลง 85% ในเรื่องแรกเป็นข่าวดีสำหรับเรื่องที่สอง แต่มันไม่ใช่อัตราการป้องกันสำหรับเรื่องที่สอง และไม่ควรมีใครยกมาอ้างแบบนั้น จงมองมันเหมือนคอมไพเลอร์ที่จับ type error ได้เก่งขึ้น มีหลุดมาถึงคุณน้อยลง แต่บั๊กประเภทนี้ยังมีอยู่

สิ่งที่โมเดลที่ดีกว่าขจัดออกไป และสิ่งที่มันทำไม่ได้

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

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

มีเพียงแถวบนสุดเท่านั้นที่ดีขึ้นในสัปดาห์นี้ ส่วนแถวล่างสุดคือแถวที่การลดราคาเพิ่งทำให้ตกอยู่ภายใต้แรงกดดัน

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

สามการตั้งค่าที่ควรเปลี่ยนในสัปดาห์นี้

Sharkly คือเลเยอร์ที่อยู่เหนือเอเจนต์ขึ้นไป มันเก็บ Task, Computer, ข้อมูลรับรอง, บันทึกการทำงาน และคนที่ทำหน้าที่อนุมัติ สามอย่างในนั้นควรปรับทันทีที่การรันเริ่มมีต้นทุนต่ำ

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

มองขอบเขตการอ่านเป็นส่วนหนึ่งของ Task ไม่ใช่เรื่องของความสะดวก เอเจนต์จะดึงข้อมูลจากที่ไหนได้บ้างกลายเป็นการตัดสินใจเชิงออกแบบแล้ว อะไรก็ตามที่มันอ่านสามารถแฝงคำสั่งได้ ดังนั้น "ดูว่าซื้อ API ของผู้ให้บริการรายนี้ทำงานอย่างไร" กับ "ทำตามคำแนะนำการตั้งค่าบนหน้านี้" จึงเป็นสอง Task ที่แบกความเสี่ยงสองแบบต่างกัน จุดที่ผลการค้นเว็บของเอเจนต์ควรไปลง ลงรายละเอียดเรื่องนี้ไว้แล้ว

เขียนให้ชัดว่าการเปลี่ยนแปลงแบบไหนที่คนต้องอ่านทีละบรรทัด ไม่ใช่เป็นนิสัย แต่เป็นกฎบน Workflow ได้แก่ การมิเกรตสคีมา อะไรก็ตามที่แตะเรื่อง auth อะไรก็ตามที่เพิ่ม dependency อะไรก็ตามที่ Agent สร้างขึ้นตอนที่ไม่มีใครตื่นอยู่ ส่วนที่เหลือผ่านได้ด้วยหลักฐาน ประตูอนุมัติคือที่ที่กฎนี้อยู่ และการเขียนมันลงไปคือสิ่งที่ทำให้ความสนใจยังอยู่กับแถวที่ความสนใจได้ผลตอบแทน

คิวคือสิ่งที่ไม่ได้ถูกลง

ทุกประกาศเมื่อวันที่ 2026-09-22 ทำให้งานของเอเจนต์มีต้นทุนต่ำลง ปลอดภัยขึ้น หรือทั้งสองอย่าง ต่อการรันหนึ่งครั้ง ไม่มีสักประกาศที่ทำให้คนอ่านเร็วขึ้น ความไม่สมมาตรนี้คือปัญหาการออกแบบตัวจริง และเป็นเหตุผลว่าทำไมการรีวิวโดยมนุษย์จึงเป็นคอขวด ไม่ใช่คุณภาพของโมเดล

ซึ่งเป็นเหตุผลว่าทำไมคำตอบจึงเป็นเชิงโครงสร้าง ไม่ใช่รูปทรงของโมเดล การรันแต่ละครั้งได้ไดเรกทอรีที่แยกออกไป ดังนั้นตัวที่ถูกโจมตีจึงถูกกักไว้ ไม่ใช่ต้องไปเถียงด้วย การทำงาน อุปสรรค ผลลัพธ์ และการพูดคุยติดตามผลกลับมาอยู่ใน Task แทนที่จะเลื่อนผ่านไปในเทอร์มินัลของใครสักคน ซึ่งเป็นวิธีเดียวที่นักรีวิวจะแยกได้ว่าการรันครั้งไหนถูกเบี่ยงออกนอกเส้นทาง กับการรันที่แค่ล้มเหลว รายการที่ต้องให้ความสนใจไปรวมอยู่ใน Inbox เดียว เพื่อให้การตัดสินใจที่ต้องอาศัยคนไม่ถูกฝังอยู่ใต้การรันที่เสร็จเรียบร้อย บริบท ความคืบหน้า อุปสรรค ผลลัพธ์ และการรีวิวโดยมนุษย์ยังมองเห็นได้ตั้งแต่คำขอจนถึงการปล่อย

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

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