การลดควอตาของ Claude Code: ตัวแทนกำลังสร้าง 'ภูเขาโค้ดแบบเดิม' ใหม่หรือไม่?

การขยายวงเงินรายสัปดาห์ของ Claude Code ได้รับความสนใจ โดยบทความวิเคราะห์กลไกการใช้ Token ของโปรแกรม Agent การทำงานของ Agent เป็นเวลานานจะทำให้ working set ขยายตัวอย่างต่อเนื่อง ทุกขั้นตอนสะสมสถานะย้อนหลัง พร้อมกับคุณสมบัติที่แคชที่ถูกเรียกใช้ยังคงใช้พื้นที่ context ทำให้ต้นทุนการคำนวณเพิ่มขึ้นแบบสะสม การล้างข้อมูลมากเกินไปจะก่อให้เกิด “semantic page fault” ทำให้ Agent ต้องดึงข้อมูลใหม่ บทความชี้ให้เห็นว่าความไม่สอดคล้องกันระหว่างสถานะโค้ดกับความแม่นยำในการบันทึกสถานะการออกแบบอาจนำไปสู่การสร้าง “โค้ดมรดก” โดย Agent รุ่นถัดไปไม่สามารถเข้าใจเหตุและผลของการออกแบบโค้ดรุ่นก่อนหน้า สุดท้ายจึงเกิดโค้ดที่ซับซ้อนซึ่งมีการชดเชยกันระหว่าง queue, bypass และ retry

ผู้เขียนบทความ แหล่งที่มา: LeFeng.com

รหัสนั้นเป็นของ Agent เขียนขึ้น แต่ Agent ที่ตามมาไม่ทราบว่าทำไม Agent ก่อนหน้าถึงเขียนแบบนั้น

การเพิ่มปริมาณรายสัปดาห์ +50% สำหรับ Claude Code ซึ่งเดิมกำหนดสิ้นสุดวันที่ 19 สิงหาคม ได้รับการขยายเวลาโดย Anthropic ไปจนถึงวันที่ 31 สิงหาคม ในช่วงเวลาใกล้เคียงกับวันหมดอายุเดิม ได้มีการอภิปรายบน Hacker News เกี่ยวกับค่าใช้จ่ายในการใช้งาน Claude Code: หลายคนพบว่า งานที่ไม่ซับซ้อนมากนัก เมื่อ Agent รันผ่านหลายรอบ ปริมาณจะลดลงอย่างรวดเร็ว

ปัญหาคือ Claude Code ใช้ทรัพยากรไม่เพียงแค่โค้ดไม่กี่บรรทัดสุดท้ายที่สร้างขึ้น การอ่านไฟล์ การค้นหาโซ่การเรียกใช้งาน การรันการทดสอบ และการจัดการล็อก แต่ละขั้นตอนจะยังคงส่งผลต่อบริบทถัดไป ยิ่งงานยาวเท่าใด ประวัติที่ Agent ต้องแบกไว้ก็ยิ่งหนักขึ้น และระบบก็ยิ่งพึ่งพาการล้างและบีบอัดมากขึ้น

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

ขอบเขตการคำนวณของ Chat coding แบบทั่วไปชัดเจน ป้อนรหัสหนึ่งชุด โมเดลอ่านแล้วให้คำอธิบายหรือแนวทางการแก้ไข รอบนี้จะสิ้นสุดลงโดยทั่วไป

หน่วยพื้นฐานของ Claude Code ถูกเปลี่ยนเป็น agent loop โมเดลจะสังเกตสถานะปัจจุบันก่อน ตัดสินใจว่าจะอ่านไฟล์ใดหรือดำเนินการคำสั่งใดต่อไป; หลังจากเครื่องมือส่งผลลัพธ์กลับมา โมเดลจะทำการตัดสินใจในรอบถัดไป

การอ่านรหัสแหล่งที่มา การค้นหาการอ้างอิง การรันการทดสอบ การดู Git diff และการแก้ไขไฟล์ ดูเหมือนเป็นการกระทำต่อเนื่อง แต่ในด้านโมเดลจริงๆ แล้วเป็นชุดคำขอการให้เหตุผลที่แยกจากกัน เอกสารอย่างเป็นทางการของ Claude Code ยังถือว่าวงจร “โมเดลตัดสินใจ — เรียกใช้เครื่องมือ — ตัดสินใจต่อตามผลลัพธ์” เป็นหัวใจของวิธีการทำงานของเอเจนต์

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

