วิธีสร้าง AI Agent Swarms (คู่มือฉบับสมบูรณ์)

นี่คือรายละเอียดแบบ A–Z ครบถ้วนของ AI Agent Swarms ว่ามันคืออะไร และใช้งานอย่างไร

เหตุใดมันถึงเปลี่ยนแปลงทุกอย่างเกี่ยวกับวิธีที่คุณทำงานกับ AI

คั่นหน้าไว้ก่อนที่คุณจะลืม

Kimi K2.6 โมเดล open-weight เรือธงของ Moonshot AI ประจำเดือนเมษายน 2026 คือการนำแนวคิดนี้ไปใช้แบบโอเพนซอร์สที่จริงจังที่สุดที่ฉันเคยเห็น

งานจริงมีขอบเขตที่กว้าง บริษัทห้าสิบแห่งที่ต้องวิจัย

ไฟล์สองร้อยไฟล์ที่ต้องวิเคราะห์ งานย่อยอีกนับสิบที่ไม่ได้พึ่งพากันและไม่ควรรอคิวกัน Agent swarm คือสถาปัตยกรรมสำหรับสิ่งนั้น

คู่มือนี้จะอธิบายว่ามันทำงานอย่างไร ตั้งแต่โครงสร้างพื้นฐานการฝึกอบรมไปจนถึง API จากนั้นจะครอบคลุมรูปแบบที่ฉันคิดว่าสำคัญที่สุดในตอนนี้: Kimi สำหรับการดำเนินการ Claude Opus 4.8 สำหรับการวางแผนและการตรวจสอบ

นี่คือลักษณะของเวิร์กโฟลว์สุดท้าย

ส่วนที่ 1: Agent swarm คืออะไร?

Agent swarm คือเอเจนต์หลายตัวที่ทำงานพร้อมกันบนงานย่อยที่ถูกแยกส่วน ประสานงานโดย orchestrator ที่รวบรวมผลลัพธ์

ความแตกต่างจาก chain แบบเรียงลำดับคือประเด็นสำคัญ:

• Sequential chain: เอเจนต์ A ทำงาน ส่งต่อให้ B, B ส่งต่อให้ C เวลาทั้งหมด = A + B + C
• Swarm: Orchestrator แยกเป้าหมาย เอเจนต์ A, B, C ทำงานพร้อมกันบนงานย่อยที่ไม่ขึ้นต่อกัน ผลลัพธ์ถูกรวม เวลาทั้งหมด ≈ max(A, B, C)

เมื่องานมีโครงสร้างแบบขนานจริง นั่นคือความแตกต่างระหว่างนาทีกับชั่วโมง

Swarm ยังแก้ปัญหาบริบทล้น เอเจนต์ตัวเดียวในงานยาวจะสะสม tokens จนกระทั่งหน้าต่างของมันท่วม Swarm ให้แต่ละงานย่อยมีบริบทที่จำกัดของตัวเอง และมีเพียงเอาต์พุตที่มีโครงสร้างเท่านั้นที่ไหลกลับไปยัง orchestrator

องค์ประกอบพื้นฐานหกประการ

ทุก swarm มีองค์ประกอบหลักเหมือนกัน:

องค์ประกอบ

สิ่งที่มันทำ

Orchestrator

แยกส่วนงาน กำหนดงานย่อย ติดตามการดำเนินการ รวบรวมผลลัพธ์

Subagents

ผู้ปฏิบัติงานเฉพาะทางที่จำกัดอยู่ในโดเมนเดียว (วิจัย, เขียนโค้ด, วิเคราะห์, เขียน)

Tools

ฟังก์ชันที่เอเจนต์สามารถเรียกใช้: ค้นหาเว็บ, ตัวแปลโค้ด, ไฟล์ I/O, APIs

Memory

สถานะที่แชร์ซึ่ง swarm สามารถอ่าน/เขียนได้

Handoffs / Routing

กลไกในการส่งผ่านการควบคุมหรือข้อมูลระหว่างเอเจนต์

Guardrails

ขีดจำกัดการวนซ้ำ, การหมดเวลา, ทริกเกอร์ให้มนุษย์เข้ามาตรวจสอบ, การกู้คืนข้อผิดพลาด

ทำทั้งหกอย่างนี้ให้ถูกต้อง คุณก็จะมี swarm ทำผิดสักอย่าง คุณก็จะได้เซสชันการดีบักที่แพงหูฉี่

ส่วนที่ 2: Kimi K2.6 จริงๆแล้วคืออะไร

ก่อนที่จะเจาะลึกพฤติกรรม swarm ควรทำความเข้าใจว่าอะไรอยู่เบื้องหลังมัน K2.6 คือโมเดล Mixture-of-Experts ขนาด 1 ล้านล้านพารามิเตอร์จาก Moonshot AI เผยแพร่แบบ open-weight เมื่อวันที่ 20 เมษายน 2026 ภายใต้สัญญา Modified MIT License การใช้งานเชิงพาณิชย์ฟรีต่ำกว่ารายได้ต่อเดือน 20 ล้านดอลลาร์สหรัฐ หรือผู้ใช้ที่ใช้งานต่อเดือน 100 ล้านคน ดังนั้นสำหรับนักพัฒนาส่วนใหญ่แล้วมันแทบจะฟรี

