สรุปจากคลิป ดูคลิปต้นฉบับ

Eval++ คืออะไร และทำไมอาจเป็นโครงสร้าง AI ตัวต่อไป

ประเด็นที่น่าสนใจที่สุดของ AI ตอนนี้ไม่ใช่แค่ model ไหนฉลาดกว่า แต่คือเราออกแบบ “ที่อยู่” ให้ AI agent อยู่ตรงไหนและทำงานต่อเนื่องอย่างไร ถ้าโครงสร้างข้างล่างยังคิดแบบ request เข้า ตอบกลับ แล้วจบ เราก็จะได้ agent ที่ฉลาดขึ้นนิดหน่อย แต่ยังเปราะ ใช้จริงลำบาก และต้องพึ่งงานวิศวกรรมจำนวนมากเพื่อเย็บทุกอย่างเข้าด้วยกัน

คลิปจากช่อง AI Engineer ที่ชวน Sunil Pai และ Matt Carey จากทีม Agents ของ Cloudflare มาคุยกัน ทำให้เห็นภาพชัดว่าโจทย์ใหญ่ของ AI agent ไม่ได้อยู่แค่เรื่อง prompt หรือเครื่องมือ แต่คือ compute primitive ที่เหมาะกับงานประเภทนี้จริงๆ แกนหลักของบทสนทนาคือ Durable Objects, Agents SDK และแนวคิดที่พวกเขาเรียกว่า Dynamic Workers หรือในมุมที่ชวนจำง่ายคือ Eval++

สำหรับเจ้าของธุรกิจและคนทำงานไทย ประเด็นนี้สำคัญมาก เพราะมันชี้ให้เห็นว่า AI ที่ใช้จริงในองค์กร ไม่ควรเป็นแค่ chatbot แยกเดี่ยว แต่ควรเป็นระบบที่จำสถานะได้ ทำงานต่อได้ เชื่อมหลายอุปกรณ์ได้ และสร้างความสามารถใหม่จากโค้ดที่ AI เขียนขึ้นได้ใน sandbox ที่คุมสิทธิ์ชัดเจน

สารบัญ

• Step 1: เริ่มจากเข้าใจก่อนว่า AI agent พังตรงไหนในโครงสร้างแบบเดิม
• Step 2: มอง Durable Objects เป็นบ้านของ agent ที่มีตัวตนจริง
• Step 3: ใช้ Agents SDK เพื่อลดงานประกอบระบบที่ไม่สร้างมูลค่า
• Step 4: เข้าใจ Dynamic Workers หรือ Eval++ ให้ถูก ว่ามันไม่ใช่แค่ eval แบบเสี่ยงๆ
• Step 5: มอง use case ที่ธุรกิจน่าจะได้ประโยชน์ก่อน ไม่ใช่เริ่มจากเทคโนโลยี
• Step 6: ใช้แนวคิดนี้กับ MCP และเครื่องมือองค์กรให้ฉลาดขึ้น
• Step 7: อย่ามองว่า AI ต้องเป็นเกมเล่นคนเดียวอีกต่อไป
• Step 8: เข้าใจข้อจำกัดจริงก่อนลงมือ อย่าคิดว่าเทคโนโลยีใหม่จะแก้ทุกอย่าง
• Actionable Insights
• Troubleshooting
• การต่อยอด
• สรุป Checklist ทั้งหมด

Step 1: เริ่มจากเข้าใจก่อนว่า AI agent พังตรงไหนในโครงสร้างแบบเดิม

ระบบ cloud สมัยใหม่ส่วนใหญ่ออกแบบด้วยแนวคิดง่ายๆ คือรับ request หนึ่งครั้ง แล้วส่ง response กลับไปหนึ่งครั้ง โมเดลนี้ดีมากสำหรับเว็บทั่วไป แต่พอเอามาใช้กับ AI agent จะเริ่มเห็นข้อจำกัดทันที

ตัวอย่างที่อธิบายง่ายมากคือ counter ถ้าเราเขียนตัวแปรนับจำนวนไว้ในหน่วยความจำของฟังก์ชัน มันอาจทำงานได้บนเครื่องตัวเอง แต่พอ deploy จริง state จะหาย เพราะแต่ละคำขอไม่ได้วิ่งกลับมาที่ instance เดิมเสมอ สุดท้ายเราต้องเพิ่ม database, session handling, replication และกลไกอื่นอีกมาก

