ข้ามไปยังเนื้อหา
Pydantic AI 2.14 ยก durability เป็น capability ระดับหนึ่ง — Temporal, DBOS, Prefect
เครื่องมือนักพัฒนา

Pydantic AI 2.14 ยก durability เป็น capability ระดับหนึ่ง — Temporal, DBOS, Prefect

อ่าน 5 นาที ที่มา: Pydantic AI (GitHub Releases)

Pydantic AI เฟรมเวิร์กสร้าง AI agent ยอดนิยมของฝั่ง Python ปล่อยเวอร์ชัน v2.14.0 เมื่อเช้าวันที่ 21 กรกฎาคม 2026 (01:15 UTC) โดยไฮไลต์สำคัญคือการยกระดับ durability — ความสามารถให้ agent รันแบบทนทานต่อการล่ม/รีสตาร์ท — ให้กลายเป็น “capability” ระดับหนึ่งของเฟรมเวิร์ก แทนรูปแบบ wrapper agent เดิมที่ถูกประกาศ deprecate

สำหรับทีมที่เอา agent ขึ้น production นี่คือการเปลี่ยนที่ควรรู้ เพราะ agent ที่เรียก LLM หลายรอบและมี tool call ยาว ๆ ต้องการกลไกที่ทำให้งานไม่หายเมื่อ process ตาย และรันต่อจากจุดเดิมได้ — เดิม Pydantic AI ให้ทำผ่านการห่อ agent ด้วยคลาสเฉพาะ ตอนนี้เปลี่ยนมาเป็นการประกาศ durability ตรง ๆ

จาก wrapper agent สู่ durability capability

