ใช้โมเดล AI ในเครื่อง (Local Models) ช่วยคัดกรองงานใน OpenClaw ได้ฟรี! 🚀

ใช้โมเดล AI ในเครื่อง (Local Models) ช่วยคัดกรองงานใน OpenClaw ได้ฟรี! 🚀ในยุคที่ AI พัฒนาไปอย่างรวดเร็ว การที่เราสามารถควบคุมและใช้งานโมเดล AI ได้ด้วยตัวเองเป็นสิ่งสำคัญอย่างยิ่ง โดยเฉพาะอย่างยิ่งเมื่อธุรกิจของคุณต้องพึ่งพาเทคโนโลยี AI เป็นหลัก การที่โมเดล AI แบบปิด (Closed Models) อาจถูกนำออกไปได้ทุกเมื่อ ทำให้การมีโมเดล AI ที่คุณสามารถรันบนเครื่องของคุณเองได้ (Local Models) เป็นทางออกที่น่าสนใจบทความนี้จะพาคุณไปดูวิธีการที่เรานำ Local Models อย่าง Gemma และ Qwen มาใช้ในระบบ Agent Harness เพื่อช่วยคัดกรองและจัดหมวดหมู่ (Classification Tasks) งานต่างๆ ใน OpenClaw ซึ่งเป็นคลังเก็บโค้ดโอเพนซอร์สขนาดใหญ่ ที่มี Issues และ Pull Requests (PRs) เข้ามาจำนวนมากในแต่ละวันทำไมต้องใช้ Local Models ในการคัดกรอง? 🤔OpenClaw เป็นโปรเจกต์โอเพนซอร์สที่รับ Issues และ PRs จำนวนมหาศาลในแต่ละวัน ซึ่งจำเป็นต้องมีการคัดกรอง จัดลำดับความสำคัญ และส่งต่อไปยังผู้ดูแล (Maintainers) อย่างรวดเร็ว โดยเฉพาะอย่างยิ่ง Issues ที่เป็นระดับ P0 (Priority 0)แม้ว่าโมเดล AI แบบปิดที่ทันสมัยที่สุดอย่าง GPT-5, Opus หรือ Sonnet จะสามารถทำงานนี้ได้ง่าย แต่การใช้งานโมเดลเหล่านี้อย่างต่อเนื่อง อาจมีค่าใช้จ่ายสูงและส่งผลต่อโควต้าการใช้งาน หากต้องตั้งค่าให้แจ้งเตือนแบบเรียลไทม์ทุกครั้งที่มีการสร้าง Issue หรือ PR ใหม่แต่ถ้าเรามีฮาร์ดแวร์ที่รองรับ (เช่น มี RAM 128 GB) การรัน Local Models บนเครื่องของเราเอง จะทำให้เราได้รับการแจ้งเตือนเกือบจะทันที และที่สำคัญคือ ฟรี! (หรืออย่างน้อยก็มีค่าใช้จ่ายแค่ค่าไฟฟ้า)วิธีการจัดหมวดหมู่ Issues และ PRs ด้วย Local Models 🏷️เรากำหนดชุดป้ายกำกับ (Labels) ที่ชัดเจนเพื่อใช้ในการจัดหมวดหมู่ Issues และ PRs จากนั้นจึงใช้ Local Models ในการจำแนกแต่ละรายการให้อยู่ในหมวดหมู่ที่ถูกต้อง เช่น localmodels, selfhostedinference, acp, agentruntime, codex, ui_tui เป็นต้นแล้วจะจำแนก Pull Requests อย่างไร? 🧐แทนที่จะใช้การเรียก API แบบง่ายๆ เราใช้ประโยชน์จาก Agents ในปี 2026 นี้ เราสามารถทำได้ดีกว่านั้น!เราได้ทดสอบ Local Models สองตัวคือ Gemma-4-26b-a4b และ Qwen-3.6-35b-a3b ซึ่งเมื่อมีการปรับปรุงประสิทธิภาพแล้ว สามารถสร้าง Token ได้หลายร้อย Token ต่อวินาทีบนเครื่องของเราเราใช้ Agent Harness ที่ชื่อว่า Pi เพื่อควบคุมการทำงานของ Local Models ผ่าน API โดย Agent นี้จะได้รับข้อมูลเบื้องต้น เช่น ชื่อ PR, เนื้อหา PR และส่วนหนึ่งของ Diff ของ PRAgent สามารถเลือกใช้เครื่องมือ bash (ซึ่งเราปรับให้ปลอดภัยขึ้นด้วย reposhell) เพื่อดำเนินการอ่านข้อมูลใน OpenClaw Repo หรือใช้เครื่องมือ final_json เพื่อส่งผลการจำแนกหมวดหมู่สุดท้ายข้อควรระวัง: เราไม่ควรให้สิทธิ์ bash แบบเต็มแก่ Local Model ในการทำงานที่มีปริมาณการใช้งานสูงเช่นนี้ เพราะอาจถูกใช้เป็นช่องทางในการโจมตี (Prompt Injection) ได้ตัวอย่างการใช้งาน Reposhell 🛠️reposhell เป็นเหมือน bash ที่ถูกจำกัดสิทธิ์ให้สามารถดำเนินการอ่านข้อมูลแบบ Read-only เท่านั้น (เช่น ls, find, cat, grep) หากโมเดลพยายามทำอะไรที่ไม่ได้รับอนุญาต ระบบจะปฏิเสธการทำงานนั้นตัวอย่างเช่น โมเดล qwen3.6-35b-a3b กำลังจำแนก openclaw/openclaw#84621 ที่มีชื่อว่า "Fix Kimi tool-call rewriting stop reason handling" ในตอนแรก โมเดลอาจคิดว่าเกี่ยวข้องกับ codingagentintegrations เพราะเห็นเส้นทางไฟล์ที่เปลี่ยนแปลง แต่เมื่อใช้ reposhell ตรวจสอบไฟล์ package.json ในไดเรกทอรีนั้น ก็พบว่าแท้จริงแล้วเป็นปลั๊กอินของ OpenClaw Kimi ทำให้โมเดลสามารถแก้ไขป้ายกำกับสุดท้ายเป็น inferenceapi และ toolcalling ได้อย่างถูกต้องการประมวลผล PRs และ Issues ที่เข้ามา ⚙️ระบบที่ Orchestrate การทำงานทั้งหมด ตั้งแต่รับ PR/Issue ไปจนถึงแจ้งเตือนบน Discord นั้นค่อนข้างเรียบง่าย โดยมีเพียงขั้นตอนการจำแนกหมวดหมู่ที่ต้องใช้ LLMการมิเรอร์ Repo: เราใช้ openclaw/gitcrawl เพื่อทำ Local Mirror ของ Repo เมื่อมี PR หรือ Issue ใหม่เข้ามา ข้อมูลจะถูกปรับให้อยู่ในรูปแบบเดียวกันและบันทึกลงในฐานข้อมูล SQLite ของ localpagerการสร้าง Job: หากรายการนั้นเป็นรายการใหม่ localpager จะสร้าง Job สำหรับการจำแนกหมวดหมู่Worker ทำงาน: Worker จะดึง Job จากคิว และสร้าง GitHub Context Object ซึ่งประกอบด้วย ชื่อ, เนื้อหา, ป้ายกำกับ, ผู้สร้าง, สถานะ ของ Issue หรือ PR รวมถึงความคิดเห็น, ไฟล์ที่เปลี่ยนแปลง และส่วนหนึ่งของ Diff (ถ้ามี)ส่ง Prompt ให้ Agent: Context Object จะถูกแปลงเป็น Prompt และส่งไปยัง localpager-agent ซึ่ง Agent นี้สามารถคิดและใช้ reposhell ได้ แต่สุดท้ายจะต้องส่งผลลัพธ์การจำแนกหมวดหมู่ตาม Schema ที่กำหนดไว้บันทึกผลและแจ้งเตือน: ผลลัพธ์จะถูกบันทึกลงในฐานข้อมูล SQLite และส่งต่อไปยัง Discord ตามนโยบายการแจ้งเตือนที่ผู้ใช้ตั้งค่าไว้สถาปัตยกรรมนี้เป็นแบบ กึ่ง Agentic โดยการติดป้ายกำกับจะใช้ Agent แต่การส่งการแจ้งเตือนจะเป็นไปตามกฎที่กำหนดไว้ เพื่อให้กระบวนการแจ้งเตือนรวดเร็วขึ้น และสงวนทรัพยากร GPU ไว้สำหรับงานที่จำเป็นจริงๆLocal Models สามารถคัดกรอง PRs ได้จริงหรือ? ✅ในเวอร์ชันแรกๆ ของระบบนี้ การทำงานอาจยังมีเสียงรบกวน (Noisy) อยู่บ้าง โมเดล gemma-4-e4b-it ที่ใช้ในการทดสอบช่วงแรกมีแนวโน้มที่จะติดป้ายกำกับที่ไม่เกี่ยวข้องจำนวนมาก ทำให้ฟีด Discord มีข้อมูลมากเกินไปเราจึงได้ทดสอบโมเดล Local Models ที่มีขนาดใหญ่ขึ้น เช่น gemma-4-26b-a4b และ qwen3.6-35b-a3b บนชุดข้อมูลประเมิน 330 รายการGemma-4-26b-a4b: มี Recall สูงกว่า และใช้เวลาต่อแถวน้อยกว่าQwen-3.6-35b-a3b: มี Precision สูงกว่า, Exact Match สูงกว่า และมี False Positives น้อยกว่าเรายังได้เปรียบเทียบกับ DeepSeek-V4-Flash ซึ่งมี False Positives น้อยที่สุด แต่ด้วยขนาดโมเดลและ Throughput ทำให้ไม่เหมาะกับการทำงานแบบเรียลไทม์บนฮาร์ดแวร์ที่เรามีการประเมินประสิทธิภาพ: เราใช้ GPT-5.5 และ Opus 4.8 เป็นเกณฑ์มาตรฐานในการประเมิน False Positives และ False Negatives โดยรันทั้ง Local Models และ SOTA Cloud Models พร้อมกันทุกๆ 2 ชั่วโมงสรุป 💡การใช้ Local Models ในการคัดกรอง Issues และ PRs ใน OpenClaw เป็นวิธีที่มีประสิทธิภาพและคุ้มค่า ทำให้เราสามารถจัดการกับปริมาณงานที่เข้ามาได้อย่างรวดเร็วและแม่นยำ โดยไม่ต้องกังวลเรื่องค่าใช้จ่ายหรือข้อจำกัดของโมเดล AI แบบปิดหากคุณกำลังมองหาวิธีปรับปรุงกระบวนการทำงานกับโปรเจกต์โอเพนซอร์ส หรือต้องการควบคุมการใช้งาน AI ได้มากขึ้น การลองนำ Local Models มาประยุกต์ใช้ อาจเป็นคำตอบที่คุณกำลังมองหาอยู่ก็เป็นได้#LocalModels #OpenSource #AI #HuggingFacehttps://huggingface.co/blog/local-models-pr-triage