0:29

ข้อมูลจำเพาะของสถาปัตยกรรม

ข้อมูลจำเพาะ

ค่า

พารามิเตอร์ทั้งหมด

~1.04 ล้านล้าน

เปิดใช้งานต่อ token

~32 พันล้าน (8 ผู้เชี่ยวชาญที่ถูกเลือก + 1 ที่ใช้ร่วมกัน)

ผู้เชี่ยวชาญทั้งหมด

384, ครอบคลุม 61 เลเยอร์ของ transformer

หน้าต่างบริบท

262,144 tokens (262K)

Attention

Multi-Head Latent Attention (MLA) - รอยเท้า KV cache เล็กลง

ฟังก์ชันกระตุ้น

SwiGLU

ตัวเข้ารหัสภาพ

MoonViT-3D (400M พารามิเตอร์, ภาพ + วิดีโอสูงสุด 2K)

Quantization

INT4 ผ่าน Quantization-Aware Training (~594GB บนดิสก์)

ขนาด FP16 เต็ม

~2TB

ลิขสิทธิ์

Modified MIT

INT4 QAT variant ทำงานบน 4x H100 80GB ได้ตามธรรมชาติ FP16 ต้องใช้ 8x H100 80GB เฟรมเวิร์กการอนุมานที่รองรับทั้งสามตัว (vLLM, SGLang, KTransformers) เปิดเผย APIs ที่เข้ากันได้กับ OpenAI

ส่วนที่ 3: ตัวปรับแต่ง MuonClip หรือเหตุใดการฝึกอบรมจึงมีเสถียรภาพ

การฝึก MoE แบบ sparse ขนาดล้านล้านพารามิเตอร์โดยไม่ให้มันพังนั้นยาก รูปแบบความล้มเหลวที่เฉพาะเจาะจง: เมื่อความยาวของลำดับเพิ่มขึ้น ผลคูณจุด QK (query-key) ในเลเยอร์ attention สามารถเติบโตได้ไม่มีขอบเขต คุณจะได้ loss spikes และในระดับนี้ loss spike อาจไม่สามารถกู้คืนได้

เอกสารทางเทคนิคของ Kimi K2 (arxiv: 2507.20534) นำเสนอ MuonClip เพื่อจัดการกับสิ่งนี้

Muon คือตัวปรับแต่งการไล่ระดับสีที่มีประสิทธิภาพด้าน token มากกว่า AdamW คุณภาพเท่ากัน ขั้นตอนการฝึกน้อยกว่า ข้อเสีย: Muon เพียงอย่างเดียวทำให้เกิดความไม่เสถียรของ attention ในระดับล้านล้านพารามิเตอร์

QK-Clip เพิ่มการตัดต่อตาม token และต่อ head โดยตรงบนเมทริกซ์ QK ก่อน softmax ซึ่งจำกัดขนาดของ attention score และกำจัดปัญหาการระเบิด ไม่ต้องปรับแต่งด้วยตนเอง ไม่มีเทคนิคเกี่ยวกับอัตราการเรียนรู้

จากบทคัดย่อของเอกสาร:

"เรานำเสนอ MuonClip ตัวปรับแต่งแบบใหม่ที่รวมอัลกอริทึม Muon ที่มีประสิทธิภาพด้าน token เข้ากับกลไกเสริมเสถียรภาพที่เรียกว่า QK-Clip... การใช้ MuonClip ทำให้ Kimi K2 บรรลุประสิทธิภาพที่แข่งขันได้ในขณะที่ต้องใช้ token ในการฝึกน้อยกว่าพื้นฐาน AdamW อย่างมีนัยสำคัญ"

ทำไมนักพัฒนาถึงควรสนใจรายละเอียดการฝึก? เพราะเหตุผลที่ K2.6 สามารถรองรับการเรียกใช้เครื่องมือ 4,000 ครั้งนานกว่า 12 ชั่วโมงโดยไม่เสื่อมคุณภาพนั้นย้อนกลับไปถึงสิ่งนี้ โมเดลที่ได้รับการฝึกด้วยความไม่เสถียรของ attention มักจะหลอนภายใต้เงื่อนไขบริบทยาวและจำนวนขั้นตอนสูง ซึ่งเป็นสภาวะที่ Agent Swarm ทำงานอยู่นั่นเอง

ส่วนที่ 4: PARL งานวิจัยเบื้องหลัง swarm

Agent Swarm ไม่ใช่เฟรมเวิร์กที่ถูกนำมาติดตั้งบน K2.6 พฤติกรรมนี้ถูกฝึกเข้าไปในโมเดล ผ่านกระบวนทัศน์ที่ Moonshot เรียกว่า PARL: Parallel-Agent Reinforcement Learning ซึ่งอธิบายไว้ในเอกสารทางเทคนิคของ Kimi K2.5 (arxiv: 2602.02276)

Orchestrator ที่ฝึกได้, subagents ที่ถูกตรึง

วิธีปกติในการสร้างระบบหลายเอเจนต์คือการประสานงานอินสแตนซ์โมเดลสดหลายตัวที่เลเยอร์แอปพลิเคชัน จากนั้นการกำหนดเครดิตก็กลายเป็นเรื่องยุ่งเหยิง: เอเจนต์ตัวไหนของคุณที่ทำให้คำตอบสุดท้ายดีหรือไม่ดี? การฝึกแบบ end-to-end ผ่านกราฟนั้นไม่สามารถทำได้ในเชิงคำนวณ

