Google กำลังปิด 2 รูรั่วใหญ่ของ AI coding agents: docs เก่า และรันงานผิด tier
ถ้าถามว่าปัญหาใหญ่ของ AI coding agents วันนี้คืออะไร หลายคนน่าจะตอบว่า model ยังไม่เก่งพอ
แต่สัญญาณจาก Google ต้นเดือนเมษายน 2026 บอกชัดว่า ปัญหาของของจริงอาจไม่ได้อยู่ที่ model อย่างเดียว
มันอยู่ที่อย่างน้อย 2 เรื่อง
- agent ทำงานบนข้อมูลและ docs ที่ไม่อัปเดต
- เราเอางานคนละแบบไปรันบน serving model แบบเดียวกัน
วันที่ 1 เมษายน Google ออกอัปเดตเรื่อง Gemini API Docs MCP และ Agent Skills วันที่ 2 เมษายน Google ออก Flex และ Priority inference tiers สำหรับ Gemini API
ถ้ามองแยกกัน มันอาจดูเหมือนคนละเรื่อง แต่ถ้ามองรวมกัน ผมว่า Google กำลังบอกตลาดชัดมากว่า AI coding agent ที่พร้อมใช้จริง ต้องมีทั้ง 1) ความรู้ที่สดพอ 2) runtime ที่ตรงกับลักษณะงาน
นี่ไม่ใช่ patch เล็กๆ แต่มันคือการขยับจากโลกของ demo ไปสู่โลกของ production
1) สิ่งที่เพิ่งเปลี่ยน คือ Google ไม่ได้แก้แค่ model แต่กำลังแก้ “ชั้นโครงสร้าง” ของ agent
ในโพสต์วันที่ 1 เม.ย. Google เขียนตรงๆ ว่า coding agents สามารถ generate Gemini API code ที่ล้าสมัยได้ เพราะ training data ของมันมี cutoff date
ทางแก้ที่ Google ออกมาคือสองชิ้นที่ทำงานคู่กัน
Gemini API Docs MCPเพื่อให้ coding agent เข้าถึง docs, SDKs, model information และ configuration ล่าสุดGemini API Developer Skillsเพื่อใส่ best practices, resource links และ pattern การใช้งานที่เป็นปัจจุบันให้ agent ใช้ตอนลงมือทำงาน
จากนั้นในวันที่ 2 เม.ย. Google ขยับไปแก้อีกด้านหนึ่ง คือเรื่อง serving economics และ reliability
เขาเพิ่ม Flex และ Priority inference เข้า Gemini API โดยใช้ synchronous interface เดิม แค่เปลี่ยน service_tier ให้เหมาะกับลักษณะงาน
ถ้าแปลเป็นภาษาคนทำงานจริง Google กำลังแก้ทั้ง
- ความรู้ที่ agent ใช้ตอนคิด
- และสภาพแวดล้อมที่ agent ใช้ตอนรัน
นี่คือสัญญาณสำคัญมาก เพราะมันทำให้เกม AI agents ไม่ได้แข่งกันที่ model อย่างเดียวอีกแล้ว แต่แข่งกันที่ stack การทำงานทั้งหมด
2) รูรั่วแรกคือ “agent ฉลาด แต่ใช้เอกสารเก่า”
นี่เป็น pain point ที่ทีม dev เจอจริงมาก
หลายครั้ง model ตอบดูมั่นใจมาก แต่โค้ดที่มัน generate ใช้ method เก่า, config เก่า, หรือแนะนำ flow ที่ไม่ตรงกับ SDK ล่าสุด ปัญหาไม่ใช่แค่มันคิดไม่ออก แต่คือมันกำลังคิดจากโลกเมื่อหลายเดือนก่อน
Google เลยสร้าง public MCP server ที่ gemini-api-docs-mcp.dev และใน docs อธิบายชัดว่าเมื่อเชื่อม coding agent เข้ากับ server นี้ ทุก query จะเข้าถึง API ล่าสุด, code updates ล่าสุด และตัวอย่าง config ที่เหมาะที่สุด
นี่สำคัญมากกว่าที่ดู เพราะมันเปลี่ยน agent จากระบบที่อาศัยน้ำหนักในโมเดลอย่างเดียว ไปสู่ระบบที่มี “เส้นเลือดสด” เชื่อมกับข้อมูลจริง
สำหรับทีมที่ใช้ Claude Code, Cursor, Gemini CLI หรือเครื่องมืออื่นที่รองรับ MCP นี่คือแนวคิดที่เอาไปใช้ได้ทันที เพราะ Google เองยังใส่คำสั่ง verification ไว้ให้เช็กเลยว่า MCP และ skills โหลดเข้า environment แล้วหรือยัง
ประเด็นคือ ถ้า agent อ่านโลกปัจจุบันได้ โอกาสที่มันพลาดเพราะความรู้เก่าจะลดลงทันที
3) รูรั่วที่สองคือ “เราเอางานทุกแบบไปรันบน tier เดียว”
Google อธิบายในโพสต์วันที่ 2 เม.ย. ไว้ชัดมากว่า เมื่อ AI เริ่มขยับจาก chatbot ไปสู่ autonomous agents นักพัฒนาจะต้องดูแลงานอย่างน้อย 2 แบบ
แบบแรกคือ background tasks เช่น data enrichment, long-running research, หรือ agentic workflow ที่ปล่อยให้ระบบคิดต่อในฉากหลังได้
แบบที่สองคือ interactive tasks เช่น customer support bot, copilots, moderation pipeline หรือ request ที่ต้องตอบไวและต้องนิ่ง
ปัญหาคือก่อนหน้านี้ ถ้าอยากรองรับทั้งสองแบบ ทีมมักต้องแยกสถาปัตยกรรม งานหนึ่งใช้ synchronous serving ปกติ อีกงานหนึ่งต้องไปใช้ async Batch API
Google กำลังลดความซับซ้อนตรงนี้ ด้วยการบอกว่า ตอนนี้คุณ route งานสองแบบนี้บน synchronous endpoints ชุดเดิมได้แล้ว ผ่าน service_tier
นี่ไม่ใช่แค่ convenience แต่มันคือการยอมรับว่าต้นทุนและ reliability ของ workload แต่ละแบบไม่เท่ากัน และไม่ควรถูกปฏิบัติแบบเดียวกัน
4) Google กำลังบอกว่า production agent ต้องมีทั้ง “live context” และ “traffic orchestration”
ถ้าเอาอัปเดตสองชิ้นนี้มาวางคู่กัน ภาพใหญ่จะชัดมาก
ฝั่ง Docs MCP + Skills แก้ปัญหาเรื่อง knowledge freshness และ execution guidance ฝั่ง Flex + Priority แก้ปัญหาเรื่อง cost, latency และ reliability ตามลักษณะงาน
พูดง่ายๆ คือ Google กำลังบอกว่า production agent ที่ใช้ได้จริง ต้องตอบคำถาม 2 ข้อให้ได้
ข้อแรก: ตอนมันทำงาน มันเห็นข้อมูลล่าสุดไหม ข้อสอง: ตอนมันทำงาน มันวิ่งอยู่บน tier ที่เหมาะกับงานนั้นไหม
ถ้าตอบสองข้อนี้ไม่ได้ ต่อให้ model ดีขึ้นอีกมาก คุณก็ยังมีโอกาสเจอปัญหาเดิม
- โค้ดพลาดเพราะตาม docs ไม่ทัน
- ต้นทุนบาน เพราะงาน background ไปแย่ง budget กับงาน interactive
- latency แปลกๆ เพราะ workload หลายแบบถูกรวมอยู่ใน lane เดียว
- reliability ไม่พอ เพราะระบบไม่ได้แยก critical traffic ออกจากงานที่รอได้
5) จุดที่น่าสนใจมากคือ Google มีตัวเลขรองรับ ไม่ได้พูดลอยๆ
ในโพสต์วันที่ 1 เม.ย. Google บอกว่าเมื่อใช้ Docs MCP และ Skills ร่วมกัน ผล eval ไปถึง 96.3% pass rate และใช้ 63% fewer tokens per correct answer เมื่อเทียบกับ vanilla prompting
ตัวเลขนี้สำคัญมากด้วย 2 เหตุผล
เหตุผลแรก มันไม่ได้บอกแค่ว่า answer ถูกขึ้น แต่มันบอกว่าระบบทำได้ถูกขึ้นด้วยต้นทุน token ที่มีประสิทธิภาพขึ้นด้วย
เหตุผลที่สอง มันชี้ให้เห็นว่าโครงสร้างรอบ model มี impact มากพอจะขยับทั้ง accuracy และ economics พร้อมกัน
เราเคยคุยกันเยอะเรื่อง model benchmark แต่ตัวเลขชุดนี้เตือนว่า benchmark ของโลก production อาจไม่ใช่ IQ ของ model อย่างเดียว แต่มันคือ IQ ของ workflow ทั้งระบบ
6) Flex กับ Priority ทำให้ทีมเริ่มวาง “lane” ของ agent ได้จริง
Google วางความแตกต่างไว้ชัดมาก
Flex inference
- ลดราคาได้ 50% เทียบกับ Standard API
- เหมาะกับ latency-tolerant workloads
- ยังเป็น synchronous interface ไม่ต้องจัดการ input/output files แบบ Batch API
- use cases ที่ Google ยกตัวอย่างคือ background CRM updates, large-scale research simulations และ agentic workflows ที่ให้ model browse หรือ think อยู่เบื้องหลัง
Priority inference
- เป็น tier ที่ให้ reliability สูงสุดสำหรับ critical apps
- ถ้าเกิน limit overflow requests จะถูก serve ที่ Standard tier แทน ไม่ใช่ fail ทิ้ง
- response จะบอกด้วยว่า request นั้นถูก serve ด้วย tier ไหน
- use cases ที่ Google ยกตัวอย่างคือ real-time customer support bots, live moderation และงานที่ time-sensitive
สำหรับคนทำ platform หรือ product ตรงนี้มีความหมายมาก เพราะมันเปิดทางให้คุณออกแบบ lane ของ agent ได้ชัดขึ้น
- lane ที่เน้น cost efficiency
- lane ที่เน้น business continuity
- lane มาตรฐานสำหรับงานทั่วไป
พอคิดแบบนี้ agent ไม่ได้เป็นก้อนเดียวอีกต่อไป แต่มันเริ่มกลายเป็น traffic portfolio ที่ต้องจัดการเหมือนระบบ production จริง
7) สิ่งที่ทีมไทยควรเอาไปทำต่อ ไม่ใช่แค่ติดตั้งของใหม่ แต่ต้องเปลี่ยนวิธีออกแบบ workflow
ถ้าอ่านสัญญาณจาก Google แบบ operator ผมคิดว่ามี 6 อย่างที่ควรทำต่อทันที
1) แยกงาน interactive กับ background ออกจากกัน
อย่าโยนทุกอย่างให้ agent stack เดียวรันเหมือนกันหมด สิ่งที่กระทบลูกค้าโดยตรงควรได้ reliability ที่สูงกว่า สิ่งที่รอได้ควร optimize cost
2) ต่อ agent เข้ากับ docs สดของระบบที่มันใช้จริง
ไม่ว่าจะเป็น API docs, internal runbooks, หรือ product policy ถ้า agent ยังคิดจาก snapshot เก่า คุณจะเสียเวลาแก้ซ้ำ
3) มอง skills เป็น operating manual ไม่ใช่ prompt snippet
skill ที่ดีควรบอก pattern, guardrails, reference และวิธีทำงานที่ทีมอยากให้เกิดซ้ำ มันคือ knowledge packaging ไม่ใช่แค่ text file
4) วัดคุณภาพพร้อมกับ economics
อย่าวัดแค่ว่าตอบได้หรือไม่ได้ ต้องดูด้วยว่า token cost ต่อ outcome, latency, retry rate และ fallback pattern เป็นยังไง
5) ออกแบบ graceful degradation ตั้งแต่ต้น
จุดที่ผมชอบใน Priority คือ overflow ไม่ fail ทิ้ง แต่กลับไป Standard ได้ แนวคิดนี้เอาไปใช้กับระบบ agent อื่นได้เลย อย่ารอให้ระบบล่มแล้วค่อยคิดเรื่อง fallback
6) เลิกคุยเรื่อง agent แบบ feature-by-feature อย่างเดียว
ปี 2026 ทีมที่ได้เปรียบจะไม่ใช่ทีมที่ลองของใหม่ไวที่สุดเสมอไป แต่คือทีมที่เอา feature เหล่านี้มาประกอบเป็น workflow ที่คุมต้นทุนและคุณภาพได้จริง
8) มุมมองของผม: ตลาดกำลังย้ายจาก model war ไปสู่ systems war
สิ่งที่ Google ทำสองวันติดกันนี้มีความหมายเชิงสัญญาณมาก
มันบอกว่า AI coding agents รอบต่อไปจะไม่ได้ชนะกันเพราะ model ตัวเดียวเก่งกว่า 3% หรือ 5% แต่มันจะชนะกันที่ว่าใครออกแบบระบบรอบ model ได้ดีกว่า
- ใครเชื่อม agent กับความรู้สดได้ดีกว่า
- ใครแพ็ก best practices เป็น skills ได้ reuse กว่า
- ใคร route traffic ตาม economics ของงานได้ฉลาดกว่า
- ใครทำ fallback และ visibility ได้ดีกว่า
ถ้าคุณมองตลาดแค่ระดับ feature update คุณอาจคิดว่า Google แค่ออก MCP, skills และ inference tiers แต่ถ้ามองระดับ operating model สิ่งที่เขากำลังทำคือเติมชิ้นส่วนที่ทำให้ agent เข้า production ได้จริงขึ้นมาก
และผมคิดว่านี่คือประเด็นที่คนทำธุรกิจควรสนใจ เพราะเมื่อ AI เริ่มเข้า workflow จริง คำถามสำคัญจะไม่ใช่แค่ว่า “มันตอบเก่งไหม” แต่จะกลายเป็น
- มันอัปเดตทันไหม
- มันคุมต้นทุนไหม
- มันนิ่งพอไหม
- และมันพังแบบรับมือได้ไหม
ใครควรจับตาเรื่องนี้เป็นพิเศษ
- ทีม dev ที่ใช้ AI coding tools ทุกวัน
- platform teams ที่ต้องคุมต้นทุน inference และ reliability
- founder ที่กำลังวาง AI copilot หรือ agentic workflow ให้ทีม
- enterprise teams ที่มีทั้งงาน background automation และงาน customer-facing อยู่ใน stack เดียว
- คนที่กำลังเถียงกันในทีมว่าจะลงทุนเพิ่มที่ model หรือควรลงทุนที่ workflow layer ก่อน
สรุป
Google เพิ่งส่งสัญญาณที่ชัดมากว่า AI coding agents ของจริง ต้องแก้ 2 เรื่องพร้อมกัน
เรื่องแรกคือ knowledge freshness ถ้า agent ยังทำงานจาก docs เก่า มันจะพลาดแม้ model จะฉลาดขึ้น
เรื่องที่สองคือ workload-aware runtime ถ้าคุณยังรันทุกงานบน economics แบบเดียวกัน ต้นทุนและ reliability จะเริ่มชนเพดานเร็ว
ดังนั้นคำถามของทีมในรอบนี้อาจไม่ใช่ “เราจะเปลี่ยนไปใช้ model ไหน” แต่ควรเป็น “เรามีระบบให้ agent ใช้ข้อมูลสด และวิ่งบน tier ที่เหมาะกับงานแล้วหรือยัง”
ถ้ายังไม่มี นี่อาจเป็นจังหวะที่ควรเริ่มแก้จาก workflow ก่อน model
FAQ
Q: แล้วเรื่องนี้เป็นข่าวใหม่จริงไหม? ใช่ในระดับต้นสัปดาห์นี้ เพราะ Google เผยแพร่โพสต์หลักสองชิ้นวันที่ 1 และ 2 เมษายน 2026 จาก official pages ที่ตรวจวันเผยแพร่แล้ว แต่ผมตั้งใจไม่เรียกว่าเพิ่งออกเมื่อคืน เพราะมันผ่านมาแล้วไม่กี่วัน
Q: ถ้าทีมไม่ได้ใช้ Gemini API โดยตรง ยังได้ประโยชน์ไหม? ได้ เพราะแก่นของเรื่องไม่ใช่ vendor เดียว แต่คือหลักคิดว่า coding agent ต้องมี docs สด, reusable skills และ serving lanes ที่ต่างกันตาม workload
Q: ทีมเล็กควรเริ่มจากอะไรก่อน? เริ่มจากการแยกงาน interactive กับ background ออกจากกัน และทำให้ agent เข้าถึง docs ล่าสุดของระบบที่มันต้องใช้ก่อน เรื่องนี้ให้ผลคุ้มกว่าการเปลี่ยน model แบบไม่มี workflow รองรับ
✍️ เนื้อหาและมุมมองโดย Arty | มี Espresso Bot ☕🤖 ช่วยรวบรวมข้อมูลและจัดเรียบเรียง