企业官网建设流程全解析

这一周，我几乎所有精力都耗在了三件看起来毫不相关、实际上咬得很紧的事情上：token 用量、模型能力升级、还有 agent 的失控问题。先说结论：模型确实更强了，prompt 也真的能写得更短了，但 agent 并没有因为模型变强而变得更省心，反而更难管了。

如果你正在做 LLM 应用，或者团队里有人负责 prompt 优化、模型选型、agent 开发，这篇文章应该能帮你节省不少试错时间。我会把这周实际踩过的坑、验证过的手法、以及最后沉淀下来的一套排查思路，全部摊开来讲。不保证每一条都适用于你的场景，但至少能让你少走几段弯路。

1. 三个关键词背后的工程信号

1.1 为什么偏偏是这三件事

这周我们内部正好进入了一个新阶段：之前跑通的原型要往生产环境搬。一旦涉及生产，考核的维度就从“能不能跑”变成了“贵不贵、稳不稳、乱不乱”。结果一盘点，问题刚好集中在这三个词上。

token 的问题最直白。账单上输入的 token 量比预期高了一大截，翻日志一看，很多成本花在了重复的系统提示词、冗长的 few-shot 示例，以及“为了保险而塞进去”的历史消息里。模型的问题也很现实——新出的模型能力确实强，特别是指令遵循和结构化输出，但其中一些并不对普通用户开放，于是团队里不少人开始研究本地部署和轻量化方案。至于 agent，则是从 demo 进入真实业务后暴露出来的：它会循环调用工具、会编造参数、会在第 7 步的时候忘记第 1 步的目标。

这三件事不是孤立的。模型变强了，大家都想用更少的 prompt 完成任务，所以 token 在降；但 agent 的能力边界也跟着变大，调用链拉长，出问题的概率反而上升。这就是我标题里写的“更少 token、更强模型、更难管的 agent”三个信号。

1.2 三件事如何互相传导

我这一周最大的感受是：问题在转移，而不是消失。

过去我们优化成本，盯着 prompt 长度、历史消息轮数、缓存命中率，这些属于输入侧优化。把输入做短、做精，token 自然降下来。模型变强以后，这套优化变得更顺手了，因为新模型对啰嗦指令的依赖度明显降低，你不需要再写“请你以一名资深专家的身份，用非常正式的语气……”这种话，直接说“转成 JSON”它就能听懂。

但与此同时，agent 消耗掉的 token 并没有减少，甚至更多了。原因在于 agent 每走一步都要把工具返回结果、中间思考、上一步动作重新拼进上下文，轮次一多，token 就像滚雪球一样涨。所以 Token 优化这件事，从“写好一段 prompt”变成了“管好一整条 agent 执行链”。输入侧的账越来越好算，输出侧的账却越来越难算。这就是这周让我最拧巴的地方。

2 更少 token：把账算到每一层

2.1 token 在请求里到底花在了哪

要省钱，先得知道钱花在哪。大模型推理大致分成两个阶段：prefill（预填充）和 decode（解码）。prefill 阶段把输入的所有 token 一次性并行计算，产出 KV Cache；decode 阶段根据缓存逐 token 生成输出。也就是说，输入 token 决定 KV Cache 能占多大显存，输出 token 决定你等多久。

这里给个粗略估算。假设你用的是 7B 模型，hidden size 是 4096，层数是 32，KV Cache 的占用大致是 2（K 和 V）乘层数乘 hidden size 乘序列长度乘每个参数字节数。序列从 1000 token 涨到 4000 token，缓存占用就翻了 4 倍。放到 API 计费上也是一样的逻辑：输入 token 通常比输出 token 便宜，但输入量往往是输出量的几倍甚至几十倍，所以账单的大头经常在输入侧。

举个例子，假设一天 5 万次请求，平均每次输入 3000 token、输出 500 token。按某些主流 API 的价格估算（只用于理解量级，具体以各家实时报价为准），一个月光输入成本就可能占到总成本 70% 以上。所以做 token 优化，核心是压缩输入，而不是跟输出那几个 token 较劲。

2.2 把 prompt 从 2800 token 压到 1100 token

这周我花了大半天做了一次 prompt 压缩实验，对象是一个信息抽取任务。原始 prompt 有 2800 token，包括一大段角色设定、五组 few-shot、格式说明、边界案例清单。压缩后只剩下 1100 token，效果还更稳定了。

