输出格式有问题

[DylanWu92]

[DylanWu92]

输出格式result造成后面的节点根本没有提取出段好的内容。

[asukhodko]

Thanks for the update — I get what you mean now.

What you’re seeing is intentional and currently considered correct behavior on this plugin’s side.

Why the output looks like this

In Dify tool nodes, the most reliable “payload” channel for this kind of tool is essentially a list of strings (chunks). That’s why the plugin returns the chunked content as:

• result: array[string]

And when include_metadata=true, metadata is embedded at the start of each chunk as a <metadata>...</metadata> block. This was done on purpose so the chunk still remains a plain string (which is the common denominator in Dify pipelines), while keeping provenance/debug info attached to the chunk.

What’s going wrong in your flow

You’re not wrong: some downstream nodes don’t “pick up” result well (or don’t make array outputs convenient to use), so it can feel like the next node “can’t extract the chunked content”, even though the data is there.

That’s a Dify workflow interoperability limitation more than a formatting bug in the chunker.

Workarounds (practical options)

Here are the common ways to deal with it:

1. If your goal is Knowledge Base ingestion
   Route the tool output directly into the Knowledge Base / ingestion node (or whatever node expects chunks). Those parts of Dify are aligned with “array of strings” style chunk outputs.

2. If you need to process chunks in later workflow nodes
   Insert a small “adapter” step right after the chunker:

   • Code/Python node: iterate over result, split <metadata>...</metadata> from the chunk text, and output whatever structure your next node expects.
   • Or Template node: in simpler cases, join/slice/reformat the chunk list into a single string (less ideal, but sometimes enough).

3. If metadata-in-text is the part that breaks your downstream logic
   Run the chunker with include_metadata=false so the chunks are clean text only, and keep provenance outside of the chunk text (or reconstruct it via the adapter step).

---

Possible improvement I’m considering (no promises)

That said, I agree the ergonomics could be better for workflow-heavy use cases.

One direction I’m open to exploring is adding two explicit output “modes”:

• KB-friendly output (current):
  result = array[string] (chunks as strings, optionally with embedded metadata)

• Workflow-friendly output (additional):
  also populate json with a structured list like:
  { text: "...", metadata: {...}, start_line, end_line, header_path, ... }

This would make it much easier to consume chunks in downstream nodes that prefer text/json over custom/array outputs. But I want to see more feedback and real workflows before committing to that design.