Steuermann AI工作流引擎

Prerequisites

• Docker & Docker Compose
• At least one reachable LLM provider endpoint configured for the active profile (for example LM Studio, Ollama, or OpenRouter)

Deployment Profiles

Profiles are the architectural core of Steuermann — the mechanism that makes one codebase serve unlimited deployment scenarios. Each domain deployment is a self-contained YAML overlay that customizes LLM providers, prompts, tools, memory settings, crews, UI branding, and feature flags without touching the runtime. Activate a profile by setting PROFILE_ID in .env; no rebuild needed for config-only changes.

See docs/profile_creation.md for a step-by-step guide.

Quick Start

1. Clone and configure

```bash git clone https://github.com/mediaworkbench/steuermann-ai.git cd steuermann-ai cp .env.example .env

Edit .env — at minimum set POSTGRES_PASSWORD, PROFILE_ID, and the provider endpoint vars used by that profile

poetry install poetry run steuermann setup doctor --format json poetry run steuermann config validate --format json poetry run steuermann config contract-check --format json poetry run steuermann docs check --format json

Linux hosts (bind-mount permissions): set UID/GID in `.env` before first build so container users match your host account.

3. (Optional) Enable authentication

Set these in .env:

AUTH_ENABLED=true
AUTH_USERNAME=admin
AUTH_PASSWORD_HASH='scrypt$...$...'   # see .env.example for generation command
AUTH_SESSION_SECRET=$(python -c "import secrets; print(secrets.token_hex(32))")
CHAT_ACCESS_TOKEN=$(python -c "import secrets; print(secrets.token_hex(32))")

Rebuild and visit <http://localhost:3000/login>:

docker compose up -d --build

4. (Optional) Ingest domain knowledge

```bash

Prepare a document directory (adjust RAG_DATA_PATH in .env)

mkdir -p ./data/rag-data

5. (Optional) Scaffold a new profile

poetry run steuermann profile scaffold --from starter --profile my-profile
poetry run steuermann config validate --profile my-profile --format json

---

Configuration

Configuration follows a three-layer hierarchy: Base → Profile Overlay → Environment Variables.

config/
├── core.yaml              # Base infra only: database, memory vector store, checkpointing
├── features.yaml          # Deployment-global feature flags
├── contracts/             # Config contract schemas (validation)
└── profiles/
    └── starter/           # Default profile (copy to create your own)
        ├── profile.yaml   # Profile metadata (top-level `profile:` key)
        ├── core.yaml      # LLM roles, embeddings, memory, RAG, tokens, ingestion
        ├── features.yaml  # Feature flag overrides
        ├── agents.yaml    # CrewAI crew and agent definitions
        ├── tools.yaml     # Tool registration and routing
        ├── ui.yaml        # Branding and theme
        └── prompts/
            ├── en.yaml    # English system prompts
            └── de.yaml    # German system prompts

Everything except base infra lives in the profile overlay — agents.yaml, tools.yaml, and per-language prompts/ exist only under config/profiles/<profile_id>/, not at the base level.

Activate a profile by setting PROFILE_ID in .env. See docs/configuration.md for the full schema reference.

---

Operational Interface

A Next.js frontend built for operators. It ships a streaming chat interface with image attachment support, a settings panel for runtime configuration, a metrics dashboard with real-time and historical views, a memory management page, an admin-only RAG knowledge explorer for searching the knowledge base by keyword and reviewing retrieved documents, and persistent workspace documents with version history and AI-driven save-back. Branding and theming adapt to the active profile.

Memory Pipeline

Memory is an explicit, first-class part of the execution graph. Dedicated nodes load relevant context before the LLM responds and persist new memories after — no hidden side effects. Memories are ranked by relevance, recency, and user feedback, with co-occurrence linking to surface related context across conversations.

See docs/technical_architecture.md for memory pipeline details.

Tool Runtime & MCP Integration

Tools are discovered from YAML manifests at startup. Each tool can be a LangChain-native Python class or a remote MCP server — the routing pipeline treats both identically. Semantic similarity matching selects the right tools for each query, and the system automatically adapts its calling strategy to match what the active model supports.

See docs/tool_development_guide.md for building custom tools and MCP integrations.