‍发布会录像tps://wwhttps://www.bilibili.com/video/BV1HN411G7cb/

0、前言

发布会的概要介绍已经有很多，本文也无意重复，仅评论一些我觉得值得说的点。

我看完了发布会、相关新功能的文档、Sam在论坛中对于Assistants API的费用解释等等。我建议所有LLM应用开发者都应该去看下这些原始内容，而不是看一些一图概要，他们丢失了一些重要信息。

由于我暂未用上这里的不少功能，所以一些细节还无法确定。

1、新模型及API

https://platform.openai.com/docs/models

1.1、gpt-4-turbo 与 gpt-3.5-turbo-1106

gpt-4-1106-preview虽然模型名中没写turbo，但官方说了这是turbo版本。也就是费用明显降低、速度提升。

这次的gpt-4-turbo更新了数据版本，而其他模型均没有更新数据，所以web页面上的GPT4已经是这个gpt-4-turbo了。

gpt-4-turbo的context window扩展到了128k tokens，单次调用最大返回长度为4k token。Claude模型的优势至此已经丧失。

gpt-3.5-turbo-1106也一同更新，context window扩展到了16k，但遗憾的是没更新数据版本。

两个模型版本的context window都提升，且不再有单独的更长context window的版本，这标志着OpenAI已经基本搞定了128k以下长上下文的训练能力（在它自己的质量标准下）。

gpt-4-turbo推出之后，原有的gpt-4、gpt-4-32k也没有更新，正式标志着它们跟早期的gpt-3.5原版一样将退出历史舞台。

一些其他2个模型共有的更新点：

• Function calling能力支持在一次请求中同时请求调用多个function，提升了LLM在复杂场景下的自用使用工具能力。

• 提升了输出格式指定能力，并增加了专门的json输出控制选项

• 支持设置随机数种子，以实现可复现的LLM调用结果。

• (后续将)支持新模型输出token log-prob

1.2、多模态API

这次OpenAI直接发布了全部的多模态能力的API，没有任何私藏。包括：图片输入(GPT4V)、图片生成(DALL-E)、语音生成(高质量TTS)。

并更新了whisper到V3版本，很可惜whisper在中文普通话上提高很少，提升幅度小于所有其他语言，但粤语提升明显。

GPT4V模型名为gpt-4-vision-preview，支持文字和图片输入，图片按大小计费。gpt-3.5-turbo无缘此功能。

DALL-E 2/3都开放了API，不过只有DALL-E 2支持图像局部修改。

高质量TTS开放了API，分成tts-1和tts-1-hd两个版本。

Whisper-V3也会进入API，Whisper API支持GPT-4后处理环节。

2、GPT Builder 与 Agent Store

2.1、GPT Builder

发布会上展示了一个使用自然语言构建简单Agent的功能，叫做GPT Builder。整个会上基本把Agent都叫做GPT。

构建出来的Agent能力至少包括：

• 类知识库的方案，支持system prompt、文档知识库等

• 搜索功能

• DALL-E图像生成功能

• Code Interpreter功能

• 疑似外部函数插件

所有只是一个system prompt黄页的产品都被颠覆了，目前我看到的比较接近的是讯飞星火的“友伴”，但支持调用的能力也是弱于此的，更别说模型本身了。

2.2、Agent Store

OpenAI官方提供了一个GPT分享和浏览平台，我暂时称作Agent Store。

从宣传内容来看，这次的产品设计明显好于之前的plugin store。OpenAI下半年应该是有靠谱的产品负责人了，不能再瞧不起OpenAI的产品设计了。

本来Agent as a Service平台还有计费等等问题，现在在该平台上直接使用用户自己的OpenAI账号就好了。

OpenAI发布会上说了会给Agent开发者分成，还没有看到细节。个人Agent开发者的时代要来了。

2.3、对国内的影响

整个这一节的内容技术上不算有卡点，更多是产品设计和平台设计。这方面本来应该是国内大公司的优势，但最早交出一个完整答卷的是OpenAI。