ปัญหาเดียวกันนี้เกิดกับ AI agent เช่นกัน ไม่ว่าจะเป็นการคุยต่อเนื่อง, การจำงานค้าง, การ stream คำตอบต่อหลังหน้ารีเฟรช, หรือการ sync ระหว่างมือถือกับคอม ถ้าใช้ serverless แบบ stateless เพียวๆ งานเล็กจะกลายเป็นระบบกระจายศูนย์ขนาดย่อมทันที

มุมนี้น่าสนใจสำหรับธุรกิจไทยมาก เพราะหลายทีมเริ่มจากการต่อ AI เข้ากับเว็บหรือ LINE OA แบบเร็วๆ แล้วพออยากให้มัน “จำได้” หรือ “ทำงานต่อได้” ระบบจะซับซ้อนขึ้นรวดเร็ว ค่าใช้จ่ายไม่ได้อยู่ที่ token อย่างเดียว แต่ไปหนักที่ต้นทุนการประกอบระบบ

Step 2: มอง Durable Objects เป็นบ้านของ agent ที่มีตัวตนจริง

สิ่งที่ Cloudflare เสนอคือแนวคิด stateful serverless ผ่าน Durable Objects ฟังดูขัดกันนิดหน่อย แต่สาระคือมีหน่วยประมวลผลที่ผูกกับ ID หนึ่งๆ และ request หรือ WebSocket ที่เกี่ยวข้องจะวิ่งมาที่จุดเดิม ทำให้สิ่งนั้น “มีตัวตนต่อเนื่อง” มากกว่าฟังก์ชันที่เกิดแล้วหาย

ข้อดีของแนวทางนี้มีหลายข้อ

• agent มี state ที่คงอยู่ได้
• เชื่อมต่อแบบต่อเนื่องได้ง่าย
• ทำงานเบื้องหลังได้แม้ไม่มี request ใหม่เข้ามา
• พักตัวได้เมื่อไม่ใช้งานและกลับมาทำงานต่อได้
• ได้ latency ต่ำจากเครือข่าย edge ของ Cloudflare

คำว่า latency ต่ำอาจฟังเป็นเรื่องสายเทคนิค แต่ในเชิงธุรกิจมันแปลเป็นประสบการณ์ใช้งานที่ลื่นขึ้น โดยเฉพาะระบบที่ต้อง sync ข้อมูลแบบทันที เช่น AI assistant ในทีมขาย, ศูนย์บริการลูกค้า, หรือ agent ที่ช่วยวิเคราะห์เอกสารร่วมกันหลายคน

ถ้าเอามาเทียบกับการทำงานจริง Durable Objects ทำให้เราเริ่มคิดถึง agent ในฐานะ “พนักงานดิจิทัล” ที่มี memory, งานค้าง, ตารางเวลา และช่องทางติดต่อหลายแบบ ไม่ใช่แค่กล่องถามตอบ

Step 3: ใช้ Agents SDK เพื่อลดงานประกอบระบบที่ไม่สร้างมูลค่า

เมื่อมี compute unit ที่เหมาะแล้ว ชั้นถัดมาคือเครื่องมือสำหรับเอาไปใช้จริง Agents SDK ของ Cloudflare ถูกวางมาเพื่อช่วยเรื่องที่ทีมส่วนใหญ่มักต้องต่อเอง เช่น background jobs, scheduling, client callable functions และการเชื่อมกับฝั่ง UI

จุดที่น่าจำมากคือเรื่อง resumable streaming สมมติเราให้ AI สร้างรายงานยาวๆ แล้วเผลอรีเฟรชหน้า ถ้าเป็นระบบทั่วไป เราอาจต้องมานั่งออกแบบการบันทึก stream, เก็บตำแหน่งที่ค้าง, ทำ sticky session และ sync ข้ามแท็บเอง แต่ในโมเดลนี้ ถ้าตัว agent ยังทำงานอยู่ เรากลับมาเชื่อมต่อใหม่แล้วรับข้อมูลต่อได้เลย

นี่ไม่ใช่แค่ความสะดวก แต่เป็นความต่างระหว่าง demo กับ production เพราะประสบการณ์ใช้งานในโลกจริงเต็มไปด้วยการเปิดหลายแท็บ สลับอุปกรณ์ อินเทอร์เน็ตหลุด หรือหยุดงานกลางคัน

