Workflow node reference-Platform For AI(PAI)-阿里云帮助中心

LangStudio provides pre-built workflow nodes for flow control, LLMs, agents, data retrieval, document parsing, speech recognition, and Python scripting.

Flow control

Start

Note

An application flow can have only one Start node.

The Start node marks where execution begins and declares the input parameters for the application flow.

For conversational flows, the system provides two default fields: conversation history and user input. Add custom variables as needed. To accept user-uploaded files, define an input variable with the file type. For details, see File type input and output.
When you run the application flow, configure the input parameters for the current session in the conversation panel.

Conditional branch

This node implements if-else logic for flow control. It evaluates conditions and directs execution to the first matching branch. If no condition is true, the else branch runs. Pair this node with the Variable aggregate node to merge the results from different branches.

Configuration
Input

When you configure branch conditions, note the following:
- Each branch represents an execution path. The last branch is the else branch, which runs when no other condition matches and cannot be edited.
- Each branch can contain multiple conditions, which can be combined using and/or logic.
- Verify the outputs from upstream nodes, the operators (such as =, ≠, is empty, and does not include), and the values to ensure accurate and valid conditions.
Output

This node produces no output.
Usage example

When you connect the Conditional branch node to downstream nodes, each branch has a corresponding connection port. If a branch condition is met, the system runs the downstream nodes on that branch and skips other branches. Use a Variable aggregate node to collect execution results from the active branch.

Variable aggregate

This node merges output results from different branches into unified variables. When a Conditional branch or Intent recognition node runs, only one branch executes. This node lets downstream nodes reference a single aggregated variable regardless of which branch ran, preventing redundant logic.

Configuration
Input

When you configure variable groups, note the following:
- Upstream nodes are typically multiple execution branches generated by a Conditional branch or Intent recognition node.
- Variables within the same group must be of the same type. The first non-empty value becomes the output for that group.
- Because only one upstream branch runs, each group will have at most one non-empty value. The Variable aggregate node extracts this value for use by downstream nodes.
- If each branch has multiple outputs to collect, you can add multiple groups to extract each corresponding output value.
Output

The node output variables depend on the configured groups. If multiple groups exist, the node outputs a key-value pair for each group, where the key is the group name and the value is the first non-empty variable from that group.
Usage example

See the use case for the Conditional branch node.

Loop

The Loop node runs repetitive tasks where each iteration depends on the previous result. The loop continues until an exit condition is met or the maximum iteration count is reached. Inside the Loop node, configure a sub-flow that the system repeatedly runs based on the loop variable.

Configuration
Input
- Loop variables: Pass data between iterations. Their final values remain available to downstream nodes after the loop completes. Configure multiple loop variables whose values can be entered manually or selected from upstream node outputs.
- Loop exit condition: You can configure an exit condition based on the loop variables. The loop terminates when a specified loop variable meets the preset condition.
- Maximum iteration count: Limits the maximum number of loop executions to prevent infinite loops.
Output

The node's output is the value of the loop variables after the final iteration. Loop variables can only be updated by a Variable Assigner node. Without this node, the loop's output will remain identical to its initial input, regardless of the iteration count.
Related nodes

Loop-related nodes can only be used within a loop. Add the following related nodes by clicking the + icon to the right of a node within the loop:
- Break Loop
  
  Exits the loop immediately. This is typically preceded by a Conditional branch node.
- Variable Assigner
  
  Assigns the output of nodes within the loop to the loop variables, advancing the loop's state.

Direct output

The Direct output node configures direct reply content by using an output template. It supports referencing upstream node outputs with the {{node.variable}} syntax and streaming output.

Example: Add a Direct output node before an LLM node to send an initial message to the user, such as "Thinking...", while the main task is being processed.

Batch processing

The Batch processing node processes list data in parallel. It applies the same sub-flow to each list element, which significantly improves efficiency. For iterative tasks where each step depends on the previous one, use the Loop node instead.

Input

Input list: The list of data to be processed. The node sends each element to the sub-flow for execution as an independent item.
Output field: Select an output variable from a node within the sub-flow to serve as the result for each item's task.
Parallel count: Optional. Controls the number of tasks executed simultaneously. The default is 4, with a valid range of 1 to 10.

Output

result: A list containing the output results from all batch tasks, in the same order as the input list. It aggregates the actual output values of the "Output field" specified in the input.

Related nodes

