【解读ByteByteGo 长文】ChatGPT Agent Loop 深度性能优化全解：Harness、API 与推理三层工程落地

ChatGPT 如何优化智能体循环：调度层、接口与推理层全解析

背景：ByteByteGo 长文《How ChatGPT Optimizes its Agent Loop: Harness, API, and Inference》（2026 年 7 月 29 日发布）深入探讨了 ChatGPT 如何优化 Agent Loop。作者通过采访负责 Codex 与 ChatGPT Work 的 OpenAI 工程团队，梳理了 Frontier AI 系统在 Harness、API 和 Inference 三个核心层面的工程优化策略，揭示了现代 Agent 系统如何通过运行框架、接口设计和模型推理协同提升效率、稳定性与任务完成能力。
原文地址：https://blog.bytebytego.com/p/how-chatgpt-optimizes-its-agent-loop

开篇

各大AI实验室迭代速度空前，不断推出性能更强的大模型。不久前Anthropic发布Fable 5，OpenAI推出GPT-5.6全系，包含目前最强的GPT-5.6 Sol；Kimi上线Kimi K3，Opus 5也于近日更新。

但模型能力只是故事的一半，另一半是完成单次任务的成本，即「单次成功任务开销」。
更低的成本既能降低用户使用门槛，也能减少服务商的硬件亏损。各大实验室投入海量工程资源，打磨AI应用每一层组件，以此降低整体运行成本。举个例子：GPT-5.6 Sol开启最高推理档位，在人工分析代码智能体榜单上得分高于Fable 5，但运行成本不足后者一半。

为搞懂头部实验室落地的效率优化方案，我们专访了负责Codex与ChatGPT Work性能体系的OpenAI工程师（感谢Joe、Ahmed、Steve、Matthew、Philippe分享内部细节）。

读完本文你将收获：

• 向AI智能体发起请求后，底层完整执行流程
• 调度层（Harness）如何通过持久WebSocket、稳定提示词前缀、延迟工具检索、代码运行模式削减重复工作
• API网关层如何实现仅增量分词、安全检测与推理并行执行
• 推理层如何依靠缓存感知路由、KV缓存管理、投机解码、预填充/解码负载分离榨干GPU算力
• OpenAI总结的工程经验，可直接复用到你自研的AI系统中

一、AI智能体应用整体架构拆解

当你给Codex或ChatGPT Work下达任务（例如修复代码Bug），用户请求并不会直接发送给LLM，整套系统远比大家想象的复杂。Codex这类AI产品不是单一LLM，而是由多组件构成的完整系统。用户请求需要穿过多层模块，LLM才能读取到第一个Token。

为什么不能直接把请求丢给LLM？

我们先理清LLM的本质：大模型是一个训练用于预测下一个Token的神经网络，输入一串Token序列，输出一串Token序列。
模型本身无法执行Shell命令、编辑文件，跨次调用之间也不会记忆任何上下文。但「修复Bug并运行测试」这类智能体任务，核心是连续动作执行。必须有一套中间系统，把模型输出的Token转换成真实指令、将执行结果回传给模型、循环往复直至任务完成。

这套中间系统就是调度层（Harness），运行在LLM上层，承担以下工作：
接收用户任务，决定上下文需要携带哪些指令、哪些工具定义、保留多少历史对话；维护完整会话记录；当模型返回工具调用指令时，在沙箱环境中按权限策略执行工具，将结果追加至对话，再把更新后的会话重新发给LLM。

即便调度层组装好完整请求，也不会直连LLM推理服务。面向生产环境的应用，调度层与推理端点之间还存在一层API网关层。
该层承载调度层、LLM都不负责的工作：调用者身份鉴权、限流管控，最关键的是完成「文本 ↔ LLM专用Token ID」的双向转换。

当API网关处理好上下文并转换为Token ID序列后，才会进入推理层。推理层由大规模GPU集群提供远程算力，核心目标是用最高效的方式执行模型计算、生成响应（新工具调用或最终回答），再将生成的Token回传给API网关。

单次请求完整流转示例

理解三层架构后，我们以具体任务「定位结账流程回归Bug、编写修复补丁、执行全量测试」，完整走一遍请求链路：

