ความจริงที่ซ่อนอยู่ของ Coding Agent: การใช้ Token พุ่งสูงขึ้น แต่การใช้จ่ายมากไม่ได้หมายความว่าผลลัพธ์จะดีขึ้น

ในปัจจุบัน AI Agent กำลังเข้าสู่ขั้นตอนการปรับใช้ในวงกว้าง โดยเฉพาะอย่างยิ่ง Coding Agent อย่าง Claude Code, Codex, Cursor ที่มีการใช้งานแพร่หลายและได้รับความสนใจสูงที่สุด ในปีที่ผ่านมา ผลิตภัณฑ์ประเภทนี้มีการพัฒนาอย่างรวดเร็ว โดยความแม่นยำบนเกณฑ์ชี้วัด SWE-bench-verified เพิ่มขึ้นมากกว่า 78% ภายในหนึ่งปี

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

ข้อร้องเรียนเหล่านี้เผยให้เห็นปัญหาหลักหลายประการของ Coding Agent ในปัจจุบัน:

1. ความไม่โปร่งใส: รูปแบบพฤติกรรมการบริโภค Token ของ Coding Agent ไม่ชัดเจน และความแตกต่างระหว่างโมเดลต่างๆ ก็ขาดความโปร่งใส
2. ไม่มีการรับประกัน: ก่อนดำเนินการงาน เป็นการยากที่จะคาดเดาว่างานจะสำเร็จหรือไม่ แต่ไม่ว่าจะสำเร็จหรือล้มเหลว ผู้ใช้ก็ต้องจ่ายค่าทรัพยากรที่ใช้ไปแล้ว
3. คาดเดาไม่ได้: การตัดสินเชิงอัตนัยของมนุษย์เกี่ยวกับความยากของงาน สอดคล้องกับการบริโภค Token จริงหรือไม่? ตัว Agent เองสามารถประมาณการได้หรือไม่ว่างานจะใช้ Token ไปเท่าไร?

เพื่อตอบสนองต่อปัญหาเหล่านี้ นักวิจัยจากมหาวิทยาลัยมิชิแกน มหาวิทยาลัยสแตนฟอร์ด และสถาบันอื่นๆ ได้ใช้เฟรมเวิร์ก OpenHands Agent แบบโอเพนซอร์ส วิเคราะห์เส้นทางการทำงานของโมเดล前沿 8 รุ่นบน SWE-bench-verified และให้คำตอบเชิงระบบเป็นครั้งแรก

• ชื่อบทความ: How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks
• บทความ arXiv: https://arxiv.org/pdf/2604.22750
• เว็บไซต์โครงการ: https://longjubai.github.io/agent_token_consumption/

Agentic Coding มีราคาแพงแค่ไหน?

บทความเริ่มต้นด้วยการเปรียบเทียบงานที่เกี่ยวข้องกับการเขียนโค้ดสามประเภท: การใช้เหตุผลด้านโค้ด (งานใช้เหตุผลแบบโต้ตอบครั้งเดียว), การสนทนาถาม-ตอบเกี่ยวกับโค้ด (การแชทแบบหลายรอบ) และงาน Agentic Coding บน SWE-bench ผลลัพธ์พบว่างาน Agentic Coding มีอัตราส่วน Output/Input Token โดยเฉลี่ย ปริมาณ Token รวมโดยเฉลี่ย และค่าใช้จ่ายทางการเงินโดยเฉลี่ย สูงกว่างานอีกสองประเภทแบบทวีคูณ

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

ค่าใช้จ่ายของ Agentic Coding มีความสุ่มสูง และการใช้จ่ายมากขึ้นไม่ได้หมายความว่าจะทำได้ดีขึ้น

บทความได้คำนวณปริมาณ Token โดยเฉลี่ยสำหรับ 500 ปัญหาบน SWE-bench-verified และจัดเรียงตามปริมาณการบริโภคจากน้อยไปมาก จากกราฟพบว่างานที่แพงที่สุดอาจใช้ Token มากกว่างานที่ถูกที่สุดประมาณ 7 ล้าน Token และยิ่งงานมีราคาแพง ค่าเบี่ยงเบนมาตรฐานของการบริโภค Token ก็ยิ่งมากขึ้น

สำหรับการรันซ้ำหลายครั้งของงานเดียวกัน โดยเปรียบเทียบการรันที่แพงที่สุดและถูกที่สุด ผลลัพธ์พบว่าแม้จะเป็นงานเดียวกัน การรันที่แพงที่สุดก็ยังอาจแพงกว่าการรันที่ถูกที่สุดประมาณสองเท่า

การวิเคราะห์เพิ่มเติมเกี่ยวกับความสัมพันธ์ระหว่างปริมาณ Token ที่ใช้กับอัตราความแม่นยำ พบว่าการบริโภคที่มากขึ้นไม่ได้รับประกันความแม่นยำที่สูงขึ้น

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

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

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

