ห้องควบคุมมืดที่มีแขนกลจับบัตรสีขาวยื่นไปหน้ากล้องบนขาตั้ง ข้างม้วนเทปบันทึกโลหะ เหมือนการตรวจว่าอะไรถูกบันทึกเก็บไว้

Pydantic AI 2.58.0 มาแล้ว อุดช่องโทเคนหลุดในบันทึกและแชตสั่งเครื่องมือ

น้องกายEngineering

Pydantic AI 2.58.0 แก้ปัญหาความปลอดภัยระดับปานกลาง 2 เรื่อง ทั้งข้อมูลลับที่อาจติดไปกับบันทึกการทำงาน และหน้าแชตที่อาจทำให้เครื่องมือทำงานโดยไม่มีคำขอไปยังโมเดล AI ครับ (GitHub Release) สำหรับคนใช้แชตช่วยงาน ประเด็นที่ควรสนใจจึงอยู่หลังหน้าจอด้วยว่า ระบบเก็บความลับไว้ตรงไหน และตรวจสิทธิ์ก่อนลงมือทำงานจริงหรือเปล่า

แพ็กเกจ 2.58.0 ถูกอัปโหลดขึ้น PyPI ซึ่งเป็นแหล่งแจกจ่ายแพ็กเกจภาษา Python วันนี้ 20 ตุลาคม 2026 เวลาไทย 12:25 น. ส่วนรุ่นสายเดิม 1.107.8 ตามมาเวลา 12:39 น. โดยหน้าโครงการระบุรุ่นล่าสุดเป็น 2.58.0 และต้องใช้ Python ตั้งแต่ 3.11 ขึ้นไป (PyPI) คนดูแลระบบจึงมีรุ่นแก้ไขให้ตรวจสอบแล้ว แต่การอัปเดตอย่างเดียวอาจยังไม่จบ หากข้อมูลลับเคยเข้าไปอยู่ในบันทึกเก่า

สรุป 30 วินาที: เกิดอะไรขึ้น

Pydantic AI เป็นเฟรมเวิร์กสำหรับสร้าง AI agent หรือระบบ AI ที่เชื่อมเครื่องมือเพื่อทำงานได้ โดยหน้า PyPI อธิบายโครงการว่าเป็น AI Agent Framework (PyPI) รอบนี้มีทั้งคุณสมบัติใหม่และประกาศความปลอดภัยที่ควรอ่านก่อนเปิดใช้กับงานจริง ดังนี้

  • บันทึกอาจมีข้อมูลลับ: เมื่อเปิดระบบบันทึกคำขอ การเชื่อม MCP บางแบบอาจส่งที่อยู่เซิร์ฟเวอร์ โทเคนยืนยันสิทธิ์ และค่าข้อมูลกำกับคำขอไปอยู่ในบันทึก แม้ตั้งค่าไม่เก็บเนื้อหาแล้ว แก้ใน 2.58.0 และ 1.107.8 (GitHub Release)
  • หน้าแชตอาจข้ามการตัดสินใจของโมเดล: ตัวเชื่อม Vercel AI และ AG-UI อาจเรียกเครื่องมือที่มีอยู่ด้วยข้อมูลที่ฝั่งผู้ใช้กำหนด ภายใต้เงื่อนไขที่ประกาศระบุ แก้ใน 2.58.0 ส่วนสายรุ่น 1 ไม่ได้รับผลจากปัญหานี้ (GitHub Release)
  • มีตัวคุมเวลาและการลองซ้ำ: รุ่นใหม่เพิ่มการจำกัดเวลาทั้งงานและแต่ละคำขอ รวมถึงจำนวนครั้งที่ชุดเชื่อมบริการลองส่งคำขอใหม่ และมีคำเตือนเมื่อโมเดลไม่รองรับค่าบางอย่าง (GitHub Release)

ทำไมเรื่องนี้เกี่ยวกับคุณ

พนักงานออฟฟิศ นักเรียน ผู้ปกครอง หรือเจ้าของร้านที่ใช้แชตช่วยงาน ไม่จำเป็นต้องจำชื่อไลบรารีนี้ทั้งหมด แต่ควรแยกให้ออกว่า “AI ตอบข้อความ” กับ “AI เรียกเครื่องมือ” มีผลต่อการตรวจสิทธิ์ต่างกัน ประกาศรอบนี้ชี้ว่ามีเส้นทางเรียกเครื่องมือที่ข้ามคำขอไปยังโมเดล และมาตรการที่วางไว้เฉพาะก่อนหรือหลังคำขอโมเดลจะไม่เห็นการเรียกนั้น (GitHub Advisory: UI adapters)

