AI 30 เมษายน 2569 • อ่าน 6 นาที

Gemini CLI 0.40 อัปเกรดใหญ่ — Agent เริ่มฉลาดขึ้น ประหยัดขึ้…

🚀 Gemini CLI 0.40 อัปเกรดใหญ่ — Agent เริ่มฉลาดขึ้น ประหยัดขึ้น และจำงานเป็นระบบขึ้นกว่าเดิม

รอบนี้ Gemini CLI มีอัปเดตที่ผมว่าน่าสนใจมากครับ

ไม่ใช่แค่อัปเดตแก้บั๊กธรรมดา แต่เป็นอัปเดตที่เริ่มทำให้ Gemini CLI ขยับเข้าใกล้ภาพของ “Agent CLI ที่ใช้งานจริงระยะยาว” มากขึ้น

โดยเฉพาะ 3 เรื่องใหญ่ที่ควรรู้คือ

Gemma Local Model Routing ใช้โมเดล local มาช่วยตัดสินใจว่า งานนี้ควรส่งให้โมเดลไหนทำ
Memory / Context แบบเป็นไฟล์ ทำให้ AI ไม่ได้จำแบบกล่องดำ แต่เริ่มอ่าน แก้ และจัดการ context ได้ชัดขึ้น
Auto Memory + Skills เริ่มสกัด workflow จาก session เก่า ๆ แล้วแปลงเป็น skill ที่เอากลับมาใช้ซ้ำได้

พูดง่าย ๆ คือ Gemini CLI กำลังเปลี่ยนจาก “เครื่องมือคุยกับโมเดลผ่าน Terminal” ไปเป็น “Agent Workspace” ที่เริ่มรู้จักเลือกโมเดล จัดการ memory และเรียนรู้จากงานเดิมของเรา

🧠 ปัญหาเดิมของ Agent CLI คืออะไร?

เวลาเราใช้ AI Agent ผ่าน CLI ไม่ว่าจะให้ช่วยอ่านโค้ด แก้บั๊ก วางแผน refactor หรือสร้างไฟล์ใหม่ สิ่งที่เกิดขึ้นเบื้องหลังคือ Agent ต้องตัดสินใจตลอดเวลาว่า

งานนี้ต้องคิดลึกไหม? ต้องใช้ context เยอะแค่ไหน? ต้องเรียก tool หรือเปล่า? ต้องใช้โมเดลตัวใหญ่ไหม? หรือแค่ตอบง่าย ๆ ก็พอ?

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

ทั้งในแง่ของ

quota
latency
cost
token
ความเร็วในการทำงาน
และความรู้สึกว่า “แค่งานง่าย ๆ ทำไมต้องใช้พลังเยอะขนาดนั้น”

เหมือนเราจะให้คนช่วยเปลี่ยนชื่อตัวแปรหนึ่งตัว แต่ดันเรียกทีม senior ทั้งทีมมาประชุม

มันทำได้ แต่มันไม่คุ้ม

ตรงนี้แหละที่แนวคิด Model Routing เริ่มสำคัญขึ้นมาก

🛠 Gemma Local Model Routing คืออะไร?

ใน Gemini CLI รอบนี้ มีแนวคิดที่น่าสนใจคือการใช้ Gemma ที่รันบนเครื่องเรา มาช่วยเรื่อง routing

Gemma ไม่ได้มาแทน Gemini Pro และไม่ได้แปลว่าเราจะไม่ใช้ Cloud Model แล้ว

แต่ Gemma จะเข้ามาเป็นเหมือน “ด่านคัดกรองงาน” ก่อนว่า

Prompt นี้เป็นงานง่ายไหม? เป็นงานที่ต้องคิดลึกไหม? ควรส่งไปให้โมเดลเบา ๆ จัดการพอไหม? หรือควรใช้โมเดลตัวใหญ่กว่าเพื่อคุณภาพ?

ภาพง่าย ๆ คือ

