Next.js กับยุค AI Agent: วิธีที่ Vercel พัฒนา Framework ให้รองรับ AI Agents

ในโลกของการพัฒนาเว็บยุคใหม่ที่ AI Agents กลายเป็นเครื่องมือสำคัญ Vercel ได้ใช้เวลาหนึ่งปีในการปรับปรุง Next.js ให้ทำงานได้ดีขึ้นกับ AI coding agents และได้เรียนรู้บทเรียนสำคัญมากมายที่นักพัฒนาทุกคนควรรู้

ปัญหา: AI Agents ไม่สามารถมองเห็น Browser ได้

ช่วงต้นฤดูร้อนที่ผ่านมา ทีม Next.js กำลังทำงานเกี่ยวกับ devtools และสังเกตเห็นรูปแบบที่น่าสนใจ นักพัฒนาจะเห็นข้อผิดพลาดใน browser จากนั้นคัดลอกรายละเอียด วางลงใน AI editor แล้วถาม agent ให้แก้ไข

ปัญหาคือ agents ไม่สามารถมองเห็น browser ได้ Runtime errors, client-side warnings และ rendered components ล้วนมองไม่เห็นสำหรับ agents เมื่อผู้ใช้พูดว่า "แก้ไขข้อผิดพลาด" agent ไม่รู้ว่าหมายถึงข้อผิดพลาดอะไร

การตอบสนองแรกคือการอัปเดตปุ่มคัดลอกให้จับข้อมูลข้อผิดพลาดในรูปแบบที่มีโครงสร้าง จากนั้นเพิ่มฟีเจอร์ที่ส่งต่อ browser logs ไปยัง terminal การแก้ไขเล็กๆ น้อยๆ เหล่านี้ชี้ไปที่ความเข้าใจที่ใหญ่กว่า พวกเขาต้องทำให้ Next.js เองมองเห็นได้สำหรับ agents

การทดลอง: In-browser Agent ชื่อ Vector

นั่นนำไปสู่ความคิดที่ทะเยอทะยาน ถ้าสร้าง agent โดยตรงใน Next.js ที่ทำงานเหมือน smart devtools ล่ะ?

พวกเขาสร้าง in-browser chat agent ชื่อ Vector คล้ายกับ react-grab แต่รวมเข้ากับ Next.js Vector ให้คุณเลือก elements บนหน้าเว็บ ดู source code และแจ้งเปลี่ยนแปลง มันมี best practices ของ Next.js ฝังอยู่เพื่อช่วย agents หลีกเลี่ยงการ hallucinate

lightbulb บทเรียนสำคัญ

Vector มีประโยชน์ แต่มันทับซ้อนกับ general coding agents เช่น Cursor และ Claude Code ที่นักพัฒนาส่วนใหญ่ใช้อยู่แล้วสำหรับทุกโปรเจกต์ ไม่ใช่แค่ Next.js

สุดท้ายพวกเขาตัดสินใจยกเลิก Vector แต่เอาสิ่งที่มีประโยชน์ (structured visibility และ framework-specific knowledge) ไปสร้างใน Next.js โดยตรง

MCP ทำให้ Next.js State มองเห็นได้สำหรับ Agents

รอบๆ Next.js v16 release ในเดือนตุลาคม 2025 ผู้ใช้กำลังต่อสู้กับการ debug ด้วย agents คำขอที่พบบ่อยคือ "แก้ไขข้อผิดพลาด" โดยให้ agents แก้ไขปัญหาจาก browser overlay แต่ agents จะขอ page HTML และไม่พบอะไรผิด

Runtime failures, browser JavaScript errors และ async errors อยู่ใน browser ไม่ใช่ใน HTML หน้าที่ render, layout segments, routes และ internal states อื่นๆ มองไม่เห็นสำหรับ agents

MCP (Model Context Protocol) ให้วิธีเปิดเผยข้อมูลนี้ เวอร์ชันแรกเปิดเผย internal states เช่น errors, routes และ rendered segments แต่การเปิดเผยข้อมูลอย่างเดียวไม่พอ Agents ยังต้องค้นหา dev servers ที่ทำงานอยู่และสื่อสารกับ它们 ซึ่งนำไปสู่ next-devtools-mcp

MCP ยังรวม prompts และ tools เพื่อช่วยกับ upgrades และ cache component migrations

คำตอบคือ: คิดเหมือน Agent

MCP ยืนยันสิ่งที่ Vector สอนไว้ Agents ต้องการ visibility ในสิ่งที่ Next.js ทำ แต่นั่นเป็นแค่ส่วนหนึ่งของเรื่อง บทเรียนที่ลึกซึ้งกว่าคือการปฏิบัติต่อ agents เป็น first-class users ของ Next.js และคิดจากมุมมองของพวกมัน ข้อมูลอะไรที่พวกเขาต้องการ? ต้องการเมื่อไหร่? พวกเขาใช้มันอย่างไร?

มุมมองนี้นำไปสู่การเปลี่ยนแปลงที่เป็นรูปธรรม:

ถ้า agents อ่าน terminal output ระหว่าง development การ log Server Action invocations และส่งต่อ browser errors ให้พวกเขาเป็นเบาะแสที่ต้องการ
ถ้า agents ต่อสู้กับ framework concepts ที่ไม่อยู่ใน training data ของพวกเขา การฝัง compressed docs index agents.md หรือให้ structured workflows (Next.js skills) ให้บริบทที่ดีกว่าเอกสารอย่างเดียว

อนาคต: การรวมเข้ากับ next dev

ตอนนี้พวกเขากำลังทำให้มันง่ายขึ้นสำหรับการ adopt คุณสามารถรัน npx @next/codemod เพื่อสร้าง docs index ที่อัปเดตแล้วสำหรับโปรเจกต์ของคุณ และพวกเขากำลังขยาย eval suite เพื่อครอบคลุม Next.js 16 APIs มากขึ้นเพื่อวัดว่าอะไรช่วย agents จริงๆ

ในระยะยาว พวกเขาต้องการให้มัน built-in เข้าไปใน next dev เพื่อให้ agents ได้รับ context ที่ถูกต้องโดยอัตโนมัติโดยไม่ต้องตั้งค่าอะไร

insights สรุป

เมื่อคุณปฏิบัติต่อ agents เป็น first-class users และพบพวกเขาที่พวกเขาอยู่ debugging กลายเป็น feedback loop ที่แน่นระหว่าง code, runtime และ AI