สำหรับองค์กรไทย ภาพการใช้งานที่ชัดคือ

• agent สรุปงานขายประจำสัปดาห์อัตโนมัติทุกคืนวันศุกร์
• agent อ่านเอกสารหลายแหล่งแล้วส่งสรุปให้ผู้จัดการตอนเช้า
• agent สนทนากับลูกค้าแล้วเปิดเคสค้างไว้ให้ทีมรับช่วงต่อได้
• agent ดึงข้อมูลจาก CRM, Notion, Google Drive แล้วรวมเป็น insight เดียว

สิ่งที่ทีมพูดไว้ชัดคือ เป้าหมายไม่ใช่ให้ทุกคนต้องกลายเป็นวิศวกร distributed systems แต่ทำให้ platform จัดการเรื่องยากๆ แทน นี่เป็นมุมที่เราเห็นด้วยมาก เพราะธุรกิจส่วนใหญ่ไม่ได้แพ้ที่ AI ไม่เก่ง แต่แพ้ที่ระบบรอบ AI ประกอบยากเกินไป

Step 4: เข้าใจ Dynamic Workers หรือ Eval++ ให้ถูก ว่ามันไม่ใช่แค่ eval แบบเสี่ยงๆ

หัวใจของคลิปอยู่ตรงนี้ Dynamic Workers คือ primitive ใหม่ที่ให้เรานำ “สตริงของโค้ด” ซึ่งอาจมาจากผู้ใช้ ลูกค้า หรือ LLM แล้วรันมันใน isolated worker แยกต่างหากได้ทันที โดยไม่ต้อง deploy แบบปกติ

ถ้าฟังเผินๆ หลายคนจะตกใจ เพราะวงการซอฟต์แวร์ถูกสอนมานานว่า eval เป็นของอันตราย แต่สิ่งที่ทีมนี้กำลังเสนอไม่ใช่การเปิดประตูให้โค้ดใดๆ วิ่งในระบบหลักแบบไร้การควบคุม ตรงกันข้าม พวกเขาเริ่มจาก sandbox ที่แทบไม่มีสิทธิ์อะไรเลย แล้วค่อยเติม capability เท่าที่อนุญาต

แนวคิดนี้สำคัญมาก

• โค้ดข้างในไม่มีสิทธิ์เรียก API อะไรก็ได้เอง
• ไม่มี environment variables หลุดเข้าไปโดยอัตโนมัติ
• การเชื่อมออกไปภายนอกควรถูก whitelist เป็นรายกรณี
• สามารถกำหนดได้ว่าเข้าถึงได้แค่ endpoint ที่อนุญาต

พูดง่ายๆ คือไม่ใช่การ “ปล่อยให้ AI เขียนอะไรก็ได้” แต่คือการ “ให้ AI เขียนความสามารถใหม่ภายใต้กรอบสิทธิ์ที่กำหนด”

มุมนี้ถ้าเอามาใช้กับธุรกิจไทย หน้าตาจะเป็นระบบที่ให้ AI สร้าง logic เฉพาะงานขึ้นได้ เช่น กติกาคำนวณโปรโมชั่น, เงื่อนไขการจัดกลุ่มลูกค้า, ขั้นตอนแปลงข้อมูลจากหลายแหล่ง หรือ UI ชิ้นเล็กที่ประกอบขึ้นตามคำสั่ง โดยไม่ต้องรอ dev deploy ทุกครั้ง

นี่คือจุดที่คำว่า Eval++ น่าคิดมาก เพราะมันเหมือนวงการกำลังกลับมาเปิดพื้นที่ให้ “โค้ดที่ถูกสร้างขึ้นระหว่างรันไทม์” อีกครั้ง แต่ในสภาพแวดล้อมที่ปลอดภัยกว่าเดิมมาก

Step 5: มอง use case ที่ธุรกิจน่าจะได้ประโยชน์ก่อน ไม่ใช่เริ่มจากเทคโนโลยี

ในคลิปมีตัวอย่างหนึ่งที่คมมาก คือแทนที่จะให้ AI สร้าง JSON เพื่อเอาไป render UI อีกที ทำไมไม่ให้มันสร้าง HTML หรือแม้แต่ React component ไปเลย แล้วค่อย render ใน sandbox ที่ไว้ใจได้

