企业官网建设流程全解析

如果你也维护过自养Agent，应该遇到过这种尴尬：功能逻辑全通，可每次请求都像两个人第一次见面，把同样的上下文原封不动发给模型，再原封不动等它从头算一遍。我最近对自己的Agent做了一轮54次实测，把“复用”从模型输出侧挪到了协议层，结果协议字节直接砍半，延迟降到原来的七分之一，唯独主上下文一个字节都没省。这篇日志就是完整记录我这轮复用的设计思路、实测数据，以及那个让我最意外的发现——省字节和省上下文，根本不是一回事。如果你是刚开始搭Agent，或者正在被Agent的调用延迟和流量成本折腾，这篇应该能帮上忙。

1. 谁说优化Agent只能从模型侧下手：把复用瞄准协议层

1.1 自养Agent的真实瓶颈：不是模型不聪明，而是每次都在“重复劳动”

先交代一下我为什么盯上协议层。市面上聊Agent优化的文章，十个里有九个都在讲提示词工程、模型微调、思维链这些“模型侧”玩法。这些当然有用，但多数人忽略了一个更现实的问题：自养Agent的日常开销里，有相当一部分是纯重复劳动。

我手里的这个Agent是个高频轮询式的工单状态汇总助手。它的工作逻辑不复杂：每隔一段时间拉一次工单列表→把工单摘要、处理规则、历史结论拼成提示词→发给远程推理接口→拿回一段状态汇总文本→返回给调用方。听起来很顺，但问题是，两个相邻周期里的工单变化往往不到20%。也就是说，Agent有80%的输入内容是重复的，却有100%的流程要被完整走一遍。

这个“重复”里藏着两个隐形代价。一是协议代价：每次请求要把完整的上下文塞进请求体，每次响应还要把完整的结果文本传回来，字节数累加得很快。二是推理代价：同一个问题，换个时间问模型，模型还得重新读一遍、重新算一遍。尤其当远程推理接口排队严重时，那一笔等待时间才是延迟的大头。

自养Agent和调第三方API还不太一样。第三方API你只管发请求，协议栈、鉴权、路由全是别人处理；自养意味着从Agent到推理服务之间这一整条链路都是你在维护。链路越长，能压的地方越多，而协议层恰恰是一个从来没人写进优化清单的盲区。

1.2 复用的三种可能：输入复用、结果复用、连接复用

在动手之前，我把“复用”拆成了三个层面，避免一上来就抓错重点。

第一是输入复用。意思是让模型侧能共享已经处理过的前缀内容，比如某类平台自带的前缀缓存，代价很低甚至为零，但前提是推理服务必须支持这种缓存能力，而且请求前缀高度一致。我的Agent每次拼出来的提示词里，工单部分在变，单靠前缀缓存帮不上太大忙。

第二是结果复用。核心思路是：如果两个请求问的是同一个问题、且答案在有效期内没变，那就不必再去打扰模型。直接缓存上一次的模型输出。这是自己完全可控的方案，不依赖推理平台开不开放某个特性。也是我这次最终选择的路线。

第三是连接复用。比如HTTP长连接、连接池、减少TLS握手次数，能省一部分网络往返开销，但它改变不了“模型必须被重新调用一次”这个事实。省的是边缘时间，动不了主干成本。

我实际落地的是“结果复用+协议瘦身”的组合：命中缓存的时候，不再传完整请求和完整响应，只传一个短标识；推理这一跳也被彻底跳过去。这样字节和延迟都能吃到收益。

2. 54次实测是怎么组织的：测试对象、基线、数据口径

2.1 测试场景与Agent原型：一个高频轮询的工单助手

为了让结论可复现，我把测试对象限定得很死：某个内部工单Agent，干的事就是每10分钟拉一次工单数据源，然后调用远程推理服务生成一段状态汇报。汇报内容包括当前待处理工单数、超时风险项、以及最近3个小时的处理趋势。输出格式固定为结构化Markdown，长度大约在1000到1500字节左右。

为什么选这个场景？因为它足够典型。工单数量变化不大，Agent问模型的问题几乎一样，周期又短，属于最典型的“重复劳动型Agent”。在这种场景下如果协议层复用都没收益，那别的场景也就别指望了。

