Deep Dive: Agent retry ไม่รู้จบ จาก Cloudflare Agents

ข่าวนี้คืออะไรในภาษาคนทำงาน

Cloudflare Agents ออก release [email protected] เพื่อแก้ปัญหา recovery loop ของ agent ที่เจอ Out of Memory แล้วพยายามกู้ตัวเองซ้ำไม่หยุด

เคสต้นทางมาจาก GitHub issue ชื่อ “Neverending retries during recovery” ผู้ใช้แจ้งว่า agent retry ซ้ำหลัง memory limit และทำให้ค่า LLM เพิ่มขึ้น เพราะระบบรัน turn เดิมซ้ำไปเรื่อย ๆ

สิ่งที่ Cloudflare แก้คือทำให้ OOM เป็น failure ที่มีงบ retry เฉพาะ ไม่ใช่ transient error ที่ปล่อยให้วนไปเรื่อย ๆ ตัว release เพิ่ม chatRecovery.maxOomRetries ค่า default 3 ครั้ง และมี circuit breaker ที่ชั้น Agent.alarm() เพื่อหยุดเคสที่ memory crash หลุดจาก budget ข้างใน

พูดง่าย ๆ คือ agent ยังพยายามกู้ตัวเองได้ แต่ถ้าพังด้วยสาเหตุเดิมซ้ำจนชัดแล้ว ระบบต้อง seal งานนั้นเป็น out_of_memory แทนที่จะเผาเงินต่อ

So what: ทำไมทีมเล็กและ founder ควรสนใจ

หลายทีมเริ่มใช้ AI Agent แบบ “ปล่อยให้ทำงานต่อเอง” แล้วครับ เช่น coding agent, support bot, workflow automation, crawler, research agent, หรือ LINE/CRM assistant

พอระบบเริ่มมี retry อัตโนมัติ ปัญหาจะเปลี่ยนจาก “AI ตอบได้ไหม” เป็น “ถ้ามันพัง มันพังแบบหยุดเป็นไหม”

สำหรับทีมเล็ก จุดเสี่ยงไม่ใช่แค่ downtime แต่คือ silent cost งานเดิมถูกเรียกซ้ำ, LLM ถูกชาร์จซ้ำ, queue ค้าง, log ดูเหมือนระบบพยายามช่วยตัวเอง แต่จริง ๆ กำลังวนอยู่ในหลุมเดิม

ข่าวนี้เลยเป็นสัญญาณที่ดี เพราะมันสอน pattern ที่เอาไปใช้กับระบบ agent ของตัวเองได้ทันที ไม่ต้องใช้ Cloudflare ก็ได้

How to use: เอาไปใช้กับงานตัวเองยังไง

1. แยก error เป็น 2 กลุ่มก่อน retry

อย่าใช้ retry rule เดียวกับทุก error

Network timeout, deploy restart, temporary provider failure อาจ retry ได้หลายครั้ง แต่ OOM, schema mismatch, permission denied, bad credentials, input ใหญ่เกิน limit มักเป็น error ที่ retry ซ้ำก็พังแบบเดิม

1. ตั้ง budget ต่อ incident ไม่ใช่แค่ต่อ request

ถ้า request เดียว fail แล้ว retry 3 ครั้งยังไม่พอ เพราะ agent workflow หนึ่งอาจถูกปลุกใหม่โดย alarm, queue, webhook หรือ cron

ต้องมีตัวนับระดับ incident เช่น recovery_attempts, oom_attempts, work_units, last_progress_at เพื่อให้ระบบรู้ว่ากำลังวนซ้ำในงานเดิม

1. ให้ retry จบด้วยสถานะที่คนอ่านรู้เรื่อง

อย่าจบด้วยคำว่า failed เฉย ๆ

สถานะที่ดีกว่าคือ out_of_memory, budget_exceeded, permission_required, input_too_large, needs_human_review เพราะทำให้ operator รู้ว่าควรแก้อะไรต่อ

1. เชื่อม cost cap เข้ากับ recovery loop

ถ้างานหนึ่งกำลัง retry LLM call ซ้ำ ให้มีเพดานค่าใช้จ่ายระดับ task หรือ incident

