Neon Functions 现在支持无限时长的流式连接，让 AI 智能体能够保持实时通道开启数秒、数分钟甚至更长时间，而不会触及导致大多数无服务器工作负载中断的超时限制。这一变化对于任何构建对话式助手或使用工具的机器人的人来说都至关重要，因为流式传输中断会导致对话停滞，从而破坏用户体验。

为什么无服务器架构与 AI 智能体一直存在矛盾

大多数无服务器平台是为快速、即发即忘的任务而构建的。为了保持资源的可预测性，它们强制执行硬性的执行上限——免费层级通常为 10 秒，付费计划通常为 60 秒。然而，AI 智能体需要时间进行思考、调用外部工具，并随着生成过程不断输出 token。这种“思考”阶段往往会持续数十秒，而且只要模型在产生输出，token 流就可以一直持续下去。当平台的计时器到期时，它会关闭连接，客户端就会看到流式传输中断。

Neon 的解决方案：默认支持长连接流式传输

Neon Functions 改变了这一局面。函数调用可以无限期保持开启状态，通过 WebSockets 或 Server-Sent Events (SSE) 交付数据，无需任何特殊配置。平台将长流视为普通请求，因此开发者只需编写生成流的逻辑，剩下的交给 Neon 处理即可。

在最近的一次测试中，两个端点展示了这一行为：

  • Heartbeat endpoint – 函数每秒发出一次“滴答”信号，持续 90 秒。典型的无服务器层级会在 10 或 60 秒后终止请求；而 Neon 会保持连接一直处于活跃状态，直到函数自行结束。
  • Token-relay endpoint – 函数在每个 token 生成后立即将其从 AI 模型流式传输到客户端。用户可以看到答案逐字出现，而不是等待整个文本块。

这两个示例都只需要客户端发起单个请求；无需轮询或保持活跃（keep-alive）的技巧。

谁能受益，谁需要保持谨慎

构建对话式助手、使用工具的智能体或任何需要推送增量结果的服务团队都能获得立竿见影的优势：超时限制消失了。其结果是更简洁的代码、更低的延迟和更流畅的用户体验。

但也值得注意以下权衡：

  • 仅限请求的模型 – Neon Functions 处理的是附着在活跃请求上的流。必须比请求生命周期更长的后台任务仍需要单独的调度器，例如 Inngest 或类似的流工作引擎。
  • 冷启动 – 空闲函数可以缩减至零，因此下一个请求可能会产生冷启动延迟。活跃的流可以防止缩减，但在不活动后的第一次请求仍需承担启动成本。

后续关注点

核心结论是：Neon Functions 消除了长期迫使 AI 开发者寻找绕过方案的超时天花板。通过允许请求根据智能体思考和对话所需的时间保持开启，Neon 让部署流式 AI 智能体变得像部署任何其他无服务器函数一样简单。