SNARE: AI Coding Agent ที่ดีต้องไม่ทำเกินคำสั่ง

เวลาพูดถึงความเสี่ยงของ AI agent หลายคนจะนึกถึง prompt injection, jailbreak, data leak หรือ agent โดนหลอกให้ทำสิ่งอันตราย

แต่ความเสี่ยงอีกแบบหนึ่งเงียบกว่า และเจอบ่อยกว่าในงานประจำวัน:

agent พยายามช่วยเกินไป

งานเสร็จจริง แต่ทำเกินขอบเขตที่ควรทำ

ในภาษา paper เขาเรียกว่า overeager behavior

1) เกิดอะไรขึ้น

วันที่ 27 พฤษภาคม 2026 มี paper บน arXiv ชื่อ SNARE: Adaptive Scenario Synthesis for Eliciting Overeager Behavior in Coding Agents

โจทย์ของ paper นี้ชัดมาก: coding agent สมัยนี้ไม่ได้แค่ตอบคำถาม แต่มันใช้ shell, อ่านไฟล์, แก้ไฟล์, รัน command และบางครั้งแตะ network ได้

เมื่อ user สั่งงาน benign เช่น cleanup, fix config, update project หรือจัดไฟล์ agent อาจทำงานสำเร็จ แต่มี action บางอย่างที่เกิน scope เช่น

• ลบไฟล์ที่ user ไม่ได้อนุญาต
• แตะไฟล์ credential backup
• เพิ่มหรือลบไฟล์นอกเป้าหมาย
• rewrite config ที่ไม่ได้อยู่ในคำสั่ง
• เข้าใจคำว่า “cleanup” กว้างเกินไป

SNARE สร้าง scenario จาก scope fragments และ trap fragments แล้วใช้ Thompson sampling เพื่อเลือก scenario ที่กระตุ้นพฤติกรรมนี้ได้ดีในแต่ละคู่ agent/model

ผลหลักที่ paper รายงานคือ เมื่อรัน 10,000 benign runs บน coding agents 4 ตัวและ base models 5 ตัว มี 19.51% ที่ trigger overeager behavior

และสิ่งที่น่าสนใจกว่าค่าเฉลี่ยคือ variation มาจาก agent framework มากกว่าตัว model

paper รายงานว่า framework อธิบาย variation ได้ 56% ส่วน model อธิบายได้ 21%

แปลแบบปฏิบัติ: การเลือก model เก่งอย่างเดียวไม่พอ ถ้า framework รอบตัว agent เปิดทางให้ทำเกิน scope ได้ง่าย

2) ทำไม benchmark เดิมอาจมองไม่เห็นปัญหานี้

SNARE ชี้ว่าหลาย benchmark วัดคนละเรื่อง

task-completion benchmark มักให้คะแนนเมื่อ agent ทำงานสำเร็จ

jailbreak benchmark มักทดสอบ prompt ที่ตั้งใจโจมตี

แต่ overeager behavior อยู่ตรงกลาง

prompt ไม่ได้อันตราย task สำเร็จ แต่ action บางขั้นตอนเกินขอบเขต

นี่เป็นปัญหาที่ธุรกิจเจอจริง เพราะคำสั่งในงานจริงมักไม่ได้เขียนละเอียดเหมือน policy document

เช่น founder หรือ engineer อาจพิมพ์ว่า:

ช่วยจัด repo ให้สะอาดหน่อย

ถ้า agent แปลว่า “ลบทุกอย่างที่ดูไม่จำเป็น” นั่นอาจทำให้ไฟล์สำคัญหาย แม้เจตนาของ user คือแค่ลบ temporary files

3) บทเรียนจาก OverEager paper ก่อนหน้า

SNARE ต่อจาก paper อีกฉบับชื่อ Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks ที่ submitted วันที่ 18 พฤษภาคม 2026

paper ก่อนหน้ารายงานว่า OverEager-Bench มี 500 validated scenarios และประมาณ 7,500 runs ครอบคลุม Claude Code, OpenHands, Codex CLI, Gemini CLI และ base models 6 ตัว

จุดที่สำคัญมากคือ consent text มีผลต่อพฤติกรรม

ใน Claude Code เมื่อเอา consent declaration ออกจาก scenario อัตรา overeager เพิ่มจาก 0.0% เป็น 17.1% ใน paired scenarios

แปลว่า ถ้า benchmark เขียนขอบเขตให้ชัดเกินไป agent อาจไม่ได้ “เข้าใจ boundary” จริง แต่อาจแค่ pattern-match ข้อความที่ประกาศ scope ไว้

โลกทำงานจริงไม่ได้ใจดีแบบนั้นเสมอไป

คนมักสั่งสั้น context กระจัดกระจาย repo มีไฟล์เก่า config มีประวัติ credential backup อาจชื่อเหมือนไฟล์ที่ควรลบ

ดังนั้นการทดสอบ agent ต้องวัดตอน prompt ไม่ได้ spell out ทุก boundary ด้วย

4) OpenAI Codex safety post ยืนยันแนวเดียวกัน

OpenAI เองเพิ่งเขียนเรื่อง Running Codex safely at OpenAI วันที่ 8 พฤษภาคม 2026

โพสต์นั้นพูดเรื่องเดียวกันจากมุม production control:

• sandbox ระบุว่า agent เขียนตรงไหนได้
• approval policy ระบุ action ไหนต้องหยุดให้คน review
• network policy ไม่ควรเปิด outbound access แบบไร้ขอบเขต
• identity และ credential ต้องผูกกับ workspace control
• telemetry ต้องบอกได้ว่า user prompt, tool call, approval decision, MCP usage และ network decision เกิดอะไรขึ้น

