企业官网建设流程全解析

先聊个背景。这周我们团队其实没有发布什么大功能，但是周一例会开着开着就变成了“吐槽大会”：有人抱怨一个很简单的文档问答动辄烧掉几万token，有人发现新接的模型在结构化的function calling上把老代码全带崩了，还有人凌晨被线上告警叫起来，因为某个agent在没人干预的情况下循环调了十七轮工具，把供应商API配额干穿了。回头一看，这周的观感高度浓缩成了三句话：更少token、更强模型、更难管的agent。这三件事单独拎出来都不算新话题，但放在同一个星期里集中爆发，就非常值得掰开揉碎聊一聊。

这不是一篇技术教程，更像是我作为一线AI工程从业者的周记复盘。里面会包括这周真实遇到的项目现象、我做的方案取舍、踩过的坑，以及一些可以直接抄走的排查思路和配置参数。无论你是正在接模型做应用的同学，还是在维护agent平台的负责人，应该都能从中找到对应自己处境的部分。

1. 更少 token：这周所有人都在和“token浪费”较劲

1.1 为什么token会越用越多

先看一个最容易被忽略的现象：上下文本身会随着对话轮数膨胀。很多团队的agent实现是“把历史消息全部塞给模型”，第一轮可能才1千token，跑到第十轮就已经1万token，跑完一个真实业务会话可能到3万起步。这3万里有多少是模型真正需要的？我观察下来，往往不到20%。

另一个膨胀来源是为了适配弱模型而额外填充的“提示词话术”。有些团队用的模型能力一般，于是靠写很长的角色设定、few-shot示例、输出格式约束才能稳定结果。这些内容本身不产生业务价值，但每次请求都要跟着走一遍。上周帮一个团队做审计，发现他们的system prompt占了总输入token的47%，而真正有用的用户问题只占6%。这就是典型的“用token买稳定性”，短期能跑，长期账一定算不过来。

再叠加一个因素：多路并行时token是在“烧钱”的，不是像以前调用数据库那样按次数计费。过去我们优化接口性能看的是延迟和QPS，现在还要把token成本作为一等公民来考虑。这周的直观感受是，一个“看起来没毛病”的agent任务，背后可能已经烧掉了相当于几百次普通API调用的成本。所以“更少token”不是省钱的洁癖，而是系统能不能规模化跑下去的前提。

1.2 压缩上下文与分级路由，两种立刻能落地的省钱打法

这周我们实际落地的第一件事，是把历史消息切成“记忆摘要+最近窗口”。说白了就是：超过N轮之前的对话，不再原文塞进去，而是由一个小模型定期把前面的关键信息浓缩成一条摘要。举例来说，原来是：

[system] 你是客服助手… [user] 我要退货 [assistant] 好的，请问订单号是？ [user] 订单号是A12345 …（中间十几轮） [user] 最后一个问题，退款几天到账？

现在变成：

[system] 你是客服助手… [user] 退款几天到账？ [memory] 用户订单号A12345，已发起退货申请，客服已确认收货地址，待退款审核。

这条摘要大概只要几十个token，却能保住最关键的事实状态。实现上也不复杂，核心就是维护一个滑动窗口，窗口外的消息触发一次压缩改写。这其实也呼应了很多人在讨论的“滑动窗口滤波模型”——把这个问题看成状态滤波就很好理解：保留与当前任务最相关的最近状态，丢掉冗余历史。

第二件落地的事是分级路由。我们不再让所有请求都打到最强的模型上，而是在前面加了一个意图分类层。简单问题（翻译、实体抽取、格式整理）直接走便宜的小模型；复杂推理、多步规划才走旗舰模型。比例大概是70%的请求被路由到轻量模型，整体token开销直接少了将近一半，而且用户无感知。

这样做还有个附带好处：输出token往往比输入token更贵，小模型生成废话少，等于同时把输出费用也降下来了。

1.3 治本还得靠缓存和向量检索

压缩和路由属于“能立刻见效”的动作，但治本方向其实在两个地方。

第一是缓存。如果你的应用里有很多固定前缀，比如一个超长的系统提示词、一份产品手册、一套工具说明，这些内容是每次都原样塞给模型的，完全可以用Prompt Cache的方式命中。命中之后，缓存部分的单价会低一个量级，而且首token延迟也大幅下降。前提是：前缀要完全一致，顺序都不能乱。所以我们把“不变的内容”统一放在prompt最前面，把“每次变化的用户问题”放在后面，就是为了最大化缓存命中率。

