Qorvexus is a maintainable Go agent platform for building an always-on assistant with tools, memory, social channels, self-improvement workflows, and a built-in control panel.

Maintained by FWERKOR Team
Contact: admin@fwerkor.com

Think of it as an agent runtime, not a single hard-coded bot. Models, tools, skills, sessions, background jobs, and social channels are all explicit subsystems.

• model is isolated so new providers or logging shims can be added without touching the core loop.
• tool is first-class and model-visible, so the model decides when to act.
• skill stays compatible with OpenClaw-style SKILL.md workflows.
• session, memory, scheduler, and taskqueue are explicit subsystems instead of hidden prompt behavior.
• socialplugin keeps channels like Telegram, QQ Bot, Discord, and Slack optional, and a generated autoload manifest keeps runtime registration out of the core loop.
• self and audit make self-modification possible without making it invisible.

1. Build the binary:

go build ./cmd/qorvexus

2. Start Qorvexus once to generate config.yaml:

./qorvexus start

3. Stop it after the file appears, then add your model and channel credentials:

models:
  primary:
    provider: openai-compatible
    base_url: https://api.openai.com/v1
    api_key: "your-model-key"
    model: gpt-4.1

social:
  allowed_channels:
    - telegram
    - discord
    - slack
  telegram:
    bot_token: "your-telegram-bot-token"
  discord:
    bot_token: "your-discord-bot-token"
    default_channel_id: "your-channel-id"
  slack:
    bot_token: "your-slack-bot-token"
    default_channel_id: "your-channel-id"

4. Start the full service:

./qorvexus start

start now runs Qorvexus under a lightweight supervisor. That lets the runtime restart cleanly after config or skill changes, and it also enables supervised self-update handoffs when the owner approves a code rebuild.

5. Open the control panel:

http://127.0.0.1:7788

Qorvexus fills in many internal defaults automatically, but model connection settings remain explicit because they are part of the deployment contract. The model value is the provider-facing model ID sent to the OpenAI-compatible endpoint; the map key such as primary is only Qorvexus' local alias.

• License: GPL v3
• Security: SECURITY.md
• Contributing: CONTRIBUTING.md
• Support: SUPPORT.md
• Conduct: CODE_OF_CONDUCT.md

./qorvexus start
./qorvexus daemon
./qorvexus run "Plan my day and execute any necessary research"
./qorvexus run --image https://example.com/screen.png "Describe this screen"
./qorvexus skills
./qorvexus queue

• Use start for the normal supervised service.
• Use daemon only when you intentionally want a single unsupervised runtime process.

Local developer workflows:

make build
make test
make race
make docker-build
make ci

GitHub Actions can publish a release from the Release workflow.

1. Open Actions -> Release -> Run workflow.
2. Enter a tag such as v0.1.0.
3. Optionally set a release title, draft mode, or prerelease mode.

The workflow builds portable release archives for Linux, macOS, and Windows across amd64/arm64 targets, then uploads a checksums.txt file with SHA-256 hashes.

Each portable archive includes the Qorvexus binary, the full source tree, a Go toolchain, Node.js/npm, Playwright, and a Chromium browser cache. Start it with ./run.sh on Linux/macOS or .\run.ps1 on Windows. The launcher sets QORVEXUS_SOURCE_ROOT, QORVEXUS_PLAYWRIGHT_RUNTIME_DIR, PLAYWRIGHT_BROWSERS_PATH, GOROOT, and PATH so runtime self-update builds use the bundled source tree and toolchain.

To publish Docker images from the same workflow, add repository secrets named DOCKERHUB_USERNAME and DOCKERHUB_TOKEN. The workflow always publishes a multi-architecture Linux image named ${DOCKERHUB_USERNAME}/qorvexus for amd64 and arm64 with tags like v0.1.0, 0.1.0, and latest for non-prerelease builds.

Social channels are plugin-based, not core-runtime special cases.

Telegram uses polling by default.

social:
  allowed_channels:
    - telegram
  telegram:
    bot_token: "your-telegram-bot-token"
    mode: polling

Qorvexus will call Telegram getUpdates, ingest messages through the social layer, and send replies back through the Telegram Bot API.

Discord currently ships as a clean outbound plugin baseline.

