What causes "生成旅行计划失败: {str(e)}" in datawhalechina/hello-agents?

Read the traceback printed by the route (traceback.print_exc()) — it pinpoints the layer (LLM, parsing, or tool)

datawhalechina/hello-agents · error · HTTPException

生成旅行计划失败: {str(e)}

Error message

生成旅行计划失败: {str(e)}

What it means

HTTPException(500) raised by POST /trip/plan (chapter13 trip routes) when the trip-planner agent throws anywhere in plan generation — LLM call failure, JSON parse exhaustion, tool errors. The route prints a full traceback server-side, so the stack in the console is the debugging entry point.

Source

Thrown at code/chapter13/helloagents-trip-planner/backend/app/api/routes/trip.py:58

        agent = get_trip_planner_agent()

        # 生成旅行计划
        print("🚀 开始生成旅行计划...")
        trip_plan = agent.plan_trip(request)

        print("✅ 旅行计划生成成功,准备返回响应\n")

        return TripPlanResponse(
            success=True,
            message="旅行计划生成成功",
            data=trip_plan
        )

    except Exception as e:
        print(f"❌ 生成旅行计划失败: {str(e)}")
        import traceback
        traceback.print_exc()
        raise HTTPException(
            status_code=500,
            detail=f"生成旅行计划失败: {str(e)}"
        )


@router.get(
    "/health",
    summary="健康检查",
    description="检查旅行规划服务是否正常"
)
async def health_check():
    """健康检查"""
    try:
        # 检查Agent是否可用
        agent = get_trip_planner_agent()
        
        return {
            "status": "healthy",

View on GitHub (pinned to 606a07d341)

Solutions

Read the traceback printed by the route (traceback.print_exc()) — it pinpoints the layer (LLM, parsing, or tool)
Verify LLM_API_KEY/OPENAI_API_KEY and AMAP_API_KEY are configured in backend/.env
Retry with simpler/smaller request parameters (fewer days, well-known city) to isolate payload-dependent failures
Check provider status and quota if the failure is at the LLM call

Example fix

# before
r = requests.post(f'{BASE}/trip/plan', json=body)
r.raise_for_status()  # opaque 500

# after
r = requests.post(f'{BASE}/trip/plan', json=body, timeout=300)
if r.status_code == 500:
    print('Agent failure, server detail:', r.json().get('detail'))
    r = requests.post(f'{BASE}/trip/plan', json=smaller_body, timeout=300)

Defensive patterns

Strategy: retry

Validate before calling

def valid_trip_request(b: dict) -> bool:
    return (
        isinstance(b.get('destination'), str) and bool(b['destination'].strip())
        and isinstance(b.get('days'), int) and 1 <= b['days'] <= 10
    )
assert valid_trip_request(body)

Try / catch

for attempt in range(2):
    r = requests.post(f'{BASE}/trip/plan', json=body, timeout=300)
    if r.status_code == 500 and attempt == 0:
        body['days'] = min(body['days'], 3)  # shrink workload and retry once
        continue
    r.raise_for_status()

Prevention

Set long client timeouts; agent runs are slow and timeouts masquerade as failures
Keep requests small (fewer days/days with fewer POIs) to reduce failure surface
Correlate client errors with the server traceback via a request id so the masked detail is recoverable

When it happens

Trigger: LLM_API_KEY/OPENAI_API_KEY unset so the agent's LLM client fails mid-plan; agent's response parser failing (see trip_planner_agent.py:356) and its fallback also erroring; Amap tool failures propagating up through the agent loop; malformed request payload fields.

Common situations: Backend started without .env keys; provider outage or rate limit during a long multi-turn agent run; prompt/model regression producing unparseable plans on certain cities.

Related errors

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