อาจจนถึงตอนนี้มันถึงจะเริ่มเขียนโค้ดไม่กี่บรรทัดนั้นจริงๆ ดังนั้นdiff ขนาดและปริมาณการคำนวณแทบไม่มีสัดส่วนที่คงที่ แพตช์ 5 บรรทัดอาจมีเพียงการให้เหตุผล 3 ครั้ง หรืออาจผ่านการโต้ตอบกับเครื่องมือมาแล้ว 30 ครั้ง

หากแบ่งงานของเอเจนต์หนึ่งครั้งออกเป็นส่วนย่อย จะได้ตัวแปรสองตัว: หนึ่งคือ step count ซึ่งหมายถึงจำนวนขั้นตอนที่เอเจนต์ใช้เพื่อ hoàn thiệnงาน อีกตัวคือ working set ซึ่งหมายถึงจำนวนสถานะของรายการที่โมเดลยังต้องรู้เมื่อไปถึงขั้นตอนปัจจุบัน

การเพิ่มจำนวนขั้นตอนเพียงอย่างเดียวจะเพิ่มการใช้งานแล้ว หากชุดงานยังคงขยายตัวแบบซิงค์กัน สถานการณ์จะต่างออกไปอย่างมาก ขั้นที่ 3 อาจต้องจัดการกับ Token เพียงไม่กี่พัน แต่ขั้นที่ 30 อาจต้องรับภาระของกฎโครงการ รหัสแหล่งที่มาที่เกี่ยวข้อง ผลการทดสอบ ประวัติการแก้ไข และเครื่องมือเพื่อให้การอนุมานต่อไป

นี่คือจุดเริ่มต้นของความเปลี่ยนแปลงในโครงสร้างต้นทุนของ Coding Agent: ปริมาณการคำนวณเริ่มขึ้นอยู่กับ “จำนวนก้าวที่เดิน × น้ำหนักที่แบกในแต่ละก้าว” แทนที่จะขึ้นอยู่กับจำนวนบรรทัดของรหัสที่เขียน

การแยกคำขอแบบจำลองของ Agent ออกเป็นส่วนๆ สามารถมองเห็นได้คร่าวๆ เป็นสามส่วน ได้แก่ ส่วนที่ค่อนข้างคงที่ ได้แก่ system prompt, CLAUDE.md, นิยามเครื่องมือ และกฎโครงการ; ส่วนที่เปลี่ยนแปลงตลอดเวลา ได้แก่ ไฟล์โค้ด ผลลัพธ์การค้นหา บันทึกการทดสอบ Git diff และประวัติงานก่อนหน้า; และสุดท้ายคือเหตุผล ข้อความ และโค้ดที่แบบจำลองสร้างขึ้นในรอบนี้

ที่นี่มักเกิดความเข้าใจผิด: หากเนื้อหาด้านหน้าได้ถูกอ่านไปแล้ว ก็ไม่ควรสร้างต้นทุนซ้ำซ้อนมากเกินไป ปัญหาอยู่ที่ LLM ไม่มีหน่วยความจำภายในที่สามารถเข้าถึงได้ทันทีเหมือนโปรแกรมทั่วไป ข้อมูลที่รู้ในรอบก่อนหน้า หากรอบถัดไปยังคงต้องพึ่งพา มันยังคงต้องปรากฏอยู่ใน context ที่ใช้งานได้

Prompt cache สามารถช่วยบรรเทาปัญหานี้ได้ เอกสารอย่างเป็นทางการของ Claude Code ระบุชัดเจนว่า หากไม่มีการแคชคำสั่ง ทุกคำขอจะต้องประมวลผลประวัติทั้งหมดใหม่; เมื่อแคชตรงกัน คำนำหน้าที่ได้รับการประมวลผลแล้วและมีความเสถียรสามารถนำกลับมาใช้ใหม่ได้ ซึ่งช่วยลดการคำนวณซ้ำและค่าใช้จ่าย

