跳转到内容
类型解锁阶段生产环境难度中等工作分享流用于AI 构建者用于后端开发者服务管道服务智能体为何选 HoodyHTTP 原生为何选 HoodyAI 原生
类型解锁阶段生产环境难度中等工作分享流用于AI 构建者用于后端开发者服务管道服务智能体为何选 HoodyHTTP 原生为何选 HoodyAI 原生
类型解锁阶段生产环境难度中等工作分享流用于AI 构建者用于后端开发者服务管道服务智能体为何选 HoodyHTTP 原生为何选 HoodyAI 原生
类型解锁阶段生产环境难度中等工作分享流用于AI 构建者用于后端开发者服务管道服务智能体为何选 HoodyHTTP 原生为何选 HoodyAI 原生
返回使用场景列表
use-cases / stream-llm-tokens-to-anything / hero
PIPE · AGENT · STREAMING

把 LLM token 流到任何能读 HTTP 的东西

你 agent 的第 3 步在生成 token。第 4 步要在第 3 步还没结束前就开始消费。把模型输出直接管道送进一条路径;下一个进程 curl 同一条路径。无 SSE 管道、无中间件、无回调缠绕——字节以线速流动。

阅读 Pipe API
use-cases / stream-llm-tokens-to-anything / mechanism

两条 curl,一条路径,无中间层

大多数流式栈要 SSE 端点、队列、pub/sub 总线和一段框架回调,才能把 token 挪四英尺。管道把这一切都替掉:生产者用 PUT 写到一条路径,消费者用 GET 从同一路径读。字节直接在两端之间流——服务端不存任何中间结果。

通常的栈

生成者和读取者之间五层

  • LangChain 流式抽象回调地狱
  • Server-Sent Events 管道分帧 + 心跳
  • Redis pub/sub要运维的中间件
  • 自定义 WebSocket 中继鉴权 + 重连
  • 消息中间件(Kafka/RabbitMQ)topic + partition
  • Agent 框架回调厂商绑定
管道

两条 curl 共用一条路径

PRODUCERcurl -T - /pipe/tokens
同一路径
CONSUMERcurl /pipe/tokens

服务端存储:零。两端一连,字节就从发送端流到接收端,反压按接收端处理。端点存在,只是因为有两条 curl 摸到了它。

agent-step-3.sh
# Step 3 — agent generates and pipes tokens upward.
ai.generate({ model, stream: true }) \
  | jq -c '{delta: .text}' \
  | curl -T - https://pipe.hoody.com/api/v1/pipe/run-42/tokens?n=3

# Step 4 — three readers GET the same path. The pipe fans out.
curl https://pipe.hoody.com/api/v1/pipe/run-42/tokens?n=3 | tee evaluator.log
curl https://pipe.hoody.com/api/v1/pipe/run-42/tokens?n=3 | jq -c .delta
curl https://pipe.hoody.com/api/v1/pipe/run-42/tokens?n=3 | websocketd --port=8080

# All four processes block until the n=3 readers connect, then bytes flow.

PUT 把字节推上去,GET 把它们拉下来。?n 参数说要等几个读取者;管道阻塞到那么多人连上,然后同时扇出。无客户端 SDK、无中间件、无 SDK 安装——只有 HTTP。

use-cases / stream-llm-tokens-to-anything / listeners

同一路径,多个读取者,无 SDK

生产者一开始管道送字节,任何说 HTTP 的东西就能订阅。同一条流上最多 256 个读取者,管道扇出,反压按接收端处理。无客户端库要装,无中继要部署。

FOR THE FRONTEND

浏览器读同一个 URL

EventSource 或 fetch 读取者命中 pipe 路径,就能拿到 agent 正在生成的同一字节流。你的服务器上不必做 SSE 分帧——管道运的就是模型发出的原始字节。

FOR THE EVALUATOR

第二个 agent 监听并决策

评估进程订阅同一路径。一旦输出跑偏,它可以在第一时间打断生产者。两个 agent 在同一根线上,无编排框架在中间撮合。

FOR THE LOG TRAIL

把流分支给一个监听容器

一个日志消费者读、压缩、写盘。一个调试 UI 并行地读。它们都不知道彼此存在——管道只是把同一字节交给每个读取者。

FAN-OUT CAP256管道强制的每路径接收端上限——用 ?n 让它等到那么多人连上再开始传输。
LATENCY OVERHEAD0字节随到随穿。服务器上无缓冲——反压按接收端处理。
SDK FOOTPRINT0 kb生产者和消费者都是 curl。任何说 HTTP 的东西都能订阅——浏览器、容器、agent、shell。
use-cases / stream-llm-tokens-to-anything / punchline

LLM 流式。管道流式。读取者流式。无中间层。

0101 · 模型发出 token
0202 · 管道转发字节
0303 · 读取者应用它们
步与步之间无中间件路径就是协议
use-cases / stream-llm-tokens-to-anything / replaces

它替代了什么

当一个进程要实时把 token 流给另一个时,你伸手会去找的那些东西。每一种都自带分帧、自带 SDK、自带运维表面。管道就是那根线。

  • LangChain 流式抽象回调链、框架绑定
  • Server-sent events 管道分帧 + 心跳 + 重连逻辑
  • Redis pub/sub要装、要运维、要付费的中间件
  • 自定义 WebSocket 中继鉴权、重连、反压都得自己写
  • 消息中间件(Kafka、RabbitMQ)为一条流引入 topic、partition、消费组
  • Agent 框架回调厂商绑定,只能在同一 SDK 里读
use-cases / stream-llm-tokens-to-anything / cta

别再为两个本来就说 HTTP 的进程之间架流式基础设施。开一条路径。管道送进去。读出来。

阅读 Pipe API
use-cases / stream-llm-tokens-to-anything / related

阅读其他内容