Hugging Face เปิด Funes ให้เอเจนต์เขียนโค้ดจำงานเก่าข้ามเครื่องมือได้ — ย้ายจาก Claude Code ไป Codex แล้วยัง recall ประวัติเดิมครบ แต่ความจำที่แชร์กันได้คือช่องทาง prompt injection

3 กันยายน 2026 Hugging Face เผยแพร่บทความแนะนำ Funes — เครื่องมือที่แก้ปัญหาซึ่งใครที่ใช้เอเจนต์เขียนโค้ดทุกวันน่าจะเจอมาแล้ว: เซสชันที่แล้วคุณกับเอเจนต์ตัดสินใจอะไรไว้ ไม่มีใครจำได้ รวมทั้งตัวเอเจนต์เอง

Funes ทำดัชนีทรานสคริปต์เซสชันเก่าจาก Claude Code, Codex, pi และ Hermes เข้าเป็นความจำก้อนเดียว แล้วติดตั้งทูล recall กับ get ให้เอเจนต์ ผลคือโมเดลหยิบใช้เองกลางงานโดยไม่ต้องสั่ง — README เขียนว่า “The model spontaneously uses funes to recall prior decisions, rationale, and findings mid-task”

จุดที่ทำให้มันต่างจากเครื่องมือความจำตัวอื่น: ความจำไม่ผูกกับเครื่องมือใดเครื่องมือหนึ่ง เริ่มงานใน Claude Code สัปดาห์หน้าไปทำต่อใน Codex — ตัวหลังจะ recall ประวัติ ทั้งหมด ไม่ใช่แค่เซสชันของตัวเอง และผลลัพธ์แต่ละชิ้นบอกด้วยว่ามาจากเอเจนต์ตัวไหน

ทำงานยังไง: ท่อเดียว ทั้งอินเด็กซ์และค้น

ตามเอกสาร Funes เป็นไบนารี Rust ตัวเดียวที่ทำงานทั้งหมดในเครื่อง:

1. แต่ละแหล่งถูกแปลงเป็นรูปแบบ turn/block กลาง — นี่คือหัวใจของดีไซน์ เพราะทุกอย่างหลังขั้นตอน parse ไม่รู้จักว่าต้นทางเป็นเอเจนต์ตัวไหน การเพิ่มเอเจนต์ใหม่จึงเท่ากับเขียน trait TraceSource หนึ่งตัว โดยไม่ต้องแตะ pipeline อินเด็กซ์หรือ query หรือถ้าเป็นเครื่องมือภายนอกก็ส่งผ่าน .parquet ตาม import contract ที่กำหนดสคีมาไว้
2. chunk แล้ว embed ด้วยโมเดล local ที่ pin เวอร์ชันไว้ เขียนลง Lance dataset ในเครื่อง
3. ตอนค้น รวม vector search กับ BM25 แล้ว fuse อันดับ, rerank ด้วย cross-encoder, และถ่วงน้ำหนักตามความใหม่

สำคัญ: Funes ไม่มีโมเดล generative ของตัวเอง มันรันแค่ embedding กับ reranking ในเครื่อง ส่วนการให้เหตุผลใช้โมเดลอะไรก็ได้ที่เอเจนต์คุณใช้อยู่ เปลี่ยนโมเดลระหว่างเซสชันแล้วความจำไม่ต้องย้ายตาม

การติดตั้งจบในสองคำสั่ง — ตัวติดตั้งตรวจแพลตฟอร์ม ดาวน์โหลดไบนารี และตรวจ checksum ของรีลีสที่ติดแท็กไว้:

curl -fsSL https://huggingface.co/buckets/huggingface/funes/resolve/install.sh | sh
funes add claude    # หรือ codex, pi, hermes

คำสั่งที่สองทำหลายอย่างในทีเดียว: ให้ทูล recall กับ get กับเอเจนต์, สร้างดัชนีแรก, และติดตั้ง hook ที่อัปเดตดัชนีทุกเทิร์น แล้วเผยแพร่ที่ขอบเซสชันถ้าผูกความจำไว้กับรีโปบน Hub

อยากลองก่อนอินเด็กซ์อะไรของตัวเองก็ได้ เพราะทีมงานเปิดความจำของโปรเจกต์ตัวเองไว้เป็น dataset สาธารณะ:

funes recall "why is funes append-only" --memory huggingface/funes-memory
funes ask claude "why is funes append-only" --memory huggingface/funes-memory

คำสั่งแรกคืน passage ที่จัดอันดับแล้ว (Funes จัดรูปเอาต์พุตเพื่อเอเจนต์ ไม่ใช่เพื่อคนอ่าน) ส่วนคำสั่ง ask คือการยืมเอเจนต์มาตอบหนึ่งคำถามโดยไม่ต้องติดตั้งอะไรเพิ่ม

ความจำเป็น dataset บน Hub — และที่ที่ต้องระวัง