เราไม่ได้ให้โมเดลตัวแพงทำทุกอย่าง แต่ให้ระบบช่วยเลือก “โมเดลที่เหมาะกับงานที่สุด”

นี่คือจุดที่ผมว่าน่าสนใจมาก เพราะอนาคตของ AI Agent อาจไม่ได้ชนะกันที่ว่า “ใครใช้โมเดลแรงที่สุดตลอดเวลา”

แต่อาจชนะกันที่ว่า

ใครจัดงานให้ถูกโมเดล ถูกเวลา และคุ้มต้นทุนที่สุด

🔄 Model Routing: งานง่ายให้ตัวเร็ว งานยากค่อยใช้ตัวใหญ่

ลองนึกภาพแบบนี้ครับ

ถ้าเราสั่งว่า

“ช่วยสรุปไฟล์นี้ให้หน่อย” “ช่วยดู error นี้ว่าเกิดจากอะไร” “ช่วย rename function นี้ให้สื่อความหมายขึ้น” “ช่วยหาไฟล์ที่เกี่ยวข้องกับ auth ให้หน่อย”

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

แต่ถ้าเราสั่งว่า

“ช่วยวิเคราะห์ architecture ทั้งโปรเจกต์” “ช่วย refactor ระบบนี้โดยไม่ทำให้ test พัง” “ช่วยออกแบบ migration plan” “ช่วยวาง multi-agent workflow สำหรับงานนี้” “ช่วยอ่านหลายไฟล์แล้วหาสาเหตุ bug ลึก ๆ”

งานแบบนี้ควรใช้โมเดลที่ reasoning ดีขึ้น เพราะต้องเข้าใจ context หลายชั้น และต้องตัดสินใจละเอียดกว่า

Gemma Local Model Routing จึงน่าสนใจตรงที่ มันทำให้ CLI เริ่มมีสมองชั้นแรกสำหรับแยกประเภทงาน

ไม่ใช่ถามอะไรก็ส่งขึ้น cloud model แบบเดิมทั้งหมด แต่เริ่มมี logic ว่า

“งานนี้ควรใช้พลังแค่ไหนถึงจะพอดี”

💸 ทำไมเรื่องนี้ถึงช่วยให้ประหยัด?

สำหรับคนที่ใช้ AI Agent ทุกวัน จะรู้เลยว่า cost ไม่ได้มาจากคำถามใหญ่ ๆ อย่างเดียว

แต่มันมาจากคำสั่งเล็ก ๆ ที่เกิดขึ้นซ้ำ ๆ ทั้งวันด้วย

เช่น

อ่านไฟล์
สรุปไฟล์
ค้นหา pattern
อธิบาย error
ช่วยแก้คำสั่ง shell
เช็กโครงสร้าง repo
เขียน snippet เล็ก ๆ
ถามต่อเนื่องระหว่าง coding

ถ้าทุก turn ถูกส่งไปใช้โมเดลตัวใหญ่หมด ต่อให้แต่ละคำสั่งดูเล็ก แต่รวมกันทั้งวันก็หนักมาก

แนวคิด routing จึงช่วยลดการใช้พลังเกินจำเป็น งานไหนเบา ก็ไม่ต้องใช้ตัวใหญ่ งานไหนหนัก ค่อยให้ตัวเก่งลงสนาม

นี่คือแนวคิดเดียวกับการมี “ทีมงาน” มากกว่ามี “คนเก่งคนเดียว”

ไม่ใช่ให้ senior ทำทุก task แต่ให้ junior ทำงานเบื้องต้น ให้ specialist รับงานเฉพาะทาง และให้ lead เข้ามาตัดสินใจตอนงานซับซ้อนจริง ๆ

พอเอาแนวคิดนี้มาอยู่ใน AI Agent มันคือจุดเริ่มของ Agent ที่ “คุมต้นทุนเป็น”

🧠 Memory ใหม่: จาก AI ที่จำมั่ว เป็น context ที่เราอ่านออก