1. 调度层整合指令、工具定义、用户任务组装请求，发送至API网关；
2. API网关将请求缓存至内存，解析并校验JSON：格式合规、当前模型支持所有请求功能；校验调用身份、执行限流预检；
3. API网关将会话渲染为模型输入格式，完成全文分词；
4. API网关同步发起两项操作：向推理层下发Token、启动安全检测分类器（识别网络攻击、生化武器相关违规内容）；安全检测需要赶在首Token生成前完成；
5. 推理层处理提示词并开始生成内容，本次输出并非最终答案，而是工具调用指令：检索代码中「结账超时」相关逻辑；
6. 生成的Token流逐层回传至API网关；
7. API网关将Token还原为文本，封装标准化API事件；
8. 流式事件持续推送到调度层；
9. 调度层识别工具调用，在隔离沙箱执行代码检索，将输出追加至会话，把更新后的对话重新发给API网关。

以上仅为一轮循环。真实业务中，一项任务会重复该流程数十次，直到模型输出最终总结，调度层将结果返还用户。
每一轮迭代都会重复大量相同操作：重复上传历史对话、重复对全文分词、重复处理提示词。消除重复工作，就是性能优化的核心突破口。下文分三层介绍OpenAI落地的全套优化手段。

二、调度层（Harness）优化方案

调度层是离用户最近的编排模块，负责将原始用户请求组装为模型上下文，循环与LLM交互直至任务完成。它有两大核心职责：

1. 会话唯一数据源：完整保存所有指令、对话消息、工具调用记录、工具返回结果，是会话信息的权威存储；
2. 驱动智能体循环：决定发送给LLM的上下文内容（指令、工具定义、历史长度）、发起请求、接收流式响应并解析、监控工具调用；识别工具调用后在沙箱按权限执行、追加结果、重新发起模型请求，循环至任务结束。

复杂任务理论上会循环100次以上，每一轮都会产生额外开销。例如单次模型调用多1秒延迟，长任务整体会增加半分钟等待时长。

调度层四大性能优化手段

从调度层视角，延迟来源分为四类：网络传输、提示词处理、上下文体积、循环往返次数。OpenAI落地四项核心优化。

1. 持久WebSocket + 增量差分请求

调度层运行在用户设备，模型部署在OpenAI数据中心，每次模型调用都需要跨网络传输数据。传统传输方案基于HTTPS：调度层建立连接，发送包含服务端所需全部信息的请求，接收返回结果。
大模型输出Token是分段流式返回，聊天应用通常在HTTPS之上使用SSE（服务器推送事件）。SSE为单向通信，非常适合传统聊天场景：一条用户消息对应一次模型调用、一轮流式回复。
但智能体并非单次交互，单轮Codex任务会触发数十次模型调用。基于HTTPS的方案会带来两类额外成本：

1. 连接建立开销：新建HTTPS连接需要TCP握手+TLS加密握手，在传输有效数据前完成多轮网络往返。单次聊天消息仅一次尚可接受，单会话数十次调用会造成巨额网络损耗；
2. 载荷重复传输：HTTP无状态，每次请求必须携带服务端需要的全部数据：系统指令、工具定义、全部历史对话。到第20次工具调用时，调度层仅新增一行工具结果，却需要重新上传原始提示词、前19轮全部工具调用与返回数据，上传体积持续膨胀，不断重复上传服务端已存储的内容。

优化解决方案

1. 解决连接损耗：使用长连接复用，也就是WebSocket。仅需一次初始握手，会话生命周期内双方可随时收发消息，无需每次重建连接。Codex会为单任务会话维持一条固定WebSocket连接，覆盖所有模型调用，彻底消除重复TCP/TLS握手；
2. 解决载荷重复：停止重复上传服务端已保存的会话数据。调度层缓存上一轮完整请求与响应，若仅对话内容发生变更，仅上传新增数据，并携带上一轮会话ID引用。

工具调用完成后，WebSocket下发的消息体可以极简，示例如下：

{"type":"response.create","previous_response_id":"resp_abc123","input":[{"type":"function_call_output","call_id":"call_xyz","output":"新的工具返回结果"}]}

该消息不携带任何系统指令、工具Schema、历史对话。服务端依靠本地缓存的历史会话状态，结合增量数据还原完整上下文，模型读取信息不受影响，仅大幅降低网络传输数据量。

