osFoundry / Platform
实时数据通道
发布/订阅通道,具备至少一次投递、历史回放与按订阅者游标。
简介
实时数据通道是 osFoundry 的消息中枢，负责在工作区各个部件之间传递事件。任何生产者（智能体、正在运行的应用、代码进程或聊天）向一个命名通道发布消息，该通道上的每个订阅者都会收到。这是经典的发布/订阅模型：生产者与消费者相互解耦，你可以在不改动发布方代码的情况下增删订阅者，一个事件也能同时扇出给多个读取方。
投递方式是至少一次（at-least-once）。已发布的消息即便跨越重连与重启也会送达每个订阅者，代价是订阅者偶尔会看到同一条消息两次，因此消费者应把处理逻辑视为幂等的（用消息 id 作为工作键，或按自然键去重）。通道会保留历史，而不是一读完就丢弃消息，由此解锁两件事：一是回放，订阅者可以重新读取通道里的历史消息，而不只是看实时到达的内容；二是按订阅者游标，每个订阅者独立记录自己的位置。有了游标，落后、断线或稍后才启动的订阅者都能从上次停下的位置精确续读，同一通道上的两个订阅者也可以停在流中完全不同的位置而互不干扰。
由于 osFoundry 是自带密钥（BYOK）、本地优先的桌面工作区，这条数据通路是与你的工作并肩运行的，而不必经过一个需要你自行配置并按席位付费的第三方消息代理。通道是那些需要在变化发生时立即响应的功能背后的管道：监视新条目以待处理的智能体、上游数据一到就更新的应用，或者一个阶段把结果交给下一个阶段的流水线。它让这些部件无需轮询、无需紧耦合即可通信，同时你的数据可以留在自己的设备上。
主要功能
- 发布/订阅通道把生产者与消费者解耦，一个已发布的事件无需改动发布方代码即可扇出给每个订阅者
- 至少一次投递让消息在重连与重启中不丢失；由于消息偶尔会重复，请把消费者设计成幂等的
- 历史回放让订阅者能重新读取历史消息，而不只是接收实时流量，对迟到加入者和重新处理都很有用
- 按订阅者游标独立跟踪每个读取方的位置，因此慢速、重启或迟到的订阅者都能从上次停下的位置精确续读
- 在共享的本地优先数据通路上连接智能体、应用、代码与聊天，无需配置外部代理，也没有按席位收费
使用场景
- 智能体开发者：智能体订阅一个入站任务通道并逐一处理，重启后从自己的游标续读，既不漏活也不重复处理
- 应用开发者：工作区应用订阅一个通道，上游数据一发布就更新视图，而不必按定时器轮询
- 流水线作者：阶段一把结果发布到通道，阶段二从中消费，逻辑变更后还可用回放重新处理历史
常见问题
至少一次投递对我的代码意味着什么？
它保证已发布的消息即便跨越断连与重启也能送达每个订阅者，但订阅者偶尔会收到同一条消息不止一次。请把处理逻辑做成幂等的（按消息 id 或自然键去重），这样重复只是无害的，而不会被重复计数。
新加入或重启的订阅者能补上错过的消息吗？
能。通道保留历史，且每个订阅者都有自己的游标，因此迟到加入或重启后回来的订阅者可以回放历史消息，从上次记录的位置续读，而不只是看它连接期间到达的流量。
同一通道上的两个订阅者会共享流中的同一位置吗？
不会。游标是按订阅者划分的，每个读取方独立推进。在同一通道上，一个订阅者可能已追到最新消息，另一个还在处理更早的历史，二者互不影响。