PARL เลี่ยงมัน:

• Orchestrator สามารถฝึกได้ อัปเดตผ่าน RL ตามรางวัลผลลัพธ์
• Subagents ถูกตรึง เป็นจุดตรวจสอบนโยบายระหว่างกลางที่ตายตัว

วิถีของ subagent จะถูกปฏิบัติเป็นข้อสังเกตด้านสิ่งแวดล้อม ไม่ใช่จุดตัดสินใจที่แตกต่างกัน ซึ่งจะแยกปัญหายากสองข้อออกจากกันในคราวเดียว เครดิตจะไปที่การกระทำของ orchestrator เท่านั้น ไม่เคยไปที่ subagent 300 ตัวพร้อมกัน และการฝึกอบรมยังคงมีเสถียรภาพเพราะมีเพียงโมเดลเดียวเท่านั้นที่ถูกอัปเดต

Orchestrator เรียนรู้ว่าเมื่อใดควรทำแบบขนาน ควรสร้าง subagents กี่ตัว และจะแบ่งงานอย่างไร ไม่มีใครระบุพฤติกรรมเหล่านั้นด้วยตนเอง พวกมันเกิดขึ้นจากการเพิ่มรางวัลสูงสุด

ฟังก์ชันรางวัลสามส่วน

Orchestrator ฝึกโดยใช้สัญญาณสามอย่าง

รางวัล parallelism ผลักดันให้มันสร้าง subagents ที่ทำงานพร้อมกันแทนที่จะทำงานตามลำดับ หากไม่มีสิ่งนี้ โมเดลจะใช้เอเจนต์ทีละตัวเป็นค่าเริ่มต้น: ปลอดภัย คาดเดาได้ ช้า

รางวัล finish ทำให้แน่ใจว่า subagents ทำงานของมันสำเร็จจริงๆ สิ่งนี้จะบล็อก "spurious parallelism" ที่ orchestrator สร้างฝูงเอเจนต์ที่ไม่ทำอะไรเลยเพียงเพื่อรับรางวัล parallelism

รางวัล performance ให้คะแนนคุณภาพของผลลัพธ์สุดท้ายเมื่อเทียบกับวัตถุประสงค์ของงาน นี่คือความจริงพื้นฐานที่ทุกอย่างอื่นต้องรับใช้

รายละเอียดที่ฉันพบว่าน่าสนใจที่สุด: เมตริกการปรับให้เหมาะสมคือ critical steps (ความยาวเส้นทางวิกฤต) ไม่ใช่จำนวนขั้นตอนทั้งหมด โมเดลจะได้รับรางวัลสำหรับการทำให้ห่วงโซ่การพึ่งพาที่ยาวที่สุดสั้นลง ไม่ใช่สำหรับการเพิ่มความขนานดิบ นั่นคือสิ่งที่ช่วยลดเวลาจริงได้จริง

ผลลัพธ์ PARL

• BrowseComp: โหมด swarm ทำได้ 78.4% บน K2.5 ซึ่งเป็นการเพิ่มขึ้น 17.8 จุดสัมบูรณ์เหนือ K2.5 แบบเอเจนต์เดียว (60.6%) ซึ่งเอาชนะ GPT-5.2 Pro (77.9%) ในขณะนั้น K2.6 ผลักดันสิ่งนี้ไปที่ 86.3%
• WideSearch: การปรับปรุงสัมบูรณ์ 6.3 จุดบน Item-F1 (72.7% เป็น 79.0%)
• เวลาจริง: ลดลง 3-4.5 เท่าในงานที่ทำแบบขนานได้ เมื่อเทียบกับพื้นฐานเอเจนต์เดียว
• การเรียกใช้เครื่องมือแบบขนาน: มากถึง 4,000 ขั้นตอนที่ประสานงานกันใน K2.6

ส่วนที่ 5: Mooncake โครงสร้างพื้นฐานเบื้องหลัง Kimi

โครงสร้างพื้นฐานการให้บริการของ Moonshot อธิบายว่าเหตุใด K2.6 จึงสามารถรองรับเอเจนต์ขนาน 300 ตัวได้โดยไม่พัง น้ำหนักโมเดลเป็นเพียงครึ่งหนึ่งของเรื่องราว ระบบที่ให้บริการพวกมันคืออีกครึ่งหนึ่ง

โครงสร้างพื้นฐานทำงานได้ดีสำหรับงานบริบทยาว

สถาปัตยกรรมแบบแยกส่วนที่เน้น KVCache

แพลตฟอร์มการให้บริการของ Moonshot เรียกว่า Mooncake อธิบายไว้ในเอกสารโครงสร้างพื้นฐานปี 2024 (arxiv: 2407.00079) มันคือเครื่องยนต์ที่ขับเคลื่อน Kimi ในระดับใหญ่ และการออกแบบของมันก็ผิดปกติ

การอนุมาน LLM แบบดั้งเดิมทำงาน prefill (การประมวลผลพรอมต์อินพุต) และ decode (การสร้าง tokens) บนอินสแตนซ์ GPU เดียวกัน Mooncake แยกพวกมันออกเป็นคลัสเตอร์แยกกัน:

• Prefill cluster: จัดการการประมวลผลพรอมต์เริ่มต้น ปรับขนาดได้อย่างอิสระสำหรับอินพุตบริบทยาว
• Decode cluster: จัดการการสร้าง tokens ปรับให้เหมาะสมสำหรับปริมาณงานและความหน่วง

KV cache ซึ่งเป็นสถานะ attention ระดับกลางที่ทำให้การสร้างแบบ autoregressive มีประสิทธิภาพ ถูกจัดการเป็นทรัพยากรระบบระดับแรก Mooncake สร้าง KV cache แบบกระจายที่ครอบคลุม VRAM ของ GPU, DRAM ของ CPU และ SSD ด้วยเอ็นจิ้นการถ่ายโอนแบบกำหนดเองที่เคลื่อนย้าย cache ระหว่างโหนด

เหตุใดสิ่งนี้จึงสำคัญสำหรับ Agent Swarm

เมื่อ sub-agent 300 ตัวทำงานพร้อมกัน แต่ละตัวจะสร้าง KV cache ของตัวเอง ในสถาปัตยกรรมแบบดั้งเดิม นั่นคือแรงกดดันหน่วยความจำ GPU และความขัดแย้งในการจัดตารางเวลามหาศาล ด้วย cache ที่แยกส่วนของ Mooncake:

• KV caches จาก sub-agent ที่เสร็จสมบูรณ์สามารถถูกย้ายไปยัง DRAM หรือ SSD และเรียกคืนได้หากจำเป็น
• Prefill cluster จัดการพรอมต์ระบบ (ซึ่งมักจะใหญ่) สำหรับแต่ละ sub-agent อย่างอิสระ
• ตัวจัดตารางเวลาเพิ่มปริมาณงานโดยรวมสูงสุดในขณะที่รักษา SLOs ความหน่วงของแต่ละเอเจนต์

จากเอกสาร Mooncake: "เมื่อเทียบกับวิธีพื้นฐาน Mooncake สามารถเพิ่มปริมาณงานได้มากถึง 525% ในสถานการณ์จำลองบางสถานการณ์ในขณะที่ปฏิบัติตาม SLOs ภายใต้ภาระงานจริง สถาปัตยกรรมที่เป็นนวัตกรรมของ Mooncake ช่วยให้ Kimi จัดการคำขอได้มากกว่า 75%"

เอกสารที่อัปเดตรายงานว่า Mooncake "ทำงานบนหลายพันโหนด ประมวลผล tokens มากกว่า 1 แสนล้านต่อวัน" และจัดการคำขอได้มากกว่า 115% บนคลัสเตอร์ A800 และมากกว่า 107% บนคลัสเตอร์ H800 เมื่อเทียบกับระบบก่อนหน้า

PD disaggregation ในระดับใหญ่: การปรับใช้ K2 บน 128 GPU

LMSYS เผยแพร่กรณีศึกษาการปรับใช้สำหรับ Kimi K2 โดยใช้ Prefill-Decode (PD) Disaggregation บน 128 H200 GPUs ผ่าน SGLang Router สถาปัตยกรรม:

• SGLang Router: บริการน้ำหนักเบาสำหรับการค้นพบบริการแบบไดนามิกของโหนด prefill และ decode ผ่าน label selectors
• Expert Parallelism: ผู้เชี่ยวชาญ 384 คนของ K2 กระจายไปทั่วโหนด ด้วยการกำหนดเส้นทางที่ระดับเครือข่าย
• OME (Open Model Engine): การจัดระบบแบบ Kubernetes-native สำหรับเลเยอร์การให้บริการ

นี่คือสแต็กที่ขับเคลื่อนตระกูล K2 ในระดับการผลิต หากคุณโฮสต์ K2.6 ด้วยตัวเอง นี่คือเทมเพลตของคุณ

ส่วนที่ 6: Agent Swarm ทำงานอย่างไร ทีละขั้นตอน

ลำดับกลไกเมื่อ K2.6 ดำเนินการงานในโหมด swarm:

ขั้นตอนที่ 1: การแยกส่วนงาน

Orchestrator วิเคราะห์งานและสร้างกราฟการพึ่งพา: งานย่อยใดที่ไม่ขึ้นต่อกันและสามารถทำงานแบบขนานได้ งานย่อยใดขึ้นอยู่กับผลลัพธ์ก่อนหน้า

สำหรับ "วิจัยบริษัท YC 100 แห่งและสร้างการวิเคราะห์ภาคส่วน" orchestrator ระบุงานวิจัยอิสระ 100 งาน จากนั้นงานรวม 1 งาน จากนั้นงานสังเคราะห์ 1 งาน เลเยอร์แรกสามารถทำแบบขนานได้เต็มที่

ขั้นตอนที่ 2: การสร้างเอเจนต์ผู้เชี่ยวชาญ

Orchestrator สร้าง sub-agent ที่เชี่ยวชาญเฉพาะด้านตามประเภทงานย่อย K2.6 สร้างอินสแตนซ์เอเจนต์แบบไดนามิกด้วยคำแนะนำเฉพาะบทบาทและการเข้าถึงเครื่องมือที่ตรงเป้าหมาย:

• เอเจนต์วิจัยเว็บ: เครื่องมือค้นหา + เบราว์เซอร์
• เอเจนต์วิเคราะห์ข้อมูล: การดำเนินการ Python + เครื่องมือสเปรดชีต
• เอเจนต์เขียน: การสังเคราะห์และการสร้างเอกสาร
• เอเจนต์ตรวจสอบข้อเท็จจริง: การอ้างอิงโยงและการตรวจสอบความถูกต้อง

Sub-agent แต่ละตัวทำงานภายในบริบทท้องถิ่นที่จำกัดของตัวเอง มันจัดการงานที่จำกัดหนึ่งงาน สร้างเอาต์พุตที่มีโครงสร้าง และออกไป บริบทท้องถิ่นไม่ได้บรรทุกทุกอย่างที่ orchestrator รู้ มีเพียงสิ่งที่ sub-agent นั้นต้องการ นี่คือวิธีที่ K2.6 หลีกเลี่ยงการล้นในงานที่จะเติมเต็มหน้าต่างของเอเจนต์เดียวภายในไม่กี่นาที

ขั้นตอนที่ 3: การดำเนินการแบบขนานเป็นระลอก

เอเจนต์ดำเนินการเป็นระลอก ระลอกแรกจัดการงานที่ไม่ขึ้นต่อกันโดยสิ้นเชิง

1. เมื่อผลลัพธ์เข้ามา orchestrator จะเปิดตัวระลอกที่สองในงานที่ขึ้นอยู่กับผลลัพธ์ของระลอกแรก และต่อไปเรื่อยๆ จนกว่ากราฟการพึ่งพาจะได้รับการแก้ไข
2. K2.6 รองรับ sub-agent สูงสุด 300 ตัวและ 4,000 ขั้นตอนที่ประสานงานกันต่อเซสชัน Orchestrator ติดตามการดำเนินการแบบเรียลไทม์ ตรวจพบเอเจนต์ที่ล้มเหลวหรือหยุดชะงัก และกำหนดงานของพวกมันใหม่โดยอัตโนมัติ
3. ความทนทานต่อความผิดพลาดนั้นคือสิ่งที่ทำให้การทำงานอัตโนมัตินานกว่า 12 ชั่วโมงเป็นไปได้โดยไม่มีมนุษย์คอยดู

ขั้นตอนที่ 4: การรวบรวมและผลลัพธ์

เมื่อ sub-agent ทั้งหมดเสร็จสมบูรณ์ orchestrator จะรวบรวมผลลัพธ์เป็นงานส่งมอบสุดท้าย: เอกสาร, สเปรดชีต, เว็บไซต์, สไลด์เด็ค

• มันสังเคราะห์ข้ามผลลัพธ์ของเอเจนต์แทนที่จะต่อกัน ดังนั้นผลลัพธ์จึงสอดคล้องกันเชิงโครงสร้าง
• อีกสิ่งหนึ่งที่ควรสังเกต: โครงสร้าง swarm ยังเป็นคำตอบของ Kimi สำหรับปัญหาหน้าต่างบริบท
• นโยบายที่ชัดเจนของ K2.6: "เมื่อหน้าต่างบริบทเกินเกณฑ์ จะคงไว้เฉพาะข้อความที่เกี่ยวข้องกับเครื่องมือรอบล่าสุดเท่านั้น" swarm ทำให้นโยบายนั้นยั่งยืนตลอดขอบเขตงานที่ยาวนานมาก

ส่วนที่ 7: สถาปัตยกรรม Kimi x Claude Opus 4.8

ไม่มีโมเดลใดที่คำตอบที่ถูกต้องสำหรับทุกเลเยอร์ของ swarm Kimi K2.6 ถูกสร้างขึ้นสำหรับขนาดแนวนอน - การดำเนินการแบบขนานข้ามเอเจนต์หลายร้อยตัว การทำงานอัตโนมัติที่ยาวนาน การประมวลผลจำนวนมากที่คุ้มค่า

Claude Opus 4.8 ถูกสร้างขึ้นสำหรับการตัดสิน - การวางแผน การใช้เหตุผลที่ละเอียดอ่อน และการจับข้อผิดพลาดของตัวเอง พวกเขาเติมเต็มซึ่งกันและกันในเชิงโครงสร้าง และช่องว่างที่แต่ละตัวทิ้งไว้ก็ใกล้เคียงกับรูปร่างของจุดแข็งของอีกฝ่าย

รูปแบบ:

1[เป้าหมายผู้ใช้]
2      |
3[Claude Opus 4.8 - นักวางแผน]
4  แยกเป้าหมายเป็นข้อกำหนดงานที่มีโครงสร้าง
5  ระบุงานย่อยที่ขนานกัน vs. ตามลำดับ
6  กำหนดเกณฑ์ความสำเร็จสำหรับแต่ละงานย่อย
7      |
8[Kimi K2.6 Agent Swarm - ผู้ดำเนินการ]
9  รับข้อกำหนดงานที่มีโครงสร้าง
10  สร้าง sub-agent เฉพาะทางสูงสุด 300 ตัว
11  ทำงานแบบขนานข้ามการเรียกใช้เครื่องมือ
12  ส่งคืนผลลัพธ์ที่มีโครงสร้าง
13      |
14[Claude Opus 4.8 - ผู้ตรวจสอบ]
15  ตรวจสอบผลลัพธ์ของ Kimi กับเกณฑ์ความสำเร็จ
16  แจ้งความล้มเหลว ช่องว่าง ความไม่สอดคล้องกัน
17  สังเคราะห์งานส่งมอบสุดท้าย

