Multi-Agent Collaboration Patterns and Engineering Practices

Preface

As the capabilities of LLMs continue to expand, an obvious question surfaces: Can a single Agent solve all problems?

The answer is no. Just as software development evolved from monolithic architectures to microservices, Agent architectures are undergoing a similar evolution. When facing complex business scenarios, a single Agent is often limited by its context window, the scale of its toolset, and decision-making biases akin to "single points of failure." Multi-Agent systems, through the division of labor and collaboration among multiple Agents, are becoming the core paradigm for Agent engineering.

This article will break down the practical experience of Multi-Agent systems from three dimensions: pattern classification, architecture design, and engineering practices.

---

1. Why Multi-Agent?

Bottlenecks of a Single Agent

In actual production environments, single-Agent architectures often face the following problems:

1. Context Overload: One Agent needs to simultaneously handle system instructions, user requirements, tool descriptions, and conversation history, easily hitting the upper limit of the context window.
2. Toolset Bloat: The more tools an Agent has, the lower its accuracy in selecting the correct one (research shows a significant drop in accuracy when exceeding 20 tools).
3. Role Conflict: The same Agent is required to perform rigorous data calculations and generate creative copy, making style switching difficult.
4. Single Point of Vulnerability: When an Agent makes an error in one step, it lacks a "peer review" mechanism, and the error propagates all the way to the final result.

Advantages of Multi-Agent

• Specialized Division of Labor: Each Agent focuses on its own domain, just like a team has backend, frontend, and design roles.
• Parallel Processing: Multiple Agents can handle independent sub-tasks simultaneously, significantly reducing response time.
• Fault Tolerance: Cross-validation and review mechanisms among Agents reduce the single-point error rate.
• Scalability: Adding new capabilities only requires adding a new Agent, without modifying the existing system.

---

2. Classification of Multi-Agent Collaboration Patterns

Based on different collaboration methods, I categorize Multi-Agent systems into the following four core patterns:

1. Star Pattern (Orchestrator-Worker)

Structure: A master control Agent (Orchestrator) is responsible for task decomposition, scheduling, and result integration, while multiple Worker Agents execute specific sub-tasks.

Applicable Scenarios: Complex task decomposition, such as code generation, data analysis reports, and multi-step workflows.

Typical Flow:

Orchestrator (Master Control)
  ├── Worker 1: Requirements Analysis
  ├── Worker 2: Solution Design
  ├── Worker 3: Code Implementation
  ├── Worker 4: Testing & Verification
  └── Worker 5: Documentation Generation

Pros and Cons:

• ✅ Clear structure, easy to manage and debug
• ✅ The Orchestrator can control overall quality
• ❌ The Orchestrator can become a bottleneck
• ❌ Communication overhead increases with the number of Workers

2. Pipeline Pattern

Structure: Tasks pass through multiple Agents in sequence, with each Agent handling a specific stage. The output of one serves as the input for the next.

Applicable Scenarios: Processes with clear sequential steps, such as content review, data cleaning, and multi-stage processing.

Typical Flow:

Agent A (Data Collection) → Agent B (Data Cleaning) → Agent C (Data Analysis) → Agent D (Report Generation)

Pros and Cons:

• ✅ Clear responsibilities; each stage can be optimized independently
• ✅ Easy to add intermediate review nodes
• ❌ Overall latency equals the sum of all stages
• ❌ Errors from preceding Agents are amplified

3. Debate Pattern (Debate / Verifier)

Structure: Multiple Agents complete a task independently, then reach a consensus through discussion, debate, or voting.

Applicable Scenarios: Decision-making scenarios requiring high accuracy, such as code review, risk assessment, and fact-checking.

Typical Flow:

Agent A: Independent Analysis → Conclusion
Agent B: Independent Analysis → Conclusion
Agent C: Independent Analysis → Conclusion
        ↓
    Arbitration Agent: Summarizes the three conclusions, identifies points of disagreement, and guides discussion
        ↓
    Final Consensus

Pros and Cons:

• ✅ Significantly improves accuracy (research suggests error rates can be reduced by over 40%)
• ✅ Multiple perspectives avoid blind spots in thinking
• ❌ High computational cost (multiple LLM calls)
• ❌ May fall into endless debate loops

4. Hierarchical Pattern

Structure: A tree-like structure of Agents across multiple levels. High-level Agents are responsible for strategy and direction, while low-level Agents handle execution and details.

Applicable Scenarios: Large-scale complex systems, such as enterprise-level automation platforms and automated operations.

Typical Flow:

Level 1: Strategy Agent (Determines goal priority)
  ├── Level 2: Planning Agent (Creates execution plan)
  │   ├── Level 3: Execution Agent 1 (Specific operation)
  │   ├── Level 3: Execution Agent 2 (Specific operation)
  │   └── Level 3: Execution Agent 3 (Specific operation)
  └── Level 2: Monitoring Agent (Tracks progress, handles exceptions)

Pros and Cons:

• ✅ Can scale to very large systems
• ✅ Clear responsibilities at each level make it easy to locate problems
• ❌ High architectural complexity, difficult to debug
• ❌ Communication latency accumulates between layers

---

3. Engineering Practices: From Pattern to Implementation

Practical Case: Automated Code Review System

Our team built an automated code review system using a Multi-Agent pattern, adopting a hybrid architecture of Debate Pattern + Star Pattern.

Architecture Design