整个Agent部署在某个内部容器集群里，客户端通过网关访问，网关再转发给推理服务。我没有用任何特殊硬件，也没改模型本身。唯一改动的，是在网关和Agent客户端之间加了一层响应缓存模块，顺便把命中时的协议交互改成短包模式。

2.2 实验变量：协议字节、往返延迟、主上下文长度三个口径

这次实测我盯着三个指标看，一个都没多，一个都没少。

第一个是协议字节数。指从客户端到网关、再从网关回客户端的完整请求和响应原始字节数，不含TLS握手等底层开销。它反映的是线上真实的流量成本。

第二个是往返延迟。从客户端发出请求开始计时，到完整响应落地结束。包含网络传输、鉴权、缓存查询、推理排队、token生成等所有环节。用户可感知的“快慢”，就是这个数字。

第三个是主上下文长度。指Agent构造出来准备发给模型的那份提示词总字节数，包括系统提示词、工具说明、工单摘要等。它直接关联到模型服务的计费口径，也是大多数Agent优化文章里最常提到的token成本。

我知道有人会问为什么不用“首字延迟”。我的想法是：Agent这类应用对完整响应的时间更敏感，用户要的是整段汇报能出来，不是第一个字什么时候蹦出来。所以用完整往返延迟做口径，更贴近真实体验。

2.3 数据采集方式与54次样本构成

数据采集我用了两层：一层是网关日志，记录每次请求的时间戳、请求体和响应体大小；另一层是Agent侧埋点，记录缓存是否命中、主上下文长度。两边按请求ID对齐。

54次样本不是随手跑的，我把它分成了三段，每段18次：

• 前18次：改动上线前的基线数据，走完整协议、完整推理链路，不含任何缓存。
• 中间18次：只启用响应缓存，但协议还是传完整内容，用于单独观察缓存对延迟的贡献。
• 后18次：启用“缓存+协议瘦身”，命中的请求只传缓存键和增量字段。

之所以每组取18次，是考虑到一个小时内正好能跑三个完整周期，每周期内工单数据的特征又足够接近，方便做对照。当然，54次样本量不算大，结论的置信区间别吹太满，但趋势已经非常明显了。

缓存键的实现很简单，我给了它一个归一化的JSON负载做哈希：

import hashlib import json def build_cache_key(session_id: str, normalized_payload: dict) -> str: canonical = json.dumps( normalized_payload, sort_keys=True, ensure_ascii=False, separators=(",", ":") ) raw = f"{session_id}|{canonical}" return hashlib.sha256(raw.encode("utf-8")).hexdigest()

关键是那一句sort_keys=True。如果不做键排序，字段顺序一变，同一个查询就会生成两个不同的缓存键，命中率直接打折，这是第一版踩出来的问题。

3. 复用落地后的真实收益：字节砍半、延迟1/7，先看数据

3.1 总体数据对比：中位数、均值、P95

先把数据摆在前面，省得看官们猜。下表是54次实测里，基线组和完整复用组的对比结果。

延迟部分就是我标题里那句“降到1/7”的来源：TP50从480ms降到了68ms，四舍五入差不多就是七分之一。字节也确实是砍了一半以上，P95从12.5KB降到6.1KB。

主上下文那行是0%，一字节没省。这个反差炸出了整篇博文想聊的核心问题：复用动作本身带来的收益，和很多人预期的“Token更省了”完全是两码事。

再说一个真实的细节：后18次里其实有4次没命中缓存。如果把没命中的样本剔除掉，复用组的延迟中位数能进一步压到45ms左右。但我不建议这么报数，因为线上就是要带上未命中的开销一起看。任何缓存系统都有兜不住的时候，这才是真实的运行状态。

3.2 为什么协议字节能砍半：请求体瘦身、缓存键替代全文

字节砍半的关键不是压缩算法，而是“请求体里该传的东西变少了”。

基线模式下，客户端每次都要把完整提示词塞进请求体，那个7.3KB的主上下文一个字节都不能少；响应体又要完整传回模型生成的汇报结果。一来一回，流量就上去了。

启用协议瘦身之后，缓存命中的请求长这样：客户端不再传完整提示词，只传一个会话ID加一个32字节的缓存键；网关收到后去缓存里找结果，找到就直接回一个很短的响应体。翻了翻实际日志，这种短请求的请求体平均只有300字节左右，响应体也只有400字节上下。即便算上偶尔没命中时传全量数据的开销，平均下来也能做到砍半。