第二是向量检索替代全量拼接。过去很多人为了让模型“懂业务”，会把一整个知识库的文档拼进上下文，这是最疯狂的token浪费。现在的常规做法是先把文档切块、用embedding模型转成向量存进向量库，每次请求先用用户问题检索出最相关的3~5个片段，拼个几百token进去就够了。这周我们内部把几个“读全部文档”的场景改成RAG之后，token用量下降了不止一个数量级，效果反而更准。embedding模型的选择也不用纠结排行，关键看你的文档语言、检索精度和向量维度成本，实测下来小模型在大文本上并不吃亏。

注意：切块大小直接影响检索质量。我这边实践下来，中文技术文档按300~500字切成一段，重叠50字左右，召回效果比较稳。切太小丢语义，切太大检索不精准。

2. 更强模型：升级之后的第一反应不应该是“开心”

2.1 新模型的三道边界：上下文、工具、输出约束

这周我们接了一个上下文窗口更大、推理能力更强的新模型。团队第一反应是“太好了，以后不用做上下文压缩了”。我当场泼了盆冷水：模型越强，越要把“边界”摸清楚，因为你过去为弱模型做的所有补偿机制都可能失效。

第一道边界是上下文。新模型号称支持128K甚至更长，但实测下来，中段位置的记忆衰减很明显。你不能真的把128K全塞满，尤其是重要信息放在中段时，模型调用工具的准确率会明显下滑。我们现在的经验是：文档型内容能放后面就放后面，对话历史和中间推理过程尽量压缩，核心指令保持在前面几千token以内。

第二道边界是工具调用的格式。换了新模型之后，最崩溃的是function calling行为变了。比如老的模型倾向于严格按照你给的schema输出JSON，新模型可能更“聪明”地省略了某些必填字段，或者多输出一些说明性文字。你原本的解析层就会报错。这周我们排查了一个线上问题，最后发现就是新模型在一个工具参数里主动加了一句解释性的话，导致JSON解析失败。解决方案不是去骂模型，而是把工具schema写得边界更清晰，并且在解析层做容错（比如提取JSON片段再解析）。

第三道边界是输出风格。强模型不等于“听话的模型”，它在开放生成任务里更容易有自己的“表达习惯”。如果你的业务对输出格式有强要求，一定要在接入前用线上真实样本回放一遍，别只看几个测试用例好就上。

2.2 上下文加长以后，隐性成本比想象中高

这周还有一个有意思的观察：模型变强、上下文变长之后，很多人反而更浪费了。因为潜意识里觉得“反正能装下，那就多塞点”。我这边算了一笔账：一次2万token的输入请求，如果一天跑10万次，一年下来光输入费用就是一笔很大的数字，而且随着时间推移还会因为长度翻倍成本翻倍。更麻烦的是，长上下文请求的处理时间更长，并发瓶颈提前到来。

我们这周处理的一个实际案例：一个批量处理任务原本分成100个子任务并行，每个子任务用短上下文模型，跑得挺稳。有人为了省事改成长上下文模型，一次性把100个文件全塞进去，结果发现耗时是原来的3倍，还频繁触发了供应商侧的速率限制。这不是模型不行，是用法错了。所以接新模型的时候真要算“全链路账”：不只算单次token单价，还要算延迟、并发上限、失败重试成本。

2.3 强模型进场之后，灰度与回滚比以往更重要

以前模型升级顶多是“效果变好一点”，现在模型行为变化会直接改变产品逻辑，所以必须把模型切换当成一次上线来管理。我的做法是：老模型和新模型并行跑一周，流量按1%、10%、50%、100%的比例灰度，每个阶段对比关键指标——任务成功率、平均轮数、token消耗、用户反馈。这周在灰度到30%的时候，我们发现新模型的工具调用失败率比老模型高了2个百分点，原因就是上面说的schema问题。幸好有灰度机制，不然直接全量上，又是一次线上事故。

另外建议大家给每个模型版本打上标识，并在日志里记录下来。很多团队压根不知道线上跑的是哪个模型版本，出了问题都没法复现，这是很危险的。模型服务商经常悄悄调整模型行为，所以**“锁定版本”比想象中重要**。如果供应商支持固定快照版本，尽量用快照；如果支持降级回滚，就提前确认好回滚路径。这些“工程琐事”在平时不起眼，出事的时候就是救命的。

3. 更难管的 agent：从“能跑”到“能管”是质的跨越

