dify 当前存在 start 节点其有两个职责 其一是系统变量其二是 user input，后者简单来说就是开发者定义终端用户传值，然后开发者将placeholder （形参）用于构建函数
这么做也好理解从工程来看一个 workflow 就是一个可重用函数 然后将参数交给用户在一开始的时候来赋值，但是从用户角度出发尤其现在 chatUI 是主流的情况下很难理解对话一开始需要填表单，因为他们被教育只需要一个对话框就能开启应用，所以 form 这种形式应该是可以在会话的任何合理时刻可以要求用户通过 form 表单来补充应用需要的信息
现在的 input 做到开始节点 然后开始节点和 webapp 和 service api 耦合，加之trigger 应该是和业务流程无关 应该在业务上级来触发应用 从这个角度来看 workflow input（函数入参）是固定的 然后无论是用户出发还是事件触发都需要将其最终赋值
这种设计看似合理 技术上抽象的很干净，但是从应用构建者的角度思考他们构建一个事件触发的应用往往不是构建业务流程最后配置从事件webhook body 到 input 的规则，而是在构建应用的第一直觉就去寻找 where is trigger
从这个角度出发我们应该有一个更加直接的从触发场景出发的构建应用流程 “Trigger Output as 函数签名”几乎呼之欲出
也就是明确对于聊天类型的应用本质上是 pull ，Pull 模式 (原先的函数调用/Web App)： 主动触发，需要明确提供所有定义的输入参数。Human input (或 API 调用者 input) 是核心。 而对于被动触发，事件发生时自动执行。参数来源于事件数据，理想情况下不应再有额外的 human input (在触发到执行的链条中)。 这两个场景的不同性
希望流程更直接，减少不必要的Star Node映射步骤，允许直接使用Trigger输出。
如果Trigger的输出就是函数的输入，那么Trigger节点自然就成为了流程的起点。画布上的 Trigger Node -> LLM Node -> End Node 这样的流程非常清晰。 变量的来源明确： 后续节点可以直接从连接上来的Trigger节点获取其输出变量，选择变量的交互会更直观。 可视化： 将触发条件和事件源在画布上明确展示出来，增强了流程的可理解性。 多Trigger处理： 如果有多个Trigger，它们可以作为多个并行的起点节点，或者通过某种逻辑（如合并、分支）连接到后续流程，这在画布上更容易表达。 解决了Star节点与Trigger关系的模糊性： 如果Trigger是节点，就不再有“Star节点和Trigger是什么关系”的困惑，因为Trigger节点就是起点。