นี่สะท้อนปัญหาคลาสสิกของหลายองค์กร คือเรามักสร้างชั้นกลางเพิ่มเพื่อชดเชยข้อจำกัดของ platform เดิม ถ้ามี primitive ที่รองรับโค้ดที่ไม่น่าเชื่อถืออย่างปลอดภัย ชั้นกลางเหล่านั้นอาจไม่จำเป็นอีกต่อไป

ตัวอย่างการใช้จริงในธุรกิจ เช่น

• ระบบเสนอหน้า landing page เฉพาะลูกค้าแต่ละ segment
• แดชบอร์ดสรุปข้อมูลที่ AI ประกอบ widget ให้ตามโจทย์
• หน้าแบบฟอร์มที่ปรับโครงสร้างตามคำอธิบายงาน
• ปลั๊กอินภายในองค์กรที่ AI สร้าง logic ย่อยแล้วรันทันที

อย่างไรก็ดี ตรงนี้เราควรระวังไม่ให้หลงกับคำว่า generate code มากเกินไป เพราะในทางปฏิบัติ งานที่เหมาะที่สุดมักเป็นงานขอบเขตชัด มี capability จำกัด และตรวจผลลัพธ์ได้ ถ้าเป็นงาน core business ที่มีความเสี่ยงสูง เช่น คำนวณภาษี ตัดสินสินเชื่อ หรืออนุมัติธุรกรรม ยังต้องมี guardrail และการตรวจสอบโดยมนุษย์อย่างจริงจัง

Step 6: ใช้แนวคิดนี้กับ MCP และเครื่องมือองค์กรให้ฉลาดขึ้น

อีกประเด็นที่น่าสนใจคือ Durable Objects เหมาะกับการทำ MCP server เพราะ MCP รุ่นแรกต้องการการเชื่อมต่อแบบ stateful ระหว่าง client และ server ซึ่งมักเป็นเรื่องน่าปวดหัวตอนเอาขึ้น production

ถ้าโครงสร้างรองรับ stateful connection ตั้งแต่ต้น งานพวกนี้จะง่ายขึ้นมาก และนั่นนำไปสู่แนวคิดใหญ่กว่า คือ agent ที่ไม่ได้แค่เรียก tool แบบคงที่ แต่สามารถ “สร้างทักษะใหม่” ผ่านโค้ดที่รันใน sandbox ได้

ในทางธุรกิจ สิ่งนี้อาจแปลเป็น

• agent ที่เชื่อมกับระบบภายในจำนวนมากโดยไม่ต้องยัดทุก endpoint เข้า prompt ตรงๆ
• agent ที่รับงานใหม่แล้วสร้าง routine ย่อยขึ้นเอง
• agent ที่ขยายความสามารถผ่าน extension หรือ plugin แบบปลอดภัยกว่าเดิม

ทีมยังพูดถึงไอเดียการย่อ API จำนวนมหาศาลให้ agent เข้าถึงได้ใน token ที่น้อยลง ซึ่งชี้ให้เห็นปัญหาหนึ่งที่เจ้าของธุรกิจควรสนใจ คือ AI ไม่ได้ติดแค่ความฉลาด แต่ติด “ต้นทุนการเข้าถึงระบบ” ด้วย ยิ่งโครงสร้างเครื่องมือซับซ้อน context ก็ยิ่งเปลือง และเปลืองทั้งค่าใช้จ่ายกับความแม่นยำ

ถ้าอยากตามแนวคิด MCP เพิ่มเติม สามารถอ่านมาตรฐานได้ที่ Model Context Protocol

Step 7: อย่ามองว่า AI ต้องเป็นเกมเล่นคนเดียวอีกต่อไป

อีกมุมที่น่าคิดต่อสำหรับคนทำงานคือความคิดที่ว่า AI ควรเป็น multiplayer experience มากกว่าเป็นหน้าต่างแชตของใครคนใดคนหนึ่ง

ถ้าเรายอมรับว่า agent มี state มีที่อยู่ และ sync ข้ามอุปกรณ์ได้ คำถามใหม่จะเกิดขึ้นทันที เช่น ทำไมแชตเดียวกันถึงแชร์ให้ทีมเข้ามาทำงานร่วมกันไม่ได้ ทำไมผู้จัดการกับทีมขายถึงใช้ agent ตัวเดียวกันในเคสลูกค้ารายเดียวกันไม่ได้ หรือทำไมงานที่เริ่มบนมือถือถึงไม่ต่อบนโน้ตบุ๊กแบบไร้รอยต่อ

