feat: 将原有的‘ demo_human‘诗歌创作工作流进行修改和补充”

[tanininl]

改动概述：
1.调整了工作流，加入了多个节点以及计数器等工具
2.对每一个节点的config字段中加入了"provider"（因为实际测试时，主程序要求每一个节点的config字段的第一项为string类型，否则会报错），human节点的”provider“默认为”human“

改动原因：
1.原有诗歌创作工作流相对来说难以适应用户的复杂需求：对于诗歌创作而言，客户使用时往往会输入比较宽泛、少量的文字，但又希望诗歌所承载的意境能够符合自己的期待，表达出自己复杂的情感。原有workflow的自调节功能和创作文学性相对不足。
2.（对节点config字段的改动）因为实际测试时，主程序要求每一个节点的config字段的第一项为string类型，否则会报错，无法运行

[zxrys]

Your token has been compromised! Please reset your token immediately!

[tanininl]

I have deleted the leaked token . Please review it again. Thank you for the reminder!

[zxrys]

Thanks for the update on this PR and for expanding the demo_human workflow. I reviewed it, and I have a few concerns before we merge:

1. In yaml_instance/demo_human.yaml, the python nodes are using config.code, but in our current implementation python node config does not support a code field.
   The executor runs code from upstream message content, so Iteration Controller / User Decider won’t behave as intended.
   If you want a Python node to execute specific predefined code, a practical approach is to send that code from an upstream literal node.

2. The loop control logic seems misaligned with loop_counter behavior.
   loop_counter suppresses output until max_iterations is reached (default is 10 if not set), so the current flow may stall or behave differently from the described “score-based” branching.

3. Several branching edges are unconditional (condition not set), so both downstream paths can trigger at the same time.
   This conflicts with the intended “choose one path” logic (e.g., continue iterating vs. go to human review).

4. Some fields appear to be in the wrong place and get ignored (for example, provider under human.config).

5. frontend/package-lock.json changes look unrelated to this workflow change and may add noise/conflicts in review.

Would you mind revising the workflow with the current node schema/runtime semantics in mind? Happy to re-review once updated.