压缩路径大致是四步。第一步，删掉所有重复强调。原来的系统提示词里说了三遍“请严格按照以下格式输出”，其实只需要在结构化输出约束里写一次。第二步，把 few-shot 从每组 5 条砍到 1 条。新模型的指令遵循能力比较强，对示例的依赖明显下降，保留最典型的那一条就够。第三步，格式说明尽量用 JSON Schema 来表达，而不是写一长段“字段 a 是字符串，字段 b 是数组”。第四步，历史消息按相关性截断，而不是按时间顺序向后丢——比如用户中途上传过一份文件，之后所有轮次都在讨论这份文件，那文件内容就应该一直保留，早期的寒暄反而可以先丢掉。

压缩完我跑了一遍回归集，准确率不降反升。原因也很容易理解：prompt 变短之后，关键指令在上下文里的“密度”变高了，模型更容易聚焦到真正重要的部分。但这里必须提醒一句：prompt 压缩不是单纯删文字，每一步改动都要在固定评测集上验证，否则你根本分不清效果变化到底是压缩导致的，还是模型随机性导致的。

2.3 滑动窗口、Longformer 与长上下文的取舍

这周还有同事问我：既然要省 token，能不能直接上 Longformer 这类长文档模型，或者把上下文切成滑动窗口？正好这两个词都在这周的热搜里出现过，我把自己的理解说清楚。

滑动窗口在多轮对话里很有用。它把注意力限制在最近的 N 个 token 上，KV Cache 不再随历史无限增长，工程上非常好控制。缺点是窗口之外的信息完全不可见，如果用户在第 1 轮提到一个要求、第 20 轮才让你执行，模型就已经忘干净了。所以滑动窗口适合实时性强的场景，比如客服机器人的最近几轮对话，但不适合“全程都要记着”的任务。

Longformer 的思路是用稀疏注意力把复杂度从 O(n²) 降到 O(n)，处理长文档时理论上有优势。但我在中文场景里实测过，效果不算稳定，有些任务上表现很好，有些任务上反而抓不住关键信息。再加上生态和部署复杂度，我的建议是：如果任务是分类、抽取这类结构化预测，可以先用 Longformer 或类似模型做一轮预处理，把文档压缩成摘要或关键片段，再交给大模型做最终判断。不要把长文本一股脑塞给大模型硬读——那对 token 的消耗非常可观，效果也不一定理想。

提示：热词里还有个“滑动窗口滤波模型”，那是信号处理里的方法，用于平滑噪声数据，跟大模型的滑动窗口注意力不是一回事。别被名字误导，选型之前先确认你要解决的是时序数据问题，还是文本上下文问题。

3. 更强模型：红利与适配成本

3.1 模型能力跃迁对工程的三点改变

这周我用新模型重跑了一批旧任务，感受最深的有三点变化。

第一是指令遵循。过去写 prompt 要“哄着”模型，现在可以直接下命令。同样是做实体抽取，以前要写两段“请从以下文本中抽取……并将结果输出为 JSON 格式”加上一堆注意事项，现在简单说“抽取其中的公司名、金额、日期，输出 JSON 数组”就能稳定执行。第二是代码和结构化文本的生成质量。原来生成一段 JSON 经常出现多余逗号或者末尾缺失括号，需要后端再做一层修复；新模型在这方面的错误率低了很多，很多修复逻辑可以直接删掉。第三是上下文利用能力。模型开始能利用中间位置的信息，而不是只记得开头和结尾，这对长文档问答是一个实质利好。

但能力变强也带来一个麻烦：回答变得过于流畅，幻觉更难辨别。以前模型不确定时会支支吾吾，现在它能给你编出一段结构完整但完全错误的内容。所以我把很多任务的输出校验从“格式校验”升级成了“逻辑校验”，比如对关键数据做二次交叉验证，而不是只看字段类型对不对。

3.2 本地部署的现实：从 API 到 GPUSTack

这周讨论度很高的一个背景是：新模型暂时不面向普通用户开放。于是不少团队转向本地部署，用各种工具在自有机器和云主机上跑开源模型。

以 Windows 环境为例，部署一个 7B 模型，我建议按这个顺序检查：先确认 GPU 驱动和 CUDA 版本是否匹配，再看显存够不够，最后看模型格式支不支持。GPUSTack 这类工具做的事其实是把这些步骤封装成相对统一的管理界面，但底层依然要靠驱动和显存撑住。如果显存不够，常见做法有两种：一是用 INT8/INT4 量化把模型压小，二是用多卡并行。量化要特别注意精度损失——有人把模型从 FP16 量化到 INT4 后，推理速度上去了，但某些输出开始偶尔跑偏。对于要交付给用户的关键内容，我个人不敢直接上 INT4，至少会保留 FP16，或者用 GPTQ/AWQ 这类质量更好的量化方式。

