Skip to content

TrafficSimAgent: A Hierarchical Agent Framework for Autonomous Traffic Simulation with MCP Control

🕒 Published (v1): 2025-12-24 06:48 UTC · Source: Arxiv · link

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

💬 Ask ChatGPT✦ Ask Claude

TL;DR

TrafficSimAgent is a hierarchical, LLM-based multi-agent framework that wraps traffic simulators (MOSS) behind an MCP server, enabling autonomous end-to-end simulation—from map generation to real-time signal optimization—via natural language. A four-module architecture (Task Understanding → Orchestrator → Task Executors → Context Manager) dynamically plans experiment workflows and embeds low-level agent-driven optimization, outperforming domain-specific (ChatSUMO) and general-purpose (OpenManus, MetaGPT) baselines across diverse scenarios.

Problem

Existing traffic simulators (SUMO, MATSim, CityFlow, MOSS) require heavy expert knowledge for data preparation, parameter configuration, and result interpretation. Prior LLM-driven simulation agents (ChatSUMO, SUMO-MCP, Open-TI) address usability but rely on fixed, predefined workflows and lack systematic feedback loops for automatic optimization, limiting them to narrow task sets and preventing iterative improvement.

Method

The framework exposes all simulator utilities as MCP-compatible tools (JSON-RPC via SSE), fully decoupled from the underlying platform. Four modules collaborate:

  1. Task Understanding Module: LLM-powered semantic comprehension parses ambiguous natural language into structured config files, inferring implicit parameters beyond template matching.
  2. Orchestrator Module: Dynamically decomposes tasks into ordered subtasks and routes them to executor agents; supports multi-agent parallel execution and result aggregation.
  3. Task Executor Modules: Three specialized agents—Map Generator (OSM geocoding → Protobuf network), Trip Generator (OD matrix → per-agent demographic profiles and departure curves), Simulation Executor (online/offline modes, selects RL or LLM control strategy).
  4. Context Manager: Global session memory (tool call history, intermediate variables, error logs) enabling per-agent reflection; per-agent memory pools store action-reward history for "scratchpad" trend analysis.

Low-level optimization uses LLM agents embodying individual traffic elements (signals, vehicles) in perception-decision-action cycles. Agents consider multi-neighbor queue pressure, neighboring junction states, and historical strategy outcomes rather than just local phase data (as in LLMLight).

Key Contributions

  • First autonomous traffic simulation agent supporting both scenario generalization and self-optimization within a single framework.
  • MCP-abstracted API layer decoupling simulator functions from agent logic, enabling platform-agnostic invocation.
  • Dynamic task planning via LLM-driven Orchestrator (no fixed workflow templates), demonstrated on scenarios requiring multi-step conditional execution.
  • Two-layer optimization: high-level strategy selection (RL vs. LLM) by Orchestrator + low-level multi-element collaborative real-time control by embodied agents.
  • Synthetic benchmark covering specified and ambiguous instructions across online (auto_drive, TSC, fusion) and offline (medical service selection) tasks.

Results

  • Generalization (Table 2): TrafficSimAgent achieves score 0.715 vs. next-best OpenManus 0.651; only framework completing all four task types (ChatSUMO handles TSC only; GPT-5/Gemini show high AQL or high carbon; MetaGPT/OpenManus trade off TP vs. AQL poorly).
  • TSC Optimization (Table 3): Fusion (TrafficSimAgent) achieves TP=1417, MRR=0.564 vs. LLMLight TP=595, MRR=0.405; TSC variant achieves TP=1337, MRR=0.557 vs. MaxPressure TP=526, MRR=0.360.
  • Model scaling (Table 4): Qwen3-235B reaches SR=78%, MRR=0.611; mistral-7b-v3 at SR=35%, MRR=0.344—clear monotonic scaling trend.
  • Figure 5 shows TrafficSimAgent's throughput advantage over LLMLight widens across simulation steps, attributed to history-aware reward-driven decisions vs. greedy phase analysis.

Limitations

  • Performance and token cost are directly coupled to underlying LLM scale; smaller models degrade substantially.
  • Only evaluated on the MOSS simulator; portability to SUMO/MATSim/CityFlow not demonstrated.
  • No multi-modal input (vision, maps as images) supported yet.
  • Optimization results show increased ACE (carbon emissions) in some fusion scenarios relative to traditional TSC, suggesting tradeoffs not fully resolved.
  • Dataset is entirely synthetic (generated by the framework itself), limiting external validity.

Relevance to Harnesses / Meta-Harnesses

TrafficSimAgent is a domain-specific meta-harness: the Orchestrator functions as a runtime planner that dynamically composes and sequences specialized sub-agents, precisely the meta-harness pattern of routing tasks to capability-matched agents with shared state. The MCP server layer instantiates the "tool registry" design canonical to harness architectures—tools are dynamically registered per-session and invoked via JSON-RPC, demonstrating how MCP can serve as the inter-agent middleware in a scientific simulation harness. The Context Manager's role as a cross-agent shared memory pool with reflection and error-history replay directly parallels memory management patterns in general meta-harnesses (e.g., AutoGen, MetaGPT). The two-level optimization (high-level LLM strategy selection + low-level RL-inspired agent execution) illustrates how harnesses can embed closed-loop feedback, not just task routing.