Claude Code 2.1.212 ช่วยให้นักพัฒนาสามารถกำหนดขีดจำกัด (hard limits) ของจำนวน sub-agents และการค้นหาเว็บ (web searches) ที่เซสชัน AI สามารถสร้างขึ้นได้ ซึ่งเป็นเครื่องมือที่จับต้องได้ในการควบคุมไม่ให้ค่าใช้จ่ายบานปลาย

การอัปเดตนี้เพิ่มการกำหนดเพดาน (caps) ที่ปรับแต่งได้สองส่วน ได้แก่ จำนวนการสร้าง sub-agent และจำนวนการเรียกใช้การค้นหาเว็บ โดยทั้งคู่มีค่าเริ่มต้นอยู่ที่ 200 ต่อเซสชัน นักพัฒนาสามารถลดตัวเลขเหล่านี้ได้ผ่าน environment variables และการเรียกใช้ MCP (Model-Control-Plane) ใดๆ ที่ทำงานนานกว่าสองนาทีจะถูกส่งไปทำงานเบื้องหลัง (background) โดยอัตโนมัติ เพื่อป้องกันไม่ให้เครื่องมือที่ทำงานช้าเพียงตัวเดียวทำให้เวิร์กโฟลว์ทั้งหมดหยุดชะงัก

ทำไมการกำหนดขีดจำกัดถึงสำคัญในตอนนี้

AI agent ที่สามารถเรียก agent ตัวอื่นหรือดึงข้อมูลจากเว็บ (scrape the web) ได้อย่างไร้ขีดจำกัดนั้นมีประโยชน์ แต่ก็กลายเป็นความเสี่ยงทางการเงินด้วยเช่นกัน คำสั่ง (prompt) ที่คลุมเครืออาจกระตุ้นให้เกิดการสร้าง sub-agents ต่อเนื่องกันเป็นทอดๆ ซึ่งแต่ละตัวจะใช้ token และเรียกใช้เครื่องมือภายนอก ส่งผลให้ค่าใช้จ่ายพุ่งสูงขึ้นอย่างรวดเร็วก่อนที่จะมีใครทันสังเกตเห็น ในทางปฏิบัติ ทีมต่างๆ ได้รายงานปัญหาดังนี้:

  • การใช้ token ที่สูงเกินคาดจนเกินงบประมาณที่ตั้งไว้สำหรับงานนั้นๆ อย่างมาก
  • การมี sub-agents ที่ทำงานซ้ำซ้อนกันจนเข้าไปแก้ไขงานทับซ้อนกัน ทำให้เกิดผลลัพธ์ที่ขัดแย้งกัน
  • ผลลัพธ์ที่ไม่สมบูรณ์จำนวนมหาศาลที่ยากต่อการนำมาประกอบกัน
  • เครื่องมือภายนอกที่ทำงานช้าทำให้เซสชันทั้งหมดล่าช้า เปลี่ยนจากการสอบถามสั้นๆ ให้กลายเป็นการรอคอยนานหลายนาที

การกำหนดเพดานที่ชัดเจนจะช่วยให้ Claude Code บังคับให้ระบบหยุดทำงานก่อนที่ค่าใช้จ่ายจะบานปลาย ในขณะที่ยังคงส่งมอบคำตอบบางส่วนที่มนุษย์สามารถนำไปตรวจสอบต่อได้

วิธีการกำหนดเพดาน (caps)

การปรับตั้งค่าทั้งสามส่วนสามารถทำได้ผ่าน environment variables:

export CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION=12   # default 200
export CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION=30   # default 200
export CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS=120000   # 2 minutes

