企业官网建设流程全解析

AI Agent这个名词现在不缺热度，缺的是有人把账算明白。我接手一个客服Agent项目的时候，第一次开资源账单，财务直接把表甩过来：单月推理成本12万，环比翻了一倍。当时团队第一反应是"模型不是降价了吗，怎么花费反而涨了"，拆完数据才发现，问题根本不在模型单价，而在技术栈设计和推理服务选型——平均每个任务要调7次模型接口，其中3次是无谓重试；每轮对话都背着几千Token的历史上下文；所有问题无论难易都丢给同一个顶级模型。这些都是钱悄悄流掉的地方。这篇文章不聊通用架构趋势，只把五层技术栈每一层的成本逻辑拆开，再把三种推理服务形态摆在一起算账，最后用一次真实复盘收尾。

1. 五层技术栈的账本：先把成本分布看清

1.1 我习惯的分层方式与每层成本构成

讲技术栈之前，必须把"分层的目的是什么"说清楚。很多介绍AI Agent的文章会把架构画得很复杂，但对做落地项目的人来说，分层的唯一价值是让每一层都有明确的成本负责人，出账单一查就知道该找谁。

我习惯按成本归属，把Agent系统拆成五层：

很多成本分析把账全部记在模型层，这是不够准确的。L3编排层的循环次数会成倍放大L2模型的Token消耗；L4工具层的失败又会让L3的循环雪上加霜；L5层的日志如果全量上报，同样是一笔不小的隐性支出。所以真正的降本，看得是跨层影响，而不是单点抠门。

1.2 真正的成本大头是"无效推理"，不是GPU

我见过不少团队，一谈降本就盯着GPU类型和模型单价，结果把钱省在了最不起眼的地方。举个形象的类比：你公司雇了一位顶级专家顾问，按小时计费，结果你天天让他帮你整理会议室、查字典、核对格式。Agent系统里也一样，LLM每输出一个Token都是要付钱的，如果大量Token被耗在无意义的步骤上，再便宜的模型也救不了账单。

无效推理最常见的几个场景：

1. 规划器太啰嗦。某些Agent框架里，模型在真正动手前会先给自己写一整页行动计划，一些简单任务也被迫进入"规划—调用—验证"的完整链路。
2. 工具调用失败后无脑重试。工具返回的格式不符合预期，模型修一次不对、两次还不对，来回三四轮。
3. 多Agent互相传话时携带完整上下文。A Agent把结果传给B Agent时，把整个历史消息也带上了，消息越传越大，Token消耗呈指数上升。
4. 缺少缓存导致的重复请求。同一个业务知识被反复检索、反复回答，但系统完全不记得。

一个Agent任务的完整Token消耗可以写成：任务过程中的模型调用次数 × 单次调用的输入长度。很多团队只盯着后面的"输入长度优化"，却忘了前面的"调用次数"是一个倍数。把这个倍数压下来，效果立竿见影——我后面复盘部分会用真实数据说明。

2. 模型层省成本三板斧：选型、压缩、缓存

2.1 模型选型：按任务难度分档，别让大模型干杂活

模型层降本，第一个原则是"够用就好"，而不是"越强越好"。道理和团队配置类似：你不能让CTO去回复客服邮件，也不能让实习生去写核心架构代码。

我曾经把某个客服Agent的全部流量打到一个旗舰大模型上，后来分档统计发现，60%的请求只是查订单、改地址、问退款，这些任务用中小模型加规则就能做得很好，只有20%到30%的复杂问题才真正需要旗舰模型的能力。也就是说，超过一半的钱都花在了简单问题上。

实操中可以把任务按难度分档匹配模型：

还要注意一个成本放大器：思维链。让模型"先思考再回答"能提升效果，但代价是输出Token量可能膨胀好几倍。一个本来只需要输出50个Token的简单问题，如果默认开启深度推理，可能输出几千Token。所以分档不只是换模型，还要对简单任务关闭长思维链模式，用受控结构化输出来约束格式。

2.2 上下文压缩：把每轮对话的"历史包袱"减掉

多轮对话场景下，最大浪费不是模型输出，而是每次调用都要把完整历史重新发送一遍。我按一个典型场景算过账：假设历史对话固定在2000Token，系统提示300Token，用户当前问题50Token，模型回答200Token。单次调用的实际消耗是2550Token，其中历史占2000Token，接近80%。

如果一次任务需要来回5轮，总消耗就是12750Token，而真正有效的信息可能只有不到3000Token。更糟的是，一些Agent框架会对历史做逐字保留，甚至把工具返回的原始日志也塞进上下文，几轮下来上下文膨胀到几万Token也不稀奇。

压缩手段按性价比排序：