轻量化不止限于大模型。这周有人提到 yolov5s 的轻量化和 LightGBM 回归模型。放在同一个语境里理解很简单：不是所有任务都需要大模型出场。视觉任务里，yolov5s 本身就是为了实时性设计的，再做蒸馏、剪枝、量化是为了跑在边缘设备上；表格类预测任务里，LightGBM 这类传统模型速度飞快、可解释性也好，完全没必要套一个 LLM。把它们和 LLM 组合在一起，反而能形成更省钱的架构。

3.3 模型路由：把更强的模型用在刀刃上

既然本地小模型、场景模型、最强 API 模型各有各的适用面，那团队里就一定会出现“模型路由”的需求。

思路很简单：请求进来，先判断任务类型和难度，然后路由到不同档位的模型。简单的事实问答、分类、抽取，走本地小模型或传统模型；复杂的推理、代码生成、长文档综合，才动用最强模型。路由本身不一定非得用大模型——用 embedding 特征加一个 LightGBM 分类器，或者用一套关键词规则，都完全可行。

路由层最关键的是兜底逻辑。判断错了怎么办？比如把小模型处理不了的长文档总结误判成简单抽取，小模型输出质量会很差。我的做法是给路由层设置置信度阈值，低于阈值时自动升级到更高档位的模型，同时在响应里打一个模型标识，方便事后分析路由准确率。引入路由之后，整体成本大概能降 30% 到 50%，但这需要建立一套评估集来验证路由判断的准确性，不然省了钱、丢了效果，得不偿失。

4. 更难管的 agent：失控是常态，围栏是必须

4.1 难管在哪：四个典型失控场景

这一周里，我至少四次被 agent 的意外行为打断。第一次是 agent 反复调用同一个搜索工具，拿到一样的失败结果，还是不死心，连续重试了十多次。第二次是调用外部 API 时，它把参数里的日期字段从“2024-11-25”改成了“2025-11-25”，理由居然是“觉得用户应该指的是明年”——这是典型的工具参数幻觉。

第三次是上下文污染。工具返回了一大段原始 HTML，agent 既没有清洗也没有提取，直接把整段塞回上下文，模型被大量无关信息干扰，后续决策质量急剧下降。第四次是目标漂移：一个多步骤任务，前两步还正常，到第 5 步时 agent 开始处理别的事情，经过提醒才发现已经偏离原始需求很远了。

这四个场景的共同点是：agent 的每一步都有不确定性，且错误会沿着调用链叠加放大。模型越强，单步执行得越流畅，反而越容易让人放松对“整条链路可控性”的警惕。

4.2 给 agent 装围栏：五个必设边界

这一周的教训让我把 agent 的安全配置当成第一优先级。现在每个 agent 上线前，至少要确认五件事。

• 步骤上限：max steps 硬性设死，一般任务 5 步起步，少数复杂任务放宽到 10 步，超过立即中止。绝不允许无限循环。
• 工具白名单：只暴露当前任务必需的工具，跟任务无关的删除、写入、发送类接口一律不挂。宁可临时加权限，也不要默认给全量。
• 人工确认点：对外发消息、创建订单、删除数据这类敏感动作，必须设人工确认卡点。agent 只能生成“待确认请求”，不能直接执行。
• Token 预算：为单次任务设定 token 上限。这个上限覆盖所有轮次的总和，达到上限就强制结束并生成总结。
• 失败熔断：同一工具连续失败超过两次，直接放弃该路径并向上汇报，不让 agent 进入重试死循环。

配置上我习惯用一份 JSON 来描述这些边界，既方便评审，也方便同事复用。你可以用一个类似的模版，把步骤上限、工具列表、人工确认点、token 预算、熔断规则都写成字段。

4.3 agent 的可观测性与并发治理

结合热词里反复出现的“ai agent 怎么扛并发”，这周我也专门压了一轮。结论很直接：agent 的并发问题和普通接口完全不同。

普通接口很快，几十毫秒就返回，后端用常规限流就能压住。但 agent 任务动辄十几秒、几十秒，每次任务中间还要调多个工具、攒大量上下文，直接用同步请求处理，后端线程很快就会被占满，接着整批请求排队，再后面就是超时雪崩。