这个原理你能在生活里找到对应：以前你每换一个项目同事，就得把来龙去脉从头讲一遍；现在你只要说“我们上个月定的那个方案还按原样执行”，对方就懂了。协议字节省掉的不是信息，而是不需要重复表达的那部分信息。

提醒一句：不要指望所有Agent都能砍半。我这个场景的输入输出比较规整，输出格式固定，所以瘦身效果明显。如果你的Agent每次生成的文本差异很大，那命中后的收益会低不少，因为长响应体本身就是流量大头。

3.3 延迟降到1/7的底层逻辑：绕开了最贵的两次远程调用

很多人看到“延迟降到1/7”的第一反应是缓存快，但这只是表象。真正的逻辑，是我们绕开了线上链路里最贵的两段开销。

复盘一下基线延迟的构成。一次完整请求大概包括：网络握手与上传（约20ms）、网关鉴权（约5ms）、推理服务排队（约150ms到300ms）、token生成（约200ms到400ms）、响应下载（约20ms）。最贵的部分全在推理那一侧，排队加生成经常占到总时长的八成以上。

复用命中之后，推理服务根本不参与。网关直接从本地缓存里捞结果，剩下的只有网络传输、缓存查询、鉴权这些轻量操作。就好比去餐馆吃饭，如果这道菜已经提前做好放在保温柜里，你进去就能端走，不用等后厨从头开火。

所以延迟收益的本质不是“跑得更快”，而是“少跑了一段最远的路”。这一点对有自养推理服务的人尤其重要——你的排队长短受并发影响波动很大，缓存能把高峰期的一部分请求直接挡在推理队列之外，变相增强了整体吞吐能力。

4. 主上下文一字节没省：这口锅到底该谁来背

4.1 复用的是结果不是输入：对“上下文”的定义要拆清

我承认，第一版上线时我心里是有点幻想的：以为缓存都命中了，用量应该全面下降。结果看监控的时候，主上下文那一行纹丝不动，属实被现实教育了一下。

后来一想，这个结果在逻辑上完全成立。响应缓存缓存的是“模型已经算出来的答案”，不是“发给模型的问题”。命中的时候，我们压根就没构造上下文，模型也没见过这份提示词。它省的是推理和执行，而不是省掉“下次还需要构造的那份输入”。

主上下文是另一个维度的东西。它是一份客观存在的文本，不管模型调不调用它，Agent在拼提示词的时候就得把它拼出来。你缓存了模型对上一轮的输出，下一轮如果没命中，还是要原样把主上下文发出去。所以主上下文长度不变，不是因为缓存没用，而是因为它属于另一个优化范畴。

这就像你有一个书架，上面摆满了参考书。响应缓存相当于你在某页贴了便利贴，注明“这个问题的答案在这页”，但书本身还在那里，该占多大地方还是多大。

4.2 主上下文的真实浪费点：历史消息、工具说明、系统提示词

既然主上下文没省，那总得看看钱到底花在哪。我拆了一下那个7.3KB的上下文结构：

• 系统提示词：1.2KB，描述Agent的角色、语气、汇报格式。
• 工具说明：2.5KB，告诉模型它有什么工具、工具参数怎么填。
• 工单摘要：3.3KB，当前工单列表的摘要和分类。
• 历史决策：0.3KB，上一轮Agent自己做了什么判断。

真正的动态数据只有工单摘要的3.3KB，剩下4KB全是“每次都是这么写”的固定内容。也就是说，即便你把工单数据优化到极致，主上下文里也有一半以上的字节是恒定开销。

这类恒定内容在Agent项目里特别容易被忽视，因为它已经变成了“习惯性的上下文”。但恰恰是它把主上下文基数顶得很高。真想压缩主上下文，方向不是把提示词写得更好，而是要让这4KB的固定内容变得更短，或者干脆不放进每次的请求里。这属于模型侧和记忆层的工程优化，和协议层的复用完全两条线。

4.3 字节省了为什么费用没省：计费口径与优化目标的错位

我见过不少同行做优化，指标选得很漂亮，但最后一算账没省多少钱，原因就是“优化错了口径”。