Batch Start

The Batch Start node is the entry point for the batch processing sub-flow. It provides the following output variables for reference by subsequent nodes in the sub-flow:

item: The data item currently being processed, corresponding to an element in the input list.
index: The index of the current data item in the input list (starting from 0).

Batch Break

The Batch Break node is used to prematurely terminate the processing of the current data item when a specific condition is met.

Note: The Batch Break node terminates only the current iteration and does not affect the processing of other data items.

Usage example

Batch document parsing and intelligent processing

Scenario: An enterprise needs to parse multiple document files in batches, call an LLM for content processing on successfully parsed documents, and automatically skip those that fail to parse.

Batch processing node configuration:

Parameter	Value	Description
Input list	`Start / files`	Reference the file list output from the upstream Start node.
Output field	`LLM / output`	Select the output field of the LLM node as the output for the Batch processing node.
Parallel count	`4`	Process 4 files simultaneously.

Sample output:

{
  "result": [
    "This document is the user manual for product XX, which includes product feature introductions, installation steps...",
    "This is a software service procurement contract with a term of 12 months...",
    null,
    "Value-added tax ordinary invoice, dated January 15, 2026..."
  ]
}

Note: A null value in the output indicates that the file failed to be parsed, and the Batch Break node skipped subsequent processing.

Notes

Guaranteed result order: The order of the output list is consistent with the order of the input list.
Sub-flow flexibility: Within the sub-flow, different data items may trigger different execution paths.
Null value handling: If an item's execution flow exits prematurely or its output is empty, the corresponding position in the output list will be null.

End

The End node marks the completion of an application flow and defines its output parameters. An application flow can have only one End node.

Output parameter configuration

The application flow's output can reference the outputs of any upstream node. For example, in the sample below, the 'answer' output of the application flow uses the output of the LLM node, while 'search_results' uses the output of the search node.
Note
- A conversational flow has a default 'Chat' output field, which serves as the conversational output of the application flow.
- An application flow must include Start and End nodes. Only nodes connected between them are executed; isolated nodes are ignored.

AI capabilities

LLM

The LLM node is a core component of an application flow that calls a large language model for natural language tasks such as text generation, question answering, and complex input processing. It provides configuration options to adjust model parameters, manage conversation history, and customize prompts.

Use cases
- Text generation: Generate text content based on topics and keywords.
- Content classification: Automatically classify email types (for example, inquiry, complaint, or spam).
- Text translation: Translate text into a specified language.
- RAG: Answer user questions by combining retrieved knowledge with the model's reasoning.
Configuration
Input
- Model settings: Supports models deployed from ModelGallery, custom-deployed model services, and models from providers such as Dashscope and DeepSeek. For best performance, choose a highly capable model. Configure the following model parameters:
  - Temperature: A value typically between 0 and 1 that controls output randomness. Values closer to 0 produce more deterministic outputs, while values closer to 1 produce more diverse results.
  - Top P: Nucleus sampling threshold. The model samples from the smallest set of tokens whose cumulative probability exceeds the threshold P, influencing the output's diversity.
  - Top K: Limits candidate tokens to the top K most probable ones. This reduces randomness and makes output more focused, constraining creativity more directly than Top P.
  - Presence penalty: Reduces repetition of the same entities or information. Penalizes tokens already in the generated text. Higher values reduce repetition more aggressively.
  - Frequency penalty: Penalizes tokens based on their frequency in the generated text, reducing overly frequent words or phrases. Higher values encourage more lexical diversity.
  - Max tokens: Maximum output length (in tokens) per run. Lower values may truncate output, while higher values allow longer responses.
  - Seed: When specified, the model attempts deterministic sampling. Repeated requests with the same seed and parameters should produce the same result, but complete determinism is not guaranteed. Refer to the system_fingerprint response parameter to monitor for changes.
  - Stop sequences: Up to four sequences that instruct the model to stop generating further output. When the model encounters one of these sequences, it stops generating tokens. The returned text does not include the stop sequence.
- Conversation history: If enabled, the application flow's chat history is automatically inserted into the prompt.
- Input variables: Variables can reference the outputs of all preceding nodes.
- Prompt: A prompt contains the custom content for the System (SYSTEM), User (USER), or Assistant (ASSISTANT). The prompt is a Jinja2 template where you can reference input variables by using double curly braces {{}}.
Output

