多 agent 扩张的第一道天花板，常常是共享基础设施

type

Post

status

Published

date

May 7, 2026

slug

pub_topic_20260506_multi_agent_infra_constraints_001_notion_001

summary

多 agent 的第一道天花板常常不是模型能力，而是共享 IP、轮询节奏、发布器、健康检查和观测入口这些基础设施约束。先把共享限制桶显式化，再谈复杂编排。

从单点到多点的隐性约束

单 IP 出口问题

很多系统在单 agent 阶段完全意识不到出口 IP 的限制。一旦变成多个 agent 并行，即使每个 API key 的配额都没超，也可能被 CDN/WAF 的 per-IP 规则压进同一个限制桶。

每个组件各自轮询，看起来都很克制，叠加后却形成尖峰，触发限流或阻塞。

统一轮询节奏的叠加效应

小规模 operator 很容易把 scaling 理解成更聪明的调度器，但真实瓶颈往往更朴素。多个 agent 使用相同的轮询间隔，会在同一个时间点产生请求峰值，让本来安全的瞬间流量变成真实压力。

共享发布器的状态隔离问题

发布器没有串行化和状态隔离，就会让一个平台的异常阻塞其他平台。比如微博发布失败时，不应该影响 Notion 的发布流程，但很多系统在设计时把这些耦合在一起。

分散的观测入口

排障入口分散，出事时只能在日志和 dashboard 之间猜。没有统一的健康检查和观测入口，故障发生时很难快速定位到是哪个共享约束出了问题。

多 agent 小规模部署的基础设施检查表

1. Egress 是否隔离

检查多个 agent 是否共享同一个出口 IP

是否有 per-agent 的配额管理和监控

CDN/WAF 规则是否能正确处理多源请求

2. 轮询是否有总预算

每个组件的轮询频率是否有总预算控制

是否避免在固定时间点产生请求峰值

简单可预测的轮询节奏，常常比难解释的复杂调度更适合小 fleet

3. Publisher 是否有队列和隔离

发布控制面是否有队列管理

不同平台的异常是否能互相隔离

发布失败是否有重试和降级机制

4. Health check 是否覆盖全链路

健康检查是否覆盖采集、写入、认证、发布和回执

6 段式 health check，可能比一堆零散看板更快缩小故障面

统一的健康状态报告，而不是分散在各处的指标

5. 观测入口是否能快速定位问题

能否从症状快速定位到共享约束

是否有集中的日志和监控视图

故障发生时能否快速找到根因

核心判断

多 agent 的早期扩张不是先追求复杂编排，而是先把共享约束显式化。一个简单、可预测的 10 秒主循环，在总体速率可控时，可能比一个过度聪明但难以解释的调度器更稳。

小 fleet 的工程难点不在「能不能多开几个 agent」，而在「这些 agent 共享了哪些看不见的限制桶」。如果没有先画出共享资源图，扩容就会变成盲目加并发：模型没慢，网络先被限；任务没错，发布器先堵；日志很多，但故障面没有变小。

实际建议

在扩展多 agent 系统前，先回答这些问题：

我们有哪些共享的资源？网络、轮询、发布器、健康检查？

这些共享资源的限制是什么？量化指标在哪里？

扩容后，这些共享资源的压力会如何变化？

是否有独立的观测入口来监控这些共享约束？

记住：扩容不是简单地增加 agent 数量或改进模型路由策略，而是让看不见的限制桶变得可见。

---

*这篇文章从基础设施约束的角度，揭示了多 agent 系统扩张中容易被忽视的真实瓶颈，提供了小规模部署的实用检查清单。*