Langmanus Multi-Agent Framework Deep Dive: Architecture Principles and Agent Extension in Practice

Why We Need Multi-Agent Frameworks

In AI application development, a single large model often struggles to handle complex end-to-end tasks. A typical scenario might require searching for information first, then analyzing and planning, followed by writing code, and finally generating a report—each step has different requirements, and a single prompt can rarely handle them all.

The concept of Multi-Agent Systems (MAS) originally emerged from distributed artificial intelligence research, and experienced an explosion in 2023-2024 as large language model capabilities took a quantum leap. Stanford's "Generative Agents" experiment, the open-source frenzy around AutoGPT, and Microsoft's release of the AutoGen framework collectively drove the popularization of this paradigm. The core idea is: rather than having one model shoulder all responsibilities, let multiple specialized agents each handle their own domain and collaborate to complete tasks—this aligns closely with the microservices architecture philosophy in software engineering.

Langmanus was born precisely to address this pain point as a multi-agent framework. Developed by the ByteDance team (later removed from TikTok for various reasons), it's built on LangGraph and orchestrates multiple AI agents into a collaborative graph, enabling automatic task decomposition, distribution, and execution. Although the project has experienced some turbulence, its architectural design and orchestration philosophy remain well worth studying in depth.

LangGraph Fundamentals: Understanding Core Concepts of Graph Orchestration

Everything is a Graph

The underlying framework of Langmanus is LangGraph, whose core idea is very intuitive—orchestrate the entire execution flow as a directed graph.

LangGraph is an agent orchestration framework released by the LangChain team in 2024. It addresses the limitations of early LangChain's chain-based calls when handling complex branching and loops. LangGraph draws on concepts from Finite State Machines (FSM) and dataflow programming, abstracting the agent's execution flow into a directed graph. Unlike traditional DAG (Directed Acyclic Graph) workflow engines, LangGraph explicitly supports cycles, enabling agents to iterate repeatedly and self-correct until they achieve their goal—this is exactly the infrastructure that the ReAct (Reasoning + Acting) pattern requires.

The graph has two special nodes: Start node and End node. Tasks depart from the Start node, pass through various functional nodes in sequence, and ultimately reach the End node. Each node can be a simple function, an AI Agent, or even another nested subgraph.

Edges in the graph come in two types:

• Solid edges: Deterministic single paths—from A you always go to B
• Conditional edges (dashed): The LLM determines the direction based on current data, enabling dynamic routing

Since it's a directed graph, flow between nodes is unidirectional by default, but loops can be implemented through explicit definitions, enabling the construction of various topological structures such as mesh, supervisory, and ladder patterns.

State: The Information Carrier in Transit

There's a key concept in LangGraph called State, which is essentially a dictionary data structure. Each node receives the State, processes data, appends results to the State, and passes it to the next node.

State's design draws on the philosophy of frontend state management libraries like Redux, adopting the concept of immutable data flow. Each node's modification to State isn't a direct overwrite but rather a merge through Reducer functions—for example, message list fields default to an append strategy rather than replacement. This design ensures data consistency when multiple nodes execute concurrently, while also providing the foundation for implementing Checkpoints and time-travel debugging. State also supports a Channel mechanism, allowing selective sharing or isolation of data between different nodes.

State serves as the carrier for information flow throughout the entire graph, containing user input, planning steps, intermediate results, and all other key information. Think of it as a "work order" being passed along an assembly line, where each workstation (node) fills in the section they're responsible for.

Langmanus Architecture Explained: How Six Roles Collaborate

Langmanus designs a universal multi-agent architecture on top of LangGraph that can cover a wide range of real-world task scenarios. Let's break down each core role.

Coordinator: The First Checkpoint for Tasks

The Coordinator is similar to a company receptionist, responsible for initially assessing the nature of user requests. If it's simple chitchat (like "Hello, who are you?"), it responds politely and terminates; if it's a complex task requiring multi-agent collaboration, it forwards the request to the Planner.

This design avoids wasting resources by running simple questions through the entire pipeline. In production environments, this "intent recognition + fast short-circuit" pattern is very common—similar to an IVR (Interactive Voice Response) routing mechanism in customer service systems, using low-cost methods to filter out simple requests so that only tasks truly requiring deep processing enter the complex workflow.

Planner: The Brain of the Task

The Planner uses a reasoning model (such as QWQ-32B) to perform deep analysis and step decomposition of tasks. It also supports a clever configuration—Search Before Planning, which searches the internet for background information before planning, making the plan more precise.

For example, when a user asks "Introduce news about the Myanmar earthquake and write it as a report," the Planner would decompose it into:

1. Search and collect basic earthquake information
2. Search for earthquake causes and impacts
3. Integrate information to generate a research report

A notable pitfall: The step order output by the Planner may not be strictly followed during actual execution, and some steps might even be skipped. This is because the Supervisor dynamically determines which steps are still necessary based on information already present in the current State. While this "elastic execution" increases flexibility, it also presents certain debugging challenges.

Supervisor: The Task Dispatch Center

The Supervisor acts as a project team lead, responsible for assigning planned steps one by one to specific execution agents. It uses structured JSON output to decide which node to call next, making routing decisions precise and controllable.

Structured Output is a critical technique in LLM application engineering. Traditional natural language output has format uncertainty, making it difficult for downstream programs to parse reliably. Through mechanisms like Function Calling, JSON Mode, or Pydantic Schema constraints, models can be forced to output JSON data conforming to predefined formats. In Langmanus, the Supervisor uses structured output to specify the name of the next execution node—this is far more reliable than extracting routing information from free text, significantly reducing the risk of workflow interruptions caused by model output format errors.

