Đây là bản phân tích toàn diện từ A–Z về AI Agent Swarm — chúng là gì và cách sử dụng chúng.
Tại sao chúng thay đổi hoàn toàn cách bạn làm việc với AI.
Hãy đánh dấu trang này lại trước khi bạn quên.
Kimi K2.6, mô hình open-weight hàng đầu tháng 4 năm 2026 của Moonshot AI, là triển khai mã nguồn mở nghiêm túc nhất của ý tưởng này mà tôi từng thấy.
Các tác vụ thực tế có chiều rộng. Năm mươi công ty cần nghiên cứu.
Hai trăm tệp cần phân tích. Hàng tá tác vụ con không phụ thuộc lẫn nhau và không nên xếp hàng chờ nhau. Một agent swarm là kiến trúc dành cho điều đó.
Hướng dẫn này phân tích cách nó hoạt động, từ hạ tầng huấn luyện cho đến API, sau đó đề cập đến mẫu hình mà tôi cho là quan trọng nhất ngay lúc này: Kimi để thực thi, Claude Opus 4.8 để lập kế hoạch và xác minh.
Dưới đây là cách Quy trình cuối cùng trông như thế nào.
Phần 1: Agent swarm là gì?
Một agent swarm là nhiều agent làm việc đồng thời trên các tác vụ con đã được phân rã, được điều phối bởi một bộ điều phối (orchestrator) tổng hợp kết quả.
Sự khác biệt so với một chuỗi tuần tự chính là điểm mấu chốt:
- Chuỗi tuần tự: Agent A chạy, bàn giao cho B, B bàn giao cho C. Tổng thời gian = A + B + C.
- Swarm: Bộ điều phối chia nhỏ mục tiêu, các agent A, B, C chạy đồng thời trên các tác vụ con độc lập, kết quả được hợp nhất. Tổng thời gian ≈ max(A, B, C).
Khi một tác vụ có cấu trúc song song thực sự, đó là sự khác biệt giữa vài phút và vài giờ.
Một swarm cũng giải quyết vấn đề tràn ngữ cảnh (context overflow). Một agent duy nhất trên một tác vụ dài tích lũy token cho đến khi cửa sổ của nó bị ngập. Một swarm cung cấp cho mỗi tác vụ con ngữ cảnh giới hạn riêng, và chỉ có đầu ra có cấu trúc quay trở lại bộ điều phối.
Sáu khối xây dựng
Mọi swarm đều có các thành phần cốt lõi giống nhau:
Thành phần
Chức năng
Bộ điều phối (Orchestrator)
Phân rã tác vụ, gán tác vụ con, giám sát thực thi, tổng hợp kết quả
Sub-agent (Agent con)
Các worker chuyên biệt chỉ làm việc trong một lĩnh vực (nghiên cứu, mã, phân tích, viết lách)
Công cụ (Tools)
Các hàm agent có thể gọi: tìm kiếm web, trình thông dịch mã, I/O tệp, API
Bộ nhớ (Memory)
Trạng thái dùng chung mà swarm có thể đọc/ghi
Bàn giao / Định tuyến (Handoffs / Routing)
Cơ chế chuyển quyền điều khiển hoặc dữ liệu giữa các agent
Lan can bảo vệ (Guardrails)
Giới hạn số lần lặp, thời gian chờ, kích hoạt con người trong vòng lặp, phục hồi lỗi
Nắm được sáu điều này là bạn có một swarm. Sai bất kỳ một điều nào và bạn sẽ có một phiên gỡ lỗi đắt đỏ.
Phần 2: Kimi K2.6 thực sự là gì
Trước khi đi vào hành vi swarm, cần hiểu những gì bên dưới nó. K2.6 là một mô hình Mixture-of-Experts với 1 nghìn tỷ tham số từ Moonshot AI, được phát hành dưới dạng open-weight vào ngày 20 tháng 4 năm 2026 theo Giấy phép MIT đã sửa đổi. Sử dụng thương mại miễn phí dưới 20 triệu đô la doanh thu hàng tháng hoặc 100 triệu người dùng hoạt động hàng tháng — vì vậy nó thực tế miễn phí đối với hầu hết các nhà xây dựng.
0:29
Thông số kiến trúc
Thông số
Giá trị
Tổng tham số
~1,04 nghìn tỷ
Kích hoạt mỗi token
~32 tỷ (8 chuyên gia được chọn + 1 chuyên gia dùng chung)
Tổng số chuyên gia
384, trải đều trên 61 lớp transformer
Cửa sổ ngữ cảnh
262.144 token (262K)
Cơ chế Attention
Multi-Head Latent Attention (MLA) — dấu chân KV cache nhỏ hơn
Hàm kích hoạt
SwiGLU
Bộ mã hóa hình ảnh
MoonViT-3D (400M tham số, hình ảnh + video lên đến 2K)
Lượng tử hóa
INT4 thông qua Huấn luyện Nhận thức Lượng tử (QAT) (~594GB trên đĩa)
Kích thước trọng số FP16 đầy đủ
~2TB
Giấy phép
MIT đã sửa đổi
Biến thể INT4 QAT chạy gốc trên 4x H100 80GB. FP16 cần 8x H100 80GB. Cả ba framework suy luận được hỗ trợ (vLLM, SGLang, KTransformers) đều hiển thị API tương thích với OpenAI.
Phần 3: Trình tối ưu MuonClip, hay tại sao việc huấn luyện ổn định
Huấn luyện một MoE thưa với nghìn tỷ tham số mà không bị nổ là rất khó. Chế độ lỗi cụ thể: khi độ dài chuỗi tăng lên, tích vô hướng query-key (QK) trong các lớp attention có thể tăng không giới hạn. Bạn gặp phải các đột biến mất mát (loss spikes), và ở quy mô này, một đột biến mất mát có thể không thể phục hồi được.
Bài báo kỹ thuật Kimi K2 (arxiv: 2507.20534) giới thiệu MuonClip để giải quyết vấn đề này.
Muon là một trình tối ưu gradient hiệu quả về token hơn AdamW. Cùng chất lượng, ít bước huấn luyện hơn. Điểm hạn chế: riêng Muon gây ra sự bất ổn định attention ở quy mô nghìn tỷ tham số.
QK-Clip thêm việc cắt (clipping) cho mỗi token, mỗi head trực tiếp trên ma trận QK trước softmax. Điều này giới hạn độ lớn của điểm số attention và loại bỏ hiện tượng bùng nổ. Không cần điều chỉnh thủ công, không cần thủ thuật learning rate.
Từ phần tóm tắt của bài báo:
"Chúng tôi trình bày MuonClip, một trình tối ưu mới tích hợp thuật toán Muon hiệu quả về token với một cơ chế tăng cường ổn định gọi là QK-Clip... Sử dụng MuonClip, Kimi K2 đạt được hiệu suất cạnh tranh trong khi yêu cầu ít token huấn luyện hơn đáng kể so với các baseline AdamW."
Tại sao một nhà xây dựng nên quan tâm đến chi tiết huấn luyện? Bởi vì lý do K2.6 có thể duy trì 4.000 lần gọi công cụ trong suốt 12 giờ đồng hồ mà không bị suy giảm bắt nguồn từ điều này. Một mô hình được huấn luyện với sự bất ổn định attention có xu hướng ảo giác trong điều kiện ngữ cảnh dài, số bước cao. Đó chính xác là chế độ mà Agent Swarm hoạt động.
Phần 4: PARL, nghiên cứu đằng sau swarm
Agent Swarm không phải là một framework gắn thêm vào K2.6. Hành vi này đã được huấn luyện vào mô hình, thông qua một mô hình mà Moonshot gọi là PARL: Parallel-Agent Reinforcement Learning (Học tăng cường đa tác tử song song), được mô tả trong bài báo kỹ thuật Kimi K2.5 (arxiv: 2602.02276).
Bộ điều phối có thể huấn luyện, sub-agent bị đóng băng
Cách thông thường để xây dựng hệ thống đa tác tử là điều phối nhiều phiên bản mô hình trực tiếp ở tầng ứng dụng. Khi đó việc gán tín nhiệm (credit assignment) trở nên lộn xộn: agent nào trong số các agent của bạn đã làm cho câu trả lời cuối cùng tốt hay xấu? Huấn luyện end-to-end qua đồ thị đó là không khả thi về mặt tính toán.
PARL né tránh điều đó:
- Bộ điều phối có thể huấn luyện được, cập nhật thông qua RL dựa trên phần thưởng cho kết quả đầu ra.
- Các sub-agent bị đóng băng, là các điểm kiểm tra chính sách trung gian cố định.
Các quỹ đạo của sub-agent được coi là các quan sát môi trường, chứ không phải các điểm quyết định có thể vi phân. Điều đó tách rời hai vấn đề khó cùng một lúc. Tín nhiệm chỉ thuộc về hành động của bộ điều phối, không bao giờ thuộc về 300 sub-agent đồng thời. Và việc huấn luyện vẫn ổn định vì chỉ có một mô hình được cập nhật.
Bộ điều phối học khi nào nên song song hóa, bao nhiêu sub-agent cần tạo ra, và cách phân chia công việc. Không ai chỉ định thủ công các hành vi đó. Chúng xuất hiện từ việc tối đa hóa phần thưởng.
Hàm phần thưởng ba phần
Bộ điều phối được huấn luyện dựa trên ba tín hiệu.
Phần thưởng song song hóa thúc đẩy nó tạo ra các sub-agent đồng thời thay vì chạy tuần tự. Nếu không có điều này, mô hình sẽ mặc định mỗi lần một agent: an toàn, có thể dự đoán, nhưng chậm.
Phần thưởng hoàn thành đảm bảo các sub-agent thực sự hoàn thành nhiệm vụ của chúng. Điều này ngăn chặn "song song hóa giả tạo", nơi bộ điều phối tạo ra một đám agent không làm gì chỉ để kiếm phần thưởng song song hóa.
Phần thưởng hiệu suất tính điểm chất lượng đầu ra cuối cùng so với mục tiêu tác vụ. Đây là sự thật cơ bản mà mọi thứ khác phục vụ.
Chi tiết tôi thấy thú vị nhất: số liệu tối ưu hóa là các bước quan trọng (độ dài đường dẫn quan trọng), chứ không phải tổng số bước. Mô hình được thưởng vì rút ngắn chuỗi phụ thuộc dài nhất, chứ không phải vì tối đa hóa số lượng đồng thời thô. Đó là điều thực sự giảm thời gian thực tế.
Kết quả PARL
- BrowseComp: Chế độ swarm đạt 78,4% trên K2.5, tăng 17,8 điểm tuyệt đối so với K2.5 agent đơn (60,6%), vốn đã vượt qua GPT-5.2 Pro (77,9%) vào thời điểm đó. K2.6 đẩy con số này lên 86,3%.
- WideSearch: Cải thiện 6,3 điểm tuyệt đối trên Item-F1 (72,7% lên 79,0%)
- Thời gian thực tế: Giảm 3-4,5 lần trên các tác vụ có thể song song hóa so với baseline agent đơn
- Gọi công cụ song song: lên đến 4.000 bước phối hợp trong K2.6
Phần 5: Mooncake, hạ tầng đằng sau Kimi
Hạ tầng phục vụ của Moonshot giải thích lý do tại sao K2.6 có thể duy trì 300 agent song song mà không bị quá tải. Trọng số mô hình chỉ là một nửa câu chuyện; hệ thống phục vụ chúng là nửa còn lại.
Hạ tầng được cấu trúc tốt cho các Tác vụ Ngữ cảnh Dài
Kiến trúc phân tách lấy KVCache làm trung tâm
Nền tảng phục vụ của Moonshot được gọi là Mooncake, được mô tả trong bài báo hạ tầng năm 2024 của họ (arxiv: 2407.00079). Đây là động cơ chạy Kimi ở quy mô lớn, và lựa chọn thiết kế của nó là bất thường.
Suy luận LLM truyền thống chạy prefill (xử lý prompt đầu vào) và decode (sinh token) trên cùng một phiên bản GPU. Mooncake phân tách chúng thành các cụm riêng biệt:
- Cụm Prefill: xử lý prompt ban đầu, mở rộng quy mô độc lập cho đầu vào ngữ cảnh dài
- Cụm Decode: xử lý sinh token, tối ưu cho thông lượng và độ trễ
KV cache, trạng thái attention trung gian giúp sinh tự hồi quy hiệu quả, được quản lý như một tài nguyên hệ thống hạng nhất. Mooncake xây dựng một KV cache phân tán trải dài trên GPU VRAM, CPU DRAM và SSD, với một engine truyền tải tùy chỉnh di chuyển cache giữa các nút.
Tại sao điều này quan trọng đối với Agent Swarm
Khi 300 sub-agent chạy đồng thời, mỗi agent tạo ra KV cache riêng. Trong kiến trúc truyền thống, đó là áp lực bộ nhớ GPU lớn và xung đột lập lịch. Với cache phân tách của Mooncake:
- KV cache từ các sub-agent đã hoàn thành có thể được chuyển đến DRAM hoặc SSD và được triệu hồi nếu cần
- Cụm prefill xử lý các prompt hệ thống (thường lớn) cho mỗi sub-agent một cách độc lập
- Bộ lập lịch tối đa hóa thông lượng tổng thể trong khi vẫn duy trì SLO về độ trễ cho từng agent
Từ bài báo Mooncake: "So với phương pháp baseline, Mooncake có thể đạt được mức tăng thông lượng lên tới 525% trong một số kịch bản mô phỏng nhất định trong khi tuân thủ SLO. Dưới khối lượng công việc thực tế, kiến trúc sáng tạo của Mooncake cho phép Kimi xử lý nhiều hơn 75% yêu cầu."
Bài báo cập nhật báo cáo rằng Mooncake "hoạt động trên hàng nghìn nút, xử lý hơn 100 tỷ token mỗi ngày", và xử lý nhiều hơn 115% yêu cầu trên cụm A800 và 107% yêu cầu trên cụm H800 so với các hệ thống trước đó.
PD disaggregation ở quy mô lớn: triển khai K2 trên 128 GPU
LMSYS đã công bố một nghiên cứu điển hình về triển khai cho Kimi K2 sử dụng Prefill-Decode (PD) Disaggregation trên 128 GPU H200 thông qua SGLang Router. Kiến trúc:
- SGLang Router: dịch vụ nhẹ để khám phá dịch vụ động của các nút prefill và decode thông qua label selectors
- Expert Parallelism: 384 chuyên gia của K2 được phân phối trên các nút, với định tuyến ở cấp độ mạng
- OME (Open Model Engine): điều phối gốc Kubernetes cho tầng phục vụ
Đây là ngăn xếp chạy họ K2 ở quy mô sản xuất. Nếu bạn tự lưu trữ K2.6, đây là khuôn mẫu của bạn.
Phần 6: Agent Swarm hoạt động như thế nào, từng bước một
Trình tự cơ học khi K2.6 thực thi một tác vụ ở chế độ swarm:
Bước 1: Phân rã tác vụ
Bộ điều phối phân tích tác vụ và xây dựng đồ thị phụ thuộc: tác vụ con nào độc lập và có thể chạy song song, tác vụ nào phụ thuộc vào đầu ra trước đó.
Đối với "nghiên cứu 100 công ty YC và tạo ra một phân tích ngành", bộ điều phối xác định 100 tác vụ nghiên cứu độc lập, sau đó 1 tác vụ tổng hợp, sau đó 1 tác vụ tổng hợp cuối. Lớp đầu tiên có thể song song hóa hoàn toàn.
Bước 2: Tạo agent chuyên biệt
Bộ điều phối tạo ra các sub-agent chuyên biệt theo lĩnh vực dựa trên loại tác vụ con. K2.6 khởi tạo agent một cách linh hoạt với hướng dẫn theo vai trò cụ thể và quyền truy cập công cụ có mục tiêu:
- Agent nghiên cứu web: công cụ tìm kiếm + trình duyệt
- Agent phân tích dữ liệu: công cụ thực thi Python + bảng tính
- Agent viết: tổng hợp và tạo tài liệu
- Agent kiểm tra thông tin: đối chiếu và xác thực
Mỗi sub-agent hoạt động trong ngữ cảnh cục bộ giới hạn riêng của nó. Nó xử lý một tác vụ có phạm vi, tạo ra đầu ra có cấu trúc và kết thúc. Ngữ cảnh cục bộ không mang theo mọi thứ bộ điều phối biết, chỉ mang những gì sub-agent đó cần. Đây là cách K2.6 tránh bị tràn trong các tác vụ mà có thể làm đầy cửa sổ của bất kỳ agent đơn lẻ nào chỉ trong vài phút.
Bước 3: Thực thi song song theo đợt
Các agent thực thi theo đợt. Đợt đầu tiên xử lý các tác vụ hoàn toàn độc lập.
- Khi kết quả đến, bộ điều phối khởi chạy đợt thứ hai cho các tác vụ phụ thuộc vào đầu ra của đợt đầu, và cứ thế cho đến khi đồ thị phụ thuộc được giải quyết.
- K2.6 hỗ trợ tới 300 sub-agent và 4.000 bước phối hợp mỗi phiên. Bộ điều phối giám sát thực thi theo thời gian thực, phát hiện các agent bị lỗi hoặc bị đình trệ và tự động gán lại nhiệm vụ của chúng.
- Khả năng chịu lỗi đó là điều giúp các tác vụ tự động kéo dài 12 giờ đồng hồ trở nên khả thi mà không cần con người giám sát.
Bước 4: Tổng hợp và đầu ra
Khi tất cả sub-agent hoàn thành, bộ điều phối tổng hợp kết quả thành một sản phẩm cuối cùng: tài liệu, bảng tính, trang web, slide deck.
- Nó tổng hợp các đầu ra của agent thay vì nối chúng lại, do đó kết quả giữ được cấu trúc thống nhất.
- Một điều đáng chú ý nữa: cấu trúc swarm cũng là câu trả lời của Kimi cho vấn đề cửa sổ ngữ cảnh.
- Chính sách rõ ràng của K2.6: "khi cửa sổ ngữ cảnh vượt quá ngưỡng, chỉ giữ lại vòng thông điệp liên quan đến công cụ gần nhất." Swarm làm cho chính sách đó bền vững trên các chân trời tác vụ rất dài.
Phần 7: Kiến trúc Kimi x Claude Opus 4.8
Không có mô hình đơn lẻ nào là câu trả lời đúng cho mọi lớp của một swarm. Kimi K2.6 được xây dựng cho quy mô ngang — thực thi song song trên hàng trăm agent, các tác vụ tự động dài, xử lý hàng loạt hiệu quả về chi phí.
Claude Opus 4.8 được xây dựng cho khả năng phán đoán — lập kế hoạch, suy luận sắc thái và phát hiện lỗi của chính nó. Chúng bổ sung cho nhau về mặt cấu trúc, và khoảng trống mà mỗi mô hình để lại gần như có hình dạng của điểm mạnh của mô hình kia.
Mẫu hình:
1[Mục tiêu người dùng]2 |3[Claude Opus 4.8 - Người lập kế hoạch]4 Phân rã mục tiêu thành một đặc tả tác vụ có cấu trúc5 Xác định các tác vụ con song song vs. tuần tự6 Xác định tiêu chí thành công cho mỗi tác vụ con7 |8[Kimi K2.6 Agent Swarm - Người thực thi]9 Nhận đặc tả tác vụ có cấu trúc10 Tạo ra tới 300 sub-agent chuyên biệt11 Chạy song song qua các lần gọi công cụ12 Trả về kết quả có cấu trúc13 |14[Claude Opus 4.8 - Người xác minh]15 Xem xét đầu ra của Kimi dựa trên tiêu chí thành công16 Đánh dấu các lỗi, khoảng trống, mâu thuẫn17 Tổng hợp sản phẩm cuối cùng
Tại sao lại là Claude cho lập kế hoạch và xác minh?
Sự thay đổi bị đánh giá thấp nhất trong Opus 4.8 là sự cải thiện về tính trung thực: "Opus 4.8 có khả năng cho phép các lỗi trong mã nó viết mà không được chú ý ít hơn khoảng bốn lần so với người tiền nhiệm." Trong các hệ thống tác tử, sự tự tin sai lầm là chế độ lỗi thảm khốc.
- Một bộ điều phối nói "đã hoàn thành" trong khi chưa hoàn thành sẽ làm lan truyền lỗi cho 300 agent ở phía dưới. Xu hướng của Claude trong việc đánh dấu sự không chắc chắn và phát hiện lỗi của chính nó giữa tác vụ khiến nó trở thành mỏ neo đúng đắn cho các lớp nơi việc sai lầm rất tốn kém.
- Opus 4.8 cũng hỗ trợ cửa sổ ngữ cảnh 1M token, điều này quan trọng cho bước xác minh khi bạn kéo đầu ra từ 50+ agent nghiên cứu song song vào một bối cảnh xem xét duy nhất.
Tại sao lại là Kimi cho thực thi?
Agent Swarm của K2.6 hỗ trợ tới 300 sub-agent song song và 4.000 bước công cụ phối hợp mỗi phiên — đó là một hành vi được huấn luyện, không phải một lớp bọc ở tầng ứng dụng.
- Claude có tính năng Dynamic Workflows trong Claude Code, nhưng hiện đang trong bản xem trước nghiên cứu và chỉ giới hạn cho các gói Enterprise/Max.
- Khả năng swarm của Kimi có sẵn cho mọi người thông qua API ngay bây giờ. Kinh tế token cũng quan trọng ở quy mô lớn: K2.6 chạy ở mức $0,95/$4,00 mỗi triệu token đầu vào/đầu ra. Đối với thực thi song song hàng loạt, đó không phải là một con số nhỏ.
Phần 8: Khi nào bạn cần một swarm (và khi nào không)
Sai lầm phổ biến nhất trong thiết kế đa tác tử: thêm độ phức tạp của swarm trước khi bạn chạm đến trần của agent đơn.
Hãy ở lại với agent đơn khi:
- Tác vụ nằm gọn trong một cửa sổ ngữ cảnh duy nhất (dưới ~50K token công việc thực tế)
- Tác vụ về bản chất là tuần tự, mỗi bước phụ thuộc vào bước trước đó
- Bạn vẫn đang xây dựng nguyên mẫu — các chế độ lỗi của agent đơn dễ gỡ lỗi hơn nhiều
- Tác vụ sẽ hoàn thành trong vòng chưa đầy 10 phút
Hãy chuyển sang Agent Swarm khi:
- Tác vụ có n tác vụ con độc lập, song song với n > 5
- Tràn ngữ cảnh là một vấn đề thực sự (nghiên cứu sâu, cơ sở mã lớn, thao tác hàng loạt)
- Bạn cần các agent chuyên biệt theo lĩnh vực làm việc đồng thời
- Tác vụ quá dài để duy trì chất lượng qua một phiên tuần tự duy nhất
- Bạn muốn một agent phê bình hoặc xác minh kiểm tra công việc của agent khác
Sử dụng kết hợp Kimi + Claude Opus 4.8 khi:
- Chất lượng lập kế hoạch quan trọng và bạn muốn một mô hình sẽ phản đối nếu kế hoạch sai
- Đầu ra được xuất bản mà không cần con người xem xét thêm — vì vậy việc xác minh phải được tích hợp sẵn
- Bạn đang chạy thực thi khối lượng lớn mà chi phí token tăng nhanh chóng
- Bạn muốn khả năng phán đoán của Claude trên các lớp quyết định và quy mô của Kimi trên các lớp công việc
Phần 10: Bốn mẫu hình kiến trúc swarm
Mẫu hình 1: Người điều phối - Người lao động (phổ biến nhất)
Một bộ điều phối trung tâm gán tác vụ con cho các worker, worker thực thi song song, kết quả tổng hợp.
1[Mục tiêu người dùng]2 |3[Bộ điều phối - 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[Bộ tổng hợp - Claude Opus 4.8]9 |10[Đầu ra cuối cùng]
Phù hợp nhất cho: các tác vụ có tác vụ con có thể tách biệt rõ ràng và số lượng worker thay đổi.
Mẫu hình 2: Vòng lặp phê bình - tinh chỉnh
Một agent tạo ra, một agent khác phê bình, lặp lại cho đến khi đạt ngưỡng chất lượng.
1[Kimi K2.6 Builder] -> bản nháp -> [Claude Opus 4.8 Critic] -> phản hồi -> [Kimi K2.6 Builder]2 |3 (đã phê duyệt)4 [Đầu ra cuối cùng]
Phù hợp nhất cho: tạo mã, viết tài liệu kỹ thuật, đầu ra nhạy cảm với tuân thủ. Luôn đặt giới hạn số lần lặp tối đa.
Mẫu hình 3: Phân cấp
Một bộ điều phối chiến lược quản lý các bộ điều phối lĩnh vực, các bộ điều phối này quản lý các worker.
1[Claude Opus 4.8 - Bộ điều phối chiến lược]2 +-- [Kimi K2.6 Swarm - Nhóm Nghiên cứu (50 agent)]3 +-- [Kimi K2.6 Swarm - Nhóm Xây dựng (50 agent)]
Phù hợp nhất cho: quy trình doanh nghiệp lớn với các lĩnh vực riêng biệt.
Mẫu hình 4: Nhóm Claw (swarm không đồng nhất gốc Kimi)
K2.6 điều phối các agent chạy bất kỳ mô hình nào, bao gồm mô hình cục bộ, Claude và GPT, cùng với các worker là con người trong một không gian hoạt động chung. Hiện đang trong bản xem trước nghiên cứu.
1[Kimi K2.6 Điều phối viên]2 +-- [Claude Opus 4.8 - chuyên gia lý luận]3 +-- [Llama 3.3 cục bộ - tác vụ hàng loạt nhạy cảm chi phí]4 +-- [Kimi K2.6 agents x N - lớp thực thi]5 +-- [Người đánh giá - điểm kiểm tra phê duyệt]
Phù hợp nhất cho: quy trình cần sự đa dạng mô hình, kết hợp cục bộ + đám mây, hoặc yêu cầu con người trong vòng lặp.
Phần 12: Thiết kế prompt cho tác vụ swarm
Prompt phân rã (dành cho bộ điều phối)
1Bạn là một kiến trúc sư tác vụ. Hãy phân rã mục tiêu này thành các tác vụ con độc lập, có thể song song hóa.23Quy tắc:4- Mỗi tác vụ con phải có thể hoàn thành bởi một agent chuyên biệt duy nhất trong sự cô lập5- Các tác vụ con có phụ thuộc phải được đánh dấu bằng chuỗi phụ thuộc của chúng6- Đầu ra dưới dạng JSON: {task_id, description, agent_type, depends_on, success_criteria}78Mục tiêu: {user_goal}9Các loại agent có sẵn: nhà nghiên cứu, nhà phân tích, lập trình viên, người viết, người xác minh
Prompt hệ thống chuyên biệt (dành cho sub-agent)
1Bạn là một agent {ROLE} chuyên về {DOMAIN}.23Tác vụ: {subtask_description}45CÁC RÀNG BUỘC:6- Chỉ trả về JSON hợp lệ khớp với: {output_schema}7- Không vượt quá phạm vi tác vụ của bạn8- Nếu bạn không thể hoàn thành tác vụ: {"error": "lý do", "partial_results": [...]}9- Số lần gọi công cụ tối đa: {max_tool_calls}1011Ngữ cảnh: {context_from_orchestrator}
Prompt tổng hợp (dành cho bộ tổng hợp)
1Tổng hợp nghiên cứu từ {n} agent chuyên biệt thành một đầu ra mạch lạc.231. Đọc tất cả đầu ra của agent được cung cấp42. Xác định nơi chúng đồng ý, bất đồng hoặc có khoảng trống53. Tạo ra một {output_type} tích hợp tất cả các phát hiện64. Chỉ ra những mâu thuẫn một cách rõ ràng — không âm thầm giải quyết các mâu thuẫn78Đầu ra của agent: {agent_outputs_as_json}9Định dạng đầu ra: {final_output_spec}
Phần 13: Bảy lan can bảo vệ bất di bất dịch
1. Số lần lặp tối đa cho mỗi agent. Giới hạn cứng đối với các vòng lặp trước khi thông báo cho bộ điều phối.
2. Thời gian chờ phiên. Nếu swarm chưa hoàn thành trong N phút, hãy kết thúc và trả về kết quả một phần.
3. Thực thi đầu ra có cấu trúc. Buộc các agent trả về JSON. Văn xuôi từ các agent trung gian tạo ra lỗi phân tích cú pháp ở phía sau.
4. Cô lập lỗi. Một sub-agent bị lỗi không được làm hỏng bộ điều phối.
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=40967 )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. Thử lại với thời gian chờ tăng dần theo hàm mũ. Xử lý các lỗi 429 và lỗi tạm thời mà không coi chúng là lỗi vĩnh viễn.
6. Điểm kiểm tra có con người trong vòng lặp. Đối với các swarm có quyền ghi (triển khai mã, gửi email, thực hiện đột biến API), hãy chèn các lần tạm dừng phê duyệt bắt buộc.
7. Giám sát chi phí. Đặt ngân sách token cho mỗi lần chạy. Các vòng lặp chạy không kiểm soát luôn thể hiện dưới dạng bất thường chi phí trước khi chúng thể hiện dưới dạng lỗi chất lượng.
Nên xây dựng cái gì trước tiên
Hãy bắt đầu với đường ống ba agent từ Phần 9. Nó đủ nhỏ để gỡ lỗi trong một buổi chiều, nó rèn luyện khả năng lập kế hoạch, thực thi song song và xác minh, và bạn có thể chạy nó với một tác vụ thực tế trong vòng chưa đầy một giờ thiết lập.
Khi nó hỏng — và chắc chắn nó sẽ hỏng — chế độ lỗi sẽ dạy cho bạn nhiều hơn về thiết kế swarm so với một giờ đọc tài liệu khác.
Hãy xây dựng nó. Hãy cố tình làm hỏng nó. Sau đó quay lại các mẫu hình trong Phần 11 với một điểm tham chiếu cụ thể.
Kiến trúc không phải là phần khó. Phần khó là khoảng cách giữa "hoạt động trong thử nghiệm" và "hoạt động lúc 3 giờ sáng mà không có ai giám sát", và khoảng cách đó hoàn toàn nằm ở các lan can bảo vệ, khả năng quan sát và thiết kế bộ nhớ.
Kết luận
Kimi 2.6 là một cuộc cách mạng về agent, cho thấy cách học tăng cường có thể thiết lập các agent swarm.
Nó cũng cho thấy cách các chân trời ngữ cảnh dài có thể tận dụng các hạ tầng dựa trên bộ điều phối như vậy, cho phép tạo ra nhiều sub-agent để xây dựng các hệ thống phức tạp chỉ bằng một
Tuyên bố miễn trách trách nhiệm
Bài viết được viết bằng cách sử dụng tài liệu kỹ thuật Kimi 2.6 và các bài báo nghiên cứu trong ghi chú của tác giả, và được biên tập bởi AI, Opus 4.7.
