StreamCore 开源发布：专注 AI 语音代理的实时媒体基础设施

StreamCore 在 Hacker News 以 Show HN 形式公开亮相，定位为「AI 语音代理的实时媒体基础设施层」。它不接管 Prompt、工具或业务逻辑，而是负责用户与 AI 之间对延迟最敏感的那一段音视频通路——从浏览器、电话到后端、嵌入式设备全平台覆盖。

项目要解决的真实痛点

作者指出，演示一个语音代理很容易，但当真实用户加入，问题会集中爆发：通话中插话、句中停顿、被企业防火墙封掉 UDP、首字延迟长达三秒……这些场景足以让 Demo 不再是产品。StreamCore 把这一整条链路抽象出来：WebRTC 传输、自适应轮换、打断、流式 STT/LLM/TTS、NAT 穿透、会话状态与实时事件，全部由它统一负责。

关键技术能力

• 传输层：基于 WHIP（RFC 9725）的 WebRTC 音频，单次 HTTP POST 即可接入，无需额外信令通道；Opus/RTP 双向互通。
• 连通性：内置 Pion STUN/TUN 服务，监听 UDP 与 TCP 3478，无需额外部署 coturn；网络切换或 NAT rebind 时通过 ICE restart 在同一会话内恢复。
• 轮换控制：自适应 VAD 跟踪每路通话噪声底，并配合去抖逻辑把句中停顿合并为一个轮换。
• 打断（barge-in）：对智能体音频做 ducking，过滤「嗯—嗯」类附和词，并在确认打断后取消进行中的 LLM 与 TTS 请求。
• 流式管线：流式 STT → 流式 LLM → 分块流式 TTS，让音频在合成完成前就开始播放。
• 会话与事件：服务端生成会话 ID，支持多端会话，通过 DataChannel 暴露转写、回复、状态与每轮延迟事件。

官方在 streamcore.ai 跑通了这个仓库，访问即可与代理对话并随时打断，屏幕上会实时显示每轮的 STT、LLM、TTS 时延。

提供商与「自带代理」集成

StreamCore 刻意把智能体留在用户侧，提供五种集成方式：

• 工具调用：通过 Python/TS/JS 插件或原生 Go 工具对接现有后端。
• 自有代理：设置 llm.provider = "agent"，每轮通过 HTTP POST 转发到用户自托管的任意语言代理。
• 自有模型：直接指向任意 Ollama 兼容地址。
• 自有代码：实现一个小型 Go 接口，整条媒体通路不变。
• 内置运行时：也可选用 StreamCore 自带的代理运行时，附带工具、技能、RAG 与历史记录。

当前已适配的提供商包括 Deepgram、AssemblyAI、OpenAI、Cartesia、ElevenLabs、MiniMax、Speechify、Ollama、本地 VibeVoice，以及 xAI Grok Voice 的端到端语音方案；检索侧支持 pgvector 与 Supabase。

现状与已知不足

作者明确列出了尚未完成的能力，以保持功能矩阵的诚实：尚无 Prometheus/OpenTelemetry 指标导出，日志仍为文本格式而非带 session_id 的 JSON；无版本化二进制发行；会话存于进程内存，水平扩展需外部存储配合 sticky 路由；内置运行时不持久化跨会话记忆，需由用户代理自行承担。

项目以 Go 1.25+ 与 Docker 启动，五分钟内可在两个终端中跑起完整链路，并在仓库中提供 TypeScript、React Native、Go、Rust 多端 SDK。项目方邀请开发者在 Discord 中反馈需求，路线图优先级由社区呼声决定。