ZML_LLM JSON提取器
The JSON splitter that makes LLM output useful
- 值1
- 值2
- 值3
- 值4
- 值5
- 值6
- 值7
The name says "LLM," but here's the thing to know first: ZML_JsonExtractor (ZML_LLM JSON提取器) calls no LLM, needs no API key, and doesn't even talk to a model. It's the receiving end of an LLM - the node that takes whatever JSON a language model spat out, digs out the fields you asked for, and hands them to the rest of your workflow as clean outputs. Think of it as a JSON post-processor that happens to live in the LLM neighborhood.
It's from ComfyUI-ZML-Image, zml-w's 160+ node pack, which got a full LLM node family in late 2025 (the pack's LLM nodes now use the openai library for model calls). This extractor is the part that turns their raw output into something usable.
How it works
An LLM answering "give me JSON" almost never returns just JSON - it wraps it in markdown code fences, adds a "Here is your response:" preamble, or narrates around the object. This node handles all of that defensively:
- Strip markdown fences (
json ...). - Find the outermost
{...}or[...]in whatever's left and extract it. - Parse it, then pull the values for up to 7 keys you list.
- Emit each value on its own output socket.
The keys field is a comma-separated list (it even accepts a Chinese comma) - the default is "回复内容,状态" (reply content, status), the two fields the pack's LLM chat nodes return. default_value fills in any key that's missing, so your downstream never sees a crash on a partial response.
The array_mode knob
When a key's value is a list, you choose how it comes out:
- 换行连接 (NewLine) - the list items joined into one string, one per line. Best for feeding a prompt-style multi-line field.
- 文本列表 (List) - each item as its own string in a list, so downstream list nodes iterate per item.
- 原样列表 (JSON) - the whole list re-serialized as one JSON string.
The outputs that matter
值1 through 值7 - seven STRING outputs, and every one of them is a list output (they connect to list-consuming sockets). One key per socket, in the order you wrote them in keys. That's the whole interface: seven wires you populate in the order your LLM contract defines. Because they're lists, pair them with list nodes (the pack ships several) if you're consuming single values.
Installing it
Pack install:
cd ComfyUI/custom_nodes
git clone https://github.com/zml-w/ComfyUI-ZML-Image
restart ComfyUI, or ComfyUI Manager → search "ComfyUI-ZML-Image". The extractor itself is pure Python (the pack's openai dependency is for the LLM call nodes, not this one). No models to download.
Where people get caught
The seven outputs are always lists - if you wire one into a plain STRING socket expecting a single value, it may misbehave or drop to the first item. And the default keys only makes sense if you're feeding it from the pack's own LLM nodes; if you're parsing your own JSON, change keys to match your field names, and set default_value so a missing field degrades gracefully instead of surprising you.
It's one of those nodes that reads as a puzzle until you wire it to an actual LLM output - then it's simply the hinge that makes "ask a model for structured data" work in a graph.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| json_string | STRING | — | |
| keys | STRING | 回复内容,状态 | — |
| array_mode | COMBO | 换行连接 (NewLine) | 3 options: 换行连接 (NewLine), 文本列表 (List), 原样列表 (JSON) |
| default_valueopt | STRING | — |
Outputs (7)
| Name | Type | Description |
|---|---|---|
| 值1 | STRING | — |
| 值2 | STRING | — |
| 值3 | STRING | — |
| 值4 | STRING | — |
| 值5 | STRING | — |
| 值6 | STRING | — |
| 值7 | STRING | — |