企业官网建设流程全解析

我经常在群里跟人聊Agent落地的经验，最近做了一个自养Agent项目的协议层优化，连续测了54次，数据有点意思：协议传输字节直接砍掉了一半，端到端延迟降到原来的七分之一左右。但让我最清醒的并不是这些漂亮的数字，而是测完之后发现，主上下文消耗一字节都没省下来。这篇文章就把整个过程拆开讲一遍，包括复用方案的设计思路、54次实测的实验方法和结果、以及那些只有动手做才会踩到的坑。

很多人在优化Agent时，第一反应都是去压缩发给大模型的prompt，觉得token少了就省钱省延迟。但我的这次优化完全没碰主上下文，动的是Agent节点之间通信的那套“线上协议”。两者是两笔完全不同的账，理解清楚这个区别，你才能真正意识到该怎么分配优化精力。

1. 项目到底在优化什么：先看清“协议字节”和“主上下文”是两笔账

1.1 我自养的Agent是怎么通信的

先交代一下背景。这个自养Agent不是单一大模型直连，而是一个由多个子Agent协作的系统。主控Agent负责接收用户请求、拆解任务、调度各个专长Agent去执行，然后把结果汇总返回。子Agent之间、子Agent与主控之间的通信，走的是我自定义的一套JSON协议，本质上是把“谁发的、发给谁、需要什么工具、携带什么上下文、返回什么状态”这些信息封装成结构化消息。

这套系统跑起来之后，我抓了一下网络流量，吓了一跳。一个很普通的工具调用链路，子Agent向主控上报状态时，协议消息里往往动不动就是十几KB甚至几十KB。因为每个消息都是独立构造的，状态信息、系统描述、工具定义、历史摘要、上下文标记这些数据，每条消息里都会完整地重复一遍。

主上下文呢，是指真正塞进大模型输入窗口的token序列。包括system prompt、工具定义、对话历史、当前任务状态。这部分的字节数取决于模型输入，和节点之间传输的协议数据没有直接关系。我当时的困惑就在于：既然协议流量这么大，是不是说明我可以先在协议层做优化，让主上下文也跟着瘦身？答案是：不行。

1.2 为什么想到复用：重复字段占到六成

我随机抓了20条线上协议消息做字段统计，发现一个特别扎眼的事实：有六成左右的字节是重复的。具体来说：

• 每个消息都会携带Agent的身份标识、角色描述、系统版本号，这些在整个会话生命周期内完全不变。
• 工具定义几乎是全量照搬，一个工具的描述可能有几百上千个字符，每条消息都传一份。
• 状态标记、时间戳格式、错误码映射表，明明系统里已经有统一维护，但消息里仍然重复写入。

你可能会问，为什么不直接让通信双方内部共享这些信息？对，这就是复用的思路。协议层不需要去解析每个字段的含义，只需要在第一次传输时把这些“慢变化”的数据登记到一个共享存储里，后续消息里用一个很短的应用层引用ID去指代它们。这样每条消息的载荷大幅缩水，尤其是那些承载全量工具定义和历史状态的消息，效果立竿见影。

但这里有个关键点：复用的是协议传输中的重复数据，而不是模型输入。这也为后面的结果埋下了伏笔——主上下文一字节没省。

2. 复用方案的设计：不是压缩，而是“会话级去重”

2.1 三类复用策略：字段级复用、消息模板复用、缓存复用

我给这套方案起了个土名字叫“会话级去重”。因为所有复用的对象都绑定在一个会话ID内部，跨会话不共享，这样避免不同任务之间的数据串扰。实际落地时用了三种策略，互相配合。

第一种是字段级复用。针对那些取值在会话内固定的字段，比如Agent标识、模型名、角色描述、系统时区、功能开关列表。通信双方在会话建立时先通过一次握手消息交换这些字段，并生成一张字段映射表。后续消息里，如果某个字段的值和映射表里的某个条目完全一致，就直接写字段编号，不再写完整值。这个策略类似HTTP里的头部压缩，但更激进，因为我们把字段语义也一起复用了。