The node defaults to String output but supports JSON. The JSON type supports custom output variables, and the model generates output based on the variable names.
Use cases
- Build a Q&A application flow for Finance and Healthcare with DeepSeek+RAG Based on LangStudio
- LangStudio & DeepSeek: RAG and Web Search Chatbot Solution

Intent recognition

The Intent recognition node is primarily for flow control. It uses a large language model to analyze user intent and directs execution to the corresponding branch based on the result. It supports multi-intent configuration and conversation history.

Configuration
Input
- User input: Select the user input to be used for intent recognition.
- Multi-intent configuration: Set up intents as needed, ensuring that each intent's description is clear and that there is no semantic overlap between different intents. The last intent defaults to "Other," which is matched when no other intent applies and cannot be edited.
- Model settings: Configure the large language model for intent recognition. For better performance, choose a more capable model, such as qwen-max.
- Conversation history: When enabled, the large language model automatically inserts the application flow's chat history into the prompt during reasoning.
- Additional prompt: This content is appended to the system prompt to help the model perform intent recognition more accurately.
Output

This node produces no output.
Usage example

When connecting the Intent recognition node to downstream nodes, each intent branch has a corresponding connection port on the node. When an intent is recognized, the downstream nodes connected to that branch are executed, while nodes on other branches are skipped. You can then use a Variable aggregate node to collect the execution results from each branch.

Agent

The Agent node enables a large language model (LLM) to plan, select tools, and act autonomously. It supports reasoning strategies and tool-use capabilities. By integrating strategies like FunctionCalling and ReAct, it allows the LLM to autonomously call tools that comply with the Model Context Protocol (MCP) at runtime to achieve multi-step reasoning.

Node parameters

Agent strategy: Select the desired agent reasoning strategy. Currently, FunctionCalling and ReAct strategies are supported.
FunctionCalling

This feature enables interaction between a Large Language Model (LLM) and external tools based on the structured tool call definition (in JSON format) from the OpenAI Chat API. The LLM analyzes a user's natural language instructions to automatically identify the intent, select the appropriate tool, and extract parameters. The system then calls the corresponding tool and returns the result to the model to perform further reasoning and generate the final answer.

Use cases and advantages:
- Structured calls, strong compatibility: Uses structured data to clearly define tool names and call parameters, making it compatible with all models that support tool calling.
- Stable performance: Suitable for tasks with clear objectives and well-defined steps, such as checking the weather, searching for information, or querying data.
ReAct

ReAct (Reasoning + Acting) is a flexible reasoning strategy that uses prompts to guide a model to explicitly generate Thoughts and Actions, which creates a closed loop for multi-step reasoning and tool calls. This strategy typically uses natural language to describe the calling process. It triggers backend tool execution by outputting text such as "Action=xxx, Action Input=xxx" and injects the results back into the model's reasoning chain. This method does not require API-level tool_calls, which makes it suitable for more general models and frameworks.

Use cases and advantages:
- Enhanced reasoning ability: Guides the model to think step-by-step, with each step explicitly expressing the reasoning logic.
- Transparent strategy: Ideal for agent applications that require strong debugging and interpretability.
- No Tool Calling support required: Can be used even with models that do not support structured output.
Model settings: The FunctionCalling strategy requires a model that natively supports tool calling. The ReAct strategy does not have this limitation, but we recommend choosing a model with strong reasoning capabilities.
Conversation history: Enabling conversation history provides the agent with contextual memory. The system automatically includes past conversation messages in the prompt, allowing the agent to understand and reference previous parts of the conversation. For example, an agent with conversation history enabled can resolve pronouns (such as "he" or "it") without requiring the user to repeat information.
Task planning: When enabled, the system automatically adds the built-in write_todos tool to the agent's available tools. For complex user questions, the agent automatically calls the write_todos tool to plan the task and execute it step-by-step, dynamically updating the plan based on the latest information.
MCP tools & tools: Supports configuring both MCP and non-MCP tools. For more information, see Configure tools for an Agent.
Prompt configuration
- Input Variables: When you want to reference a variable from an upstream node of an application flow in a prompt, you must define a corresponding input variable in the current node and set its value as a reference to the upstream node's variable. Then, in the Prompt section below, you can use Jinja2 template syntax, which is denoted by double curly braces ({{}}), to reference these defined input variables and enable dynamic data passing.
- System prompt: Used to specify the agent's task objectives and context, providing the model with the necessary background to guide its response generation. This is optional for the ReAct strategy.
- User prompt: Receives the user's input or query, which serves as the basis for the model's response generation.
Loop count: Sets the maximum number of execution cycles for the agent, ranging from 1 to 99. The agent repeats the task to generate a response until one of the following conditions is met:
- The LLM determines that it has gathered enough information by calling tools to generate a complete result.
- The set maximum loop count is reached.
Setting a reasonable loop count helps balance response completeness with execution efficiency. If Task planning is enabled, we recommend using the default maximum loop count to ensure the model can fully execute all steps as planned.
Output variables:
- intermediate_steps: A string containing the intermediate steps of the agent's execution.
- text: A string containing the final output of the agent.

