1. 先聊聊标题里的那个“0ms”它到底意味着什么如果你做过几年后端一定会对“首字节响应时间”这个词有种本能的敏感。HTTP请求发出去到浏览器或客户端拿到 response 的第一个字节这个时间基本决定了用户对“快”的直觉。常规接口做到 50ms 以内已经算优秀做到 10ms 内算是极致优化而标题里那个 0ms 看起来像是一个不可能的数字——尤其是当它和 Spring AI Agent 这种充满不确定性的东西放在一起时。先说结论这里的“0ms”不是指整个 Agent 任务完成的时间而是指 Agent 在流式输出场景下从用户发起请求到服务端返回第一个响应字节的耗时。换句话说是“首包”时间不是“完包”时间。Agent 内部可能要经历模型推理、工具调用、多轮判定、记忆拼装等一系列过程但如果这些逻辑都放在异步任务里执行而主链路先用一个轻量级的响应流把“我收到了正在处理”的字节推给客户端那首字节就能做到几乎为零。不过这只是表象。真正让人头疼的是 Agent 本身的不确定性。模型输出的内容不可预知工具调用的次数不可预知甚至同一个问题每次回答的路径都不同。这种不确定性会让首字节时间很难稳定控制——有时候模型响应快有时候工具调用链很长有时候 Agent 在内部做了好几次循环判断才决定输出内容。如果把这些不确定性统统塞进用户的请求链路里首字节时间必然波动巨大甚至动不动就超时。我当初接手这个项目时团队的目标其实只有一句话让 Agent 接口的首字节时间稳定收敛到极低水平同时不能牺牲回复质量。这句话听起来简单真正做起来牵扯的东西非常多。从请求入口的异步化改造到流式响应的骨架搭建再到 Agent 内部每一步执行的可观测性和超时治理最后还要让这套机制经得住并发和故障考验。整趟下来核心逻辑加配套代码大概 1000 行出头不算多但每一行都是在和不确定性做对抗。这篇文章就把我在这 1000 行里踩过的坑、想通的道理、以及最终的落地方案完整拆开讲清楚。适合那些已经在用 Spring AI 做 Agent 开发、或者正打算把 Agent 能力接入 Web 服务的人。如果你还停留在“调通一个 Demo”的阶段那这篇文章能帮你少走很多弯路如果你已经遇到了首字节慢、响应不稳定、流式输出乱序、超时难控制这些问题那这篇文章更值得读完。2. 为什么 Agent 接口天然做不好首字节控制先别急着写代码得先把问题看清楚。很多人上来就喷 Spring AI说它慢、不稳定、不适合生产。但实际用下来Spring AI 本身并不慢慢的是我们把这些组件拼起来的方式。Agent 链路里藏着几个天然的不确定性来源每一个都在跟首字节指标作对。2.1 模型推理本身的延迟波动大语言模型接口的响应时间受限于 token 生成速度。同一个模型在服务端负载低时可能 20ms 出一个 token负载高时可能 80ms 才出一个 token。对于生成式接口第一个 token 的返回时间TTFTTime To First Token也极不稳定有时候 100ms有时候 1 秒钟。我们无法控制模型服务端的负载情况只能想办法把这种波动挡在用户请求链路之外。2.2 Agent 的决策次数不受控Agent 和普通接口最大的区别在于普通接口的执行路径是确定的而 Agent 的执行路径是模型“临时决定”的。比如用户问“帮我查一下上海明天天气然后安排一个适合出行的活动”Agent 内部可能需要先调用天气查询工具再调用活动推荐工具最后汇总答案。但另一个用户问同样的问题模型可能会先直接回答“明天下雨不适合出行”连工具都不调。这种决策路径的差异直接导致响应时间的方差特别大。更麻烦的是多步工具调用时每一步都有超时可能。如果某个工具服务迟迟不返回Agent 会持续等待用户端的第一字节就遥遥无期。这是 Agent 接口做不好首字节控制的核心原因——不确定性集中在请求链路中间而不是在入口。2.3 结构化输出与重试放大延迟Spring AI 提供了 Structured Output 能力可以让模型按要求输出 JSON 等结构化数据。但这背后往往需要多一次模型调用比如用于格式校验和修正或者需要等待模型生成完整的内容后再解析。只要走了解析校验逻辑首字节一定不是 0ms因为系统必须等模型生成完、校验通过后才敢把数据发给客户端。这就是标题里的“驯服”二字的含义不是消灭不确定性而是把不确定性从用户感知链路中剥离出去。让用户感知到一个近乎即时响应的服务然后后台慢慢处理真正的 Agent 逻辑处理完后再通过流式通道逐步把内容推给用户。3. 整体架构设计拆开“响应”和“处理”想清楚上面这些之后我定下了整套方案的架构基调响应链路与处理链路彻底分离。这个思路不新鲜Netty、WebFlux 的前辈们早就这么干了但把它用到 Spring AI Agent 上需要做几个关键设计决策。3.1 请求入口异步化先把连接占住我们的技术栈是 Spring Boot 3 Spring AIWeb 层最初用的是传统的 Tomcat 同步 Servlet 模型。同步模型下一个请求占用一个线程直到响应结束才释放。如果 Agent 要跑 10 秒那这个线程就要卡 10 秒Tomcat 默认 200 个线程很快就耗尽。更致命的是同步模型下我们没法在 Agent 处理完之前主动给客户端推任何字节首字节只能等最终结果。所以我做的第一件事把 Web 层迁移到 WebFlux 的异步模型或者保留 Servlet 但使用 DeferredResult/SseEmitter 这类异步返回机制。我最终选了 SseEmitter原因后面细说。核心目的是让请求一进来立即返回一个处于打开状态的 SSE 流用户的连接被稳稳占住然后后台用一个线程池去跑 Agent 任务任务有进展就通过 SseEmitter 的 send() 方法推给客户端。// 请求入口先给客户端打开一个 SSE 流 PostMapping(value /agent/chat, produces MediaType.TEXT_EVENT_STREAM_VALUE) public SseEmitter chat(RequestBody ChatRequest request) { SseEmitter emitter new SseEmitter(120_000L); agentTaskExecutor.execute(() - handleAgentProcess(request, emitter)); return emitter; }这段代码很短但它是整个 0ms 首字节的基石。SseEmitter 一创建Spring MVC 就会立即返回响应头客户端马上能收到 HTTP 200 和 Content-Type: text/event-stream。从用户发出请求到收到第一个字节中间只有网络传输和框架本身的毫秒级开销无限接近 0ms。3.2 线程池设计别把 Agent 任务塞进用户线程SseEmitter 返回后Agent 任务不能占着请求线程执行必须丢到独立的线程池里。这里线程池的配置很讲究。Agent 任务涉及模型调用和工具调用基本都是 IO 密集型操作但中间也有 CPU 密集的解析环节。我使用了一个核心线程数等于 CPU 核数的线程池然后设置了一个比较大的队列容量同时拒绝策略选择 CallerRunsPolicy避免在高并发下直接丢弃任务。Bean(agentTaskExecutor) public Executor agentTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(Runtime.getRuntime().availableProcessors()); executor.setMaxPoolSize(Runtime.getRuntime().availableProcessors() * 2); executor.setQueueCapacity(1000); executor.setThreadNamePrefix(agent-worker-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; }CallerRunsPolicy 这个策略很关键。如果线程池满了新任务不会丢弃而是由提交任务的线程也就是 Web 层的请求线程来直接执行。这会导致请求线程阻塞但在极端流量下它保证了任务的完整执行而不是静默丢失。实际生产里我会配合监控告警一旦触发 CallerRuns 就说明线程池不够了需要扩容或限流。3.3 为什么选 SSE 而不是 WebSocket 或普通 JSON这里我纠结了很久。WebSocket 是全双工看似更适合流式交互但它把连接协议升级成了 ws和现有 HTTP 网关、鉴权中间件的兼容性成本较高。普通 JSON 响应又做不到“首字节 0ms”必须等整体结果。SSE 在两者之间找到了平衡——它是标准 HTTP直接复用现有网关和鉴权逻辑又能服务端向客户端持续推送数据。SSE 的另一个优势是自带重连机制和事件命名。客户端断开后会自动重连服务端可以给不同事件类型命名比如 event: token 表示流式 tokenevent: done 表示结束event: error 表示错误。这些对 Agent 这种既有中间状态又有最终结果的场景特别方便。// 服务端 SSE 推送示例 emitter.send(SseEmitter.event().name(token).data(这是一段生成的文本)); emitter.send(SseEmitter.event().name(done).data(finish));前端用 EventSource 或者 fetch 的流式读取接口都能接。如果前端需要携带 Authorization 头则只能使用 fetch ReadableStreamEventSource 不支持自定义请求头这点要提前和前端同学约定好。4. 驯服 Agent 内部的不确定性三步递进策略架构上把首字节问题和内部处理问题解耦后剩下的硬骨头就在 Agent 内部。这里我做了三步递进的设计每一步都在压缩不确定性带来的风险。4.1 第一步固定 Agent 执行骨架减少模型自由发挥的空间Spring AI 的 ChatClient 很灵活你可以用 prompt 告诉模型“你是一个助手”然后让它自己发挥。但在生产环境里这种自由发挥是灾难。我的做法是把 Agent 的执行过程拆成固定的阶段——意图识别、工具路由、工具执行、结果聚合、最终回答。每个阶段用一个明确的 Java 方法封装模型只在规定的节点上做决策而不是让它从头到尾自由编排。// 固定执行骨架 public AgentResponse execute(AgentContext context) { Intent intent intentDetector.detect(context.getUserMessage()); if (intent.isDirect()) { String answer chatClient.call(context.getUserMessage()); return new AgentResponse(answer); } ListToolSpec tools toolRouter.route(intent); for (ToolSpec tool : tools) { String result toolInvoker.invoke(tool, context); context.addToolResult(tool, result); } String finalAnswer chatClient.call(context.buildFinalPrompt()); return new AgentResponse(finalAnswer); }这个骨架看起来简单但它的价值在于每个阶段都可以单独设置超时、单独重试、单独记录日志。模型再“不确定”它也只在意图识别和工具路由这两个节点上做选择题而这两个节点我都可以用更小的 prompt、更低温度的参数去限制它的行为。实测下来固定骨架后同类型问题的执行路径收敛了很多响应时间的方差大幅下降。4.2 第二步给每个阶段设置独立的超时控制不确定性最大的来源是模型调用或工具调用“挂起”。如果不设置超时一个异常的工具请求可以让整个 Agent 任务卡死而客户端已经在等数据了。我的做法是给每个阶段都配置明确的超时并且超时后执行兜底逻辑——不是直接抛异常而是返回一个降级结果让 Agent 能继续往下走或温和地告知用户。public AgentResponse execute(AgentContext context) { Intent intent CompletableFuture.supplyAsync(() - intentDetector.detect(context.getUserMessage()), agentTaskExecutor) .get(3, TimeUnit.SECONDS); // 意图识别最多等 3 秒 ... }工具调用阶段可能更复杂。有些工具是外部 HTTP 接口有些是本地函数每个工具的超时时间应该可配置。我把超时时间放进了工具注解里这样不同的工具可以有不同的容忍度。比如查数据库的超时给 5 秒调用第三方 AI 服务的超时给 10 秒本地计算的超时给 2 秒。每个工具执行时都会包裹一层超时控制超时后产生一个 ToolTimeout 结果把它当作普通工具结果丢回给模型让模型决定下一步。4.3 第三步流式拼装与“首字节体验”的配合前面两步保证了 Agent 内部不会无限等待但真正让首字节体验“好”的是阶段推进时立刻把中间状态推给用户。意图识别完成后立即推一个 event: stage 告诉前端“正在识别意图”工具路由完成后推一个 event: stage 告诉前端“正在调用天气服务”最终回答流式生成时每生成一个 token 就推一个 event: token。这样用户在感官上看到的不是“等了 5 秒然后一堆文字突然冒出来”而是“请求发出去马上就有阶段反馈然后文字一个接一个出现”。首字节的指标虽然没有变化第一个字节本来就被 SseEmitter 提前推送了但用户对响应速度的体感会好非常多。这里有一个关键技术细节Spring AI 的 ChatClient 支持流式调用返回的是 Flux。你可以把这个 Flux 映射成 SSE 事件逐条推给 SseEmitter。但要注意 SseEmitter 是阻塞式的 send()而 Flux 是响应式的需要做线程切换不能直接在 Netty 事件循环里调 send()。我封装了一个 StreamBridge 组件专门处理 Flux 到 SseEmitter 的桥接。public void bridge(FluxString flux, SseEmitter emitter) { flux.subscribe( token - { // 切到异步线程执行 send避免阻塞 Netty 线程 agentTaskExecutor.execute(() - { try { emitter.send(SseEmitter.event().name(token).data(token)); } catch (IOException e) { // 客户端断开取消订阅 log.warn(SSE send failed: {}, e.getMessage()); fluxCancelled.set(true); } }); }, error - { ... }, () - { try { emitter.send(SseEmitter.event().name(done).data(finish)); emitter.complete(); } catch (IOException e) { ... } } ); }注意在订阅的回调里执行 send 时要判断取消状态否则客户端断开后还在不断 send日志里会刷一堆 Broken pipe。这一点是我在压测时发现的一开始没处理压了十分钟后日志直接爆炸。5. 那 1000 行代码的核心模块到底写了什么很多人看到“1000 行代码”会觉得是不是一个很大的工程。其实拆开之后每个模块都非常聚焦。我把代码按职责分成了五个部分每部分大概 200 行左右这也是我能在两周内完成初版并跑通压测的关键。5.1 AgentContext贯穿全流程的状态容器Agent 执行过程中需要传递用户消息、意图结果、工具调用列表、工具执行结果、历史对话、以及各类配置参数。如果每个方法都单独传参数调用链会非常长且难以维护。我设计了一个 AgentContext 上下文对象它是一个可变的 POJO既可以保存输入状态也能记录中间结果。public class AgentContext { private String sessionId; private String userMessage; private Intent intent; private ListMessage history; private ListToolExecutionRecord toolRecords; private AgentConfig config; // 额外参数 private MapString, Object attributes; }这个类里有几个值得注意的点history 字段保存的是 Spring AI 的 Message 对象列表用于和 ChatClient 直接交互attributes 是一个自由扩展的 Map任何阶段都可以往里塞值后续阶段可以取出来。这样即使未来增加新的阶段也不需要改方法签名只在 context 加属性就行。实际上AgentContext 还承担了“链路追踪”的职责。我在里面放了一个 TraceId每个阶段执行时都会用这个 TraceId 记录日志。压测时如果发现某个请求特别慢可以直接用 TraceId 把所有日志拉出来一目了然。没有这个设计排查 Agent 问题会非常痛苦——因为同一个会话的异步任务散落在不同线程里没有 TraceId 根本串不起来。5.2 IntentDetector用最轻量的方式判断用户意图不是所有问题都需要走完整 Agent 流程。有些问题比如“你好”“你是谁”根本不需要调用工具模型直接回答就行。如果每次都走完整的工具路由既浪费 token 又增加延迟。IntentDetector 的职责就是快速判断这个问题是“直接回答型”还是“工具处理型”。我最初试过用第二个模型调用来做意图识别准确率很高但延迟翻倍不划算。后来改用规则模型的双重判断先跑一遍轻量正则规则比如包含“天气”“新闻”“订单”等关键词命中就直接走对应工具未命中的再调用一次小模型判断意图。这样大部分简单问题走规则即可只有模糊表达才需要模型介入。这一层优化让平均响应时间降低了约 40%。public Intent detect(String userMessage) { // 先走规则命中即返回 if (messageMatcher.isMatch(userMessage, weather)) return Intent.weather(); if (messageMatcher.isMatch(userMessage, order)) return Intent.order(); // 规则未命中时走模型降级判断 return chatClient.prompt() .system(你只负责判断用户意图返回固定枚举值DIRECT, TOOL_WEATHER, TOOL_ORDER) .user(userMessage) .call() .entity(IntentType.class); }Intent 枚举不宜太多越少越好。我把业务工具分成五类Intent 也只对应这五类直接回答。这样模型需要做的选择题维度很低不易出错。如果业务方需要新增工具最佳实践是同时新增 Intent 类型和规则不要让模型在 20 个工具里做选择那是自找麻烦。5.3 ToolRegistry统一工具注册与调用入口Spring AI 的 Tool 机制其实很完善可以直接通过 Tool 注解把方法暴露给模型。但生产环境中工具往往有权限校验、限流、超时、审计等额外要求直接暴露朴素方法并不合适。我封装了一个 ToolRegistry对工具做统一管理。public class ToolRegistry { private final MapString, ToolSpec toolMap new ConcurrentHashMap(); public void register(String name, ToolSpec spec) { toolMap.put(name, spec); } public OptionalToolSpec get(String name) { return Optional.ofNullable(toolMap.get(name)); } }ToolSpec 里包含工具名称、描述、参数 schema、执行器逻辑、超时时间、重试次数、是否异步执行等元信息。注册时把这些信息收集好执行时由统一的 ToolExecutor 来调用而不是让工具自己定义执行方式。这样可以在工具执行前后自动加上限流、审计日志、超时控制工具作者只需要写业务逻辑就好。有一个坑要提醒Spring AI Alibaba 的 Tool 注解在 1.x 系列里对方法参数和返回类型有严格要求如果返回的是自定义对象序列化时可能会有问题。我后来统一要求工具方法尽量返回 String 或简单 Map避免模型解析复杂 JSON 时出错。5.4 StreamBridgeFlux 与 SseEmitter 的安全桥这部分代码是整个流式输出的关键。我前面提到SseEmitter.send() 不能直接在 WebFlux 的 Netty 线程上调用需要切换到独立线程池。StreamBridge 做的事情就是订阅上游的 Flux 流把每个元素异步发送给 SseEmitter同时处理取消、超时、异常等边界情况。public class StreamBridge { private final Executor executor; public StreamBridge(Executor executor) { this.executor executor; } public void bridge(FluxString flux, SseEmitter emitter, long timeoutMs) { AtomicBoolean completed new AtomicBoolean(false); Disposable disposable flux .timeout(Duration.ofMillis(timeoutMs)) .subscribe( token - executor.execute(() - safeSend(emitter, token, token, completed)), error - handleError(emitter, error, completed), () - completeEmitter(emitter, completed) ); emitter.onCompletion(disposable::dispose); emitter.onTimeout(() - { disposable.dispose(); emitter.complete(); }); } }这里有几个设计细节很重要。第一timeout 要设置防止模型侧长时间没有输出导致连接挂死。第二completed 标志要在线程间共享避免超时后还在 send。第三emitter.onCompletion 里要 disposable.dispose()否则 Flux 不会取消底层连接会被一直占用。我实际遇到的 bug 是当客户端主动断开时emitter 会触发 onCompletion 回调但此时上游 Flux 可能还在推送数据dispose() 后会出现算子取消异常。后来我在 safeSend 里捕获了 IOException 和 IllegalStateException并把 completed 置为 true后面的 send 直接跳过。这个处理虽然简单但如果不做日志里每天能扫出上千条异常。5.5 AgentOrchestrator对外的统一门面最后是 AgentOrchestrator它把前面这些组件串成一个完整流程并对外提供统一的调用入口。这个类的设计目标是“高内聚低耦合”外部调用者只需要传一个 userMessage拿到一个 SseEmitter 即可。public SseEmitter startChat(ChatRequest request) { SseEmitter emitter new SseEmitter(config.getTimeout()); AgentContext context new AgentContext(request); context.setTraceId(UUID.randomUUID().toString().replace(-, )); executor.execute(() - { try { // 立即推送一个“开始”事件确保连接在没有任何真实处理结果前就保持活跃 emitter.send(SseEmitter.event().name(start).data(begin)); Intent intent intentDetector.detect(context.getUserMessage()); emitter.send(SseEmitter.event().name(stage).data(intent)); // 阶段结果处理 ... if (intent.isDirect()) { streamBridge.bridge(chatClient.stream().prompt(...).stream(), emitter, config.getModelTimeout()); return; } ListToolSpec tools toolRouter.route(intent); emitter.send(SseEmitter.event().name(stage).data(routing)); ... } catch (Exception e) { log.error(Agent process failed, traceId: {}, context.getTraceId(), e); sendError(emitter, e); } }); return emitter; }Orchestrator 里我特意保留了 traceId 日志这个字符串从入口到每个阶段都会出现在日志上下文里。压测时排查慢请求只要 grep 这个 traceId就能串起整个执行链路的所有步骤耗时。没有这个机制Agent 排障基本只能靠猜。6. 结构化输出的坑实体类定义与稳定性优化热词里多次出现“spring ai structured out 结构化输出 如何定义实体类”这个确实是 Spring AI 使用中非常容易踩坑的点。尤其当你把模型输出转成 Java 对象时字段名、类型、格式稍有偏差整个流程就会崩。6.1 实体类定义的正确姿势Spring AI 结构化输出最常见的做法是让模型返回 JSON然后通过 ObjectMapper 反序列化成实体类。但模型生成的 JSON 可能缺少字段、多出字段、或者类型不符直接反序列化会抛异常。Spring AI 内部用了类似 JsonSchemaGenerator 的机制来约束模型输出格式但前提是实体类定义必须规整。我的经验是字段类型尽量用包装类比如 Integer 而不是 intString 而不是 enum 的单值字段。原因很简单模型输出缺失字段时包装类反序列化结果是 null基本类型则会得到默认值 0 或 false掩盖了“字段缺失”的事实。在意图识别场景里一个字段缺失和有默认值后续代码的行为差别很大。实体类字段命名建议用驼峰但如果有下划线最好用 JsonProperty 显式映射。模型在生成 JSON 时对字段名的把握并不稳定直接用和模型约定一致的字段名效果最好。我习惯在实体类上加上 JsonIgnoreProperties(ignoreUnknown true)防止模型输出多余字段时反序列化失败。public record IntentResult( JsonProperty(intent_type) String intentType, JsonProperty(confidence) Double confidence, JsonProperty(target_tool) String targetTool, JsonProperty(arguments) MapString, Object arguments ) { public static IntentResult empty() { return new IntentResult(DIRECT, 0.0, , Map.of()); } }定义实体类以后调用方式很简单IntentResult result chatClient.prompt() .system(你只负责意图识别输出符合 JSON Schema 的结果不要输出额外说明。) .user(userMessage) .call() .entity(IntentResult.class);6.2 结构化输出失败的兜底策略即使定义了 JsonSchema模型还是可能输出不合法 JSON特别是用了低温度或高温度的场景下。我的兜底策略是定义默认值解析失败时直接返回 IntentResult.empty()不要让它抛异常进入全局错误处理。对 Agent 来说一次意图识别失败不算失败后续的默认路径DIRECT也能给出一个可用的回答最多是没用工具而已。try { return mapper.readValue(jsonString, IntentResult.class); } catch (JsonProcessingException e) { log.warn(Structured output parse failed, fallback to empty intent); return IntentResult.empty(); }这个兜底策略看起来简单但对稳定性提升巨大。生产环境中模型偶尔抽风是常态我们不能因为一次输出格式不对就让整个请求 500。用降级代替失败是 Agent 工程化的核心思想之一。6.3 结构化输出与流式输出的冲突这个坑比较隐蔽。如果你的 Agent 需要流式输出同时又要求结构化输出两者天然冲突——结构化输出需要等着攒完整 JSON 才能解析流式输出则希望一边生成一边推送。我的做法是阶段性的结构化输出比如意图、工具路由结果不和最终回答混在一起前者用非流式调用快速拿到结果后者走流式输出。这样既保证了阶段判定可靠也不会让用户等太久。如果非要全程流式且结构化有一个折中方案让模型流式输出一个大的 JSON前端拿完后整体解析。但这样首字节即使 0ms用户也看不到实际内容直到所有 token 到齐才能解析渲染体感反而不如阶段反馈最终流式回答。7. 实测首字节数据与压测中的意外情况光说不练假把式。我把这套方案部署到测试环境后做了一轮性能压测和真实场景验证。结果如何直接看数据。7.1 不同场景下的首字节时间和整体耗时场景首字节时间整体完成时间说明纯文本对话直接回答0-5ms1.2sSseEmitter 立即打开模型流式返回单工具调用查天气0-5ms2.8s工具耗时 1.5s模型汇总 1.0s多工具链查天气推荐活动0-5ms4.5s两个工具串行调用工具超时降级0-5ms3.1s工具 3 秒超时后走兜底回答首字节时间稳定在几毫秒内这是 SseEmitter 异步返回的必然结果没有悬念。真正让我意外的是整体完成时间的波动尤其在多工具链场景下模型对工具结果的汇总时间会波动很大。同样是一次天气查询有时 0.8 秒就汇总完了有时要 2 秒多。这种波动在深层原因是模型生成 token 的速度不稳定尤其是输入上下文变长之后首 token 延迟明显增加。7.2 压测时暴露的三个真实问题压测过程中我遇到了三个问题都是文档里不会写的这里单独说一下。第一个是连接未释放。压测刚开始时我用 200 并发跑了 10 分钟发现服务端连接数只增不减。排查后定位到是 SseEmitter 在客户端断开后没有触发 onCompletion原因是有些客户端比如压测脚本用的不是标准 EventSource而是普通的 HTTP 请求服务端发送完 done 事件后调用 emitter.complete()但连接却没有立刻关闭。后来我在 SseEmitter 上加了 onTimeout 和 onError 回调并且设置了 120 秒超时确保异常情况下能回收连接。第二个是线程池队列积压。当 Agent 任务处理速度跟不上请求进入速度时线程池的队列会疯狂积压。由于任务里有等待模型响应的操作积压意味着很多请求几分钟后才开始处理而这种延迟不会直接暴露在首字节指标里因为 SseEmitter 已经立即返回了但用户会在 SSE 流里看到长时间的“静默”。解决方式是给每个任务设置排队上界超过上界直接返回 429 限流错误而不是让用户无限等待。第三个问题是 Flux 取消不及时。前文提到的 StreamBridge 里如果客户端断开SseEmitter 会进入完成状态但上游模型调用的 Flux 并不会自动取消。如果你不显式调用 disposable.dispose()模型服务端的 token 生成会继续浪费大量资源。这个 bug 在压测中表现为模型服务端 CPU 飙升排查了很久才定位到是下游没人消费上游还在生产。7.3 稳定性验证连续跑一周的观察结果压测通过后我把这套服务放在测试环境连续跑了一周每天模拟真实用户请求约 2 万次。最终统计结果是首字节时间 P99 在 8ms 以内Agent 整体完成率 99.87%工具超时率从最初的 12% 降到 2.3%。超时率下降不是因为工具变快了而是因为降级策略和重试策略配合得当很多瞬时故障被自动绕过。最让我高兴的是这 2 万次请求中没有出现一次因为 Agent 内部不确定性导致的线程泄漏或连接泄漏。这说明 SseEmitter 的完整生命周期管理onCompletion/onTimeout/onError起到了作用。8. 一些后话这 1000 行代码的真正价值写完这套东西后我回顾了一下发现真正让我“驯服”不确定性的并不是哪一行具体的代码而是一整套设计哲学。这里总结几条我个人的体会希望能帮你少走弯路。第一首字节时间不是终极目标体验一致性才是。0ms 首字节可以让用户觉得“响应很快”但如果后续的流式输出时断时续或者阶段反馈乱序用户还是会觉得系统很卡。所以首字节只是入场券真正要花心思的是把整个 Agent 执行过程的每个阶段都控制得稳定可预期。第二不要试图控制模型而是控制模型可见的决策面。模型的输出天然不可控但你可以通过固定骨架、限制意图分类、规范工具注册等方式让模型在非常有限的选项里做决策。你给模型的自由度越小系统的确定性就越高。第三降级是 Agent 稳定性的灵魂。模型调用可能失败、工具调用可能超时、JSON 解析可能出错这些异常在传统接口里可能就是 500 错误但在 Agent 场景里你可以设计降级路径让系统在不完美的情况下继续运行。我的经验是每个阶段都要有降级方案即使降级导致回答质量下降也好过整个服务不可用。第四可观测性从第一行代码就要考虑。Agent 的异步执行链路天然复杂如果不从入口就埋好 TraceId出了问题你只能在茫茫日志里大海捞针。我建议在 AgentContext 里贯穿一个 traceId并且每个阶段都输出耗时日志这样排查问题时能快速定位瓶颈。最后再说一个具体的技巧如果你用 Spring AI Alibaba 的 1.x 系列组件注意它和 Spring AI 官方组件之间的一些版本兼容性问题。特别是 spring-ai-alibaba-graph 这类图形化编排组件虽然看起来很省事但一旦遇到版本升级接口变化可能让你的代码全部失效。我目前更倾向于用官方 Spring AI 的核心 API 自己封装的控制逻辑这样可控性更高升级也相对平滑。前后花了两周时间代码量控制在了 1000 行左右换来的是 Agent 接口可预测的首字节表现和整体稳定性。说实话Agent 本身的价值不在“快”而在于能处理复杂任务但一个让人等得心焦的 Agent 很难真正落地。希望这篇文章的思路能给你一些启发也欢迎在评论区分享你在 Spring AI Agent 实战中遇到的那些奇奇怪怪的问题说不定我下篇文章就会聊到。