第二种是消息模板复用。业务上存在大量结构完全相同的消息，只是局部参数不同。比如“工具调用结果上报”这个消息，结构永远是【任务ID、工具ID、参数哈希、返回状态、耗时】这几个字段。之前每条消息都把结构名和字段名完整写一遍，现在只需要在会话层面注册一次模板，后续消息只填模板ID和数据区。这一招对内部通信占比高的Agent系统特别有效，因为Agent之间本来就是一堆固定的动作模式。

第三种是缓存复用。针对的是那些经常被重复引用的“大数据块”，比如某个工具的长描述、一份固定的执行策略、一段很少变更的历史摘要。第一次传输时把数据块存入缓存并计算哈希，之后消息里如果携带了相同的哈希值，接收方就直接从缓存读，不再接收实际内容。等于把“传数据”变成了“传指纹”。

这三类复用叠加之后，协议消息里剩下的基本只有变化的部分：时间戳、请求ID、业务参数、结果数据。理论上重复越多，收益越大。

2.2 为什么选择传输层复用而不是主上下文压缩

这是我决策过程中最纠结的一点。既然要优化，为什么不直接去压缩主上下文？那样不是省得更彻底吗？

问题在于，主上下文压缩和协议层复用的目标和约束完全不同。主上下文是模型推理的输入，每一段文字都会影响模型的语义理解。如果你把工具描述压缩成一句话，或者把历史对话粗暴截断，模型的执行效果会立刻下降，轻则工具参数填错，重则整个任务逻辑紊乱。而且主上下文压缩通常意味着要引入额外的摘要模型、检索逻辑、动态裁剪策略，这是一整套复杂工程，不是简单去掉几个字节的事。

协议层复用的目标是减少节点间的网络传输和解析开销。这个层面的数据是结构化的、可精确定义的，重复就是重复，去重不影响任何业务语义。接收方在本地用映射表或缓存把消息还原成原始结构，模型看到的输入和之前完全一样，执行效果不受影响。换句话说，协议层优化像优化快递包裹的包装，里面的货物原封不动；主上下文优化则是动货物本身，做的是减法或重构。

我当时的判断是：先把能无损拿到的收益全部拿掉。复用方案不改变任何模型行为，不需要重新跑效果评测，风险最小，收益直接体现在网络和延迟指标上。至于主上下文优化，那是另一个战场，需要更多实验去衡量质量损失。所以，我决定先做协议层复用。

这一步决策也决定了后来的实测结果必然有一个尴尬的“省一半”与“一点没省”的对比。

3. 54次实测的完整过程与结果

3.1 实验设计：变量、场景、指标

为了验证复用方案的真实效果，我没有只测一两个用例就下结论，而是设计了一组相对严谨的对比实验。基本原则是：同一批请求，同样的大模型参数，同样的任务逻辑，唯一的变量是协议层复用开关的开启与关闭。

54次这个数字不是拍脑袋出来的，而是来自这样的组合：3个典型业务场景 × 3个会话深度档位 × 3轮重复执行 × 2种复用状态。每个场景每档跑3轮取中间值，最后汇总得到54次有效数据。

三个业务场景分别是：

• 工具调用密集型场景：子Agent频繁调用外部工具，消息量大，主要是结构化状态上报。
• 多轮对话协作场景：用户与主控连续对话，主控反复下发任务调整指令，上下文重叠度高。
• 长任务分片处理场景：一个大任务被拆成多个子任务，由多个Agent接力完成，期间需要传递大量中间结果。

会话深度分三档：5轮、15轮、30轮。主要考察会话拉长后复用效果是增加还是衰减。指标方面，我关注四个：单次请求平均协议字节数、端到端平均延迟、主上下文token数、成功率。前两个是主要优化目标，第三个是用来验证“主上下文没省”的关键证据，第四个保证优化没有副作用。

