Skip to main content

πŸ—οΈ System Architecture

This document provides a detailed overview of Wegent's system architecture, component design, and technology stack.


πŸ“‹ Table of Contents​


🌐 Architecture Overview​

Wegent adopts a modern layered architecture design based on Kubernetes-style declarative API and CRD (Custom Resource Definition) design patterns, providing a standardized framework for creating and managing AI agent ecosystems.

System Architecture Diagram​

Architecture Layers​

LayerResponsibilitiesCore Technologies
Management Platform LayerUser interaction, resource management, API servicesNext.js 15, FastAPI, React 19
Data LayerData persistence, cache managementMySQL 9.4, Redis 7
Execution LayerTask scheduling, container orchestration, resource isolationDocker, Python
Agent LayerAI capabilities, code execution, chat processing, external API integrationClaude Code, Agno, Dify

πŸ”§ Core Components​

1. 🌐 Frontend​

Responsibilities:

  • Provide user interface for resource definition and management
  • Implement task creation, monitoring, and result display
  • Provide real-time interaction and status updates

Technology Stack:

  • Framework: Next.js 15 (App Router)
  • UI Library: React 19, Ant Design 5
  • Styling: Tailwind CSS 3
  • State Management: React Hooks
  • Internationalization: i18next
  • Icons: Heroicons, Tabler Icons

Core Features:

  • 🎨 Configuration-driven UI with YAML visualization
  • πŸ”„ Real-time task status updates
  • 🌍 Multi-language support (Chinese/English)
  • πŸ“± Responsive design

Key File Structure:

frontend/
β”œβ”€β”€ app/ # Next.js App Router
β”œβ”€β”€ components/ # React components
β”œβ”€β”€ public/ # Static assets
└── package.json # Dependencies

2. βš™οΈ Backend​

Responsibilities:

  • Implement declarative API for resource CRUD operations
  • Manage user authentication and authorization
  • Coordinate execution layer for task scheduling
  • Provide WebSocket support for real-time chat communication (Socket.IO)

Technology Stack:

  • Framework: FastAPI 0.68+
  • ORM: SQLAlchemy 2.0
  • Database Driver: PyMySQL
  • Authentication: JWT (PyJWT), OAuth (Authlib)
  • Async Support: asyncio, aiohttp
  • Cache: Redis client
  • Real-time Communication: Socket.IO (python-socketio) with Redis adapter

Core Features:

  • πŸš€ High-performance async API
  • πŸ”’ JWT-based authentication
  • πŸ“ Complete CRUD operation support
  • πŸ”„ Real-time status synchronization
  • πŸ›‘οΈ Data encryption (AES)
  • πŸ‘₯ Role-based access control (admin/user)

API Design:

/api/v1/
β”œβ”€β”€ /ghosts # Ghost resource management
β”œβ”€β”€ /models # Model resource management
β”œβ”€β”€ /shells # Shell resource management
β”œβ”€β”€ /bots # Bot resource management
β”œβ”€β”€ /teams # Team resource management
β”œβ”€β”€ /workspaces # Workspace resource management
β”œβ”€β”€ /tasks # Task resource management
└── /admin # Admin operations (user management, public models)

Key Dependencies:

FastAPI >= 0.68.0      # Web framework
SQLAlchemy >= 2.0.28 # ORM
PyJWT >= 2.8.0 # JWT authentication
Redis >= 4.5.0 # Cache
httpx >= 0.19.0 # HTTP client

3. πŸ’― Executor Manager​

Responsibilities:

  • Manage Executor lifecycle
  • Task queue and scheduling
  • Resource allocation and rate limiting
  • Callback handling

Technology Stack:

  • Language: Python
  • Container Management: Docker SDK
  • Networking: Docker bridge network

Core Features:

  • 🎯 Maximum concurrent task control (default: 5)
  • πŸ”§ Dynamic port allocation (10001-10100)
  • 🐳 Docker container orchestration
  • πŸ“Š Task status tracking

Configuration Parameters:

MAX_CONCURRENT_TASKS: 5              # Maximum concurrent tasks
EXECUTOR_PORT_RANGE_MIN: 10001 # Port range start
EXECUTOR_PORT_RANGE_MAX: 10100 # Port range end
NETWORK: wegent-network # Docker network
EXECUTOR_IMAGE: wegent-executor:latest # Executor image