Execution Layer Agents: Specialized Players in Their Domains

The execution layer contains multiple specialized agents, each handling different task types:

• Researcher: Equipped with search engine and web crawler tools, supporting repeated invocations until the task is complete. The Researcher itself is also a subgraph (created via create_react_agent), embodying the nested "graph within a graph" design. create_react_agent creates an agent based on the ReAct paradigm—ReAct (Reasoning and Acting) was proposed by a Google research team in 2022. Its core idea is to have the LLM alternate between "reasoning" and "acting" when executing tasks: the model first thinks about what should be done (Thought), then calls external tools to perform operations (Action), observes the returned results (Observation), and then decides on the next action. This loop continues until the model believes it has gathered sufficient information to provide a final answer, making it particularly suitable for scenarios requiring multiple rounds of information retrieval and verification.
• Coder: Equipped with Python code writing and Bash script execution tools, compensating for LLMs' computational limitations. Large language models have inherent weaknesses in precise mathematical calculations and data processing. By having the model generate code and actually execute it, "approximate reasoning" can be transformed into "precise computation"—this is the Code Interpreter pattern widely adopted in the current AI Agent field.
• Browser: Uses Vision models to process image-related information
• Reporter: Responsible for final report writing and output

Model Configuration Strategy: Assigning Different Models by Role

One of Langmanus's elegant aspects is differentially assigning models by role, rather than using the same large model for all nodes:

Model Type	Specific Model	Applicable Roles
Reasoning Model	QWQ-32B	Planner (requires deep thinking)
Base Model	Qwen-32B	Coordinator, Supervisor, Researcher, etc.
Vision Model	Vision Model	Browser (processing images)

This differentiated configuration ensures reasoning quality at critical stages while effectively controlling overall API call costs. In production environments, API call cost is a real issue that multi-agent systems must face. Taking OpenAI as an example, GPT-4o's call cost is approximately 15-20x that of GPT-4o-mini. If all nodes use the most powerful model, a single complex task might involve dozens of API calls, causing costs to escalate rapidly. Langmanus's differentiated configuration strategy is essentially "rational allocation of computational resources": using high-performance models only at stages that truly require deep reasoning (like planning), while using lightweight models for relatively simpler tasks like routing decisions and information integration. This approach is known in industry as "Model Cascading" and is one of the core strategies for cost reduction and efficiency improvement in LLM applications.

Hands-On Extension: Adding a Custom Weather Agent

The true value of a framework lies in its extensibility. Below, we demonstrate how to extend a new Agent node in Langmanus using the example of adding a weather query agent.

Step 1: Create an External Agent Service

On the Alibaba Cloud Bailian platform, create a weather query agent using the Amap (Gaode Maps) MCP service:

1. Enter the Bailian platform and select Amap from the MCP services
2. Configure the agent with an LLM, prompts, and MCP tools
3. After publishing, obtain the application ID for API calls

MCP (Model Context Protocol) is an open protocol released by Anthropic in late 2024, aimed at standardizing interactions between LLMs and external tools and data sources. Before MCP, each tool integration required writing specialized adapter code; MCP defines unified communication specifications so that tool providers only need to implement an MCP Server once, and any MCP-supporting client can call it directly. The Amap MCP service integrated in Alibaba Cloud's Bailian platform is a typical application of this ecosystem—developers don't need to understand the specifics of the Amap API and can give agents geographic information query capabilities through the MCP protocol.

Step 2: Register the New Node in the Graph

Add a weather node in the Graph configuration, defining its call logic (calling the Alibaba Cloud agent service) and return path (returning to the Supervisor for next-step dispatch).

Step 3: Notify Relevant Roles Through Prompts

This is the most critical and elegant step—only prompts need to be modified, with no changes to the framework's core code:

• Add to the Planner's prompt: "Use the weather node to query weather information"
• Add weather as an available downstream node in the Supervisor's prompt

The entire extension process is completed simply by adding nodes and adjusting prompts, embodying Langmanus's prompt-driven, lightweight extension design philosophy. This design coincides with the "Open-Closed Principle" in traditional software engineering (open for extension, closed for modification)—new functionality doesn't require modifying existing core logic, only declarative configuration changes at the periphery.

Verifying the Extension

Turn off web search (set to false) to prevent the Researcher from obtaining weather information directly through web searches. When asking "Check the weather in Beijing," the Planner will automatically identify and invoke the weather agent, ultimately generating a weather report.

Summary and Reflections

The core value of Langmanus lies not only in providing a usable multi-agent framework, but more importantly in demonstrating a universal AI application orchestration philosophy:

1. Graph orchestration makes workflows visual: Complex multi-step tasks become clear and controllable
2. The agent trinity (prompts + model + tools) is the standard paradigm for building each Agent node
3. Prompt-driven extension mechanisms give the system extremely strong flexibility
4. Nested graph design (graphs within graphs) enables truly multi-level agent collaboration

For AI application developers, understanding this architectural philosophy matters more than using the framework itself. Whether using LangGraph or other orchestration tools (like Microsoft's AutoGen, CrewAI, or custom solutions based on workflow engines like Temporal/Prefect), the layered pattern of coordination-planning-supervision-execution is an effective paradigm for building complex multi-agent applications. It's worth noting that this field is evolving rapidly—from early simple chain calls, to today's graph orchestration and dynamic routing, to potentially adaptive topological structures and autonomous agent evolution in the future, there remains enormous exploration space in multi-agent system architecture patterns. If you're exploring implementation strategies for AI Agents, Langmanus's design philosophy is worth considering as a reference starting point.