แต่แคชแก้ปัญหาการ “ใช้ซ้ำประวัติเดิมในราคาที่ถูกลง” ไม่ได้แก้ปัญหาการ “ยังคงต้องการให้ประวัตินี้มีอยู่ต่อไปหรือไม่” แม้สถานะเก่าของ 100K Token จะถูกแคชและลดต้นทุนลง แต่มันยังคงใช้พื้นที่ context และยังคงเป็นสถานะที่การอนุมานปัจจุบันอิงอยู่

ดังนั้นสามารถเขียนงานที่ยาวได้คร่าวๆ ว่า: ขนาดการป้อนข้อมูลในขั้นที่ t ประมาณเท่ากับคำนำที่เสถียร S บวกกับชุดงานที่ใช้งานอยู่ในปัจจุบัน W_t บวกกับข้อมูลใหม่ที่เกิดขึ้นในรอบนี้ Δ_t。

ปัญหาที่แท้จริงคือ W_t หากทุกขั้นตอน Agent อ่านโค้ดต้นฉบับเพิ่มขึ้น รับข้อมูลล็อกเพิ่มขึ้น และทิ้งการตัดสินใจไว้หนึ่งครั้ง ขณะที่ข้อมูลเก่าไม่ถูกลบออกอย่างทันเวลา แล้ว W_t จะเพิ่มขึ้นเรื่อยๆ ตามความคืบหน้าของงาน

ในโมเดลที่ถูกทำให้เรียบง่ายอย่างสุดขั้ว โดยไม่มีการแคชหรือทำความสะอาดเลย หากสถานะที่ถูกเพิ่มในแต่ละรอบมีปริมาณใกล้เคียงกัน ปริมาณการประมวลผลรวมจะมีโครงสร้างสะสมใกล้เคียงกับ 1 + 2 + 3 + … + n กล่าวคือ แม้จำนวนขั้นตอนจะเพิ่มขึ้นเพียงสองเท่า สถานะที่ผ่านมาทั้งหมดที่ถูกประมวลผลอาจเพิ่มขึ้นเร็วกว่านั้นมาก

ระบบจริงมี cache การแก้ไขบริบท และการบีบอัด จึงไม่ได้ปฏิบัติตามเส้นโค้งการเติบโตนี้อย่างเคร่งครัด แต่รูปร่างของปัญหาไม่ได้เปลี่ยนไป: ยิ่ง Agent ทำงานนานเท่าใด แต่ละการกระทำใหม่ก็ยิ่งมีแนวโน้มที่จะอิงอยู่บนประวัติที่หนักหน่วงยิ่งขึ้น

ดังนั้น คำสั่งของผู้ใช้ที่สั้นมากในงานยาวจะสูญเสียความสำคัญไปอย่างรวดเร็ว สิ่งที่เริ่มควบคุมต้นทุนจริงๆ คือชุดงานที่โมเดลต้องพกติดตัวอย่างต่อเนื่องเพื่อรักษาความต่อเนื่องของงาน

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

หนึ่ง grep สามารถคืนค่าอ้างอิงนับร้อย หนึ่งการสร้างอาจแสดงคำเตือนจำนวนมาก หนึ่งการทดสอบล้มเหลวอาจนำพา stack trace ทั้งหมดมาด้วย Docker ตัวคอมไพเลอร์ และตัวจัดการแพ็กเกจก็สร้างข้อความจำนวนมากที่ไม่มีคุณค่าระยะยาวต่องาน

สมมติว่าการทดสอบขั้นที่ 10 สร้างบันทึก 8K Token เมื่อเข้าสู่ context เป็นครั้งแรก มันมีเพียง 8K Token เท่านั้น แต่ Agent ยังต้องตรวจสอบซอร์สโค้ด แก้ไข และทดสอบใหม่อีก ตราบใดที่บันทึกนี้ยังคงอยู่ในประวัติที่ใช้งานได้ มันจะเพิ่มน้ำหนักพื้นฐานของการร้องขอหลายรอบถัดไป

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