social:
  allowed_channels:
    - discord
  discord:
    bot_token: "your-discord-bot-token"
    default_channel_id: "your-channel-id"

If a task sends a Discord message without an explicit channel target, Qorvexus will fall back to social.discord.default_channel_id.

QQ Bot ships as a plugin and uses the official AppID + AppSecret credential flow.

social:
  allowed_channels:
    - qqbot
  qqbot:
    app_id: "your-app-id"
    client_secret: "your-client-secret"
    default_target: "qqbot:c2c:USER_OPENID"

Qorvexus accepts the same target shape OpenClaw documents:

• qqbot:c2c:OPENID for private chat
• qqbot:group:GROUP_OPENID for group chat
• qqbot:channel:CHANNEL_ID for guild channel messages

If a task sends a QQ Bot message without an explicit thread_id or recipient, Qorvexus will fall back to social.qqbot.default_target.

Slack currently ships as a clean outbound plugin baseline.

social:
  allowed_channels:
    - slack
  slack:
    bot_token: "your-slack-bot-token"
    default_channel_id: "your-channel-id"

If a task sends a Slack message without an explicit target, Qorvexus will fall back to social.slack.default_channel_id.

curl -X POST http://127.0.0.1:7788/api/social/inbound \
  -H 'Content-Type: application/json' \
  -d '{"channel":"telegram","thread_id":"chat-1","sender_id":"owner","sender_name":"owner","text":"Summarize today and draft replies I should send."}'

The Docker image includes the Go toolchain, Node.js, Playwright, Chromium dependencies, and the source tree under /workspace/qorvexus. This keeps browser automation and supervised self-update builds consistent across hosts.

Run the published image:

mkdir -p docker-data
docker run -d \
  --name qorvexus \
  -p 7788:7788 \
  -v "$(pwd)/docker-data:/data" \
  --restart unless-stopped \
  fwerkor/qorvexus:latest

On first boot the container will generate /data/config.yaml. Edit that file on the host, add your model and channel credentials, then restart the container:

docker restart qorvexus

Open the control panel:

http://127.0.0.1:7788

Upgrade to the latest published image:

docker pull fwerkor/qorvexus:latest
docker stop qorvexus
docker rm qorvexus
docker run -d \
  --name qorvexus \
  -p 7788:7788 \
  -v "$(pwd)/docker-data:/data" \
  --restart unless-stopped \
  fwerkor/qorvexus:latest

Docker Compose example:

services:
  qorvexus:
    image: fwerkor/qorvexus:latest
    container_name: qorvexus
    restart: unless-stopped
    ports:
      - "7788:7788"
    volumes:
      - ./docker-data:/data

For a fixed version, replace latest with a release tag such as v0.1.0.

Build the image locally for development:

docker build -t qorvexus:local .
docker run --rm -p 7788:7788 -v "$(pwd)/docker-data:/data" qorvexus:local

The repository includes:

• CI workflow for tests, race tests, formatting checks, builds, and Docker image builds
• Release workflow for multi-platform binaries on tags or manual dispatch
• a multi-stage Dockerfile
• a small Makefile for common local workflows

cmd/qorvexus           CLI entrypoint
internal/agent         agent loop and tool orchestration
internal/audit         high-impact action logging
internal/cli           bootstrap, commands, runtime wiring
internal/config        config schema and defaults
internal/contextx      context compression
internal/memory        durable note storage
internal/model         provider abstraction and adapters
internal/orchestrator  multi-model discussion
internal/policy        command execution safety rules
internal/scheduler     cron-backed recurring tasks
internal/self          self-improvement backlog and skill management
internal/session       persistent session state
internal/skill         skill discovery and prompt injection
internal/social        envelopes and trust routing
internal/socialplugin  optional social-channel plugins
internal/taskqueue     async work queue and worker
internal/tool          built-in model-visible tools
internal/types         shared protocol types
internal/webui         control panel and HTTP APIs
skills/                workspace skills
docker/                container entrypoint assets

Qorvexus is already usable, but it is still moving toward a stronger product shape:

• richer social plugins
• more model providers
• better long-term memory retrieval
• stronger operational observability
• safer self-improvement workflows

If you want to extend it, the intended path is to add adapters, tools, skills, or plugins without collapsing everything back into one giant runtime file.