MaxKB Version
MaxKB v2.10.2-lts（专业版）
Please describe your needs or suggestions for improvements
「表单收集」节点目前只支持静态配置的固定字段列表。当工作流需要操作
员对运行时才能确定数量的列表（N 个条目）进行逐项确认时，没有可用的
方案：
- 对每个条目循环一次表单节点可以实现，但会产生 N 个连续的表单页面。
在我们的派工工作流中，操作员一次需要复核 30–50 个检查项——30–50 连续
弹出的表单队列基本不可用。
- html_rander 可以在一个页面里渲染丰富的自定义 UI（复选框列表、分组
单选、实时预览），但它无法阻塞工作流，也无法把结构化数据返回给下游
节点：
- iframe 仅带
sandbox="allow-scripts" → opaque origin（源为 null）→
无法访问父页面 DOM（已实测：parent.document、
parent.document.forms、对输入框赋值均抛出 SecurityError），
因此也无法代填「表单收集」节点的字段。
sendMessage(str) 发送的是一条聊天消息，会直接结束当前轮次——
用于入口表单没问题，但无法作为工作流中间节点的输入。- 兄弟 iframe 之间的
postMessage 可用，但数据只停留在前端，
服务端的 Python / SQL / LLM 节点永远拿不到。
我们目前的临时方案是自建了一套 iframe 之间的 postMessage 总线，让后续的
html 块在前端消费用户的选择结果——能用，但确认后的数据对 Python/SQL/LLM
节点完全不可见，只能做别扭的前后端混合设计。
Please describe the solution you suggest
方案 A —— 可阻塞的自定义表单节点（首选）
新增一种节点类型：在现有的沙箱 iframe 中渲染作者提供的 HTML，并像
「表单收集」一样暂停工作流，当页面调用注入的全局函数时恢复执行，例如：
// 在沙箱 iframe 内可用，与现有的 sendMessage() 同类
submitForm({ confirmed_ids: ["3", "19"], qty: 2, note: "..." });
- 参数（可 JSON 序列化的对象）成为该节点的输出：
{{自定义表单节点.result.confirmed_ids}} 等。
- 沙箱保持现状（仅
allow-scripts）——桥接方式是注入函数，
不需要 allow-same-origin。
- 加分项：超时/重新提示选项；提交后保留页面为只读展示的开关。
方案 B —— 表单收集节点支持动态字段
允许「表单收集」节点绑定上游变量（{label, value, checked, description} 数组），由原生
表单渲染。灵活性不如方案 A，但能覆盖变长列表确认的场景。
Additional Information
价值说明
任何需要人工复核 LLM 变长输出的工作流（复核 N 个选定结果、批准 N 个检查
项、从 N 个候选中选择）都会撞上这堵墙。方案 A 只需一个与现有
sendMessage 对称的单函数 API（submitForm），就能把 html_rander 从
纯展示层升级为一等输入界面。
环境信息
- MaxKB v2.10.2-lts 专业版，工作流应用
- 实测 iframe 属性：
<iframe srcdoc allow="geolocation" sandbox="allow-scripts">
MaxKB Version
MaxKB v2.10.2-lts（专业版）
Please describe your needs or suggestions for improvements
「表单收集」节点目前只支持静态配置的固定字段列表。当工作流需要操作
员对运行时才能确定数量的列表（N 个条目）进行逐项确认时，没有可用的
方案：
在我们的派工工作流中，操作员一次需要复核 30–50 个检查项——30–50 连续
弹出的表单队列基本不可用。
单选、实时预览），但它无法阻塞工作流，也无法把结构化数据返回给下游
节点：
sandbox="allow-scripts"→ opaque origin（源为 null）→无法访问父页面 DOM（已实测：
parent.document、parent.document.forms、对输入框赋值均抛出 SecurityError），因此也无法代填「表单收集」节点的字段。
sendMessage(str)发送的是一条聊天消息，会直接结束当前轮次——用于入口表单没问题，但无法作为工作流中间节点的输入。
postMessage可用，但数据只停留在前端，服务端的 Python / SQL / LLM 节点永远拿不到。
我们目前的临时方案是自建了一套 iframe 之间的 postMessage 总线，让后续的
html 块在前端消费用户的选择结果——能用，但确认后的数据对 Python/SQL/LLM
节点完全不可见，只能做别扭的前后端混合设计。
Please describe the solution you suggest
方案 A —— 可阻塞的自定义表单节点（首选）
新增一种节点类型：在现有的沙箱 iframe 中渲染作者提供的 HTML，并像
「表单收集」一样暂停工作流，当页面调用注入的全局函数时恢复执行，例如：
{{自定义表单节点.result.confirmed_ids}}等。allow-scripts）——桥接方式是注入函数，不需要
allow-same-origin。方案 B —— 表单收集节点支持动态字段
允许「表单收集」节点绑定上游变量（
{label, value, checked, description}数组），由原生表单渲染。灵活性不如方案 A，但能覆盖变长列表确认的场景。
Additional Information
价值说明
任何需要人工复核 LLM 变长输出的工作流（复核 N 个选定结果、批准 N 个检查
项、从 N 个候选中选择）都会撞上这堵墙。方案 A 只需一个与现有
sendMessage对称的单函数 API（submitForm），就能把 html_rander 从纯展示层升级为一等输入界面。
环境信息
<iframe srcdoc allow="geolocation" sandbox="allow-scripts">