ดังนั้น แม้จะเป็น Token 8K เดียวกัน การวางไว้ในรอบก่อนสิ้นสุดภารกิจและวางไว้ตอนเริ่มต้นภารกิจ จะส่งผลต่อภาพรวมที่ต่างกันอย่างสิ้นเชิง Claude Code ตอนนี้ยังลดการปนเปื้อนแบบนี้อย่างกระตือรือร้น ทางผู้พัฒนาแนะนำให้ใช้ sub-agent แยกภารกิจที่ต้องส่งออกมาก และระบุชัดเจนว่าผลลัพธ์การค้นหา ล็อก และเนื้อหาไฟล์จำนวนมากจะใช้พื้นที่ context ของเซสชันหลัก; คำจำกัดความของเครื่องมือเองก็ใช้พื้นที่เช่นกัน ดังนั้นชุดเครื่องมือที่ใหญ่เกินไปก็จะเพิ่มภาระสถานะ

แต่ที่นี่ก็เกิดปัญหาในทิศทางตรงกันข้าม: ไม่สามารถตัดไฟล์ล็อกทั้งหมดออกได้เพียงเพราะมันมีราคาสูง ไฟล์ล็อก 3,000 บรรทัดอาจมีเพียง 20 บรรทัดที่เกี่ยวข้องกับสาเหตุหลัก ระบบไม่สามารถรู้ล่วงหน้าได้ว่าเป็น 20 บรรทัดใด หากดำเนินการล้างข้อมูลเร็วเกินไป ตัวแทนอาจต้องการรายละเอียดหนึ่งในนั้นในภายหลัง และจะต้องรันการทดสอบใหม่หรือเปิดไฟล์ใหม่อีกครั้ง

สิ่งนี้สามารถเรียกว่า semantic page fault หรือการขาดหน้าเชิงความหมาย ในระบบหน่วยความจำเสมือนแบบดั้งเดิม เมื่อโปรแกรมเข้าถึงหน้าที่ไม่อยู่ในหน่วยความจำแล้ว ระบบจะโหลดใหม่จากดิสก์; เมื่อ Coding Agent ทิ้งหลักฐานช่วงก่อนหน้าบางส่วนไป ก็จะเกิดปรากฏการณ์คล้ายกัน แต่แสดงออกในรูปแบบของการค้นหาคลังใหม่ อ่านไฟล์ซ้ำ รันคำสั่งอีกครั้ง หรือแม้แต่สรุปปัญหาที่เคยวิเคราะห์ไปแล้วใหม่

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

สิ่งนี้ยังอธิบายว่าทำไมการจัดการบริบทไม่สามารถลดรูปแบบเป็น “ใส่โทเค็นน้อยลง” ได้ สิ่งที่ต้องแก้ไขอย่างแท้จริงคือการเลือก working set: ข้อมูลใดบ้างที่ต้องคงไว้ในพื้นที่ทำงานในขณะนี้ และข้อมูลใดเป็นเพียงผลิตภัณฑ์ระหว่างทางที่ได้เสร็จสิ้นภารกิจไปแล้ว

ที่นี่ compaction, memory และ sub-agent จึงมีเหตุผลที่แท้จริงในการมีอยู่

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

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

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

หลังจากหลายขั้นตอน ถ้าข้อมูลนี้ถูกบีบอัดเป็น: “ปัญหาสถานะได้รับการแก้ไขผ่านการปรับแต่งบริการ” ข้อเท็จจริงยังถูกต้อง แต่ข้อมูลได้เปลี่ยนไปแล้ว เนื้อหาต้นฉบับมี constraint ส่วนสรุปด้านหลังเก็บเฉพาะ event เท่านั้น

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

เอกสารบริบทของ Claude Code ยังระบุอย่างชัดเจนว่า กฎบางประการที่จำกัดตาม path และ CLAUDE.md ที่ซ้อนกันจะถูกรวบรวมและสรุปไปพร้อมกับเซสชัน และจำเป็นต้องอ่านไฟล์ที่ตรงกันอีกครั้งเพื่อโหลดใหม่

Memory พยายามแก้ไขปัญหาการเก็บข้อมูลความรู้ระยะยาว ไฟล์ CLAUDE.md และ auto memory ในไดเรกทอรีรากของโปรเจกต์สามารถดึงข้อมูลเช่นคำสั่งการสร้าง ข้อกำหนดของโปรเจกต์ และประสบการณ์การดีบักออกจากบทสนทนาระยะสั้น และโหลดกลับมาเมื่อเริ่มการสนทนา แต่ Anthropic ก็ได้ระบุอย่างชัดเจนว่า memory เหล่านี้ยังคงเป็นเพียง context และไม่ใช่การตั้งค่าบังคับ