1. 滑动窗口：只保留最近2到3轮对话，更早的内容不再进入上下文。
2. 定期摘要：用便宜的小模型把旧会话压缩成300Token的摘要，要点不丢，细节丢弃。
3. 关键状态外置：把订单号、用户ID、上下文中的结构化工单数据存到数据库，只在需要时按需查询，而不是全部堆在对话历史里。
4. 按需带历史：当前问题不依赖上文时，直接不带历史。这个判断本身可以做成规则，不需要模型决定。

我们给客服Agent做完上下文清理后，单任务Token量降了接近一半。效果能这么明显，是因为几乎所有Agent框架默认的"记忆"策略都是全量保留，默认配置本身就是成本陷阱。

2.3 缓存命中：语义缓存与KV Cache的实际效果

模型层省钱的第三板斧是缓存，但很多人对缓存的理解只停留在"同样的Prompt复用同一个答案"这个层面。

第一种是语义缓存。在FAQ和内部知识库场景里，用户问"退款多久到账"和"退款什么时候能到"，描述不同但意图相同，可以用Embedding计算相似度，命中阈值内直接复用之前的答案。这个方案对静态知识类问题非常有效，我们曾把重复问题命中率做到30%到40%，整体Token消耗下降约两成。

第二种是Prompt缓存。系统提示词和少样本示例通常是每次请求都携带的固定部分，不少模型服务商对新版本API提供自动前缀缓存，重复的前缀不再重复计费。这要求你在工程上保持系统提示词稳定，别动不动把整段Prompt重新生成一遍。

第三种是KV Cache复用，主要针对自部署场景。用vLLM或SGLang这类推理引擎部署开源模型时，相同前缀的请求可以复用计算图，配合前缀树调度，单卡吞吐量能提升不少。这部分优化不会直接改API账单，但会把GPU利用率拉高，单位Token成本自然会降下来。

缓存有个调优细节容易被忽略——语义相似度阈值。阈值设得太严，命中率极低，缓存形同虚设；设得太松，经常把语义不同的问题强行复用同一个答案，用户会觉得答非所问。我的经验是先跑一段真实日志离线试阈值，一般从0.85往上调，观察误召回率再定。

3. 编排层容易被忽略的浪费：循环、重试和"空转"

3.1 无限重试循环是怎么把Token耗光的

模型层的账算清楚之后，下一个要动刀的是编排层。这个层级的浪费不是单个Token贵，而是把Token消耗总量成倍放大。

我遇到过最典型的"Token黑洞"，是一个比重试逻辑造成的：工具调用返回的数据格式与预期不一致，Agent修了一次仍然不对，又重试第二次，第三次才成功。每次重试都会把完整历史重新发送一遍，单次任务成本直接翻了四倍。事后排查才发现，工具返回的CSV里多了一个汇总行，代码解析失败，Agent并不知道该怎么处理这种"脏数据"，只好不断尝试。

这类问题根源在于：LLM本身有不确定性，工具也不是每次都稳定，如果编排层不设置约束，两者叠加就会形成"规划—调用—失败—再规划"的死循环。很多Agent框架把最大迭代次数默认设在8到10次，这对大多数业务场景来说太高了。我最开始接手项目时，线上配置就是10次，很多任务根本不需要10次，但模型总会把预算用尽才结束。

给Agent设置合理的迭代上限，通常3到5次就够。但需要配合一个好的终止判断，否则在迭代上限内依然会空转。

3.2 把确定性逻辑从模型手里拿回来

一个核心原则：能用正则、循环、映射解决的问题，绝不交给模型。模型是概率系统，用概率系统去处理确定性逻辑，既慢又贵还不可靠。

举个例子，用户说"明天下午3点"这类时间表达，正确的做法是用规则解析或调用时间解析库，而不是让模型去理解并生成一个时间戳。再比如字段校验，在调用工具之前先对模型生成的参数做JSON Schema校验，如果不合法，直接返回错误信息让模型修正一次，而不是让它重新开始整轮规划。

工具层还应该做好幂等设计。当客户端调用工具超时，我们无法判断工具到底执行没有，如果不加TraceId去重就重试，可能造成重复扣款或重复发消息。这种问题一旦发生，会产生业务赔付，成本比Token高得多。所以工具调用前置校验、失败分类、幂等键，这三个工程细节一定要有。

另外，对工具返回的数据要做一层"协议适配"。模型调用工具时，期望拿到的是干净、标准化、可解析的结果；如果工具返回原始CSV、HTML或日志，解析失败几乎是必然的。在工具侧做一个统一的解析清洗层，把脏数据变成规范的JSON，这个工作省下来的重试钱，远高于开发成本。

3.3 提前终止机制：让Agent学会"不需要工具就停"