สำหรับเจ้าของธุรกิจที่ให้ทีมพัฒนาทำผู้ช่วย AI ใช้งานเอง ผมแนะนำให้ส่งข่าวนี้ให้คนดูแลระบบตรวจว่าใช้ Pydantic AI หรือไม่ แล้วตรวจต่อว่าเปิดบันทึกและเชื่อมหน้าแชตแบบใด อย่าสรุปว่าทุกระบบได้รับผล เพราะประกาศเรื่องหน้าแชตมีเงื่อนไขหลายข้อร่วมกัน ส่วนประกาศเรื่อง MCP ก็แยกชนิดการเชื่อมที่มีปัญหากับชนิดที่ไม่อยู่ในเส้นทางดังกล่าวไว้ชัดเจน (GitHub Advisory: UI adapters, GitHub Advisory: MCP)

ธุรกิจในไทยที่ใช้ส่วนประกอบเหล่านี้ก็ควรเช็กครับ แต่แหล่งข้อมูลชุดนี้ไม่ได้ระบุว่ามีองค์กรไทยได้รับผลหรือมีผู้ใช้ไทยกี่ราย จึงยังบอกขนาดผลกระทบในไทยไม่ได้

ทำงานยังไง

MCP คือวิธีเชื่อมระบบ AI เข้ากับเครื่องมือภายนอก ส่วน telemetry คือข้อมูลที่ระบบเก็บเพื่อสังเกตการทำงาน และ trace คือบันทึกที่ช่วยตามดูว่าคำขอหนึ่งผ่านส่วนใดบ้าง ในประกาศนี้ระบบบันทึกที่เกี่ยวข้องคือ OpenTelemetry รวมถึงกรณีใช้ Temporal พร้อมการบันทึกผ่าน LogfirePlugin (GitHub Advisory: MCP)

นึกถึง กล้องวงจรปิดที่บันทึกการทำงานของแอป ถ้ามันถ่ายติดรหัสผ่านบนกระดาษ ใครดูเทปก็เห็น การบอกว่าไม่ต้องเก็บเนื้อหาไม่ได้รับประกันว่าข้อมูลกำกับงานจะไม่มีความลับ ปัญหารอบนี้คือที่อยู่บริการ โทเคนซึ่งใช้ยืนยันสิทธิ์ และค่าหัวข้อความกำกับคำขออาจเข้าไปอยู่ใน trace ได้ แม้ปิดการเก็บเนื้อหาไว้ ผู้ที่เข้าถึงบันทึกที่ได้รับผลจึงอ่านค่าที่เปิดเผยนั้นได้ (GitHub Advisory: MCP)

อีกกรณีหนึ่งเกี่ยวกับชื่อระบุการเชื่อมต่อที่ระบบสร้างจากที่อยู่บริการ หากที่อยู่นั้นมีข้อมูลลับอยู่ ข้อมูลลับก็อาจติดไปกับชื่อในบันทึกด้วย สายรุ่น 1 ใช้การเชื่อม MCP ผ่านผู้ให้บริการเป็นค่าเริ่มต้นเมื่อโมเดลรองรับ ขณะที่สายรุ่น 2 ใช้การเชื่อมภายในเป็นค่าเริ่มต้น อย่างไรก็ตาม ประกาศยังอธิบายความเสี่ยงจากชื่อที่สร้างตามที่อยู่ในกรณีเชื่อมภายในไว้ด้วย จึงไม่ควรใช้แค่คำว่า “ค่าเริ่มต้นเปลี่ยนแล้ว” มาตัดสินว่าปลอดภัย (GitHub Advisory: MCP)

ปัญหาหน้าแชตเป็นคนละส่วน ตัวเชื่อมหรือ adapter คือส่วนแปลงข้อมูลระหว่างหน้าจอแชตกับระบบ agent เมื่อระบบมีประวัติข้อความฝั่งเซิร์ฟเวอร์ที่ไม่ว่าง และใช้การจัดการคำสั่งระบบโดยเซิร์ฟเวอร์ซึ่งเป็นค่าเริ่มต้น ลำดับการจัดการประวัติในรุ่นที่มีปัญหาอาจเปิดทางให้เครื่องมือถูกเรียกโดยไม่ผ่านคำขอโมเดล รุ่นแก้ไขปรับลำดับการจัดการข้อมูลประวัติแล้ว (GitHub Advisory: UI adapters)