ความแตกต่างนี้สำคัญมาก หากเขียนว่า “ไม่สามารถเข้าถึงฐานข้อมูลโดยตรงที่นี่” ไว้ในหน่วยความจำเพียงอย่างเดียว มันยังคงเป็นภาษาธรรมชาติที่โมเดลต้องเข้าใจและปฏิบัติตาม แต่ถ้ากฎเดียวกันนี้ถูกเขียนในรูปแบบ dependency lint, ข้อจำกัดประเภท หรือการตรวจสอบ CI มันจึงจะกลายเป็น software invariant ที่ไม่สามารถหลีกเลี่ยงได้ง่ายๆ

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

ต้นทุนของมันก็น่าสนใจเช่นกัน: Agent หลักได้รับสถานะที่สะอาดกว่า แต่สูญเสียหลักฐานดั้งเดิมบางส่วน; การรัน Agent หลายตัวพร้อมกันยังสร้าง context ของตนเองขึ้นมา ดังนั้น การบีบอัด การจัดเก็บหน่วยความจำ และ Agent ย่อย เมื่อมองร่วมกัน แท้จริงแล้วก็คล้ายกับระดับหน่วยความจำในยุคของ Agent:

ปัจจุบัน context เป็นหน่วยความจำที่มีต้นทุนสูง compaction รับผิดชอบในการบีบอัด memory จัดเก็บสถานะข้ามเซสชัน และ sub-agent ใช้พื้นที่ที่อยู่อิสระเพื่อแยกสัญญาณรบกวน ปัญหาจึงเปลี่ยนจาก “context จะใหญ่พอไหม” เป็นระดับที่สูงขึ้นอีกขั้น:

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

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

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

Claude Code ใช้ข้อจำกัดการเลื่อนและวงเงินรายสัปดาห์ในการจัดการสิ่งนี้; Codex ตอนนี้ได้คำนวณเครดิตอย่างชัดเจนตาม input token, cached input token และ output token; ส่วนแพ็กเกจของ Cursor จะจัดให้ Agent มี pool การใช้งานที่แตกต่างกัน การใช้งานโมเดลจากบุคคลที่สามจะได้รับผลกระทบจากราคา API ของโมเดล

อินเทอร์เฟซของผลิตภัณฑ์ทั้งสามมีภาษาต่างกัน แต่ปัญหาพื้นฐานที่ต้องแก้ไขกลับใกล้เคียงกันมาก: วิธีการจัดสรรทรัพยากรการให้เหตุผลให้กับโปรแกรมอัจฉริยะที่เส้นทางการดำเนินการไม่สามารถระบุล่วงหน้าได้ โปรแกรม Coding Agent จะทำงานนานแค่ไหนนั้นยากที่จะคาดเดาได้ตั้งแต่เริ่มต้นงาน

โมเดลอาจค้นหาสาเหตุหลักได้อย่างรวดเร็ว หรืออาจเสนอสมมติฐานผิดหลายข้อติดต่อกัน; อาจผ่านการทดสอบเพียงครั้งเดียว หรืออาจเข้าสู่ลูปดีบักที่ยืดเยื้อ; อาจต้องการเพียงหนึ่ง Agent หรืออาจแบ่งออกเป็น sub-agent หลายตัว

API แบบดั้งเดิมชอบคิดค่าบริการตามจำนวนคำขอ เพราะการเปลี่ยนแปลงของทรัพยากรในแต่ละคำขอสามารถควบคุมให้อยู่ในขอบเขตที่กำหนดได้ แต่ Agent ทำลายความเสถียรนี้ไป ดังนั้น Token ในที่นี้จึงเริ่มมีลักษณะคล้ายกับเวลา CPU

การเปรียบเทียบนี้ไม่สามารถเทียบเท่ากันได้ โมเดลที่แตกต่างกันมีต้นทุนการประมวลผลที่ต่างกันสำหรับจำนวนโทเค็นเดียวกัน โดย input, cached input และ output ต่างก็มีต้นทุนที่ไม่เหมือนกัน แต่ในมุมของนักพัฒนา ฟังก์ชันของพวกมันกลับมีความคล้ายคลึงกันมากขึ้น: ทั้งหมดล้วนกำลังอธิบายว่าเพื่อให้งานดำเนินต่อไป ต้องใช้ทรัพยากรการประมวลผลเท่าใด

