โดย Nokka (นก-กา) | 1 พ.ย. 2026
วันที่ 31 ต.ค. 2026 ตามเวลาไทย บัญชี X (Twitter) ของ Google Cloud Tech โพสต์ข้อความสั้น ๆ ว่า agent ส่วนใหญ่หยุดนิ่งเมื่อขึ้น production [1]
ทวีตนั้นยกตัวเลขสองชุดของสิ่งที่เรียกว่า Project Chrysalis [1]
- เวลาตั้งแต่เกิดเหตุถึงการบรรเทา ลดจาก 15 ถึง 45 นาที เหลือ 1.8 วินาที
- latency ที่เปอร์เซ็นไทล์ 99 ลดจาก 519.8 มิลลิวินาที เหลือ 18.2 มิลลิวินาที
ทวีตมียอดวิวราว 3.1 หมื่น ณ เวลาที่ผมอ่าน [1]
ตัวเลขพวกนี้ฟังดูเหลือเชื่อ และนั่นคือเหตุผลที่ผมไปเปิดบทความต้นทางเพื่อดูว่ามันวัดจากอะไร
ต้นทางคืออะไร
บทความชื่อ "Architecting Governed, Self-Evolving AI Agents on Google Cloud" ลงวันที่ 22 ต.ค. 2026 เขียนโดย Anant Nawalgaria ตำแหน่ง Group Product Manager และ AI Engineer ของ Google [2]
มีโค้ดเปิดให้ดูใน GitHub ของ GoogleCloudPlatform และ commit แรกของโฟลเดอร์นี้ลงวันที่ 22 ต.ค. 2026 ตรงกับวันโพสต์บทความ [3]
คำสำคัญที่ต้องเข้าใจก่อนคือคำว่า reference architecture
มันไม่ใช่ผลิตภัณฑ์ที่ขายอยู่ และไม่ใช่ระบบที่ Google ใช้รับมือเหตุจริงในวันนั้น
มันคือแบบแปลนที่ทีมหนึ่งสร้างขึ้นมาเพื่อสาธิตว่า ถ้าจะสร้างระบบแบบนี้ ควรประกอบชิ้นส่วนอย่างไร
ปัญหาที่เขาอยากแก้
ช่วงโปรโมชันใหญ่ ๆ อย่าง Black Friday ระบบที่ใช้แคช Redis อยู่หน้าฐานข้อมูลจะเจอเหตุที่เรียกว่า cache stampede [2]
ลำดับเหตุเป็นแบบนี้ [2]
- โปรโมชันกระตุ้นให้คนแห่ซื้อพร้อมกัน
- คีย์สินค้าที่ไม่ค่อยถูกใช้ถูกไล่ออกจากแคชเพราะเต็มหน่วยความจำ
- คำขอทั้งหมดไหลตรงไปที่ฐานข้อมูล
- connection pool เต็ม แล้วทุกอย่างก็ค้าง
วิศวกรที่เข้าไปแก้กลางเหตุมีเวลาไม่กี่วินาที และ playbook ที่เขียนไว้ล่วงหน้ามักไม่ครอบคลุมสถานการณ์จริง [2]
บทความเขียนตรง ๆ ว่า copilot ที่เก่งเรื่องสรุป log ยังไม่สามารถแก้เหตุบน production ได้อย่างน่าเชื่อถือ [2]
ระบบแบบ Self-Evolving ต้องทำอะไรได้
บทความวางกรอบความสามารถไว้ห้าข้อ [2]
- Diagnose หาสาเหตุที่กระจายอยู่หลายชั้น ทั้งแคชและฐานข้อมูล
- Self-patch เขียนเครื่องมือแก้ปัญหาเอง แล้วตรวจสอบและติดตั้งเข้าไปในตัวระบบที่กำลังรันอยู่
- Self-critique ให้คะแนนทุกการกระทำว่า อันไหนช่วยจริง อันไหนทำให้แย่ลง
- Remember สกัดบทเรียนที่ลงลายเซ็นกำกับไว้ เก็บเป็นความจำเชิงความหมาย
- Re-architect ปรับโครงสร้าง multi-agent ของตัวเองใหม่ โดยมีคนอนุมัติ
ข้อที่สามกับข้อที่ห้าคือหัวใจ เพราะมันเปลี่ยน agent จากผู้ช่วยที่ทำตามคำสั่ง เป็นระบบที่เรียนรู้จากผลลัพธ์ของตัวเอง
สามงานวิจัยที่เอามาประกอบกัน
ทีมผู้ออกแบบไม่ได้คิดเองทั้งหมด แต่หยิบงานวิจัยสามชิ้นมาประกอบเป็นชั้น ๆ [2]
ชั้นที่หนึ่ง Dream-RSI (arXiv 2609.14858) ใช้จำลองสถานการณ์แบบ counterfactual เพื่อลองนโยบายหลายร้อยแบบใน BigQuery ก่อนเอาไปใช้จริง 2
ชั้นที่สอง APEX (arXiv 2606.15363) แบ่งการพัฒนาตัวเองออกเป็นสามระดับเวลา ตั้งแต่ hotpatch ชั่วคราว ไปจนถึงการเขียนหลักการถาวร และการปรับโครงสร้างทีม agent 2
ชั้นที่สาม AgentEvolver (arXiv 2511.10395) คำนวณเครดิตของแต่ละขั้นตอนด้วยวิธี Shapley เพื่อแยกว่าขั้นไหนช่วย ขั้นไหนทำร้าย 2
งานวิจัยทั้งสามชิ้นมาจากคนละทีม [4] [5] [6] การเอามาประกอบเป็นชั้นเดียวคือการสังเคราะห์ของทีม Google เอง ไม่ใช่ผลงานร่วมของเปเปอร์เหล่านั้น [2]
จุดที่ผมสนใจคือชั้นที่สาม เพราะปัญหาที่คนทำ agent เจอบ่อยไม่ใช่ "agent ทำอะไรไม่ได้" แต่คือ "agent ทำหลายอย่าง แล้วเราไม่รู้ว่าอันไหนได้ผล"
ทำไมงานนี้ถึงต้องใช้ LLM ไม่ใช่สคริปต์
การหาว่าเหตุมาจากแคชหรือจาก connection pool เป็นการอ่านบริบทที่กระจัดกระจายใน telemetry หลายแหล่ง
สคริปต์ที่เขียนด้วยเงื่อนไขตายตัวทำแบบนั้นไม่ได้ เพราะมันไม่เคยเห็นรูปแบบที่ไม่ได้ถูกเขียนไว้ล่วงหน้า
LLM หรือโมเดลภาษาทำงานนี้ได้เพราะกลไก attention ทำให้มันชั่งน้ำหนักบริบททั้งชุดในคราวเดียว ไม่ได้อ่านทีละบรรทัด
ส่วน vector search ที่ใช้เก็บหลักการนั้นอาศัย embedding แปลงข้อความเป็นตัวเลข แล้ววัดความใกล้กัน
แต่ผลลัพธ์ของโมเดลคือการแจกแจงความน่าจะเป็น (probability) ไม่ใช่คำตอบที่รับประกันว่าถูก
นี่คือเหตุผลที่สถาปัตยกรรมนี้ต้องมี AST, OPA และลายเซ็น KMS คร่อมอยู่ ไม่ใช่ปล่อยให้โมเดลลงมือเอง
เดินดูเดโมทีละเฟส
เดโมจำลองเหตุการณ์สี่เฟส และทุกตัวเลขในบทความนี้มาจากส่วนนี้ [2]
เฟส 1 ก่อนมี agent
ยิงคำขอพร้อมกัน 50 รายการเข้าไปยังคีย์สินค้าเย็น 15 คีย์ ผลที่เกิดคือ [2]
อัตราการเข้าถึงแคช 100% -> 0.0% connection pool เต็ม 2 จาก 2 ช่อง latency P99 312.8 ถึง 519.8 มิลลิวินาที HTTP 500 72.7% ถึง 80.0% ในบทความต้นทาง ตัวเลขชุดนี้เขียนติดกันเป็นช่วง คือตั้งแต่ 72.7 ถึง 80.0 เปอร์เซ็นต์ ซึ่งเป็นขอบเขตของค่าที่วัดได้ ไม่ใช่ยอดที่เพิ่มขึ้น [2]
เฟส 2 agent เขียนโค้ดแก้เอง
agent ชื่อ Supervisor Router ถูกปลุกด้วยระบบแจ้งเตือน ตัวโมเดลคือ Gemini 4 Argon บน Agent Platform [2] [7]
มันวินิจฉัยว่า connection pool หมดเพราะคำขอไหลเข้าไม่จำกัด จึงเขียน middleware ชื่อ token-bucket rate limiter ขึ้นมาเอง ตั้งไว้ที่ความจุ 10 โทเคน เติม 40 คำขอต่อวินาที [2]
ก่อนติดตั้ง โค้ดต้องผ่านสามด่าน [2]
- AST visitor ตรวจว่าไม่มีโมดูลต้องห้ามหรือจุดรันโค้ดแบบไดนามิก
- OPA policy ตรวจว่าอัตราการเติมไม่ต่ำกว่า 10 คำขอต่อวินาที
- Cloud KMS ลงลายเซ็น แล้ว Binary Authorization ตรวจลายเซ็นก่อนติดตั้ง
ผลลัพธ์หลังยิงคำขอชุดที่สอง [2]
HTTP 500 0.0% connection pool 0% latency P99 18.2 มิลลิวินาที คำขอส่วนเกิน ถูกตอบ 429 เฟส 3 ให้คะแนนและจำบทเรียน
เอนจิน AgentEvolver ย้อนดูทุกช่วงการทำงาน แล้วให้คะแนน [2]
- การรีสตาร์ตฐานข้อมูลได้คะแนนติดลบ เพราะทำให้ latency พุ่งไป 3,800 มิลลิวินาที
- token bucket ที่เพิ่งเขียนได้ +0.97
จากนั้นระบบเขียนหลักการหนึ่งข้อลงใน vector search พร้อมลายเซ็น ใจความว่า เหตุ cache stampede ห้ามรีสตาร์ตฐานข้อมูล ให้ใช้การจำกัดโหลดแทน [2]
ขั้นต่อไปคือการขออนุมัติจากคน เพื่อเพิ่ม agent ผู้เชี่ยวชาญด้าน traffic shaping เข้าไปในโครงสร้างถาวร ระบบหยุดรอจนกว่าวิศวกรจะกดอนุมัติ [2]
เมื่อได้อนุมัติแล้ว มันไม่ได้แก้ไฟล์บนดิสก์ เพราะ container ใน production อย่าง GKE หรือ Cloud Run เป็น immutable
มันจึงแก้กราฟของ agent ในหน่วยความจำแทน แล้ว rebind runner ใหม่โดยไม่ต้องรีสตาร์ต [2]
เฟส 4 ทดสอบซ้ำและทดสอบแย่สุด
BigQuery รันการจำลองนโยบาย 400 แบบ ในเวลาราว 0.5 มิลลิวินาที และเลือกนโยบายที่ดีที่สุดออกมา [2]
จากนั้น agent red team จะล้างแคชทั้งหมดแล้วยิงคำขอพร้อมกัน 200 รายการ ระบบใหม่รับไหว โดยไม่มี HTTP 500 และภาระฐานข้อมูลสูงสุดอยู่ที่ 13% [2]
ด่านป้องกันสี่ชั้น
ตัวเลขไม่ได้ทำให้ผมอ่านบทความนี้จนจบ ส่วน governance ต่างหากที่ทำให้อ่านจบ
หลักการที่บทความเขียนไว้คือ agent ปรับ tactic ของตัวเองได้ แต่สิทธิ์ในการลงมือถูกจำกัดด้วยนโยบายขององค์กรและลายเซ็นเข้ารหัส [2]
สี่ด่านมีอะไรบ้าง [2]
- Model Armor และ AST sandbox กรอง prompt injection และปิดข้อมูลส่วนบุคคลก่อนเข้าสู่ลูปคิด แล้วตรวจ AST ของโค้ดที่ agent เขียนก่อนคอมไพล์
- Cloud KMS และ Binary Authorization ลงลายเซ็นและตรวจลายเซ็นก่อนติดตั้งโค้ด
- OPA และคนอนุมัติสองชั้น บังคับเพดาน SLA และหยุดรอคนกดอนุมัติสำหรับการเปลี่ยนโครงสร้าง
- Cloud Logging เก็บร่องรอยทุกครั้งที่กรอง ตรวจ หรืออนุมัติ
ด่านที่สามคือจุดที่ผมคิดว่าสำคัญที่สุด เพราะมันยอมรับว่า agent อาจตัดสินใจผิดในแบบที่ทำให้ระบบล่มเอง
สิ่งที่ตัวเลขพวกนี้ไม่ได้บอก
นี่คือส่วนที่ผมอยากให้อ่านช้า ๆ
ตัวเลขทั้งหมดมาจาก เดโมจำลอง ไม่ใช่เหตุการณ์จริงบน production ของบริษัทใด [2]
README ของโปรเจกต์ระบุชัดว่าอะไรเป็นของจริงและอะไรเป็นของจำลอง [3]
ของจริง ADK agent, Gemini เขียนโค้ด, Cloud KMS ถ้าตั้งค่า, BigQuery ถ้าตั้งค่า, Cloud Logging ของจำลอง Redis (LRU ในหน่วยความจำ), Cloud SQL (SQLite + semaphore 2 ช่อง), Model Armor (regex แทน API จริง), vector index (ในหน่วยความจำ แต่ embedding เป็นของจริง) แปลว่า ตัวเลข 18.2 มิลลิวินาที กับ 0 HTTP 500 เกิดจากระบบจำลองที่ควบคุมตัวแปรได้หมด
นั่นทำให้ผลลัพธ์นี้เป็นหลักฐานว่า สถาปัตยกรรมนี้ทำงานได้ในเงื่อนไขที่กำหนด ไม่ใช่หลักฐานว่ามันจะทำงานแบบเดียวกันบนระบบจริงที่มี traffic จริงและมีเหตุการณ์ที่ไม่มีใครคาดคิด
อีกจุดคือ 0.5 มิลลิวินาทีสำหรับ 400 นโยบาย เป็นเวลาของการคำนวณบนข้อมูลขนาดเล็ก ไม่ใช่ตัวชี้วัดว่าจะเร็วแบบนั้นกับข้อมูล production
ความเสี่ยงที่บทความไม่ได้เน้น
ผมอ่านแล้วเห็นจุดที่คนนำไปใช้ควรคิดเพิ่ม
หนึ่ง agent ที่เขียนโค้ดและติดตั้งเองได้ คือพื้นผิวโจมตีใหม่ บทความแก้เรื่องนี้ด้วย AST และลายเซ็น ซึ่งดี แต่ AST จับได้แค่รูปร่างของโค้ด ไม่ได้จับว่าโค้ดนั้นจะไปทำอะไรกับระบบ
สอง ลายเซ็น KMS ป้องกันการปลอมแปลง แต่ไม่ได้ป้องกันการตัดสินใจที่แย่ ถ้า agent เขียน patch ที่ถูกต้องตามรูปแบบแต่ผิดเชิงกลไก ด่านทั้งหมดจะปล่อยผ่าน
สาม คนยังอยู่ในลูปแค่ขั้นที่ถูกจัดว่าความเสี่ยงสูง ขั้น hotpatch ที่เร็วที่สุดกลับไม่มีคนตรวจก่อน
สี่ ตัวเลขที่ดีที่สุดของบทความมาจากสถานการณ์ที่ผู้เขียนเลือกเอง ซึ่งเป็นเรื่องปกติของงานสาธิต แต่ผู้อ่านควรรู้ว่ามันไม่ใช่ benchmark กลางที่ใครก็รันซ้ำได้ในเงื่อนไขเดียวกัน
ตัวอย่างวิธีคิดถ้าทีมคุณอยากลอง
สมมติคุณดูแลระบบ e-commerce ขนาดกลาง และกำลังคิดว่าจะเอา agent มาช่วยตอนเกิดเหตุ
คำถามที่ผมจะถามก่อนคือ
- เหตุแบบไหนที่เกิดซ้ำจนเขียน playbook ได้ ถ้ามันเกิดครั้งเดียว agent ก็เรียนรู้อะไรไม่ได้
- ขั้นไหนที่ยอมให้เครื่องตัดสินใจคนเดียวได้ และขั้นไหนต้องมีคนเซ็น
- ถ้า agent ติดตั้งโค้ดผิด คุณจะรู้ตัวภายในกี่วินาที และย้อนกลับได้ไหม
- ข้อมูล telemetry ที่ป้อนให้มัน ปิดข้อมูลส่วนบุคคลพอหรือยัง
สี่ข้อนี้ตอบได้ก่อน ค่อยไปดูว่าจะใช้ Chrysalis หรือสร้างเอง
สิ่งที่ผมยังไม่ได้ทำ
ผมยังไม่ได้รันเดโมนี้ เพราะต้องมีโปรเจกต์ Google Cloud และสิทธิ์เรียก Gemini บน Agent Platform [3]
ผมอ่านบทความต้นทางราว 1.5 หมื่นตัวอักษร อ่าน README ของ repo ตรวจว่าโฟลเดอร์มีอยู่จริงและมี commit วันที่ตรงกัน เปิดหน้า arXiv ของงานวิจัยทั้งสามชิ้น และตรวจว่า Gemini 4 Argon มีหน้าอยู่จริงในเอกสาร [4] [5] [6] [7]
ตัวเลขทุกตัวในบทนี้คัดจาก [1] และ [2] โดยตรง ไม่ได้คำนวณเพิ่ม
แหล่งอ้างอิง
[1] X · @GoogleCloudTech · ทวีต Project Chrysalis (30 ต.ค. 2026 21:15 UTC / 31 ต.ค. เวลาไทย) · https://x.com/GoogleCloudTech/status/2116277717096186261
[2] Google Developers Blog · Anant Nawalgaria · "Architecting Governed, Self-Evolving AI Agents on Google Cloud" (22 ต.ค. 2026) · https://developers.googleblog.com/architecting-governed-self-evolving-ai-agents-on-gemini-agent-platform/
[3] GitHub · GoogleCloudPlatform/generative-ai · agents/self-evolving-ai (commit 22 ต.ค. 2026) · https://github.com/GoogleCloudPlatform/generative-ai/tree/main/agents/self-evolving-ai
[4] arXiv (2026) · "Dream-RSI: Recursive Self-Improvement through Evolving Worlds" (2609.14858) · https://arxiv.org/abs/2609.14858
[5] arXiv (2026) · "APEX: Adaptive Principle EXtraction, A Three-Layer Self-Evolution Framework for Production AI Agents" (2606.15363) · https://arxiv.org/abs/2606.15363
[6] arXiv (2025) · "AgentEvolver: Towards Efficient Self-Evolving Agent System" (2511.10395) · https://arxiv.org/abs/2511.10395
[7] Google Cloud Docs · Gemini 4 Argon บน Gemini Enterprise Agent Platform (เข้าถึง 1 พ.ย. 2026) · https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/gemini/4-argon
บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)
