WikiSkill ของ Google Research: ให้เอเจนต์เขียน "วิกิ" บันทึกความผิดพลาดของตัวเอง แล้วค่อยกลั่นเป็น skill — ดัน Gemini 3.5 Flash จาก 49.5 เป็น 68.1 โดยไม่แตะน้ำหนัก

ปัญหาที่ทุกคนที่ทำเอเจนต์เจอเหมือนกันคือ เอเจนต์ไม่จำอะไรเลยระหว่างงาน รันจบแล้วร่องรอยการทำงานทั้งหมดหายไป งานถัดไปที่พลาดด้วยเหตุผลเดียวกันก็พลาดซ้ำ วงการแก้ปัญหานี้ด้วย “agent skills” — คือแพ็กความรู้เฉพาะทางกับเวิร์กโฟลว์เป็นไฟล์ที่ยัดกลับเข้าพรอมป์ต์ได้ และมีงานวิจัยหลายชิ้นที่พยายามให้ระบบ ค้นพบ skill เหล่านั้นเอง จากประสบการณ์

Google Research เผยแพร่ WikiSkill บน arXiv เมื่อวันที่ 27 สิงหาคม 2026 (arXiv 2608.27454) พร้อมข้อสังเกตว่างานก่อนหน้าพลาดจุดสำคัญไปจุดหนึ่ง — ข้อมูลเชิงลึกที่ใช้ตัดสินใจปรับ skill นั้นกระจัดกระจายอยู่ในประวัติการ optimize และถูกทิ้งไปทุกรอบ พูดง่าย ๆ คือระบบเก็บ “ผลลัพธ์” ไว้ แต่ไม่เก็บ “เหตุผลที่ทำให้ได้ผลลัพธ์นั้น”

วิธีแก้ของ WikiSkill ตรงไปตรงมาจนน่าสนใจ: ให้เอเจนต์เขียนวิกิของตัวเอง

สามชั้นที่แยกกันชัด

WikiSkill แบ่งพื้นที่ทำงานของเอเจนต์เป็นสามชั้นที่มีอายุต่างกัน:

• Raw Layer — ร่องรอยการรันดิบ ๆ ทุกเทิร์นจากรอบล่าสุด
• Wiki Layer — ความรู้ที่ถูกกลั่นแล้ว เก็บเป็นไฟล์จริงใต้ wiki/patterns/ มี index.md เป็นสารบัญ, logs.md เป็นบันทึกวิวัฒนาการรายรอบ และ skill-impact.md ที่ตามรอยว่า skill ไหนช่วยหรือไม่ช่วย
• Skill Layer — ชุด skill ที่ใช้งานอยู่จริง ซึ่งถูกยัดเข้า system prompt ของเอเจนต์เต็ม ๆ ตอนทำงาน

วงจรหนึ่งรอบทำงานแบบนี้ Wiki Maintainer รับร่องรอยที่สุ่มมาทั้งงานที่สำเร็จและล้มเหลว ทำ root cause analysis กับที่ล้ม สกัดกลยุทธ์จากที่ผ่าน แล้วเขียนเข้าหน้าวิกิด้วยการแก้แบบ patch (ต่อท้าย แทนที่ หรือแทรก) ไม่ใช่เขียนทับทั้งหน้า

จากนั้น Skill Proposer ซึ่งทำงานแบบ ReAct จะได้แค่ สารบัญวิกิ กับสรุปผลผ่าน-ตกของงานทั้งหมด แล้วต้องเรียก read_file ไปเปิดหน้าที่ตัวเองสนใจกับร่องรอยดิบเอง — ออกแบบมาแบบนี้เพื่อไม่ให้ context window ระเบิดตอนวิเคราะห์ประวัติยาว ๆ ผลลัพธ์คือข้อเสนอ อะตอม หนึ่งข้อที่แตะ skill เดียว ไม่สร้างใหม่ก็แก้ของเดิม

สุดท้ายคือ ประตูกั้น (gating) ข้อเสนอถูกเอาไปรันบน validation split ถ้าคะแนนไม่ดีกว่าสถิติที่ดีที่สุด ระบบจะย้อน skill กลับไปสถานะเดิมทันที แต่จุดสำคัญคือ วิกิไม่เคยถูกย้อนกลับ ต่อให้ข้อเสนอถูกปฏิเสธ ความรู้ที่ได้จากการลองก็ยังอยู่ให้รอบถัดไปใช้ นี่คือหัวใจของ “persistent” ในชื่อเปเปอร์