模型服务的计费是按token算的，token数主要由发给模型的输入上下文和模型生成的输出决定，协议上传输的字节数不是所有平台的计费依据。我的协议字节砍半，反应到账单上，只有缓存完全命中、模型调用被跳过的部分才真正省了费用。而那些没命中、不得不走推理的请求，主上下文有多少钱就付多少钱，一分不差。

换句话说，协议字节和主上下文Token是两个口径的事。流量账单省了，模型账单没动，才是这次实测最真实的财务结果。

这也给所有做Agent优化的人提了个醒：动手之前先想清楚，你到底要优化哪个数字。是省流量，那就重点压协议体；是省延迟，那就上结果复用和连接优化；是想省模型费用，那真正的硬骨头在主上下文压缩和缓存被跳过时的推理优化上。这几个目标各有各的办法，混在一起做，最后很可能像我这轮一样只省了一半。

5. 从这轮测试里我学到的判断原则：什么该复用，什么不该复用

5.1 响应缓存的价值边界：高重复率、低时效性、稳定输出

54次实测跑完，我总结出一个判断标准：一个Agent任务适不适合上响应缓存，就看三条。

第一是请求重复率要够高。如果同一个问题在短时间窗口里反复出现，缓存才有机会发挥作用。那种每次都要问新问题的对话型Agent，命中率会低到很难看，缓存不仅没省事，还会平白多一次查询开销。

第二是时效性容忍度要够大。我这个工单Agent十分钟左右跑一轮，答案晚几十秒完全无所谓。如果换成一个实时库存查询Agent，数据每秒都在变，缓存里的答案刚写进去就已经过期了，这种场景绝不能硬套。

第三是输出格式要稳定。格式越固定，缓存的价值越能体现出来。因为格式稳定意味着你可以安全地复用整段输出，而不用做额外解析和拼接。

我在下表里把这个判断标准整理了一下，方便对照自己的项目：

5.2 缓存污染与过期策略：我踩过的一次脏缓存事故

这轮测试过程中，我真实踩过一次缓存污染，差点把线上的汇报结果带偏，值得单独记一笔。

当时我在缓存键里加了时间戳字段，本意是防止数据过期，结果反而出问题。某个工单周期里，状态已经变更了，但由于工单页本身发生了一次没有变化的伪更新，缓存键被判定为“没变”，Agent照样返回了上一轮的旧汇报。要不是人工抽查时发现数字对不上，这个错误可能要挂在线上一整天。

排查链路是这样的：先看网关日志，确认请求是命中了缓存；再看缓存键生成逻辑，确认工单状态字段没有参与哈希；最后才发现问题出在“工单数据没变”的判定条件太宽。

修复方案是给缓存键加上“业务数据指纹”，把工单状态、数量、更新时间等关键业务字段单独拉出来参与哈希，而不是简单哈希整个请求。同时把缓存TTL从5分钟压缩到90秒，并在网关层加了一个强制绕过的调试参数：只要带上bypass_cache=1，请求就强制走完整推理链路。这样线上发现问题时，我能第一时间绕过缓存，不用等缓存自然过期。

缓存优化做久了容易产生一个误区：命中率越高越好。但命中率只是表，数据质量才是里。缓存喂给Agent一份过期的错误答案，省下的延迟和字节没有任何意义。

5.3 下一步：把省下来的延迟和字节导向更深的上下文压缩

延迟和字节的收益已经吃到嘴了，但我不打算就此收手。原因很简单：它们已经进入平台期，再扣也就是几毫秒和几百字节的事。

下一轮我准备集中做上下文压缩。方向很明确：把4KB固定内容砍到一半。工具说明准备改成按需动态注入，平时没用到工具就不放进提示词；系统提示词打算做一轮瘦身，把那些“背景解释”类文字压缩成一句话；历史决策则改成结构化的摘要对象，而不是大段文字。

这么做之后，主上下文这个指标才会真正开始往下降。协议层的复用解决的是“重复计算”的问题，上下文压缩解决的才是“不必要的思考负担”问题。

最后想给同行们一个实在的建议：做Agent优化先分清楚你的优化对象。到底是想省流量、省时间，还是省模型的注意力？这三个目标没有哪个能包打天下的方案，盲目上线复用，很可能像我一样，字节已经优化得很漂亮了，抬头一看，主上下文还是那个7.3KB，纹丝不动。字节省了，脑子没省，这才是自养Agent优化的下一站。