อีกเรื่องที่ผมชอบมากคือฝั่ง Memory / Context

หลายคนที่ใช้ AI Agent น่าจะเคยเจอปัญหานี้

เราเคยบอก Agent ไปแล้วว่าโปรเจกต์นี้ใช้ stack อะไร เคยบอกแล้วว่าห้ามแก้ไฟล์บางส่วน เคยบอกแล้วว่าต้องใช้ coding style แบบไหน เคยบอกแล้วว่าเวลารัน test ต้องใช้คำสั่งอะไร

แต่พอเปิด session ใหม่ AI ก็ลืม

หรือแย่กว่านั้นคือ มันเหมือนจำได้บางส่วน แต่จำผิด

ปัญหานี้อันตรายมากในงาน coding เพราะถ้า Agent จำ context ผิด มันไม่ได้ตอบผิดแค่ประโยคเดียว แต่มันอาจแก้โค้ดผิดทั้งชุด

Gemini CLI เลยขยับมาทางระบบ memory ที่ชัดขึ้น โดยใช้ไฟล์อย่าง GEMINI.md สำหรับเก็บ context, instruction และกติกาของโปรเจกต์

ข้อดีคือมันไม่ใช่ memory แบบดำ ๆ ที่เราไม่รู้ว่า AI จำอะไรอยู่ แต่มันเป็นไฟล์ที่เราเปิดอ่านได้ แก้ได้ และ debug ได้

📂 4-Tier Memory System เข้าใจง่าย ๆ

ระบบ memory รอบนี้มองได้เป็นหลายชั้น เพื่อแยก context ให้เหมาะกับงานมากขึ้น

📂 Project Memory เช่น ./GEMINI.md

อันนี้คือ context ระดับโปรเจกต์ เหมาะกับข้อมูลที่ทุกคนในทีมควรรู้เหมือนกัน

เช่น

โปรเจกต์นี้ใช้ Next.js
package manager ใช้ pnpm
ห้ามใช้ npm install
test ต้องรันด้วยคำสั่งนี้
coding style ของ repo นี้เป็นแบบไหน
folder ไหนห้ามแก้โดยไม่จำเป็น

เหมาะกับงานทีม เพราะเก็บไว้กับ repo ได้ Agent ที่เปิดในโปรเจกต์นี้ก็จะเข้าใจ context พื้นฐานทันที

📁 Subdirectory Memory

อันนี้เหมาะกับโปรเจกต์ใหญ่ ๆ ที่แต่ละโฟลเดอร์มีกติกาไม่เหมือนกัน

เช่น

/frontend ใช้ React + Tailwind /backend ใช้ Python + FastAPI /packages/ui เป็น shared component /infra เป็น Terraform /docs เป็นเอกสารที่ห้ามแก้ format มั่ว ๆ

ถ้ามี context เฉพาะโฟลเดอร์ Agent ก็ไม่จำเป็นต้องใช้กติกาเดียวทั้ง repo

นี่ช่วยลดอาการ AI เหมา context ผิด เช่น เอากติกา backend ไปใช้กับ frontend หรือแก้ไฟล์ infra ด้วย logic แบบเขียนแอปทั่วไป

🔒 Private / Local Memory

อันนี้คือ memory ที่อยู่เฉพาะเครื่องเรา เหมาะกับข้อมูลส่วนตัวหรือ preference ที่ไม่ควรแชร์เข้า repo ทีม

เช่น

เครื่องเรารัน test ด้วย path พิเศษ
local env ของเรา setup ไม่เหมือนคนอื่น
เราชอบให้ Agent ตอบสั้น/ยาวแบบไหน
เรามี workflow ส่วนตัวสำหรับ debug
มี note เฉพาะเครื่องที่ไม่ควร commit

จุดนี้สำคัญมาก เพราะหลายครั้งสิ่งที่เราอยากให้ AI จำ ไม่ได้แปลว่าคนทั้งทีมต้องรู้