Agent空转的另一个常见原因是"停不下来"。很多框架用"是否调用了工具"来判断Agent是否完成，但只要模型觉得需要调用工具，循环就会继续，哪怕工具结果完全没有帮助。

解决办法是在编排层加一个明确的终止判断。第一，当模型输出FINAL_ANSWER标记时，立即停止；第二，当工具调用返回空结果或明确表示"无法解决"时，停止推进并转入兜底流程；第三，在Prompt里直接写清楚："如果你已经能够回答用户问题，不得再调用任何工具，直接输出最终答案。"这句话看似简单，但对减少无效调用作用极大。

实测数据：我们给客服Agent加上"提前终止"逻辑并设置合理迭代上限后，平均每个任务的模型调用次数从7次降到了3.5次。代码改动量不到100行，成本却降了40%左右。这就是编排层杠杆的威力。

这里要提醒的是，提前终止不能只靠Prompt。Prompt可能被模型忽略，必须配合结构化输出和代码层面的控制条件。模型输出JSON时，可以要求它显式给出"need_more_tools"布尔字段，代码根据这个字段决定是否继续循环，这才是可落地的做法。

4. 三种推理服务怎么选：按日调用量算一笔硬账

4.1 托管API：起步快，但单价随量上涨

托管的模型API按Token计费，是很多AI Agent项目起步时的默认选择。它的优势非常明显：不用管GPU、不用管运维、能力和生态都是现成的，对原型验证和低频复杂任务来说，性价比是最高的。

但它的成本特征是线性增长：每百万Token单价固定，调用量越大，总账单越高，而且没有任何规模折扣。我用一个虚拟但贴近实际的例子来算：假设一个Agent任务平均消耗2万Token，输入占1.5万、输出0.5万，用中高端模型API，输入价格按30元/百万Token、输出价格按90元/百万Token计算，单次任务成本大约0.9元。日调用1万次，单日就是9000元，一个月27万。

再强调一次：这里数字只是一个估算，实际价格随时在变，但你看到趋势了吗？当业务量上来之后，价格再低也经不起规模放大。所以托管API适合项目早期和长尾复杂任务，但不能作为高频业务的唯一选择。

4.2 自部署开源模型：临界点在哪里

自部署开源模型是另一种典型形态，常见组合是Qwen、DeepSeek等开源权重模型加vLLM或Ollama推理引擎。它的成本结构从"按Token计费"变成了"固定资源投入"：GPU租金或折旧、电费、带宽、运维人力，外加模型效果不如旗舰闭源API的风险。

什么情况下自部署更划算？我按临界点算一笔账。

以7B模型为例，FP16权重约14GB显存，量化后能压到7到9GB，一张24GB显存的RTX 4090或A10即可部署。用vLLM部署后，单卡吞吐大约1500到3000Token/s。假设业务每天要处理5000万Token，毛估需要好几个小时的计算时间，但通常业务有峰谷，我们按一天中大部分时间有负载来算。如果一张GPU月租金在2000到4000元区间，日成本约70到130元。同样的5000万Token如果全走托管API，按输入输出混合价约42元/百万Token算，日成本约2100元。两者差了十倍以上。

但这么算太理想了。实际自部署要扣掉运维成本、GPU闲置率和模型效果损耗。如果业务流量不稳定，GPU大部分时间空转，自部署的"单位固定成本"就会很高。以我的经验，在每天Token消耗稳定超过几千万的场景，自部署才有明显优势；如果每天只有几十万Token，自部署纯属给自己找麻烦。

4.3 混合路由：用便宜模型扛住80%的流量

讲完两种极端形态，第三种是混合路由。这也是我在生产环境中用得最多、赚钱感最强的一种方案。

混合路由的核心思路，是让请求按难度走不同的推理路径。具体有三种实现层次：

1. 规则优先：关键词、正则、FAQ匹配能解决，直接返回，不进入任何模型。
2. 语义路由：用Embedding把用户问题向量化，和已有问题簇做相似度匹配。命中高频场景时，路由到小模型或专用模型。
3. 级联升级：先让便宜模型尝试回答，模型同时输出一个置信度分数，置信度低于阈值再升级到强模型。

混合路由的关键在于路由器本身。你可以用一个轻量模型来做难度分类，也可以纯靠规则加语义匹配。不要一上来就搞太复杂的路由器，先用一段时间的日志分析出高频问题类型，手工写好路由映射表，再慢慢迭代。

实际效果方面，客服场景中我们的流量有50%到60%被路由到了小模型或专用模型，整体Token费用下降四成左右。但要注意，路由错误会造成用户体验回退，所以必须留一条兜底路径：当便宜模型输出质量存疑，立刻升级。没有兜底的路由，省下来的钱会变成流失的口碑。

