Recuris: ทำให้ agent เก่งขึ้นด้วยการวิวัฒน์ "ความจำ" แทนการเทรนใหม่ — ดัน Claude Opus 5 บน τ²-Retail จาก 72.4 ไป 87.9 โดยไม่แตะน้ำหนักโมเดล

สมมติว่า agent ของคุณทำงานยาว 40 ขั้นแล้วพลาดที่ขั้นที่ 31 คำถามคือคุณจะแก้ยังไง ทางเลือกที่วงการใช้กันมาตลอดมีสองทาง — fine-tune โมเดลใหม่ (แพง ช้า และต้องมีน้ำหนัก) หรือ ไปนั่งแก้พรอมป์ต์ (ถูก เร็ว แต่เป็นการเดาที่ไม่มีใครรู้ว่าแก้ตรงจุดหรือเปล่า)

25 สิงหาคม 2026 ทีมวิจัยจาก National University of Singapore, Stanford, Oxford และ Princeton เสนอทางที่สาม ในเปเปอร์ชื่อ Recursive Experiential-Working Memory Evolution for Long-Horizon Agent Harnesses พร้อมปล่อยโค้ดใต้ Apache-2.0 บน GitHub วันเดียวกัน แนวคิดคือ: ปล่อยให้โมเดลถูกแช่แข็งไว้ แล้วไปวิวัฒน์ “ความจำ” ของมันแทน

ปัญหาที่แท้จริง — ประวัติที่ยาวขึ้นกลบสถานะของงาน

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

Recuris แยกความจำออกเป็นสองส่วนที่ทำหน้าที่ต่างกันชัดเจน:

• Working Memory — ติดตามว่าตอนนี้งานไปถึงไหน และเป็นตัว สั่ง ว่าจะหยิบทักษะไหนมาใช้
• Experiential Memory — คลังทักษะและความรู้ที่สะสมไว้

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

ลูปที่แก้เฉพาะชิ้นที่พัง และมีประตูตรวจที่โมเดลโหวตให้ตัวเองไม่ได้

ส่วนที่ผมคิดว่าออกแบบได้ดีที่สุดคือลูปการปรับปรุง เพราะมันจงใจไม่ให้ LLM ตัดสินผลงานของตัวเอง:

1. การรันแต่ละครั้งถูกบันทึกเป็น trajectory เชิงโครงสร้าง (w_t, E_t, a_t, o_t) ไม่ใช่ log ข้อความดิบ
2. meta-agent อ่าน trace นั้นแล้ว ระบุให้ได้ว่าความล้มเหลวอยู่ที่ความจำชิ้นไหน แล้ว แก้เฉพาะชิ้นนั้น — ไม่ใช่ไปขยับพรอมป์ต์ก้อนใหญ่ทั้งก้อนตามผลลัพธ์
3. ประตูตรวจแบบกำหนดได้ (deterministic validation gate) ตัดสินว่าแพตช์นั้นรอดหรือไม่ โดยใช้ หลักฐาน held-out แบบจับคู่ เท่านั้น

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

ผลพลอยได้สองอย่างที่สำคัญ: Recuris ไม่ต้องเทรน (training-free) และไม่ผูกกับโมเดล — และ ความจำที่วิวัฒน์บนโมเดลหนึ่ง ย้ายไปใช้กับอีกโมเดลได้โดยไม่ต้องแก้

ตัวเลข — และช่องที่มันไม่ได้ผล

ทดสอบบน 4 เบนช์มาร์กยาว (τ²-Retail, τ²-Airline, SkillFlow, Terminal-Bench 2.1) กับ 10 โมเดล วัดเป็น avg@4 ผลคือ ดีขึ้นใน 35 จาก 37 คู่โมเดล-เบนช์มาร์กที่รันเสร็จ ตั้งแต่โมเดลเปิด 3B ไปจนถึง frontier

โมเดล	τ²-Retail	+ Recuris	Terminal-Bench 2.1	+ Recuris
Claude Opus 5	72.4	87.9 (+15.6)	84.6	88.4 (+3.8)
GPT-5.6 Sol	58.3	76.1 (+17.8)	83.2	86.4 (+3.2)
Gemini 3.7 Flash	73.5	78.3 (+4.8)	79.8	82.4 (+2.6)
Doubao-2.0-Pro	58.1	81.4 (+23.3)	46.1	48.9 (+2.9)
Qwen3.6-27B	62.8	71.2 (+8.3)	38.8	42.1 (+3.3)
GPT-OSS-20B	50.6	60.8 (+10.2)	3.9	6.7 (+2.8)

และบน SkillFlow ซึ่งเป็นงานที่ยาวที่สุด Qwen3.6-27B ขยับจาก 42.2 ไป 58.7 (+16.6) ส่วน Doubao-2.0-Pro ขยับ +16.8 — ผู้เขียนระบุว่า ยิ่งงานยาว ส่วนต่างยิ่งกว้าง ไปถึง +32.2 จุดในงานที่ยาวที่สุด และความล้มเหลวแบบ long-horizon ลดลงได้ถึง 80%

แต่ต้องอ่านช่องที่ไม่สวยด้วย เพราะเปเปอร์ก็รายงานไว้เอง: Gemini 3.7 Flash บน τ²-Airline ตกจาก 86.5 เหลือ 85.0 (−1.5) และ Granite-4.1-3B บน SkillFlow ตกจาก 0.3 เหลือ 0.0 สองช่องนี้คือ 2 ใน 37 ที่ไม่ผ่าน สิ่งที่มันบอกคือ — เมื่อโมเดลทำงานนั้นได้ดีอยู่แล้ว การใส่ชั้นความจำเพิ่มมีต้นทุน ไม่ใช่ของฟรี Recuris ให้ผลตอบแทนสูงสุดตรงที่ งานยาวและ agent กำลังพลาดจริง ๆ

