Agent Relay Fleet完全指南如何跨多台机器运行Agent并可靠投递消息【免费下载链接】relayReal time communication for agents. Wake on message, channels, DMs and actions. Useful for orchestrating agents.项目地址: https://gitcode.com/gh_mirrors/relay35/relayAgent Relay Fleet 是开源项目Agent Relay的集群能力它让你把 Claude Code、Codex、Gemini 等 AI Agent 分布到多台机器上运行并通过统一的消息总线频道、私信、线程实现跨机器的可靠消息投递。每台机器称为一个 Node节点Fleet 调度器会根据节点能力自动决定 Agent 落在哪台机器上即使网络抖动或 Agent 重启消息也不会丢失。核心概念一张图看懂 Fleet 的两层平面 ️Fleet 的设计刻意保持简单所有东西都落在两个平面之一。概念含义所属平面Agent消息网络中的平等节点拥有稳定身份可收发消息、暴露 Action消息平面Node一台命名机器运行 Agent 并上报自己能跑什么计算平面Broker节点上的投递引擎基础设施不是 Agent计算平面LocationRelaycast 把入站消息路由到 Agent 的位置路由细节Capability节点能拉起什么例如spawn:claude、spawn:codex计算平面关键直觉消息网络是扁平的所有 Agent 地位平等跑在哪台机器上只是部署事实不是一种身份关系。每个 Agent 在任一时刻只有一个活跃位置——同名的第二个在线声明者会被直接拒绝从根上避免了双重投递。完整设计依据见设计文档 specs/fleet-delivery.md其中对投递模型、持久化策略的取舍有逐条说明。三步上手把一台机器变成 Fleet 节点 第 1 步注册节点Cloud 托管场景如果你使用 Cloud 部署的 Relaycast先在目标机器上执行agent-relay cloud enroll --token token。它会持久化节点身份node id node token之后启动时自动认领这台机器避免每次启动都生成新身份。第 2 步用节点定义文件启动 Broker在节点目录中放一份节点定义项目自带一个可直接参考的示例examples/relay-node.ts然后用agent-relay node up --config examples/relay-node.ts启动。定义文件声明了三件事节点名与最大 Agent 数如maxAgents: 8能力capabilities比如spawn:claude: spawn(claude)声明我能拉起 Claude触发器triggers比如当#general频道出现echo:前缀的消息时执行echoaction启动后Broker 通过一条控制连接向 Relaycast 注册节点、上报能力并开始按 10~15 秒的间隔发送心跳。第 3 步把 Agent 派到集群里在任意一台已连入工作区的机器上执行agent-relay fleet spawn claude --name worker-1 --task 修复登录模块的竞态问题 --node gpu-box-1如果省略--node调度器会自动挑选有能力 在线 有空闲容量的节点并优先派往负载最低的一台。支持的目标写法有三种指定节点名必须派到那里能力不匹配会明确报错capability_mismatch而不是悄悄降级self派到发起者所在的节点共享工作目录的常见场景省略最少负载调度消息为什么可靠读懂有界持久邮箱 ✉️这是 Fleet 与普通把消息发出去就行方案的本质区别。每条消息在 Relaycast 侧有一个状态机queued排队──投递──▶ delivered已投递──确认──▶ acked已确认/已读 └──超过 TTL──▶ dead-letter死信并通知发送者由此得到四条对新手非常实用的保证至少一次投递 按消息 ID 去重网络重传不会产生重复消息Agent 端按单调递增的序号seq接收乱序和缺口会被自动识别。有界持久化bounded-durableAgent 临时不可达断网、重启中时消息在邮箱里保留一个 TTL 期恢复后补投而不是无限堆积状态。死信必通知TTL 到期仍未送达的消息进入死信同时向发送方发出delivery_failed事件——绝不静默丢弃。重启不丢进度支持会话恢复resumable的 Agent 重启后Broker 会带着持久化的确认游标重新同步只补投未确认的尾部消息不从头重放。换句话说持久状态全部在 Relaycast唯一事实来源Broker 只保持内存态——Broker 崩溃后重新注册时服务端会先回传权威的确认游标再补发消息。这套游标恢复握手的完整规则同样写在 specs/fleet-delivery.md 的 §8.4。调度与容错节点宕机时发生什么 ️Fleet 的 spawn 走的是通用的 Action 调用机制契约是幂等 至少一次 对账每次调用带invocationId作为幂等键重试同一 ID 不会重复拉起 Agent派发到某节点后超时或节点失联 →自动改派到另一个有能力的节点沿用同一个 invocationId节点恢复后重新上报 Agent 清单inventory sync与调度器对账谁先完成谁生效重复副本会被释放这意味着单点宕机不会阻塞任务流消息排队等待、任务改派、恢复后自动对账整个集群对外表现为一个消息网络。日常运维4 个最常用命令 命令用途agent-relay fleet nodes列出工作区内的所有节点、能力与在线状态--all含离线历史agent-relay fleet agent list --pretty跨节点查看每个节点上存活的 Agent并与工作区名册做对照agent-relay fleet spawn cli --name X --task Y在集群中拉起 Agent可加--sandbox直接开一台云端沙箱节点agent-relay fleet release name释放并回收 Agent 资源其中--sandbox是新手友好的捷径它会自动预配一台云端 Daytona 沙箱节点、挂载工作区代码然后把 Agent 拉起来——不需要你自己准备任何机器。命令实现细节可参考packages/cli/src/cli/commands/fleet.ts节点服务端的运行逻辑在packages/fleet/src/serve-node.ts。如何验证你的 Fleet 配置是否正确 ✅项目自带一套双节点端到端测试tests/e2e/fleet/它会真实启动两个节点并覆盖这些关键场景可以当作自检清单使用节点启动注册、能力查询按 capability 过滤节点跨节点 Action 派发与确认定向 spawn、能力路由 spawn、最少负载调度节点半死状态下调用改派 重启对账不会重复认领投递序号单调、去重、断点续投邮箱 TTL 到期 → 死信 →发送方收到通知这套矩阵的完整说明见tests/e2e/fleet/README.mdRust 侧 Broker 的 Fleet 运行时在crates/broker/src/runtime/fleet.rs。小结什么时候该上 Fleet 单机够用→ 直接用agent-relay node up本地跑 Broker 即可需要异构算力一台跑 Claude、一台跑 Codex、一台只跑重型任务→ 用 Fleet 按能力路由任务不能丢长时间任务、消息驱动的工作流→ 有界持久邮箱 死信通知兜底不想管机器→fleet spawn --sandbox一键云沙箱Fleet 的设计哲学一句话总结消息网络保持扁平算力按节点声明可靠性交给有界持久邮箱。理解了这三点跨机器编排 Agent 就不再是复杂问题。【免费下载链接】relayReal time communication for agents. Wake on message, channels, DMs and actions. Useful for orchestrating agents.项目地址: https://gitcode.com/gh_mirrors/relay35/relay创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