3.1 这一周agent失控的几种典型姿势

这周我们隔壁组一个agent半夜跑飞了，原因是它在处理用户退款时反复调用“查询库存”工具，因为查询结果始终返回“库存不足”，它就天真地认为“换个姿势再查一次就能查到”，一路循环了17轮，最后触发了供应商的配额上限，整条流水线直接熔断。这是非常典型的agent在错误前提下的重复尝试。

还有一种是目标漂移。多步骤任务里，agent做到第三步之后，已经完全忘了最初用户要什么，开始自己给自己加戏。比如让它“总结这份PDF”，它中途开始“顺便生成一份PPT提纲”，然后继续“顺便查一下行业背景”。单看每一步都合理，连起来就是灾难。

第三种是并行互相打架。我们内部有多个agent共享同一个工具API，这周出现了一个agent把另一个agent刚写入的数据给覆盖掉的破事。原因很简单：两个任务操作的是同一个对象，但没有加锁也没有版本校验。这类问题在agent数量少的时候根本看不见，一旦数量上来了就会集中爆发。

所以说“更难管的agent”并不是危言耸听，它本质上是从“单次调用”到“有状态、长周期、自主决策”的复杂度转移。模型越强，agent越能自主做事，也就越需要更强的管理机制兜底。

3.2 Agent能扛多少并发？先解决幂等和配额

热词里有人问“AI agent怎么扛并发”，这其实是两个问题：一个是能扛多少，一个是瞎扛会出什么事。

能扛多少，取决于你的工具层能承受多少。agent本身只是一个调度器，真正的瓶颈在外部API、数据库、下游系统。我们这周做了一轮压测，结论是：单机部署的agent服务，在100个并发任务以内还算稳定；再往上，瓶颈不再是agent引擎，而是它调用的那些工具接口。所以你的agent平台一定要在设计之初就引入并发配额：每个agent任务最多占几个并发位、每秒最多调几次工具、每天最多烧多少token。没有配额，等于让一群手贱的人在金库里搬钱。

比配额更要紧的是幂等设计。一个agent失败后重试，如果工具不是幂等的，就会产生重复订单、重复扣款、重复写库。这周我们给所有写操作工具加上了request_id去重，成本很低，但避免了好几次事故。给agent用的工具和给人用的接口，设计哲学应该不一样，前者必须更健壮、更保守。

3.3 想让agent不乱跑，状态机是必修课

很多项目把agent实现成了一个大while循环，里面不断“推理-调用-观察”。这种写法在Demo阶段没问题，但生产环境一定要引入状态管理。我的建议是每个agent任务都用一个显式的状态机：待执行、执行中、等待工具结果、需要人工审批、失败、重试中、完成。

有了状态机之后，很多事情就变得可治理了：

• 超时控制：每个任务和每一步都设置超时时间，超时就终止并告警。
• 循环检测：如果同一个工具连续被调用超过N次且参数无变化，直接判为死循环，进入人工处理队列。
• 预算封顶：每个任务设置最大token用量和最大步数，到达阈值强制终止。
• 审计日志：把每一步的输入、输出、token消耗、决策理由都结构化记录下来，出了问题可以复盘。

这周我对团队的要求是：agent的每一次工具调用都必须有记录，每一条记录都必须能回答“它为什么要这么干”。这不是为了监控员工，是为了排查时不被agent逼疯。

3.4 用框架还是自建？我的真实取舍

关于Agent框架，这周也被问了很多次。我的观点是：只做应用层，可以站在成熟框架肩膀上；但你要运营一个“多agent协作的生产系统”，迟早要向自建方向演进。框架能帮你快速把“单agent跑通”，但多agent之间的资源共享、并发控制、审批流程、成本审计，这些恰恰是通用框架里最薄弱的部分。不是框架不好，而是它要兼容所有用户，做不到为你的业务深度定制。

如果你还在早期，我的建议是先认真用好一个框架，把业务跑通，再把框架里那几个核心接口换成自研实现，也就是“先跑通，再替换”。全自研的前提是你团队里有对LLM机制、状态管理、分布式调度都熟的人，否则会陷入“造火箭”的陷阱。

4. 本周踩坑与排查实录

这一节我按真实发生的问题来写，每个都给排查思路和解决路径，以后你们遇到同类的可以少走弯路。

4.1 token exchange failed：登录链路里最常见的“伪网络问题”