补充拓展：HTTP Keep-Alive 与 WebSocket 核心差异解析
很多开发者会存在疑问：HTTP 开启 Keep-Alive 即可实现 TCP 连接复用，避免重复的 TCP、TLS 握手开销，为何 OpenAI Agent 体系仍坚持使用 WebSocket 长连接，而非传统 HTTP 架构？核心原因在于二者优化维度完全不同，HTTP Keep-Alive 仅解决传输层 TCP 复用问题，而 WebSocket 解决的是 AI 多轮智能体循环的应用层核心痛点，二者无法互相替代。

1. HTTP Keep-Alive 的能力边界 Keep-Alive 作用仅局限于 TCP 链路复用，不会改变 HTTP 协议与生俱来的约束：协议要求每次请求必须自包含、无状态。即便 TCP 通道不断开，每一轮 Agent

请求依然需要上传完整上下文（系统提示词、历史对话、工具定义）。

TCP连接【持续复用不关闭】 请求1：完整上下文 → LLM生成 → SSE推送token → 等待流全部结束 → 解析工具调用 →执行工具 请求2：完整上下文 → LLM生成 → SSE推送token → 等待流全部结束 → 解析工具调用 → 执行工具 ``` 痛点：仅节省握手开销，无法缩减上行载荷；工具执行与模型生成完全串行，没有时间重叠优化空间。

2. 即便HTTP增加服务端Session缓存，依然存在架构硬伤 不少人设想方案：HTTP+Keep-Alive + SessionID，服务端缓存对话，每次只上传增量消息。这套方案可以简易跑通，但在大规模Agent集群下难以落地：

• 会话粘性问题（关联文中KV缓存优化）HTTP独立请求容易被负载均衡打散，同一会话被分发到不同GPU节点。Redis只能缓存文本对话，无法迁移显存内的KV缓存，缓存失效触发昂贵的重复Prefill计算。WebSocket连接建立后固定绑定后端实例，天然保证会话粘性。

• 串行执行无法重叠时延
  串行时序（HTTP/SSE） 模型生成token ▬▬▬▬▬▬ → 工具执行 ██████ 总耗时 = 模型生成耗时 + 工具IO耗时
流水并行时序（WebSocket双向流） 模型生成token ▬▬▬▬▬▬ 工具执行 ██████ 总耗时 ≈ max(模型生成耗时,工具IO耗时)
  WebSocket支持边接收流式Token、边增量解析，识别出完整ToolCall即可异步启动工具；不需要等待本轮响应全部结束，实现耗时重叠。而SSE单向流主流实现范式都是接收完整响应后再处理。

• 网关超时不匹配长任务Nginx、云LB对普通HTTP请求默认较短超时；Agent执行沙箱代码、远程检索时常出现长时间空闲，连接极易被网关切断。WebSocket作为标准长会话，拥有独立超时配置与心跳保活机制，适配长时间运行的智能体任务。

3. WebSocket在OpenAI智能体架构中的核心价值 依托持久双向会话，支撑全文提到的整套分层优化：

1. 通过会话ID+previous_response_id标准化实现增量差分传输，无需每轮上传全部对话； 示例增量消息体（文中Harness传输格式）

{"type":"response.create","previous_response_id":"resp_abc123","input":[{"type":"function_call_output","output":"工具返回增量结果"}]}

2. 天然会话粘性，配合推理层缓存感知路由，持续命中KV Cache；
3. 全双工双向消息，实现工具IO与模型生成并行，降低端到端延迟；
4. 原生支持心跳保活，适配多轮循环、存在大量空闲等待的Agent场景。

总结区分：HTTP Keep-Alive 只优化TCP握手的微小损耗；WebSocket是整套Agent全链路优化的基础架构，是实现增量传输、时延重叠、显存缓存复用、长任务稳定运行的必要前提，二者优化层级不同，不能互相替换。

2. 稳定不变的提示词前缀

大模型厂商通用优化手段为提示词缓存：当新请求开头Token序列与历史请求完全匹配（前缀一致），直接复用已计算完成的注意力缓存状态，仅增量计算末尾新增内容。
缓存匹配规则为逐Token精准匹配，提示词前半段任意字符改动，都会导致整段缓存失效，全部内容需要重新计算。

对调度层而言，每轮组装的提示词开头必须和上一轮完全一致。这件事看似简单，但调度层每轮都会基于内存中实时状态重新构建请求，组装逻辑的微小差异都可能静默破坏缓存匹配。

OpenAI分享过真实踩坑案例：Codex早期将MCP工具定义存入哈希表，哈希表遍历顺序无固定规则，同一批工具每轮请求序列化顺序随机变更。上下文工具完全没变，仅字段顺序不同，虽不影响任务执行，但会大幅拉高算力成本。

落地规范

1. 历史对话采用仅追加模式（append-only），禁止修改前置历史内容；
2. 动态运行时配置（工具审批权限等）不写入提示词，由调度层本地逻辑处理。用户中途修改权限，不会改动上下文内的工具定义，保证提示词前缀永久固定，最大化缓存命中率。

3. 延迟工具检索（Deferred tool discovery）

稳定提示词前缀可以降低重复上下文的计算成本，但无法压缩提示词整体体积。当智能体接入上百个第三方集成、MCP服务时，所有工具完整JSON Schema全部写入提示词会造成上下文极度臃肿。每一套工具Schema包含名称、描述、参数定义，全部加载后，模型每轮都需要解析大量当前任务完全用不到的工具。

优化思路：延迟加载非核心工具，仅将高频工具常驻提示词。

1. 提示词仅保留核心工具（Shell、文件编辑），额外内置tool_search检索专用工具；
2. 其余数百套集成工具定义离线存储在工具目录，不加载进上下文；
3. 模型需要特定功能时，主动调用检索工具，传入关键词（例如「list deployments」）；
4. 调度层使用BM25词法检索算法，匹配关键词与工具描述相似度，将命中工具的Schema临时载入上下文。

配套轻量化压缩方案：

1. Schema压缩：按照Token预算裁剪工具定义，删除冗余描述、扁平化嵌套结构，仅保留核心参数名；
2. 对话压缩：超长历史对话精简为短摘要，控制上下文窗口占用。

4. Code Mode 代码运行模式

传统执行逻辑：模型单次输出一条工具调用 → 等待工具返回结果 → 再次推理生成下一条调用。很多场景下多条工具调用之间不需要模型推理判断，仅用于批量收集数据。该方案成本极高，每条工具调用都需要一次完整模型往返，且每轮工具结果持续占用上下文空间。

Code Mode优化方案：模型不再逐条输出工具调用，而是生成一段小型JS脚本；调度层内置隔离JS运行时，所有工具封装为全局可调用函数。脚本支持：

1. 并行发起多条独立工具请求；
2. 通过代码逻辑过滤、合并多条工具返回数据；
3. 仅将精简汇总后的最终结果写入对话上下文，中间临时数据保存在运行时，不占用Token。

三、API网关层优化方案

API网关是调度层直接对接的服务，部署在普通CPU服务器上，介于调度层与推理层之间。调度层发送描述会话内容的JSON数据，模型输入输出则是数字Token ID。
请求抵达API网关后，会完整执行以下流程：

1. 请求体缓存至内存；
2. JSON解析与Schema校验（字段格式、数组长度合规性等）；
3. 第二轮语义校验：当前模型是否支持请求携带的全部功能；
4. 预检流程：身份鉴权、配额限流、请求内图片内容检测；
5. 会话渲染、全文分词；同步发起两项任务：向GPU下发推理请求、提示词安全检测；
6. 推理层流式返回Token时，API网关逐行转换为文本，封装API事件推送给客户端。

上述流程会在每一轮智能体循环重复执行。推理性能不受API网关控制，网关无法加速GPU计算，唯一优化方向是尽可能减少附加延迟。API网关解析、校验、分词消耗的时间，都会转化为用户可感知的等待时长。

API网关三大优化手段

1. 仅对增量内容执行分词

模型无法识别自然文本，推理前必须转换为Token ID。分词算法复杂度为O(n)，文本越长耗时线性上涨。
无状态HTTP模式下，每一轮循环都需要对完整会话重新分词。到第20次工具调用时，API网关需要重读上万Token，只为提取一行新增工具结果。GPU仅需要新增内容，CPU却重复处理全部历史，开销随对话长度持续增加。

WebSocket长连接模式下，API网关在内存持久化已分词完成的完整Token序列：首次请求全量分词，后续仅上传新增会话片段。网关仅对增量文本分词，追加至已存储序列。单轮分词耗时不再随对话长度增长，无限趋近常数O(1)，仅取决于新增内容长度。

2. 安全检测与推理并行执行

智能体输出展示给用户前，必须完成安全校验。OpenAI在API网关内置两套分类器：图片专用检测模型、文本风险分类器（识别网络攻击、生化武器教程等违规内容）。分类器运行会消耗时间。
简单串行方案：先执行安全检测，校验通过后再启动推理。该模式会把检测耗时叠加到所有请求的首Token延迟（TTFT），但绝大多数用户请求不存在风险内容。

优化方案：安全检测与推理任务同步启动。模型处理提示词、生成首Token本身存在天然等待窗口，安全检测利用该时段同步完成，不额外增加等待时间。
两种兜底策略：

1. 通用模型：提前流式输出Token，安全检测失败时直接切断数据流；
2. 高敏感模型：缓存全部输出内容，校验通过后再推送给客户端。
   两种模式下，安全检测耗时都会隐藏在原有等待窗口内，无额外延迟。

3. 流量调度至新一代高性能CPU

企业大规模服务器集群分多年采购，会存在多代处理器硬件。调度系统默认将同配置标签机器视为同等性能，实际硬件算力差距显著。
OpenAI读取Kubernetes集群中每台服务节点的真实CPU型号，发现同标签机器混合老旧Broadwell芯片与新款Ice Lake芯片。同等负载下，老款CPU首Token延迟高出约20%，CPU占用率翻倍。

优化策略：

1. 将绝大多数业务流量调度至搭载新一代处理器的节点；
2. CPU硬件代际纳入容量规划核心指标。
   很多时候最优的软件优化，本质是更好的硬件资源调度。

四、推理层优化方案

推理层是模型真实运行载体，由大规模GPU与专用加速卡集群、配套调度服务引擎组成。模型核心计算为海量矩阵运算，可在加速卡数千核心上并行执行。
推理层职责：跨集群调度、批量处理请求、存储单会话专属计算状态、执行模型前向传播、将生成Token回传给API网关。

Token请求增速永远高于硬件扩容速度，推理层「运行慢」等同于「算力浪费」。损耗主要来自四类场景：请求分发至错误节点、内存存储无效会话状态、串行生成闲置并行算力、两类完全不同的负载共用硬件资源。

推理层四大核心优化

1. 缓存感知路由，兼顾负载均衡与缓存复用

OpenAI使用大量GPU机器承载模型服务，每条请求需要分配至其中一台节点。路由失衡会导致部分机器空闲、部分机器请求排队，闲置GPU是整套技术栈中成本最高的资源浪费。
同时存在隐性损耗：每台节点缓存近期服务会话的计算状态。若同一会话下一条请求分发至其他机器，原有缓存直接失效，新节点需要从零完整重算，即便该计算结果已存在于集群其他机器。

因此路由调度存在两大核心目标：

1. 负载均衡：将请求分发至当前最空闲的节点；
2. 缓存复用：将会话路由至已存储该对话缓存的节点。

OpenAI路由调度器对每条请求综合加权计算：节点负载、本地缓存匹配度、地理位置、剩余算力容量。仅路由逻辑优化，就大幅降低整体服务成本。

2. KV缓存精细化生命周期管理

Transformer模型每生成一个Token，都需要读取全部历史上下文注意力状态。为避免每次新Token生成重复计算注意力，服务系统将Key/Value注意力状态保存在加速卡显存中，即KV缓存。
缓存体积随对话长度线性增长，叠加集群并发会话数量，长上下文场景下缓存总大小可接近模型权重本身。若系统淘汰高复用价值的缓存会话，该对话再次发起请求时，推理层需要全额重复计算。

优化手段：基于真实线上流量轨迹管理缓存生命周期。

1. 分析生产环境请求日志，预判缓存状态的复用概率；
2. 缓存淘汰策略基于真实业务流量验证，而非主观经验；
3. 优化缓存状态在多级内存间的存储、迁移逻辑。
   核心目标：高价值热缓存长期驻留显存，同时避免显存溢出、减少缓存迁移带来的算力损耗。

3.推测性解码（Speculative decoding）

模型生成输出是串行流程：每个Token依赖前文内容。即便提示词答案极易预测（例如「法国的首都是」），大模型仍需要完整处理全部上下文、执行大规模矩阵运算才能输出单个Token，生成速度受限。

推测解码实现逻辑：

1. 使用轻量化小草稿模型预生成后续多条候选Token；
2. 主大模型单次并行前向传播，批量校验草稿模型输出；
3. 草稿预测正确则批量采纳，节省大模型逐一生成的耗时；草稿预测错误则直接丢弃，由主模型独立生成，输出质量不受任何影响。
   评估草稿模型效果的核心指标：平均接受长度，代表单次校验可一次性节省的Token生成数量。

4. 预填充（Prefill）与解码（Decode）负载分离

推理分为两个完全独立的计算阶段：

1. Prefill预填充：一次性并行处理完整输入提示词，构建KV缓存，属于计算密集型负载；
2. Decode解码生成：逐Token输出回复，反复读写显存缓存，属于内存带宽密集型负载。

两类负载硬件瓶颈完全不同，混合部署会互相抢占硬件资源，GPU利用率极低。
优化方案：集群硬件拆分，专属机器分别承载两类任务，硬件配置匹配对应负载瓶颈。

1. 一部分集群仅处理Prefill请求，硬件侧重浮点算力；
2. 另一部分集群仅负责Decode生成，硬件侧重显存带宽；
   Prefill阶段完成后，序列化KV缓存传输至解码节点，由解码节点持续流式生成Token。

五、OpenAI性能优化总结与可复用工程经验

纵观全栈三层优化，底层统一逻辑：同一份计算、传输、解析工作，绝不重复付费执行。
调度层仅传输增量内容、维持稳定提示词保证缓存生效；API网关仅对增量分词、将阻塞流程并行执行隐藏延迟；推理层会话路由复用已有缓存，避免上下文重复计算。
三层优化互相增益：调度层保障缓存不失效、API网关提升缓存命中率，最终GPU侧重复计算减少，直接降低用户使用成本。
除具体技术方案外，OpenAI工程师分享三条可落地通用工程经验：

经验1：架构优先保持简洁，拒绝过度复杂化

简洁优先级高于复杂方案。例如工具检索选用轻量BM25词法检索，而非成本更高的向量嵌入；对话压缩仅保留一套成熟方案，不提供多套自定义配置。
LLM本身具备极强语义理解能力，在模型上层叠加复杂编排逻辑，大多只会增加系统维护成本，无法带来对等收益。落地遵循：先实现最简可用版本，业务规模上涨后再迭代扩展。

经验2：用智能体优化自身技术栈，形成正向自加速循环

Codex自身参与承载它的API服务迭代重构：原本两名工程师数年的重写工作量，由Codex生成代码压缩至数月完成。推理团队使用Codex分析流量轨迹、开发底层算子。
当自动化智能体承担编码工作，开发语言不再优先选择人类易读语法，可直接选用运行效率最优的底层编程语言。整套性能优化工作形成自我加速循环。

经验3：必须端到端全局优化，拒绝单点攻坚

推理团队复盘总结：过去多次聚焦单一技术深度优化，最终整体收益远低于预期。AI全链路环环相扣，单一层次极致优化后，其余层级瓶颈会快速凸显。不存在一劳永逸的“银弹优化方案”，大幅度性能提升来自多层级微小优化叠加。
同时，所有性能改动必须使用线上真实流量压测验证，离线仿真表现优异的优化策略，落地真实业务流量后可能出现性能倒退。

六、 精简总结

本文逐层拆解了 OpenAI 针对 Agent 多轮循环搭建的三层全链路优化体系：Harness调度层、Responses API网关层、LLM推理层。整套优化的核心逻辑十分统一：杜绝重复传输、重复分词、重复模型计算，同类任务只执行一次，依靠多层优化协同降低延迟与算力成本，不存在单一性能“银弹”。

在靠近用户的Harness 调度层，依靠 WebSocket 长连接+增量消息传输减少网络开销；通过固定 Prompt 前缀保障 KV 缓存稳定命中；搭配延迟工具检索、Code Mode，精简上下文体积并减少模型往返次数。

中间API 网关层通过增量分词规避全文反复 Tokenize；将安全检测与推理并行执行掩盖阻塞耗时，并结合硬件代际进行流量调度，削减CPU侧额外延迟。

底层GPU推理层使用缓存感知路由提升会话缓存复用率；精细化管理KV缓存生命周期；借助投机解码加快Token生成；同时将 Prefill、Decode 两类异构负载集群分离，充分挖掘硬件算力。

从工程实践来看，优化应当遵循由简至繁的顺序：优先落地长连接、规范Prompt结构等低成本改造；重视端到端协同优化，单点优化很容易遭遇上下游瓶颈。同时所有性能策略不能仅依赖离线测试，必须依托真实线上流量验证效果。对于自研Agent开发者而言，这套分层思路可以直接借鉴，根据自身技术栈分步落地改造。