ขอบเขตยังสำคัญครับ การเรียกดังกล่าวเข้าถึงได้เฉพาะเครื่องมือที่ agent มีอยู่ และข้อมูลที่ส่งเข้าเครื่องมือยังถูกตรวจตามรูปแบบข้อมูลที่เครื่องมือกำหนด เครื่องมือที่ต้องขออนุมัติไม่ถูกเรียกผ่านเส้นทางนี้ ส่วนการตรวจสิทธิ์ในตัวเครื่องมือและการตรวจทันทีก่อนเครื่องมือทำงานยังมีผลอยู่ (GitHub Advisory: UI adapters) การตรวจว่าข้อมูลถูกชนิดจึงต้องอ่านแยกจากการตรวจว่าผู้ใช้มีสิทธิ์ทำสิ่งนั้นหรือไม่

จุดหักมุม: ปิดเก็บเนื้อหาแล้ว ความลับก็ยังอาจอยู่ในบันทึก

จุดที่ผมอยากให้ทีมพัฒนาหยุดอ่านคือ การตั้งค่าไม่เก็บเนื้อหาไม่ได้กันปัญหา MCP รอบนี้ เพราะข้อมูลลับอาจมากับการตั้งค่าการเชื่อมต่อและชื่อระบุงาน แหล่งข่าวระบุเรื่องนี้โดยตรง พร้อมแนะนำให้จำกัดคนเข้าถึงบันทึกย้อนหลังและเปลี่ยนข้อมูลรับรองที่เคยถูกเปิดเผย (GitHub Advisory: MCP)

อีกจุดคือ AI ไม่จำเป็นต้องได้เห็นคำขอทุกครั้งก่อนเครื่องมือทำงาน สำหรับช่องโหว่หน้าแชตนี้ โมเดลไม่มีโอกาสปฏิเสธ และตัวตรวจที่ผูกกับคำขอโมเดลก็ไม่เห็นเหตุการณ์ แต่ตัวตรวจที่อยู่ก่อนเครื่องมือทำงานยังทำหน้าที่ได้ (GitHub Advisory: UI adapters) ผมจึงอ่านข่าวนี้เป็นเหตุผลให้ตรวจตำแหน่งที่บังคับสิทธิ์ด้วย ไม่ใช่อ่านเพียงว่ามีรุ่นใหม่ให้ติดตั้ง

เรื่องเงิน / ผลกระทบ

แหล่งข้อมูลไม่ได้รายงานจำนวนผู้เสียหาย มูลค่าความเสียหาย หรือค่าใช้จ่ายแก้ระบบ จึงยังตีเป็นเงินบาทไม่ได้ ผลกระทบที่ยืนยันได้ตามประกาศคือค่าลับอาจถูกอ่านโดยคนที่เข้าถึง trace และเครื่องมือบางชนิดอาจทำงานข้ามการตัดสินใจของโมเดลภายใต้เงื่อนไขที่ระบุ (GitHub Advisory: MCP, GitHub Advisory: UI adapters)

ในทางวางแผนงาน ผมแนะนำให้เผื่อเวลาสำหรับตรวจบันทึก เปลี่ยนข้อมูลรับรอง และทดสอบระบบหลังอัปเดตด้วย การเปลี่ยนโทเคนควรตามผลตรวจว่าค่าใดถูกเปิดเผย ไม่ควรถือว่าลงแพ็กเกจใหม่แล้วข้อมูลในบันทึกเก่าหายไป เพราะคำแนะนำของผู้ดูแลโครงการยังให้จัดการทั้งบันทึกย้อนหลังและข้อมูลรับรองแยกกัน (GitHub Advisory: MCP)

ด้านการคุมเวลางาน รุ่นใหม่เพิ่มเวลาสูงสุดสำหรับการทำงานของ agent ทั้งรอบ พร้อมข้อมูลเส้นตายผ่าน RunContext.deadline เพิ่มการกำหนดจำนวนครั้งที่ชุดเชื่อมบริการลองคำขอซ้ำ และเวลาสูงสุดของคำขอโมเดลหนึ่งครั้งซึ่งครอบคลุมทุกความพยายามและการรับผลแบบทยอยส่ง (GitHub Release) สำหรับทีมทำงาน นี่เป็นตัวเลือกให้กำหนดกรอบการรออย่างชัดเจน แต่แหล่งข้อมูลไม่ได้ให้ผลทดสอบว่าลดค่าใช้จ่ายหรือเพิ่มความเร็วได้เท่าไร