ทำไมต้อง Claude สำหรับการวางแผนและการตรวจสอบ?

การเปลี่ยนแปลงที่ถูกประเมินค่าต่ำที่สุดใน Opus 4.8 คือการปรับปรุงความซื่อสัตย์: "Opus 4.8 มีแนวโน้มที่จะปล่อยให้ข้อบกพร่องในโค้ดที่มันเขียนผ่านไปโดยไม่ถูกสังเกตน้อยกว่ารุ่นก่อนหน้าประมาณสี่เท่า" ในระบบเอเจนต์ ความมั่นใจที่ผิดพลาดคือรูปแบบความล้มเหลวที่ร้ายแรง

• Orchestrator ที่พูดว่า "เสร็จแล้ว" ทั้งที่ยังไม่เสร็จจะทำให้เกิดข้อผิดพลาดแบบลูกโซ่ไปยังเอเจนต์ปลายน้ำ 300 ตัว แนวโน้มของ Claude ในการแจ้งความไม่แน่นอนและจับข้อผิดพลาดของตัวเองระหว่างงาน ทำให้มันเป็นจุดยึดที่เหมาะสมสำหรับเลเยอร์ที่การผิดพลาดนั้นมีค่าใช้จ่ายสูง
• Opus 4.8 ยังรองรับหน้าต่างบริบท 1M tokens ซึ่งมีความสำคัญสำหรับรอบการตรวจสอบเมื่อคุณดึงผลลัพธ์จากเอเจนต์วิจัยแบบขนาน 50+ ตัวเข้าสู่บริบทการตรวจสอบเดียว

ทำไมต้อง Kimi สำหรับการดำเนินการ?

Agent Swarm ของ K2.6 รองรับ sub-agent แบบขนานสูงสุด 300 ตัวและขั้นตอนเครื่องมือที่ประสานงานกัน 4,000 ขั้นตอนต่อเซสชัน - นั่นคือพฤติกรรมที่ได้รับการฝึกมา ไม่ใช่ wrapper ที่เลเยอร์แอปพลิเคชัน

• Claude มีฟีเจอร์ Dynamic Workflows ใน Claude Code แต่ตอนนี้ยังอยู่ในตัวอย่างการวิจัยและจำกัดเฉพาะแผน Enterprise/Max
• ความสามารถ swarm ของ Kimi พร้อมให้ทุกคนใช้ผ่าน API ได้ทันที เศรษฐศาสตร์ของ token ก็มีความสำคัญในระดับใหญ่เช่นกัน: K2.6 ทำงานที่ $0.95/$4.00 ต่อ token อินพุต/เอาต์พุต 1 ล้านตัว สำหรับการดำเนินการแบบขนานจำนวนมาก นั่นไม่ใช่จำนวนเล็กน้อย

ส่วนที่ 8: เมื่อคุณต้องการ swarm (และเมื่อไม่ต้องการ)

ข้อผิดพลาดที่พบบ่อยที่สุดในการออกแบบหลายเอเจนต์: การเพิ่มความซับซ้อนของ swarm ก่อนที่คุณจะถึงเพดานของเอเจนต์เดียว

ใช้เอเจนต์เดียวเมื่อ:

• งานพอดีกับหน้าต่างบริบทเดียว (ต่ำกว่า ~50K tokens ของงานจริง)
• งานเป็นแบบตามลำดับโดยธรรมชาติ แต่ละขั้นตอนขึ้นอยู่กับขั้นตอนก่อนหน้า
• คุณยังอยู่ในขั้นตอนการสร้างต้นแบบ - รูปแบบความล้มเหลวของเอเจนต์เดียวนั้นดีบั๊กได้ง่ายกว่ามาก
• งานจะเสร็จภายใน 10 นาทีอยู่แล้ว

ใช้ Agent Swarm เมื่อ:

• งานมี n งานย่อยแบบขนานและอิสระ โดยที่ n > 5
• บริบทล้นเป็นปัญหาจริง (การวิจัยเชิงลึก, โค้ดเบสขนาดใหญ่, การดำเนินการแบบแบตช์)
• คุณต้องการเอเจนต์ที่เชี่ยวชาญเฉพาะด้านที่ทำงานพร้อมกัน
• งานยาวเกินไปที่จะรักษาคุณภาพในเซสชันตามลำดับเดียว
• คุณต้องการเอเจนต์นักวิจารณ์หรือผู้ตรวจสอบที่ตรวจสอบงานของเอเจนต์อื่น

ใช้ไฮบริด Kimi + Claude Opus 4.8 เมื่อ:

• คุณภาพของการวางแผนมีความสำคัญและคุณต้องการโมเดลที่จะโต้แย้งหากแผนผิด
• เอาต์พุตถูกส่งออกไปโดยไม่ต้องมีการตรวจสอบของมนุษย์เพิ่มเติม - ดังนั้นการตรวจสอบต้องถูกฝังไว้
• คุณกำลังดำเนินการปริมาณมากซึ่งต้นทุน token ทวีคูณอย่างรวดเร็ว
• คุณต้องการดุลยพินิจของ Claude ในเลเยอร์การตัดสินใจและขนาดของ Kimi ในเลเยอร์การทำงาน

