高并发主链路该不该接 Agent：延迟、确定性与失败成本

本文用可复现的示例场景说明排查和设计方法；阈值、容量与超时设置需要结合实际流量、依赖版本和压测结果确认，不能直接照搬。

人工智能和 Agent 工作流在各大技术大会上红得发紫。不少架构师在规划亿级流量系统时，也忍不住想在核心链路上引入 AI —— 比如用 Agent 智能拆解订单优惠策略、用多轮 ReAct 工具调用来判断用户风控等级，甚至让大模型实时编排微服务调用顺序。

但在高并发、高可用（四个 9 以上）的生产系统里，盲目套用 AI Agent 往往是一场灾难。大模型的“不确定性”、“秒级的响应延迟”以及“不可控的工具调用循环”，与亿级流量架构所追求的“确定性”、“毫秒级 SLA”和“极端隔离”天然冲突。

在考虑把 Agent 塞进架构之前，最重要的一步是画清它的应用边界。

1. 风险场景：在秒杀主链路塞入 Agent 工具调用

假设在秒杀下单的同步链路里加入“优惠券组合 Agent”：它需要依次调用库存、积分和优惠券服务，再生成下单方案。

这类设计首先会碰到延迟预算和工具调用次数问题。

[10:00:01.002] INFO  [order-agent] Starting ReAct loop for Order: 88192019
[10:00:01.450] INFO  [order-agent] Action: CallTool(get_user_coupons) -> returned 12 items
[10:00:02.100] INFO  [order-agent] Action: CallTool(calculate_discount) -> error: API rate limit
[10:00:03.200] WARN  [order-agent] ReAct Thought: "Tool error encountered, retrying with tool: get_user_points..."
[10:00:05.300] ERROR [order-gateway] Request HTTP 504 Gateway Timeout after 5000ms. User aborted.

监控指标令人窒息：

• P99 响应延迟 从原来的 12ms 飙升到 4800ms；
• 每次请求新增多轮外部调用，系统可承载 QPS 会明显下降；
• 如果重试没有幂等键与轮次上限，同一积分扣减可能被重复提交，并挤占数据库连接池。

这个反例证明：千万不要把带有概率性推理、多轮 IO 交互的 Agent 工作流，挂在亿级流量的同步阻塞链路上。

flowchart TD
    subgraph 严禁放置 AI 的高并发同步主链路 (QPS 10W+, SLA < 20ms)
        User[用户请求] --> GW[API Gateway]
        GW --> OrderSvc[下单核心服务]
        OrderSvc --> DynamicRules[确定性规则引擎 (Drools / Go Engine)]
        DynamicRules --> DB[(MySQL / Redis Cluster)]
    end

    subgraph 适合 Agent 介入的异步旁路与离线解耦区 (SLA > 2s)
        OrderSvc -->|Kafka / RocketMQ 异步消息| MQ[Order Event Topic]
        MQ --> AgentWorker[Agent 任务拆解与 ReAct 工作流]
        AgentWorker --> Tool1[知识库检索]
        AgentWorker --> Tool2[客服自动工单]
        AgentWorker --> Tool3[离线风控审计]
    end

2. 三项检查：业务场景是否适合 Agent

在评估一个业务模块是否适合引入 Agent 时，可以使用以下三条硬性指标进行过滤：

检查一：延迟预算是否容得下模型调用？

亿级流量的主链路（如支付、库存扣减、路由分发），要求 P99 应锁定在 50ms 以内。而一个单次 LLM 推理（包含 Token 传输）动辄 500ms 以上，如果加上 2~3 轮 ReAct 工具调用，延迟至少在 3 秒以上。只要延迟容忍度低于 2 秒，一律禁用 Agent。

检查二：结果是否要求幂等与确定？

财务结算、库存扣减、权限校验等业务，要求逻辑应是 100% 确定性的代码逻辑（输入 A 应输出 B）。而 Agent 的推理机制天然具有随机性与采样温度（Temperature）。涉及资金与安全的核心逻辑，绝不能交给概率模型去决策。

检查三：失败成本是否可控？

如果 Agent 在调用外部工具时出现死循环、参数传错或者遗漏调用，系统是否有机制在毫秒级内自动回滚并保持数据一致？如果答案是“否”，那么说明现有架构还没有做好支撑 Agent 的准备。

3. Agent 旁路解耦与沙盒隔离

如果业务确实需要 Agent（如智能售后判研、复杂运营报表离线生成、长尾日志诊断），正确的做法是：同步主链路只做数据收集与异步解耦，Agent 放在后台沙盒消费。

// 生产级防线：同步主链路采用绝对确定的降级方案
@RestController
@RequestMapping("/api/v1/order")
public class OrderController {

    @Autowired
    private OrderCoreService orderCoreService;
    
    @Autowired
    private KafkaTemplate<String, OrderEvent> kafkaTemplate;

    @PostMapping("/submit")
    public ResponseEntity<OrderResponse> submitOrder(@RequestBody OrderRequest request) {
        // 1. 同步主流程：完全使用确定性 Java 逻辑，保证 15ms 内响应
        OrderResponse response = orderCoreService.processOrderDeterministic(request);

        // 2. 异步旁路：将复杂的智能处理（如售后智能预测、消费行为深度分析）丢入 MQ
        OrderEvent event = new OrderEvent(response.getOrderId(), request.getUserPayload());
        kafkaTemplate.send("async-agent-processing-topic", event);

        return ResponseEntity.ok(response);
    }
}

在后台消费端（Agent Worker Pool）中，还需要为 Agent 构建“工具调用的沙盒隔离与熔断防线”：

1. 最大轮次限制（Max Iterations Guard）：设定 ReAct 循环上限（如最多 3 次），达到上限立刻退出并抛出异常，防止 Agent 陷入死循环；
2. 只读工具隔离（Read-Only Tools）：给 Agent 配置的 ToolCalling 应是只读或幂等的接口（如 get_order_detail、query_user_level），严禁赋予 Agent 直接修改核心数据库的写权限；
3. 配额与令牌桶熔断（Token Bucket Rate Limiting）：针对 Agent 发起的并发工具调用配置全局 限流器，防止后台 Worker 把下游微服务压垮。

高可用架构的本质是控制不确定性。把 AI Agent 限制在它擅长的异步推理领域，让核心主链路保持极致的简单与确定，才是系统支撑亿级流量的根基所在。