4. πŸš€ Executor​

Responsibilities:

  • Provide isolated sandbox environment
  • Execute agent tasks
  • Manage workspace and code repositories
  • Report execution results

Technology Stack:

  • Container: Docker
  • Runtime: Claude Code, Agno, Dify
  • Version Control: Git

Core Features:

  • πŸ”’ Fully isolated execution environment
  • πŸ’Ό Independent workspace
  • πŸ”„ Automatic cleanup mechanism
  • πŸ“ Real-time log output

Lifecycle:


5. πŸ’Ύ Database (MySQL)​

Responsibilities:

  • Persistent storage of all resource definitions
  • Manage user data and authentication information
  • Record task execution history

Version: MySQL 9.4

Core Table Structure:

wegent_db/
β”œβ”€β”€ ghosts # Ghost definitions
β”œβ”€β”€ models # Model configurations
β”œβ”€β”€ shells # Shell configurations
β”œβ”€β”€ bots # Bot instances
β”œβ”€β”€ teams # Team definitions
β”œβ”€β”€ workspaces # Workspace configurations
β”œβ”€β”€ tasks # Task records
β”œβ”€β”€ users # User information (with role field)
└── public_models # System-wide public models

Data Model Features:

  • Uses SQLAlchemy ORM
  • Supports transactions and relational queries
  • Automatic timestamp management
  • Soft delete support

6. πŸ”΄ Cache (Redis)​

Responsibilities:

  • Task status caching
  • Session management
  • Temporary real-time data storage
  • Task expiration management

Version: Redis 7

Use Cases:

  • πŸ”„ Chat task context caching (2-hour expiration)
  • πŸ’» Code task status caching (2-hour expiration)
  • 🎯 Executor deletion delay control
  • πŸ“Š Real-time status updates

πŸ”„ Data Flow and Communication Patterns​

Task Execution Flow​

Communication Protocols​

Communication TypeProtocolPurpose
Frontend ↔ BackendHTTP/HTTPS, WebSocket (Socket.IO)API calls, real-time chat streaming
Backend ↔ DatabaseMySQL ProtocolData persistence
Backend ↔ RedisRedis ProtocolCache operations, Socket.IO adapter
Backend ↔ Executor ManagerHTTPTask scheduling
Executor Manager ↔ ExecutorDocker APIContainer management
Executor ↔ AgentProcess invocationTask execution

WebSocket Architecture (Socket.IO)​

The chat system uses Socket.IO for bidirectional real-time communication:

Namespace: /chat Path: /socket.io

Client β†’ Server Events:

EventPurpose
chat:sendSend a chat message
chat:cancelCancel ongoing stream
chat:resumeResume stream after reconnect
task:joinJoin a task room
task:leaveLeave a task room
history:syncSync message history

Server β†’ Client Events:

EventPurpose
chat:startAI started generating response
chat:chunkStreaming content chunk
chat:doneAI response completed
chat:errorError occurred
chat:cancelledStream was cancelled
chat:messageNon-streaming message (group chat)
task:createdNew task created
task:statusTask status update

Room-based Message Routing:

  • User Room: user:{user_id} - For personal notifications
  • Task Room: task:{task_id} - For chat streaming and group chat

Redis Adapter: Enables multi-worker support for horizontal scaling


πŸ› οΈ Technology Stack​

Frontend Stack​

{
"framework": "Next.js 15",
"runtime": "React 19",
"language": "TypeScript 5.7",
"ui": [
"Ant Design 5.27",
"Tailwind CSS 3.4",
"Heroicons 2.2"
],
"i18n": "i18next 25.5",
"markdown": "react-markdown",
"devTools": [
"ESLint 9.17",
"Prettier 3.4",
"Husky 9.1"
]
}

Backend Stack​

{
"framework": "FastAPI >= 0.68.0",
"language": "Python 3.10+",
"orm": "SQLAlchemy >= 2.0.28",
"database": "PyMySQL 1.1.0",
"auth": [
"PyJWT >= 2.8.0",
"python-jose 3.3.0",
"passlib 1.7.4"
],
"async": [
"asyncio >= 3.4.3",
"aiohttp >= 3.8.0",
"httpx >= 0.19.0"
],
"cache": "redis >= 4.5.0",
"security": [
"cryptography >= 41.0.5",
"pycryptodome >= 3.20.0"
],
"testing": [
"pytest >= 7.4.0",
"pytest-asyncio >= 0.21.0"
]
}

