跳至主要内容

高并发场景下的 Agent 系统扩展策略

pax大约 7 分钟

高并发场景下的 Agent 系统扩展策略

来源：Agent Interview 100 #094

难度：高级
分类：Production & Deployment

简短回答

Agent 系统的高并发扩展面临独特挑战：每个请求执行时间长（秒到分钟级）、资源消耗不确定（Token 数量变化大）、有状态（多步执行需要维护上下文）。核心扩展策略：(1) 无状态设计+外部状态存储——将 Agent 会话状态存储到 Redis/PostgreSQL，使服务实例可以自由水平扩展；(2) 任务队列解耦——用 Celery/RabbitMQ 将请求接收和 LLM 处理解耦，Worker 独立扩缩容；(3) 智能自动扩缩容——基于队列深度、并发数（而非 CPU）触发扩容，LLM 服务有其独特的并发限制；(4) 模型路由+故障转移——多提供商分散流量，避免单一 API 限流成为瓶颈；(5) 多层缓存——语义缓存+Prompt 缓存减少实际 LLM 调用量。ByteDance 的 HeteroScale 已在数万 GPU 上验证，通过网络感知调度和协调式扩缩容策略显著提升资源利用率。MIT 研究提出 LLM Archetypes 方法可将 Agent 模拟从千级扩展到百万级。生产实证（2026-10）：Third Moment Research 常态运行 10,000 个 agent 持续 36 小时以上（GPT-6 Astra/Sol + Codex + Daybreak，OpenAI 10-14 工程复盘）——万级并发 × 小时级时长的组合已是真实负载形态。关键指标：TTFT、TPS、QPS 在并发增加时的变化趋势，以及达到"饱和点"后的降级策略。

详细解析

Agent 高并发的独特挑战

维度传统 Web 服务Agent 系统
请求处理时间10-100ms1-60s（甚至更长）
资源消耗可预测Token 消耗不确定（变化 10x）
状态无状态（通常）多步执行有状态
扩展指标CPU/内存并发数/队列深度
失败模式超时/500API 限流/成本爆炸
连接短连接长连接/SSE 流式

核心矛盾：

  • Agent 占用连接时间长 → 同等并发需要更多实例
  • API 限流 → 不能无限扩展实例
  • 成本与流量正比 → 流量翻倍成本翻倍

扩展架构设计

高并发公式：无状态 Worker + 队列解耦 + 外部状态，扩容看队列深度不看 CPU——真瓶颈在上游 API 限流。

# 推荐的高并发 Agent 架构

class ScalableAgentArchitecture:
    """可水平扩展的 Agent 架构"""

    architecture = {
        "接入层": {
            "组件": "API Gateway + Load Balancer",
            "功能": "认证、限流、路由",
            "扩展": "无状态，自由水平扩展",
        },
        "请求队列": {
            "组件": "RabbitMQ / Redis Streams / SQS",
            "功能": "解耦请求接收和处理",
            "扩展": "队列深度 → 触发 Worker 扩容",
        },
        "Worker 池": {
            "组件": "Celery Workers / K8s Jobs",
            "功能": "执行 Agent 逻辑 + LLM 调用",
            "扩展": "基于队列深度自动扩缩容",
            "关键": "每个 Worker 无状态",
        },
        "状态存储": {
            "组件": "Redis（会话）+ PostgreSQL（持久化）",
            "功能": "Agent 执行状态、对话历史、检查点",
            "扩展": "Redis Cluster / PG 读写分离",
        },
        "模型网关": {
            "组件": "LiteLLM / Portkey",
            "功能": "多提供商路由 + 限流 + 故障转移",
            "扩展": "分散流量到多个 LLM 提供商",
        },
        "缓存层": {
            "组件": "Redis Semantic Cache",
            "功能": "减少实际 LLM 调用量",
            "扩展": "缓存命中率越高，扩展压力越小",
        },
    }

任务队列模式

from celery import Celery

app = Celery('agent', broker='redis://redis:6379/0')

@app.task(bind=True, max_retries=3, time_limit=600, soft_time_limit=540)
def execute_agent_task(self, task_id, user_message, session_id):
    """Agent 任务 Worker
    time_limit 设为 600s（10min）：本文档前提是 Agent 1-60s 甚至更长，
    Celery 默认 120s 会硬杀长任务。soft_time_limit 提前 1 分钟抛 SoftTimeLimitExceeded，
    让 Worker 有机会优雅 cleanup。Coding/Research Agent 等更长任务建议 1800s+。
    """
    try:
        # 从外部存储加载会话状态
        session = SessionStore.load(session_id)

        # 执行 Agent
        result = agent.invoke(
            message=user_message,
            history=session.history,
        )

        # 保存更新后的状态
        session.add_message(user_message, result)
        SessionStore.save(session)

        # 推送结果（WebSocket / SSE）
        ResultChannel.push(task_id, result)
        return result

    except RateLimitError:
        # LLM API 限流 → 延迟重试
        self.retry(countdown=30)  # 30 秒后重试