这周好几个同事反馈某个内部工具登录报错：token exchange failed，后面跟着一大串请求错误。第一反应是网络问题，但排查下来发现是本地系统时间与认证服务器偏差太大，导致JWT签名验证不过。JWT里有iat和exp字段，本地时钟快了五分钟，客户端拿着这个token去换refresh_token，服务端校验直接判定无效。解决方法是同步系统时间，并且SDK里的时钟容差不要设0。

如果你的应用是自己做的JWT续签，要注意token exchange的本质流程：

1. 用短期有效的access_token访问资源；
2. access_token快过期时，用refresh_token去认证服务换新的access_token；
3. 认证服务校验refresh_token的状态、过期时间、是否被吊销。

这里最常见的坑就是refresh_token过期没有兜底逻辑。这周我还真见过一个报错：refresh_token为空字符串。排查下来是前端在localStorage里没存到refresh_token，刷新页面后直接拿空字符串去请求续签。解决方案很简单：续签接口加参数校验，初期就报错而不是发到后端；前端启动时检查本地token完整性，缺失就走静默重新登录。

还有，如果你对接的是海外模型平台的OAuth流程，token exchange这一步失败时，先确认网络能直连到它的域名，而不是先怀疑代码逻辑。这周一次“登录失败”最后定位到就是出口网络临时抖动，重试三次就成功了。

4.2 用Codex类工具对接国内模型API，注意这俩地方

本周团队里有人想把Codex这类CLI工具接到国内的模型API（比如千问的Token Plan），遇到了“代码能跑但消息发不出去”的现象。这类工具一般写死了官方API的基础地址和鉴权方式，要想改成第三方服务，需要做两件事：

第一，改base_url。找到配置文件的端点配置，把请求目标从官方域名换成国内模型服务商兼容端点。注意别只改host，有些路径前缀也要跟着调。

第二，调整鉴权头。有些工具默认带Bearer Token，而国内服务商兼容的是另外一个Header名字，或者要求带额外的项目标识。不改这个，就会出现“请求发出去了，但服务端不认”。

除此之外，这类工具往往还会申请一个本地沙盒环境，用来执行代码或隔离agent运行。这周我们遇到过一次“agent沙盒更新不了”导致消息发不出去。排查结论是：沙盒更新其实是一个后台下载过程，失败原因通常是磁盘满了或者下载源被网络策略挡住了。处理办法是把沙盒目录缓存清掉、确认磁盘预留空间，然后手动触发一次性更新；不要反复重启，容易留下半个更新状态的坏缓存。

4.3 请把“重新生成”按钮当成危险操作

这周还发现一个业务逻辑上的大坑：很多产品给agent回复加了一个“重新生成”按钮，用户一点，前端直接重新发起一次请求，完全不考虑上一次请求是不是已经在下游产生了副作用。比如用户让agent“帮我查库存然后下单”，第一次请求已经执行了下单动作，用户觉得回复太慢又点了一下“重新生成”，结果下了两单。

这类问题的解法很朴素：前端生成一个requestId，后端用requestId做幂等。同一个requestId重复请求，直接返回第一次的结果。这跟上面说的给工具加request_id是一个思路，先有幂等，才敢谈重试和交互。这个坑特别容易出现在“看起来很简单”的AI功能里，我希望各位引以为戒。

5. 一些在细节里磨出来的体会

这周最深的感受是：AI工程真正难的从来不是让模型“变聪明”，而是让一切行为可控、可预算、可解释。模型能力越强，agent能做的事越多，系统越复杂，工程侧的“管理成本”就越高。这不是逆水行舟，而是必然的演化方向。

给大家两个非常具体的小建议。第一个是从这周开始，给每个agent任务加一个“预算上限”字段，哪怕你的场景看起来根本烧不了多少钱。我见过太多系统在上线三个月后突然账单爆炸，原因就是没有预算护栏。预算字段可以很小，比如单任务最多30步、最多5万token，但一定要有，否则你连“失控”的定义都没有。

第二个建议是建立“AI行为审计”的习惯。每天挑三五个失败的agent轨迹，像看代码review一样看它的推理过程和工具调用，不要只看结果。结果成功不代表过程合理，过程离谱的结果早晚会出事。这周我们就是从一条“看似成功但实际绕了远路”的轨迹里，挖出了一个提示词设计问题，顺手省掉的token大概够跑几千次普通请求。

AI工程这个领域变化太快，这周的经验下周可能就过时。但“控制成本、拥抱新模型、管好agent”这三件事，短期内不会变。希望这篇周记对你有用。