ตัวอย่างง่าย ๆ คือถ้า incident นี้เรียก model เกิน 3 รอบหรือค่า token เกินเพดาน ให้หยุดและสรุปสิ่งที่เกิดขึ้นแทนการลองต่อ

1. ทำ runbook สำหรับ “งานไม่ควร retry แล้ว”

บาง failure ไม่ต้องให้ AI แก้ต่อเอง ให้มันสร้าง summary, แนบ logs สำคัญ, บอก next action แล้วส่งให้คนดู

นี่คือความต่างระหว่าง agent ที่ดูเหมือนฉลาด กับ agent ที่พร้อมอยู่ในงานจริง

Operator Kit

Mini Playbook: Agent retry แบบไม่เผาเงินเงียบ

ใช้ checklist นี้กับ agent workflow ที่มี retry, queue, cron, webhook หรือ background job

1. ระบุประเภท failure

• [ ] transient: network, provider timeout, temporary rate limit
• [ ] deterministic: OOM, input too large, permission denied, invalid schema, bad credentials
• [ ] unknown: ยังไม่รู้สาเหตุ ต้อง retry น้อยและเก็บ proof เพิ่ม

2. ตั้ง retry budget 3 ชั้น

• [ ] ต่อ call: เช่น retry 2 ถึง 3 ครั้ง
• [ ] ต่อ task: เช่น task เดิมห้ามรัน LLM เกิน 3 รอบ
• [ ] ต่อ incident: เช่น alarm หรือ queue ปลุกซ้ำได้ไม่เกิน 3 ครั้งก่อน seal

3. เขียนสถานะจบให้ชัด

ใช้ final reason ที่ action ได้ เช่น

• out_of_memory: ลด context, แบ่งงาน, เพิ่ม memory, หรือเปลี่ยน runtime
• work_budget_exceeded: workflow วนยาวเกินเพดาน
• permission_required: ต้องให้คนเพิ่มสิทธิ์หรือเปลี่ยน credential
• input_too_large: ต้อง summarize หรือ chunk ก่อน
• needs_human_review: ต้องให้คนตัดสินใจ

4. เก็บ proof ขั้นต่ำก่อนหยุด

• [ ] error message ล่าสุด
• [ ] task id หรือ incident id
• [ ] จำนวน retry
• [ ] จำนวน model calls โดยประมาณ
• [ ] token หรือ cost โดยประมาณถ้ามี
• [ ] next recommended action

5. ทดลองวันนี้แบบไม่ต้องรื้อระบบ

เลือก workflow agent 1 ตัว แล้วทำ failure drill สั้น ๆ:

1. ป้อน input ใหญ่เกิน limit หรือจำลอง OOM
2. ดูว่ามัน retry กี่ครั้ง
3. ดูว่ามี final reason ไหม
4. ดูว่าค่าใช้จ่ายหยุดเองไหม
5. เขียน rule ใหม่ว่า error แบบนี้ควร retry หรือควรส่งให้คนดู

Caveat: อย่าแก้ด้วยการปิด retry ทั้งหมด

retry ยังจำเป็นครับ โดยเฉพาะงานที่เจอ network, provider, หรือ deploy transient error

บทเรียนจากข่าวนี้ไม่ใช่ “ห้าม retry” แต่คือ “retry ต้องรู้ชนิดของปัญหาและมีจุดจบ”

ถ้าปิด retry หมด agent จะเปราะเกินไป แต่ถ้าเปิด retry ไม่จำกัด agent จะกลายเป็นเครื่องเผา token แบบเงียบ ๆ

ทางสายกลางคือ retry แบบมี budget, มี final reason, มี proof และมี handoff ให้คนเข้าใจได้เร็ว

สรุป

Cloudflare Agents 0.17.1 เป็นข่าวเล็ก แต่เป็นบทเรียนใหญ่สำหรับคนทำระบบ AI จริง

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

Data-Espresso จะคอยช่วยย่อยข่าว AI แบบนี้ให้กลายเป็น workflow, checklist และ playbook ที่ทีมเล็กเอาไปใช้ได้จริง โดยไม่ต้องนั่งอ่าน release note ทุกตัวเอง

ถ้าอยากเปลี่ยนข่าว AI ให้เป็นระบบทำงานจริงในบริษัท ติดตาม Data-Espresso และ OPB Stack ไว้ได้ครับ