OpenAI发布了AgentKit,一个可视化的工作流构建器。
这个其实不稀奇,毕竟扣子和dify都已经做了。

但LangChain创始人Chase回应了他们为啥不做托拉拽的智能体工作流。
Chase的很多道理我觉得挺对的。
在第一天,就有很多人建议LangChain做托拉拽,但一直没有这么做。
首先,工作流(workflows)和智能体(agents)不是一回事。
workflows,追求的是可观测性,代价是牺牲了自主性。
agents,追求的是自主性,牺牲了可观测性。
但真正优秀且可靠的系统,单纯的可观测性和自助性都无法满足。
workflows的复杂,体现在图结构上,有分支、有并行、有多条路径。
agents的复杂,体现在提示词里,复杂的逻辑被抽象成了自然语言,所以智能体是提示词+工具。
那托拉拽工作流会有什么问题?
首先,托拉拽实现智能体门槛并没有那么低,虽说是面向大众设计,但普通非技术用户使用起来还是很困难。
其次,复杂一点的任务,想用托拉拽来实现,会变得难以管理,一旦超过某个复杂度阈值,就得面对一大堆乱七八糟的连线,很难迭代和维护。
以软件工程的逻辑来看,对于高度复杂的问题,要实现可靠性,系统往往不能是纯粹的agent,还需要结合workflow的部分。
面对复杂逻辑,写代码反而是最简单的,这也是LangChain设计的初衷。
而随着AI coding的成熟,自然语言写代码,将用代码实现复杂逻辑的成本降到趋于0,越来越多的人可以使用该方案。
所以,对于简单任务,提示词+工具已经足够可靠,面对复杂任务,用无代码方式构建的工作流反而更合适。
托拉拽的方式构建智能体正在面对着两端的积压,随着模型能力越来越强,原有构建的图便没有了价值,随着代码生成越来越便宜,写代码的门槛正在降低。
Chase这些观点我是可以理解的,试想我们在工作中有多少低代码的框架?有多少自己设计的DSL语言?
将这些低代码框架和DSL语言给到运营同学或者研发同学使用,他们的眉头是紧皱的还是舒展的?
很多时候大家都是捏着鼻子在用一些所谓的低代码平台解决复杂的业务逻辑,而且一旦出问题就很难快速止损。
最终这些所谓的低代码平台或者DSL面对复杂问题时,还是不得不需要研发介入才行。