Google เสนอวิธีคุม system prompt ที่บวมจนแก้ไม่ไหว — คอมไพล์ prompt เหมือนคอมไพล์โค้ด จับ error ตั้งแต่ตอน build

เมื่อวันที่ 16 กรกฎาคม 2026 Google Developers Blog เผยแพร่บทความของ Simerus Mahesh วิศวกร Site Reliability Engineer ที่พูดถึงปัญหาซึ่งทีมที่เอาเอเจนต์ขึ้น production จริงน่าจะเจอกันทุกทีม แต่แทบไม่มีใครพูดถึงตรง ๆ: system prompt ที่โตขึ้นเรื่อย ๆ จนไม่มีใครกล้าแก้

ประโยคที่สรุปบทความนี้ได้ดีที่สุดคือ “At production scale, prompt maintainability becomes agent reliability” — พอถึงระดับ production ความง่ายในการดูแล prompt กลายเป็นเรื่องเดียวกันกับความน่าเชื่อถือของเอเจนต์ ไม่ใช่เรื่องความสะอาดของโค้ดอีกต่อไป

อาการสามอย่างของ prompt ที่บวมเกินคุม

บทความระบุรูปแบบความล้มเหลวไว้สามข้อ ซึ่งอ่านแล้วน่าจะคุ้นสำหรับใครที่ดูแลเอเจนต์หลายตัว:

• Obscured blast radius — ไม่รู้ว่าแก้แล้วกระทบอะไรบ้าง แก้ prompt จุดเดียวแล้วพฤติกรรมของเอเจนต์ตัวอื่นเปลี่ยนตามแบบคาดไม่ถึง
• Copy-paste drift — ตรรกะที่ใช้ร่วมกัน เช่น นโยบายความปลอดภัย หรือวิธีจัดการข้อมูล PII ถูกก๊อปวางไปในหลาย ๆ prompt แล้วค่อย ๆ เพี้ยนออกจากกันจนไม่ตรงกันอีกต่อไป
• Deferred runtime errors — การประกอบ prompt ด้วยการต่อสตริงแบบมือ ๆ ทำให้ error ทุกชนิดไปโผล่ตอนรันจริง แทนที่จะโดนจับตั้งแต่ตอน build

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

แนวทาง: มอง prompt เป็น build artifact

ข้อเสนอของบทความคือเลิกมอง prompt เป็น “ข้อความที่แก้ตรง ๆ” แล้วมองเป็น ผลลัพธ์ที่ถูก build ออกมา เหมือน binary ที่คอมไพล์จาก source โดยมีองค์ประกอบหลักคือ:

• Modular skill files — แตกพฤติกรรมแต่ละอย่างออกเป็นไฟล์ของตัวเอง
• Template layer — ประกอบไฟล์เหล่านั้นด้วย include, ตัวแปร และ macro
• Transpiler — แปลง source ที่เป็น template ให้กลายเป็น artifact สุดท้ายแบบ deterministic
• Build-time validation — จับ import ที่หาไม่เจอ ตัวแปรที่ไม่ได้นิยาม และ dependency ที่วนลูป ก่อน deploy
• Drift checking — ให้ CI/CD สร้าง prompt ใหม่แล้วเทียบกับ artifact ที่ commit ไว้ ถ้าไม่ตรงแปลว่ามีคนแก้ข้ามขั้นตอน

หน้าตาของ template ที่ยกตัวอย่างในบทความก็ตรงไปตรงมา:

{% include "shared/safety.prompt.md" %}
{% include "shared/tool_usage.prompt.md" %}

{% if allow_remediation %}
You may recommend remediation steps...
{% endif %}

อีกแนวคิดที่บทความเน้นคือ progressive disclosure — แยก “control plane” ที่นิ่งและใช้ตลอด ออกจาก skill ที่เฉพาะกับงานและโหลดเข้ามาตอนรันเท่านั้น ผลตรงคือ ประหยัด token เพราะไม่ต้องยัดทุกความสามารถลงไปใน context ทุกครั้ง