ยังมี UnsupportedSettingWarning ซึ่งเป็นคำเตือนเมื่อโมเดลละเลยค่าที่ไม่รองรับ เช่น การจำกัดเวลาหรือจำนวนครั้งที่ลองซ้ำ และเพิ่มตัวเชื่อม openai-chatgpt ให้ผู้ใช้แอปลงชื่อเข้าใช้ด้วย ChatGPT แล้วใช้แผนของตัวเอง (GitHub Release) รายละเอียดราคาในไทย เงื่อนไขแผนที่ใช้ได้ และขอบเขตความพร้อมใช้งานไม่ได้อยู่ในข้อมูลชุดนี้ จึงไม่ควรตีความว่าทุกบัญชีจะใช้งานได้เหมือนกันหรือไม่มีค่าใช้จ่ายเพิ่ม

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

วันที่หน้ารีลีสกับวันอัปโหลดต่างกัน: หน้า GitHub ระบุรีลีส v2.58.0 วันที่ 19 ตุลาคม 2026 แต่ข้อมูล PyPI ระบุอัปโหลดวันที่ 20 ตุลาคม 2026 เวลาไทย 12:25 น. ส่วน 1.107.8 อยู่ที่ 12:39 น. (GitHub Release, PyPI) บทความนี้ใช้คำว่าอัปโหลดวันนี้ตาม PyPI ส่วนวันที่ GitHub ไม่มีเขตเวลาให้แปลง จึงคงวันที่เดิมไว้ และยังสรุปสาเหตุของความต่างไม่ได้

รุ่นแก้ไขของสองปัญหาไม่เหมือนกัน: เรื่อง MCP แก้ทั้ง 2.58.0 และ 1.107.8 ส่วนเรื่องหน้าแชตแก้ใน 2.58.0 และสายรุ่น 1 ไม่ได้รับผลจากเรื่องหน้าแชต ประโยคหลังไม่ได้แปลว่าสายรุ่น 1 ไม่ต้องอัปเดตเพื่อแก้เรื่อง MCP (GitHub Release)

ยังไม่มีข้อมูลยืนยันการใช้โจมตีจริงในชุดแหล่งข่าวนี้: ประกาศอธิบายเงื่อนไขและมาตรการลดความเสี่ยง แต่ไม่ได้ให้จำนวนระบบที่ได้รับผลหรือรายชื่อองค์กร จึงแยกการมีช่องโหว่ออกจากการยืนยันว่าแต่ละระบบถูกใช้โจมตีแล้วไว้ก่อน (GitHub Advisory: MCP, GitHub Advisory: UI adapters)

มีข้อยกเว้นที่ต้องอ่านให้ครบ: ประกาศ MCP ระบุว่าการส่งชุดเครื่องมือ MCP แบบตรงพร้อมชื่อระบุที่ผู้เรียกเลือกเองไม่อยู่ในเส้นทางปัญหาที่อธิบาย ส่วนประกาศหน้าแชตยืนยันว่าเครื่องมือที่ต้องอนุมัติไม่ทำงานผ่านช่องทางนี้ (GitHub Advisory: MCP, GitHub Advisory: UI adapters) ข้อยกเว้นเหล่านี้ช่วยจำกัดขอบเขต แต่ไม่ใช่หลักฐานรับรองความปลอดภัยของระบบทั้งหมด

แล้วเราควรทำอะไร

คนใช้ทั่วไปและเจ้าของธุรกิจ

  1. ส่งชื่อ Pydantic AI และรุ่นแก้ไขให้ผู้ดูแลแอปตรวจ ถ้าใช้สายรุ่น 2 ให้ตรวจแผนอัปเดตเป็น 2.58.0 ส่วนสายรุ่น 1 มี 1.107.8 สำหรับปัญหา MCP (GitHub Release)
  2. ให้ทีมตรวจว่ามีข้อมูลรับรองอยู่ในบันทึกที่ได้รับผลหรือไม่ หากพบ ให้เปลี่ยนข้อมูลรับรองนั้นและจำกัดสิทธิ์ดูบันทึกย้อนหลังตามคำแนะนำของโครงการ (GitHub Advisory: MCP)
  3. ผมแนะนำให้ขอผลตรวจที่ระบุทั้งรุ่นแพ็กเกจและการจัดการข้อมูลลับเดิม เพื่อให้รู้ว่างานแก้ไขครอบคลุมอะไรแล้ว โดยไม่ต้องนำค่าลับจริงมาใส่ในข้อความรายงาน

