TL;DR

Phần 3 của series về AI Agent Swarms. Phần 1 cover kiến trúc và nền tảng. Phần 2 cover Mooncake và cách swarm hoạt động. Bài này là phần thực hành: khi nào dùng swarm, 4 pattern kiến trúc, prompt design, và 7 guardrail không thể thiếu nếu bạn muốn swarm chạy được lúc 3 giờ sáng không có người theo dõi.

Khi Nào Dùng Swarm (Và Khi Nào Không)

Sai lầm phổ biến nhất trong multi-agent design: thêm độ phức tạp của swarm trước khi bạn đã chạm trần của single-agent.

Dùng single-agent khi

  • Task vừa vặn trong một context window (dưới ~50K token actual work)

  • Task có bản chất tuần tự, mỗi bước phụ thuộc bước trước

  • Bạn vẫn đang prototype - single-agent failure mode dễ debug hơn nhiều

  • Task sẽ hoàn thành trong dưới 10 phút

Dùng Agent Swarm khi

  • Task có n parallel, independent subtask với n > 5

  • Context overflow là vấn đề thực sự (deep research, codebase lớn, batch operation)

  • Bạn cần domain-specialized agent làm việc đồng thời

  • Task quá dài để duy trì chất lượng trong một sequential session

  • Bạn muốn critic agent kiểm tra output của agent khác

Dùng hybrid Kimi + Claude Opus 4.8 khi

  • Chất lượng planning quan trọng và bạn muốn mô hình push back nếu plan sai

  • Output được ship mà không có human review thêm - verification phải được bake-in

  • Bạn chạy high-volume execution nơi token cost cộng dồn nhanh

  • Bạn muốn judgment của Claude ở các decision layer và scale của Kimi ở work layer

4 Pattern Kiến Trúc Swarm

Pattern 1: Orchestrator-worker (phổ biến nhất)

Một central orchestrator giao subtask cho worker, worker thực thi song song, kết quả được aggregate.

[User Goal]
    |
[Orchestrator - Claude Opus 4.8]
    +-- [Worker: Kimi Research Agent x N]
    +-- [Worker: Kimi Data Agent x N]
    +-- [Worker: Kimi Code Agent x N]
    |
[Synthesizer - Claude Opus 4.8]
    |
[Final Output]

Tốt nhất cho: các task có subtask tách biệt rõ ràng và số lượng worker biến đổi.

Pattern 2: Critic-refiner loop

Một agent produce, agent khác critique, lặp lại cho đến khi đạt quality threshold.

[Kimi K2.6 Builder] -> draft -> [Claude Opus 4.8 Critic] -> feedback -> [Kimi K2.6 Builder]
                                       |
                                  (approved)
                               [Final Output]

Tốt nhất cho: code generation, technical writing, compliance-sensitive output. Luôn đặt max-iterations limit.

Pattern 3: Hierarchical

Một strategic orchestrator quản lý domain orchestrator, domain orchestrator quản lý worker.

[Claude Opus 4.8 - Strategic Orchestrator]
    +-- [Kimi K2.6 Swarm - Research Team (50 agents)]
    +-- [Kimi K2.6 Swarm - Build Team (50 agents)]

Tốt nhất cho: enterprise workflow lớn với các domain riêng biệt.

Pattern 4: Claw Groups (Kimi-native heterogeneous swarm)

K2.6 coordinate các agent chạy bất kỳ mô hình nào - bao gồm local model, Claude, GPT - cùng human worker trong shared operational space. Hiện đang trong research preview.

[Kimi K2.6 Coordinator]
    +-- [Claude Opus 4.8 - reasoning specialist]
    +-- [Llama 3.3 local - cost-sensitive bulk tasks]
    +-- [Kimi K2.6 agents x N - execution layer]
    +-- [Human reviewer - approval checkpoints]

Tốt nhất cho: workflow cần model diversity, hybrid local + cloud, hoặc human-in-the-loop.

Prompt Design Cho Swarm Task

Decomposition prompt (orchestrators)

You are a task architect. Decompose this goal into independent, parallelizable subtasks.
Rules:
- Each subtask must be completable by a single specialized agent in isolation
- Subtasks with dependencies must be marked with their dependency chain
- Output as JSON: {task_id, description, agent_type, depends_on, success_criteria}
Goal: {user_goal}
Available agent types: researcher, analyst, coder, writer, verifier

Specialist system prompt (sub-agents)

You are a {ROLE} agent specializing in {DOMAIN}.
Task: {subtask_description}
CONSTRAINTS:
- Return ONLY valid JSON matching: {output_schema}
- Do NOT go beyond your task scope
- If you cannot complete the task: {"error": "reason", "partial_results": [...]}
- Maximum tool calls: {max_tool_calls}
Context: {context_from_orchestrator}

Aggregation prompt (synthesizers)

Synthesize research from {n} specialized agents into a coherent output.
1. Read all provided agent outputs
2. Identify where they agree, disagree, or have gaps
3. Produce a {output_type} integrating all findings
4. Call out inconsistencies explicitly - do not silently resolve contradictions
Agent outputs: {agent_outputs_as_json}
Output format: {final_output_spec}

7 Guardrail Không Thể Thiếu

1. Max iterations per agent. Giới hạn cứng trên loop trước khi orchestrator được thông báo.

2. Session timeout. Nếu swarm chưa hoàn thành trong N phút, terminate và trả về partial results.

3. Structured output enforcement. Bắt buộc agent trả về JSON. Prose từ intermediate agent tạo downstream parsing failure.

4. Failure isolation. Sub-agent fail không được crash orchestrator:

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

5. Retry với exponential backoff. Xử lý 429 và transient error mà không expose chúng như permanent failure.

6. Human-in-the-loop checkpoints. Với swarm có write access (deploy code, gửi email, tạo API mutation), chèn mandatory approval pause.

7. Cost monitoring. Đặt per-run token budget. Runaway loop xuất hiện như cost anomaly trước khi xuất hiện như quality failure - luôn luôn như vậy.

Kết

Kimi K2.6 là bằng chứng về cách reinforcement learning có thể thiết lập agent swarm như một hành vi được train vào mô hình, không phải được tạo ra ở application layer. PARL cho thấy rằng một orchestrator trainable đơn lẻ với frozen subagent có thể học cách phân rã task, quản lý dependency, và tối ưu hóa critical path - không cần hand-coded rules.

Bắt đầu với three-agent pipeline từ Pattern 1 (Phần 2 của series). Nó đủ nhỏ để debug trong một buổi chiều, đủ để exercise planning, parallel execution, và verification, và bạn có thể chạy nó trên task thực trong dưới một giờ setup.

Khi nó hỏng - và nó sẽ hỏng - failure mode sẽ dạy bạn về swarm design nhiều hơn thêm một giờ đọc. Kiến trúc không phải là phần khó. Phần khó là khoảng cách giữa "chạy được khi test" và "chạy được lúc 3 giờ sáng không có ai theo dõi" - và khoảng cách đó hoàn toàn nằm ở guardrail, observability, và memory design.

via Kimi K2 technical paper (MuonClip) & Kimi K2.5 technical paper (PARL) & Mooncake infrastructure paper