kritsana.devpassing
runartifactsdocsworkhistorydispatch

© 2026 Kritsana Prasit — built from source on a self-hosted runner

resume.pdfrssdispatch

back to artifacts
category: aidate: 15 Nov 2026read: 3 min readsource: posts/grokbot-kimi-k3-multi-agent.mdxtrending

สรุป: เปลี่ยน Grokbot ให้เป็นระบบ Multi-Agent 300 ตัวด้วย Kimi K3

เพื่อนโพสต์ยาวของ Ricker บอกว่า bot เดียวฉลาดแค่ไหนก็ชนกำแพง เพราะมัน "อยู่คนเดียว" — ทางแก้ไม่ใช่สมองที่ดีขึ้น แต่คือเปลี่ยนรูปร่างงาน: ให้ Grokbot เป็น router แล้วให้ Kimi K3 ปล่อย agent วิ่งคูขนานถึง 300 ตัว สรุปให้ฟังแบบเพื่อนคุยกัน

สรุป: เปลี่ยน Grokbot ให้เป็นระบบ Multi-Agent 300 ตัวด้วย Kimi K3

เจอโพสต์ยาวของ Ricker (@0xRicker) ชื่อ "How to Turn Grokbot Into a Multi-Agent System With 300 K3 Agents (Full Guide)" อ่านจบแล้วรู้สึกว่ามันอธิบายเรื่อง multi-agent ได้ง่ายกว่าที่เคยอ่านมา เลยมาสรุปให้ฟังแบบเพื่อนเล่า — ของจริงยาวกว่านี้ ลิงก์ต้นทางอยู่ท้ายโพสต์

ปัญหา: bot เดียว = ชนกำแพง

ประโยคที่จำได้จากโพสต์คือ "Your Grokbot is smart. It is also alone, and alone is the ceiling." — ฉลาดแค่ไหนก็เถียงไม่ได้ แต่มันอยู่คนเดียว และการอยู่คนเดียวคือเพดาน

ยกตัวอย่างง่าย ๆ: ให้ bot ตัวเดียว scan ข้อมูล 80 บริษัทแล้วสรุปพร้อม recommendation ท้ายงาน มันจะอ่าน ลืมสิ่งที่อ่านไปแล้ว รีบในครึ่งหลัง แล้วส่งงานออกมาแบบ "มั่นใจแต่บาง" ประเด็นของโพสต์คือ นี่ไม่ใช่ปัญหาของโมเดล แต่เป็นปัญหาของรูปร่างงาน (shape problem): หนึ่ง agent, หนึ่ง context, หนึ่ง pass

วิธีแก้คือ multi-agent — แยกงานให้ agent หลายตัวทำเฉพาะทาง แชร์สิ่งที่เรียนรู้ และตรวจกันเอง ฟังดูต้องซอฟต์แวร์เยอะใช่ไหม ทางนั้นบอกว่าไม่แล้ว: ถ้าแบ่งถูก มันคือ prompt ไม่กี่ชุด

โครงสร้าง: Grokbot เป็น router, Kimi K3 เป็น runtime

  • Grokbot หยุดตอบตรง ๆ — ทุก request เข้าคำถามเดียวก่อน: "งานนี้มีรูปร่างแบบไหน?" แล้วส่งลง 1 ใน 4 เลน
  • Kimi K3 เป็น runtime — ปล่อย agent วิ่งขนานได้ถึง 300 ตัว ต่อ run ยาวถึง 4,000 steps context 1M tokens ใช้เป็นความจำร่วมของทั้งระบบ
  • Router ตัดสินจากรูปร่างงานเท่านั้น ไม่ต้องเก่งเรื่องหัวข้อ: ของหลายชิ้นอิสระต่อกัน? fan-out / แต่ละ step ต้องใช้ผล step ก่อน? chain / เป็นการตัดสินที่ไม่มีคำตอบถูกเดียว? debate / งานยาว มั่ว และมักพังตรงไหนสักแห่ง? supervisor

4 รูปแบบที่ครอบคลุมเกือบทุกงาน

  • Fan-out — ไปให้กว้าง: brief เดียว agent เหมือนกันหลายตัว ตัวละชิ้น ส่งผลในฟอร์แมตเดียวกัน แล้วมี agent ตัวสุดท้าย merge — 80 บริษัทจบเร็วเท่าทำ 1 บริษัท
  • Chain — ไปให้ลึก: agent ต่อกันเป็นสาย research → analysis → draft → edit ตัวใดเห็นแค่สิ่งที่ตัวเองต้องใช้ ใช้เมื่อคุณภาพขึ้นกับลำดับ
  • Debate — ทะเลาะให้รู้จริง: สองตัวเถียงกันคนละฝ่าย อีกตัวเป็นผู้พิพากษา ได้ผลเพราะ agent เดียวมักเห็นด้วยกับไอเดียแรกของตัวเอง ใช้กับการตัดสินใจ launch หรือรอ, build หรือ buy
  • Supervisor — ดักความพัง: หนึ่งตัวคุมงาน ส่ง task ให้ worker เช็กทุกผล แล้วส่งกลับพร้อมเหตุผลเมื่อพัง ใช้กับงานยาวที่อะไรก็อาจล้ม

