การรัน AI Agent ระดับล้าน Token ไม่ใช่เรื่องของความเร็ว แต่คือปัญหาในการ Review

Gemini 4 Argon เปิดให้ใช้งานโดยทั่วไปแล้วตั้งแต่วันที่ 13 ตุลาคม 2026 โดยช่วยยกระดับขีดจำกัดเอาต์พุตของ Google จาก 64K โทเค็นขึ้นเป็นราวๆ 1M โทเค็น ทำให้โมเดลสามารถ “สร้างผลลัพธ์ได้หลายแสนโทเค็นใน trajectory เดียว” ซึ่งคู่มือสำหรับนักพัฒนาของ Google ได้ระบุรายละเอียดเกี่ยวกับเรื่องนี้ไว้ โดยปกติแล้วคำขอทั่วไปจะยังคงหยุดอยู่ที่เอาต์พุต 65,536 โทเค็นตามค่าเริ่มต้น แต่หากตั้งค่า max_output_tokens ให้สูงขึ้นบน Interactions API ร่วมกับ background: true เซิร์ฟเวอร์ก็จะสร้างผลลัพธ์ต่อเนื่องไปทีละรอบสูงสุดรอบละ 64K จนกระทั่งถึงขีดจำกัดสูงสุด 1,048,576 โทเค็น ลบด้วยจำนวนโทเค็นของอินพุต ทั้งนี้ Google ได้แจ้งเตือนไว้ว่าพร้อมต์ที่มีความซับซ้อนอาจต้องใช้เวลานานหลายนาที

ประโยคที่ควรอ่านซ้ำอีกรอบในบล็อกโพสต์เปิดตัวไม่ใช่เรื่องของขีดจำกัด แต่เป็นสิ่งที่ Google นำเอาต์พุตขนาดมหึมานั้นไปใช้งานจริง Google ระบุว่าได้นำ Argon มาใช้ภายในองค์กรสำหรับการย้ายโค้ดจาก C/C++ ไปเป็น Rust ตั้งแต่ระดับ “หลายหมื่นบรรทัดในคลังโค้ดหลักอย่าง re2, libgav1 ไปจนถึงกว่า 800K บรรทัดสำหรับเคอร์เนล Fuchsia Zircon” และระบุอีกว่าการเขียนโค้ดขึ้นมาใหม่เหล่านั้นกำลัง “อยู่ระหว่างการตรวจสอบอย่างเข้มงวด ทั้งแบบอัตโนมัติและแบบแมนนวล รวมถึงการทดสอบผ่านการจำลอง (emulation testing) และการรีวิว ก่อนที่จะนำไปใช้งานจริงบนโพรดักชัน” แม้แต่แล็บที่เทรนโมเดลเองก็ยังต้องรีวิวโค้ดก่อนนำไปใช้งาน ดังนั้น ทีมที่เอเจนต์สามารถส่งผลลัพธ์กลับมาได้มากกว่าเดิมถึงสิบหกเท่า ย่อมต้องการแผนการรีวิวโค้ดก่อนที่จะเริ่มใช้งานโมเดลด้วยซ้ำ

สรุปใจความสำคัญ (TL;DR)

ขีดจำกัดเอาต์พุตระดับหนึ่งล้านโทเค็นได้ย้ายคอขวดจากการสร้างโค้ดไปสู่ขั้นตอนการตรวจรับโค้ด ในเมื่อการรันเพียงครั้งเดียวสามารถส่งผลลัพธ์กลับมาได้มหาศาลขนาดนี้ สิ่งที่ควรทำคือแบ่งงานออกเป็น Task ย่อยๆ ที่คนสามารถรีวิวจบได้ในคราวเดียว โดยแต่ละ Task ต้องมีการกำหนดนิยามของงานที่เสร็จสมบูรณ์ (definition of done) ไว้อย่างชัดเจนและมี timeout ประจำแต่ละ Task พร้อมทั้งกำหนดให้ต้องมีหลักฐานยืนยันแนบมาในทุก Task และที่สำคัญคือควรคำนวณขีดความสามารถในการรีวิว (review capacity) ให้เรียบร้อยเสียก่อน เอเจนต์มีหน้าที่ค้นคว้า ดำเนินการ ทดสอบ และรายงานผล ส่วนมนุษย์คือผู้กำหนดทิศทาง มอบหมายสิทธิ์ และตรวจรับผลลัพธ์