Infrastructure​

database:
mysql: "9.4"

cache:
redis: "7"

container:
docker: "latest"
docker-compose: "latest"

executor_engines:
- "Claude Code (Anthropic)"
- "Agno"
- "Dify"

🎯 Design Principles​

1. Declarative API Design​

Following Kubernetes CRD design patterns:

  • βœ… Resources defined declaratively in YAML
  • βœ… Clear resource hierarchy
  • βœ… Unified API version management
  • βœ… Separation of status and desired state

Example:

apiVersion: agent.wecode.io/v1
kind: Bot
metadata:
name: developer-bot
namespace: default
spec:
# Desired state
ghostRef:
name: developer-ghost
status:
# Actual state
state: "Available"

2. Separation of Concerns​

  • 🎨 Frontend: Focused on user interaction and presentation
  • βš™οΈ Backend: Focused on business logic and data management
  • πŸš€ Execution Layer: Focused on task scheduling and resource isolation
  • πŸ€– Agent Layer: Focused on AI capability provision

3. Microservices Architecture​

  • πŸ”§ Each component deployed independently
  • πŸ“¦ Containerized packaging
  • πŸ”„ Loose coupling between services
  • πŸ“Š Independent scaling capability

4. Security First​

  • πŸ”’ JWT authentication mechanism
  • πŸ›‘οΈ AES encryption for sensitive data
  • πŸ” Sandbox environment isolation
  • 🚫 Principle of least privilege
  • πŸ‘₯ Role-based access control (admin/user roles)

5. Observability​

  • πŸ“ Structured logging (structlog)
  • πŸ“Š Status tracking and monitoring
  • πŸ” Detailed error information
  • πŸ“ˆ Performance metrics collection

πŸ“ˆ Scalability and Deployment​

Horizontal Scaling​

Frontend Scaling​

# Multi-instance deployment
frontend:
replicas: 3
load_balancer: nginx

Backend Scaling​

# Stateless design, supports multiple instances
backend:
replicas: 5
session: redis

Executor Scaling​

# Dynamic creation and destruction
executor_manager:
max_concurrent_tasks: 20
auto_scaling: true

Vertical Scaling​

Database Optimization​

  • Read-write separation
  • Index optimization
  • Query caching

Redis Optimization​

  • Memory optimization
  • Persistence strategy
  • Cluster mode

Deployment Modes​

1. Single-Machine Deployment (Development/Testing)​

docker-compose up -d

Use Cases:

  • Local development
  • Feature testing
  • Small-scale usage

2. Distributed Deployment (Production)​

architecture:
frontend: "Multi-instance + Nginx load balancing"
backend: "Multi-instance + API gateway"
mysql: "Master-slave replication + read-write separation"
redis: "Redis Cluster"
executor: "Dynamic scaling"

Use Cases:

  • Production environment
  • High concurrency requirements
  • Large-scale teams

3. Cloud-Native Deployment (Kubernetes)​

apiVersion: apps/v1
kind: Deployment
metadata:
name: wegent-backend
spec:
replicas: 3
template:
spec:
containers:
- name: backend
image: wegent-backend:latest

Use Cases:

  • Cloud environments
  • Auto-scaling
  • High availability requirements

Performance Metrics​

MetricTarget ValueDescription
API Response Time< 200msP95 latency
Task Startup Time< 5sFrom creation to execution
Concurrent Tasks5-100Configurable
Database Connection Pool20Default configuration
WebSocket Connections1000+Concurrent online

Monitoring and Alerting​

Key Metrics​

  • πŸ“Š Task success rate
  • ⏱️ Task execution time
  • πŸ’Ύ Database performance
  • πŸ”΄ Redis cache hit rate
  • 🐳 Container resource usage

Log Collection​

import structlog

logger = structlog.get_logger()
logger.info("task.created",
task_id=task.id,
team=task.team_ref.name)


Understanding the architecture is key to mastering Wegent! πŸš€