Vercel eve: เมื่อ AI Agent ต้องมีบ้าน ไม่ใช่แค่ prompt

Vercel เปิดตัว eve เป็น open-source framework สำหรับ building, running, และ scaling AI agents ใน production

ถ้าอ่านแบบผิวเผิน เรื่องนี้อาจดูเหมือนข่าว framework ใหม่อีกตัวหนึ่งในโลก agent ที่เริ่มแน่นขึ้นเรื่อย ๆ

แต่ถ้าอ่านแบบ operator ผมว่า signal ที่ใหญ่กว่าคือ:

AI Agent กำลังถูกจัดรูปใหม่ จาก prompt หรือ bot ตัวเดียว ไปเป็น “บ้านของงาน” ที่ตรวจสอบและรันซ้ำได้

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

ในโพสต์ทางการ Vercel อธิบายว่า eve เป็น framework สำหรับ production agents โดยมาพร้อม capability สำคัญ เช่น durable execution, sandboxed compute, human-in-the-loop approvals, subagents, evals, tracing, channels, schedules และ secure connections

ประโยคที่ผมว่าจับใจที่สุดคือแนวคิดว่า:

An agent is a directory

โครงสร้างตัวอย่างของ eve คือ agent หนึ่งตัวไม่ได้มีแค่ prompt แต่มี directory ที่ประกอบด้วยไฟล์และโฟลเดอร์ เช่น:

• instructions.md สำหรับ identity และ standing rules
• agent.ts สำหรับ model และ runtime config
• tools/ สำหรับ typed tools ที่ model เรียกใช้ได้
• skills/ สำหรับ playbook หรือ procedure ที่โหลดเมื่อเกี่ยวข้อง
• connections/ สำหรับเชื่อม MCP server หรือ API พร้อม auth broker
• channels/ สำหรับ Slack, Discord, web หรือ surface อื่น
• schedules/ สำหรับงานที่ต้องรันเป็นเวลา
• subagents/ สำหรับ delegation
• sandbox/ สำหรับ code/file execution ที่แยกจาก app runtime

นี่คือการเปลี่ยนมุมมองจาก “มี chatbot หนึ่งตัว” ไปเป็น “มี worker หนึ่งตัวที่มีบ้าน มีเครื่องมือ และมีขอบเขตงานชัดเจน”

2) ทำไมเรื่องนี้สำคัญกับธุรกิจ

หลายธุรกิจเริ่มใช้ AI Agent ด้วยความเร็วครับ

เริ่มจากให้ช่วยตอบลูกค้า ช่วยสรุปรายงาน ช่วยเขียน code ช่วยหา lead ช่วยแตะ CRM หรือช่วยทำ automation ระหว่างหลายระบบ

ช่วงแรกทุกอย่างดูง่าย เพราะยังเป็นงานทดลอง

แต่พอ agent เริ่มแตะของจริง ปัญหาที่เจอบ่อยไม่ใช่แค่ “model ฉลาดพอไหม”

ปัญหาจริงคือ:

• agent ตัวนี้มีสิทธิ์ทำอะไรบ้าง
• tool ไหนอ่านได้ tool ไหนเขียนได้
• credential ถูกเก็บและส่งต่ออย่างไร
• ข้อมูลไหนห้ามออกนอกระบบ
• งานไหนต้องให้คน approve ก่อน
• ถ้า agent ทำผิด มี log ให้ย้อนดูไหม
• ถ้า provider หรือ tool ล่ม มี fallback ไหม
• ใครเป็นเจ้าของ agent ตัวนี้ในบริษัท

ถ้าเปรียบง่าย ๆ AI Agent เหมือนพนักงานใหม่ที่ทำงานเร็วมาก

แต่ถ้าไม่มีโต๊ะ ไม่มี job description ไม่มีสิทธิ์เข้าออก ไม่มีหัวหน้าตรวจงาน และไม่มีประวัติการทำงาน เราจะเริ่มเสี่ยงทันทีที่ให้เขาแตะงานสำคัญ

3) บทเรียน operator: Agent ต้องมีบ้าน

สิ่งที่ eve สะท้อนชัดคือ production agent ไม่ควรถูกเก็บเป็น prompt ยาว ๆ ในหัวใครบางคน หรือ config กระจัดกระจายอยู่คนละที่

มันควรมีบ้านที่ทีมเปิดดูแล้วตอบได้ทันทีว่า:

• agent นี้คือใคร
• ทำงานอะไร
• ใช้ model อะไร
• เรียก tool อะไรได้
• เชื่อมระบบใดอยู่
• มีสิทธิ์ระดับไหน
• ต้องขอ approval ตอนไหน
• วัดคุณภาพอย่างไร
• deploy และ rollback อย่างไร

นี่คือเหตุผลที่ผมชอบแนวคิด filesystem-first ของ eve ไม่ใช่เพราะทุกธุรกิจต้องใช้ eve ทันที แต่เพราะมันทำให้ agent กลายเป็นสิ่งที่ audit ได้มากขึ้น

ทีมสามารถ review agent เหมือน review software project ได้ ไม่ใช่แค่คุยกันว่า “เดี๋ยว AI น่าจะทำให้”

4) อย่าอ่านเป็นข่าว framework อย่างเดียว

Vercel มีบริบทของตัวเองครับ เขาเป็น platform company และ eve ก็เชื่อมกับระบบของ Vercel เช่น AI Gateway, Vercel Sandbox, Vercel Workflows และ Vercel Connect

ดังนั้นถ้าเราอ่านแบบ vendor-neutral ต้องแยก fact กับ lesson ให้ชัด