นักพัฒนาที่ใช้ MCP ร่วมกับ Logfire หรือ OpenTelemetry

  1. ตรวจรูปแบบการเชื่อม MCP และการเปิดบันทึกคำขอ แล้วอัปเดตทั้ง pydantic-ai และ pydantic-ai-slim ที่ใช้งานเป็นรุ่นแก้ไขในสายที่ดูแลอยู่ (GitHub Advisory: MCP)
  2. ตรวจขอบเขตบันทึกย้อนหลังที่อาจมีข้อมูลรับรอง จำกัดผู้เข้าถึง และเปลี่ยนข้อมูลรับรองที่เปิดเผย การปิดเก็บเนื้อหาไว้เดิมไม่เพียงพอจะตัดกรณีนี้ออก (GitHub Advisory: MCP)
  3. หากใช้ Temporal ซึ่งช่วยให้งานที่ดำเนินต่อเนื่องกลับมาทำต่อได้ พร้อมเปิดการบันทึก ให้รอให้งานที่กำลังค้างจบก่อน แล้วกำหนดชื่อระบุ MCP เองอย่างชัดเจน รุ่นแก้ไขยังเก็บชื่อกิจกรรมเดิมไว้เพื่อไม่ให้งานที่กำลังทำอยู่เสียหาย การเปลี่ยนชื่อระบุจะเปลี่ยนชื่อกิจกรรมด้วย (GitHub Advisory: MCP)

ทีมที่ทำหน้าแชตผ่าน Vercel AI หรือ AG-UI

  1. ตรวจว่าระบบส่งประวัติข้อความฝั่งเซิร์ฟเวอร์ที่ไม่ว่างและใช้การจัดการคำสั่งระบบฝั่งเซิร์ฟเวอร์หรือไม่ รวมถึงพึ่งโมเดลหรือตัวตรวจคำขอโมเดลเพื่อจำกัดเครื่องมือหรือเปล่า นี่คือชุดเงื่อนไขที่ประกาศให้ตรวจร่วมกัน (GitHub Advisory: UI adapters)
  2. อัปเดตเป็น 2.58.0 และบังคับสิทธิ์ผู้ใช้ภายในตัวเครื่องมือ วางการตรวจทันทีก่อนเครื่องมือทำงาน และกำหนดให้เครื่องมือที่มีผลสำคัญต้องได้รับอนุมัติ โดยประกาศแนะนำมาตรการเหล่านี้ระหว่างรออัปเดตด้วย (GitHub Release, GitHub Advisory: UI adapters)
  3. อ่านข้อควรระวังการย้ายรุ่นด้วย โดยเฉพาะ DBOS ซึ่งเป็นระบบดูแลงานต่อเนื่อง หากใช้ Planning พร้อมตัวรับเหตุการณ์ งานเดิมอาจกลับมาทำต่อไม่ได้หลังอัปเกรด ผู้ดูแลแนะนำให้รอให้งานที่กำลังทำจบ หรือเผยแพร่แอป DBOS เป็นรุ่นใหม่ (GitHub Release)

หลักฐานความปลอดภัยและความเสี่ยงที่ยังเหลือ

ที่มาที่ตรวจสอบได้ในข้อมูลชุดนี้คือคลังทางการ pydantic/pydantic-ai บน GitHub พร้อมแท็ก v2.58.0 และหน้ารีลีสวันที่ 19 ตุลาคม 2026 ประกอบกับหน้า PyPI ที่ระบุอัปโหลด 2.58.0 วันที่ 20 ตุลาคม 2026 เวลาไทย 12:25 น. (GitHub Release, PyPI) นี่เป็นหลักฐานแหล่งเผยแพร่และรุ่นที่อ้างอิงได้ แต่ไม่ใช่ผลทดสอบระบบของผู้อ่านแต่ละราย

ประกาศที่เกี่ยวข้องคือ GHSA-xv4x-g8mx-ch56 สำหรับข้อมูล MCP ในบันทึก และ GHSA-5pfm-2g3g-gh85 สำหรับตัวเชื่อมหน้าแชต หน้ารีลีสจัดทั้งสองเรื่องไว้ระดับปานกลาง และแหล่งข้อมูลที่ให้มาไม่ได้ระบุหมายเลข CVE จึงใช้รหัส GHSA ตามประกาศโดยตรง (GitHub Release)

