epoll-router：为自托管AI代理打造的安全反向连接路由系统

一款基于Rust开发的反向连接能力路由器原型，让托管AI代理能够安全地调用私有工作节点上的本地能力，无需暴露内网端口或授予广泛网络访问权限。

• 原作者/维护者：chrisvo
• 来源平台：github
• 原始标题：epoll-router
• 原始链接：https://github.com/chrisvo/epoll-router
• 来源发布时间/更新时间：2026-06-11T15:11:28Z

原作者与来源

• 原作者/维护者：chrisvo
• 来源平台：github
• 原始标题：epoll-router
• 原始链接：https://github.com/chrisvo/epoll-router
• 来源发布时间/更新时间：2026-06-11T15:11:28Z 原作者与来源\n\n- 原作者/维护者：chrisvo\n- 来源平台：GitHub\n- 原始标题：epoll-router\n- 原始链接：https://github.com/chrisvo/epoll-router\n- 来源发布时间/更新时间：2026-06-11\n\n项目背景与核心问题\n\n随着大型语言模型（LLM）和AI代理技术的快速发展，越来越多的团队选择使用托管AI服务来辅助开发工作。然而，一个长期存在的痛点是：如何让托管的AI代理安全地访问和操作私有环境中的资源？\n\n传统的解决方案通常面临两难困境。一方面，直接授予托管代理SSH、VPN或数据库访问权限意味着将敏感凭证交给第三方服务，这显然违背了安全最佳实践。另一方面，将私有代码库、日志数据或内部服务完全迁移到云端进行测试和诊断，既不现实也不经济。\n\nepoll-router项目正是为了解决这一信任边界问题而诞生的。它提出了一种全新的架构思路：不是让托管代理主动连接私有环境，而是让私有工作节点主动建立到公共路由器的出站连接，从而在不暴露任何入站端口的情况下，实现能力的安全委托。\n\n架构设计理念\n\nepoll-router的核心设计哲学可以概括为"反向连接、能力边界、最小权限"。整个系统的数据流向与传统架构恰好相反：\n\n\n托管AI代理\n |\n | 请求已批准的能力\n v\n公共路由器\n |\n | 已建立的出站WebSocket连接\n v\n私有代理工作节点\n |\n | 在本地执行工作\n v\n私有仓库 / 服务 / 日志 / 模型\n\n\n这种架构的关键优势在于，托管代理永远无法直接访问私有网络。它只能请求那些由私有工作节点预先声明并批准的具名能力（capabilities）。工作节点通过持久的出站WebSocket连接与路由器通信，这意味着它们可以运行在任何没有公网IP的机器上，甚至位于严格防火墙后的内网环境中。\n\n技术实现细节\n\nepoll-router采用Rust语言开发，充分利用了Rust在系统编程和高并发场景下的性能优势与内存安全保障。项目目前包含两个主要组件：路由器和模拟工作节点。\n\n路由器组件\n\n路由器提供了符合OpenAI兼容格式的HTTP API端点，位于/v1/chat/completions，支持流式（SSE）和非流式JSON响应。此外，它还暴露了一个通用能力API端点/v1/capabilities/{capability}，用于调用工作节点上注册的各种自定义能力。\n\n工作节点通过WebSocket连接到路由器的/workers/socket端点进行注册。连接使用JSON消息信封格式，包含协议版本和消息类型字段，当前支持的消息类型包括：\n\n- worker.register - 工作节点注册\n- worker.telemetry - 遥测信息更新\n- job.start / job.delta / job.finish / job.error - 任务生命周期管理\n- capability.start / capability.delta / capability.finish / capability.error - 能力调用管理\n\n工作节点组件\n\n工作节点是实际执行工作的实体。在原型实现中，它模拟了一个能够处理聊天补全请求的工作节点，支持令牌增量流式传输。工作节点在启动时会向路由器声明自己支持的能力列表，目前原型实现了run_echo能力作为示例。\n\n身份验证采用Bearer Token机制，支持为客户端和工作节点配置不同的API密钥，实现了调用方与执行方的权限分离。\n\n本地运行与测试\n\n项目的使用方式非常简洁。首先启动路由器服务：\n\nbash\ncargo run --bin router\n\n\n然后在另一个终端启动模拟工作节点：\n\nbash\ncargo run --bin mock-worker\n\n\n此时就可以发送测试请求了。流式聊天请求示例：\n\nbash\ncurl -N http://127.0.0.1:3000/v1/chat/completions \\\n -H 'Authorization: Bearer dev-client-token' \\\n -H 'Content-Type: application/json' \\\n -d '{\n \"model\": \"local-default\",\n \"stream\": true,\n \"messages\": [\n { \"role\": \"user\", \"content\": \"hello router\" }\n ]\n }'\n\n\n能力调用请求示例：\n\nbash\ncurl -N http://127.0.0.1:3000/v1/capabilities/run_echo \\\n -H 'Authorization: Bearer dev-client-token' \\\n -H 'Content-Type: application/json' \\\n -d '{\n \"stream\": true,\n \"input\": {\n \"message\": \"hello private worker\"\n }\n }'\n\n\n典型应用场景\n\nepoll-router的设计使其适用于多种实际场景：\n\n私有代码测试：开发团队可以让托管AI代理在私有工作节点上运行测试，无需将整个开发环境上传到云端。AI代理可以请求run_tests能力，工作节点在本地执行测试并返回结果。\n\n日志安全访问：对于包含敏感信息的应用日志，可以通过read_logs能力让AI代理在本地进行日志分析，只将脱敏后的分析结果返回，原始日志数据永远不会离开私有环境。\n\n内部服务查询：AI代理可以通过query_deploy_status能力查询内部部署状态，而无需获得直接访问生产环境的权限。\n\n本地模型推理：对于需要特定硬件（如GPU）或私有模型的推理任务，工作节点可以暴露run_local_model能力，让托管代理能够利用本地计算资源。\n\nBYOC产品模式：企业客户可以在自己的基础设施中部署工作节点，构建"自带计算"（Bring Your Own Compute）的AI产品，确保数据处理的合规性和安全性。\n\n当前局限与发展路线图\n\n需要明确的是，epoll-router目前仍处于原型阶段，不适合直接用于生产环境。当前版本的主要限制包括：\n\n- 活跃任务仅存储在内存中，没有持久化队列\n- 流式传输开始后没有重试机制\n- 尚未集成真实的推理后端（如vLLM、TGI或llama.cpp）\n- 仅实现了单个模拟能力\n- 路由策略采用简单的首匹配算法，未考虑延迟和成本优化\n\n项目维护者在README中列出了明确的后续里程碑，包括添加客户端断开时的任务取消机制、请求和协议验证测试、更多实际能力（如测试执行、日志读取、部署查询）、与主流推理引擎的适配器、队列限制和客户端并发控制、Prometheus/OpenTelemetry指标监控、心跳超时处理，以及完善的Worker SDK文档。\n\n技术意义与行业价值\n\nepoll-router的出现代表了AI基础设施架构演进的一个重要方向。随着AI代理越来越多地参与到软件开发和运维工作中，如何在便利性和安全性之间取得平衡成为了一个核心议题。\n\n该项目提出的反向连接模式本质上是一种"零信任网络"思想的实践：不假设任何网络位置是可信的，而是通过加密连接和显式能力声明来建立信任。这种模式不仅适用于AI代理场景，也可以为远程开发、边缘计算、IoT设备管理等场景提供参考。\n\n从更宏观的视角看，epoll-router所探索的架构模式可能预示着AI基础设施的未来形态：云端AI服务与本地计算资源之间形成松耦合的协作关系，数据主权和计算主权得到充分尊重，同时又能享受AI技术带来的效率提升。\n\n结语\n\nepoll-router作为一个原型项目，展示了Rust语言在构建高性能网络基础设施方面的潜力，更重要的是，它为AI代理与私有环境的集成提供了一个值得深入研究的安全架构范式。对于正在探索AI代理部署方案的团队来说，这个项目不仅是一个可用的起点，更是一个引发思考的契机：在AI时代，我们应该如何重新定义网络边界和信任模型。