Fact คือ Vercel เปิดตัว eve เป็น open-source framework และ repo ระบุ Apache-2.0 พร้อมสถานะ beta

Lesson คือ production agent stack กำลังมี pattern ที่ชัดขึ้น:

1. Identity layer: agent คือใคร และทำหน้าที่อะไร
2. Tool layer: agent เรียกเครื่องมืออะไรได้
3. Connection layer: agent เข้าระบบจริงผ่าน auth แบบไหน
4. Runtime layer: agent รันงานยาว ๆ ได้อย่างไร
5. Sandbox layer: agent แตะ file/code ได้แค่ไหน
6. Approval layer: งานเสี่ยงต้องหยุดรอคนตรงไหน
7. Evaluation layer: รู้ได้อย่างไรว่างานดีพอ
8. Observability layer: ย้อนดูได้ไหมว่าเกิดอะไรขึ้น

ถ้า framework หรือ platform ที่คุณใช้อยู่ไม่มีคำตอบเหล่านี้ แปลว่าเรายังไม่ได้มี production agent จริง ๆ เราอาจมีแค่ automation ที่เรียก LLM ได้

Operator Kit: Agent Home Spec Canvas

ก่อนให้ AI Agent แตะ workflow จริง ลองใช้ checklist นี้ครับ

A) Agent identity

• ชื่อ agent คืออะไร
• ใช้กับงานประเภทไหน
• ไม่ควรทำงานประเภทไหน
• ใครเป็น owner ทางธุรกิจ
• ใครเป็น owner ทาง technical

B) Tool and data boundary

• agent อ่านข้อมูลจากที่ไหนได้บ้าง
• agent เขียนหรือแก้ข้อมูลที่ไหนได้บ้าง
• tool ไหนเป็น read-only
• tool ไหนเป็น write / delete / money-moving action
• ข้อมูลประเภทใดห้ามส่งเข้า model หรือ external tool

C) Approval gate

ตั้งกฎง่าย ๆ ก่อนครับ:

• งานอ่านข้อมูลทั่วไป: agent ทำเองได้
• งานร่างข้อความ: agent ทำเองได้ แต่คนตรวจก่อนส่ง
• งานแก้ฐานข้อมูล / deploy / จ่ายเงิน / ส่งลูกค้า: ต้องมี human approval
• งานที่แตะ PII, finance, legal, HR: ต้องมี owner approve และมี log

D) Sandbox and runtime

• agent-generated code รันใน sandbox หรือรันบนเครื่องจริง
• sandbox มี network/file permission แค่ไหน
• session สามารถ pause/resume ได้ไหม
• ถ้า process ล่ม งานกลับมาต่อได้หรือเริ่มใหม่ทั้งหมด
• ถ้า provider timeout มี retry/fallback อย่างไร

E) Eval and proof

• งานของ agent ถูกวัดด้วย metric อะไร
• มี test case หรือ golden examples ไหม
• มี log ของ tool call และผลลัพธ์ไหม
• มี review loop หลังทำงานเสร็จหรือเปล่า
• ถ้าพลาด เราใช้ evidence อะไรในการแก้ policy หรือ prompt

F) Kill switch

คำถามนี้สำคัญมากครับ:

ถ้าพรุ่งนี้ agent ทำงานผิด เราปิดมันตรงไหน?

อย่างน้อยควรมี:

• owner ที่สั่ง pause ได้
• environment flag หรือ config ที่ปิด tool เสี่ยงได้
• fallback workflow ให้คนทำต่อได้
• audit trail ให้รู้ว่าก่อนปิด agent ทำอะไรไปแล้ว

5) ธุรกิจไทยควรเริ่มอย่างไร

ถ้าคุณยังไม่มี agent ใน production ไม่ต้องรีบกระโดดไปทำทุกอย่างพร้อมกัน

ผมแนะนำให้เริ่มจาก workflow ที่มี input และ output ชัด เช่น:

• สรุป lead ใหม่จากฟอร์ม แล้วร่าง follow-up ให้ทีมขายตรวจ
• สรุป ticket ลูกค้า แล้วจัดหมวดปัญหาเข้า CRM
• สรุป meeting แล้วสร้าง task draft ใน project management tool
• อ่านรายงาน sales รายวัน แล้วชี้ anomaly ให้คนตรวจ
• ตรวจ draft content ก่อนส่งออก public channel

เริ่มจากงานที่ agent อ่านเยอะ เขียนน้อย และมีคน approve ก่อนออกนอกบริษัท

จากนั้นค่อยเพิ่ม tool ที่มีผลกระทบสูงขึ้น เช่น update CRM, create invoice, deploy code หรือส่งข้อความจริง

สรุป

ในความเห็นของผม Vercel eve น่าสนใจไม่ใช่เพราะมันเป็น framework ใหม่เท่านั้น

แต่มันช่วยทำให้เราเห็นว่า AI Agent ที่เอาไปใช้จริงต้องมีโครงสร้างเหมือนระบบงาน ไม่ใช่แค่บทสนทนา

ธุรกิจที่เริ่มใช้ agent ควรเริ่มทำ inventory ของ agent ตั้งแต่วันนี้:

• ตัวไหนมีอยู่แล้ว
• แตะข้อมูลอะไร
• ใช้ tool อะไร
• ใคร approve
• วัดผลอย่างไร
• ปิดระบบตรงไหนถ้ามีปัญหา

สุดท้าย Agent ที่ดีไม่ใช่ตัวที่ตอบเก่งอย่างเดียวครับ

แต่คือตัวที่มีบ้าน มีขอบเขต มีหัวหน้าตรวจงาน และมีหลักฐานให้ทีมไว้ใจได้