Mastra 1.42: เมื่อ AI Agent เริ่มเป็นระบบงานเบื้องหลัง ไม่ใช่แค่แชต

Mastra ปล่อย release @mastra/[email protected] วันที่ 12 มิถุนายน 2026

ถ้าอ่านแบบผ่าน ๆ อาจรู้สึกว่าเป็น changelog ของ framework สำหรับคนเขียน agent เท่านั้น

แต่ถ้าอ่านในมุม operator ข่าวนี้มีสาระสำคัญมากกว่านั้นครับ

เพราะหลายฟีเจอร์ใน release นี้ชี้ไปทางเดียวกัน:

AI Agent ที่ใช้งานจริงไม่ได้จบที่ prompt หรือการกด Run แต่ต้องมีชั้น workflow control รอบตัวมัน

1) จาก chatbot ไปสู่ background worker

ใน release นี้ Mastra เพิ่ม trusted “system actor” execution สำหรับ workflow, tool, memory และ agent

แปลเป็นภาษาคนคือ บางงานไม่ได้เริ่มจากมนุษย์นั่งกดปุ่มในหน้าแชตเสมอไป

งานอาจเริ่มจาก cron job, queue, scheduler, webhook หรือระบบหลังบ้านที่ต้องให้ agent ทำงานแทนในบริบทที่ชัดเจน

จุดสำคัญคือ agent ไม่ควรกลายเป็น “ผีในระบบ” ที่ทำงานโดยไม่มีตัวตน

มันต้องตอบได้ว่า:

• งานนี้รันในนามของใครหรือระบบไหน
• tenant หรือ organization ไหนเกี่ยวข้อง
• สิทธิ์อะไรใช้ได้ สิทธิ์อะไรใช้ไม่ได้
• ถ้ากลับมาตรวจย้อนหลัง จะรู้ไหมว่าใครสั่งให้เกิดงานนี้

สำหรับธุรกิจ เรื่องนี้ไม่ใช่ technical detail เล็ก ๆ ครับ

มันคือจุดเริ่มต้นของ accountability

ถ้า AI ส่งอีเมลผิดคน, เปิดข้อมูลผิดที่, แก้ไฟล์ผิด repository หรือกด action ผิด workflow เราต้องรู้ว่าเกิดจากงานไหนและภายใต้สิทธิ์ของใคร

2) Agent ที่ดีต้องรู้จักหยุดถามคน

อีกฟีเจอร์ที่น่าสนใจคือ native tool suspension สำหรับเครื่องมืออย่าง ask_user และ submit_plan

พูดง่าย ๆ คือ tool สามารถ pause งานไว้ เพื่อถามคนหรือขออนุมัติก่อนเดินต่อได้

นี่เป็นแนวคิดที่สำคัญมากสำหรับ AI ในธุรกิจ

เพราะงานจริงจำนวนมากไม่ได้ควรให้ AI ตัดสินใจจบเองทันที

ตัวอย่างเช่น:

• สรุป lead แล้วอยากส่ง follow-up เสนอราคา
• ตรวจ invoice แล้วเจอเลขที่น่าสงสัย
• เตรียม PR แก้ code ที่แตะระบบ production
• เขียนคำตอบลูกค้าเกี่ยวกับเงิน, refund หรือ policy
• ดึงข้อมูลจาก CRM แล้วจะส่งออกไปนอกระบบ

งานพวกนี้ agent อาจช่วยเตรียม, วิเคราะห์, draft หรือเสนอ plan ได้

แต่จุดสำคัญบางจุดควรมี human approval

ถ้า framework รองรับการ pause/resume เป็น primitive โดยตรง เราจะออกแบบ workflow ที่มี “เบรก” ได้เป็นธรรมชาติมากขึ้น

ไม่ใช่ปล่อยให้ agent วิ่งยาว แล้วค่อยตามแก้ทีหลัง

3) SignalProvider: agent ต้องฟังระบบจริง ไม่ใช่คุยคนเดียว

Mastra 1.42 ยังเพิ่ม SignalProvider framework สำหรับการต่อ signal เช่น webhook, polling และ subscription lifecycle

นี่คืออีกสัญญาณว่า agent กำลังเข้าใกล้ระบบปฏิบัติการจริงมากขึ้น

เพราะในงานจริง agent ไม่ได้ทำงานจาก prompt เดียวแล้วจบ

มันต้องรอ event จากระบบอื่น เช่น:

• ลูกค้ากรอกฟอร์มใหม่
• payment สำเร็จหรือ fail
• ticket เปลี่ยนสถานะ
• approval ถูกกดผ่าน
• ไฟล์ใหม่ถูกอัปโหลด
• webhook จากบริการภายนอกส่งข้อมูลกลับมา

ถ้าไม่มี signal layer ที่ออกแบบดี agent จะกลายเป็นระบบที่ต้องคอยปลุกด้วยมือ

แต่ถ้ามี signal ที่ชัด agent สามารถทำงานต่อจากเหตุการณ์จริงในธุรกิจได้

นี่คือความต่างระหว่าง “AI ที่ตอบเก่ง” กับ “AI ที่อยู่ใน workflow จริง”

4) Durable task state สำคัญกว่าที่หลายคนคิด

อีกจุดหนึ่งใน release คือ task tools กลายเป็น agent-agnostic และเก็บ state ใน threadState storage domain

ภาษาง่าย ๆ คือสถานะของงานควรอยู่ในชั้นที่ทนทานและนำกลับมาใช้ต่อได้ ไม่ใช่ติดอยู่กับ agent เฉพาะตัวหรือ session ชั่วคราว