Microsoft มาถึงข้อสรุปเดียวกันจากคนละทาง

หนึ่งวันก่อนหน้า (24 สิงหาคม 2026) ทีมที่นำโดย Sungho Park ร่วมกับนักวิจัยจาก Microsoft เผยแพร่ AutoSaddler ซึ่งโจมตีปัญหาเดียวกันจากอีกมุม: แทนที่จะวิวัฒน์ความจำ มันมองว่า harness คือโค้ด แล้วสร้างแพตช์เชิงโครงสร้างเข้าไปแก้พรอมป์ต์ การตั้งค่าทูล และ control logic โดยเรียนรู้แบบ offline จาก mini-batch ของ trace ที่ล้มเหลว

ผลลัพธ์: +9.0 จุดบน GAIA2, +9.6 บน SWE-Bench Pro และ +10.0 บน Terminal-Bench 2.0 เทียบกับ harness ตั้งต้นของแต่ละเบนช์มาร์ก

ส่วนที่มีค่าที่สุดของ AutoSaddler คือ ablation ที่สรุปว่าการปรับ harness ให้ได้ผลต้องมีสามอย่าง — และทั้งสามข้อตรงกับสิ่งที่ Recuris ทำโดยไม่ได้นัดกัน:

1. ดีบักลึก ไม่ใช่สะท้อนคิดผิวเผิน (agent เขียนว่า “ครั้งหน้าจะระวังกว่านี้” ไม่ใช่การแก้)
2. แก้แบบเจาะจง ไม่ใช่แก้อิสระทั้งก้อน
3. เลือกแพตช์โดยดูการวางนัยทั่วไป ไม่ใช่ซ่อมเฉพาะ trajectory นั้น

มุมมอง AI Curator

สองเปเปอร์นี้ออกห่างกันวันเดียว จากคนละทวีป คนละสถาบัน ใช้คนละกลไก แล้วชนกับข้อสรุปเดียวกัน — ตอนนี้ headroom ที่ใหญ่ที่สุดของ agent ไม่ได้อยู่ในน้ำหนักโมเดลแล้ว แต่อยู่ในโครงนั่งร้านรอบ ๆ มัน ตัวเลข +15.6 จุดบน Claude Opus 5 โดยไม่แตะน้ำหนักเลยแม้แต่นิดเดียว คือหลักฐานที่หนักแน่นว่าโมเดล frontier ที่เราใช้กันอยู่ทุกวันนี้ ยังถูกใช้งานได้ไม่เต็มความสามารถของมันเอง เพราะ harness ที่ห่อมันไว้อ่อนเกินไป

สำหรับทีมไทย ผมคิดว่านี่เป็นข่าวที่เข้าทางเป็นพิเศษ และเหตุผลเป็นเรื่องเศรษฐศาสตร์ล้วน ๆ ทีมในไทยแทบไม่มีใครมีงบ fine-tune โมเดลขนาดใหญ่ และส่วนมากก็เรียก API ของ Anthropic/OpenAI/Google ซึ่งแตะน้ำหนักไม่ได้อยู่แล้ว แนวทางที่ปรับปรุง agent โดยไม่ต้องมีน้ำหนักโมเดลจึงเป็นแนวทางเดียวที่ทีมไทยส่วนใหญ่ทำได้จริง — และ Recuris ปล่อยโค้ดใต้ Apache-2.0 พร้อม Skill Memory package ที่วิวัฒน์เสร็จแล้วกับ evaluation split ที่แช่แข็งไว้ แปลว่ามันทำซ้ำได้ ไม่ใช่เปเปอร์ที่อ่านได้อย่างเดียว การที่ ความจำย้ายข้ามโมเดลได้ ยิ่งสำคัญ เพราะมันหมายความว่าการลงแรงปรับ harness ไม่ได้ผูกติดกับผู้ให้บริการรายใดรายหนึ่ง — วันที่คุณย้ายจาก GPT ไป Claude เพราะราคา คุณไม่ต้องเริ่มใหม่

ข้อควรระวังสองข้อ หนึ่ง — ตัวเลขพวกนี้มาจากการวิวัฒน์ความจำ บนเบนช์มาร์กนั้น ๆ ความจำที่เก่งบน τ²-Retail ไม่ได้แปลว่าจะเก่งบนโดเมนงานของคุณ สิ่งที่ควรลอกไปใช้คือ กลไก — โดยเฉพาะประตูตรวจแบบ held-out ที่ไม่ให้โมเดลโหวตให้ตัวเอง ซึ่งเป็นสิ่งที่ทีมส่วนใหญ่ข้ามไปแล้วหลอกตัวเองว่า agent ดีขึ้น สอง — การจะรัน Recuris เองต้องมี Python 3.12, Docker Compose V2 และ endpoint แบบ OpenAI-compatible ซึ่งจำเป็น แม้ตัว agent จะเป็นโมเดลเปิด เพราะ τ²-Bench ใช้ LLM จำลองผู้ใช้และ LLM ตัดสินผลที่ตรึงไว้ที่โมเดลอ้างอิง — นี่เป็นต้นทุนแฝงที่คนมักไม่คิดถึงตอนวางแผนงบประเมินผล

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

แหล่งข่าว

• Recursive Experiential-Working Memory Evolution for Long-Horizon Agent Harnesses — arXiv 2608.24876
• Gen-Verse/Recuris — GitHub (Apache-2.0)
• AutoSaddler: Automatic Harness Optimization with Durable Updates from Agent Execution Traces — arXiv 2608.23041