สำหรับธุรกิจไทย นี่คือมุมที่มีโอกาสสูงมาก เพราะหลายองค์กรยังใช้ AI แบบส่วนตัว ใครใช้ใครได้ประโยชน์ แต่ความรู้ไม่ไหลกลับเข้าทีม ถ้า agent กลายเป็น asset กลางที่หลายคนเชื่อมได้ งานจะเปลี่ยนจาก productivity ส่วนบุคคล เป็น productivity ระดับทีม

แนวคิดนี้คล้ายกับการเปลี่ยนจากเอกสารเดี่ยวไปสู่ Google Docs เมื่อก่อนเราแก้ไฟล์กันทีละคน เดี๋ยวนี้เราคาดหวังการร่วมมือแบบทันที AI ก็น่าจะเดินไปทางนั้นเช่นกัน

Step 8: เข้าใจข้อจำกัดจริงก่อนลงมือ อย่าคิดว่าเทคโนโลยีใหม่จะแก้ทุกอย่าง

แม้ไอเดียของ Eval++ จะน่าตื่นเต้น แต่ก็มีข้อจำกัดที่เราควรมองให้ตรง

• โค้ดที่ LLM สร้างยังผิดได้ และผิดแบบคาดเดายาก
• sandbox ที่ปลอดภัยต้องออกแบบ capability อย่างรอบคอบ
• งานที่มีความเสี่ยงสูงต้องมีขั้นตรวจซ้ำ
• ทีมที่ไม่ชัดเรื่อง process อาจได้ระบบใหม่ที่ยิ่งซับซ้อนกว่าเดิม
• ภาษาและ ecosystem ยังมีความต่าง โดยตอนนี้ JavaScript และ Python เด่นที่สุด

ในคลิปมีการพูดถึงภาษาอื่นผ่าน WebAssembly ด้วย ซึ่งสะท้อนว่าระบบกำลังขยายไปได้กว้างขึ้น แต่สำหรับคนทำธุรกิจ ประเด็นไม่ใช่จะใช้ภาษาอะไรเป็นหลัก ประเด็นคือเราจะออกแบบ capability ของ agent อย่างไรให้ปลอดภัยและคุ้มค่า

ถ้าอยากอ่านแนวคิดเรื่อง sandbox และ isolates เพิ่มเติม งานของ Cloudflare Workers ช่วยให้เห็นภาพโครงสร้างนี้ได้ดี

Actionable Insights

• เริ่มจาก workflow ที่ต้องจำสถานะ เช่น งานบริการลูกค้า งานขาย หรือการตามเอกสาร ไม่ใช่เริ่มจาก chatbot ทั่วไป
• แยก capability ของ agent เป็นชุดเล็กๆ เช่น อ่านไฟล์, สรุปข้อมูล, เรียก CRM, ส่งอีเมล เพื่อควบคุมความเสี่ยงได้ง่าย
• ออกแบบให้คุยต่อได้ข้ามอุปกรณ์ ถ้า AI ใช้จริงในงาน มันควรต่อเนื่อง ไม่ใช่เริ่มใหม่ทุกครั้ง
• ใช้ AI สร้าง logic ย่อยก่อนสร้างระบบใหญ่ เช่น กติกาจัดหมวดหมู่หรือ UI ชิ้นเล็ก แทนการปล่อยให้มันควบคุมงานหลักทั้งหมด
• วัดมูลค่าจากเวลาที่ทีมประหยัดได้ ไม่ใช่วัดแค่จำนวน prompt หรือความเก่งของ model

Troubleshooting

• ปัญหา: AI คุยไม่ต่อเนื่อง รีเฟรชแล้วเหมือนเริ่มใหม่

สาเหตุ: ระบบยังออกแบบแบบ stateless เป็นหลัก

วิธีแก้: ย้ายงานที่ต้องมี memory ไปอยู่ในหน่วยประมวลผลที่เก็บ state ได้ และออกแบบ session ให้ reconnect ได้

• ปัญหา: agent ทำงานได้ใน demo แต่ใช้จริงแล้วซับซ้อนมาก