ตัวเลข: ยิ่งโมเดลเก่ง ยิ่งได้ประโยชน์

ทีมทดสอบบนห้าเบนช์มาร์กที่ครอบคลุมโดเมนต่างกันชัดเจน — LiveMathematicianBench (คณิตศาสตร์), SealQA (ค้นเว็บ), SpreadsheetBench (จัดการสเปรดชีต), OfficeQA (ถามตอบเอกสารบริบทยาว) และ ALFWorld (สภาพแวดล้อมจำลองแบบโต้ตอบ) — กับห้าโมเดล และรันกระบวนการวิวัฒน์เต็มรูปแบบซ้ำ สามรอบอิสระ แล้วรายงานค่าเฉลี่ย พร้อมทดสอบนัยสำคัญด้วย paired bootstrap ที่ p < 0.05

คะแนนเฉลี่ยห้าเบนช์มาร์ก (ไม่มี skill → WikiSkill):

โมเดล	ไม่มี skill	WikiSkill	ต่าง
Qwen-3.5-4B	26.2	38.5	+12.3
Qwen-3.5-9B	29.9	47.4	+17.5
Qwen-3.6-27B	39.4	63.3	+23.9
Gemma-4-31B	41.3	54.9	+13.6
Gemini-3.5-Flash	49.5	68.1	+18.6

เทียบกับวิธี skill-evolution ที่ดีที่สุดของแต่ละโมเดล (Trace2Skill, EvoSkill, SkillOpt) WikiSkill ยังนำอยู่ 3.3, 5.1, 10.0, 5.8 และ 12.0 จุด ตามลำดับ

ตัวอย่างที่ชัดที่สุด: Gemini-3.5-Flash บน LiveMath ขึ้นจาก 33.0 เป็น 72.6 และบน SpreadSheet จาก 50.5 เป็น 76.6 ส่วน Qwen-3.6-27B บน ALFWorld ขึ้นจาก 52.8 เป็น 77.6

ข้อค้นพบที่น่าสนใจที่สุดคือ ประโยชน์เพิ่มตามความสามารถของโมเดล ไม่ใช่ลดลง ในตระกูล Qwen ค่าเฉลี่ยที่เพิ่มไล่จาก +12.3 (4B) → +17.5 (9B) → +23.9 (27B) และบน SpreadSheet เห็นชัดกว่านั้นอีกที่ +6.5 / +9.3 / +40.9 — โมเดลที่แข็งแรงกว่าคิด skill ที่ดีกว่าและรัน skill ได้ครบกว่า ขณะเดียวกัน skill ก็ชดเชยขนาดโมเดลได้จริง: Qwen-3.5-9B พร้อม WikiSkill ทำได้ 47.4 เอาชนะ Qwen-3.6-27B ที่ไม่มี skill ซึ่งได้ 39.4

skill ย้ายข้ามโมเดลได้ — บางครั้งดีกว่า skill ที่ตัวเองคิดเอง

ตารางที่ควรอ่านที่สุดคือตาราง cross-model transfer เพราะมันตอบคำถามที่คนทำเอเจนต์อยากรู้: skill ที่โมเดลหนึ่งพัฒนา เอาไปใช้กับอีกโมเดลได้ไหม

คำตอบคือได้ และบ่อยครั้งดีกว่าของตัวเอง — skill จาก Qwen-3.6-27B ทำให้ Gemini-3.5-Flash บน LiveMath ขึ้นเป็น 73.9 ซึ่งสูงกว่า 72.6 ที่ Gemini คิด skill เอง และ skill จาก Qwen-3.5-4B (โมเดลเล็กสุด) ก็ยังดัน Gemma-4-31B บน LiveMath ไปถึง 73.1 จากฐาน 33.9

แต่มันไม่ได้ดีเสมอไป และเปเปอร์ก็ไม่ปิดบัง — skill จาก Qwen-3.5-4B ทำให้ Gemini-3.5-Flash บน SpreadSheet ร่วงจาก 50.5 เหลือ 18.1 สาเหตุที่ error analysis ระบุมีสองข้อ: หนึ่ง skill ของโมเดลเล็กเข้ารหัส วิธีหลบปัญหาระดับต่ำ เช่นคำสั่ง Python บรรทัดเดียวและกฎแปลงสตริง ซึ่งช่วยโมเดลเล็กไม่ให้รันพัง แต่ไป บล็อกไม่ให้โมเดลใหญ่เขียนสคริปต์แบบ end-to-end ที่มันทำได้ดีกว่า สอง ขั้นตอนวินิจฉัยที่แตกย่อยเกินไปทำให้เกิด tool call ซ้ำซ้อนจนงบการโต้ตอบหมดก่อนงานเสร็จ

