Qwen Code Architecture Overview

This document provides a high-level overview of Qwen Code’s architecture.

Core components

Qwen Code is primarily composed of two main packages, along with a suite of tools that can be used by the system in the course of handling command-line input:

1. CLI package (packages/cli):

   • Purpose: This contains the user-facing portion of Qwen Code, such as handling the initial user input, presenting the final output, and managing the overall user experience.
   • Key functions contained in the package:
     • Input processing
     • History management
     • Display rendering
     • Theme and UI customization
     • CLI configuration settings

2. Core package (packages/core):

   • Purpose: This acts as the backend for Qwen Code. It receives requests sent from packages/cli, orchestrates interactions with the configured model API, and manages the execution of available tools.
   • Key functions contained in the package:
     • API client for communicating with the Google Gemini API
     • Prompt construction and management
     • Tool registration and execution logic
     • State management for conversations or sessions
     • Server-side configuration

3. Tools (packages/core/src/tools/):

   • Purpose: These are individual modules that extend the capabilities of the Gemini model, allowing it to interact with the local environment (e.g., file system, shell commands, web fetching).
   • Interaction: packages/core invokes these tools based on requests from the Gemini model.

Interaction Flow

A typical interaction with Qwen Code follows this flow:

1. User input: The user types a prompt or command into the terminal, which is managed by packages/cli.
2. Request to core: packages/cli sends the user’s input to packages/core.
3. Request processed: The core package:
   • Constructs an appropriate prompt for the configured model API, possibly including conversation history and available tool definitions.
   • Sends the prompt to the model API.
4. Model API response: The model API processes the prompt and returns a response. This response might be a direct answer or a request to use one of the available tools.
5. Tool execution (if applicable):
   • When the model API requests a tool, the core package prepares to execute it.
   • If the requested tool can modify the file system or execute shell commands, the user is first given details of the tool and its arguments, and the user must approve the execution.
   • Read-only operations, such as reading files, might not require explicit user confirmation to proceed.
   • Once confirmed, or if confirmation is not required, the core package executes the relevant action within the relevant tool, and the result is sent back to the model API by the core package.
   • The model API processes the tool result and generates a final response.
6. Response to CLI: The core package sends the final response back to the CLI package.
7. Display to user: The CLI package formats and displays the response to the user in the terminal.

Key Design Principles

• Modularity: Separating the CLI (frontend) from the Core (backend) allows for independent development and potential future extensions (e.g., different frontends for the same backend).
• Extensibility: The tool system is designed to be extensible, allowing new capabilities to be added.
• User experience: The CLI focuses on providing a rich and interactive terminal experience.