各位朋友，今天咱们来聊聊OpenAI的一个大动作——他们把Responses API的交互模式从传统的HTTP请求（像REST、SSE这些）升级成WebSocket了。这对那些需要多工具调用的AI Agent场景来说，可是能带来巨大的带宽节省，还有20–40%的速度提升呢。咱们来好好说说这背后的原因。

首先，OpenAI刚对他们的API做了个重大改变。以前大家可能都习惯用REST调用处理所有事，但现在他们转向了WebSocket，这变化可不小。表面上看好像没那么显眼，但实际上，这能把带宽减少90%以上，速度还能提升20–30%，就只是把SSE改成WebSocket而已，是不是听起来挺疯狂的？

要是你还不太了解AI模型的工作原理，或者不明白终端、编辑器里的程序和生成输出的服务器之间的关系，那这个视频对你来说会特别有用。就算你已经懂了，也可以把它分享给你那些可能还不太明白的同事。我经常惊讶于很多开发者居然不理解上下文是怎么工作的，也不清楚请求是怎么往返的，希望这个内容能帮大家把这些概念弄明白。

那我为啥对这个WebSocket的改动这么兴奋呢？首先得说，我们现在还没在T3 Chat里用它，说实话，对T3 Chat的使用场景来说，这变化没太大意义，但在其他地方，这作用可就大了去了。

咱们先得搞清楚上下文管理和AI模型请求的工作方式。比如说，上方有个系统提示符，然后是用户消息。咱们举个传统的例子，假设我想改进我应用的SEO，让我们写个详尽的计划，说说怎么让这个应用的SEO更好。这是个很经典的用户消息场景。然后呢，会有来自Agent的响应，Agent可能会说，“好的，首先咱们得更好地理解这个代码库。”用户发出这个提示词后，Agent决定要更好地理解代码库，那它会做啥呢？它会调用工具，比如列出给定目录里的所有内容。然后它可能会说，“很有趣，重要的代码可能在src目录下，那咱们接下来扫描那里。”就这么一系列操作后，最终会得到答案，比如“你的SEO已经改进了，我编辑了某个文件”。咱们用Agent构建应用的时候都见过这种情况，这就是某一时刻的上下文。

显然，随着操作的进行，上下文会不断累积。顶部是系统提示符，然后是用户消息，接着是Agent消息，Agent消息以工具调用结束。工具调用触发后会获得结果，Agent然后响应，进行下一组工具调用，最终得到实际结果。

那当你想发送后续消息时会发生什么呢？比如你说“看起来不错，但我想改一下描述之类的”，这时候发送到OpenAI API的请求里包含什么呢？如果你接触这个有一段时间了，你就会知道，要是你看聊天记录，会发现它把所有内容都包含进去了。后续请求不只是发送你的新消息，而是发送整个历史。

但这还不是最头疼的地方。要是就这么一次，那问题还不大，每次用户消息发送所有这些文本也还能接受。可要是我告诉你，它发送的次数远远超过这个呢？比如，当你发送用户消息时发送一次，第一个工具调用完成时发送一次，第二个工具调用完成时又发送一次，每次发送新提示词时，每一个工具调用都会把整个历史发送回去。

仔细想想，这其实挺有道理的。因为Agent调用工具时，比如要更好地理解代码库，它输出一个工具调用，Agent其实就像自动补全一样，只是在生成词语，它不知道正在发生什么，不知道自己在什么系统里，也不知道这个过程需要多长时间。

大家可能觉得当工具调用发生时会有暂停，但其实不是这样的。工具调用意味着生成已经完成，AI在工具调用发生时并没有在运行，实际上是暂停了，甚至可以说“死了”“被终止了”“关闭了”。

当工具调用完成后，所有从这个时间点往上的内容都会被发送回AI，通过API调用发送回运行它的服务，现在它就有了新的历史记录来继续生成内容。

有人会问，这是用来验证工具调用是否成功的吗？不是的，这是为了获取工具调用的信息。比如工具调用是列出目录内容，这是一个ls调用，现在有了输出，但它在拥有这个输出之前什么也做不了，所以就停止了。

所以每次工具调用发生时，模型都需要知道工具调用的结果是什么。一旦工具调用完成，它就会把所有内容发回，因为它需要所有内容。这就像“土拨鼠之日”那种循环，每次模型“醒来”时，它的“大脑”里什么都没有，它是无状态的，所以所有的状态都必须每次都传回去。

如果你观察长时间Agent运行时的网络流量，你会发现每一个工具调用都会把整个历史记录发回给Anthropic API、OpenAI API或者其他服务，然后可用的GPU会接收所有上下文，为下一次响应加载它。

你可能会想，这不是缓存的作用吗？缓存只是为了减少模型需要做的计算，让它更便宜、更快地获得第一个token，但它并没有改变你发送的数据量，因为缓存的键是你历史记录的哈希值。所以就算部分内容被缓存了，你还是得传递整个历史记录，它会对其进行哈希计算，然后加载到某个点的状态，再添加新内容，开始响应。缓存只是减少了计算时间，并没有减少发送的流量。

我得把这一点说清楚，有人问这是不是压缩，不是的，压缩完全是另一回事。压缩是获取整个历史记录并对其进行总结，这样你就不再需要所有的token了。但压缩会破坏缓存，对缓存没有帮助，它是选择放弃缓存，因为你想要更短的历史记录。