บทเรียนที่สรุปได้คือ skill ที่ย้ายได้ดีคือ skill ที่บันทึก “ขั้นตอนทั่วไป” ส่วน skill ที่ย้ายแล้วพังคือ skill ที่บันทึก “วิธีหลบข้อจำกัดของโมเดลตัวนั้น” ซึ่งเป็นเส้นแบ่งที่ตอนนี้ยังไม่มีใครตรวจอัตโนมัติได้

วิกิคือส่วนที่สำคัญจริง และหลักฐานอยู่ในตาราง ablation

ตาราง ablation บน Gemini-3.5-Flash เป็นส่วนที่พิสูจน์ว่าชื่อเปเปอร์ไม่ได้ตั้งเล่น เมื่อ Skill Proposer ไม่มี สิทธิ์เข้าถึงวิกิ (และถอด Wiki Maintainer ออก คือไม่มีการสะสมความรู้ข้ามรอบเลย) คะแนนเฉลี่ยอยู่ที่ 48.7 พอให้สิทธิ์เข้าถึงวิกิถาวร คะแนนขึ้นเป็น 63.7 (+15.0 จุด) โดย LiveMath ขึ้นจาก 51.3 เป็น 72.6 และ SpreadsheetBench จาก 49.9 เป็น 76.6

และมีรายละเอียดที่ขัดสัญชาตญาณอยู่หนึ่งข้อ — การให้ Inference Agent เข้าถึงวิกิด้วยระหว่างเก็บ rollout กลับทำให้แย่ลง จาก 63.7 เหลือ 60.9 (LiveMath ร่วงจาก 72.6 เป็น 64.8) สมมติฐานของทีมคือเมื่อเอเจนต์ที่กำลังทำงานมองเห็นทั้ง skill และวิกิ มันไปดึงคำตอบจากวิกิโดยตรงแทนที่จะใช้ skill ทำให้ร่องรอยที่ได้ ไม่บอกอะไรเกี่ยวกับคุณภาพของ skill ค่าดีฟอลต์ของ WikiSkill จึงจงใจให้วิกิกับ Skill Proposer เท่านั้น ไม่ให้เอเจนต์ที่รันงาน

ข้อจำกัดที่เปเปอร์เขียนเอง

ควรอ่านให้ครบก่อนตื่นเต้น เปเปอร์ระบุข้อจำกัดสี่ข้อตรง ๆ

หนึ่ง — ไม่ได้ทดสอบการเลือก skill เลย ทุก skill ที่แอ็กทีฟถูกยัดเข้าพรอมป์ต์ทั้งหมด เพื่อตัดตัวแปรเรื่อง retrieval ออกจากการทดลอง ซึ่งแปลว่า ผลนี้ยังไม่บอกอะไรเกี่ยวกับสถานการณ์จริงที่มี skill หลายร้อยตัวและต้องเลือกมาใช้

สอง — เกณฑ์รับข้อเสนอเข้มเกินไป ข้อเสนอที่ไม่ทำให้คะแนน validation ขึ้นทันทีจะถูกทิ้ง ทั้งที่บางข้ออาจปูทางให้รอบถัดไป

สาม — วิกิไม่มีกลไกตัดแต่ง มันโตขึ้นเรื่อย ๆ ทั้งหน้า pattern, log และ diff ของข้อเสนอ ซึ่งจะกลายเป็นปัญหาเมื่อรันวิวัฒน์ยาว ๆ

สี่ — ไม่ครอบคลุมงาน long-horizon จริง ห้าเบนช์มาร์กมีทั้งเอกสารบริบทยาวและงานหลายขั้นก็จริง แต่ไม่มีอันไหนยาวถึงระดับหลายร้อย action หรือกินเวลาหลายชั่วโมง

ที่ต้องเพิ่มเองคือ เปเปอร์ไม่ได้ประกาศปล่อยโค้ด ไม่มีลิงก์ GitHub ในเอกสาร แปลว่าตอนนี้ยังไม่มีอะไรให้ git clone — ต่างจาก Recuris ที่เราเขียนถึงเมื่อ 26 ส.ค. ซึ่งปล่อยโค้ดใต้ Apache-2.0 พร้อมกับเปเปอร์

มุมมอง AI Curator