# 扩缩容策略：
# 队列深度 > 100 → 增加 Worker
# 队列深度 < 10 且持续 5 分钟 → 减少 Worker
# 最小 Worker 数 = 2（保证可用性）
# 最大 Worker 数 = 基于 API 限流上限计算

自动扩缩容策略

class AutoScaler:
    """Agent 系统的自动扩缩容"""

    def compute_desired_replicas(self, current_metrics):
        """计算目标副本数"""

        # 策略 1：基于队列深度
        queue_depth = current_metrics["queue_depth"]
        processing_rate = current_metrics["processing_rate_per_worker"]
        queue_based = math.ceil(queue_depth / processing_rate)

        # 策略 2：基于并发数
        concurrent_requests = current_metrics["concurrent_requests"]
        max_concurrent_per_worker = 5  # Agent 长连接，每 Worker 并发有限
        concurrency_based = math.ceil(concurrent_requests / max_concurrent_per_worker)

        # 策略 3：基于 API 限流
        api_rate_limit = current_metrics["api_rate_limit_remaining"]
        if api_rate_limit < 100:
            # API 限流接近上限，不再扩容
            return current_metrics["current_replicas"]

        # 取最大值，但不超过上限
        desired = max(queue_based, concurrency_based)
        desired = min(desired, self.max_replicas)
        desired = max(desired, self.min_replicas)

        return desired

    # 注意：不要用 CPU 作为扩缩容指标！
    # Agent Worker 大部分时间在等待 LLM API 响应（I/O 密集）
    # CPU 利用率很低但实际已经满载

多提供商流量分散

class MultiProviderRouter:
    """多 LLM 提供商分散流量"""

    def __init__(self):
        self.providers = {
            "openai": {
                "rate_limit": 10000,  # RPM
                "weight": 0.4,
                "models": ["gpt-4o", "gpt-4o-mini"],
            },
            "anthropic": {
                "rate_limit": 4000,
                "weight": 0.35,
                "models": ["claude-sonnet-4-5"],
            },
            "google": {
                "rate_limit": 5000,
                "weight": 0.25,
                "models": ["gemini-2.0-flash"],
            },
        }

    async def route(self, request):
        """智能路由到可用的提供商"""
        # 1. 检查各提供商的剩余配额
        available = [
            p for p in self.providers
            if self.get_remaining_quota(p) > 0
        ]

        # 2. 按权重选择
        provider = self.weighted_select(available)

        # 3. 故障转移
        try:
            return await self.call(provider, request)
        except (RateLimitError, ServiceUnavailableError):
            # 自动切换到下一个提供商
            fallback = self.get_next_available(exclude=provider)
            return await self.call(fallback, request)

降级策略

高并发时的降级策略（按优先级）：

Level 1: 缓存优先
├── 提高语义缓存的相似度阈值（0.95 → 0.90）
└── 更积极地使用缓存结果

Level 2: 模型降级
├── 将复杂任务从 GPT-4o 降级到 GPT-4o-mini
└── 牺牲部分质量换取吞吐量

Level 3: 功能降级
├── 禁用非必要工具调用
├── 减少 Agent 最大步数
└── 简化推理流程

Level 4: 排队等待
├── 显示"当前繁忙，请稍候"
├── 优先处理高优先级请求
└── 非实时任务延迟处理

Level 5: 限流拒绝
├── 返回 429 Too Many Requests
├── 提供重试建议
└── 保护系统稳定性优先

常见误区 / 面试追问

  1. 误区："Agent 系统和 Web 服务一样用 CPU 指标扩容" — Agent Worker 大部分时间在等待 LLM API 响应（I/O 密集），CPU 利用率可能只有 10% 但已经满载。应该用队列深度、并发连接数或 API 配额剩余量作为扩缩容指标。

  2. 误区："加机器就能解决高并发" — Agent 系统的瓶颈通常不在计算资源，而在 LLM API 的限流。无限加 Worker 只会更快地触及 API 限流上限。需要多提供商分散流量 + 缓存减少 API 调用 + 模型路由优化。

  3. 追问："如何估算 Agent 系统需要的资源？" — 关键公式：所需 Worker 数 = 目标 QPS × 平均响应时间(秒) / 每 Worker 并发数。例如：目标 100 QPS，平均响应 5s，每 Worker 并发 5 → 需要 100 个 Worker。再加上缓存命中率的折扣。

  4. 追问："Serverless 适合 Agent 系统吗？" — 适合低流量和突发流量场景。但要注意：(1) 冷启动延迟（2-10s）影响用户体验；(2) 执行时间限制（Lambda 15min）可能不够长 Agent 使用；(3) 高流量时成本可能高于容器化部署。建议低流量用 Serverless，高流量用容器化。

参考资料

Pax 技术文档 · 工程面试与技术笔记
Copyright © 2026 pax