总之，希望你能看出这里的问题。问题不是模型获取这些数据太难，而是每次工具调用都要发送所有这些数据，数据量不断增长，这效率太低、太昂贵了，消耗大量带宽，这让运行大量Agent的成本比实际需要的高很多。

这就意味着OpenAI的API需要处理这些巨大的文本负载、路由等各种事情。要是能不发送所有这些内容，只发送新的内容，比如新的工具调用，那会容易得多。但这样做会让事情变得更复杂，因为OpenAI的基础设施不允许这样。

OpenAI有很多GPU，但你不是直接访问这些GPU的，你的请求会先到一个API编排层。OpenAI有数千甚至数万个GPU分布在不同地方，你的请求到API后，API会检查是否有缓存、是否有空闲GPU、用户是否有权限等，然后把请求路由到某个GPU上。如果一切顺利，会返回token，这些token最终成为Agent的响应。

但API的工作没那么简单，有多个独立的API节点，它们会寻找随机可用的GPU并路由过去。所以你的第一个请求可能到第一个API节点，第二个请求可能到第四个，下一个可能到完全不同的GPU。这就导致要维护状态，确保正确的服务器有正确的上下文非常麻烦。而且缓存层是一个完全独立的层，需要管理所有这些内容。当你发送请求时，它会去OpenAI运行的服务器，这些服务器需要检查缓存、加载状态到GPU、加载prompt、生成token然后响应。

有时候，只是为了生成仅仅十个token，就要做这么多工作。因为API层没有你的历史记录，不知道你之前发送了什么，每个额外的请求可能被路由到其他地方，所以你必须重新发送整个内容，否则就会丢失。他们可以尝试一直附加一个ID并保持所有内容缓存，但不知道要保留多久，在全球范围内扩展带来的延迟问题让这根本不可行。

不过有个解决方案，就是保证每一个请求都打到同一个服务器实例上。要是能确保工具调用2和工具调用1去到同一个实例，确保同一会话期间的所有操作都打到同一个服务器实例，那会怎样？这样就不用从存储中加载所有数据了，不需要检查缓存，因为你已经知道了，也不需要发送所有上下文，只需要发送新消息或新的工具调用，几乎不需要发送任何东西。但这必须是有状态的，而OpenAI API之前是无状态的，服务器实例什么都不知道，必须去查找数据、检查权限等。

这就是为什么我们要讨论WebSocket了。WebSocket的价值不是因为它是一个更好的协议或者更快，而是因为它能保证你访问的是同一个服务器实例。通过在整个生成过程中保持与API服务器的连接，你不用担心丢失状态，不需要重新检查权限，也不需要担心哪些被缓存了哪些没有。

WebSocket更像是一个保证，随着生成的进行，你可以持续访问同一个服务器实例，它能追踪你到目前为止做了什么。你不需要重新发送整个上下文，只需要发送新的内容，然后它能立即连接到GPU，传送所有内容并开始响应。这减少了发送的数据量、处理的数据量、执行的检查次数，以及从工具调用完成到API知道发生了什么之间的步骤。这真的太棒了，很难相信花了这么长时间才实现这样的功能。我非常感谢OpenAI是实现这个的一方，因为他们的实现方案往往会成为标准。

OpenResponses就是一个受OpenAI Response API启发的开放标准，定义了共享的请求响应模型、流式语义和工具调用模式，让客户端和提供者可以交换结构化的输入和输出，采用一致的格式调用各种API，现在已经成为开放标准。虽然目前还没实现WebSocket部分，但预计很快就会实现。

这里要说明的是，在聊天应用场景中，WebSocket的优势并不大，因为如果不是立即跟进，保持连接就不值得。但每条用户消息可能会产生上百个工具调用，这时候问题就大了。

OpenAI自己说，WebSocket保持与Responses API的持久连接，允许只发送新的输入，而不是每次都往返发送整个上下文。通过在交互之间保持内存状态，避免了重复工作，能将包含二十多个工具调用的AI运行速度提升20–40%。

这真的很重大，在这个领域有很多重要的事情，不仅仅是模型生成token的速度。我们现在还处于早期阶段，一方面这很酷，我们有办法保持状态并大幅提升性能；另一方面，我们又很早期，之前居然接受每次都发送整个上下文，只是因为把工具调用硬塞进了现有的API和标准里。这里有太多机会了，希望这能让你对构建AI应用感到兴奋，在整个技术栈中可以做出很多有用的改进。

很多时候我们做事的方式只是因为一开始就是那样，很多工具我们依赖也只是因为习惯了。现在，从联网方式、请求发送方式到代码在Git中的存储方式，整个技术栈都面临变革，这真的很有趣。那些认为深度技术规划和思考会因为AI消亡的人错了，现在它比以往任何时候都更重要，我们得以从第一性原理重新思考一切，这真的很有趣。

当OpenAI告诉我他们的这个改动时，我超级兴奋，也很幸运能提前试用。尽管这个内容很“极客”，我也预期这个视频可能表现不好，但我真的希望它能成功，因为这比任何新模型都酷得多。我个人对这个小小的API改变非常感兴趣。

谢谢大家和我一起探讨，希望你们也喜欢这个内容。下次见，极客们。
转载：OpenAI 改用 WebSocket，AI Agent 多工具调用大优化，背后架构逻辑全解析