โมเดลไหนแพง โมเดลไหนประหยัด? ประสิทธิภาพ Token ระหว่างโมเดลต่างๆ แตกต่างกันอย่างมาก

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

แปดโมเดลที่ทดสอบในบทความประกอบด้วย: GPT-5 และ GPT-5.2 ของ OpenAI, Claude Sonnet-3.7, Claude Sonnet-4 และ Claude Sonnet-4.5 ของ Anthropic, Gemini-3-Pro Preview ของ Google, Kimi-K2 ของ Moonshot AI และ Qwen3-Coder-480B ของ Alibaba แปดโมเดลนี้ครอบคลุมห้าบริษัทที่แตกต่างกัน พร้อมทั้งรวมโมเดล API แบบปิด (ซีรีส์ GPT, Claude, Gemini) และโมเดลโอเพนซอร์ส (Kimi-K2, Qwen3-Coder-480B) โดย Claude Sonnet มีสามเวอร์ชัน GPT มีสองเวอร์ชัน ซึ่งรวมถึงการเปรียบเทียบในแนวนอนข้ามบริษัท และการเปรียบเทียบในแนวตั้งระหว่างรุ่นต่างๆ ภายในตระกูลเดียวกัน

จากการสังเกตความสัมพันธ์ระหว่างการบริโภค Token และอัตราความแม่นยำของงานของโมเดลต่างๆ พบว่าความแตกต่างระหว่างโมเดลนั้นเป็นระบบ ไม่ได้เกิดจากความยากของงานที่แตกต่างกัน แต่เกิดจากนิสัยพฤติกรรมของโมเดลเอง ตัวอย่างเช่น GPT-5 และ GPT-5.2 สามารถบรรลุอัตราความแม่นยำที่ดีด้วยต้นทุน Token ที่ต่ำ ในขณะที่ Kimi-K2 มีต้นทุนสูง แต่อัตราความแม่นยำกลับไม่โดดเด่น ภายใต้ 500 งานเดียวกัน Kimi-K2 และ Claude Sonnet-4.5 ใช้ Token มากกว่า GPT-5 ประมาณ 1.5 ล้าน Token

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

มีวิธีในการคาดการณ์การบริโภค Token ของงานล่วงหน้าหรือไม่?

การตัดสินความยากของงานโดยผู้เชี่ยวชาญมนุษย์ไม่สอดคล้องกับการบริโภค Token จริงของ Agent อย่างสมบูรณ์

หลังจากเข้าใจค่าใช้จ่ายของ Agentic Coding แล้ว คำถามต่อไปคือ: ก่อนดำเนินการงาน สามารถคาดการณ์ค่าใช้จ่ายตามตัวงานเองได้หรือไม่?

บทความเริ่มต้นด้วยการวิเคราะห์ว่าระดับความยากของงานที่ผู้เชี่ยวชาญมนุษย์เข้าใจ สามารถใช้เป็นมาตรฐานในการคาดการณ์ค่าใช้จ่าย Token ของ Agent ได้หรือไม่ ใน SWE-bench-verified แต่ละงานมีระดับความยากที่标注โดยผู้เชี่ยวชาญมนุษย์ โดยแบ่งเป็นสามระดับตามเวลาที่คาดว่าจะเสร็จ: “< 15 นาที”, “15 นาที – 1 ชม.”, “> 1 ชม.” หากเวลาที่มนุษย์ใช้เทียบเท่ากับ Token ที่ Agent ใช้ ความยากของงานที่มนุษย์ประเมินจะสอดคล้องกับค่าใช้จ่าย Token ของ Agent หรือไม่?

บทความจัดเรียงงานต่างๆ ตามค่าใช้จ่าย Token และคำนวณความสัมพันธ์กับระดับความยากที่มนุษย์标注 ผลลัพธ์แสดงให้เห็นว่า Kendall tau = 0.32 ซึ่งบ่งชี้ว่าการตัดสินความยากของงานโดยผู้เชี่ยวชาญมนุษย์กับการบริโภค Token จริงของ Agent มีความสัมพันธ์กันเพียงเล็กน้อยเท่านั้น

ความไม่สอดคล้องในการรับรู้ความซับซ้อนของงาน: มุมมอง “ความยาก” ของมนุษย์และ AI นั้นแตกต่างกัน

ที่น่าสนใจคือ 6.7% ของงานที่ถูกจัดว่า “ง่าย” มีการบริโภค Token จริงสูงกว่าระดับเฉลี่ยของงาน “ยาก” ทั้งหมด ในขณะที่ 11.1% ของงาน “ยาก” มีการบริโภค Token ต่ำกว่าค่าเฉลี่ยของงาน “ง่าย” ทั้งหมด ปรากฏการณ์ที่ผิดปกตินี้แสดงให้เห็นอย่างชัดเจนว่า โปรแกรมเมอร์มนุษย์และ AI Agent มีการรับรู้ “ความซับซ้อน” ของงานในมิติที่แตกต่างกันโดยสิ้นเชิง