我整体觉得OpenAI的这一套设计是不错的，虽然目前能做的Agent还比较简单，但后面可以逐步做的复杂起来。其他的方面都基本成型了，而且也是我觉得没有太大问题的方式。

国内大厂应该直接抄一套方案了。我相信国内很快（一个季度之内）就能用上类似的Agent开发和共享平台。唯一的问题就是基础模型、多模态能力、工具等能力拖累Agent的效果了。这我就没啥办法了，只能期待国内大厂和有流量的基座公司多努力了。

3、Assistants API

Assistants API其实算是之前传闻的Stateful API，但发布的能力跟很多人的猜测不同，它并没有降低成本。

从发布会来看，它其实是为Agent开发服务的API，也就是上面GPT Agent的API对应物。

3.1、Assistants API的真实能力

Assistants API并不能降低历史对话的API调用成本，也没有压缩历史对话的能力。

它更像是一个有序的workspace，用户存放简单Agent工作流中的各种信息，例如用户输入、模型返回结果、上传的文件、tool调用的中间状态等等，触发下一次LLM调用时，直接使用该API提供的thread抽象作为上下文。

如果thread中的内容超过了模型支持的上下文，目前的策略是截断历史。但不排除OpenAI将来会做一个更好的历史压缩功能，甚至无限上下文能力。

整个Assistants API的交互是异步的，而不再是同步的等待模型返回结果。目前还没有推出流式返回的API。

Assistants API在收费上完全没有任何折扣，跟使用模型的API并使用同样的历史请求是一样的。

这也是让不少人觉得这个API有些鸡肋的原因，如果都还需要自己压缩和控制上下文，那么似乎在应用侧自己做会更好一些，为何要使用这个API呢？

3.2、长期影响

在我看来，这个设计的长期价值更为重要。它其实更符合我之前在 LLM Stateful API前瞻【2023.10】 一文中第3节预测的思路，即给未来更接近应用的特性提供一个尽量通用的API抽象层。

虽然目前还只有一个LLM能在上面产生信息，但将来可以加入更复杂的工具/能力/子Agent等等。所有更复杂的产品逻辑都可以依托于这个workspace（OpenAI叫thread）来完成，而开发者后续的修改并不大。

这个设计用3年感觉也没什么问题，这才是重要之处。它给整个生态中基座LLM和底层能力公司 与 上层应用开发者划定了一个新的边界，而且这个边界看起来问题不大。由于OpenAI的带动作用，相信全球的公司都会朝着类似的设计前进，更快的形成一个新的标准，让整个生态的各方更好的形成合力。

目前Assistants API上绑定的功能还较为简单，它的Retrieval能力看起来和简单的RAG其实也没什么不同。但这个接口设计没什么问题，后面的实现未来可以慢慢提升，而上层的开发的简单应用都可以直接利用上后续新提供的能力。这个价值作为接口设计来说，已经很够了。

目前它对于定制开发能力强的LLM-native/Agent应用开发团队来说，并不好用，可操控性不高。它赋能的是那些没有太多定制开发能力的人，而且这些开发能力更差的人做出来的Agent的能力会随着平台提供的能力提升而免费全自动提升。

这次对于中间件应用的影响可能较大，很多中间层方案包装的并不够好，应该是需要被抛弃的了。我祝愿这些团队能做出正确的选择。

4、总体感慨

• OpenAI的产品和API设计真的好了很多，我们得调整对于OpenAI这方面能力的认知。

• OpenAI没有藏私，所有产品端提供的能力基本上都提供了API，或者正在路上。

• OpenAI已经做了2C Agent Store，不犯错误的话未来可期。

• 新功能真的多，需要整个社区消化一阵。

• 自己弄一个OpenAI开发者账号，而不是通过API Proxy变得越来越重要。

交流与合作

如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，见 联系方式。

读者交流群见 公众号读者交流群

希望留言可以到知乎对应文章下留言。

本文于2023.11.7首发于微信公众号与知乎。

知乎链接 https://zhuanlan.zhihu.com/p/665549816