Traces and logs

After clicking Run in the upper-right corner of the application flow page, you can view the trace or log below the run result in the dialog box that appears.

View intermediate output: Click the run status icon in the upper-right corner of the Agent node in the workflow. In the drawer below, find intermediate_steps in the Output to view the agent's reasoning process.
View trace: View the trace information of the current run to understand the agent's input and output for each model request (including tool calls and request parameters), token costs, and time consumption.
View log: If an application flow encounters an error, you can view the current run log to get more details about the node execution process.

Additionally, you can click the icon to the right of the Run button in the upper-right corner of the application flow page to view the Run History. Select a specific run record to view its trace or log.

Document parsing

Supports using the system's built-in intelligent document parser and the document parsing services of AI Search Open Platform.

Built-in parser: Extracts structured content and metadata from documents, supporting various mainstream document formats, including PDF, DOCX, PPTX, TXT, HTML, CSV, XLSX, XLS, JSONL, and MD.
AI Search Open Platform: Achieves high-precision structured document parsing, supporting the extraction of logical hierarchy information such as titles and paragraphs, as well as content like text, tables, and images. This improves the effectiveness and accuracy of document extraction. You need to first configure an AI Search Open Platform model service connection. Supported file formats include PDF, DOCX, PPTX, TXT, and HTML.

This tool supports RAG, summarization, and question answering scenarios. The configuration interface is as follows:

Document file: The document file to parse. Select a file-type field from an upstream node.
Model settings: (Optional) Select an AI Search Open Platform model service connection that has been created on LangStudio. If not configured, the system uses the built-in basic parsing method by default.
Output:
- file_id: The unique identifier of the input file.
- content: The parsed structured text content, including hierarchical information such as titles and paragraphs.
- status: The parsing status, which can be SUCCESS or FAIL.
- metadata: The document's metadata and parsing details.
  - file_name: The name of the file.
  - file_type: The type of the file.
  - source_uri: The original URI of the file.
  - download_url: The downloadable URL of the file.
  - analysis_method: The parsing method used. "opensearch" indicates structured parsing using AI Search Open Platform, while "builtin" indicates the use of the built-in basic parsing method.

Downstream usage example: In downstream nodes, reference the result fields of the document parsing node as needed. To use the document parsing results in an LLM node, you can include the parsed content in the user prompt as shown below:

Speech recognition

Use the Speech recognition node to convert audio or video files into text. It supports multiple audio formats and language recognition.

Input

Model settings: Configure the speech recognition model. The speech recognition service provided by Alibaba Cloud Model Studio is currently supported. We recommend using paraformer-v2 for better recognition performance and multilingual support.
Audio/video file: Select the audio or video file to be recognized. For supported formats, see File type input and output.
Recognition Language: Specifies the language for audio recognition. The supported languages are Chinese, English, Japanese, Cantonese, Korean, German, French, Russian, or automatic detection. Note: This feature is supported only by the paraformer-v2 model. Other models use automatic language detection by default.

Output

file_id: The unique identifier of the input file.
status: The recognition status. Possible values are SUCCESS or FAIL.
content: The transcribed text content.
segments: A list of sentence fragment information, including timestamps, text fragments, and other details.
metadata: The metadata of the file, including:
- file_name: The name of the file.
- file_type: The type of the file.
- source_uri: The URI of the file.
- download_url: The download URL of the file.

Data retrieval

To configure the following nodes, see Data retrieval node:

Knowledge base retrieval
Alibaba Cloud IQS - web search
SerpAPI - generic search
HTTP request

Data processing

Python development (Python)

Application flows support nodes with custom Python code for complex data processing. These nodes support streaming input and output. The configuration page is as follows:

Simply fill in the Python code. Inputs and outputs are automatically parsed from the code. Note the following:

The entry function must be decorated with @tool to be loaded as a node.

Note
To enable streaming input for a Python node, you must configure @tool(properties={"streaming_pass_through": True}). Otherwise, inputs to the Python node, such as from an LLM, will be complete output text instead of a stream.
The function supports the following input/output types: int, float, bool, str, dict, TypedDict, dataclass (output only), list, and File.
The parameters of the entry function are dynamically parsed as the node's inputs. The output is placed in an output dictionary and can be referenced by other nodes.

Important
The automatic parsing of input and output parameters for a Python node depends on the runtime. If the runtime is not launched, you cannot configure the node's input and output information.
If your Python code requires dependencies, select Install Dependencies in the upper-right corner of the canvas and enter the required packages. The requirements.txt file is saved with the application flow. Dependencies are installed when you launch the runtime or deploy the service.

Use case 1: Enter the following code in the code area. The code is mapped to the node's inputs and outputs:

from langstudio.core import tool
from dataclasses import dataclass

@dataclass
class Result:
    output1: str
    output2: int

@tool
def invoke(foo: str, bar: int) -> Result:    
    return Result(
        output1="hello" + foo,
        output2=bar + 10
    )

Use case 2: Streaming input and output. Use a Python node to trim a text stream from an LLM or agent node that includes thought processes. By discarding the content within the <think>\n\n</think> section, you can get a final text stream of the result. The following is an example:

import re
from typing import Iterator
from langstudio.core import tool

@tool(properties={"streaming_pass_through": True})
def strip_think(
    stream: Iterator[str],
) -> Iterator[str]:  # The input is a streaming string iterator, and the output is a filtered streaming string iterator.
    # Match the <think>\n...\n</think> structure and capture the text after the closing tag.
    pattern = re.compile(r"<think>\n[\s\S]*\n</think>(.*)")
    in_thinking = True  # Flag to indicate if the current position is inside a <think> block.
    think_buf = ""      # Buffer to store unprocessed content.

    for chunk in stream:
        if in_thinking:
            think_buf += chunk
            m = pattern.search(think_buf)  # Check if the buffer contains a complete thought block.
            if m:
                in_thinking = False
                result_part = m.groups()[0]
                if result_part:
                    yield result_part  # If the result text exists, yield it immediately.
        else:
            yield chunk  # After exiting the thought block, directly yield all subsequent chunks.

Template transformation

The Template transformation tool uses Jinja2 template syntax to enable flexible text formatting and data transformation.

Input

The transformation mode supports Jinja2 mode and Node reference mode.

Jinja2 mode: Uses the full Jinja2 template syntax to customize the output format. This mode is suitable for complex structured output, conditional logic, and loop rendering.
- Template variables: Define the variables used in the template.
  
  Important
  Variable names cannot be Python built-in method names, such as items, keys, or values. Use specific field names, such as item_list or product_list.
- Template content: A template string written in Jinja2 syntax. It supports the full syntax, including variable substitution {{ variable }}, loops {% for %}, conditional statements {% if %}, and filters {{ value | filter }}.
  
  Important
  All variables referenced in the template must be defined in the variable list. Otherwise, an error will occur.
Node reference mode: Directly references the output of upstream nodes and automatically concatenates it into a string. This mode is suitable for simple text combination scenarios.
- Template content: Select the output fields of upstream nodes. The system automatically concatenates them in order.

Output

output: The text result after the template is rendered. Note: The length of both the input and output template content is limited to 100,000 characters. Any content exceeding this limit will be truncated.

Usage examples

Example 1: Generate an order confirmation email

Variable configuration:

Variable name	Variable value
customer_name	`"John Doe"`
order_id	`"ORD-2025-001"`
products	`[{"name": "Laptop", "price": 8999}, {"name": "Wireless Mouse", "price": 199}]`
total	`9198`

Template content:

Dear {{ customer_name }}:

Your order {{ order_id }} has been confirmed. The details are as follows:

{% for product in products %}
- {{ product.name }}: ¥{{ product.price }}
{% endfor %}

Total: ¥{{ total }}

Thank you for your purchase!

Output result:

Dear John Doe:

Your order ORD-2025-001 has been confirmed. The details are as follows:

- Laptop: ¥8999
- Wireless Mouse: ¥199

