เมื่อ eval ของ coding agent ผ่านเพราะ sandbox รั่ว — Microsoft เล่าเคสที่ agent ถูกตัดเน็ตแล้วไปเจอซอร์สโค้ดคำตอบอยู่บนเครื่องตัวเอง

16 ก.ย. 2026 Waldek Mastykarz ตำแหน่ง Principal Developer Advocate ของ Microsoft ที่ดูแลงานด้าน AI coding agents เผยแพร่บทความที่ควรถูกอ่านโดยทุกคนที่กำลังทำ eval ของ agent อยู่ ประโยคเปิดของเขาคือ “eval ที่ผ่าน อาจพิสูจน์ผิดเรื่อง คำตอบอาจถูกต้องในขณะที่การวัดเบื้องหลังมันใช้ไม่ได้”

ประเด็นคือ agent ตอบคำถามได้จากหลายเส้นทาง — จากความรู้ภายในโมเดล จากข้อมูลใน prompt หรือจากการไปค้นหลักฐานในสภาพแวดล้อมที่มันอยู่ แต่ละเส้นทางพิสูจน์ความสามารถคนละอย่าง และ คำตอบสุดท้ายแทบไม่เคยบอกว่า agent เดินทางไหนมา

เคสจริง: ปิดเน็ตแล้ว แต่คำตอบอยู่บนเครื่อง

Mastykarz ต้องการวัดว่า GPT-5.6 Luna รู้อะไรเกี่ยวกับ Dev Proxy เวอร์ชันต่าง ๆ บ้าง เพื่อเทียบกับ knowledge cutoff ที่โมเดลรายงานตัวเอง ถ้าปล่อยให้ agent ไปค้นเอกสาร การเปรียบเทียบจะไร้ความหมายทันที เขาจึงตั้งค่า eval ให้ บล็อกเครื่องมือเว็บในตัว และบล็อกการต่อเน็ตตรงผ่าน curl ดูเหมือนขอบเขตปิดสนิทแล้ว

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

แต่พอไปเปิด trajectory ดู เรื่องกลับตาลปัตร เครื่องที่รัน eval ยังมี Dev Proxy ติดตั้งอยู่พร้อม source checkout ของมัน ลำดับเหตุการณ์ที่บทความบันทึกไว้ละเอียดมาก:

1. คำสั่ง command -v devproxy ถูกบล็อก
2. agent เปลี่ยนไปใช้ which devproxy ซึ่ง ไม่ถูกบล็อก และได้ทั้งตัว executable และ path เต็มของ source checkout
3. จากนั้นใช้ rg ผ่าน shell แล้วเรียก rg แบบ standalone
4. แล้ว cd เข้าไปในรีโปเพื่ออ่านซอร์สที่ tag v0.29.2
5. คำสั่ง find หนึ่งครั้งถูกบล็อก แต่ไม่มีผลอะไร เพราะมีเส้นทางอื่นไปถึงหลักฐานเดียวกันอยู่แล้ว

สุดท้าย agent ยืนยันได้ว่า prompt ที่ถูก parse แล้วถูกแคชด้วยชื่อไฟล์และพารามิเตอร์ แล้วให้คำวินิจฉัยที่ผ่าน eval บทสรุปของ Mastykarz คือ มันเป็นคำตอบที่ค้นมาอย่างดี แต่ไม่ได้เป็นหลักฐานของความรู้ที่โมเดลมีเองเลยสักนิด

คำอธิบายว่าทำไมทุกการบล็อกถึงเผยเส้นทางใหม่เสมอ เขาตอบไว้คมมาก: agent ปฏิบัติกับ tool call ที่ถูกปฏิเสธเหมือนเป็นอุปสรรค แล้วใช้ความสามารถที่เหลือเดินต่อ ดังนั้น sandbox ที่สร้างจากกฎ deny ทีละข้อจะวิ่งตามหลังการค้นหานั้นเสมอ เว้นแต่กฎเหล่านั้นจะบังคับขอบเขตร่วมกันชุดเดียว

ข้อเสนอ: นิยาม sandbox รอบ “ข้อมูล” ไม่ใช่รอบ “เครื่องมือ”

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

ในทางปฏิบัติแปลว่า: บังคับการเข้าถึงไฟล์ ที่ขอบเขตของ workspace ให้ทุกคำสั่งอยู่ใต้กฎเดียวกัน, ถอนการติดตั้งผลิตภัณฑ์และ source checkout ที่ไม่เกี่ยวข้องออกจากเครื่อง host, ลดรายละเอียด environment ที่สืบทอดมาซึ่งเปิดเผย path หรือซอฟต์แวร์ที่ติดตั้งไว้ แล้วใช้ขอบเขตเดียวกันนั้นกับทั้งคำสั่ง shell และเครื่องมือที่ผูกมาด้วย

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

