What causes "LLM_API_KEY 未配置" in 666ghj/MiroFish?

Set LLM_API_KEY in the backend environment (.env / docker-compose) and restart.

666ghj/MiroFish · critical · ValueError

LLM_API_KEY 未配置

Error message

LLM_API_KEY 未配置

What it means

Raised in SimulationConfigGenerator.__init__: identical bootstrap check to the profile generator — the optional api_key argument falls back to Config.LLM_API_KEY, and if neither is present the constructor raises ValueError('LLM_API_KEY 未配置') before building the OpenAI client used to generate simulation configs.

Source

Thrown at backend/app/services/simulation_config_generator.py:237

    # 各步骤的上下文截断长度（字符数）
    TIME_CONFIG_CONTEXT_LENGTH = 10000   # 时间配置
    EVENT_CONFIG_CONTEXT_LENGTH = 8000   # 事件配置
    ENTITY_SUMMARY_LENGTH = 300          # 实体摘要
    AGENT_SUMMARY_LENGTH = 300           # Agent配置中的实体摘要
    ENTITIES_PER_TYPE_DISPLAY = 20       # 每类实体显示数量
    
    def __init__(
        self,
        api_key: Optional[str] = None,
        base_url: Optional[str] = None,
        model_name: Optional[str] = None
    ):
        self.api_key = api_key or Config.LLM_API_KEY
        self.base_url = base_url or Config.LLM_BASE_URL
        self.model_name = model_name or Config.LLM_MODEL_NAME
        
        if not self.api_key:
            raise ValueError("LLM_API_KEY 未配置")
        
        self.client = OpenAI(
            api_key=self.api_key,
            base_url=self.base_url
        )
    
    def generate_config(
        self,
        simulation_id: str,
        project_id: str,
        graph_id: str,
        simulation_requirement: str,
        document_text: str,
        entities: List[EntityNode],
        enable_twitter: bool = True,
        enable_reddit: bool = True,
        progress_callback: Optional[Callable[[int, int, str], None]] = None,
    ) -> SimulationParameters:

View on GitHub (pinned to b5b53acc57)

Solutions

Set LLM_API_KEY in the backend environment (.env / docker-compose) and restart.
Or pass api_key explicitly to the SimulationConfigGenerator constructor / config-generation entrypoint.
Double-check Config loading order — the .env must be loaded before Config class attributes are evaluated.
Add a startup env check so misconfiguration is caught at boot, not mid-simulation.

Example fix

# before
gen = SimulationConfigGenerator()  # ValueError
# after
gen = SimulationConfigGenerator(api_key=os.environ['LLM_API_KEY'])

Defensive patterns

Strategy: validation

Validate before calling

assert Config.LLM_API_KEY, 'LLM_API_KEY missing: set it in .env before starting the backend'

Try / catch

try:
    gen = SimulationConfigGenerator()
except ValueError as e:
    if 'LLM_API_KEY' in str(e):
        raise SystemExit('Configure LLM_API_KEY in the environment and restart') from e
    raise

Prevention

Validate all LLM env vars in one startup check shared by every generator service.
Ensure .env is loaded before Config is imported (check import order in the app entrypoint).
Surface configuration status on a /health or /config endpoint for quick diagnosis.

When it happens

Trigger: Constructing SimulationConfigGenerator (typically inside SimulationManager.prepare_simulation's config-generation stage) with LLM_API_KEY unset/empty in the environment and no explicit api_key argument.

Common situations: Same env issues as error 28: fresh deployment, .env not loaded in the container, variable typo, or secrets not ported to a new environment. Often surfaces only when a user first triggers /prepare with LLM config generation enabled.

Related errors

AI-assisted analysis of 666ghj/MiroFish@b5b53acc57 (2026-08-14). Data as JSON: /api/errors/199eb7a383edf87f. Report an issue: GitHub.