เมื่อ Anthropic เพิ่มขีดจำกัดการใช้งาน Claude Code ในปีนี้ พวกเขายังเชื่อมโยงการเพิ่มวงเงินกับการเพิ่มกำลังการประมวลผลโดยตรง สิ่งนี้จะนำไปสู่การเปลี่ยนแปลงของตัวชี้วัดที่น่าสนใจ ก่อนหน้านี้ การเปรียบเทียบตัวแทนการเขียนโค้ดมักเน้นที่ว่า “ใครสามารถเขียนโค้ดได้ดีในครั้งแรกสำหรับโจทย์เดียวกัน” แต่ในอนาคต อาจมีความหมายมากกว่าคือ: ใครสามารถบรรลุการเปลี่ยนแปลงสถานะของโครงการเดียวกันด้วยการใช้พลังการคำนวณที่มีประสิทธิภาพน้อยกว่า

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

และสถานะการกู้คืนที่ไม่มีประสิทธิภาพเช่นนี้ จะพอดีกับหนี้ทางเทคนิคในระดับถัดไป

ที่นี่สามารถมองซอฟต์แวร์ที่ตัวแทนการเขียนโปรแกรมดูแลเป็นสองชุดสถานะที่พัฒนาพร้อมกัน ชุดหนึ่งคือสถานะรหัส R_t ไฟล์ ประเภท อินเทอร์เฟซ การทดสอบ และ Git commit ทั้งหมดอยู่ในระดับนี้ บรรทัดที่ตัวแทนเพิ่มเข้ามาในขั้นตอนที่ 20 คือ retry หากยังไม่ถูกลบ ขณะเปิดไฟล์ในขั้นตอนที่ 100 มันจะยังคงอยู่ครบถ้วน รหัสเก็บรักษาความแม่นยำของการเปลี่ยนแปลงในอดีตไว้สูงมาก

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

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

ดังนั้นจึงเกิดความไม่สมดุลที่สำคัญมาก: ผลลัพธ์สามารถสะสมได้อย่างมีความแม่นยำสูง แต่ความสัมพันธ์เชิงเหตุและผลที่สร้างผลลัพธ์เหล่านั้นกลับถูกลดตัวอย่างอย่างต่อเนื่อง ซึ่งรุนแรงกว่าการพูดเพียงว่า “เอเจนต์จะลืมสิ่งต่างๆ”

ในกรณีของปัญหาการเข้าถึงพร้อมกัน หลังจากตัวแทนวิเคราะห์แล้ว ได้เพิ่มเข้าไปในคิว ข้อสรุปที่สมบูรณ์ที่สุดที่ตัวแทนมีในเวลานั้นคือ: มีการแข่งขันเฉพาะในเส้นทางการเขียน A ดังนั้นคิวจึงสามารถครอบคลุมเฉพาะ A เท่านั้น; เส้นทางการเขียน B ต้องการความล่าช้าต่ำ จึงไม่สามารถเข้าคิวนี้ได้

รหัสบันทึก queue ทั้งหมดไว้แล้ว หลังจากดำเนินการเป็นเวลานาน สถานะการออกแบบอาจเหลือเพียง “ใช้ queue เพื่อแก้ไข race condition ที่นี่”

ต่อมา B ก็เกิดข้อผิดพลาดแบบสุ่มขึ้นเช่นกัน เมื่อเอเจนต์อ่านโค้ดอีกครั้ง จึง自然而然เชื่อม B เข้ากับคิวที่มีอยู่แล้ว

จากนั้นความล่าช้าเพิ่มขึ้น จึงเพิ่ม bypass อีกครั้ง bypass กลับก่อให้เกิดความไม่สอดคล้องกันแบบสุ่ม จึงต้องเพิ่ม retry เข้าไปที่ขอบเขตภายนอก ถึงจุดนี้ การเปลี่ยนแปลงใดๆ ก็ไม่ได้ดูไร้เหตุผลอย่างแน่นอน แต่ละแพตช์ดูเหมือนมีเหตุผลอย่างยิ่งในบริบทที่มองเห็นได้ในขณะนั้น อย่างไรก็ตาม โค้ดได้เปลี่ยนจาก “โมเดลการประมวลผลแบบขนานที่ชัดเจน” กลายเป็น queue, bypass และ retry ที่ชดเชยกันเอง

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

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