4.4 选型清单：不同业务阶段对应的方案

我把三种推理服务形态的适用场景整理成一张表，方便你对照定位：

这里也要泼一盆冷水：自部署不是万能解药，开源模型的72B以上规格对GPU资源要求极高，单机不够还要插多卡组分布式推理，运维复杂度直线上升。只有当业务高频且流量稳定，自部署的优势才压得过它的成本。

5. 一次实际项目复盘：月成本从12万压到4.8万

5.1 原始账单拆解

前面说了这么多方法，最后用一个真实复盘把它们串起来。这个项目同时跑两个Agent，一个是客服问答Agent，一个是数据分析Agent。优化之前的主要指标如下：

这里有一个点值得注意：单次模型调用的单价看起来不贵，可是一旦乘以"调用次数"和"上下文膨胀"，金额就完全失控了。如果只看模型单价，会觉得每百万Token几十块钱不算什么；但20亿Token的盘子，随便浪费几个百分点就是好几万块。

当时的情况是，所有流量不管难易都打到同一款旗舰大模型API，Agent默认最大迭代次数是10，历史上下文全量保留，工具解析失败后重试三次才放弃，整个系统没有任何语义缓存和路由。每一项单独看都不致命，叠加起来账单就爆炸了。

5.2 四步调整的过程与结果

我们花了三周时间做了四步调整。

第一步是砍无效推理。把Agent的最大迭代次数从10调到4，增加提前终止和"不需要工具就停"的判断，再给工具调用加了JSON Schema前置校验和幂等去重。这一步落地后，平均每任务模型调用次数从7次降到3.5次，模型成本直接降了约40%。

第二步是模型分档。把意图分类、FAQ检索等高频简单任务切到小模型API，只在复杂推理和多步任务时使用旗舰模型。同时关闭了简单任务的长思维链模式，改用结构化输出。这一步让约60%的任务成本降为原来的五分之一到十分之一，整体账单再降约20%。

第三步是自部署一个7B开源模型，专门承接某块高频的RAG问答。这块流量非常稳定，每天固定量级，非常适合自部署。我们当时用一张24GB的GPU跑vLLM，把这块业务的模型成本压到了一个很低的水平。加上上游的流水线批处理，GPU利用率基本跑到了70%以上。

第四步是语义缓存加上下文清理。语义缓存命中了约三成重复问题，上下文清理则把单任务的"历史包袱"减掉了一半，Token总消耗再降约15%。

四步做完，月度成本从12万降到4.8万，降幅约60%。同时我们用了一套线上评估集去盯回复质量和任务成功率，确保省钱没有以牺牲效果为代价。

5.3 降本之后的几个容易翻车的点

降本动作完成不代表结束，后续踩过的坑同样值得记录。

第一个坑是模型分档后，多轮对话里的某些意图被小模型误判。用户说一句"那退了吧"，小模型可能不知道"那"指代什么，直接走了错误流程。后面我们加了一条规则：只要小模型输出置信度低于0.7，就自动升级到旗舰模型重跑一次。升级比例大约占10%，这块额外成本远低于全部流量都用大模型的开销。

第二个坑是自部署GPU利用率波动剧烈。白天在线请求多，GPU跑得满满当当；凌晨低峰期，卡在那儿空转。后来我们给离线批处理任务设计了一个低峰调度，才把闲置时间填上。如果你准备自部署，一定要先想清楚低峰期怎么打发，否则月租照付、利用率极低，账面上反而难看。

第三个坑是语义缓存的阈值调优。最初阈值设得偏低，经常出现"答非所问"的缓存复用，客服那边客诉都起来了。后来干脆把缓存命中后的答案加了一个"关键词复核"步骤，先检查用户问题里的关键实体是否在历史答案里出现过，如果缺失就直接跳过缓存。这样虽然牺牲了一点命中率，但把误答率压了下去。

第四个坑是观测指标不够细。早期我们只监控Token总量和成本，没有给路由决策、缓存命中、升级率这些环节单独埋点。一旦账单异常，只能靠猜。后面在日志里把每次请求的"路由路径"和"决策原因"记录清楚，成本一涨，立刻就能从日志里定位到是哪类流量、哪个环节出了问题。

降本真正教会我的，不是砍价能力，而是把Agent系统当成一套预算系统来设计。模型选型、上下文策略、编排约束、推理服务形态，每一个决定都同时在影响效果和成本。而且无论怎么省，先保住最关键任务的效果底线，否则省下来的钱会以另一种方式变成用户流失的成本。如果你也在做AI Agent落地，建议先从这篇文章里的"无效推理"查起，那可能是你账单里最肥的一块肉。