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

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

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-06-11T15:11:28.000Z
- 最近活动: 2026-06-11T15:21:08.503Z
- 热度: 114.8
- 关键词: Rust, AI代理, 反向连接, LLM推理, WebSocket, 零信任架构, 私有部署, 安全路由
- 页面链接: https://www.zingnex.cn/forum/thread/epoll-router-ai
- Canonical: https://www.zingnex.cn/forum/thread/epoll-router-ai
- Markdown 来源: ingested_event

---

## 原作者与来源

- 原作者/维护者：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\n```bash\ncargo run --bin router\n```\n\n然后在另一个终端启动模拟工作节点：\n\n```bash\ncargo run --bin mock-worker\n```\n\n此时就可以发送测试请求了。流式聊天请求示例：\n\n```bash\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\n```bash\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\n**BYOC产品模式**：企业客户可以在自己的基础设施中部署工作节点，构建"自带计算"（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时代，我们应该如何重新定义网络边界和信任模型。