แยก private memory ออกมาได้ ก็ช่วยให้การใช้ Agent เป็นส่วนตัวขึ้น และจัดการง่ายขึ้น

🌐 Global Memory

อันนี้คือ context ข้ามโปรเจกต์ เหมาะกับ preference ที่เราใช้ทุกงาน

เช่น

เวลาช่วยเขียนโค้ดให้คิดเรื่อง test ด้วย
ถ้าจะลบไฟล์ต้องถามก่อน
เวลาสรุป bug ให้บอก root cause ก่อน
เวลาทำเว็บให้คิดเรื่อง mobile responsive
ถ้าเจอ config อันตรายให้เตือน

Global memory ทำให้เราไม่ต้องสั่งซ้ำทุก repo เหมือนเรามี “คู่มือการทำงานกับ AI” ประจำตัว

แต่จุดที่ดีคือมันเป็นไฟล์/ระบบที่ตรวจสอบได้ ไม่ใช่ให้ AI จำแบบเรามองไม่เห็น

🛡️ Security & Performance ก็อัปเกรดด้วย

นอกจากเรื่องโมเดลกับ memory รอบนี้ยังมีงานฝั่ง security และ performance ที่น่าสนใจด้วย

เช่น

bundle ripgrep เพื่อให้ค้นหาไฟล์ได้ดีขึ้นในบางสภาพแวดล้อม
เพิ่มงานฝั่ง shell command validation
ปรับเรื่อง workspace trust
ปรับความปลอดภัยของ .env
เพิ่ม core tools allowlist
แก้ประเด็นที่เกี่ยวกับ command / tool execution
ปรับระบบ memory และ skill extraction ให้เป็นระบบขึ้น

เรื่องพวกนี้อาจฟังดูไม่หวือหวาเท่า “ใช้ Gemma local” แต่สำหรับ AI Agent สำคัญมาก

เพราะ Agent CLI ไม่ใช่ chatbot ธรรมดา มันมีสิทธิ์อ่านไฟล์ แก้ไฟล์ รันคำสั่ง เรียก tool และทำงานในเครื่องเรา

ดังนั้นคำถามสำคัญไม่ใช่แค่ว่า

“Agent เก่งขึ้นไหม?”

แต่ต้องถามด้วยว่า

“Agent ถูกควบคุมดีขึ้นไหม?” “รันคำสั่งปลอดภัยขึ้นไหม?” “เข้าใจ workspace ก่อนทำงานไหม?” “ลดโอกาสทำอะไรพังโดยไม่รู้ตัวไหม?”

AI Agent ที่ดี ไม่ควรแค่เร็ว แต่ต้องมี guardrail ที่ดีขึ้นด้วย

🔥 Smart Tip: /memory inbox

อีกฟีเจอร์ที่น่าลองมากคือ Auto Memory

แนวคิดคือ Gemini CLI สามารถดู session เก่า ๆ ที่อยู่ในเครื่องเรา แล้วพยายามสกัด workflow ที่เกิดซ้ำออกมาเป็น draft skill

เช่น

เราเคยให้ Agent แก้ปัญหา build พังแบบเดิมหลายครั้ง เคยสอนมันว่า repo นี้ต้องรัน test ยังไง เคยให้มันแก้ workflow deploy ด้วยขั้นตอนเดิม เคยมี pattern ในการ debug ที่ใช้ซ้ำบ่อย ๆ

Auto Memory จะพยายามมองว่า “อันนี้เป็นความรู้ที่ควรเก็บไว้ใช้ซ้ำไหม?”

ถ้าใช่ มันจะ draft ออกมาเป็น skill แล้วเราค่อยเปิดดูผ่านคำสั่ง

/memory inbox

ใน inbox นี้ เราไม่ได้ต้องยอมรับทุกอย่าง เราสามารถเลือกได้ว่า