v2.14.0 เพิ่มสาม capability ใหม่ (PR #4977 โดย DouweM):

  • TemporalDurability — ผูกการรัน agent เข้ากับ workflow engine ของ Temporal
  • DBOSDurability — ใช้ durable execution ของ DBOS
  • PrefectDurability — ใช้ orchestration ของ Prefect

ทั้งสามตัวเข้ามาแทน “wrapper agent” แบบเดิม (เช่นการห่อด้วย TemporalAgent) ที่ถูก deprecate การมองมันเป็น capability แทนที่จะเป็นการห่อ agent ทำให้โค้ดสะอาดขึ้นและสลับ backend การทำ durable execution ได้ง่ายกว่า — เลือกได้ว่าจะพึ่ง Temporal, DBOS หรือ Prefect ตามสแตกที่ทีมใช้อยู่ โดยไม่ต้องเปลี่ยนโครงสร้าง agent

แนวคิด durable agent กำลังเป็นหัวข้อร้อนของปีนี้ เพราะ agent ที่ทำงานยาว (long-running) แล้วต้อง retry, resume หรือ resume หลัง deploy ใหม่ เป็นปัญหาจริงที่หลายทีมเจอ การที่เฟรมเวิร์กหลักอย่าง Pydantic AI ทำให้มันเป็น first-class ก็ลดโค้ด glue ที่ต้องเขียนเองไปมาก

reasoning_effort สำหรับ Mistral

อีกฟีเจอร์คือการรองรับ reasoning_effort สำหรับโมเดล Mistral ผ่าน thinking settings (PR #5294 โดย YHallouard) ให้นักพัฒนาปรับ “ความลึกของการคิด” ของโมเดลได้ในระดับ API เดียวกับที่ Pydantic AI รองรับสำหรับผู้ให้บริการรายอื่นอยู่แล้ว — เป็นก้าวเล็ก ๆ ที่ทำให้การสลับผู้ให้บริการโมเดลใน codebase เดียวมี knob ควบคุมที่สม่ำเสมอขึ้น

ทำความสะอาดโมเดลที่ถูกปิด

รุ่นนี้ยังลบการรองรับโมเดล Gemini ที่ถูกปิดไปแล้วสองตัวออก (gemini-2.5-flash-lite-preview-09-2025 และ gemini-3.1-flash-lite-preview) เพื่อให้สอดคล้องกับไทม์ไลน์ deprecation ของ Google — เป็นการเก็บกวาดที่เตือนใจว่าโมเดล preview มีอายุ และควรตรึงเวอร์ชันโมเดลใน config ให้ชัด

มุมมอง AI Curator

ในบรรดางาน “agent framework” การเลือกใช้ตัวไหนมักไม่ได้ตัดสินกันที่ตอน prototype แต่ตัดสินกันที่ตอนขึ้น production — และ durability คือหนึ่งในข้อสอบที่โหดที่สุด agent ที่รันบน notebook สวยหรูอาจล่มทั้งงานเพียงเพราะ pod ถูก restart การที่ Pydantic AI ยก durability เป็น capability แล้วเปิดให้เสียบ Temporal/DBOS/Prefect ได้ตามสแตกเดิม เป็นทิศทางที่ถูก เพราะทีมส่วนใหญ่ไม่อยากผูกกับ orchestration ยี่ห้อเดียว

สำหรับทีมไทย/SEA ที่กำลังย้าย agent จาก POC ไป production ประเด็นที่ควรทำการบ้านคือ ต้นทุนการดำเนินงานของ durable execution: Temporal/DBOS/Prefect ต่างมีโมเดลการ deploy และค่าใช้จ่ายต่างกัน (self-host คลัสเตอร์ Temporal เองก็มีภาระดูแล ส่วน managed ก็มีค่าใช้จ่ายต่อเนื่อง) การที่เฟรมเวิร์กเปิดให้สลับได้ง่ายหมายความว่าเราเริ่มจากตัวที่เบาที่สุดก่อนแล้วค่อยขยับได้ — แต่ก็ต้องออกแบบให้ tool call เป็น idempotent ตั้งแต่แรก ไม่งั้น resume ทีก็ยิงซ้ำได้ นี่เป็นวินัยที่เฟรมเวิร์กช่วยได้แค่ครึ่งเดียว อีกครึ่งอยู่ที่การออกแบบของทีมเอง

แหล่งข่าว

บทความนี้เรียบเรียงจากแหล่งข่าวต้นทาง — Pydantic AI (GitHub Releases)

เนื้อหาบน blog นี้สร้างโดย AI โดยมีการกำกับบรรณาธิการจากมนุษย์

อ่านเพิ่มในหมวด เครื่องมือนักพัฒนา

Betelgeuse รัน Qwen3.8 Flash Next ขนาด 68GB บน RTX 3060 กับแรม 16GB ส่วน Basalt วัดให้เห็นว่าเอนจินที่เร่งด้วยแฟล็กลัดทำให้โมเดลลืมของ
เครื่องมือนักพัฒนา

Betelgeuse รัน Qwen3.8 Flash Next ขนาด 68GB บน RTX 3060 กับแรม 16GB ส่วน Basalt วัดให้เห็นว่าเอนจินที่เร่งด้วยแฟล็กลัดทำให้โมเดลลืมของ

Betelgeuse ฟอร์ก llama.cpp ที่เปิดเมื่อ 31 ต.ค. ดึง expert จาก NVMe เข้า VRAM ตามต้องการ อ้าง 22 tok/s แบบไม่ทิ้ง expert แต่ README เตือนเองว่ายังทดลองและตัวเลขมาจากคนละรอบ วันเดียวกันผู้พัฒนา Basalt เผยผลวัดว่าแฟล็กเร่งความเร็วทำคุณภาพ Q8 ตกไปใกล้ Q2

· อ่าน 5 นาที
กฎห้ามโคลนเกมของ Claude Code เริ่มกระทบงานจริง บริษัทรับทำเกมกระดานร้องงานลูกค้าหยุด แต่รายงานหลายชิ้นปนกับตัวกรองไซเบอร์คนละเรื่อง
เครื่องมือนักพัฒนา

กฎห้ามโคลนเกมของ Claude Code เริ่มกระทบงานจริง บริษัทรับทำเกมกระดานร้องงานลูกค้าหยุด แต่รายงานหลายชิ้นปนกับตัวกรองไซเบอร์คนละเรื่อง

ต่อจากที่เราพบกฎนี้ในไบนารี Claude Code ผู้ใช้เริ่มรายงานว่างานเชิงพาณิชย์ถูกปฏิเสธ และ Tom's Hardware กับ Mashable หยิบไปรายงาน แต่เมื่อไล่ issue ที่อ้างถึง พบว่าหลายรายการเกิดก่อนกฎจะมา จึงน่าจะเป็นตัวกรองด้านไซเบอร์ ส่วน Anthropic ยังไม่ชี้แจง

· อ่าน 4 นาที
Claude Code ส่ง transcript ของ background agent ให้โมเดลทุก ~30 วินาทีเพื่อเขียนสถานะ 3–5 คำ ผู้วัดรายงานกินราว 16% และยังปิดแบบทางการไม่ได้
เครื่องมือนักพัฒนา

Claude Code ส่ง transcript ของ background agent ให้โมเดลทุก ~30 วินาทีเพื่อเขียนสถานะ 3–5 คำ ผู้วัดรายงานกินราว 16% และยังปิดแบบทางการไม่ได้

รายงานอิสระพบว่าฟีเจอร์ agent_summary ของ Claude Code ส่ง transcript เต็มของ background agent ไปถามสถานะทุก ~30 วินาที คิดเป็น 16.4% ของค่าใช้จ่ายในระบบของผู้วัด Issue เปิดมาตั้งแต่ ส.ค. ยังไม่มีสวิตช์ปิดที่รองรับ เราตรวจพบโค้ดนี้ใน 2.1.314 และพบกฎใหม่เรื่องเกมที่ไม่อยู่ใน changelog

· อ่าน 4 นาที