ไอเดียที่ Hugging Face ผลักดันคือ ความจำของคุณคือ dataset เผยแพร่ขึ้น Hub แล้วมันกลายเป็น artifact เหมือนโมเดลหรือชุดข้อมูลอื่น — เป็นของบัญชีหรือ org ของคุณ กั้นด้วยโทเคนของคุณ อ่านได้เฉพาะคนที่คุณอนุญาต บทความสรุปแนวคิดไว้ว่า สิ่งที่ถูกแชร์ไม่ใช่แค่โค้ดของโปรเจกต์ แต่คือ กระบวนการ เบื้องหลัง — การตัดสินใจ ทางตัน และเหตุผล

รีโปที่ Funes สร้างเป็น private โดยดีฟอลต์ และการทำให้สาธารณะต้องไปกดเปลี่ยนเองบน Hub

เอกสาร SECURITY.md ตรงไปตรงมาผิดจากมาตรฐานของวงการ โดยเริ่มด้วยการยอมรับว่า Funes อินเด็กซ์ “among the most sensitive data on your machine” แล้วอธิบายมาตรการเป็นชั้น ๆ:

• ตอนอินเด็กซ์ ลบข้อมูลลับ (credential) ออกจากเซสชันก่อนบันทึก
• ตอนเผยแพร่ มีเกตที่เปิดตลอดสแกนทุก chunk ที่จะออก ด้วย trufflehog และกันแถวที่ยังมีความลับไว้ พร้อม exit ด้วยโค้ดที่ไม่ใช่ศูนย์แทนที่จะอัปโหลด เกตนี้ fail-closed — ถ้าสแกนเนอร์หายหรือพัง จะไม่มีอะไรถูกเผยแพร่เลย
• funes scrub ลบความลับออกจากแถวที่อยู่ในความจำ local แล้ว

แต่ประโยคที่สำคัญที่สุดคือประโยคที่บอกข้อจำกัด: “The gate stops future rows; it cannot unpublish.” ถ้าคีย์หลุดขึ้นไปแล้ว ขั้นตอนที่เอกสารสั่งคือ หมุนคีย์ทันทีโดยถือว่ามันถูกบุกรุกแล้ว จากนั้น scrub, ลบ dataset repo บน Hub, สร้างใหม่ แล้ว push ใหม่ — เพราะประวัติของรีโปยังเก็บค่าเดิมไว้แม้คอมมิตหลังจะลบออก

และเรื่องที่ควรพิมพ์แปะไว้ข้างจอ — การ recall จากความจำที่ไม่ใช่ของคุณ:

“A memory published by someone else is untrusted input: a malicious memory could embed instructions aimed at your agent (prompt injection).”

คำแนะนำของ Hugging Face คือ ผูก (bind) เฉพาะความจำที่คุณเชื่อถือ ส่วนการอ่านความจำของบุคคลที่สามให้ใช้แบบครั้งเดียว (funes recall "…" --memory org/repo) แทนการผูกไว้ถาวร และให้ใช้ fine-grained token — สิทธิ์เขียนเฉพาะเครื่องที่ต้อง push เท่านั้น ที่เหลืออ่านอย่างเดียว

สองข้อที่บทความไม่ได้เน้น แต่ดูได้จากรีโป

หนึ่ง: นี่ไม่ใช่วันแรกของโปรเจกต์ รีโป huggingface/funes สร้างเมื่อ 18 มิ.ย. 2026 และปล่อย v1.3.0 ไปตั้งแต่ 1 ก.ย. — บทความวันที่ 3 ก.ย. คือการ แนะนำ ต่อสาธารณะ ไม่ใช่การปล่อยครั้งแรก ตอนที่ตรวจสอบรีโปมีดาว 28 ดวง ซึ่งเป็นตัวเลขที่บอกว่าฐานผู้ใช้ยังเล็กมาก แม้เวอร์ชันจะขึ้นเลข 1 แล้ว

สอง: ยังไม่มีไบนารีสำหรับ Windows ตาราง release ใน README มีสามแพลตฟอร์ม — funes-x86_64-linux, funes-aarch64-linux และ funes-arm64-apple-darwin ไม่มี Windows ในรายการ ใครใช้ Windows ต้องผ่าน WSL หรือ build เอง (ต้องมี Rust toolchain กับ protoc เพราะ build script ของ lance คอมไพล์ protobuf ตอน build)

อีกจุดที่ควรให้เครดิตเรื่องความซื่อสัตย์: README ยอมรับข้อจำกัดของกลไกตรวจสอบไบนารีของตัวเองว่า “Because the binary and checksum share the same bucket, it does not authenticate the bucket itself.” — checksum จับไฟล์เสียหรือดาวน์โหลดไม่ครบได้ แต่ไม่ได้ยืนยันว่า bucket ต้นทางไม่ถูกแก้ เป็นคำเตือนที่โปรเจกต์ส่วนใหญ่ที่ให้ curl | sh ไม่เคยเขียนไว้

มุมมอง AI Curator

