Google ปล่อย Gemini 4 Argon รันข้ามคืน 11 ชั่วโมงบนโค้ด ADK 205,000 บรรทัด: เสนอ 6 จุด ทีมรับ 2 ทิ้ง 4 ลด overhead เซสชันยาว ~40% และ import เร็วขึ้น 21%
Google Developers Blog เผยแพร่บทความ (13 ต.ค. 2026) ที่ต่างจากเดโมเปิดตัวโมเดลทั่วไป แทนที่จะให้ Gemini 4 Argon สร้างแอปใหม่จากโฟลเดอร์เปล่า ทีม Google Cloud ให้มันทำงานเองข้ามคืนบน repo จริงที่ใหญ่และมีคนดูแลอยู่ คือ google/adk-python (Agent Development Kit) ซึ่งมีโค้ดราว 205,000 บรรทัด เกือบ 800 ไฟล์ และ unit test เกือบ 17,000 ตัว โจทย์คือหาและแก้คอขวดด้านประสิทธิภาพที่กระจายอยู่หลายไฟล์
ผลที่ได้ไม่ได้มีแค่ตัวเลข benchmark บทความเปิดให้ดูวิธีทำงานด้วย ทั้ง prompt ที่ใช้, การวาง .agents/skills เพื่อสอนธรรมเนียมของ repo และสัดส่วนที่คนรีวิวตัดออก Argon เสนอการแก้ไข 6 จุด ทีมรับไว้ 2 และทิ้ง 4 โค้ดที่รวมแล้วเข้า main ใน commit 1754b3e (22 ไฟล์ +956/−101 บรรทัด) ซึ่งเขียนไว้ในข้อความ commit ว่า “Argon generated these changes” commit นี้ลงวันที่ 7 ต.ค. คือก่อน Argon เปิด GA ส่วนบทความเพิ่งออกมาวันที่ 13
สองรอบ: ไม่มีคู่มือ กับมีคู่มือ
รอบแรก ไม่มีคำสั่งเฉพาะของ repo เลย มีแค่ prompt ย่อหน้าเดียวว่า “ทำให้ ADK ไม่เพิ่ม overhead ที่รู้สึกได้ ทั้งตอนเริ่ม ในเซสชันยาว และใน multi-agent/workflow ห้ามเปลี่ยนสิ่งที่โมเดลได้รับและห้ามเปลี่ยน public API ทุกการแก้ต้องมีเทสต์จับ regression” รอบนี้ใช้เวลาราว 2 ชั่วโมง Argon เขียนสคริปต์ benchmark ในนาทีที่ 7 แล้วใช้อีก 70 นาทีวัดผลและอ่านโค้ดก่อนแก้บรรทัดแรก มันเจอคอขวดจริงที่การ copy เซสชันและการ import แพ็กเกจ แต่ก็พลาดเรื่องธรรมเนียมของ maintainer หลายข้อ เช่น ไปผูก hook กับโมเดล auth จน JSON schema สาธารณะเปลี่ยนไปเล็กน้อย, รันเทสต์ใกล้ ๆ แค่ 216 ตัว และไม่ใส่ตัวเลข benchmark ในคำอธิบาย PR
รอบสอง ทีมเพิ่มของสองอย่าง อย่างแรกคือย้ายแนวทางของ maintainer ไปไว้ใน .agents/skills แต่ละ skill มี SKILL.md สั้น ๆ เป็นสารบัญ แล้วชี้ไปไฟล์ใน references/ ที่จะเปิดอ่านเมื่อจำเป็น จะได้ไม่ต้องยัดทุกอย่างใส่ context ทุก turn (ตอนนี้ใน repo มี skill อย่าง adk-architecture, adk-review, adk-style, adk-unit-guide ฯลฯ) อย่างที่สองคือเปิด /goal mode ใน Google Antigravity ซึ่งเก็บเป้าหมายไว้ข้าม context compaction ทำให้ agent ทำงานต่อได้จนจบ prompt เพิ่มมาแค่สองประโยค คือให้เปิด PR เดียวที่ maintainer น่าจะอนุมัติ ใส่ตัวเลขก่อน/หลัง และ “ห้าม merge”
Argon เริ่มตอน 21:11 และทำงานต่อเนื่อง 11 ชั่วโมง ก่อนแตะโค้ดมันอ่านไฟล์แนวทาง 12 ไฟล์และวัด baseline บน 4 workload คือ startup, บทสนทนา 200 ขั้น, แอปที่มี sub-agent 20 ตัวส่งงานต่อกัน และ workflow 12 node สามนาทีก่อนจบ มันยังตรวจ diff ของตัวเองแล้วเจอบั๊กใน cache multi-agent ที่ตัวเองเขียน จากนั้นรันเทสต์ครบ 16,892 ตัว แล้วหยุดเอง
สิ่งที่รับไว้ และสิ่งที่ถูกตัด
รับ (2 จุด):
- กรองประวัติเซสชันก่อน copy — เดิม
InMemorySessionServicedeep-copy บทสนทนาทั้งก้อนทุกครั้งที่อ่าน แม้แต่list_sessionsก็ copy ทุก event ก่อน ของใหม่กรองก่อนแล้วค่อย copy และใช้ copier ที่เร็วกว่าและรับมือ reference วนได้ แทน deep-copy ทั่วไปของ Pydantic - โหลดแพ็กเกจหนักเมื่อใช้จริง — เดิม
import google.adkดึงโมดูล live audio/video, OpenTelemetry และเว็บเซิร์ฟเวอร์มาด้วย แม้จะเป็น agent ข้อความธรรมดา บทความเล่าว่าการลบ import ตรง ๆ ทำให้เทสต์ open-source ผ่านครบ แต่ เทสต์ภายในของ Google พัง 25 target เพราะ patch attribute บนโมดูลนั้นอยู่ ตัวที่ ship จริงจึงใช้ lazy module accessor ที่ยัง patch ได้เหมือนเดิม
ตัด (4 จุด): cache ของ event แบบ multi-agent ที่ทำ benchmark สังเคราะห์เร็วขึ้น 17% แต่ใช้ weak reference ที่อาจคืนข้อมูลเก่าข้ามเซสชันได้เมื่อ Python เอา memory address กลับมาใช้ซ้ำ, การเช็ก telemetry ที่อ่าน attribute ภายในของ OpenTelemetry, การเขียนส่วนจัดรูปประวัติสนทนาใหม่ที่อ่านยากขึ้นโดย latency จริงไม่ดีขึ้น และ index สำหรับ replay workflow ที่ช่วยแค่เทสต์สังเคราะห์ ทีมสรุปไว้ว่า “agent สำรวจ ส่วน maintainer เป็นคนตัดออก”
ตัวเลขจาก benchmark ที่ Argon ไม่เคยเห็น
ทีมเขียน benchmark แยก (bench_turn.py) ไว้ก่อนเริ่มทั้งสองรอบ ใช้โมเดลและ tool แบบตอบทันที เวลาที่วัดได้จึงเป็น overhead ของ ADK ล้วน ๆ ตัวเลขใน commit มีดังนี้
| ตัวชี้วัด | ก่อน | หลัง |
|---|---|---|
| เรียกโมเดลครั้งแรกหลัง 50 turn | 64 ms | 36 ms (−43%) |
| เรียกโมเดลครั้งแรกหลัง 150 turn | 200 ms | 122 ms (−39%) |
| รันทั้งหมด 158 turn | 65.6 s | 56.1 s (−14%) |
import ADK ใน process ใหม่ | 1.22 s | 0.97 s (−21%) |
| process ใหม่ถึง request แรก | 3.07 s | 3.09 s (+1%) |
บรรทัดสุดท้ายต้องอ่านให้ดี เวลาตั้งแต่เปิด process จนถึง request แรกไม่ได้ลดลง เพราะโมดูลที่เลื่อนไว้ก็ยังต้องโหลดตอน turn แรกอยู่ดี Google จึงแนะนำให้ยิง warm-up request ก่อนเปิดรับ traffic จริง และตัวเลข −40% ใช้กับ InMemorySessionService เท่านั้น (เช่น InMemoryRunner, eval loop, CI และ deploy บน Cloud Run/GKE ที่ไม่ได้ตั้งค่า DB) ใครใช้ SQLite, Firestore, Redis หรือ DB อื่นจะไม่ได้ผลส่วนนี้
มุมมอง AI Curator
บทความนี้มีประโยชน์กว่าเดโมเปิดตัวโมเดลส่วนใหญ่ เพราะยอมให้เห็นอัตรา “เสนอ 6 รับ 2” ซึ่งเป็นตัวเลขที่ vendor ไม่ค่อยอยากเปิด และยังโชว์ว่าข้อเสนอที่ถูกตัดหลายข้อเป็นแบบที่เทสต์จับไม่ได้ เช่น weak reference ที่คืนข้อมูลผิดเซสชันได้นาน ๆ ครั้ง หรือการพึ่ง attribute ภายในของไลบรารีที่จะพังเงียบ ๆ ตอนอัปเกรด ทั้งหมดนี้ผ่านเทสต์ 16,892 ตัวได้สบาย ๆ ข้อสรุปคือ agent ที่รันข้ามคืนไม่ได้มาแทน reviewer แต่ทำให้งานรีวิวสำคัญขึ้น และต้องใช้คนที่รู้จักโค้ดเบสจริง เรื่อง 25 internal test ที่พังก็ย้ำอีกว่าเทสต์ที่ agent มองเห็นไม่เคยครอบทุกอย่างที่ผู้ใช้พึ่งพาอยู่
สิ่งที่หยิบไปใช้ได้ทันทีโดยไม่ต้องใช้ Argon คือรูปแบบ .agents/skills ที่มี SKILL.md เป็นสารบัญแล้วเปิดไฟล์ references เมื่อต้องใช้ ซึ่งตรงกับแนวคิด progressive disclosure ของ Agent Skills ที่ Claude Code และ Codex ใช้อยู่ ทีมไทยที่มี monorepo หรือโค้ด legacy ซึ่งมีกฎไม่ได้เขียนไว้ (ห้ามแตะ public schema, ใช้ lazy import, ต้องรันเทสต์ชุดไหน) ควรเขียนกฎเหล่านี้ลง repo ก่อนจะลองปล่อย agent ทำงานข้ามคืน รอบแรกของ Google ที่ไม่มีคู่มือก็เจอคอขวดจริง แต่สร้าง PR ที่ maintainer ไม่รับ อีกเรื่องที่ควรจำคือการเขียน benchmark แยกไว้ก่อนแบบที่ agent มองไม่เห็น เพราะ agent ที่ได้รับเป้าหมายเป็นตัวเลขมักหาทางทำให้ benchmark สังเคราะห์ดูดี เหมือนข้อเสนอ 2 ใน 4 ที่ถูกตัด
ข้อควรระวังคือบทความนี้เป็นเคสที่ Google เลือกมาเล่าเองบน repo ของตัวเองในวันเปิดตัวโมเดล ไม่ได้บอกว่ารันกี่ครั้งถึงได้ผลนี้ ไม่ได้บอกค่า token หรือค่าใช้จ่ายของการรัน 11 ชั่วโมง (ซึ่งน่าจะสูง เพราะ Argon ขึ้นชื่อเรื่องใช้ output token มาก) และไม่ได้เทียบกับโมเดลอื่นบนโจทย์เดียวกัน ถ้าจะใช้เป็นหลักฐานว่า Argon เก่งงาน long-horizon กว่าคู่แข่ง ยังต้องรอการวัดผลอิสระ
แหล่งข่าว
อ่านเพิ่มในหมวด เครื่องมือนักพัฒนา
Betelgeuse รัน Qwen3.8 Flash Next ขนาด 68GB บน RTX 3060 กับแรม 16GB ส่วน Basalt วัดให้เห็นว่าเอนจินที่เร่งด้วยแฟล็กลัดทำให้โมเดลลืมของ
Betelgeuse ฟอร์ก llama.cpp ที่เปิดเมื่อ 31 ต.ค. ดึง expert จาก NVMe เข้า VRAM ตามต้องการ อ้าง 22 tok/s แบบไม่ทิ้ง expert แต่ README เตือนเองว่ายังทดลองและตัวเลขมาจากคนละรอบ วันเดียวกันผู้พัฒนา Basalt เผยผลวัดว่าแฟล็กเร่งความเร็วทำคุณภาพ Q8 ตกไปใกล้ Q2
กฎห้ามโคลนเกมของ Claude Code เริ่มกระทบงานจริง บริษัทรับทำเกมกระดานร้องงานลูกค้าหยุด แต่รายงานหลายชิ้นปนกับตัวกรองไซเบอร์คนละเรื่อง
ต่อจากที่เราพบกฎนี้ในไบนารี Claude Code ผู้ใช้เริ่มรายงานว่างานเชิงพาณิชย์ถูกปฏิเสธ และ Tom's Hardware กับ Mashable หยิบไปรายงาน แต่เมื่อไล่ issue ที่อ้างถึง พบว่าหลายรายการเกิดก่อนกฎจะมา จึงน่าจะเป็นตัวกรองด้านไซเบอร์ ส่วน Anthropic ยังไม่ชี้แจง
Claude Code ส่ง transcript ของ background agent ให้โมเดลทุก ~30 วินาทีเพื่อเขียนสถานะ 3–5 คำ ผู้วัดรายงานกินราว 16% และยังปิดแบบทางการไม่ได้
รายงานอิสระพบว่าฟีเจอร์ agent_summary ของ Claude Code ส่ง transcript เต็มของ background agent ไปถามสถานะทุก ~30 วินาที คิดเป็น 16.4% ของค่าใช้จ่ายในระบบของผู้วัด Issue เปิดมาตั้งแต่ ส.ค. ยังไม่มีสวิตช์ปิดที่รองรับ เราตรวจพบโค้ดนี้ใน 2.1.314 และพบกฎใหม่เรื่องเกมที่ไม่อยู่ใน changelog