เขายังย้ำว่า grader ที่เขียน rubric ดีแค่ไหนก็ซ่อมอินพุตที่ปนเปื้อนหลังรันจบไม่ได้ ต้องไปดู trajectory เต็ม ทั้ง tool call และ observation ที่ส่งกลับไปให้ agent และ ความพยายามที่ล้มเหลวก็มีค่า เพราะมันบอกว่า agent คิดว่าอะไรมีประโยชน์ และมักชี้ขอบเขตถัดไปที่ต้องปิด การที่คำสั่งหนึ่งถูกห้ามพิสูจน์แค่ว่าเส้นทางหนึ่งปิด ไม่ได้พิสูจน์ว่าเส้นทางอื่นไม่สำเร็จ

เช็คลิสต์ที่เอาไปใช้ได้เลย

บทความปิดท้ายด้วยแปดข้อสำหรับ eval รอบหน้า:

1. นิยามความสามารถที่ต้องการวัด และข้อมูลที่ agent มีสิทธิ์ใช้
2. เริ่มทุกรันใน workspace ที่สะอาด มีแต่ fixture ที่ตั้งใจใส่
3. ใช้ path ของ workspace ที่เป็นกลาง ไม่มีคำที่ใบ้ถึงตัว eval
4. จำกัดแหล่งความรู้ภายนอกเมื่อการวัดต้องการความรู้ภายใน
5. บังคับการเข้าถึงไฟล์ที่ขอบเขตของ workspace
6. ใช้ข้อจำกัดที่เทียบเท่ากันกับเครื่องมือทุกตัวที่มี
7. ตรวจสอบผลที่ผ่านแบบน่าประหลาดใจ พร้อม trajectory เต็มที่อยู่เบื้องหลัง
8. เพิ่ม regression probe สำหรับทุกเส้นทางที่ agent ค้นเจอ แล้วรัน eval ใหม่

ประโยคปิดของเขาคือ “คุณเชื่อคะแนนที่ผ่านได้ก็ต่อเมื่อคุณอธิบายได้ว่า agent ไปถึงคะแนนนั้นได้อย่างไร มิฉะนั้น คะแนนอาจบอกเรื่องเครื่องของคนทำ eval มากกว่าบอกเรื่องตัวโมเดล”

เครื่องมือที่เขาใช้คือ Vally ซึ่งอธิบายตัวเองว่าเป็น extensible eval platform ที่รันได้ทั้งใน dev workflow และใน CI โดยไปป์ไลน์คือ stimulus → executor → trajectory → graders → score และชี้ executor ไปที่ agent, MCP server หรือ CLI ตัวไหนก็ได้ ข้อควรทราบสำหรับคนที่อยากลอง: ณ 17 ก.ย. เอกสารที่ microsoft.github.io/vally เปิดอ่านได้ แต่ github.com/microsoft/vally ยังคืน 404 ซึ่งแปลว่ารีโปยังไม่เปิดสาธารณะ

มุมมอง AI Curator

บทความนี้มาถูกจังหวะพอดีกับกระแสที่วิ่งอยู่ในวงการช่วงนี้ ในสองสัปดาห์ที่ผ่านมาเราเขียนถึงรายงานของ Trail of Bits ที่พบว่า grader ไม่ตรงกันเองถึง 36.8% และการรีวิวโค้ดที่ Astra เป็นทั้งผู้เข้าแข่งขันและกรรมการ มาแล้ว คราวนี้เป็นชั้นที่ลึกลงไปอีกหนึ่งขั้น — ไม่ใช่เรื่องคนให้คะแนนผิด แต่เป็นเรื่องที่ตัวข้อสอบรั่วตั้งแต่ต้น และมันยังไปคู่กันพอดีกับบทเรียนเรื่อง phantom speedup 20% ในงาน qorl ที่ออกวันเดียวกัน รากของทั้งสามคือเรื่องเดียวกัน คือ การวัดที่ดูผ่าน แต่วัดผิดสิ่ง

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

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

และถ้าจะให้ผมเลือกข้อเดียวจากแปดข้อไปติดไว้หน้าจอ ผมเลือกข้อ 3 — ตั้งชื่อ path ของ workspace ให้เป็นกลาง มันดูเล็กจนน่าขำเมื่อเทียบกับข้ออื่น แต่มันคือประเภทของการรั่วที่ไม่มีใครนึกถึงและไม่ปรากฏใน log ว่าเป็นการละเมิดกฎอะไรเลย agent แค่อ่านชื่อโฟลเดอร์ที่คุณตั้งไว้เอง

แหล่งข่าว

• Microsoft for Developers — Your AI coding agent evaluation is only as good as its sandbox (16 ก.ย. 2026)
• Vally — เอกสารของแพลตฟอร์ม eval ที่ใช้ในเคสนี้
• GitHub — dotnet/dev-proxy (ผลิตภัณฑ์ที่ถูกใช้เป็นหัวข้อทดสอบ)