实验跑在一套我自己搭的仿真环境里，网络层模拟了真实的请求超时和重传，避免实验室环境太干净导致数据失真。

3.2 结果对照：协议字节降低53.8%，延迟降到1/7

先看最核心的协议字节数。关闭复用时，所有场景平均下来，单次请求的协议载荷大约是11.3KB；开启复用时，这个数字变成了5.2KB左右。算下来降低幅度是53.8%，接近标题里说的“砍半”。这个结果符合预期，因为前面统计过重复字段占六成，去重之后剩下的都是真正变化的数据。

然后看端到端延迟。这里出现了让我最初有点意外、但分析后又觉得合理的现象。关闭复用时平均延迟是约2.8秒，开启复用后平均延迟只有约0.4秒，降幅大约是86%，也就是接近七分之一。你可能会觉得，字节只减少一半，延迟怎么降到七分之一？

延迟的收益不仅仅是字节数减少带来的网络传输时间降低，更关键的是：

• 消息体变小之后，序列化和反序列化开销显著下降，尤其是JSON解析，大数据块的反序列化是很费CPU的。
• 部分消息因为缓存命中，干脆不需要等待接收节点返回确认，可以直接跳过一轮内部请求。
• 网络传输时间在总延迟中的占比下降了，复用在长链路场景中减少了一次额外的状态同步。

为了确认不是实验误差，我特意把54次数据按场景拆分。工具调用密集型场景延迟降幅最大，达到了约九成；多轮对话协作场景降幅稍小，约八成；长任务分片场景降幅也稳定在七成以上。这说明复用方案不是只在某个特定场景下灵，而是在整个系统层面均匀生效。

3.3 主上下文为什么一字节没省：必须正视的边界

最具教育意义的是第三个指标：主上下文token数。关闭复用和开启复用两种情况下，我把每次请求发给大模型的输入token数都做了统计。结果完全一致，比如5轮会话场景都是4031个token，30轮会话场景都是11024个token。一个字节都没有差。

原因前面已经讲透：协议层复用只改变了消息的传输形态，接收方在把消息还原后，业务逻辑仍然用完整的、未被压缩的数据去构造大模型输入。所以主上下文必然一字节不省，这是方案设计的边界，不是bug。

这个结果给我最大的启发是，优化Agent系统，必须先明确你要优化哪个“字节”。如果你关心的是模型成本，那协议层优化帮不了你；如果你关心的是系统吞吐和交互延迟，协议层优化是真正的富矿。很多团队花了大力气去压缩模型输入，结果模型执行质量下降，延迟却因为推理处理变快没降多少，完全得不偿失。而我这个方案，模型输入完全不动，效果和原来完全一样，但网络开销和延迟显著改善，适合那些Agent节点多、通信频繁、协议载荷大的系统。

话说回来，主上下文完全不省，也意味着我的项目还有很明显的后续优化空间：如果能把主上下文里的历史摘要、工具描述、重复字段也做类似“去重”的操作，那就是把模型成本也降下来了。那是下一步计划，等做完再单独写一篇。

4. 复用落地的实操要点与避坑指南

4.1 怎么实现复用：核心协议设计与实现思路

光说概念没用，这里分享一套我实际使用的协议实现思路。不写成具体代码，因为语言和框架不同，但核心逻辑是通用的。

首先是字段级映射表的建立。会话建立后，主控节点发送一个会话初始化帧，里面包含当前会话的Agent标识、模型配置、系统固定参数。接收方解析后，把这些字段按约定的顺序编号，生成一张映射表。以后每条消息里，如果某个字段的取值和映射表对应位置的默认值一致，就用一个短整型字段ID加一个标志位表示，不再传完整字符串。

我在实现时用的是位图加可选字段的方式：