Total: ¥9198

Thank you for your purchase!

Example 2: Format knowledge base retrieval results

Variable configuration:

Variable name	Variable value
chunks	`[{"title": "Product Introduction", "content": "This is a detailed introduction to the product...", "score": 0.95}]`

Template content:

{% for chunk in chunks %}
### Relevance: {{ "%.2f" % chunk.score }}
#### {{ chunk.title }}
{{ chunk.content }}
---
{% endfor %}

Output result:

### Relevance: 0.95
#### Product Introduction
This is a detailed introduction to the product...
---

List operations

The List operations tool lets you perform flexible filtering and sorting on various types of list data for fine-grained data processing and selection.

Input

Input list: The list data to be processed. It supports any subtype, such as strings, numbers, booleans, file objects, and dictionaries.

Operations: A sequence of chained operations that are executed in order. It supports two types of operations: filtering and sorting.

Filter operation (filter): The filter operation dynamically provides different filtering methods based on the type of the input list. Note: All filter operations are case-sensitive.

Filter key	Description	Scope
Index	Filters based on the element's position in the list.	Applies to all list types.
Element value	Filters based on the value of the element itself.	Applies to all list types.
Custom attribute	Filters based on a custom attribute.	Applies only to lists of dictionaries.
File attribute	Filters based on a file's attributes.	Applies only to lists of files. Available attributes: `file_id`: The file ID. `file_name`: The file name. `file_type`: The file's MIME type. `source_uri`: The file's URI. `download_url`: The file's download URL. `category`: The file category. Valid values: `document`, `image`, `audio`, and `video`. `extension`: The file extension, such as `.jpg`.

Sort operation (sort): The sort operation provides different sorting methods based on the type of the input list.

Sort key	Description	Scope
Element value	Sorts based on the value of the element itself.	Applies only to lists of strings, numbers, or booleans.
Custom attribute	Sorts based on a custom attribute.	Applies only to lists of dictionaries.
File attribute	Sorts based on a file's attributes.	Applies only to lists of files. The available attributes are the same as for the filter operation.

Output

result: The processed list result.
first_item: The first element of the result list. If the list is empty, the value is None.
last_item: The last element of the result list. If the list is empty, the value is None.

Usage examples

Example 1: File classification - Filter for image files, sort by file name length, and take the top 3

Scenario: A user uploads a mixed list of various file types. You need to filter for image files, sort them by file name length, and keep only the top 3 for subsequent image recognition processing.

Operation configuration:

Operation 1 - Filter (by file category):
  Filter key: item.category
  Filter operator: equals
  Filter value: image

Operation 2 - Sort (by file name length):
  Sort key: item.file_name
  Sort direction: asc

Operation 3 - Filter (take top 3):
  Filter key: index
  Filter operator: less than
  Filter value: 3

Example 2: Data analysis - Filter for high-scoring users and get the top 5

Scenario: From a list of user ratings, filter for users with a score of 80 or higher, sort them by score in descending order, and take the top 5.

Input list:

[
  {"name": "Zhang San", "score": 95, "department": "Tech Dept"},
  {"name": "Li Si", "score": 72, "department": "Marketing Dept"},
  {"name": "Wang Wu", "score": 88, "department": "Tech Dept"},
  {"name": "Zhao Liu", "score": 91, "department": "Product Dept"},
  {"name": "Qian Qi", "score": 65, "department": "Marketing Dept"},
  {"name": "Sun Ba", "score": 98, "department": "Tech Dept"}
]

Operation configuration:

Operation 1 - Filter (high-scoring users):
  Filter key: item.score
  Filter operator: greater than or equal to
  Filter value: 80

Operation 2 - Sort (by score descending):
  Sort key: item.score
  Sort direction: desc

Operation 3 - Filter (take top 5):
  Filter key: index
  Filter operator: less than
  Filter value: 5

Output result:

[
  {"name": "Sun Ba", "score": 98, "department": "Tech Dept"},
  {"name": "Zhang San", "score": 95, "department": "Tech Dept"},
  {"name": "Zhao Liu", "score": 91, "department": "Product Dept"},
  {"name": "Wang Wu", "score": 88, "department": "Tech Dept"}
]

Notes:

If the tool's input references a list type output variable that is customized in a Python node, define a clear element type for the list in the Python node, such as list[str]. This ensures more accurate operator matching in the List operations node.