Funes ตอบคำถามที่ถูกต้อง เพราะปัญหาจริงของการใช้เอเจนต์เขียนโค้ดในปี 2026 ไม่ใช่คุณภาพโค้ดต่อเทิร์นอีกแล้ว — มันคือการที่บริบทหายไปทุกครั้งที่เปิดเซสชันใหม่ แล้วคนต้องเป็นฝ่ายเล่าประวัติศาสตร์ให้เครื่องฟังซ้ำ ๆ และการที่ Funes เลือกให้ความจำ ข้ามเครื่องมือ ไม่ใช่ผูกกับเอเจนต์ตัวใดตัวหนึ่ง คือการเดิมพันในทิศที่ถูก: ทีมส่วนใหญ่ตอนนี้ใช้เอเจนต์มากกว่าหนึ่งตัวอยู่แล้ว และไม่มีใครอยากให้ประวัติการทำงานกลายเป็นเหตุผลที่ย้ายเครื่องมือไม่ได้ ซึ่งพูดอีกทางคือ มันคือเครื่องมือกัน vendor lock-in ที่ปลอมตัวมาเป็นเครื่องมือความจำ

แต่ผมคิดว่าส่วนที่จะสร้างปัญหาในโลกจริงคือส่วนที่ดูน่าตื่นเต้นที่สุด นั่นคือ ความจำที่แชร์กันได้ ทีมงานเองก็เห็นเรื่องนี้ และเขียนเตือนไว้ตรง ๆ ว่าความจำของคนอื่นคืออินพุตที่เชื่อไม่ได้ — แต่ถ้าดูรูปทรงของช่องโหว่จะเห็นว่ามันไม่สวย: passage ที่ recall มาถูกแทรกเข้าไปใน context ของเอเจนต์ โดยที่โมเดลเป็นฝ่ายเรียกเอง กลางงาน โดยไม่มีใครกดอนุมัติ ซึ่งเป็นคุณสมบัติเด่นของเครื่องมือนี้พอดี ในวันที่มีคนเริ่มแชร์ “ความจำของทีม Django” หรือ “ความจำของโปรเจกต์ Kubernetes” กันเป็นเรื่องปกติ ระยะห่างจากตรงนั้นถึง supply-chain attack แบบใหม่มันสั้นกว่าที่คิด และมันคือรูปแบบเดียวกับที่เราเคยรายงานในเคส extension ปลอมบน VS Code Marketplace ที่กวาดรีโป 3,800 ตัวใน 18 นาที — คนเชื่อ artifact ที่ดาวน์โหลดมาเพราะมันอยู่ในรีจิสทรีที่คุ้นเคย คำแนะนำที่ผมจะให้ทีมไทยคือ ใช้แบบ per-call เท่านั้นกับความจำที่ไม่ใช่ของทีมตัวเอง อย่า bind และอย่าใช้ความจำสาธารณะเป็นค่าดีฟอลต์ของ CI

ข้อที่กระทบทีมไทยโดยตรงที่สุดกลับเป็นเรื่องน่าเบื่อกว่านั้น: ไม่มีไบนารี Windows สัดส่วนเครื่องพัฒนาในองค์กรไทยที่เป็น Windows ยังสูงกว่าค่าเฉลี่ยของวงการ open-source ตะวันตกมาก การต้องผ่าน WSL หรือ build เองด้วย Rust toolchain จะตัดคนออกไปเยอะกว่าที่ทีมพัฒนาน่าจะประเมินไว้ — ถ้ามีใครในไทยอยากมีส่วนร่วมกับโปรเจกต์ที่กำลังโตแบบเห็นผลชัด นี่เป็นช่องที่ตรงไปตรงมา

สุดท้าย มีเรื่องที่ยังไม่มีใครถามและควรถามตั้งแต่วันนี้: ความจำของเอเจนต์เป็นข้อมูลส่วนบุคคลไหมภายใต้ PDPA ทรานสคริปต์เซสชันของทีมพัฒนามักมีทั้งชื่อ อีเมล ตัวอย่างข้อมูลลูกค้าที่หลุดเข้ามาใน stack trace และบทสนทนาภายในองค์กร เกต trufflehog จับได้แค่ credential ไม่ได้จับ PII และดีฟอลต์ที่ปลอดภัย (private repo, ทุกอย่างรันในเครื่อง) จะปกป้องคุณได้ก็ต่อเมื่อไม่มีใครในทีมกด push ความจำขึ้น Hub เพื่อ “ให้เพื่อนดูหน่อย” องค์กรที่จะรับเครื่องมือนี้เข้าไป ควรเขียนนโยบายเรื่องการเผยแพร่ความจำก่อน ไม่ใช่หลัง

แหล่งข่าว

• Give Your Coding Agents a Memory You Own — Hugging Face Blog (3 ก.ย. 2026)
• huggingface/funes — GitHub (Apache-2.0)
• funes SECURITY.md — ความลับ โทเคน และ prompt injection จากความจำที่แชร์