“加机器就行了”——这句话骗了多少人

我见过最荒谬的一次故障复盘：一个AI Agent服务，峰值QPS从50涨到200，运维果断扩容，Pod从5个加到20个。结果呢？响应延迟从800ms飙升到8秒，数据库连接池被打满，健康检查连续失败，K8s开始频繁重启Pod——越扩越崩。

“加机器”解决不了高并发，这句话在传统微服务时代就是常识，到了Agent时代却被很多人遗忘了。原因很简单：Agent不是无状态的Web服务，它是一个带状态、带循环、带外部依赖的“有脑子的分布式系统”。 加机器解决的是计算资源不足，而Agent在高并发下遇到的瓶颈，往往是调度策略失当、资源竞争失控、以及状态管理带来的连锁反应。

今天，我们从“调度的艺术”和“隔离的哲学”两个维度，拆解高并发Agent服务的真实解法。

一、调度的艺术：从“随机分发”到“智能路由”

1.1 为什么轮询调度在Agent场景下不够用？

传统微服务用轮询或最少连接数做负载均衡，效果尚可。但Agent场景下，每个请求的“重量”天差地别：一个“查天气”的请求可能只需要一次LLM调用，一个“帮我写一份市场分析报告”的请求可能要调用5个工具、循环3轮、触发10次LLM调用。

把重量级任务和轻量级任务混在一起轮询分发，结果就是：轻任务被重任务堵死，所有Pod的队列都塞满了长任务，短任务也进不来。

一种有效的思路是引入“指挥官-调度官”双层架构：

• 指挥官（Commander）：负责意图识别和任务拆解，把用户的复杂请求转化为结构化的Task Graph
• 调度官（Dispatcher）：负责任务路由和负载均衡，根据任务类型、工具依赖、Worker状态做智能分发

# 调度官的核心逻辑：不只是轮询，而是按任务类型匹配Worker
class AgentDispatcher:
    def __init__(self, registry):
        self.registry = registry  # 服务注册中心
        
    def dispatch(self, task):
        # 1. 根据任务类型筛选候选Worker
        candidates = self.registry.lookup(
            capability=task.tool,      # 必须具备该工具能力
            max_concurrent=self.registry.get_max_concurrent(task.tool)
        )
        
        if not candidates:
            raise ServiceNotFoundError(f"No worker for {task.tool}")
            
        # 2. 在候选集中选负载最低的（而不是简单的轮询）
        selected = self.load_balancer.select(
            candidates, 
            strategy="least_loaded"  # 最少当前并发
        )
        
        # 3. 熔断降级：超时则重试或降级
        try:
            return selected.invoke(task.args, timeout=30)
        except TimeoutError:
            self.registry.record_failure(selected.id)
            return self.fallback(task)

关键在于：调度官不应该由不稳定的LLM来扮演，而是由确定性的代码逻辑构成。 它不需要“聪明”，只需要“可靠”。

1.2 调度粒度的选择：图级调度 vs. 节点级调度

LangGraph的默认执行模式是图级调度——一个请求就是一个完整的图执行，由同一个Worker从头跑到尾。这在并发量不大时没问题，但高并发下会暴露两个问题：

• 资源碎片化：一个Worker在执行长任务时，即使有闲置算力也无法承接其他请求
• 负载不均：有的Worker跑长任务忙死，有的跑短任务闲死

一种更精细的思路是节点级调度：将图的执行拆解为独立的节点任务，由调度官分别分发给不同的Worker执行。这在多Agent协作场景下尤为适用，不同Agent可以独立伸缩，按需分配资源。

# Commander将复杂任务拆解为可独立调度的子任务
{
    "plan": [
        {"step_id": 1, "tool": "Data_Analysis", "args": "query_sales", "worker": null},
        {"step_id": 2, "tool": "Code_Interpreter", "args": "plot_chart", "depends_on": [1], "worker": null}
    ]
}
# 调度官根据step_id分别路由到不同的Worker实例

1.3 从吞吐量公式反推调度参数

LangChain官方文档给出了一个计算吞吐量的公式：

吞吐量（runs/秒）= available_jobs / 平均执行时长（秒）

available_jobs = queue_worker数量 × N_JOBS_PER_WORKER

假设你的Agent平均执行时长2秒，目标吞吐量是100 runs/秒，那么：

• 需要available_jobs = 100 × 2 = 200
• 如果N_JOBS_PER_WORKER = 10，则需要20个queue worker

这个公式揭示了“加机器”的精确成本——不是拍脑袋，而是算出来的。 而且不同类型的Agent（CPU密集型 vs. I/O密集型）需要不同的N_JOBS_PER_WORKER配置：

