最近我在把 HelloAGENTS 的部署从 standby 模式切到 global 模式，本来以为只是改一行 mode 配置的事，结果前前后后折腾了两天。搜资料的时候看到两条跟“global”相关的热搜：一条是 Windows 的 netsh interface tcp show global，另一条是 GIS 圈子里传的 Global Mapper。同一个词在不同软件栈里含义差了十万八千里，而 HelloAGENTS 自己的 standby 和 global 两种部署模式，边界也比官方文档写的模糊得多。这篇不打算复述文档，主要记录我实际踩过的边界——什么时候该用 standby，什么时候必须切 global，标题里那个“还是”我最后是怎么答的，以及迁移过程中真正容易出问题的地方在哪。
1. 一个 Agent 编排框架为什么要设计两套模式
1.1 HelloAGENTS 解决的核心问题
HelloAGENTS 在概念上是一个 Agent 编排运行时。你可以把若干个 Agent 程序用配置文件描述出来，指定它们的输入输出、依赖关系、超时重试，然后框架负责在合适的时机拉起 Agent、把消息按拓扑送进正确的节点，再收集结果返回给调用方。如果只是多个接口循环调用，其实不需要一个专门的框架；但当你手上有十几个 Agent、它们之间还互相依赖时，消息怎么流转、谁先执行、失败了怎么重试，都会变成写不完的 if else。
打个比方，HelloAGENTS 做的事情像一个“任务车间调度员”：接单、分单、盯进度、收答卷。出问题的不是单个 Agent 的能力，而是它们在什么时机、用多少资源、按什么顺序被调度。这个调度过程的不同实现策略，最后就落成了 standby 和 global 两套部署模式。
1.2 两套模式在生命周期管理上的根本差异
standby 模式的核心思想是：Agent 进程默认不占资源，按需拉起，跑完任务后进入待机或者直接退出。它服务的场景是低频、资源敏感，比如边缘盒子上的定时报表 Agent，一天也就被调用三五次，没必要时刻让进程占着内存。
global 模式的核心思想则是：所有 Agent 作为常驻进程注册到一个统一控制面，控制面维护路由表和健康状态，消息进来自动分发给合适的 worker。它服务的是高频访问、多客户端并行、需要低延迟响应的在线场景。
两者的差异不只是“进程是否常驻”这一个点，它会扩散到后面一整条链路上：
- 状态：standby 默认无共享状态，global 默认有共享上下文；
- 路由：standby 靠本机信号拉起，global 靠控制面路由分发；
- 容错：standby 的单点自愈能力很弱，global 有健康检查和故障转移；
- 运维：standby 可以只跑一个进程，global 至少要拉起控制面和 worker 两组进程；
- 日志：standby 按任务生命周期出日志，global 的日志必须做跨进程聚合。
我在切到 global 模式之前，一直以为这两者只是配置里的一个枚举值不同，后来才发现 mode 字段决定的是启动器的一整套初始化流程，业务代码不用改，但你对运行时的一切假设都得换一套。
1.3 配置文件里第一个分叉点：service.mode
我用的这个版本里，模式选择就藏在配置文件的 service.mode 字段里：
service { mode = "standby" # 可选 standby / global profile = "dev" } standby { # 空闲多久后挂起，单位毫秒 idle-timeout-ms = 30000 # 是否允许按需唤醒 wake-on-demand = true # 最多允许的挂起进程数 max-idle-processes = 4 } global { # 控制面地址 coordinator-address = "127.0.0.1:7601" # worker 心跳间隔 heartbeat-interval-ms = 5000 # 路由策略：weighted-round-robin / hash-by-agent-id route-policy = "weighted-round-robin" }第一眼看上去，这只是一个枚举值，但它决定了 HelloAGENTS 启动器走“本地队列 + 按需进程”的链路，还是“注册控制面 + 心跳上报”的链路。举个例子，standby 模式下你不需要关心 coordinator-address，配了也不会报错，但它完全不生效；而 global 模式下如果没配心跳间隔，控制面默认按 5 秒一次来判定 worker 存活，日志里会不断出现 missed heartbeat 警告。
提示：如果你的业务代码里用了模块级全局变量，切到 global 模式前一定要检查。standby 模式下任务天然串行，全局变量可能“碰巧没问题”；global 模式下多个 worker 并行，全局变量会成为数据串台的重灾区。这个坑我后面单独讲。
另外，模式还会影响日志和监控。standby 模式下进程生命周期短，日志一般按一次任务一个文件轮转；global 模式下进程常驻，日志需要按进程维度聚合，否则排查问题时你会发现同一批任务散落在几十个文件里。这个操作上的差异，文档往往不会细说，但实际用起来非常影响效率。
2. 本地实测：standby 模式的资源占用和唤醒细节
2.1 一台 8GB 内存的机器上，standby 到底省了什么
我在自己的开发机上做过一次粗测：4 核 8GB 内存，系统里跑着一个 HelloAGENTS 的 dev 实例，注册了 6 个 Agent，任务量每天几百次。standby 模式下空闲时除了一个常驻的控制进程，其余 Agent 进程都处于挂起状态，总内存占用不到 300MB；切到 global 模式后，6 个 worker 常驻，内存占用直接到 1.2GB 左右。对本地开发来说这个差距不算致命，但对只有 2GB 内存的云服务器来说，差别就很明显。
冷启动开销也要算进去。standby 模式每个任务首次唤起需要 200 到 800 毫秒，取决于 Agent 启动时要加载什么；global 模式因为 worker 常驻，端到端延迟通常只有 10 到 50 毫秒。我当时测了一个需要加载外部模型的 Agent，standby 冷启动接近 1.8 秒，global 模式下因为进程一直活着，首次请求也就几十毫秒。如果你的场景是纯跑批任务，这 1.8 秒摊到几分钟的任务时长里根本感知不到；但如果是在线接口，这个延迟直接决定能不能用。
2.2 唤醒机制：端口唤醒和文件事件唤醒
standby 模式不是简单的“一直空转等消息”，它有两种常见的唤醒方式：端口唤醒和文件事件唤醒。端口唤醒是指 Agent 挂起前保留一个本地监听端口，任务消息到达时由启动器把进程拉起；文件事件唤醒是 Agent 监听某个目录的文件变化，比如任务描述文件被写入后触发执行。
我在 Linux 环境下一般推荐端口唤醒，因为文件事件唤醒容易遇到权限和 inotify 上限的问题。有一次我把工作目录放在 /data 下，服务用 systemd 托管，运行用户是个普通账号，结果 Agent 一直没被唤醒，任务全部积压。排查了一圈才发现是目录权限不对，那个用户压根没有监听该目录的权限。换成端口唤醒之后问题立刻消失。
如果你不得不用文件事件唤醒，建议提前确认三件事：目录属主和运行用户是否一致、inotify 实例数量限制、有没有别的进程在抢同一目录的监听。这三件事任何一个出了问题，表现都是“任务不执行”，但日志里不一定有明确报错，排查成本很高。
2.3 standby 适合的两个“标准画像”
什么场景下我会坚持用 standby？主要是两个画像：
- 个人开发调试。进程按需拉起，断点、日志都跟单次任务绑定，定位问题非常舒服。改完配置直接重启控制进程就好，不用维护一堆常驻 worker。
- 低频自动化任务。每天跑几次、每次几十秒到几分钟的数据采集、报表生成，机器资源有限，不想为低频任务常驻一堆 worker。
这两个画像的共性就是“不需要持续在线”。一旦你的场景变成 7×24 小时有人调用，standby 的省资源优势就会被冷启动和并发缺口抵消。这也是很多项目从原型走向产品化时的第一个转折点——调用来得越来越密，直到某一天它不再适合“按需拉起”了。
3. global 模式的全局视图：路由、状态与故障转移
3.1 控制面维护的“路由表”长什么样
global 模式下，HelloAGENTS 会有一个控制面。每个 worker 启动时向控制面注册，上报自己的 Agent 列表、健康状态、当前负载。控制面把这些信息汇总成一张动态路由表：
| Agent 名称 | worker 地址 | 健康状态 | 当前负载 | 权重 |
|---|---|---|---|---|
| report-agent | 192.168.1.10:7701 | healthy | 3 | 2 |
| report-agent | 192.168.1.11:7701 | healthy | 5 | 2 |
| extract-agent | 192.168.1.10:7702 | degraded | 20 | 1 |
消息进来时，控制面根据 route-policy 选择一个 worker 派发任务。默认策略是加权轮询，也可以按 Agent id 做哈希，保证同一来源的请求落到同一个 worker，对本地缓存的命中率更友好。
对比 standby 模式里“任务从本地队列直接拉起进程”的模型，global 的模型多了两层东西：注册和调度。这也是配置里 coordinator-address 和 route-policy 两个字段存在的意义。如果你只在一台机器上跑一个 worker，这个路由表没什么存在感；但只要 worker 数量超过两个，路由策略的选择就会直接影响请求分布和缓存命中率。
3.2 “全局状态”到底指什么，为什么它既是能力也是风险
global 模式被称为 global，不只是所有进程常驻，更重要的是它可以维护一份跨进程可访问的全局状态。比如多个 worker 之间共享一个内存缓存、一份在线状态表、一个任务去重集合。这个特性用得好能显著降低重复计算；用得不好，就是我在迁移过程中遇到的数据串台问题。
判断标准我给一个简单的：业务需要共享的状态，放进 Agent context；实现细节状态，永远不要用模块级变量。standby 模式下任务天然隔离，进程一退出所有实现细节自动清空，掩盖了一堆代码层面的坏味道。切到 global 后，进程常驻、任务并发，那些“碰巧没问题”的模块级缓存、临时变量、静态标志位全都成了定时炸弹。我在后面会详细复盘一次因为全局变量串台导致的通知错发事故。
3.3 故障转移与健康检查
global 模式的另一个关键能力是故障转移。worker 每 5 秒（在配置里是 heartbeat-interval-ms）上报一次心跳，控制面连续几次没收到心跳就标记为 unhealthy，不再派发新任务；新 worker 注册后自动加入路由表。这个机制的价值在于，你不需要在业务代码里写任何故障判断逻辑，只要保证 Agent 是无状态的，扩容和缩容就变成了加节点、减节点这么简单。
但要注意，多节点部署时控制面本身也要做高可用。我一般会起两个控制面节点配合外部存储做选主。这一步的运维复杂度和 standby 单进程启动相比直接上了一个台阶，也是很多人“明明能用 standby 却非要 global”之后后悔的原因。所以在选型时，不要只盯着能力和弹性，也要把自己未来的运维精力算进去。
4. 边界判定：一张清单帮你决定选 standby 还是 global
4.1 先问自己四个问题
与其背文档，不如直接用问题逼自己做决策：
- 你的任务是否要求低延迟响应？如果是，直接排除 standby，因为冷启动 200 毫秒以上的延迟在在线接口场景里很难接受。
- 你的节点是否要横向扩容？如果是，global 的注册发现机制更顺，standby 的按需拉起模式在多节点下几乎没法做负载均衡。
- 你的机器资源是否紧张，且任务频率极低？如果是，standby 的优势很明显，没必要让一堆常驻进程挤压其他业务。
- 你的开发团队是否只有你一个人，且主要在本机联调？如果是，别急着上 global，先让项目业务跑起来更重要。
这四个问题没有标准答案，核心是找到“临界点”。就以我自己的项目为例：最初只有我一个人用，任务每天几十次，standby 完全够用；后来加了两个同事，调用频率从每天几十次涨到每分钟上千次，并且要求接口响应在 200 毫秒以内，原来 standby 的冷启动就撑不住了。
4.2 一张对比表把两边摆到桌面上
| 对比项 | standby 模式 | global 模式 |
|---|---|---|
| 资源占用 | 低，按需拉起 | 高，常驻进程 |
| 请求延迟 | 高，冷启动明显 | 低，worker 常驻 |
| 并发能力 | 弱，单机单实例 | 强，可水平扩容 |
| 状态共享 | 没有跨进程共享 | 有，共享上下文 |
| 容错能力 | 弱，进程退出即完 | 强，健康检查+故障转移 |
| 运维复杂度 | 低，一个进程的事 | 高，控制面+注册后端 |
| 适用场景 | 开发调试、低频批任务 | 在线服务、多租户、高并发 |
这张表不是用来“选最右侧的”，而是用来判断你的真实需求落在哪一端。如果项目还在原型阶段，我会直接选 standby，因为迭代快、重启成本低；如果项目已经确定要作为团队服务对外提供，尽早规划 global 反而是省钱的做法。
4.3 “边界”最容易踩的位置：你以为的中等流量
很多项目的尴尬不是极低频或极高并发，而是“中间地带”——调用量不算高，但希望响应快一点；机器不多，但又想容错。这个区域最考验配置功力，也是大部分人在 standby 和 global 之间反复横跳的原因。
我的建议是：如果流量暂时不高，但明确三个月内会涨，直接上 global。原因是 late migration 的隐藏成本往往不在配置切换本身，而在日志聚合、监控告警、路由策略调优这些配套改造上。早一点把这些基础能力做掉，后面流量起来的时候你会感谢当初的决定。
5. 迁移实录：从 standby 切到 global 踩过的三个坑
5.1 第一个坑：业务代码里的全局变量串台
切 global 之后大概一周，我们收到了一个线上反馈：通知消息发到了错误的用户手里。这个 Agent 是一个简单的“到期提醒”处理节点，逻辑是从消息里取用户 id，组装文本，发到消息队列。排查了很久才发现，某个工具模块里用一个模块级变量存了“当前处理用户 id”。standby 模式下同时只有一个任务在跑，这个变量碰巧没问题；global 模式下一并发，A 任务的用户 id 就被 B 任务覆盖了。
修复方式不复杂：把用户 id 全部改成从 Agent context 里读取，模块级变量彻底删除。但这个 bug 的排查过程很痛苦，因为错误是间歇性的，看起来毫无规律。这个教训让我后来定了一条规矩：模式切换不是改配置，而是逼你把所有隐式状态显式化。只要代码里出现模块级可变变量，就先当坏味道处理，再去谈部署模式。
5.2 第二个坑：systemd 环境下的证书和环境变量
迁移时我把服务用 systemd 托管了，结果 global 模式下控制面拉不起 worker，排查链路大致如下：
- 先看控制面日志，发现没有任何 worker 注册；
- 手动执行 worker 启动命令，能启动，但注册还是失败；
- 查看注册后端连接信息，发现配置里 redis 地址没加密码，连不上；
- 加上密码后，worker 注册成功，但心跳又报错；
- 最终定位是 systemd 环境下环境变量没传全，控制面与 worker 之间证书路径不一致，导致双向认证失败。
整个过程花了半天。教训是：迁移 global 前，先把控制面、worker、注册后端三者的网络连通性和认证信息写成一份检查清单，逐项打勾确认。特别是用了 systemd、容器、密钥管理服务之后，环境变量和证书目录的传递链路很容易出问题，而这些在本地手动启动时根本不会暴露。
5.3 第三个坑：日志聚合方式必须一起换
standby 模式按任务输出日志文件，一个任务对应一个文件，出问题直接翻对应文件就行。切到 global 后进程常驻，日志文件不断追加，如果还沿用原来的文件轮转逻辑，会出现日志截断、跨进程 task 串联不起来的情况。
我后来把日志输出统一改成 JSON 格式，并强制写入 requestId，再按 requestId 聚合日志，排查效率才真正提上来。这一步听起来跟部署模式无关，但它恰恰是 global 模式能不能用好的关键配套。没有跨进程的 trace 能力，global 模式下的分布式排查会特别痛苦。
5.4 灰度切换与回滚点
我在实际迁移时没有一次性全切。过程是：
- 保留 standby 配置的完整备份；
- 新起一套 global 环境，跑通 smoke test，确认所有 Agent 都能注册、调度、返回结果；
- 通过网关将 10% 流量切到 global；
- 观察 10 分钟无异常后切到 50%；
- 全部切完后，再保留 standby 环境一个完整任务周期，确认无异常后才回收旧资源。
回滚只要把网关流量指回 standby 并重启即可，但前提是 standby 环境没有被回收。所以迁移期间不要急着关掉旧环境，至少等新环境稳定一个任务周期。我在迁移过程中犯过的最大错误是“想尽快清理干净”，幸好当时忍住了，因为 global 环境的日志聚合问题恰恰是切完 100% 流量后才暴露出来的。
6. 我的最终选择与补充建议
6.1 最终答案：开发机 standby，生产链路 global
对我来说，标题里那个选择题的最终答案是：开发机保持 standby，生产链路切 global。不是“二选一”，而是把它们放在各自合适的位置。开发调试时 standby 的重启成本低、日志干净、不用维护常驻进程；生产环境面对团队使用时，global 的低延迟、可扩容、健康检查带来的收益远大于它多出来的运维负担。
如果你还在犹豫，我的建议是别把这个问题当成一个永久决策。模式是配置，不是建筑设计。只要业务代码保持状态显式化、 Agent 无状态化，从 standby 迁到 global 的成本其实很低。真正昂贵的不是模式切换本身，而是在错误模式下硬撑的运维成倍增加。
6.2 如果你的团队规模很小，可以再等等
如果你的团队只有一两个人、项目还没有外部用户，我建议先不要上 global。原因不是 global 不好，而是它引入的控制面、注册后端、心跳监控，在你只有一两个消费者时都算过度设计。等流量上来后再迁移，只要迁移前把配置文件、环境变量、日志方案这三件事想清楚，成本是可控的。我见过太多项目在开发阶段就上了全套集群方案，结果半年过去了，流量还没到需要集群的程度，所有人都在维护基础设施。
6.3 一个值得尝试的扩展：把 standby 的按需能力做成自动伸缩
我个人比较看好的一种组合是：以 global 模式为主，但对低频 Agent 保留 standby 的按需拉起策略。比如夜间报表 Agent 在晚上 8 点到凌晨 2 点之间使用频率高，其他时间可以缩容到零。这套思路在容器环境里就是结合调度器做自动伸缩。
最后再分享一个小技巧：选模式之前，先把你系统里最耗资源的那个 Agent 找出来单独评估。很多项目 80% 的流量只集中在少数几个 Agent 上，把这几个高频 Agent 放 global，低频 Agent 用 standby，效果通常比一刀切好得多。我在实际测试中发现，这种混合策略比单纯切 global 每个月能省 30% 左右的常驻资源，而且延迟表现并不差。等我把这套混合部署完整跑通一个任务周期，再回来写一篇具体记录。
