Refly 的 Vibe workflow 这个想法我觉得很不错。通过 Agent 帮助用户构建工作流，然后工作流中还有单独的子 Agent 来执行更加具体的任务。相比于传统的工作流，听起来似乎单个节点的能力会更强；相比于单 Agent 自己规划并执行任务，将常用流程固定为工作流又可以提升任务的执行可控性以及降低 Token 开销。 先说第一印象，Refly 的官网做得很棒，很精致很有科技感，一看就是一个成熟的产品。但是进到系统内感觉和官网呈现的设计风格略微有点割裂：首页的科技感很强又是暗色主题，但应用内又是那种白色简约扁平的风格（图一）。 正好我手头有一个想法，就是通过工作流获取一些最新的多模态模型信息以及一些社交平台上的最新资讯。这其中的难点在于 AI 如何获取不同平台上的信息。之前我用 Grok 来查询效果还不错，但是我还想聚合一些国内平台的，比如说小红书、抖音这一类的，于是我开始用 Refly 来实现这个工作。 在我提出第一个工作流需求后，Refly 积极地反问我，让我帮他补齐上下文（图二），提出的问题非常明确，确实对于构建工作流有帮助。随后，Refly 就帮我调用工具创建了一个工作流，流程大概是这样的：由于我要求的信息时效性比较强，它会先调用工具去获取当前的时间，然后把当前的时间传递到三个节点中。这三个节点分别会通过 Agent 去获取小红书、抖音、X 上的资讯。获取的方式是通过 Apify 去获取数据（Apify 是一个爬虫平台，里面有一个市场提供了很多主流平台的自动化爬虫）。在 Refly 中，这三个节点并不是简单的执行一个 Apify 工具去获取数据，而是有三个带有不同提示词的 Agent 自己去一步一步调用工具来获取数据。这样相比于固定参数去调用工具，Agent 可以自己根据提示去调用对应的工具，还可以基于查询的结果，不断地去动态调整参数，最终拿到更准确的数据。节点的模型是可以自己选择的，基本上最强的那一批模型 Refly 都提供了（图五）。最后再将三个节点的输出聚合到一起，由一个节点进行整理，然后再输出一个文档。 流程是很清晰，想象是很美好的，但是在开始执行后，问题就暴露出来了。 首先是官方提供的 Auto 模型基本上每一次都失败（图六）。让降临派的运营小姐姐去问了一下官方，发现是已知 bug。于是我先手动更换 DeepSeek 3.1，想着先用一个简单低成本的模型看看能不能完整跑通，结果就是输出速度特别特别慢，而且有一个节点一直卡着，十几分钟都没跑完。我自己想应该是 DeepSeek 的 Token 输出速度太慢了，而且单个节点是作为一个 Agent 去执行，并不是一个工具调用，所以对于模型的能力要求就更高了。 然后我手动更换为 Gemini 2.5 flash，结果也是失败（图七），Gemini 2.5 flash 没法很好地理解 Apify 里的工具。于是我想着干脆直接换成 Gemini 2.5 pro 好了，但是这一次我想让 Agent 来帮我替换，这样我就不用手动一个一个地改模型了。但是这里我提出需求后，Agent 虽然会帮我重新生成工作流，但我点击采纳之后，工作流里的模型依然是 Auto，Agent 的响应里是告诉我已经替换成功了（图八），实际上并没有。这里我觉得不太应该，通过 Agent 来精确的修改工作流中的某一个属性，应该是一个挺普遍的需求。 后续为了检验我这工作流到底能不能跑通，我自己手动将模型替换为了 Claude 4.5 sonnet。这一次发现了一些新问题，一个是节点中的输出有时候似乎格式有问题，导致 UI 上没有正确渲染，全都是文本格式了（图九）。执行的时间特别长，我等了十几分钟都没跑完，查看输出信息发现是调用 Apify 工具花的时间太长了，一次查询就得花 1-2 分钟。 最终任务总共执行了十三分钟，花了九百积分。由于中间有一个子节点没有正确输出结果，导致最终没有生成文档，相当于跑失败了。这时候我就发现了，子节点中使用 Agent 虽然可以提升单个节点任务执行的灵活程度，但是对于下一个节点来说，它的输入就是不准确的了。因为 Agent 会自己规划任务去做很多奇奇怪怪的事情，没有办法非常明确地让一个 Agent 准确地输出某个格式的内容。尤其是在很长的一段任务执行之后，这个输出结果就更加不可控了。在工作流中，某一个节点如果它的输出无法控制，那最终后续的所有节点基本上都是没办法正确执行了。 Refly 的核心设计理念试图融合工作流的确定性与 Agent 的灵活性，但在实际落地中，这两者存在本质冲突。工作流的价值在于将 SOP 固化，要求上下游节点之间有严格的输入输出接口定义，追求的是确定性和复用性。而 Agent 的输出具有随机性和发散性。Refly 在工作流的子节点中过重地依赖 Agent 进行自主规划，导致每个节点都变得不可控。从我自己测试的场景出发，我认为使用 Refly 生成的工作流，还不如我直接使用单个 Agent 去自主调用工具获取信息，最终汇总得到的结果更好。