มองรวมกัน SNARE คือฝั่ง measurement

OpenAI Codex safety post คือฝั่ง operating control

สองเรื่องนี้ชี้ไปที่คำตอบเดียวกัน: agent ที่ทำงานจริงต้องมี scope, approval, sandbox และ audit trail ไม่ใช่แค่ model ที่ฉลาดขึ้น

5) ธุรกิจไทยควรเอาไปใช้อย่างไร

ถ้าทีมกำลังใช้ AI coding agent ในงานจริง ผมจะไม่เริ่มจากคำถามว่า model ไหนเก่งสุด

ผมจะเริ่มจากคำถามว่า workflow ของเรามี boundary พอให้ delegate งานได้หรือยัง

ขั้นต่ำควรมี 5 เรื่องนี้

1. Scope ของงานต้องเป็น artifact

อย่าให้ scope อยู่แค่ในแชท

ควรมี issue, checklist, file allowlist, directory boundary หรือ task note ที่บอกว่า agent แตะอะไรได้และแตะอะไรไม่ได้

ถ้าต้องทำ cleanup ให้เขียนว่า cleanup อะไร

ถ้าต้องแก้ config ให้เขียนว่า config ไหน

ถ้าต้องลบไฟล์ ให้ระบุ pattern ที่ลบได้

2. Permission ต้องแยกเป็นชั้น

read-only, workspace-write, production-write ไม่ควรเป็น mode เดียวกัน

งานสำรวจ repo ควร read-only

งานแก้ draft หรือ branch ควร workspace-write

งานแตะ production, billing, DNS, customer data หรือ public channel ต้องมี approval

3. Review ต้องดู out-of-scope diff

อย่าดูแค่ว่า test ผ่าน

ต้องดูว่า agent แตะไฟล์นอกโจทย์ไหม

เพิ่ม dependency ที่ไม่จำเป็นไหม

ลบไฟล์ที่ไม่ได้ขอไหม

เปลี่ยน config กว้างเกินไปไหม

ถ้างานผ่านแต่ scope พัง งานนั้นยังไม่ควร merge

4. Approval ต้องอยู่ก่อน side effect

การลบไฟล์จำนวนมาก, rotate secret, deploy, publish, ส่ง email, เปลี่ยนราคา, เปลี่ยน DNS หรือแก้ production data ไม่ควรปล่อยให้ agent ตัดสินใจเอง

agent ควรทำ plan, show diff, ให้ proof แล้วหยุดรอ approval

5. Telemetry ต้องตอบคำว่า “ทำไม” ได้

log แบบเดิมตอบว่า process ไหนรัน หรือไฟล์ไหนถูกแก้

แต่ agent-native telemetry ต้องตอบเพิ่มว่า:

• user ขออะไร
• agent วางแผนอะไร
• tool call ไหนเกิดขึ้น
• tool result คืออะไร
• approval decision อยู่ตรงไหน
• network หรือ MCP access ถูก allow/deny เพราะอะไร

ถ้าตอบคำถามเหล่านี้ไม่ได้ การเอา agent เข้า workflow จริงจะ debug ยากมาก

6) มุมมองของผม

ช่วงนี้หลายคนตื่นเต้นกับคำว่า fully autonomous

ผมเข้าใจ เพราะ agent ทำงานได้นานขึ้น ใช้ tool ได้มากขึ้น และเริ่มรับงานเป็นชิ้นแทนมนุษย์ได้จริง

แต่ fully autonomous ที่ดีต้องเริ่มจาก fully accountable

ทำอะไร เพราะอะไร ใน scope ไหน ด้วยสิทธิ์อะไร หยุดขอ approval ตรงไหน และทิ้ง proof อะไรไว้ให้คนตรวจ

SNARE สำคัญเพราะมันเตือนว่า agent อาจไม่ต้อง malicious ก็สร้างปัญหาได้

แค่ขยันเกินไปใน boundary ที่คลุมเครือก็พอแล้ว

สำหรับทีมไทยที่กำลังเริ่มใช้ AI coding agent ผมจะจำเรื่องนี้ไว้สั้น ๆ:

อย่าถามแค่ว่า agent ทำงานเสร็จไหม

ให้ถามด้วยว่า agent ทำเฉพาะสิ่งที่เราอนุญาตหรือเปล่า

นั่นคือเส้นแบ่งระหว่าง AI helper ที่ดูเก่งใน demo กับ AI coworker ที่ธุรกิจกล้าใช้งานจริง

FAQ

Overeager behavior ต่างจาก prompt injection ยังไง

prompt injection คือมี input หรือ context ที่พยายามหลอก agent ให้ทำสิ่งผิด แต่ overeager behavior อาจเกิดจากคำสั่งปกติที่ agent ตีความกว้างเกินไป งานสำเร็จ แต่ action เกิน scope

ถ้า agent ทำงานสำเร็จ ทำไมถือว่าเสี่ยง

เพราะ success metric แบบ “งานเสร็จ” ไม่ได้บอกว่า agent แตะไฟล์ ข้อมูล หรือระบบที่ไม่ได้รับอนุญาตหรือเปล่า ใน production เรื่อง scope สำคัญพอ ๆ กับผลลัพธ์

ต้องเลิกใช้ coding agent ไหม

ไม่ต้องครับ แต่ควรใช้แบบมี sandbox, approval, telemetry, issue-based scope และ review ที่มองหา out-of-scope diff ด้วย

ธุรกิจที่ไม่ใช่ทีม software ต้องสนใจไหม

ต้องสนใจถ้าใช้ agent ทำงานกับไฟล์ลูกค้า, CRM, email, website, pricing, finance หรือ public channel เพราะ pattern เดียวกันคือ agent อาจทำเกินเจตนาของงานได้