มีอะไรเปลี่ยนไปบ้าง เมื่อการรันเพียงครั้งเดียวส่งผลลัพธ์กลับมาได้มหาศาลขนาดนี้

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

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

นอกจากนี้ เพดานดังกล่าวยังเป็นพื้นที่แบบใช้งานร่วมกัน โดยหน้าต่างบริบทขนาด 1,048,576 โทเค็นของ Argon ครอบคลุมทั้ง input, thinking และ output เข้าด้วยกัน ดังนั้น การรันที่ต้องอ่านโค้ด 300K โทเค็น จะเหลือพื้นที่อีกประมาณ 748K สำหรับคิดและเขียนโค้ด ซึ่งปริมาณขนาดนั้นก็ยังคงมากเกินกว่าที่ใครจะมานั่งอ่านทีละบรรทัดจบในรอบเดียวอยู่ดี

ถัดมาคือเรื่องคุณภาพ ในช่วงที่มีการประกาศเปิดตัว Bloomberg รายงานโดยอ้างอิงพนักงานนิรนามของ Google ว่า Argon ยังทำผลงานได้ไม่น่าประทับใจนักในงานเขียนโค้ดและงานฝั่ง front-end เมื่อเทียบกับคะแนน benchmark ซึ่ง Google แย้งว่าข้อมูลดังกล่าวไม่ถูกต้อง อย่างไรก็ตาม ตารางของ Google เองก็แสดงให้เห็นว่า Argon ยังตามหลังอยู่สองรายการจากทั้งหมดสี่รายการในหมวด agentic coding (สามารถดูรายละเอียดได้ในบทความเปรียบเทียบของเรา) Benchmark คือสิ่งที่บ่งบอกประสิทธิภาพบนชุดข้อมูลทดสอบ แต่ diff ในโค้ดของคุณคือความเปลี่ยนแปลงที่เกิดขึ้นจริงใน codebase และสิ่งนี้จะได้รับการอนุมัติหรือไม่นั้นขึ้นอยู่กับหลักฐาน ไม่ว่าโมเดลตัวไหนจะเป็นผู้เขียนก็ตาม

กำหนดขอบเขตที่ตัว Task ไม่ใช่โควตาโทเค็น

หน่วยที่คุณควรควบคุมคือ Task ไม่ใช่จำนวนโทเค็น หากปล่อยให้ขีดจำกัดของโมเดลเป็นตัวกำหนดขนาดของงาน คุณก็จะได้ผลลัพธ์ขนาดใหญ่ที่สุดเท่าที่มันจะสร้างได้ แต่หากคุณกำหนดขอบเขตด้วยตัวเอง คุณจะได้ผลงานในระดับที่มนุษย์สามารถตรวจรับได้ แม้แต่แนวทางปฏิบัติของ Google เองก็เห็นพ้องในเรื่องนี้ นั่นคือให้คงค่าเริ่มต้น 65,536 เอาไว้สำหรับงานทั่วไป และใช้ background mode ที่ 131,072 หรือ 262,144 โทเค็นสำหรับงานที่ต้องใช้เหตุผลเชิงลึกและการเขียนโค้ดที่ซับซ้อน แทนที่จะปล่อยให้รันไปจนถึงขีดจำกัดสูงสุด

คำอธิบายของ Google เองก็แบ่งงานออกตามไลบรารีและเคอร์เนลอยู่แล้ว ดังนั้น ในการย้ายโค้ดจึงควรแบ่งงานในลักษณะเดียวกัน นั่นคือกำหนดหนึ่ง Task ต่อหนึ่งโมดูลเพื่อให้คนรีวิวสามารถตรวจจบได้ในคราวเดียว สำหรับ Sharkly นั่นหมายถึงการสร้าง parent Task ควบคู่ไปกับ sub-task สำหรับแต่ละโมดูล พร้อมทั้งกำหนดความสัมพันธ์แบบ “blocks / is blocked by” ในกรณีที่ต้องมีโมดูลใดเสร็จสิ้นก่อน เป้าหมาย ขอบเขต และเกณฑ์การตรวจรับทั้งหมดจะถูกระบุไว้ในคำอธิบายของ Task เพื่อให้ทั้ง Agent และคนรีวิวเข้าใจตรงกัน:

SH-412  Port the tokenizer module to Rust
Parent: SH-400  Port the parser library to Rust
Blocked by: SH-411  Port the shared buffer types

Done when:
- the Rust module replaces src/tokenizer/ and nothing outside it changes
- the existing test suite passes against the Rust build without edits
- a differential run over the fixture corpus produces identical output
- the report lists every unsafe block and the reason for it
Out of scope: public API changes, performance work

การตั้งค่า Agent สองส่วนจะช่วยสนับสนุนแนวทางนี้ ส่วนแรกคือ per-Task timeout ซึ่งควรกำหนดให้เหมาะกับ Task ไม่ใช่ขีดจำกัดของโมเดล โดยตั้งเวลาให้มากกว่าระยะเวลาทำงานจริงที่นานที่สุดของโมดูลหนึ่งๆ แต่ต้องน้อยกว่าระยะเวลาที่คุณจะรู้สึกเสียดายเงินที่จ่ายไป และส่วนที่สองคือ Max concurrency (assigned tasks) ซึ่งช่วยจำกัดจำนวนโมดูลที่กำลังทำงานอยู่พร้อมกัน เพราะหากมีสี่สิบ sub-task ทำงานพร้อมกัน ก็จะได้ผลลัพธ์สี่สิบชิ้นที่มารอกรรมการคนเดียวกันตรวจรับ

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

แนบหลักฐานไว้ใน Task เสมอ

ผลลัพธ์ชิ้นใหญ่ที่ไม่มีหลักฐานยืนยัน ไม่เรียกว่าการรีวิว แต่มันคือการสั่งรันงานซ้ำอีกรอบโดยมนุษย์ และทำได้อย่างเชื่องช้า

ตัวอย่างของ libgav1 แสดงให้เห็นว่าหลักฐานที่ดีควรเป็นอย่างไร Google ระบุว่า Argon ได้เขียนโค้ด SIMD จำนวน 32K บรรทัดขึ้นมาแทนที่ในโปรเจกต์ Rust เดิม และได้ผลลัพธ์ที่ “ทำงานเร็วกว่าโค้ดที่พอร์ตเป็น Rust เดิมถึง 2.7 เท่า โดยให้ผลลัพธ์วิดีโอเหมือนกันทุกประการ” ครึ่งหลังของประโยคนี้เองคือสิ่งที่ทำให้โค้ด 32K บรรทัดสามารถรีวิวได้ เพราะเมื่อป้อนอินพุตเดียวกันเข้าไปทั้งในโค้ดเดิมและโค้ดใหม่ ผลลัพธ์ที่ได้ออกมาตรงกันทุกประการ นี่คือ differential testing ซึ่งช่วยให้ผู้รีวิวไม่ต้องเสียเวลาไปกับการเปรียบเทียบพื้นฐาน และหันไปโฟกัสในจุดที่การเปรียบเทียบอัตโนมัติเข้าไม่ถึง เช่น โค้ด unsafe, เส้นทางการจัดการข้อผิดพลาด (error paths) และการตรวจสอบว่าประสิทธิภาพที่เร็วขึ้นนั้นคงอยู่ในการทำงานจริงหรือไม่

ทุกครั้งที่รัน ควรส่งผลลัพธ์ 4 อย่างกลับมาไว้ที่ Task เสมอ:

นี่คือรูปแบบที่เวิร์กโฟลว์ของ Sharkly กำหนดไว้ นั่นคือ Agent จะรัน typecheck, รันเทสต์ และบิลด์ จากนั้นจึงแนบสรุปการเปลี่ยนแปลง ผลการตรวจสอบยืนยัน และข้อจำกัดที่ทราบ จากนั้นมนุษย์จะเป็นผู้ตรวจรับ ขอให้แก้ไข หรือตัดสินใจเมิร์จและเผยแพร่โค้ด คำตอบสุดท้ายของ Agent จะถูกจัดเก็บไว้ใน Task ส่วนบันทึกการทำงาน (execution log) จะอยู่ในแท็บ Executions ทำให้หลักฐานทั้งหมดส่งกลับมายัง Task โดยตรง แทนที่จะค้างอยู่ในเทอร์มินัล โดยบทความการรีวิวด้วยหลักฐานระดับ Task ได้อธิบายถึงลำดับการอ่านเอาไว้ และมีเทมเพลตการส่งมอบงานเพื่อให้รายงานมีรูปแบบที่แน่นอน