Orchestrator Agent (Master Control)
  │
  ├── Code Review Agent A (Focuses on code standards & style)
  ├── Code Review Agent B (Focuses on performance & security)
  ├── Code Review Agent C (Focuses on architecture & design patterns)
  │
  └── Arbitration Agent (Arbitration & summary report)

Key Implementation Details

1. Inter-Agent Communication Protocol

Each Agent's output must follow a unified format to be understood by other Agents:

@dataclass
class AgentMessage:
    agent_id: str
    task_id: str
    message_type: MessageType  # ANALYSIS | REVIEW | VERDICT | QUESTION
    content: dict
    confidence: float  # 0.0 - 1.0
    references: list[str]  # Referenced code line numbers or file paths

2. Debate Round Control

To prevent infinite debates, we set a maximum number of debate rounds and convergence conditions:

MAX_DEBATE_ROUNDS = 3
CONVERGENCE_THRESHOLD = 0.85  # Consensus is reached if confidence exceeds 0.85

def should_continue_debate(responses: list[AgentMessage]):
    if responses.round >= MAX_DEBATE_ROUNDS:
        return False
    avg_confidence = sum(r.confidence for r in responses) / len(responses)
    return avg_confidence < CONVERGENCE_THRESHOLD

3. Context Management Strategy

Each Agent does not need to see the entire context; it only receives the part relevant to its responsibilities:

def prepare_context_for_agent(agent_role: str, code_diff: str, full_context: dict):
    if agent_role == "style":
        return {
            "code": code_diff,
            "rules": full_context["style_guide"],
            "focus": "Code standards, naming, formatting"
        }
    elif agent_role == "performance":
        return {
            "code": code_diff,
            "rules": full_context["performance_guide"],
            "focus": "Time complexity, resource usage, security vulnerabilities"
        }
    # ...

Practical Case: Content Generation Pipeline

Another case is an automated content generation system, which uses the Pipeline Pattern.

Topic Selection Agent → Outline Agent → Writing Agent → Review Agent → Formatting Agent
(Analyzes trends)   (Generates structure) (Fills content) (Quality check) (Format optimization)

Each Agent is equipped with a dedicated toolset:

• Topic Selection Agent: Web search, trend analysis API
• Outline Agent: Mind mapping tools, structure template library
• Writing Agent: Long-text generation, RAG retrieval
• Review Agent: Fact-checking API, grammar checking tools
• Formatting Agent: Markdown rendering, image search

---

4. Pitfall Avoidance Guide

1. Managing Communication Overhead

If inter-Agent communication involves full-text transmission, it will quickly exhaust the context window. Recommended practices:

• Transmit only incremental information and references
• Use structured data formats (JSON/Protobuf) instead of natural language
• Set a message length limit

2. Choosing the Number of Agents

More is not always better. Based on our actual test data:

Number of Agents	Task Completion Rate	Average Latency	Cost
1	72%	5s	1x
2-3	85%	12s	3x
4-5	91%	25s	6x
6+	93%	45s+	10x+

Recommendation: 2-4 Agents offer the best cost-performance ratio.

3. Error Propagation and Isolation

In a pipeline pattern, an error from one Agent will spread downstream. Solutions:

• Add a validation step at each stage
• Use the Circuit Breaker pattern: when an Agent fails continuously, degrade by using a default value
• Introduce a Checkpoint mechanism: periodically save intermediate states for easy rollback and retry

4. Debugging and Observability

Debugging a Multi-Agent system is extremely difficult. The following infrastructure is essential:

# Must log every round of Agent communication
logging.setup_agent_tracing(
    trace_id=task_id,
    export_to="otel_collector:4318"
)

# The input/output of each Agent must be serialized and stored
async def run_agent(agent, task):
    input_snapshot = snapshot(task)
    result = await agent.run(task)
    output_snapshot = snapshot(result)
    store_interaction(agent.id, input_snapshot, output_snapshot)
    return result

---

5. Comparison of Mainstream Frameworks

Feature	AutoGen (Microsoft)	CrewAI	LangGraph	Custom-built
Collaboration Pattern	Debate/Dialogue	Star/Pipeline	Graph/Pipeline	Flexible
Learning Curve	Medium	Low	High	-
Customizability	High	Medium	High	Very High
Debugging Tools	Yes	Weak	Weak	Self-built
Production Readiness	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐

Selection Suggestions:

• Rapid prototyping → CrewAI
• Complex graph-like flows → LangGraph
• Multi-Agent dialogue/debate → AutoGen
• Production environment customization → Build custom on top of a framework

---

Summary

Multi-Agent is not a silver bullet, but it is an inevitable direction for tackling complex AI applications. The key is not "how many Agents are used," but how to design the collaboration pattern.

Based on my practical experience, I recommend following these principles:

1. Start Simple: First validate the pattern with 2-3 Agents, then gradually expand.
2. Communication Cost is the Core Bottleneck: Design the messaging protocol between Agents well.
3. Prioritize Observability: Without a good tracing system, a Multi-Agent system is a black box.
4. Hybrid Patterns are More Practical: Most production systems need to combine multiple collaboration patterns.

If you are building an Agent system, why not start experimenting with a Multi-Agent architecture today? After all, a team goes further than an individual—this saying applies to Agents as well.

---

This article is the 5th in the "Agent Engineering" series. Feel free to follow and discuss; leave your questions in the comments.