สองกฎที่ทำให้ฝูง agent กลายเป็น "ระบบ"

  1. ความจำร่วมที่มีโครง — ทุก agent อ่านก่อนเริ่ม เขียนตอนจบ ลง 3 หมวด: facts (สิ่งที่เช็กแล้ว พร้อม source), decisions (ตัดสินอะไร เพราะอะไร), open questions (ยังไม่รู้อะไร) — ไม่มีโครง มันก็แค่ noise
  2. ฟอร์แมต hand-off เดียวกันทุกตัว — จุดพังของระบบคือตอนส่งงานต่อ ใส่ status ให้ supervisor เห็นความพังโดยไม่ต้องอ่านทุกผล และ confidence ให้ merge ถ่วงน้ำหนักแทนการปฏิบัติกับ guess และ verified fact เท่ากัน

และในระบบ 300 ตัว ของพังเป็นเรื่องปกติ — จุดต่างคือ retry ที่แถมเหตุผลไปด้วย ("หน้านี้ไม่มีราคา ลองเว็บ docs") มักสำเร็จ ส่วนที่พังซ้ำจริง ๆ ไปจบที่ open questions และถูก flag ในผลลัพธ์ ไม่ใช่เดาเงียบ ๆ

ทำไมมัน practical

Multi-agent กิน token มากกว่า แต่ Kimi K3 ราคาประมาณ 5 เท่าที่ถูกกว่า ในระดับงานเทียบเท่า และ token-efficient ทำให้ระบบนี้เป็นของ "รันใช้ประจำ" ไม่ใช่ของสะสมไว้ใช้วาระพิเศษ

ตัดต่อมาสั้น ๆ 5 ข้อ

  • อย่าเก่ง bot ให้มากขึ้น ให้เปลี่ยนรูปร่างงาน — route ก่อนรัน ถามว่างานมีรูปร่างอะไร ไม่ใช่คำตอบคืออะไร
  • 4 รูปแบบครอบคลุมเกือบหมด: fan-out, chain, debate, supervisor — งานใหม่ไม่ต้องสร้าง agent ใหม่ แค่จับใส่เลนที่ใช่
  • แชร์ความจำ + มาตรฐาน hand-off — สองกฎนี้เท่ากับเปลี่ยนฝูงให้เป็นระบบ
  • วางแผนล้ม ไม่ใช่วางแผนสมบูรณ์แบบ — retry พร้อมเหตุผล และ flag สิ่งที่ยังพัง
  • ทั้งหมดนี้ไม่มีโค้ดเลย — prompt 1 ชุด, template 4 แบบ, กฎความจำ 1 ข้อ, ฟอร์แมต 1 แบบ

อ่านต้นฉบับเต็ม ๆ (มี router prompt และ template ครบให้ก๊อป) ที่โพสต์ของ Ricker: x.com/0xRicker/status/2112903221987397874 — เขาเขียนกันบน Substack ด้วยที่ substack.com/@0xMortyx

ในมุมของเรา สิ่งที่ตรงกับที่เคยลองเล่นเองคือเรื่อง การสร้าง sub-agent — หลักคิดเรื่องแบ่งงานและ shared memory มาจากทางเดียวกัน เพียงแต่โพสต์นี้พาไปไกลถึงขนาด 300 ตัวคูขนาน

บทความนี้เป็นบทสรุปและการแปลบางส่วนจากโพสต์ต้นฉบับของ Ricker เพื่อวัตถุประสงค์การอ้างอิงและแบ่งปัน ไปยังผู้อ่านภาษาไทย เครดิตงานต้นทางเป็นของผู้เขียนเต็มที่

contents

  • ปัญหา: bot เดียว = ชนกำแพง
  • โครงสร้าง: Grokbot เป็น router, Kimi K3 เป็น runtime
  • 4 รูปแบบที่ครอบคลุมเกือบทุกงาน
  • สองกฎที่ทำให้ฝูง agent กลายเป็น "ระบบ"
  • ทำไมมัน practical
  • ตัดต่อมาสั้น ๆ 5 ข้อ

related documents

ai · 3

  • Developer ในยุค AI ในมุมของผม: งานไม่ได้หายไป แค่ย้ายจาก "พิมพ์โค้ด" ไป "ตัดสินใจและรับผิดชอบ"

    16 Nov 2026 · 2 min read

  • Gemini 4 Hydrogen: โมเดลที่ทำงานเร็วและราคาถูกสำหรับ agent workflow และการสลับโมเดลกลางคัน

    13 Nov 2026 · 4 min read

  • United Airlines แบน AI Agent จองตั๋วแทนผู้โดยสาร: การจองบัตรเครดิตผ่านบอตเริ่มมีต้นทุนจริง

    13 Nov 2026 · 2 min read

comments