消息格式： [会话ID(4字节)][模板ID(2字节)][字段位图(N字节)][字段数据区(变长)]

字段位图里每一位代表“该字段是否在本次消息中显式出现”。如果位图里某一位是0，接收方就自动从映射表或模板里取默认值。这样设计的好处是，大多数字段都不需要重复传输，实际数据区变得非常紧凑。

其次是模板注册机制。可以理解成在会话内提前定义好一批“函数签名”。比如：

• 模板01：工具调用请求，字段为工具ID、入参JSON。
• 模板02：工具调用结果，字段为工具ID、状态码、返回值摘要。
• 模板03：状态心跳，字段为当前子任务ID、进度百分比、耗时。

每条消息只要携带模板ID和按顺序排列的数据，接收方就能完整还原。模板的定义在会话握手时一次性下发，之后不再重复传输。这个思路和很多RPC框架类似，本质上是把“接口定义”从每次调用里抽了出来。

最后是缓存复用的实现。我在双方各维护一个对象缓存，当一方要发送一个可能重复的大数据块时，先计算这个数据块的哈希，然后查一下自己的缓存。如果缓存里有相同的哈希，就直接发哈希引用；如果没有，就把数据发过去，并且让接收方也缓存下来。为了控制内存，我设置了每个会话最多缓存64个数据块，每个块不超过512KB，超过上限的按LRU策略淘汰。哈希用SHA-256，冲突率可以接受。

4.2 踩过的坑：缓存失效、状态不一致、调试困难

这个方案看起来不复杂，但实际落地时踩了好几个坑。第一个坑是缓存不一致。有一版实现里，发送方根据自己缓存的哈希发了一个引用，但接收方的缓存因为淘汰策略或者启动时序问题没有对应数据，导致消息还原失败。后来我把缓存的有效期绑定到会话生命周期，并且在每次发送引用前，发送方都会检查接收方是否确认过这个引用编号。确认过的才用引用，否则直接传数据并补充登记。

第二个坑是序列化顺序不稳定。第一次实现时，消息数据区的字段顺序是动态拼接的，结果导致相同内容在不同消息里生成不同的字节流，模板复用完全失效。后来我强制所有消息在构造前先按照字段编号升序排列，保证同样的数据永远生成同样的结构。

第三个坑是调试困难。协议字节被“优化”掉之后，我们之前常用的抓包工具看消息全是短ID和位图，根本没法快速看出业务语义。后来我加了一个调试开关，开启后所有消息都使用慢速但可读的完整JSON格式，并且日志里打印还原后的消息而非原始报文。只有出问题的时候才临时开启调试模式。这个开关本身也让我意识到，复用方案在可观测性上一定要提前设计好。

除了这三个坑，还有一个特别容易忽略的地方：时间戳和请求ID这些看似唯一的数据，如果不小心把它们当成可复用字段，就会导致响应错乱。所以我明确列出了在复用时必须排除的字段——凡是每次调用都不同的数据，绝对不允许进入映射表或模板默认值。

4.3 何时不要用复用：小请求、动态数据、跨节点安全

复用不是银弹，有几种场景我明确不建议再用。第一个是请求体极小的场景。如果一条消息只有几十个字节，注册模板、维护缓存带来的额外开销可能比省下的字节还要多。我曾经试过为一条只有32字节的心跳消息做模板复用，结果加上模板ID和位图后变成了38字节，反而更大了。所以我在实现里加了一个判断：只有当消息载荷超过256字节时才进入复用流程，低于这个阈值的直接走原始格式。

第二个是动态性太强的场景。如果消息里的字段几乎每次都在变，复用映射表命中率极低，模板也需要频繁更新，效果基本可以忽略。比如一个高频随机事件上报消息，字段值全是随机的，那去重策略就没有意义。