อ่าน skill ที่มันเสนอ
ดูว่า source มาจาก session ไหน
promote ไปใช้จริง
เก็บเป็น user skill
เก็บเป็น workspace skill
หรือ discard ทิ้งถ้าไม่เวิร์ก

ผมชอบตรงนี้มาก เพราะมันไม่ใช่ memory แบบยัดทุกอย่างเข้าไปมั่ว ๆ

แต่มันมีขั้นตอน “ให้คนตรวจ” ก่อน AI เสนอมา เราเลือกว่าจะเอาหรือไม่เอา

แบบนี้เหมาะกับงานจริงมากกว่า เพราะไม่ใช่ทุกบทสนทนาควรกลายเป็น memory

บางอย่างเป็นแค่ปัญหาครั้งเดียว บางอย่างเป็น workaround ชั่วคราว บางอย่างอาจไม่ควรเก็บ แต่บางอย่างคือ workflow ที่ควรบันทึกไว้จริง

🧩 Skill ที่สกัดจาก session เก่า สำคัญยังไง?

ถ้าใครใช้ Hermes Agent, Claude Skills หรือ Agent Skills น่าจะเข้าใจภาพนี้เร็ว

Skill ไม่ใช่แค่ “จำว่าเราเคยพูดอะไร” แต่มันคือการเก็บ “วิธีทำงาน” เอาไว้

ตัวอย่างเช่น

วิธี setup project นี้
วิธีแก้ bug ที่เจอบ่อย
วิธี run test ให้ผ่าน
วิธี deploy แบบไม่พัง
วิธีตรวจ PR
วิธีสร้าง component ตาม style ของทีม
วิธีอ่าน log ของระบบนี้
วิธีแก้ error ประจำ repo

นี่แหละที่ทำให้ Agent ยิ่งใช้ยิ่งเข้าที่

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

แทนที่เราจะต้องสอน AI ใหม่ทุกครั้ง เราค่อย ๆ สร้าง “คู่มือทำงาน” ให้ Agent เข้าใจโปรเจกต์เรามากขึ้น

📌 จุดที่ต้องเข้าใจให้ถูก

ฟีเจอร์พวกนี้บางส่วนยังเป็น experimental และบางอย่างต้องเปิดใช้เองใน config

เช่น Local Model Routing ต้องมี Gemma / local runtime ที่ตั้งค่าไว้ Auto Memory ก็ต้องเปิด flag ก่อน ไม่ใช่อัปเดตแล้วทุกอย่างทำงานเองทั้งหมดทันที

แต่ทิศทางสำคัญกว่ามาก

เพราะมันบอกว่า Gemini CLI กำลังไปทางไหน

จากเดิมที่ CLI Agent คือเครื่องมือยิง prompt เข้าโมเดล ตอนนี้มันเริ่มกลายเป็นระบบที่มี

routing
memory
skills
local model
security guardrail
workspace context
workflow extraction

นี่คือภาพของ Agent CLI รุ่นต่อไป

สรุปสั้น ๆ

Gemini CLI 0.40 เป็นอัปเดตที่น่าจับตามาก เพราะมันไม่ได้ทำให้ Agent แค่ “ตอบเก่งขึ้น”

แต่มันทำให้ Agent เริ่มทำงานเป็นระบบขึ้น

ฉลาดเรื่องโมเดลมากขึ้น ไม่ใช่ทุกงานต้องใช้โมเดลตัวใหญ่ที่สุด
ประหยัดขึ้น เพราะ routing ช่วยเลือกโมเดลให้เหมาะกับงานมากขึ้น
จำงานเป็นระบบขึ้น ผ่าน GEMINI.md, memory หลายระดับ และ context ที่อ่าน/แก้ได้
ต่อยอดเป็น skill ได้ จาก session เก่า ๆ ที่เราทำงานจริง
ปลอดภัยและควบคุมได้มากขึ้น เพราะมีการปรับเรื่อง shell validation, workspace trust และ security หลายจุด