สิ่งที่ทำให้ WikiSkill น่าสนใจไม่ใช่ตัวเลข +18.6 จุด แต่คือ มันแยก “ประสบการณ์” ออกจาก “ทักษะ” อย่างชัดเจน ซึ่งเป็นเส้นแบ่งที่คนทำเอเจนต์ส่วนใหญ่ยังปนกันอยู่ ทุกวันนี้เวลาใครบอกว่า “ให้เอเจนต์มีความจำ” สิ่งที่ทำจริงมักคือยัดสรุปของงานเก่าเข้าไปในพรอมป์ต์ — ซึ่งเปเปอร์นี้แสดงให้เห็นด้วยตาราง ablation ว่ามันได้ผลตรงข้าม เพราะเอเจนต์จะไปหยิบคำตอบจากความจำแทนที่จะพัฒนาวิธีทำงาน ความจำที่มีประโยชน์จึงไม่ใช่ความจำที่เอเจนต์เห็น แต่เป็นความจำที่ ระบบใช้ปรับปรุงเครื่องมือของเอเจนต์

เชื่อมกับ Recuris ที่เราเขียนถึงเมื่อสี่วันก่อน จะเห็นว่ามีสองทีมจากคนละซีกโลกมาถึงข้อสรุปเดียวกันในเดือนเดียว: ทางที่คุ้มที่สุดในการทำให้เอเจนต์เก่งขึ้นตอนนี้ไม่ใช่การแตะน้ำหนักโมเดล แต่คือการแก้สิ่งที่อยู่รอบโมเดล เมื่อผลแบบนี้ปรากฏซ้ำจากงานอิสระหลายชิ้น มันเลิกเป็นเรื่องบังเอิญและกลายเป็นทิศทางที่ควรวางแผนตาม

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

ข้อแรกคือ แพตเทิร์นกลั่นความรู้แบบ patch-based บนไฟล์จริง สิ่งที่ Wiki Maintainer ทำคือสิ่งที่ทีมส่วนใหญ่ทำอยู่แล้วด้วยมือ — นั่งอ่าน log ที่เอเจนต์พัง แล้วไปแก้พรอมป์ต์ — เพียงแต่ WikiSkill ทำให้มันเป็นวงจรอัตโนมัติที่ มีประตูกั้นด้วย validation set และย้อนกลับได้ ถ้าคุณรันเอเจนต์ในโปรดักชันอยู่ตอนนี้ สิ่งที่ขาดน่าจะไม่ใช่โมเดลที่เก่งขึ้น แต่คือ validation set ที่ดีพอจะบอกได้ว่าการแก้พรอมป์ต์รอบล่าสุดทำให้ดีขึ้นหรือแย่ลง — ซึ่งเป็นของที่สร้างเองได้ในหนึ่งสัปดาห์และแทบไม่มีทีมไหนมี

ข้อสองคือ การถ่ายโอน skill ข้ามโมเดลเปิดตลาดที่ยังไม่มีใครยึด ผลที่ว่า skill จาก Qwen-3.6-27B ทำให้ Gemini-3.5-Flash เก่งกว่า skill ที่ Gemini คิดเอง แปลว่าองค์กรที่มีข้อจำกัดต้องรันโมเดลในประเทศ สามารถให้โมเดลเล็กที่รันเองในดาต้าเซ็นเตอร์ไทยทำหน้าที่ “พัฒนา skill” บนงานภาษาไทยของตัวเอง แล้วเอา skill นั้นไปใช้กับโมเดลตัวไหนก็ได้ที่เปลี่ยนไปมาตามราคา — เพราะ skill คือไฟล์ข้อความ ไม่ใช่น้ำหนัก มันจึงเป็นสินทรัพย์ที่ไม่ผูกกับผู้ขาย แต่ต้องระวังกับดักที่เปเปอร์เตือนไว้ให้ดี: skill ที่โมเดลเล็กคิดขึ้นมักบันทึก “วิธีหลบข้อจำกัดของตัวเอง” ปนมาด้วย และเมื่อย้ายไปโมเดลใหญ่ มันจะกลายเป็นโซ่ที่รั้งไว้ — กรณี SpreadSheet ที่ร่วงจาก 50.5 เหลือ 18.1 ไม่ใช่ตัวเลขเล็ก ๆ

แหล่งข่าว

• WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution — arXiv 2608.27454 (27 ส.ค. 2026)
• Google gives AI agents their own wiki so they can learn from mistakes and successes — The Decoder
• Recuris: ทำให้ agent เก่งขึ้นด้วยการวิวัฒน์ความจำแทนการเทรนใหม่ — บล็อกนี้ 26 ส.ค. 2026