AgentsMesh 架构深度剖析控制面与数据面分离如何支撑10万Runner并发【免费下载链接】AgentsMeshThe AI Agent Workforce Platform. Run a hundred AI coding agents across your own machines — schedule, isolate, and steer them all from one console.项目地址: https://gitcode.com/gh_mirrors/ag/AgentsMeshAgentsMesh 是一个 AI Agent 劳动力平台其核心架构通过控制面与数据面分离的设计——编排指令走 gRPC mTLS终端字节流经无状态 Relay 集群转发——让后端完全不接触 PTY 流量从而能够支撑10 万 Runner 并发连接、30 万活跃 AgentPod 的大规模场景。 一句话理解控制面管做什么数据面管搬数据。两者解耦后任何一个环节都可以独立横向扩展。为什么10万并发必须拆分控制面与数据面想象一个场景10 万台用户机器上的 Runner 同时在线每台平均跑 3 个 AI 编码 AgentClaude Code、Codex CLI、Gemini CLI 等每个 Agent 都在往终端里哗哗地吐输出。如果所有流量都压在一个 Backend 上会立刻撞墙 瓶颈规模估算后果单全局锁连接管理10 万连接抢 1 把锁延迟放大 10-100 倍心跳写库3,333 次/秒 UPDATE数据库被打穿终端回滚缓冲常驻内存30 万 Pod × 100KB ≈ 30GB内存爆炸单 goroutine 广播通道 buffer 仅 256高并发下阻塞这些账团队在 RFC-001: 10 万 Runner 规模架构设计 里算得非常清楚总内存需求约 50GB数据库 QPS 约 2 万/秒带宽 500Mbps-1Gbps。靠一台机器堆配置扛不住必须靠架构拆分。整体架构谁负责什么AgentsMesh 的服务端只有三个核心组件详见 README.md 的架构章节┌──────────┐ gRPC mTLS (控制面) ┌──────────┐ │ Runner │───────────────────────►│ Backend │─── PostgreSQL / Redis │(用户机器) │ │ (Go) │ └────┬─────┘ └──────────┘ │ WebSocket (数据面) ▼ ┌──────────┐ 终端字节流 pub/sub ┌──────────┐ │ Relay │◄──────────────────────►│ 前端 │ │ 集群 │ │ Web/iOS │ └──────────┘ └──────────┘Backend控制面API 服务器负责认证、组织/用户管理、Pod 生命周期、工单、计费以及签发 Runner 证书的 PKI。Relay数据面无状态 WebSocket 中继负责终端数据在 Runner 与客户端之间的低延迟转发。Runner执行面用户自托管的守护进程连接 Backend、拉起隔离的 PTY Pod 跑真正的 Agent。关键结论藏在 README.md 里The backend never touches a single PTY byte — which is what lets the fleet scale.后端不碰任何一个终端字节这正是集群能扩规模的原因。控制面gRPC mTLS 的双向信任控制面解决的是信任问题。Runner 跑在用户自己的机器上传统token 认证 明文 WebSocket方案有三个致命弱点伪造服务端、伪造 Runner、Token 泄露难撤销。AgentsMesh 的答案是 RFC-002: gRPC mTLS Runner 通信协议升级私有 Root CABackend 内置 CA为每个 Runner 签发 90 天有效期的 X.509 客户端证书双向验证Runner 只信任 AgentsMesh 私有 CA不信任 Lets Encrypt 等公共 CABackend 也只认私有 CA 签发的证书——伪造服务端、伪造客户端、中间人攻击全部被挡开销几乎为零Runner 用 gRPC 长连接mTLS 握手只发生一次额外 CPU 开销 1%。协议定义在 proto/runner_api/ 目录下控制指令创建 Pod、发送指令、状态上报全部走 gRPC 双向流语义清晰、天然支持流式。数据面无状态 Relay 集群为何能无限扩展数据面是最容易成为瓶颈的部分——终端输出是典型的高吞吐、低价值流量。RFC-001 实测一个 Claude Code 会话单帧就约 880KB带宽消耗可达 ~800KB/s。Relay 的设计思路是把状态从数据通路中彻底剥离Channel 模型每个 Pod 对应一个逻辑通道PublisherRunner 侧与 Subscriber浏览器侧通过 WebSocket 挂到同一通道上。核心实现见 relay/internal/channel/channel_manager.go无状态节点单个 Relay 节点不保存业务数据只维护连接映射。任何节点宕机客户端重连到任意节点即可恢复——水平扩容就是加机器与 Backend 轻量协同Relay 通过内部 API 向 Backend 上报通道生命周期如 relay/internal/backend/client.go 中的注册与回调但终端字节流从不经过 Backend。配合 RFC-004: 终端输出带宽优化 中的 VirtualTerminal Serialize 模式用 ANSI CUF 游标序列压缩连续空格单帧体积再降 30-50%数据面的带宽压力进一步减半。10万并发下的四项关键工程优化架构拆分解决了流量走向RFC-001 中还给出了 Backend 内部的四把手术刀 连接管理分片锁将 backend/ 中 ConnectionManager 的单一全局sync.RWMutex拆成256 个分片runnerID % 256定位分片——锁竞争直接降低 256 倍多核 CPU 终于能发力。 心跳批量聚合心跳不再来一条写一条实时状态先写 Redis60s TTL数据库写入改为5 秒批量聚合写压从 3,333/秒 降到 ~667/秒。 Scrollback LRU Redis 卸载终端回滚缓冲从30 万 Pod 全部常驻内存30GB改为LRU 缓存 1 万条热数据约 1GB 冷数据自动落 Redis内存占用直降 30 倍。 WebSocket Hub 分片单一 Hub 的广播 goroutine 拆成 64 个分片按 podKey 哈希路由广播并发度提升 64 倍同时单个 Pod 的消息顺序仍然有序。部署蓝图三 Region 扛住10万Runner按单 Backend 实例承载约 1 万连接的原则10 万 Runner 的推荐布局是RegionRunner 分布Backend 实例us-east-140,0006eu-west-135,0005ap-northeast-125,0004每个 Region 内K8s 集群 NGINX Ingress按org_id一致性哈希路由保证同一组织的所有请求落在同一 Backend跨实例通信直接归零 Redis Cluster PostgreSQL 主从1 主 2 从读写分离。Org 级路由隔离是整个方案最巧妙的洞察只要同一 Org 的请求路由到同一实例就不需要任何跨实例 Pub/Sub、Pod 位置发现或终端数据转发——架构复杂度大幅降低。分三阶段落地不冒进阶段目标规模关键动作周期Phase 11 万 Runner分片锁、连接池扩容、Redis 状态缓存、监控接入2 周Phase 25 万 Runner心跳聚合、LRU 缓冲、读写分离、Hub 分片、多实例部署3 周Phase 310 万 RunnerRedis Cluster、多 Region、索引优化、全链路压测4 周性能红线也很明确心跳延迟 P99 500ms、终端数据延迟 P99 100ms、故障恢复 30s、可用性 99.9%。总结分离不是目的可扩展才是回顾 AgentsMesh 这套架构本质回答了一个问题当 10 万个终端同时在屏幕上滚动字节时系统如何不崩控制面用gRPC mTLS把信任与编排收拢到 Backend指令流量小而稳定数据面用无状态 Relay 集群承接字节洪流扩容即加节点内部再用分片锁、批量写、LRU 卸载、Hub 分片四板斧消除单点最后用Org 一致性哈希把跨实例通信成本打到零。这套控制面/数据面分离的思路对所有需要大规模长连接 高吞吐数据流的系统物联网、实时协作、终端服务都具有很强的借鉴价值。想深入细节可以完整阅读 docs/rfc/ 目录下的 RFC-001 至 RFC-005。【免费下载链接】AgentsMeshThe AI Agent Workforce Platform. Run a hundred AI coding agents across your own machines — schedule, isolate, and steer them all from one console.项目地址: https://gitcode.com/gh_mirrors/ag/AgentsMesh创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AgentsMesh 架构深度剖析：控制面与数据面分离如何支撑10万Runner并发
AgentsMesh 架构深度剖析控制面与数据面分离如何支撑10万Runner并发【免费下载链接】AgentsMeshThe AI Agent Workforce Platform. Run a hundred AI coding agents across your own machines — schedule, isolate, and steer them all from one console.项目地址: https://gitcode.com/gh_mirrors/ag/AgentsMeshAgentsMesh 是一个 AI Agent 劳动力平台其核心架构通过控制面与数据面分离的设计——编排指令走 gRPC mTLS终端字节流经无状态 Relay 集群转发——让后端完全不接触 PTY 流量从而能够支撑10 万 Runner 并发连接、30 万活跃 AgentPod 的大规模场景。 一句话理解控制面管做什么数据面管搬数据。两者解耦后任何一个环节都可以独立横向扩展。为什么10万并发必须拆分控制面与数据面想象一个场景10 万台用户机器上的 Runner 同时在线每台平均跑 3 个 AI 编码 AgentClaude Code、Codex CLI、Gemini CLI 等每个 Agent 都在往终端里哗哗地吐输出。如果所有流量都压在一个 Backend 上会立刻撞墙 瓶颈规模估算后果单全局锁连接管理10 万连接抢 1 把锁延迟放大 10-100 倍心跳写库3,333 次/秒 UPDATE数据库被打穿终端回滚缓冲常驻内存30 万 Pod × 100KB ≈ 30GB内存爆炸单 goroutine 广播通道 buffer 仅 256高并发下阻塞这些账团队在 RFC-001: 10 万 Runner 规模架构设计 里算得非常清楚总内存需求约 50GB数据库 QPS 约 2 万/秒带宽 500Mbps-1Gbps。靠一台机器堆配置扛不住必须靠架构拆分。整体架构谁负责什么AgentsMesh 的服务端只有三个核心组件详见 README.md 的架构章节┌──────────┐ gRPC mTLS (控制面) ┌──────────┐ │ Runner │───────────────────────►│ Backend │─── PostgreSQL / Redis │(用户机器) │ │ (Go) │ └────┬─────┘ └──────────┘ │ WebSocket (数据面) ▼ ┌──────────┐ 终端字节流 pub/sub ┌──────────┐ │ Relay │◄──────────────────────►│ 前端 │ │ 集群 │ │ Web/iOS │ └──────────┘ └──────────┘Backend控制面API 服务器负责认证、组织/用户管理、Pod 生命周期、工单、计费以及签发 Runner 证书的 PKI。Relay数据面无状态 WebSocket 中继负责终端数据在 Runner 与客户端之间的低延迟转发。Runner执行面用户自托管的守护进程连接 Backend、拉起隔离的 PTY Pod 跑真正的 Agent。关键结论藏在 README.md 里The backend never touches a single PTY byte — which is what lets the fleet scale.后端不碰任何一个终端字节这正是集群能扩规模的原因。控制面gRPC mTLS 的双向信任控制面解决的是信任问题。Runner 跑在用户自己的机器上传统token 认证 明文 WebSocket方案有三个致命弱点伪造服务端、伪造 Runner、Token 泄露难撤销。AgentsMesh 的答案是 RFC-002: gRPC mTLS Runner 通信协议升级私有 Root CABackend 内置 CA为每个 Runner 签发 90 天有效期的 X.509 客户端证书双向验证Runner 只信任 AgentsMesh 私有 CA不信任 Lets Encrypt 等公共 CABackend 也只认私有 CA 签发的证书——伪造服务端、伪造客户端、中间人攻击全部被挡开销几乎为零Runner 用 gRPC 长连接mTLS 握手只发生一次额外 CPU 开销 1%。协议定义在 proto/runner_api/ 目录下控制指令创建 Pod、发送指令、状态上报全部走 gRPC 双向流语义清晰、天然支持流式。数据面无状态 Relay 集群为何能无限扩展数据面是最容易成为瓶颈的部分——终端输出是典型的高吞吐、低价值流量。RFC-001 实测一个 Claude Code 会话单帧就约 880KB带宽消耗可达 ~800KB/s。Relay 的设计思路是把状态从数据通路中彻底剥离Channel 模型每个 Pod 对应一个逻辑通道PublisherRunner 侧与 Subscriber浏览器侧通过 WebSocket 挂到同一通道上。核心实现见 relay/internal/channel/channel_manager.go无状态节点单个 Relay 节点不保存业务数据只维护连接映射。任何节点宕机客户端重连到任意节点即可恢复——水平扩容就是加机器与 Backend 轻量协同Relay 通过内部 API 向 Backend 上报通道生命周期如 relay/internal/backend/client.go 中的注册与回调但终端字节流从不经过 Backend。配合 RFC-004: 终端输出带宽优化 中的 VirtualTerminal Serialize 模式用 ANSI CUF 游标序列压缩连续空格单帧体积再降 30-50%数据面的带宽压力进一步减半。10万并发下的四项关键工程优化架构拆分解决了流量走向RFC-001 中还给出了 Backend 内部的四把手术刀 连接管理分片锁将 backend/ 中 ConnectionManager 的单一全局sync.RWMutex拆成256 个分片runnerID % 256定位分片——锁竞争直接降低 256 倍多核 CPU 终于能发力。 心跳批量聚合心跳不再来一条写一条实时状态先写 Redis60s TTL数据库写入改为5 秒批量聚合写压从 3,333/秒 降到 ~667/秒。 Scrollback LRU Redis 卸载终端回滚缓冲从30 万 Pod 全部常驻内存30GB改为LRU 缓存 1 万条热数据约 1GB 冷数据自动落 Redis内存占用直降 30 倍。 WebSocket Hub 分片单一 Hub 的广播 goroutine 拆成 64 个分片按 podKey 哈希路由广播并发度提升 64 倍同时单个 Pod 的消息顺序仍然有序。部署蓝图三 Region 扛住10万Runner按单 Backend 实例承载约 1 万连接的原则10 万 Runner 的推荐布局是RegionRunner 分布Backend 实例us-east-140,0006eu-west-135,0005ap-northeast-125,0004每个 Region 内K8s 集群 NGINX Ingress按org_id一致性哈希路由保证同一组织的所有请求落在同一 Backend跨实例通信直接归零 Redis Cluster PostgreSQL 主从1 主 2 从读写分离。Org 级路由隔离是整个方案最巧妙的洞察只要同一 Org 的请求路由到同一实例就不需要任何跨实例 Pub/Sub、Pod 位置发现或终端数据转发——架构复杂度大幅降低。分三阶段落地不冒进阶段目标规模关键动作周期Phase 11 万 Runner分片锁、连接池扩容、Redis 状态缓存、监控接入2 周Phase 25 万 Runner心跳聚合、LRU 缓冲、读写分离、Hub 分片、多实例部署3 周Phase 310 万 RunnerRedis Cluster、多 Region、索引优化、全链路压测4 周性能红线也很明确心跳延迟 P99 500ms、终端数据延迟 P99 100ms、故障恢复 30s、可用性 99.9%。总结分离不是目的可扩展才是回顾 AgentsMesh 这套架构本质回答了一个问题当 10 万个终端同时在屏幕上滚动字节时系统如何不崩控制面用gRPC mTLS把信任与编排收拢到 Backend指令流量小而稳定数据面用无状态 Relay 集群承接字节洪流扩容即加节点内部再用分片锁、批量写、LRU 卸载、Hub 分片四板斧消除单点最后用Org 一致性哈希把跨实例通信成本打到零。这套控制面/数据面分离的思路对所有需要大规模长连接 高吞吐数据流的系统物联网、实时协作、终端服务都具有很强的借鉴价值。想深入细节可以完整阅读 docs/rfc/ 目录下的 RFC-001 至 RFC-005。【免费下载链接】AgentsMeshThe AI Agent Workforce Platform. Run a hundred AI coding agents across your own machines — schedule, isolate, and steer them all from one console.项目地址: https://gitcode.com/gh_mirrors/ag/AgentsMesh创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考