第三个与安全性相关。如果Agent系统跨了多个信任域，或者消息内容不能缓存在本地共享存储中（比如含有临时密钥或敏感权限信息），复用可能会导致数据被其他会话意外访问。我的处理方式是：对于包含敏感数据的消息，强制走完整传输，并在缓存中禁止写入敏感字段。安全底线不能被字节数突破。

5. 常见问题与排查技巧实录

5.1 典型问题速查表

我把实验中遇到的高频问题和对应解法整理成了一个速查表，方便以后直接对照。

5.2 排查经验：为什么延迟没有明显下降？怎么验证复用是否生效？

如果你按照同样的思路做了优化，跑完测试发现延迟几乎没有下降，我建议先排查这几件事。

第一，确认是否真的命中了复用。在日志里看消息的原始载荷和还原后的载荷比例。如果开启复用后，传输字节数几乎没有变化，那说明消息里大部分字段根本没被复用。最可能在字段分类时，把所有字段都标记为“动态字段”，导致映射表完全没发挥作用。你需要重新评估哪些字段在会话内确实是稳定不变的，比如Agent的元信息。

第二，确认延迟瓶颈不在协议层。如果你的Agent系统里，延迟主要消耗在大模型推理或者外部工具调用本身，那么协议优化就算做到极致，端到端延迟也不会有什么变化。我这次之所以延迟降幅巨大，是因为系统本身的通信次数非常多，协议开销在总延迟中占比高。如果你的系统单次通信次数很少，协议优化带来的收益自然不会明显。所以判断收益前，先做延迟分解，看哪些部分占比高。

第三，验证“主上下文没省”是否被误读。我看到很多朋友会拿“token没降”来否定协议层优化的价值，这是不对的。两个指标服务于不同目标。我自己的态度是：只要协议字节下降，同时模型输出质量不变，这个优化就有价值。如果你优化的是成本，那确实需要另外一个方案。

5.3 关于测试方法的建议：54次这个数字背后

顺便分享一下做这类对比测试的经验。54次听起来多，但其实并不复杂。重点是控制变量和取合理统计值。我在每个场景下会先跑一轮预热，等缓存和映射表稳定后再记录数据。正式测试时每个组合跑3轮，去掉最高和最低值，取中间的那条记录作为样本。3轮虽然不多，但考虑到每个组合的稳定性都很高，这个样本量在工程验证上是够用的。

另外，要确保对比时网络环境和负载一致。我特意在相同时间段、相同机器负载下交替跑关闭和开启两种状态，避免因为机器跑得多导致结果偏差。记录结果时同时记录时间戳和负载信息，方便事后复查。

有一个小技巧：在协议消息里加一个复用统计字段，每次回复都带上“本次消息原始字节数”和“复用后字节数”，这样就不需要额外抓包去统计了。系统运行一段时间后，直接汇总这个字段，就能准确看到复用的长期收益。这个技巧特别适合在生产环境中持续观察效果。

最后再说一点

这次优化做完之后，我的体会其实有点复杂。一方面，“复用让协议字节砍半、延迟降到1/7”确实是实打实的结果，整个系统的响应轻快了很多，内部通信不再是卡顿的来源。另一方面，主上下文一字节没省这件事又时刻提醒我，这套方案解决的只是“管道”问题，不是“大脑”问题。

如果你也在做类似的自养Agent系统，我建议你先想清楚：你的系统瓶颈到底在哪？如果你发现内部消息传递频繁、协议载荷大、交互延迟明显，那复用这套思路可以直接参考。如果你的主要成本在于模型输入token太多，那就需要去研究主上下文压缩、语义摘要、工具裁剪这类方案，而不是指望在协议层做文章。

从实践者的角度说，优化Agent从来不是一次性的工作。我现在已经把主上下文压缩列到了下一个迭代里，准备先分出一个专门的“记忆摘要”Agent，把重复的上下文做语义级别的去重。到那时候，希望不仅能继续压低协议字节，还能真正把主上下文的token数打下来。这条路还挺长的，慢慢走吧。