ทำไมเรื่องนี้สำคัญ?

เพราะงานธุรกิจจำนวนมากไม่ได้จบใน 30 วินาที

บางงานใช้เวลาหลายชั่วโมง บางงานต้องรอคน approve บางงานต้องรอ API ภายนอก บางงานต้องแตกเป็น task ย่อย บางงานต้องกลับมาทำต่อหลังระบบ restart

ถ้า task state หายง่าย agent จะทำงานเหมือนเด็กฝึกงานที่จำไม่ได้ว่าทำถึงไหนแล้ว

แต่ถ้า state ถูกออกแบบดี เราจะเริ่มมี agent ที่รับงานต่อเนื่องได้มากขึ้น

ไม่ใช่แค่ assistant ที่ตอบเป็นรอบ ๆ

5) Tool hooks และ observability คือ proof layer

Mastra release นี้พูดถึง agent/workspace tool hooks และ PostgresStoreVNext สำหรับ observability domain ที่แยกชัดขึ้น

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

เวลา agent เรียก tool เราไม่ควรเห็นแค่ผลลัพธ์สุดท้าย

เราควรมีวิธีตรวจว่า:

• ก่อนเรียก tool มี input อะไร
• tool ไหนถูกเรียก
• ผลลัพธ์กลับมาอย่างไร
• ใช้เวลานานแค่ไหน
• เกิด error ตรงไหน
• มี policy หรือ approval อะไรเกี่ยวข้อง
• หลัง tool call ระบบเอาผลลัพธ์ไปทำอะไรต่อ

ถ้าไม่มี proof layer แบบนี้ AI workflow จะตรวจยากมาก

และพอใช้กับงานสำคัญ เช่น ลูกค้า, การเงิน, code, เอกสารภายใน หรือข้อมูลส่วนบุคคล ความเสี่ยงจะสูงขึ้นทันที

6) บทเรียนสำหรับธุรกิจไทย: อย่าออกแบบ agent เหมือน prompt เดี่ยว

ถ้าธุรกิจจะเริ่มใช้ AI Agent ผมแนะนำให้เริ่มจากคำถามเชิงระบบ ไม่ใช่เริ่มจาก prompt ก่อน

ลองถาม 7 ข้อนี้:

1. งานนี้เริ่มจากอะไร: คนกด, cron, webhook หรือ event จากระบบ
2. Agent ทำงานในนามใคร: user, team, tenant หรือ system actor
3. Tool ไหนเรียกได้: CRM, email, payment, database, GitHub หรือ file system
4. จุดไหนต้อง pause: เงิน, ลูกค้า, production, policy หรือข้อมูลอ่อนไหว
5. ถ้าข้อมูลไม่พอ agent ถามใคร
6. ถ้าระบบ restart งานกลับมาต่อได้ไหม
7. ถ้าเกิดปัญหา เรามี log และ proof พอไหม

ถ้ายังตอบไม่ได้ ไม่ได้แปลว่าห้ามใช้ AI ครับ

แต่แปลว่างานนั้นยังไม่ควรถูกปล่อยให้ agent วิ่งเองเต็มรูปแบบ

เริ่มจาก copilot mode, draft mode หรือ approval-first workflow ก่อนจะปลอดภัยกว่า

7) แล้ว Mastra 1.42 เกี่ยวกับ SME อย่างไร

หลายคนอาจคิดว่าเรื่องนี้ไกลตัว เพราะเป็น framework release

แต่ pattern นี้ใกล้กับงาน SME มากกว่าที่คิด

เช่น เจ้าของธุรกิจอยากให้ AI ช่วย:

• สรุปลูกค้าใหม่ทุกเช้า
• ติดตาม lead ที่ยังไม่ตอบ
• ตรวจ order ผิดปกติ
• สรุป comment และ inbox
• เตรียมรายงานยอดขายประจำวัน
• ดึงเอกสารแล้วร่างคำตอบให้ทีม

งานเหล่านี้ดูเหมือนง่าย แต่ถ้าจะให้ AI ทำจริงทุกวัน ต้องมีระบบควบคุมรอบตัว

เพราะสิ่งที่ต้องคุมไม่ใช่แค่ “คำตอบสวยไหม”

แต่คือ “ระบบนี้เชื่อถือได้แค่ไหนตอนเราไม่ได้นั่งเฝ้า”

นี่คือเหตุผลที่ Data-Espresso มักพูดว่า AI workflow ที่ดีควรมีทั้งคันเร่งและเบรก

คันเร่งคือ automation

เบรกคือ identity, permission, approval, log และ rollback

สรุป

ในความเห็นของผม Mastra 1.42 เป็น release ที่ควรอ่านแบบ operator มากกว่าอ่านแบบ feature list

เพราะมันสะท้อนทิศทางใหญ่ของ AI Agent ชัดมาก:

agent กำลังกลายเป็นคนทำงานในระบบ ไม่ใช่แค่กล่องแชตที่ตอบเก่ง

เมื่อ agent เข้าไปแตะงานจริง เราต้องออกแบบรอบตัวมันให้ครบ:

• มี actor identity
• มีจุด pause และ approval
• ฟัง signal จากระบบจริง
• เก็บ task state ให้ทน restart
• มี hook และ log สำหรับตรวจสอบ

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

แต่คือตัวที่ทำงานได้ในขอบเขตที่ธุรกิจควบคุม ตรวจสอบ และเชื่อใจได้