ค่าเริ่มต้นนั้นเพียงพอสำหรับการทำงานเชิงสำรวจส่วนใหญ่ แต่ทีมต่างๆ สามารถปรับให้เข้มงวดขึ้นเพื่อให้สอดคล้องกับระดับความเสี่ยงของงานแต่ละประเภท บทความที่ประกาศการเปิดตัวได้เสนอแนวทางเริ่มต้นไว้ดังนี้:

  • การแก้ไขบั๊กในเครื่อง (Local bug fix): sub-agents 0-2 ตัว, การค้นหา 0-5 ครั้ง
  • การรีวิว PR (PR review): sub-agents 3-5 ตัว, การค้นหา 0-10 ครั้ง
  • การตรวจสอบอุบัติการณ์ (Incident investigation): sub-agents 2-4 ตัว, การค้นหา 10-25 ครั้ง
  • การวิจัยสถาปัตยกรรมในวงกว้าง (Broad architecture research): 1 synthesizer, 2-4 researchers, การค้นหา 20-40 ครั้ง

สิ่งเหล่านี้ไม่ใช่ข้อกำหนดตายตัว แต่เป็นเพียงค่าพื้นฐานเพื่อให้เหล่านักพัฒนานำไปปรับใช้ตามความเหมาะสม

ข้อแลกเปลี่ยน (The trade-off)

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

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

การนำไปใช้งานจริง (Getting it into production)

  1. อัปเกรด เป็น Claude Code 2.1.212 ในสภาพแวดล้อม staging
  2. เลือกเวิร์กโฟลว์ เช่น การรีวิว PR และกำหนดงบประมาณแบบระมัดระวัง
  3. ติดตั้งระบบบันทึก (Instrument) ใน log ของคุณเพื่อเก็บข้อมูลจำนวน sub-agents ที่ถูกเรียกใช้งาน, จำนวนการค้นหาเว็บที่ทำ และการเรียกใช้ MCP ใดๆ ที่ถึงเกณฑ์สองนาที
  4. ตรวจสอบ (Review) ทุกครั้งที่การทำงานไปถึงเพดานที่กำหนด เพื่อพิจารณาว่าการกำหนดเพดานนั้นช่วยประหยัดเงินหรือขัดขวางความคืบหน้าที่แท้จริง แล้วจึงปรับขีดจำกัดตามความเหมาะสม

เนื่องจากเพดานเหล่านี้ถูกบังคับใช้ในขณะรันไทม์ (runtime) จึงสามารถเห็นได้ทันทีใน log ทีมที่ติดตามตัวชี้วัดเหล่านี้สามารถสร้างวงจรการตอบกลับ (feedback loop) ได้ เช่น ลดงบประมาณลงจนกว่า agent จะเริ่มทำงานไม่สำเร็จ จากนั้นจึงค่อยเพิ่มงบประมาณขึ้นเพียงพอที่จะทำงานหลักให้เสร็จสิ้น

สิ่งที่ควรจับตามองต่อไป

การเปิดตัวยังอยู่ในช่วงเริ่มต้น ดังนั้นข้อมูลการประหยัดค่าใช้จ่ายในโลกความเป็นจริงจึงยังมีจำกัด องค์กรที่นำการกำหนดเพดานไปใช้ควรติดตาม:

  • ค่าใช้จ่ายต่อเซสชัน (Cost per session) ทั้งก่อนและหลังการเปลี่ยนแปลง
  • อัตราการทำงานสำเร็จ (Completion rate) ของงานในระดับงบประมาณต่างๆ
  • ความพึงพอใจของผู้ใช้ (User satisfaction) เมื่อ agent หยุดทำงานก่อนกำหนด เทียบกับเมื่อปล่อยให้ทำงานจนจบ

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

สรุปสั้นๆ คือ: Claude Code 2.1.212 ช่วยให้ทีมมีวิธีที่ง่ายและบังคับใช้ได้จริง เพื่อป้องกันไม่ให้ระบบอัตโนมัติที่ขับเคลื่อนด้วย AI กลายเป็นความประหลาดใจทางการเงิน จงใช้การกำหนดเพดาน ติดตามผลลัพธ์ และให้ข้อมูลเป็นตัวนำทางว่าคุณควรจะมอบอำนาจการตัดสินใจ (autonomy) ให้กับ agent ของคุณมากน้อยเพียงใด