• I/O密集型Agent（主要瓶颈在LLM API等待）：可以调大N_JOBS_PER_WORKER，一个Worker同时处理更多请求
• CPU密集型Agent（本地推理或复杂计算）：需要调小N_JOBS_PER_WORKER，避免CPU争抢

二、隔离的哲学：不隔离，雪崩只是时间问题

2.1 资源隔离的“第一性原理”

在高并发场景下，一个“坏邻居”拖垮整个系统是常态——某个热点工具被大量调用，占满所有模型并发配额，导致其他核心功能全部不可用。

SKILL架构给出了一种精细化的隔离思路：以“技能”为粒度做隔离，而不是以“系统”为粒度。

# 每个SKILL有独立的限流和配额配置
class SkillConfig:
    def __init__(self, skill_id, complexity, rate_limit, cache_ttl):
        self.skill_id = skill_id
        self.complexity = complexity  # simple | medium | complex | extreme
        self.rate_limit = rate_limit  # {"qps": 10, "daily_tokens": 1000000}
        self.cache_ttl = cache_ttl    # 秒
        
# 执行时先校验限流
def execute_skill(skill, params):
    if not skill.check_rate_limit():
        return {"error": "Rate limit exceeded"}
    # 命中缓存直接返回，避免重复推理
    if skill.cache_ttl > 0:
        cached = cache.get(skill.skill_id, params)
        if cached:
            return cached
    # 按复杂度路由到不同模型
    model = ModelRouter.get_model(skill.complexity)
    result = model.invoke(params)
    cache.set(skill.skill_id, params, result, skill.cache_ttl)
    return result

这种设计的好处是：查询SKILL的流量暴涨，占满的只是它自己的配额，其他SKILL丝毫无损。

2.2 会话级隔离：一个Session一个沙箱

高并发场景下的另一个资源陷阱是状态共享。如果多个会话共享同一个Agent实例或同一个Checkpointer连接池，一个会话的异常状态可能污染其他会话。

AgentCube的解法是基于Session ID的端到端隔离：

• 每个Session ID对应一个独立的沙箱（MicroVM）
• 计算、内存、文件系统完全隔离
• 会话闲置时沙箱自动休眠，释放资源；唤醒时毫秒级恢复

# AgentCube的会话隔离示例
apiVersion: agentcube.volcano.sh/v1
kind: AgentRuntime
metadata:
  name: data-analyst
spec:
  session:
    isolation: true          # 每个会话独立沙箱
    ttl: 3600                # 闲置1小时后回收
  resources:
    cpu: "2"
    memory: "4Gi"

这种方案的代价是资源开销稍大，但在涉及不可信代码执行或多租户场景下，是必要的基础设施投资，而非可选项。

2.3 事件循环隔离：LangGraph隐藏的坑

LangChain的Agent Server有一个容易被忽视的环境变量BG_JOB_ISOLATED_LOOPS。默认情况下，同步阻塞代码会直接占用API服务的主事件循环，导致健康检查失败、Pod频繁重启。

官方文档明确警告：

“启用此标志只是把问题转移了，并没有真正解决。阻塞代码继续在后台循环运行，仍会导致吞吐量下降、尾部延迟飙升、连接池耗尽。”

正确的做法是：全程使用异步代码——异步HTTP客户端（httpx或aiohttp）、异步数据库驱动（asyncpg）、异步模型SDK。对于无法绕开的同步库，用asyncio.to_thread()做局部隔离，而不是对整个部署开启BG_JOB_ISOLATED_LOOPS。

# 错误：整个部署开启隔离标志
# BG_JOB_ISOLATED_LOOPS = True

# 正确：局部隔离同步调用
async def my_agent_node(state):
    # 只有这一小段同步代码跑在独立线程
    result = await asyncio.to_thread(sync_library_call, state)
    return result

这个细节看似微小，但在高并发下，错误的隔离策略会把整个集群拖垮。

三、总结：高并发Agent架构的“三条军规”

回顾全文，高并发Agent服务的请求调度与资源隔离，可以提炼为三条工程原则：

军规一：调度要“聪明”，但不要“智能”。 调度官的决策逻辑应该是确定性的代码（负载均衡、熔断、重试），而不是LLM的模糊推理。把“调度”和“推理”分开——指挥官负责思考，调度官负责执行。

军规二：隔离要以“功能”为粒度，而非“系统”。 SKILL级限流、缓存、模型路由比全局限流精细十倍；会话级沙箱隔离比共享状态安全十倍。

军规三：容量规划靠数学，不靠直觉。 用吞吐量公式算出来的扩缩容参数，比“感觉不够就加两台”靠谱一个数量级。异步代码是底线，而不是优化项。

“加机器”是基建层面的应对，但真正决定系统能否支撑高并发运行的，是调度策略是否精细、隔离机制是否到位、容量规划是否有据可依。这三件事想清楚了，加机器才真的有用。