ตัวแทนการเขียนโค้ดแปลว่า “การส่งต่อบุคลากร” เป็น “การส่งต่อบริบท” ขั้นที่ 20 และขั้นที่ 100 ดูเหมือนยังเป็นเซสชัน Claude Code เดียวกัน แต่สถานะการออกแบบที่พวกเขาได้รับนั้นไม่เหมือนกันอีกต่อไป จากมุมมองของข้อมูล ดูเหมือนว่าวิศวกรสองคนกำลังดูแลรีโพสิทอรีเดียวกันผ่านเอกสารการส่งต่อที่ค่อยๆ สั้นลง

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

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

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

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

ดังนั้นความซับซ้อนของโค้ดจึงเริ่มเพิ่มต้นทุนโทเค็น แรงกดดันจากโทเค็นกลับส่งเสริมให้มีการเก็บสถานะสั้นลงและการซ่อมแซมแบบเฉพาะจุดมากขึ้น นี่คือกลไกที่ควรระมัดระวังอย่างยิ่งเบื้องหลังปรากฏการณ์ “ยิ่งทำซ้ำยิ่งเจอปัญหามากขึ้น” ใน Agent coding

มันไม่ใช่ปัญหาของความสามารถของโมเดลเดียว แต่เป็นปัญหาของระบบที่เกี่ยวกับความไม่สอดคล้องกันของความแม่นยำในการบันทึกสถานะรหัสและสถานะการออกแบบ

ตัวแทนการเขียนโปรแกรมได้รับความสามารถในการดำเนินงานเป็นเวลานานขึ้นเรื่อยๆ แต่ “สามารถทำงานได้หลายชั่วโมง” ไม่จำเป็นต้องเป็นตัวชี้วัดความสามารถที่ดี

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

คำถามถัดไปจะกลายเป็น: หลังจากผ่านไป 50 ขั้นตอน 100 ขั้นตอน เอเจนต์ยังคงรักษาข้อมูลเชิงเหตุและผลที่มีคุณค่าสำหรับการตัดสินใจในอนาคตได้มากเพียงใด

สามารถเรียกมันว่าสถานะความถูกต้องของข้อมูล

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

บางความรู้เหมาะกับการเก็บไว้ใน memory เช่น วิธีการสร้างโปรเจกต์และนิสัยการพัฒนา; การตัดสินใจบางอย่างควรบันทึกใน ADR ที่มีโครงสร้างหรือดัชนีโค้ด; ในขณะที่สิ่งที่หากละเมิดจะทำลายขอบเขตสถาปัตยกรรมของระบบ ควรเขียนลงในประเภท การทดสอบ การ lint กฎการพึ่งพา และ CI โดยตรง

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

หากอัตราความถูกต้องต่ำ เซอร์วิสจะทำงานยิ่งนาน ก็ยิ่งฝังระเบิดให้ระบบมากขึ้น

นี่อาจเป็นเส้นแบ่งที่ Coding Agent ต้องข้ามผ่านเพื่อเปลี่ยนจาก “สามารถเขียนโค้ด” เป็น “สามารถดูแลซอฟต์แวร์ในระยะยาว”: การย้ายความรู้ด้านการออกแบบจากความจำทางภาษาที่เป็นความน่าจะเป็น ไปสู่สถานะซอฟต์แวร์ที่สามารถค้นหา ตรวจสอบ และดำเนินการได้

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

คำพูดที่พบบ่อยในรหัสดั้งเดิมคือ: “อย่าแตะส่วนนี้ ไม่รู้ว่าทำไมถึงระเบิด”

รหัสที่สืบทอดมาจาก AI อาจแปลกกว่านั้นอีก: รหัสนี้ถูกเขียนโดย Agent จริงๆ แต่ Agent ที่ตามมาไม่รู้แล้วว่าทำไม Agent ก่อนหน้าถึงเขียนแบบนี้