我的建议是走异步任务队列。用户提交需求后直接拿到一个 task id，后台把 agent 任务丢进队列，执行完再通过回调或轮询把结果返回给前端。队列之外，还要给每个 agent 任务配超时时间，超过就自动中断。压测时，不要只盯着单任务延迟，要多路并发跑真实场景，重点观察工具层的重复调用、外部 API 的限流，以及 KV Cache 的内存占用。agent 的可观测性和并发是绑定在一起的——没有每个步骤的 trace，你根本不知道瓶颈到底在哪一次工具调用上。

5. 本周踩坑记录：鉴权、对接与选型问题速查

5.1 token 过期、刷新与 region 403 的排查路径

这周最花时间的一类问题，是跟“token exchange”相关的报错。热词里已经出现过不少：

sign-in could not be completed token exchange failed: token endpoint returned status 403 forbidden: country failed to refresh token: 400 bad request: invalid 'refresh_token': empty string

这类报错看着吓人，排查路径其实很固定。第一步，分清是哪个 token 出了问题——是访问令牌（access token）过期了，还是刷新令牌（refresh token）本身失效。第二步，看返回码：4xx 基本是配置或权限问题，5xx 才是服务端问题。第三步，对比本地存储的 refresh token 是否为空、是否被其他进程改写。

遇到 403 且提示 country 或 region 的情况，先确认账号所属区域和当前使用的网络出口是否符合服务条款。大部分正规 API 都明确限制了可用区域，正确做法是确认账号权限、联系平台支持或调整到合规区域，不要尝试任何绕过手段。至于refresh_token为空，通常不是服务的锅，而是客户端在存储环节把它覆盖或删掉了。检查一下登录态持久化逻辑，看看 token 是存在 localStorage、内存还是服务端 session 里。还有一个容易被忽略的坑是 JWT 续签：刷新时服务器校验了iat（签发时间）和exp（过期时间），如果本机时钟偏差过大，明明没过期的 token 也会被判定无效，同步一下系统时间往往就能解决。

5.2 本地模型与第三方工具链对接

热词里有一条“claude code 调用 lmstudio 的本地模型”，这条我实测过，值得单独说。Claude Code 这类工具要调本地模型，通常走 OpenAI 兼容接口。操作三步就够了：先把 LM Studio 的本地服务跑起来，确认端口号；再把 Claude Code 的 base_url 指向本地地址，比如http://localhost:1234/v1；最后把模型名映射成 LM Studio 里真正加载的那个名字。

这中间最容易翻车的不是接口地址，而是模型名不一致。本地模型起了个别名，但 Claude Code 那边还在用默认名，调用时直接 404。另一个常见问题是上下文长度超出本地模型的限制，报错信息五花八门，但本质都是把模型的最大上下文设得太小。处理方式是把模型上下文窗口调到合理值，或者把 agent 传递的上下文做截断、摘要，而不是一股脑塞给本地模型。

5.3 模型选型里容易被忽略的偏差

最后整理一下这周在模型选型上遇到的偏差。

第一次偏差是“滑动窗口等于长上下文”的误解。滑动窗口只能覆盖最近的 token，和真正的长上下文模型在信息保留上是两码事。第二次偏差是 Longformer 中文效果。论文指标好看，不代表你的中文文档场景好用，同一个任务拿真实语料跑一轮再下结论，别只看 benchmark。第三次偏差是量化之后只看速度、不看精度。INT4 确实快，但某些输出质量波动很大，上线之前必须对关键 prompt 做定量对比。

另外还有一个关于“message: 自定义模型 c”的问题，看着像是自定义模型命名错误导致的调用失败。解决方案很简单：调用模型列表接口，把当前环境里真正可用的模型 ID 拉出来一一对照，别凭记忆写名字。模型 ID 看起来相似，少一个前缀多一个后缀，结果就完全不一样。

写在最后

这周过去之后，我给自己定了一个小规矩：每周做一次 token 用量复盘，用表格记录每个任务的输入 token、输出 token、平均耗时、成功率和 agent 调用步数。不要小看这一步，很多问题在数据里藏不住。比如某个任务 token 突然涨了 40%，一查就发现是工具返回内容没有截断导致上下文膨胀；某个 agent 成功率掉了 15%，一查就发现是步骤上限设得太大，给了它过度尝试的空间。

工具和模型每几个月就换一批，但“把每笔 token 花得明白、把每条 agent 调用链管得住”这个原则，短期内不会变。希望这些经验能帮你少踩几个坑。