ส่วนที่ 10: รูปแบบสถาปัตยกรรม swarm สี่รูปแบบ

รูปแบบที่ 1: Orchestrator-worker (พบมากที่สุด)

Orchestrator ส่วนกลางกำหนดงานย่อยให้กับ worker, worker ดำเนินการแบบขนาน, ผลลัพธ์ถูกรวม

1[เป้าหมายผู้ใช้]
2    |
3[Orchestrator - Claude Opus 4.8]
4    +-- [Worker: Kimi Research Agent x N]
5    +-- [Worker: Kimi Data Agent x N]
6    +-- [Worker: Kimi Code Agent x N]
7    |
8[Synthesizer - Claude Opus 4.8]
9    |
10[ผลลัพธ์สุดท้าย]

เหมาะที่สุดสำหรับ: งานที่มีงานย่อยที่แยกออกจากกันได้ชัดเจนและมี worker จำนวนผันแปรได้

รูปแบบที่ 2: Critic-refiner loop

เอเจนต์หนึ่งผลิต อีกตัววิจารณ์ ทำซ้ำจนกว่าจะถึงเกณฑ์คุณภาพ

1[Kimi K2.6 Builder] -> ร่าง -> [Claude Opus 4.8 Critic] -> ข้อเสนอแนะ -> [Kimi K2.6 Builder]
2                                        |
3                                   (อนุมัติ)
4                                [ผลลัพธ์สุดท้าย]

เหมาะที่สุดสำหรับ: การสร้างโค้ด, การเขียนเชิงเทคนิค, ผลลัพธ์ที่敏感的ต่อการปฏิบัติตามข้อกำหนด ตั้งค่าขีดจำกัดการวนซ้ำสูงสุดเสมอ

รูปแบบที่ 3: แบบลำดับชั้น (Hierarchical)

Orchestrator เชิงกลยุทธ์จัดการ orchestrator โดเมน ซึ่งจัดการ worker

1[Claude Opus 4.8 - Strategic Orchestrator]
2    +-- [Kimi K2.6 Swarm - ทีมวิจัย (50 เอเจนต์)]
3    +-- [Kimi K2.6 Swarm - ทีมสร้าง (50 เอเจนต์)]

เหมาะที่สุดสำหรับ: เวิร์กโฟลว์องค์กรขนาดใหญ่ที่มีโดเมนที่แตกต่างกัน

รูปแบบที่ 4: Claw Groups (Kimi-native heterogeneous swarm)

K2.6 ประสานงานเอเจนต์ที่รันโมเดลใดก็ได้ รวมถึงโมเดลท้องถิ่น, Claude และ GPT ควบคู่ไปกับผู้ปฏิบัติงานที่เป็นมนุษย์ในพื้นที่ปฏิบัติการที่ใช้ร่วมกัน ปัจจุบันอยู่ในตัวอย่างการวิจัย

1[Kimi K2.6 Coordinator]
2    +-- [Claude Opus 4.8 - ผู้เชี่ยวชาญด้านการใช้เหตุผล]
3    +-- [Llama 3.3 local - งานปริมาณมากที่ไวต่อต้นทุน]
4    +-- [Kimi K2.6 agents x N - เลเยอร์การดำเนินการ]
5    +-- [ผู้ตรวจสอบมนุษย์ - จุดตรวจสอบการอนุมัติ]

เหมาะที่สุดสำหรับ: เวิร์กโฟลว์ที่ต้องการความหลากหลายของโมเดล, ไฮบริดท้องถิ่น + คลาวด์, หรือข้อกำหนดให้มนุษย์อยู่ในวงจร

ส่วนที่ 12: การออกแบบพรอมต์สำหรับงาน swarm

พรอมต์การแยกส่วน (orchestrators)

1คุณคือสถาปนิกงาน จงแยกเป้าหมายนี้ออกเป็นงานย่อยที่เป็นอิสระและทำแบบขนานได้
2
3กฎ:
4- แต่ละงานย่อยต้องทำให้เสร็จสมบูรณ์ได้โดยเอเจนต์เฉพาะทางตัวเดียวโดยแยกจากกัน
5- งานย่อยที่มีการพึ่งพาต้องทำเครื่องหมายด้วยห่วงโซ่การพึ่งพา
6- ส่งออกเป็น JSON: {task_id, description, agent_type, depends_on, success_criteria}
7
8เป้าหมาย: {user_goal}
9ประเภทเอเจนต์ที่มี: researcher, analyst, coder, writer, verifier

พรอมต์ระบบผู้เชี่ยวชาญ (sub-agents)

1คุณคือเอเจนต์ {ROLE} ที่เชี่ยวชาญด้าน {DOMAIN}
2
3งาน: {subtask_description}
4
5ข้อจำกัด:
6- ส่งคืนเฉพาะ JSON ที่ถูกต้องซึ่งตรงกับ: {output_schema}
7- อย่าไปเกินขอบเขตงานของคุณ
8- หากคุณไม่สามารถทำงานให้เสร็จได้: {"error": "reason", "partial_results": [...]}
9- จำนวนการเรียกใช้เครื่องมือสูงสุด: {max_tool_calls}
10
11บริบท: {context_from_orchestrator}

