datawhalechina/hello-agents · error · RuntimeError

LLM调用完全失败: {e2}

Error message

LLM调用完全失败: {e2}

What it means

think() first tries a streaming chat completion; on failure it retries once with stream=False, and only if that also fails does it raise RuntimeError('LLM调用完全失败: ...') wrapping the second exception. Reaching this error means both the streaming and non-streaming attempts against the OpenAI-compatible endpoint failed, so the underlying cause is almost always transport/auth/model configuration rather than streaming support.

Source

Thrown at Co-creation-projects/CC1227871-StockInsightAgent/llm_client.py:57

            print()
            result = "".join(collected)
            return result
        except Exception as e:
            print(f"[ERR] LLM 调用失败: {e}")
            # 尝试非流式重试
            try:
                print("  尝试非流式重试...")
                response = self.client.chat.completions.create(
                    model=self.model, messages=messages,
                    temperature=temperature, stream=False,
                )
                content = response.choices[0].message.content or ""
                clean = content.encode("utf-8", errors="surrogateescape").decode("utf-8", errors="replace")
                print(clean)
                return clean
            except Exception as e2:
                print(f"[ERR] 非流式也失败: {e2}")
                raise RuntimeError(f"LLM调用完全失败: {e2}")

View on GitHub (pinned to 606a07d341)

Solutions

  1. Reproduce with a minimal curl against $LLM_BASE_URL/chat/completions with the same key and model to see the real status code.
  2. Verify LLM_API_KEY is valid and LLM_MODEL_ID exists on that endpoint (many providers need exact model slugs).
  3. Check LLM_BASE_URL formatting (scheme included, correct port, /v1 present if required) and network/proxy reachability.
  4. Increase LLM_TIMEOUT if the failure is a read timeout rather than connection error.

Example fix

# before
LLM_BASE_URL=https://my-proxy.example.com   # missing path

# after
LLM_BASE_URL=https://my-proxy.example.com/v1  # verify with:
# curl -sS -o /dev/null -w '%{http_code}' "$LLM_BASE_URL/chat/completions" \
#   -H "Authorization: Bearer $LLM_API_KEY" -H 'Content-Type: application/json' \
#   -d '{"model":"'$LLM_MODEL_ID'","messages":[{"role":"user","content":"hi"}]}'
Defensive patterns

Strategy: retry

Validate before calling

import os, socket
from urllib.parse import urlparse
u = urlparse(os.getenv('LLM_BASE_URL', ''))
assert u.scheme in ('http', 'https') and u.netloc, 'LLM_BASE_URL malformed'
socket.getaddrinfo(u.hostname, u.port or (443 if u.scheme == 'https' else 80))  # DNS reachable

Try / catch

for attempt in range(3):
    try:
        return client.think(messages)
    except RuntimeError as e:
        if 'LLM调用完全失败' not in str(e) or attempt == 2:
            raise
        time.sleep(2 ** attempt)  # back off, then retry both stream+non-stream path

Prevention

When it happens

Trigger: Wrong LLM_BASE_URL (unreachable host, missing /v1 suffix), invalid LLM_API_KEY (401), model id not served by the endpoint (404/400), network outage, or a proxy/firewall blocking HTTPS — every call raises, the non-streaming retry raises too, and this RuntimeError surfaces.

Common situations: Base URL pointing at a provider that does not expose the OpenAI-compatible path; rotated/revoked API keys; self-hosted model server down; corporate proxy rejecting the request; model name deprecated and removed server-side.

Related errors


AI-assisted analysis of datawhalechina/hello-agents@606a07d341 (2026-08-14). Data as JSON: /api/errors/8301911683fc916e. Report an issue: GitHub.