การผ่านการตรวจสอบไม่ได้หมายความว่างานนั้นได้รับการยอมรับ และการเมิร์จก็ไม่ใช่เช่นกัน โดยใน Sharkly การเมิร์จ Pull Request ที่เชื่อมโยงอยู่จะไม่เปลี่ยนสถานะของ Task การตรวจสอบแบบอัตโนมัติจะตรวจสอบเฉพาะสิ่งที่มันทำได้เท่านั้น และบทความเรื่องเอเจนต์สำหรับรีวิวโค้ดด้วย AI ได้แสดงให้เห็นแล้วว่าขอบเขตของมันสิ้นสุดตรงไหน ท้ายที่สุดแล้ว มนุษย์คือผู้ตัดสินว่าการเปลี่ยนแปลงนั้นตอบโจทย์สิ่งที่ Task กำหนดไว้จริงหรือไม่

คำนวณขีดความสามารถในการรีวิวก่อนเริ่มสั่งรัน

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

หากดูเฉพาะ diff การย้ายโค้ดนี้จะต้องใช้เวลาของผู้รีวิวถึง 80 ชั่วโมง หรือคิดเป็นประมาณ 27 วันทำการ แต่หากมีหลักฐานแนบมาในทุก Task จะใช้เวลาเพียง 20 ชั่วโมง หรือประมาณ 7 วันเท่านั้น ไม่ว่าจะสั่งรันครั้งเดียวยักษ์ใหญ่หรือแบ่งเป็นสี่สิบครั้งย่อย ภาระงานฝั่งผู้รีวิวก็ยังมีปริมาณเท่าเดิม

สิ่งที่เปลี่ยนไปคือรูปแบบการตัดสินใจ การแบ่งเป็นสี่สิบ Task ช่วยให้งานทยอยเข้ามาในจังหวะที่คุณควบคุมได้ และแต่ละชิ้นจะได้รับการประเมินแยกกัน แต่หากส่งผลลัพธ์ก้อนเดียวที่รวมทั้งสี่สิบโมดูลเข้ามา จะมีคำตัดสินเพียงครั้งเดียว นั่นหมายความว่าหากเกิดปัญหาที่โมดูล 31 เพียงโมดูลเดียว ก็จะฉุดอีก 39 โมดูลที่เหลือให้พังไปด้วย ในทางกลับกัน การใช้ sub-task จะช่วยให้คุณสามารถคอมเมนต์เฉพาะโมดูลที่ไม่ผ่าน เพื่อสั่งรันแก้ไขต่อใน Task นั้นได้ทันที ในขณะที่โมดูลอื่นๆ สามารถดำเนินงานต่อไปได้ตามปกติ

จากนั้นให้คำนวณเรื่องค่าใช้จ่าย การรันแบบเต็มขีดจำกัดจะสร้างเอาต์พุตประมาณ 1M โทเค็น ซึ่งคิดเป็นค่าใช้จ่ายราว 10 ดอลลาร์ตามอัตรา 10 ดอลลาร์ต่อล้านโทเค็นจนถึงวันที่ 30 พฤศจิกายน และจะเพิ่มเป็นประมาณ 20 ดอลลาร์ตั้งแต่วันที่ 1 ธันวาคม สำหรับโปรเจกต์ระดับ Tier 1 ขีดจำกัดค่าใช้จ่ายของ Google อยู่ที่ 10 ดอลลาร์ต่อช่วงเวลา 10 นาทีแบบ rolling window ดังนั้นการรันเต็มเพดานหนึ่งครั้งจะกินโควตาเต็มเพดานของช่วงเวลานั้นตามอัตราปัจจุบัน และจะเกินเพดานถึงสองเท่าตั้งแต่วันที่ 1 ธันวาคมเป็นต้นไป จึงควรตั้งค่า Max concurrency ให้ต่ำไว้เสมอสำหรับ Agent ใดก็ตามที่ได้รับอนุญาตให้รันนานขนาดนั้น

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