ให้ Agent “คิดบัญชี” เอง: การคาดการณ์การบริโภค Token ด้วยตนเองเป็นไปได้หรือไม่?

เนื่องจากการตัดสินความยากของมนุษย์กับค่าใช้จ่ายจริงของ Agent มีความเบี่ยงเบนอย่างมีนัยสำคัญ แนวคิดที่เป็นธรรมชาติคือ: สามารถให้ Agent เองคาดการณ์การบริโภค Token ของตัวเองได้หรือไม่?

สำหรับแนวคิดนี้ ผู้เขียนบทความได้ทำการทดลองการคาดการณ์ตนเอง ในการทดลองนี้ เครื่องมือทั้งหมดที่ Agent ใช้และสถาปัตยกรรมพื้นฐานยังคงไม่เปลี่ยนแปลง การเปลี่ยนแปลงเพียงอย่างเดียวเกิดขึ้นใน system prompt — โดยแทนที่คำสั่ง “แก้ปัญหา” เดิมด้วย “ประมาณการค่าใช้จ่าย” ด้วยวิธีนี้ ฟังก์ชันและคุณลักษณะของ Agent จะถูกเก็บรักษาไว้มากที่สุด ทำให้สามารถใช้เครื่องมือเดียวกันในการสำรวจ ทดสอบ และใช้เหตุผลกับ codebase หลายรอบเพื่อทำการคาดการณ์ตนเอง

ประสิทธิภาพการคาดการณ์: ความสัมพันธ์ต่ำ มีแนวโน้มประเมินต่ำเกินไป

เพื่อวัดความแม่นยำของการคาดการณ์ บทความใช้ความสัมพันธ์ระหว่างค่าใช้จ่ายที่คาดการณ์และค่าใช้จ่ายจริงเป็นตัวชี้วัดการประเมิน และบันทึก Token ที่ใช้ในการคาดการณ์เองพร้อมกัน ผลลัพธ์แสดงให้เห็นว่าค่าสัมประสิทธิ์สหสัมพันธ์สูงสุดระหว่างการคาดการณ์ของโมเดลกับค่าใช้จ่ายจริงอยู่ที่เพียง 0.39 (โดย Claude Sonnet-4.5 ในมิติ Output Token) ค่าสัมประสิทธิ์สหสัมพันธ์ของโมเดลส่วนใหญ่อยู่ระหว่าง 0.2 ถึง 0.3 นอกจากนี้ ความแม่นยำในการคาดการณ์ Output Token ของโมเดลโดยทั่วไปดีกว่าการคาดการณ์ Input Token ในด้านต้นทุน ยกเว้นโมเดล Claude Sonnet-3.7 และ Claude 4 รุ่นแรก ค่าใช้จ่ายในการคาดการณ์ของโมเดลส่วนใหญ่น้อยกว่าครึ่งหนึ่งของต้นทุนการดำเนินงานจริง ในขณะที่ต้นทุนการคาดการณ์ของ Claude Sonnet-3.7 และ Claude 4 เคยสูงกว่าต้นทุนการดำเนินงานจริงถึงสองเท่า

การวิเคราะห์เชิงลึกเพิ่มเติมพบว่าโมเดลทั้งหมดประเมินปริมาณการใช้จริงต่ำเกินไป โดยเฉพาะอย่างยิ่งการเบี่ยงเบนในการประมาณการ Input Token นั้นรุนแรงเป็นพิเศษ

สรุป: การกำหนดราคาล่วงหน้ายังคงเป็นเรื่องที่ห่างไกล

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

บทสรุป

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

ข้อมูลผู้เขียน:

Longju Bai ผู้เขียนคนแรกของบทความนี้ เป็นนักศึกษาปริญญาเอกปีที่ 1 ที่มหาวิทยาลัยมิชิแกน Jiaxin Pei ผู้เขียนที่ติดต่อได้ ปัจจุบันเป็นนักวิจัยหลังปริญญาเอกที่มหาวิทยาลัยสแตนฟอร์ด และกำลังจะเข้ารับตำแหน่งผู้ช่วยศาสตราจารย์ที่มหาวิทยาลัยเท็กซัส ออสติน ผู้ร่วมงานประกอบด้วย Zhemin Huang และ Erik Brynjolfsson จากมหาวิทยาลัยสแตนฟอร์ด Xingyao Wang จาก All Hands AI Jiao Sun จาก Google DeepMind Rada Mihalcea จากมหาวิทยาลัยมิชิแกน และ Alex Pentland จากมหาวิทยาลัยสแตนฟอร์ดและสถาบันเทคโนโลยีแมสซาชูเซตส์