目录ChatGPT 如何优化智能体循环调度层、接口与推理层全解析开篇一、AI智能体应用整体架构拆解为什么不能直接把请求丢给LLM单次请求完整流转示例二、调度层Harness优化方案调度层四大性能优化手段1. 持久WebSocket 增量差分请求优化解决方案1. HTTP Keep-Alive 的能力边界 Keep-Alive 作用仅局限于 TCP 链路复用不会改变 HTTP 协议与生俱来的约束协议要求每次请求必须自包含、无状态。即便 TCP 通道不断开每一轮 Agent2. 即便HTTP增加服务端Session缓存依然存在架构硬伤 不少人设想方案HTTPKeep-Alive SessionID服务端缓存对话每次只上传增量消息。这套方案可以简易跑通但在大规模Agent集群下难以落地3. WebSocket在OpenAI智能体架构中的核心价值 依托持久双向会话支撑全文提到的整套分层优化2. 稳定不变的提示词前缀落地规范3. 延迟工具检索Deferred tool discovery4. Code Mode 代码运行模式三、API网关层优化方案API网关三大优化手段1. 仅对增量内容执行分词2. 安全检测与推理并行执行3. 流量调度至新一代高性能CPU四、推理层优化方案推理层四大核心优化1. 缓存感知路由兼顾负载均衡与缓存复用2. KV缓存精细化生命周期管理3.推测性解码Speculative decoding4. 预填充Prefill与解码Decode负载分离五、OpenAI性能优化总结与可复用工程经验经验1架构优先保持简洁拒绝过度复杂化经验2用智能体优化自身技术栈形成正向自加速循环经验3必须端到端全局优化拒绝单点攻坚六、 精简总结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 5OpenAI推出GPT-5.6全系包含目前最强的GPT-5.6 SolKimi上线Kimi K3Opus 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、编写修复补丁、执行全量测试」完整走一遍请求链路调度层整合指令、工具定义、用户任务组装请求发送至API网关API网关将请求缓存至内存解析并校验JSON格式合规、当前模型支持所有请求功能校验调用身份、执行限流预检API网关将会话渲染为模型输入格式完成全文分词API网关同步发起两项操作向推理层下发Token、启动安全检测分类器识别网络攻击、生化武器相关违规内容安全检测需要赶在首Token生成前完成推理层处理提示词并开始生成内容本次输出并非最终答案而是工具调用指令检索代码中「结账超时」相关逻辑生成的Token流逐层回传至API网关API网关将Token还原为文本封装标准化API事件流式事件持续推送到调度层调度层识别工具调用在隔离沙箱执行代码检索将输出追加至会话把更新后的对话重新发给API网关。以上仅为一轮循环。真实业务中一项任务会重复该流程数十次直到模型输出最终总结调度层将结果返还用户。每一轮迭代都会重复大量相同操作重复上传历史对话、重复对全文分词、重复处理提示词。消除重复工作就是性能优化的核心突破口。下文分三层介绍OpenAI落地的全套优化手段。二、调度层Harness优化方案调度层是离用户最近的编排模块负责将原始用户请求组装为模型上下文循环与LLM交互直至任务完成。它有两大核心职责会话唯一数据源完整保存所有指令、对话消息、工具调用记录、工具返回结果是会话信息的权威存储驱动智能体循环决定发送给LLM的上下文内容指令、工具定义、历史长度、发起请求、接收流式响应并解析、监控工具调用识别工具调用后在沙箱按权限执行、追加结果、重新发起模型请求循环至任务结束。复杂任务理论上会循环100次以上每一轮都会产生额外开销。例如单次模型调用多1秒延迟长任务整体会增加半分钟等待时长。调度层四大性能优化手段从调度层视角延迟来源分为四类网络传输、提示词处理、上下文体积、循环往返次数。OpenAI落地四项核心优化。1. 持久WebSocket 增量差分请求调度层运行在用户设备模型部署在OpenAI数据中心每次模型调用都需要跨网络传输数据。传统传输方案基于HTTPS调度层建立连接发送包含服务端所需全部信息的请求接收返回结果。大模型输出Token是分段流式返回聊天应用通常在HTTPS之上使用SSE服务器推送事件。SSE为单向通信非常适合传统聊天场景一条用户消息对应一次模型调用、一轮流式回复。但智能体并非单次交互单轮Codex任务会触发数十次模型调用。基于HTTPS的方案会带来两类额外成本连接建立开销新建HTTPS连接需要TCP握手TLS加密握手在传输有效数据前完成多轮网络往返。单次聊天消息仅一次尚可接受单会话数十次调用会造成巨额网络损耗载荷重复传输HTTP无状态每次请求必须携带服务端需要的全部数据系统指令、工具定义、全部历史对话。到第20次工具调用时调度层仅新增一行工具结果却需要重新上传原始提示词、前19轮全部工具调用与返回数据上传体积持续膨胀不断重复上传服务端已存储的内容。优化解决方案解决连接损耗使用长连接复用也就是WebSocket。仅需一次初始握手会话生命周期内双方可随时收发消息无需每次重建连接。Codex会为单任务会话维持一条固定WebSocket连接覆盖所有模型调用彻底消除重复TCP/TLS握手解决载荷重复停止重复上传服务端已保存的会话数据。调度层缓存上一轮完整请求与响应若仅对话内容发生变更仅上传新增数据并携带上一轮会话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缓存依然存在架构硬伤 不少人设想方案HTTPKeep-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智能体架构中的核心价值 依托持久双向会话支撑全文提到的整套分层优化通过会话IDprevious_response_id标准化实现增量差分传输无需每轮上传全部对话 示例增量消息体文中Harness传输格式{type:response.create,previous_response_id:resp_abc123,input:[{type:function_call_output,output:工具返回增量结果}]}天然会话粘性配合推理层缓存感知路由持续命中KV Cache全双工双向消息实现工具IO与模型生成并行降低端到端延迟原生支持心跳保活适配多轮循环、存在大量空闲等待的Agent场景。总结区分HTTP Keep-Alive 只优化TCP握手的微小损耗WebSocket是整套Agent全链路优化的基础架构是实现增量传输、时延重叠、显存缓存复用、长任务稳定运行的必要前提二者优化层级不同不能互相替换。2. 稳定不变的提示词前缀大模型厂商通用优化手段为提示词缓存当新请求开头Token序列与历史请求完全匹配前缀一致直接复用已计算完成的注意力缓存状态仅增量计算末尾新增内容。缓存匹配规则为逐Token精准匹配提示词前半段任意字符改动都会导致整段缓存失效全部内容需要重新计算。对调度层而言每轮组装的提示词开头必须和上一轮完全一致。这件事看似简单但调度层每轮都会基于内存中实时状态重新构建请求组装逻辑的微小差异都可能静默破坏缓存匹配。OpenAI分享过真实踩坑案例Codex早期将MCP工具定义存入哈希表哈希表遍历顺序无固定规则同一批工具每轮请求序列化顺序随机变更。上下文工具完全没变仅字段顺序不同虽不影响任务执行但会大幅拉高算力成本。落地规范历史对话采用仅追加模式append-only禁止修改前置历史内容动态运行时配置工具审批权限等不写入提示词由调度层本地逻辑处理。用户中途修改权限不会改动上下文内的工具定义保证提示词前缀永久固定最大化缓存命中率。3. 延迟工具检索Deferred tool discovery稳定提示词前缀可以降低重复上下文的计算成本但无法压缩提示词整体体积。当智能体接入上百个第三方集成、MCP服务时所有工具完整JSON Schema全部写入提示词会造成上下文极度臃肿。每一套工具Schema包含名称、描述、参数定义全部加载后模型每轮都需要解析大量当前任务完全用不到的工具。优化思路延迟加载非核心工具仅将高频工具常驻提示词。提示词仅保留核心工具Shell、文件编辑额外内置tool_search检索专用工具其余数百套集成工具定义离线存储在工具目录不加载进上下文模型需要特定功能时主动调用检索工具传入关键词例如「list deployments」调度层使用BM25词法检索算法匹配关键词与工具描述相似度将命中工具的Schema临时载入上下文。配套轻量化压缩方案Schema压缩按照Token预算裁剪工具定义删除冗余描述、扁平化嵌套结构仅保留核心参数名对话压缩超长历史对话精简为短摘要控制上下文窗口占用。4. Code Mode 代码运行模式传统执行逻辑模型单次输出一条工具调用 → 等待工具返回结果 → 再次推理生成下一条调用。很多场景下多条工具调用之间不需要模型推理判断仅用于批量收集数据。该方案成本极高每条工具调用都需要一次完整模型往返且每轮工具结果持续占用上下文空间。Code Mode优化方案模型不再逐条输出工具调用而是生成一段小型JS脚本调度层内置隔离JS运行时所有工具封装为全局可调用函数。脚本支持并行发起多条独立工具请求通过代码逻辑过滤、合并多条工具返回数据仅将精简汇总后的最终结果写入对话上下文中间临时数据保存在运行时不占用Token。三、API网关层优化方案API网关是调度层直接对接的服务部署在普通CPU服务器上介于调度层与推理层之间。调度层发送描述会话内容的JSON数据模型输入输出则是数字Token ID。请求抵达API网关后会完整执行以下流程请求体缓存至内存JSON解析与Schema校验字段格式、数组长度合规性等第二轮语义校验当前模型是否支持请求携带的全部功能预检流程身份鉴权、配额限流、请求内图片内容检测会话渲染、全文分词同步发起两项任务向GPU下发推理请求、提示词安全检测推理层流式返回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本身存在天然等待窗口安全检测利用该时段同步完成不额外增加等待时间。两种兜底策略通用模型提前流式输出Token安全检测失败时直接切断数据流高敏感模型缓存全部输出内容校验通过后再推送给客户端。两种模式下安全检测耗时都会隐藏在原有等待窗口内无额外延迟。3. 流量调度至新一代高性能CPU企业大规模服务器集群分多年采购会存在多代处理器硬件。调度系统默认将同配置标签机器视为同等性能实际硬件算力差距显著。OpenAI读取Kubernetes集群中每台服务节点的真实CPU型号发现同标签机器混合老旧Broadwell芯片与新款Ice Lake芯片。同等负载下老款CPU首Token延迟高出约20%CPU占用率翻倍。优化策略将绝大多数业务流量调度至搭载新一代处理器的节点CPU硬件代际纳入容量规划核心指标。很多时候最优的软件优化本质是更好的硬件资源调度。四、推理层优化方案推理层是模型真实运行载体由大规模GPU与专用加速卡集群、配套调度服务引擎组成。模型核心计算为海量矩阵运算可在加速卡数千核心上并行执行。推理层职责跨集群调度、批量处理请求、存储单会话专属计算状态、执行模型前向传播、将生成Token回传给API网关。Token请求增速永远高于硬件扩容速度推理层「运行慢」等同于「算力浪费」。损耗主要来自四类场景请求分发至错误节点、内存存储无效会话状态、串行生成闲置并行算力、两类完全不同的负载共用硬件资源。推理层四大核心优化1. 缓存感知路由兼顾负载均衡与缓存复用OpenAI使用大量GPU机器承载模型服务每条请求需要分配至其中一台节点。路由失衡会导致部分机器空闲、部分机器请求排队闲置GPU是整套技术栈中成本最高的资源浪费。同时存在隐性损耗每台节点缓存近期服务会话的计算状态。若同一会话下一条请求分发至其他机器原有缓存直接失效新节点需要从零完整重算即便该计算结果已存在于集群其他机器。因此路由调度存在两大核心目标负载均衡将请求分发至当前最空闲的节点缓存复用将会话路由至已存储该对话缓存的节点。OpenAI路由调度器对每条请求综合加权计算节点负载、本地缓存匹配度、地理位置、剩余算力容量。仅路由逻辑优化就大幅降低整体服务成本。2. KV缓存精细化生命周期管理Transformer模型每生成一个Token都需要读取全部历史上下文注意力状态。为避免每次新Token生成重复计算注意力服务系统将Key/Value注意力状态保存在加速卡显存中即KV缓存。缓存体积随对话长度线性增长叠加集群并发会话数量长上下文场景下缓存总大小可接近模型权重本身。若系统淘汰高复用价值的缓存会话该对话再次发起请求时推理层需要全额重复计算。优化手段基于真实线上流量轨迹管理缓存生命周期。分析生产环境请求日志预判缓存状态的复用概率缓存淘汰策略基于真实业务流量验证而非主观经验优化缓存状态在多级内存间的存储、迁移逻辑。核心目标高价值热缓存长期驻留显存同时避免显存溢出、减少缓存迁移带来的算力损耗。3.推测性解码Speculative decoding模型生成输出是串行流程每个Token依赖前文内容。即便提示词答案极易预测例如「法国的首都是」大模型仍需要完整处理全部上下文、执行大规模矩阵运算才能输出单个Token生成速度受限。推测解码实现逻辑使用轻量化小草稿模型预生成后续多条候选Token主大模型单次并行前向传播批量校验草稿模型输出草稿预测正确则批量采纳节省大模型逐一生成的耗时草稿预测错误则直接丢弃由主模型独立生成输出质量不受任何影响。评估草稿模型效果的核心指标平均接受长度代表单次校验可一次性节省的Token生成数量。4. 预填充Prefill与解码Decode负载分离推理分为两个完全独立的计算阶段Prefill预填充一次性并行处理完整输入提示词构建KV缓存属于计算密集型负载Decode解码生成逐Token输出回复反复读写显存缓存属于内存带宽密集型负载。两类负载硬件瓶颈完全不同混合部署会互相抢占硬件资源GPU利用率极低。优化方案集群硬件拆分专属机器分别承载两类任务硬件配置匹配对应负载瓶颈。一部分集群仅处理Prefill请求硬件侧重浮点算力另一部分集群仅负责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开发者而言这套分层思路可以直接借鉴根据自身技术栈分步落地改造。
【解读ByteByteGo 长文】ChatGPT Agent Loop 深度性能优化全解：Harness、API 与推理三层工程落地
目录ChatGPT 如何优化智能体循环调度层、接口与推理层全解析开篇一、AI智能体应用整体架构拆解为什么不能直接把请求丢给LLM单次请求完整流转示例二、调度层Harness优化方案调度层四大性能优化手段1. 持久WebSocket 增量差分请求优化解决方案1. HTTP Keep-Alive 的能力边界 Keep-Alive 作用仅局限于 TCP 链路复用不会改变 HTTP 协议与生俱来的约束协议要求每次请求必须自包含、无状态。即便 TCP 通道不断开每一轮 Agent2. 即便HTTP增加服务端Session缓存依然存在架构硬伤 不少人设想方案HTTPKeep-Alive SessionID服务端缓存对话每次只上传增量消息。这套方案可以简易跑通但在大规模Agent集群下难以落地3. WebSocket在OpenAI智能体架构中的核心价值 依托持久双向会话支撑全文提到的整套分层优化2. 稳定不变的提示词前缀落地规范3. 延迟工具检索Deferred tool discovery4. Code Mode 代码运行模式三、API网关层优化方案API网关三大优化手段1. 仅对增量内容执行分词2. 安全检测与推理并行执行3. 流量调度至新一代高性能CPU四、推理层优化方案推理层四大核心优化1. 缓存感知路由兼顾负载均衡与缓存复用2. KV缓存精细化生命周期管理3.推测性解码Speculative decoding4. 预填充Prefill与解码Decode负载分离五、OpenAI性能优化总结与可复用工程经验经验1架构优先保持简洁拒绝过度复杂化经验2用智能体优化自身技术栈形成正向自加速循环经验3必须端到端全局优化拒绝单点攻坚六、 精简总结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 5OpenAI推出GPT-5.6全系包含目前最强的GPT-5.6 SolKimi上线Kimi K3Opus 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、编写修复补丁、执行全量测试」完整走一遍请求链路调度层整合指令、工具定义、用户任务组装请求发送至API网关API网关将请求缓存至内存解析并校验JSON格式合规、当前模型支持所有请求功能校验调用身份、执行限流预检API网关将会话渲染为模型输入格式完成全文分词API网关同步发起两项操作向推理层下发Token、启动安全检测分类器识别网络攻击、生化武器相关违规内容安全检测需要赶在首Token生成前完成推理层处理提示词并开始生成内容本次输出并非最终答案而是工具调用指令检索代码中「结账超时」相关逻辑生成的Token流逐层回传至API网关API网关将Token还原为文本封装标准化API事件流式事件持续推送到调度层调度层识别工具调用在隔离沙箱执行代码检索将输出追加至会话把更新后的对话重新发给API网关。以上仅为一轮循环。真实业务中一项任务会重复该流程数十次直到模型输出最终总结调度层将结果返还用户。每一轮迭代都会重复大量相同操作重复上传历史对话、重复对全文分词、重复处理提示词。消除重复工作就是性能优化的核心突破口。下文分三层介绍OpenAI落地的全套优化手段。二、调度层Harness优化方案调度层是离用户最近的编排模块负责将原始用户请求组装为模型上下文循环与LLM交互直至任务完成。它有两大核心职责会话唯一数据源完整保存所有指令、对话消息、工具调用记录、工具返回结果是会话信息的权威存储驱动智能体循环决定发送给LLM的上下文内容指令、工具定义、历史长度、发起请求、接收流式响应并解析、监控工具调用识别工具调用后在沙箱按权限执行、追加结果、重新发起模型请求循环至任务结束。复杂任务理论上会循环100次以上每一轮都会产生额外开销。例如单次模型调用多1秒延迟长任务整体会增加半分钟等待时长。调度层四大性能优化手段从调度层视角延迟来源分为四类网络传输、提示词处理、上下文体积、循环往返次数。OpenAI落地四项核心优化。1. 持久WebSocket 增量差分请求调度层运行在用户设备模型部署在OpenAI数据中心每次模型调用都需要跨网络传输数据。传统传输方案基于HTTPS调度层建立连接发送包含服务端所需全部信息的请求接收返回结果。大模型输出Token是分段流式返回聊天应用通常在HTTPS之上使用SSE服务器推送事件。SSE为单向通信非常适合传统聊天场景一条用户消息对应一次模型调用、一轮流式回复。但智能体并非单次交互单轮Codex任务会触发数十次模型调用。基于HTTPS的方案会带来两类额外成本连接建立开销新建HTTPS连接需要TCP握手TLS加密握手在传输有效数据前完成多轮网络往返。单次聊天消息仅一次尚可接受单会话数十次调用会造成巨额网络损耗载荷重复传输HTTP无状态每次请求必须携带服务端需要的全部数据系统指令、工具定义、全部历史对话。到第20次工具调用时调度层仅新增一行工具结果却需要重新上传原始提示词、前19轮全部工具调用与返回数据上传体积持续膨胀不断重复上传服务端已存储的内容。优化解决方案解决连接损耗使用长连接复用也就是WebSocket。仅需一次初始握手会话生命周期内双方可随时收发消息无需每次重建连接。Codex会为单任务会话维持一条固定WebSocket连接覆盖所有模型调用彻底消除重复TCP/TLS握手解决载荷重复停止重复上传服务端已保存的会话数据。调度层缓存上一轮完整请求与响应若仅对话内容发生变更仅上传新增数据并携带上一轮会话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缓存依然存在架构硬伤 不少人设想方案HTTPKeep-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智能体架构中的核心价值 依托持久双向会话支撑全文提到的整套分层优化通过会话IDprevious_response_id标准化实现增量差分传输无需每轮上传全部对话 示例增量消息体文中Harness传输格式{type:response.create,previous_response_id:resp_abc123,input:[{type:function_call_output,output:工具返回增量结果}]}天然会话粘性配合推理层缓存感知路由持续命中KV Cache全双工双向消息实现工具IO与模型生成并行降低端到端延迟原生支持心跳保活适配多轮循环、存在大量空闲等待的Agent场景。总结区分HTTP Keep-Alive 只优化TCP握手的微小损耗WebSocket是整套Agent全链路优化的基础架构是实现增量传输、时延重叠、显存缓存复用、长任务稳定运行的必要前提二者优化层级不同不能互相替换。2. 稳定不变的提示词前缀大模型厂商通用优化手段为提示词缓存当新请求开头Token序列与历史请求完全匹配前缀一致直接复用已计算完成的注意力缓存状态仅增量计算末尾新增内容。缓存匹配规则为逐Token精准匹配提示词前半段任意字符改动都会导致整段缓存失效全部内容需要重新计算。对调度层而言每轮组装的提示词开头必须和上一轮完全一致。这件事看似简单但调度层每轮都会基于内存中实时状态重新构建请求组装逻辑的微小差异都可能静默破坏缓存匹配。OpenAI分享过真实踩坑案例Codex早期将MCP工具定义存入哈希表哈希表遍历顺序无固定规则同一批工具每轮请求序列化顺序随机变更。上下文工具完全没变仅字段顺序不同虽不影响任务执行但会大幅拉高算力成本。落地规范历史对话采用仅追加模式append-only禁止修改前置历史内容动态运行时配置工具审批权限等不写入提示词由调度层本地逻辑处理。用户中途修改权限不会改动上下文内的工具定义保证提示词前缀永久固定最大化缓存命中率。3. 延迟工具检索Deferred tool discovery稳定提示词前缀可以降低重复上下文的计算成本但无法压缩提示词整体体积。当智能体接入上百个第三方集成、MCP服务时所有工具完整JSON Schema全部写入提示词会造成上下文极度臃肿。每一套工具Schema包含名称、描述、参数定义全部加载后模型每轮都需要解析大量当前任务完全用不到的工具。优化思路延迟加载非核心工具仅将高频工具常驻提示词。提示词仅保留核心工具Shell、文件编辑额外内置tool_search检索专用工具其余数百套集成工具定义离线存储在工具目录不加载进上下文模型需要特定功能时主动调用检索工具传入关键词例如「list deployments」调度层使用BM25词法检索算法匹配关键词与工具描述相似度将命中工具的Schema临时载入上下文。配套轻量化压缩方案Schema压缩按照Token预算裁剪工具定义删除冗余描述、扁平化嵌套结构仅保留核心参数名对话压缩超长历史对话精简为短摘要控制上下文窗口占用。4. Code Mode 代码运行模式传统执行逻辑模型单次输出一条工具调用 → 等待工具返回结果 → 再次推理生成下一条调用。很多场景下多条工具调用之间不需要模型推理判断仅用于批量收集数据。该方案成本极高每条工具调用都需要一次完整模型往返且每轮工具结果持续占用上下文空间。Code Mode优化方案模型不再逐条输出工具调用而是生成一段小型JS脚本调度层内置隔离JS运行时所有工具封装为全局可调用函数。脚本支持并行发起多条独立工具请求通过代码逻辑过滤、合并多条工具返回数据仅将精简汇总后的最终结果写入对话上下文中间临时数据保存在运行时不占用Token。三、API网关层优化方案API网关是调度层直接对接的服务部署在普通CPU服务器上介于调度层与推理层之间。调度层发送描述会话内容的JSON数据模型输入输出则是数字Token ID。请求抵达API网关后会完整执行以下流程请求体缓存至内存JSON解析与Schema校验字段格式、数组长度合规性等第二轮语义校验当前模型是否支持请求携带的全部功能预检流程身份鉴权、配额限流、请求内图片内容检测会话渲染、全文分词同步发起两项任务向GPU下发推理请求、提示词安全检测推理层流式返回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本身存在天然等待窗口安全检测利用该时段同步完成不额外增加等待时间。两种兜底策略通用模型提前流式输出Token安全检测失败时直接切断数据流高敏感模型缓存全部输出内容校验通过后再推送给客户端。两种模式下安全检测耗时都会隐藏在原有等待窗口内无额外延迟。3. 流量调度至新一代高性能CPU企业大规模服务器集群分多年采购会存在多代处理器硬件。调度系统默认将同配置标签机器视为同等性能实际硬件算力差距显著。OpenAI读取Kubernetes集群中每台服务节点的真实CPU型号发现同标签机器混合老旧Broadwell芯片与新款Ice Lake芯片。同等负载下老款CPU首Token延迟高出约20%CPU占用率翻倍。优化策略将绝大多数业务流量调度至搭载新一代处理器的节点CPU硬件代际纳入容量规划核心指标。很多时候最优的软件优化本质是更好的硬件资源调度。四、推理层优化方案推理层是模型真实运行载体由大规模GPU与专用加速卡集群、配套调度服务引擎组成。模型核心计算为海量矩阵运算可在加速卡数千核心上并行执行。推理层职责跨集群调度、批量处理请求、存储单会话专属计算状态、执行模型前向传播、将生成Token回传给API网关。Token请求增速永远高于硬件扩容速度推理层「运行慢」等同于「算力浪费」。损耗主要来自四类场景请求分发至错误节点、内存存储无效会话状态、串行生成闲置并行算力、两类完全不同的负载共用硬件资源。推理层四大核心优化1. 缓存感知路由兼顾负载均衡与缓存复用OpenAI使用大量GPU机器承载模型服务每条请求需要分配至其中一台节点。路由失衡会导致部分机器空闲、部分机器请求排队闲置GPU是整套技术栈中成本最高的资源浪费。同时存在隐性损耗每台节点缓存近期服务会话的计算状态。若同一会话下一条请求分发至其他机器原有缓存直接失效新节点需要从零完整重算即便该计算结果已存在于集群其他机器。因此路由调度存在两大核心目标负载均衡将请求分发至当前最空闲的节点缓存复用将会话路由至已存储该对话缓存的节点。OpenAI路由调度器对每条请求综合加权计算节点负载、本地缓存匹配度、地理位置、剩余算力容量。仅路由逻辑优化就大幅降低整体服务成本。2. KV缓存精细化生命周期管理Transformer模型每生成一个Token都需要读取全部历史上下文注意力状态。为避免每次新Token生成重复计算注意力服务系统将Key/Value注意力状态保存在加速卡显存中即KV缓存。缓存体积随对话长度线性增长叠加集群并发会话数量长上下文场景下缓存总大小可接近模型权重本身。若系统淘汰高复用价值的缓存会话该对话再次发起请求时推理层需要全额重复计算。优化手段基于真实线上流量轨迹管理缓存生命周期。分析生产环境请求日志预判缓存状态的复用概率缓存淘汰策略基于真实业务流量验证而非主观经验优化缓存状态在多级内存间的存储、迁移逻辑。核心目标高价值热缓存长期驻留显存同时避免显存溢出、减少缓存迁移带来的算力损耗。3.推测性解码Speculative decoding模型生成输出是串行流程每个Token依赖前文内容。即便提示词答案极易预测例如「法国的首都是」大模型仍需要完整处理全部上下文、执行大规模矩阵运算才能输出单个Token生成速度受限。推测解码实现逻辑使用轻量化小草稿模型预生成后续多条候选Token主大模型单次并行前向传播批量校验草稿模型输出草稿预测正确则批量采纳节省大模型逐一生成的耗时草稿预测错误则直接丢弃由主模型独立生成输出质量不受任何影响。评估草稿模型效果的核心指标平均接受长度代表单次校验可一次性节省的Token生成数量。4. 预填充Prefill与解码Decode负载分离推理分为两个完全独立的计算阶段Prefill预填充一次性并行处理完整输入提示词构建KV缓存属于计算密集型负载Decode解码生成逐Token输出回复反复读写显存缓存属于内存带宽密集型负载。两类负载硬件瓶颈完全不同混合部署会互相抢占硬件资源GPU利用率极低。优化方案集群硬件拆分专属机器分别承载两类任务硬件配置匹配对应负载瓶颈。一部分集群仅处理Prefill请求硬件侧重浮点算力另一部分集群仅负责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开发者而言这套分层思路可以直接借鉴根据自身技术栈分步落地改造。
