2025.10.6 OpenAI又一次的DevDay，这次发的内容不少，这次先谈我认为其中最预料之外的地方——Agent Builder的功能设计。

<span leaf="">title: OpenAI DevDay 2025: Opening Keynote with Sam Altman

Agent Builder支持类似Dify/Coze的workflow编排。但Agent Builder并非照搬现有Coze类产品的设计，这就是我写这篇文章的原因。

另外，有意思的是，在DevDay发布会上，把Agent Builder构建出的Workflow称作Agentic Workflow（见发布会视频 00:17:01）。我之前一般使用Agentic和Workflow的时候一般是互斥的，不会把它俩放在一起。但当你搜索这个词的时候，会发现不少地方都在非正式的使用这个词，包括OpenAI的一些文档也是如此。目前来看基本上可以把这个词近似理解为使用了LLM和tools的workflow，或者是Agent中的workflow。不过这个词目前看来并没有被非常频繁地使用。

Agent Builder的一些基本信息

首先Agent Builder并不是直接面向C端用户的，而是被放在了OpenAI的开发者平台中，入口地址为：

https://platform.openai.com/agent-builder/

Agent Builder的不少功能需要进行受信组织认证才能使用。

Agent Builder只包含简单的一些节点，包括：Agent节点（对应于LLM调用节点）、End、Note（注释）、File Search、Guardrails、MCP、If-Else、While（循环）、User approval、Transform（数据格式转换）、Set state（设置全局变量）。

Agent Builder自带的调试功能，可以直接查看每个节点的请求与响应的所有原始信息。同时还有耗时trace分析和eval功能。

Agent Builder的结果可以直接发布，也可以导出为代码。

这些都是一些传统workflow编排产品所常见的功能，虽然做的比较简单，但整体的完备性是很好的，可以实现真正的一站式。

Chat History As Context

Agent Builder与Coze类产品最大的差异是，它的每个节点并不是非要指定输入，而是可以使用Chat History作为不同节点之间的Context/信息传递方式。

而且更为关键的是，这是它的默认设置，并且在发布会上和演示视频中，也是这么用的。

它的每个LLM相关节点可以单独配置：是否输入Chat History，是否把请求结果也写入到Chat History。这两个设置都是默认开启。

这就很有意思了，如果读者对LLM应用圈稍有了解就会知道，目前仍然在Context Engineering概念的潮流期。从Context Engineering的角度来看，这种方式Chat History As Context的方式混入了过多无关的内容。这看起来很像是不懂LLM应用开发的用户自己手写的workflow并在web chatbot上执行。

**在这个配置下，实际上workflow配置的图就不是数据流了，而是控制权转移图。**从一个Agent节点转换到另一个Agent节点，实际上Chat History保持不变，而只是换成了一个Agent的prompt继续对话。

对于这个功能的评价，估计每个人会有自己的看法。下面谈下我的解读。

具体地指定和传递每个内部变量是更符合传统软件开发的方式，但这对于low-code系统用户的认知负担较大，如果都作为一个context不断增长的流程，会更加容易。类似于所有的信息都是全局变量，而且默认引用。

从技术角度来说，这种方式也有它的优势：省去了中间环节结果的提取过程，默认全量传递信息。这保留了更多的信息，并移除了不必要的信息提取环节。而且对于LLM来说，更多的背景相关信息一般都不是坏事。

另外，这个Chat History不断累加的方式，也能够比较自然地使用Prefix Cache功能。并且workflow的执行一般都是在短时间内完成，正好匹配LLM API Prefix Cache保存时间不长的特性。

所以这抛给了我们一个问题，这种方式是否比我们手工排布 Prompt/Context的方式 在某些场景更有优势？

Widget Builder

Agent Builder的另一个“创新”是自带了一个UI小组件构建能力，叫做Widget Builder。可以制作一些小卡片式的组件，并指定让一个Agent节点的输出按照某个Widget的样式显示在Chat对话流中。

我相信这种东西在一些大厂内部的low-code系统中已经有了，但在公开的workflow编码系统中很少看到有人做。

而且这个Widget似乎并不是一个死板的组件，在调用它时，仍然可以通过prompt对它进行一些定制。这个功能也在Intro to Agent Builder视频中展示了。

总评

Agent Builder这个产品的设计相对于之前的很多工作流编排产品来说，明显是经过了更多的思考的。

首先，这是不是一个To C的产品？OpenAI的回答是：不是。它被放在了开发者平台上。不过OpenAI的开发者平台并不是完全面向开发者的，包括eval等一些产品会用的功能其实也放在了开发者平台上。把它放在 ChatGPT 还是开发者平台，实际上区分了普通用户与专业用户。

虽然在开发者平台上，但Agent Builder的整体功能设计还是对于非开发者很友好的：易用的系统、不依赖本地环境、节点种类不复杂、Chat History As Context，都体现了对于非开发者的友好。这也回答了一个问题，一个开发者为什么要去用low-code产品？**OpenAI的回答是：开发者不需要用low-code产品。**在目前的这个设计下，一些更偏开发的定制无法在Agent Builder 的workflow上实现，只能通过MCP方式引入。

Widget Builder的推出更是让我觉得不能再评价OpenAI的产品设计风格是简单/简陋了。很明显Widget Builder并非一个“必须”的功能，如果OpenAI只是去抄袭Coze类产品的设计，它不会专门做这样一个功能。但对于Agent Builder的用户来说，就只能看大段的文字么？很明显一些卡片式的UI能力是需要的，这在大厂内自用的一些low-code系统上就能看出来。我们不能让Agent的用户只看大段的文字或者是bullet points。

剩下的调试功能也是麻雀虽小五脏俱全，Coze做到现在，似乎在这方面都没有做得很好。不过确实这些调试功能不同C用户是用不来的。

所以总体来看，Agent Builder是个有着更多思考、更多取舍的产品。虽然工程量仍然保持着OpenAI一贯的小而精的特点，但它相对于之前的同类产品补齐了一些必要的维度，是重新设计，而不是无脑抄袭。

交流与合作

如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请加微信，联系方式请点击 -> 专栏简介 及 联系方式 2024。

本文于2025.10.7 首发于微信公众号。