สาเหตุ: ต้องต่อ database, sync, scheduling และ background jobs เองทั้งหมด

วิธีแก้: เลือก platform ที่มี primitive พวกนี้มาให้ตั้งแต่ต้น แล้วค่อยพัฒนาตรรกะธุรกิจด้านบน

• ปัญหา: กลัวให้ AI สร้างโค้ดเพราะเสี่ยงเกินไป

สาเหตุ: มองการรันโค้ดเป็น all or nothing

วิธีแก้: ใช้ sandbox แบบ capability-based ให้สิทธิ์เฉพาะที่จำเป็น และเริ่มจากงานความเสี่ยงต่ำก่อน

• ปัญหา: context ยาวเกิน token สูงเกินโดยเฉพาะเวลาต่อหลายระบบ

สาเหตุ: ยัดคู่มือเครื่องมือหรือ API ทั้งหมดเข้าไปใน prompt

วิธีแก้: แยก tool ให้เป็น abstraction ที่เล็กลง หรือให้ agent สร้างโค้ดเรียกความสามารถเฉพาะจุดแทน

• ปัญหา: ทีมใช้ AI คนละตัว ข้อมูลไม่เชื่อมกัน

สาเหตุ: มอง AI เป็นเครื่องมือส่วนบุคคล ไม่ใช่ระบบร่วมกัน

วิธีแก้: ออกแบบ agent กลางสำหรับทีม พร้อมสิทธิ์เข้าถึงและประวัติงานร่วมกัน

การต่อยอด

• สร้าง agent ประจำทีมขายที่สรุปลูกค้าแต่ละรายและ sync สถานะระหว่างมือถือกับคอม
• สร้างระบบ plugin ภายในองค์กรที่ AI เขียน logic ย่อยได้เองใน sandbox
• ทดลอง generative UI สำหรับหน้าเสนอข้อมูลลูกค้า หรือหน้า dashboard เฉพาะ role

สรุป Checklist ทั้งหมด

• ☐ ระบุงานที่ agent ต้องจำ state และทำงานต่อเนื่อง
• ☐ แยกความต่างระหว่าง chatbot ธรรมดากับ agent ที่มีตัวตนต่อเนื่อง
• ☐ วางโครงสร้างให้รองรับ reconnect, streaming และ multi-device sync
• ☐ ใช้ scheduling และ background execution กับงานประจำ
• ☐ กำหนด capability ของ agent เป็นรายการชัดเจน
• ☐ ทดลองให้ AI สร้างโค้ดเฉพาะงานย่อยใน sandbox
• ☐ เริ่มจาก use case ที่มีขอบเขตและความเสี่ยงต่ำ
• ☐ ออกแบบ AI ให้ใช้ร่วมกันในทีม ไม่ใช่แค่รายบุคคล
• ☐ วัดผลจากเวลาที่ประหยัดได้ คุณภาพงาน และความต่อเนื่องของ workflow
• ☐ ตรวจ guardrail ก่อนขยายไปสู่งานสำคัญของธุรกิจ

สรุปแล้ว สิ่งที่คลิปนี้พยายามชี้ไม่ใช่แค่ว่า Cloudflare มีของใหม่ แต่คือการตั้งคำถามกับวิธีสร้างระบบ AI ทั้งชุด ถ้าเราเชื่อว่าระยะถัดไปของซอฟต์แวร์คือผู้ใช้และ agent ต่างก็เขียนโค้ดได้ โครงสร้างแบบ stateless เดิมอาจไม่พออีกต่อไป Durable Objects ทำหน้าที่เป็นบ้านของ agent ส่วน Dynamic Workers หรือ Eval++ เปิดทางให้ AI สร้างความสามารถใหม่ใน sandbox ที่คุมสิทธิ์ได้

สำหรับคนทำธุรกิจ ประเด็นสำคัญที่สุดไม่ใช่ชื่อเทคโนโลยี แต่คือวิธีคิดใหม่ว่า AI ที่ใช้จริงต้อง “อยู่เป็น” ไม่ใช่แค่ “ตอบเป็น” และเมื่อมันอยู่เป็น จำได้ เชื่อมหลายช่องทางได้ และสร้างทักษะใหม่ได้ เราก็เริ่มเข้าใกล้ agent ที่มีมูลค่าทางธุรกิจจริงมากขึ้น