เช็กลิสต์ก่อนเริ่มรันระดับล้านโทเค็นครั้งแรกของคุณ

• [ ] แบ่งงานออกเป็น Task ย่อยที่ผู้รีวิวสามารถตรวจจบได้ในคราวเดียว โดยมี sub-task และการเชื่อมโยง “blocked by” ไว้อย่างชัดเจน
• [ ] คำอธิบายของแต่ละ Task ระบุชัดเจนว่างานที่เสร็จสมบูรณ์หมายถึงอะไร และสิ่งใดที่อยู่นอกเหนือขอบเขต (out of scope)
• [ ] ตั้งค่า timeout ของแต่ละ Task ให้สอดคล้องกับตัวงาน (คำขอแบบ background ที่ยาวนานอาจใช้เวลาหลายนาที) ไม่ใช่ตั้งตามขีดจำกัดเอาต์พุตของโมเดล
• [ ] การรันแบบเต็มขีดจำกัดไม่เกินงบประมาณหรือ spend limit ของ API tier ที่คุณใช้งาน
• [ ] ตั้งค่า max concurrency สำหรับ Task ที่ได้รับมอบหมายของ Agent ให้สอดคล้องกับความสามารถที่ผู้รีวิวจะเคลียร์งานได้ ไม่ใช่ตามขีดความสามารถที่คอมพิวเตอร์รันไหว
• [ ] การรันทุกครั้งต้องส่งสรุปการเปลี่ยนแปลง, เอาต์พุตจากการตรวจสอบ, สิ่งที่ผ่านการยืนยัน และข้อจำกัดที่ทราบกลับมาเสมอ
• [ ] งานที่ต้องคงพฤติกรรมเดิมไว้ต้องมีการตรวจสอบแบบ differential เทียบกับโค้ดชุดเดิมเสมอ
• [ ] แต่ละ Task มีการระบุชื่อผู้รีวิวชัดเจน และการตรวจรับงานจะต้องมาจากการเปลี่ยนสถานะโดยบุคคลนั้นเท่านั้น ไม่ใช่เป็นผลพลอยได้จากการสั่งเมิร์จ

ไม่มีสิ่งใดในนี้ที่ขึ้นอยู่กับ Argon เพียงอย่างเดียว ซึ่งตอนนี้ API key แบบชำระเงินของ Gemini ทุกคีย์สามารถเรียกใช้ได้แล้ว ประโยคของ Google ถือเป็นพิมพ์เขียวที่ดี นั่นคือ: สร้างเอาต์พุตขนาดใหญ่ จากนั้นทำการตรวจสอบ (auditing), ทดสอบผ่านการจำลอง (emulation testing), และรีวิว แล้วจึงนำขึ้นโพรดักชัน ไม่ว่าแล็บไหนจะเปิดตัวโมเดลที่มีเอาต์พุตกระโดดข้ามขั้นเป็นรายถัดไป แผนการทำงานก็ยังคงอยู่ที่ตัว Task ไม่ใช่ที่ตัวโมเดล Sharkly ไม่ได้เป็นผู้เลือกโมเดล: ตามที่ระบุไว้ในเอกสารคู่มือของ Agents ตัว Agent จะทำงานตามโมเดลเริ่มต้นของ Runtime นั้นๆ ซึ่งปรับเปลี่ยนได้ผ่าน Custom arguments หรือการตั้งค่าของเครื่องมือ และเมื่อมีโมเดลขนาดใหญ่กว่าเข้ามายัง Runtime ที่คุณใช้งาน ค่าดังกล่าวก็จะเปลี่ยนไป แต่โครงสร้างของ Task, หลักฐานยืนยัน และด่านการรีวิวยังคงอยู่ที่เดิม ทั้งบริบท, ความคืบหน้า, ตัวบล็อกงาน, ผลลัพธ์ และการรีวิวโดยมนุษย์จะยังคงมองเห็นได้อย่างโปร่งใสตั้งแต่ขั้นตอนการขอไปจนถึงการรีลีส

หากคุณใช้งานเอเจนต์หลายตัวอยู่แล้ว Sharkly คือศูนย์กลางที่ให้คุณจัดการงานและผลลัพธ์ทั้งหมดได้ในที่เดียว