ผลที่ได้ และสิ่งที่บทความ ไม่ได้ ให้

ประโยชน์ที่ระบุไว้คือ separation of concerns ที่ดีขึ้น การแก้ prompt ที่ทดสอบและตรวจสอบย้อนหลังได้ และที่น่าสนใจที่สุด — ตัวเอเจนต์เองเสนอแก้คำสั่งของตัวเองผ่าน pull request ได้ แล้วให้มนุษย์รีวิวผ่านกระบวนการ code review ปกติ

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

มุมมอง AI Curator

สิ่งที่บทความนี้ทำจริง ๆ คือการประกาศว่า prompt engineering กำลังจบยุค “ศิลปะ” และเข้าสู่ยุค “วิศวกรรม” ทุกอย่างที่เสนอ — โมดูล, การ build, validation ตอนคอมไพล์, drift check ใน CI — ล้วนเป็นบทเรียนที่วงการซอฟต์แวร์เรียนรู้มาแล้วเมื่อสามสิบปีก่อน ตอนที่เราเลิกเขียนสคริปต์ก้อนเดียวแล้วหันมาใช้โมดูลกับระบบ build จริงจัง เรากำลังเดินซ้ำเส้นทางเดิม เพียงแต่คราวนี้ artifact ที่ต้องคุมคือภาษาธรรมชาติ

ที่น่าสังเกตคือทิศทางนี้สอดคล้องกับสิ่งที่เราเห็นมาตลอดเดือนนี้ ตั้งแต่ Anthropic ตัด system prompt ของ Claude Code ให้สั้นลง ไปจนถึงเรื่อง token overhead 33k ของ Claude Code — คำถามกลางเหมือนกันหมดคือ “เราจะคุมสิ่งที่ยัดเข้า context ได้อย่างไร เมื่อมันแพงและเปราะพร้อมกัน” แนวคิด progressive disclosure ในบทความนี้คือคำตอบเชิงโครงสร้างต่อคำถามเดียวกันนั้น

สำหรับทีมไทย ผมคิดว่าข้อที่ควรหยิบไปใช้ทันทีคือ drift check ไม่ใช่ transpiler เต็มรูปแบบ การสร้างระบบ template ครบชุดเป็นงานใหญ่ที่ทีมส่วนใหญ่ยังไม่คุ้ม แต่การเอา prompt เข้า git แล้วให้ CI เตือนเมื่อมีคนแก้ไฟล์ prompt โดยไม่ผ่านรีวิว เป็นงานครึ่งวันที่ป้องกันปัญหาได้จริง หลายทีมในไทยที่เพิ่งเริ่มขยับจาก POC ไป production ยังเก็บ prompt ไว้ในฐานข้อมูลหรือใน admin panel ที่แก้ได้สด ๆ โดยไม่มีประวัติ — นั่นคือจุดที่ควรแก้ก่อนเรื่องอื่นทั้งหมด

ข้อควรระวังสุดท้าย: อย่าเพิ่งรีบสร้าง abstraction ให้ prompt ตั้งแต่วันแรก บทความนี้พูดถึงปัญหาที่เกิด “as AI agents scale from prototypes to production” ถ้าคุณมีเอเจนต์ตัวเดียวกับ prompt สองร้อยบรรทัด การใส่ระบบ template และ transpiler เข้าไปคือการเพิ่มความซับซ้อนโดยไม่ได้แก้ปัญหาอะไร — วิธีนี้จ่ายคุ้มเมื่อคุณมีเอเจนต์หลายตัวที่ใช้ตรรกะร่วมกัน ไม่ใช่ก่อนหน้านั้น

แหล่งข่าว

• Building scalable AI agents with modular prompt transpilation — Google Developers Blog (16 ก.ค. 2026)
• Google Developers Blog