พรอมต์การรวบรวม (synthesizers)

1สังเคราะห์งานวิจัยจากเอเจนต์เฉพาะทาง {n} ตัวเป็นผลลัพธ์ที่สอดคล้องกัน
2
31. อ่านผลลัพธ์ของเอเจนต์ทั้งหมดที่ให้มา
42. ระบุว่าพวกเขาเห็นด้วย ไม่เห็นด้วย หรือมีช่องว่างตรงไหน
53. สร้าง {output_type} ที่รวมข้อค้นพบทั้งหมด
64. เรียกจุดที่ไม่สอดคล้องกันอย่างชัดเจน - อย่าแก้ไขความขัดแย้งอย่างเงียบๆ
7
8ผลลัพธ์ของเอเจนต์: {agent_outputs_as_json}
9รูปแบบผลลัพธ์: {final_output_spec}

ส่วนที่ 13: หลักเกณฑ์ป้องกันเจ็ดข้อที่ไม่สามารถต่อรองได้

1. จำนวนการวนซ้ำสูงสุดต่อเอเจนต์: ขีดจำกัดตายตัวของการวนซ้ำก่อนที่ orchestrator จะได้รับแจ้ง

2. การหมดเวลาเซสชัน: หาก swarm ไม่เสร็จภายใน N นาที ให้ยกเลิกและส่งคืนผลลัพธ์บางส่วน

3. การบังคับใช้เอาต์พุตที่มีโครงสร้าง: บังคับให้เอเจนต์ส่งคืน JSON ข้อความร้อยแก้วจากเอเจนต์ระดับกลางทำให้เกิดความล้มเหลวในการแยกวิเคราะห์ปลายน้ำ

4. การแยกความล้มเหลว: Sub-agent ที่ล้มเหลวต้องไม่ทำให้ orchestrator ล่ม

1async def run_subagent_safely(kimi_client, task, agent_id):
2    try:
3        result = kimi_client.chat.completions.create(
4            model="kimi-k2.6",
5            messages=[{"role": "user", "content": task}],
6            max_tokens=4096
7        )
8        return {"agent_id": agent_id, "status": "success",
9                "output": result.choices[0].message.content}
10    except Exception as e:
11        return {"agent_id": agent_id, "status": "failed", "error": str(e)}

5. ลองใหม่ด้วย exponential backoff: จัดการ 429s และข้อผิดพลาดชั่วคราวโดยไม่ทำให้เป็นความล้มเหลวถาวร

6. จุดตรวจสอบให้มนุษย์อยู่ในวงจร: สำหรับ swarm ที่มีสิทธิ์เขียน (การปรับใช้โค้ด, การส่งอีเมล, การกลายพันธุ์ API) ให้แทรกการหยุดเพื่อขออนุมัติที่จำเป็น

7. การตรวจสอบต้นทุน: กำหนดงบประมาณ token ต่อการรัน ลูปที่หนีไม่พ้นจะแสดงเป็นความผิดปกติของต้นทุนก่อนที่จะแสดงเป็นความล้มเหลวด้านคุณภาพ ทุกครั้ง

สิ่งที่จะสร้างก่อน

เริ่มต้นด้วยไปป์ไลน์สามเอเจนต์จากส่วนที่ 9 มันเล็กพอที่จะดีบั๊กได้ในบ่ายวันเดียว มันใช้การวางแผน การดำเนินการแบบขนาน และการตรวจสอบ และคุณสามารถรันมันกับงานจริงได้ในเวลา Setup ไม่ถึงหนึ่งชั่วโมง

เมื่อมันพัง - และมันจะพัง - รูปแบบความล้มเหลวจะสอนคุณเกี่ยวกับการออกแบบ swarm มากกว่าการอ่านอีกหนึ่งชั่วโมง

สร้างมัน จงใจทำให้มันพัง แล้วกลับมาที่รูปแบบในส่วนที่ 11 พร้อมจุดอ้างอิงที่เป็นรูปธรรม

สถาปัตยกรรมไม่ใช่ส่วนที่ยาก ส่วนที่ยากคือช่องว่างระหว่าง "ทำงานได้ในการทดสอบ" กับ "ทำงานได้ตอนตี 3 โดยไม่มีใครดู" และช่องว่างนั้นอยู่ที่หลักเกณฑ์ป้องกัน การสังเกตการณ์ และการออกแบบหน่วยความจำทั้งหมด

บทสรุป

Kimi 2.6 คือการปฏิวัติของเอเจนต์ว่า reinforcement learning สามารถสร้าง agent swarms ได้อย่างไร

มันยังแสดงให้เห็นว่าขอบเขตบริบทยาวสามารถใช้ประโยชน์จากโครงสร้างพื้นฐานที่ใช้ orchestrator ดังกล่าว ซึ่งอนุญาตให้สร้าง sub-agents หลายตัวเพื่อสร้างระบบที่ซับซ้อนทั้งหมดโดยใช้เพียงหนึ่งเดียว

ข้อจำกัดความรับผิดชอบ

บทความนี้เขียนโดยใช้เอกสารทางเทคนิคของ Kimi 2.6 และเอกสารวิจัยในบันทึกของผู้เขียน และแก้ไขโดย AI, Opus 4.7