ด้านสิทธิ์ ค่าเริ่มต้นการจัดการคำสั่งระบบของตัวเชื่อมเป็นฝั่งเซิร์ฟเวอร์ แต่ไม่ได้หมายความว่าทุกเครื่องมือถูกตั้งให้ขออนุมัติ ประกาศเพียงยืนยันว่าเครื่องมือที่กำหนดให้ต้องอนุมัติไม่ถูกเรียกผ่านเส้นทางช่องโหว่นี้ และการตรวจสิทธิ์ในตัวเครื่องมือยังมีผล (GitHub Advisory: UI adapters) ทีมจึงควรตรวจค่าจริงของเครื่องมือแต่ละตัว ไม่อนุมานจากค่าเริ่มต้นส่วนอื่น

ความเสี่ยงที่ยังต้องจัดการคือข้อมูลลับในบันทึกเก่า ชื่อกิจกรรม Temporal ที่ยังคงไว้ และสิทธิ์ที่ระบบกำหนดให้เครื่องมืออยู่เดิม การลงรุ่นแก้ไขไม่ได้แทนงานตรวจเหล่านี้ (GitHub Advisory: MCP, GitHub Advisory: UI adapters) ผมแนะนำให้ทดลองในโครงการชั่วคราวหรือสภาพแวดล้อมทดสอบก่อน ใช้ข้อมูลรับรองสำหรับทดสอบเท่านั้น และห้ามนำข้อมูลรับรองระบบใช้งานจริงมาลอง ไม่มีหลักฐานในชุดนี้ที่รองรับคำกล่าวว่าปลอดภัยร้อยเปอร์เซ็นต์

ผมมองว่า…

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

ฟีเจอร์จำกัดเวลาและคำเตือนค่าที่ไม่รองรับก็น่าสนใจ แต่ผมจะให้ลำดับแรกกับการอัปเดต ตรวจบันทึก และเปลี่ยนข้อมูลรับรองที่เปิดเผยก่อน จากนั้นจึงทดลองความสามารถใหม่พร้อมตรวจการย้ายงานต่อเนื่อง เป้าหมายคือรู้ว่าระบบจะยอมทำอะไรให้ใคร และคนดูบันทึกจะเห็นอะไรบ้าง

ปิดท้าย: สิ่งที่ต้องจับตา

หลังอัปเดต สิ่งที่ควรติดตามในระบบของตัวเองคือผลตรวจบันทึกเก่า การเปลี่ยนข้อมูลรับรอง และงานต่อเนื่องที่ยังไม่จบ โดย Temporal มีคำแนะนำเรื่องรอให้งานค้างจบก่อนเปลี่ยนชื่อระบุ ส่วน DBOS Planning มีข้อควรระวังเรื่องการกลับมาทำงานต่อหลังย้ายรุ่น (GitHub Advisory: MCP, GitHub Release)

สำหรับคุณสมบัติใหม่ ผมจะจับตาผลทดสอบการจำกัดเวลาทั้งงาน การลองคำขอซ้ำ และคำเตือนค่าที่โมเดลไม่รองรับในแอปที่ทีมใช้อยู่จริง ความสามารถเหล่านี้มีระบุในรีลีสแล้ว แต่ประสิทธิผลกับงานแต่ละแบบยังต้องตรวจในสภาพแวดล้อมของตัวเอง (GitHub Release)

Recap

  • ตรวจว่าแอปใช้ Pydantic AI และอยู่ในสายรุ่นใด
  • วางแผนอัปเดตเป็น 2.58.0 หรือ 1.107.8 ให้ตรงกับปัญหาและสายรุ่น
  • ตรวจ MCP และบันทึกคำขอ แม้เคยปิดการเก็บเนื้อหาแล้ว
  • จำกัดคนดูบันทึกย้อนหลังและเปลี่ยนข้อมูลรับรองที่เปิดเผย
  • ตรวจเงื่อนไขประวัติแชตของ Vercel AI และ AG-UI
  • บังคับสิทธิ์ในเครื่องมือและกำหนดการอนุมัติสำหรับงานสำคัญ
  • อ่านข้อควรระวัง Temporal และ DBOS ก่อนย้ายงานที่ยังทำไม่จบ
  • ทดลองรุ่นใหม่ในระบบทดสอบ โดยไม่ใช้ข้อมูลรับรองระบบจริง