Lingxi Multi-Agent Software Engineering Framework

Lingxi provides different graph architectures depending on the required complexity:

• Supervisor Graph (src/agent/supervisor_graph_demo.py): A linear workflow following the sequence: input_handler $\rightarrow$ supervisor $\rightarrow$ problem_decoder $\rightarrow$ solution_mapper $\rightarrow$ problem_solver. It allows for optional human feedback after each step.
• Hierarchy Graph (src/agent/hierarchy_graph_demo.py): An advanced architecture that wraps the Supervisor Graph as a subgraph. It adds a Multi-Agent Manager and a Reviewer to enable iterative fix validation.

System prompts can be implemented in several ways when defining agents:

• prompt kwarg: In create_react_agent, passing a str converts it to a SystemMessage prepended to state["messages"].
• SystemMessage: Manually prepending a SystemMessage to the message list.
• Callable: A function that takes the full graph state as input and returns the output for the LLM.
• Runnable: A LangChain runnable that takes the full graph state as input and returns the output for the LLM.

When you create a ReACT agent using create_react_agent, LangGraph automatically generates a subgraph. This subgraph contains specific nodes that manage the agent's reasoning loop:

• __start__: The entry point of the subgraph.
• agent: The node where the LLM processes the current state and decides on an action.
• tools: The node that executes the tool requested by the agent.
• __end__: The exit point of the subgraph.

The agent uses conditional edges (often represented as dashed lines in diagrams) to decide whether to transition to the tools node (if a tool call is required) or to __end__ (if a final answer is reached).

Lingxi provides two primary workflow graphs:

1. Supervisor Graph

Defined by issue_resolve_graph. It follows a linear-to-routed workflow:

• input_handler_node $\rightarrow$ supervisor_node $\rightarrow$ problem_decoder $\rightarrow$ solution_mapper $\rightarrow$ problem_solver.
• Supports human feedback after each node execution.

2. Hierarchy Graph

Defined by hierarchy_graph. It implements a more complex multi-agent coordination pattern:

• mam_node (Multi-Agent Manager) coordinates an issue_resolve_graph (the Supervisor Graph) and a reviewer_node.
• This structure allows for iterative review and feedback loops between the resolver and the reviewer.

In LangGraph, agents interact through a shared state.

• MessagesState: A specialized state used by ReACT agents. It is a dictionary containing a messages key, which holds the conversation history as a list of BaseMessage subclasses (HumanMessage, AIMessage, ToolMessage, etc.).
• State Updates: The graph automatically updates the messages list. Custom variables in a custom state can be updated by returning a Command(update={"key": "value"}) from a node.
• Critical Constraint: For ReACT agents, the sequence of messages is strict. An AIMessage (the agent's decision to use a tool) must be followed by a ToolMessage (the tool's output). Removing or altering this sequence will break the workflow.

Lingxi provides two main graph implementations for issue resolution:

1. Supervisor Graph

Defined in src/agent/supervisor_graph_demo.py via the issue_resolve_graph variable. It follows this node sequence:

1. input_handler_node: Sets up environment from GitHub URL.
2. supervisor_node: Executes the supervisor agent.
3. problem_decoder: Executes the decoder agent.
4. solution_mapper: Executes the mapper agent.
5. problem_solver: Executes the solver agent.

2. Hierarchy Graph

Defined in src/agent/hierarchy_graph_demo.py via the hierarchy_graph variable. It adds a coordination layer:

1. mam_node: Executes the Multi-Agent Manager.
2. issue_resolve_graph: Executes the standard Supervisor Graph workflow.
3. reviewer_node: Executes the reviewer agent to verify the fix.

System prompts can be provided to agents in several ways:

1. prompt kwarg: In create_react_agent(..., prompt="..."), the string is converted to a SystemMessage and prepended to the state's message list.
2. SystemMessage: Manually adding a SystemMessage to the beginning of the messages list in the state.
3. Callable: A function that accepts the full graph state and returns the output to be passed to the LLM.
4. Runnable: A LangChain runnable that processes the full graph state for the LLM.

The input format depends on the agent type:

1. Tool-less Agents (Direct LLM): Accept flexible inputs like str, List[str], or List[BaseMessage].
2. ReACT Agents: Expect a MessagesState object. This is a dictionary (or AnnotatedDict) containing a messages key, which is a list of BaseMessage subclasses (e.g., SystemMessage, HumanMessage, AIMessage).

Important Constraints:

• The messages list in MessagesState follows a strict structure for ReACT agents. If an agent uses a tool, an AIMessage (the agent's decision) must be followed by a ToolMessage (the tool's output). Removing messages from this sequence will break the workflow.
• Custom variables can be added to the state and updated from nodes using the Command class: Command(update={"custom_var": "value"}).

To start the local LangGraph Studio instance and access the UI, use one of the following commands depending on your installation method:

If installed via pip:

langgraph dev --no-reload

If installed via uv:

uv run --env-file .env langgraph dev --no-reload

# Using pip installation
langgraph dev --no-reload

# Using uv
uv run --env-file .env langgraph dev --no-reload