这周在产线上盯了三天agent调度日志又跟算法团队吵了两轮token预算晚上回家看到新发布模型的benchmark心里冒出三个词更少token、更强模型、更难管的agent。这就是我这周最真实的工作观感不是行业报告就是一个AI工程师在项目里摸爬滚打的记录。先交代一下背景。我所在的团队维护一套对外服务的AI应用底层接各家大模型API上层跑着十几个agent流程。这周我们做了一轮集中的成本优化和稳定性治理正好把token、模型、agent这三条线全过了一遍。过程中该踩的坑基本没落下有些问题排查到凌晨才定位到根因。这篇文章就顺着这三条线展开把思路、参数、踩坑记录都放出来给同样在做AI工程的同行做个参考。1. 三个变化是同一件事的不同侧面1.1 更少token工程团队集体转向成本敏感早两年做AI应用大家习惯把什么都往上下文里塞prompt写得越长越觉得安心。但token不只是技术参数它直接对应账单。我算过一笔账假设一个客服类agent日活1万用户每人每天对话10轮每轮输入2000 token含历史上下文、输出400 token那么单日总token消耗就是10000乘以10再乘以2400等于2.4亿token。按当前主流API的混合计费价格折算单日成本就是数千元级别一个月下来够买一台不错的服务器了。这个数字摆出来不需要任何人再提醒省着点用团队自己就开始琢磨怎么把token降下来。这周我们做的第一件事就是给所有prompt做减法、给上下文做节流、给输出做约束。从结果看压缩后同样的业务场景输入从2000 token降到1200 token左右直接省了三分之一以上的成本。而且效果没有肉眼可见的变差这给了我们继续往深里做的信心。1.2 更强模型能力上移工程下移另一个明显变化是模型本身变强了。以前需要靠复杂提示词技巧才能完成的任务现在用新模型直接问就能答对七八成。这看起来是好事但对工程团队来说麻烦也在悄悄转移基础问答能力不需要你操心了但你得操心路由策略、降级链路、以及换模型之后老功能会不会悄悄变差。我举个实际例子。我们有一个用来抽取订单信息的环节旧模型时代需要写三段示例加五个约束才能稳定输出JSON结构。上个月灰度了一个更强的模型后同一段prompt输出质量确实提升了但有个别case的输出风格变了导致下游解析逻辑拿到了格式合法但语义微妙的脏数据。模型变强不是单点升级它会引起整个链路的连锁反应工程侧的工作从教模型怎么答变成了验证模型答得好不好、答歪了怎么兜底。1.3 更难管的agent自由度与失控风险并存如果说token和模型是量变那agent就是质变。普通接口调用是一次请求一次响应出错有明确的错误码agent不一样它会自主决定调用哪些工具、循环多少轮、按什么顺序完成任务。一个看似简单的帮我查一下订单并处理退款任务模型在内部可能执行了十几次工具调用中间还穿插着决策、纠错、重试。自由度带来的是失控风险。这周我们就遇到一个真实事故某个agent在处理异常输入时陷入了自我纠正死循环连续调用了二十多次大模型接口才被超时机制打死单任务token消耗是正常情况的八倍。更麻烦的是这类问题的报错通常非常模糊比如agent execution terminated due to error这种信息量约等于零的日志。你根本不知道是哪个工具挂了、是参数错了还是模型决策出了问题。agent的治理已经从要不要做变成了不做就等着半夜被电话叫醒。2. 更少token这一周的成本优化实战2.1 系统提示词压缩从8000字到1800字的减法很多项目的prompt是长期堆出来的今天加一句规则、明天加一个示例最后膨胀到了几千字里面真正有用的可能不到三成。我们这周做一个系统提示词压缩原则只有一条每一句话都必须能回答删掉它输出会变差吗这个问题回答不上来就删。实际做法是拿历史日志做统计。我们把过去一万条真实请求的输入和输出拉出来逐条分析系统提示词里哪些指令在输出中产生了可观察的影响。比如原先生动形象地写了一段三百字的客服人设你是一个温柔耐心的售后顾问擅长倾听用户诉求语气亲切自然不主动寒暄但要有温度……压缩之后变成一句话你是售后客服语气简洁不主动寒暄。输出质量没有可感知的下降token省了一大截。压缩prompt的时候要注意一个坑不能只看一两条case就拍板。有些规则只在极端场景才生效平时测不出来。我的经验是压缩后至少要跑一周的线上数据回流对比关键指标比如任务完成率、用户重试率有没有变化确认没问题再保留新版本。prompt的每个版本都留档线上随时可回滚。2.2 上下文工程滑动窗口、递归摘要与关键信息筛选token消耗的大头往往不在系统提示词而在塞进上下文的业务数据。最典型的场景是长文档处理用户丢进来一份几十页的PDF如果直接把全文塞给模型一次调用就可能吃掉几万token而且模型对中间部分的内容往往视而不见——注意力机制决定了它更关注开头和结尾中间容易被稀释。这一周我们重点优化了长文本场景核心思路是别指望模型看完所有内容而是替它把真正相关的内容挑出来。具体用了三招第一招是滑动窗口采样。把长文本按固定长度切成窗口我这边以128 token为一个基本窗格大概相当于100个汉字然后用embedding计算每个窗口和当前问题的相似度只保留相似度最高的前几个窗口。这个思路其实跟信号处理里的滑动窗口滤波有点像不是把整段信号都拿去做分析而是按窗口扫描后提取有用的片段过滤掉噪声效果立竿见影。第二招是递归摘要。对超长文档先按段落调用模型生成局部摘要再把摘要合起来做二次摘要最后只把浓缩后的摘要给下游使用。多轮摘要肯定要多花调用次数但如果能把输入token从两万字降到两千字整体成本依然是划算的。第三招是检索增强。在拼上下文之前先做向量检索召回top5到top10的相关片段再做一次重排过滤掉重复和弱相关的内容最后拼装进prompt。我们实践下来最终拼装进入上下文的业务内容控制在4000 token以内既能覆盖大多数问题的答案成本又可控。检索命不中的场景再走全文摘要兜底。2.3 结构化输出把输出token压到最小输入侧省了输出侧也别放过。很多模型默认会在答案里夹带解释性文字比如你让它判断订单是否需要退款它给你回一段根据您的描述订单符合退款条件建议您联系客服处理之类的小作文。这些解释对于人看有温度对于程序消费就是纯浪费。我们的做法是全面改用结构化输出约束。让模型直接返回一个JSON对象规定好字段名和取值枚举比如{action: refund, confidence: 0.94}。这样输出token从几百字降到几十个字解析也更稳定。需要注意的一点是约束太死会在某些边缘case上导致模型无话可说所以schema设计上要留一个reason字段专门放必要的说明这样既控制了体积也不至于把模型的判断依据完全堵死。2.4 token用量监控与预算告警机制省下来的token不会自己出现在报表里你得先能看见。这周我们花了大半天时间把token用量监控补齐了核心是在网关层做统一计数按业务项目、agent实例、模型名称三个维度打点。每个请求进来的时候记录input token和output token聚合后落到时序数据库里。监控之外预算告警更重要。我们设了三层阈值单日总预算、单请求上限、单agent任务上限。任何一层超了都会触发对应的动作轻则告警通知重则自动把流量降级到替代模型或者直接拒绝非核心请求。举个例子每个agent任务我们设了5万token的硬上限超过直接中断并向用户返回任务过于复杂请拆分后再试。这个上限值不是拍脑袋定的是统计了历史任务分布的95分位数又留了安全余量。有了这层护栏至少不会再出现一个死循环agent把当天预算烧穿的情况。3. 更强模型模型能力升级后的工程侧适配3.1 模型灰度升级与降级链路设计模型变强了但你不能像换手机壳一样换模型尤其是线上业务。这周我们把一个新模型灰度到生产环境前期只放了5%的流量跑了三天观察错误率和耗时。灰度期间果然发现了一个之前测试没暴露的问题新模型对某些中文长尾表达的响应速度和旧模型差异很大平均延迟高了一倍多。模型的升级必须配套降级链路。我们的设计是三层第一优先用旗舰模型处理复杂任务第二优先用经济型模型处理常规任务第三层用本地轻量模型兜底关键路径。每一层都设置超时和失败计数连续失败自动切到下一层。网关层做路由决策把请求按规则分发到对应模型并且实时感知每个模型后端的健康状态。这样就算某个模型服务本身出问题用户的请求也不会整体挂掉只是体验降一级。3.2 从提示词工程走向上下文工程模型越强传统意义上的提示词工程边际收益在递减。以前你要精心设计措辞、构造few-shot示例、研究各种prompt技巧才能让模型输出稳定现在模型本身理解能力上去了你更需要思考的反而是给它看什么数据。我把这理解成从提示词工程向上下文工程的演进提示词工程解决的是怎么问上下文工程解决的是让它看到什么以及按什么顺序让它看。具体到工程实现上上下文工程的核心操作包括检索召回、相关度重排、文本截断、摘要压缩、以及关键信息的结构化抽取。这些环节共同决定了进入模型的上下文质量。同样的模型和同样的提示词给不同质量的上下文输出效果可以差出几个档次。这块工作目前没有统一的开箱即用方案不同场景要自己调但大方向是一致的上下文越精炼、越贴合当前问题模型的表现越好token消耗越少。3.3 检索质量embedding选型与分块策略做上下文工程绕不开检索做检索绕不开embedding模型选型。这周正好有同事在对比几个主流的embedding模型市场上排行靠前的那些模型质量差距确实存在尤其在中文长尾语义和中英文混合场景下选错模型会让召回质量明显缩水。我们内部做了一个小评测集对比模型的top10召回命中率最后选的方案在命中率上比备选方案高出近8个百分点这个差距放在生产环境就是质的差别。分块策略同样影响检索效果。固定按字数切分比如512字一块实现简单但会把逻辑完整的段落硬生生切断导致embedding表示失真。我们改成按语义切分先按段落边界拆段落太长的再按标题、列表、句号等语义边界细分。这样每一块都是一个相对完整的语义单元召回的内容更准。这块没有通用的最优参数必须拿自己业务的数据反复试。3.4 评测回归集换模型的守门员模型升级最大的隐形风险是回归。说句实在话大部分线上问题不是模型本身不行而是升级之后行为变了下游解析、业务逻辑没跟上。为了避免这个坑我们这次在使用新模型之前硬是挤时间建立了一个业务相关的评测回归集。回归集不需要很大三四百条精选case就够用了。每条case包含输入、期望输出、关键判定点。比如抽取类任务我们会标好期望的JSON字段和取值分类任务标好期望的类别问答任务标好期望包含哪些关键信息。每次换模型、改prompt、调上下文策略都拿这批case跑一遍算准确率和格式合法率。跑完对比基线任何关键指标下降超过两个百分点就不允许上线。这套东西虽然简陋但已经连续拦住了两次看起来新模型更强、实际某类case更差的坑。4. 更难管的agent从demo到生产的治理经验4.1 agent进生产的三道坎demo阶段的agent和能上生产的agent是两个物种。demo阶段跑通一条理想路径就行生产环境要面对的是无穷无尽的意外输入。我这周总结了agent转产必须跨过的三道坎。第一道坎是多轮循环的稳定性。agent基本都有计划-执行-反思的循环结构一个任务少则三五轮多则几十轮。每一轮都可能产生新状态、引入新错误循环越长越容易偏离主线。我们处理的办法是给每个agent类型设置最大轮数上限比如默认10轮超了就停止并返回当前进度让用户决定是否继续。同时定义好任务完成的判定条件一旦满足就强制退出循环不要等模型自己判断我觉得结束了。第二道坎是状态管理。普通接口是无状态的agent不是。它跑一个任务可能要几分钟甚至更长时间中间挂了怎么办进度存哪我们用一个独立的状态存储服务来记录每个agent实例的阶段、已完成的工具调用、已收集的数据。这样就算进程重启agent还能从断点恢复而不是从头再来。第三道坎是工具调用的可靠性。agent的能力上限取决于它手上有哪些工具但工具越多出错面越大。可能工具本身返回的数据格式变化了、接口超时了、权限过期了每一样都会打断agent的执行流程。我们的做法是给每个工具封装统一的出错返回结构agent调用工具失败时能拿到标准化的错误信息再由决策层决定是重试、换方案还是终止任务。4.2 并发控制agent怎么扛住流量AI agent怎么扛并发是我们内部群里这周讨论最多的问题之一。很多人的直觉是用线程池并发跑agent就完事了实际完全不是这么回事。一次普通的LLM调用是毫秒到秒级的一个agent任务却是几十次LLM调用的串联跑一次要几十秒甚至几分钟。这意味着单个agent任务对后端API的请求压力会被放大十到二十倍。我们做过一个粗略测算一个agent任务平均做12次LLM调用每次调用500毫秒串行执行就是6秒。如果同时启动50个这样的agent瞬时对上游API的并发请求量就是50乘以12等于600次调用挤在一个时间窗口里远超很多API服务的配额。所以并发控制不能只按请求数限流得按token消耗速率限流。我们同时在线程池、信号量、网关限流三层做了控制线程池限制同时运行的agent实例数信号量控制每个agent内部并发调用大模型的最大数网关层按每分钟token配额做整体限流。队列也很重要。当并发达到上限新任务不是直接拒绝而是进入有界队列等待。队列满了才拒绝避免雪崩。我们还给每个agent任务加了优先级简单任务优先跑复杂的、耗时长的任务往后排这样用户的即时提问不会因为后台批量任务占满了资源而卡住。4.3 可观测性给每个agent一套追踪体系排查agent问题最怕的是什么是不知道它内部发生了什么。普通接口出问题看一眼错误栈基本就知道原因agent出问题你面对的是一长串工具调用记录和模型决策历史没有合适的追踪手段就只能抓瞎。我们这周给所有agent接了链路追踪。每个agent实例分配一个trace_id从任务开始到结束每一步都埋点记录当前执行到哪个状态、调用了哪个工具、传入参数是什么、返回结果是什么、每次LLM调用的输入输出token数和耗时。排查问题的时候直接按trace_id把整条执行链拉出来一眼就能看到它是在哪一步走偏的。状态机是另一个好工具。我们把agent的执行过程抽象成有限个状态初始化、计划中、取数中、决策中、执行工具、异常处理、完成、终止。日志里每一行都带当前状态字段出了问题可以快速定位到卡在取数中还是反复在异常处理里打转。这套体系建成之后排查问题的平均时间从小时级降到了分钟级这是这周投入产出比最高的一件事。4.4 权限收敛与工具白名单agent的能力来自工具但工具权限给大了就是灾难。我们内部有一条铁律给agent开一个工具之前必须回答它真的需要这个权限吗。比如一个做售后分析的agent它只需要读订单表和售后记录那就只给它只读权限绝不给写库的权限。更不需要给它一个能执行任意SQL的工具那等于把数据库钥匙挂在门把手上。具体的做法是建立工具白名单每个agent类型都有各自的允许调用集合不在名单里的工具直接拒掉。白名单做成动态配置运营人员可以在管理后台调整不用发版。高危工具单独加一层强管控所谓高危就是一旦出错会造成实质影响的比如批量发消息、改数据、触发业务流程等。这类工具在agent调用时不是直接执行而是生成一个待审批的请求推到人工审批队列里由运营人员确认后才真正执行。4.5 人工审批与熔断兜底为什么一定要保留人工审批环节因为再强的模型也有胡说八道的时候。我们的经验是agent在低风险、高频、规则明确的场景里能替代人做得很稳但在高影响、不可逆的动作上必须保留人的判断。审批环节多花十几秒换来的是出大事概率的大幅下降这笔账非常划算。兜底机制也不能少。我们给每个agent配了熔断器连续失败N次我们设置的是连续5次就自动熔断不再接收新任务同时触发告警。事后人工检查原因确认修复后才能手动恢复。新上线的agent还会先跑一段时间的影子模式或监督模式影子模式下agent照常执行但结果不直接落地只记录它的决策质量监督模式则是关键动作都要人工过一遍。这套机制让我们能在控制和效率之间找到一个还算舒服的平衡点。5. 常见问题与排查技巧实录5.1 token用量暴涨的四种典型场景这周处理了几次token用量异常告警规律性很强整理了四种典型场景现象可能原因排查方法解决动作单请求token突增业务数据被全量塞进上下文查单请求的token分布看哪个字段最大改成检索召回截断控制最大上下文长度单任务token总量爆炸agent死循环反复调用模型看trace里的调用次数和轮数设置最大轮数和单任务token硬上限日均token缓慢爬升对话历史越积越长分析会话平均轮数和历史token占比做历史压缩超过N轮启递归摘要某模型后端token占比异常流量路由被集中到高价模型按模型维度拆分成本报表调整路由比例加经济模型的优先级重点是第一类和第二类。第一类是最常见的prompt里塞了长文本问题第二类是最危险的agent死循环问题都需要靠监控数据及时发现不能等账单出来才后悔。5.2 agent执行中断的排查SOP这周我们遇到过agent execution terminated due to error这类模糊报错跟同事梳理了一个排查SOP现在Team内基本按这个流程走第一步拿到trace_id拉出完整的执行时间线先看中断发生前最后成功的一步是什么。第二步定位是哪个工具调用出了问题是超时、是返回格式不对、还是权限校验失败。第三步看模型当时的决策上下文它是在什么信息基础上决定调用这个工具的判断是数据问题还是模型误判。第四步如果是超时看工具本身的响应是不是毛刺要不要加超时重试如果是权限问题检查token是否过期、角色是否变更如果是模型误判就要考虑在prompt里加约束或者把关键决策改成规则判断。这个SOP跑下来大部分agent中断问题都能在十分钟内定位到根因。最反直觉的一点是很多看起来像模型抽风的问题根因其实是工具返回的数据格式出现了细微变化模型只是被脏数据误导了。所以排查的时候别急着怪模型先查数据链路。5.3 鉴权token过期与续签设计这周还遇到一类问题agent在长时间任务执行中调用内部服务和外部API时出现鉴权失败。常见报错就是token交换失败、refresh_token为空之类的。原因很典型——agent任务可能跑几分钟甚至更久而访问token的有效期可能只有几十分钟任务执行过程中token悄悄过期了后续的工具调用全部失败。我们的经验是多步任务场景不能沿用普通接口的每个请求都带token模式应该在任务开始时获取一次长期凭证并在任务内部做好自动续期的逻辑。设计上一般是短token加长refresh token组合短期凭证负责具体请求refresh token负责在短期凭证过期前主动换新。续签动作放在任务的状态机里在执行工具调用之前先检查当前凭证的有效期剩余时间不足阈值就提前刷新而不是等请求报401了才补救。另外refresh token最好不要在每次请求里都带着刷新只在确定过期时刷新一次减少不必要的网络交互和出错面。5.4 模型输出不稳定与JSON解析失败结构化输出解决了token浪费的问题但引入了另一个问题模型偶尔会返回格式非法的JSON比如多了个逗号、字段名被改了、或者整个输出被一段解释性文字包裹。这类问题在我们的生产环境中占所有异常的比例不低。处理思路是三层防御。第一层是输出约束能用tool calling或schema约束的尽量用让模型在结构框架内生成。第二层是宽容解析用容错性强的JSON解析器能处理尾逗号、引号转义不严格等小毛病解析失败时可以进行一次简单的修复比如截取第一个左花括号到最后一个右花括号之间的内容再解析。第三层是业务兜底schema校验失败就重试一次重试还失败就返回默认值或转人工处理。实测下来这套组合拳能把JSON解析失败率降到可接受的范围但这块不可能完全消灭必须接受偶尔需要一个兜底的现实。结尾的几句实在话这周最深的体会是AI工程的重心正在从能不能做出来转向能不能稳住。更少token、更强模型、更难管的agent这三件事其实是同一个信号——AI应用开始进入精细化运营阶段了。省token不只是省钱省下的成本可以换成更强的模型、更多的场景覆盖管好agent不只是防故障防住的是不可控对用户信任的消耗。最后分享一个小技巧每周固定花半小时看一次token用量报表和agent失败日志这件事性价比极高。很多严重问题在报表里提前一两天就有征兆比如某个agent的token消耗连续几天缓慢上升、某个工具的错误率悄悄抬升。你不需要每次都做大的治理但保持对数据曲线的敏感能让你在问题发酵之前就动手。这比等到线上出事故再救火要省太多力气。 更少Token、更强模型、更难管的Agent：AI工程化实战与踩坑记录
这周在产线上盯了三天agent调度日志又跟算法团队吵了两轮token预算晚上回家看到新发布模型的benchmark心里冒出三个词更少token、更强模型、更难管的agent。这就是我这周最真实的工作观感不是行业报告就是一个AI工程师在项目里摸爬滚打的记录。先交代一下背景。我所在的团队维护一套对外服务的AI应用底层接各家大模型API上层跑着十几个agent流程。这周我们做了一轮集中的成本优化和稳定性治理正好把token、模型、agent这三条线全过了一遍。过程中该踩的坑基本没落下有些问题排查到凌晨才定位到根因。这篇文章就顺着这三条线展开把思路、参数、踩坑记录都放出来给同样在做AI工程的同行做个参考。1. 三个变化是同一件事的不同侧面1.1 更少token工程团队集体转向成本敏感早两年做AI应用大家习惯把什么都往上下文里塞prompt写得越长越觉得安心。但token不只是技术参数它直接对应账单。我算过一笔账假设一个客服类agent日活1万用户每人每天对话10轮每轮输入2000 token含历史上下文、输出400 token那么单日总token消耗就是10000乘以10再乘以2400等于2.4亿token。按当前主流API的混合计费价格折算单日成本就是数千元级别一个月下来够买一台不错的服务器了。这个数字摆出来不需要任何人再提醒省着点用团队自己就开始琢磨怎么把token降下来。这周我们做的第一件事就是给所有prompt做减法、给上下文做节流、给输出做约束。从结果看压缩后同样的业务场景输入从2000 token降到1200 token左右直接省了三分之一以上的成本。而且效果没有肉眼可见的变差这给了我们继续往深里做的信心。1.2 更强模型能力上移工程下移另一个明显变化是模型本身变强了。以前需要靠复杂提示词技巧才能完成的任务现在用新模型直接问就能答对七八成。这看起来是好事但对工程团队来说麻烦也在悄悄转移基础问答能力不需要你操心了但你得操心路由策略、降级链路、以及换模型之后老功能会不会悄悄变差。我举个实际例子。我们有一个用来抽取订单信息的环节旧模型时代需要写三段示例加五个约束才能稳定输出JSON结构。上个月灰度了一个更强的模型后同一段prompt输出质量确实提升了但有个别case的输出风格变了导致下游解析逻辑拿到了格式合法但语义微妙的脏数据。模型变强不是单点升级它会引起整个链路的连锁反应工程侧的工作从教模型怎么答变成了验证模型答得好不好、答歪了怎么兜底。1.3 更难管的agent自由度与失控风险并存如果说token和模型是量变那agent就是质变。普通接口调用是一次请求一次响应出错有明确的错误码agent不一样它会自主决定调用哪些工具、循环多少轮、按什么顺序完成任务。一个看似简单的帮我查一下订单并处理退款任务模型在内部可能执行了十几次工具调用中间还穿插着决策、纠错、重试。自由度带来的是失控风险。这周我们就遇到一个真实事故某个agent在处理异常输入时陷入了自我纠正死循环连续调用了二十多次大模型接口才被超时机制打死单任务token消耗是正常情况的八倍。更麻烦的是这类问题的报错通常非常模糊比如agent execution terminated due to error这种信息量约等于零的日志。你根本不知道是哪个工具挂了、是参数错了还是模型决策出了问题。agent的治理已经从要不要做变成了不做就等着半夜被电话叫醒。2. 更少token这一周的成本优化实战2.1 系统提示词压缩从8000字到1800字的减法很多项目的prompt是长期堆出来的今天加一句规则、明天加一个示例最后膨胀到了几千字里面真正有用的可能不到三成。我们这周做一个系统提示词压缩原则只有一条每一句话都必须能回答删掉它输出会变差吗这个问题回答不上来就删。实际做法是拿历史日志做统计。我们把过去一万条真实请求的输入和输出拉出来逐条分析系统提示词里哪些指令在输出中产生了可观察的影响。比如原先生动形象地写了一段三百字的客服人设你是一个温柔耐心的售后顾问擅长倾听用户诉求语气亲切自然不主动寒暄但要有温度……压缩之后变成一句话你是售后客服语气简洁不主动寒暄。输出质量没有可感知的下降token省了一大截。压缩prompt的时候要注意一个坑不能只看一两条case就拍板。有些规则只在极端场景才生效平时测不出来。我的经验是压缩后至少要跑一周的线上数据回流对比关键指标比如任务完成率、用户重试率有没有变化确认没问题再保留新版本。prompt的每个版本都留档线上随时可回滚。2.2 上下文工程滑动窗口、递归摘要与关键信息筛选token消耗的大头往往不在系统提示词而在塞进上下文的业务数据。最典型的场景是长文档处理用户丢进来一份几十页的PDF如果直接把全文塞给模型一次调用就可能吃掉几万token而且模型对中间部分的内容往往视而不见——注意力机制决定了它更关注开头和结尾中间容易被稀释。这一周我们重点优化了长文本场景核心思路是别指望模型看完所有内容而是替它把真正相关的内容挑出来。具体用了三招第一招是滑动窗口采样。把长文本按固定长度切成窗口我这边以128 token为一个基本窗格大概相当于100个汉字然后用embedding计算每个窗口和当前问题的相似度只保留相似度最高的前几个窗口。这个思路其实跟信号处理里的滑动窗口滤波有点像不是把整段信号都拿去做分析而是按窗口扫描后提取有用的片段过滤掉噪声效果立竿见影。第二招是递归摘要。对超长文档先按段落调用模型生成局部摘要再把摘要合起来做二次摘要最后只把浓缩后的摘要给下游使用。多轮摘要肯定要多花调用次数但如果能把输入token从两万字降到两千字整体成本依然是划算的。第三招是检索增强。在拼上下文之前先做向量检索召回top5到top10的相关片段再做一次重排过滤掉重复和弱相关的内容最后拼装进prompt。我们实践下来最终拼装进入上下文的业务内容控制在4000 token以内既能覆盖大多数问题的答案成本又可控。检索命不中的场景再走全文摘要兜底。2.3 结构化输出把输出token压到最小输入侧省了输出侧也别放过。很多模型默认会在答案里夹带解释性文字比如你让它判断订单是否需要退款它给你回一段根据您的描述订单符合退款条件建议您联系客服处理之类的小作文。这些解释对于人看有温度对于程序消费就是纯浪费。我们的做法是全面改用结构化输出约束。让模型直接返回一个JSON对象规定好字段名和取值枚举比如{action: refund, confidence: 0.94}。这样输出token从几百字降到几十个字解析也更稳定。需要注意的一点是约束太死会在某些边缘case上导致模型无话可说所以schema设计上要留一个reason字段专门放必要的说明这样既控制了体积也不至于把模型的判断依据完全堵死。2.4 token用量监控与预算告警机制省下来的token不会自己出现在报表里你得先能看见。这周我们花了大半天时间把token用量监控补齐了核心是在网关层做统一计数按业务项目、agent实例、模型名称三个维度打点。每个请求进来的时候记录input token和output token聚合后落到时序数据库里。监控之外预算告警更重要。我们设了三层阈值单日总预算、单请求上限、单agent任务上限。任何一层超了都会触发对应的动作轻则告警通知重则自动把流量降级到替代模型或者直接拒绝非核心请求。举个例子每个agent任务我们设了5万token的硬上限超过直接中断并向用户返回任务过于复杂请拆分后再试。这个上限值不是拍脑袋定的是统计了历史任务分布的95分位数又留了安全余量。有了这层护栏至少不会再出现一个死循环agent把当天预算烧穿的情况。3. 更强模型模型能力升级后的工程侧适配3.1 模型灰度升级与降级链路设计模型变强了但你不能像换手机壳一样换模型尤其是线上业务。这周我们把一个新模型灰度到生产环境前期只放了5%的流量跑了三天观察错误率和耗时。灰度期间果然发现了一个之前测试没暴露的问题新模型对某些中文长尾表达的响应速度和旧模型差异很大平均延迟高了一倍多。模型的升级必须配套降级链路。我们的设计是三层第一优先用旗舰模型处理复杂任务第二优先用经济型模型处理常规任务第三层用本地轻量模型兜底关键路径。每一层都设置超时和失败计数连续失败自动切到下一层。网关层做路由决策把请求按规则分发到对应模型并且实时感知每个模型后端的健康状态。这样就算某个模型服务本身出问题用户的请求也不会整体挂掉只是体验降一级。3.2 从提示词工程走向上下文工程模型越强传统意义上的提示词工程边际收益在递减。以前你要精心设计措辞、构造few-shot示例、研究各种prompt技巧才能让模型输出稳定现在模型本身理解能力上去了你更需要思考的反而是给它看什么数据。我把这理解成从提示词工程向上下文工程的演进提示词工程解决的是怎么问上下文工程解决的是让它看到什么以及按什么顺序让它看。具体到工程实现上上下文工程的核心操作包括检索召回、相关度重排、文本截断、摘要压缩、以及关键信息的结构化抽取。这些环节共同决定了进入模型的上下文质量。同样的模型和同样的提示词给不同质量的上下文输出效果可以差出几个档次。这块工作目前没有统一的开箱即用方案不同场景要自己调但大方向是一致的上下文越精炼、越贴合当前问题模型的表现越好token消耗越少。3.3 检索质量embedding选型与分块策略做上下文工程绕不开检索做检索绕不开embedding模型选型。这周正好有同事在对比几个主流的embedding模型市场上排行靠前的那些模型质量差距确实存在尤其在中文长尾语义和中英文混合场景下选错模型会让召回质量明显缩水。我们内部做了一个小评测集对比模型的top10召回命中率最后选的方案在命中率上比备选方案高出近8个百分点这个差距放在生产环境就是质的差别。分块策略同样影响检索效果。固定按字数切分比如512字一块实现简单但会把逻辑完整的段落硬生生切断导致embedding表示失真。我们改成按语义切分先按段落边界拆段落太长的再按标题、列表、句号等语义边界细分。这样每一块都是一个相对完整的语义单元召回的内容更准。这块没有通用的最优参数必须拿自己业务的数据反复试。3.4 评测回归集换模型的守门员模型升级最大的隐形风险是回归。说句实在话大部分线上问题不是模型本身不行而是升级之后行为变了下游解析、业务逻辑没跟上。为了避免这个坑我们这次在使用新模型之前硬是挤时间建立了一个业务相关的评测回归集。回归集不需要很大三四百条精选case就够用了。每条case包含输入、期望输出、关键判定点。比如抽取类任务我们会标好期望的JSON字段和取值分类任务标好期望的类别问答任务标好期望包含哪些关键信息。每次换模型、改prompt、调上下文策略都拿这批case跑一遍算准确率和格式合法率。跑完对比基线任何关键指标下降超过两个百分点就不允许上线。这套东西虽然简陋但已经连续拦住了两次看起来新模型更强、实际某类case更差的坑。4. 更难管的agent从demo到生产的治理经验4.1 agent进生产的三道坎demo阶段的agent和能上生产的agent是两个物种。demo阶段跑通一条理想路径就行生产环境要面对的是无穷无尽的意外输入。我这周总结了agent转产必须跨过的三道坎。第一道坎是多轮循环的稳定性。agent基本都有计划-执行-反思的循环结构一个任务少则三五轮多则几十轮。每一轮都可能产生新状态、引入新错误循环越长越容易偏离主线。我们处理的办法是给每个agent类型设置最大轮数上限比如默认10轮超了就停止并返回当前进度让用户决定是否继续。同时定义好任务完成的判定条件一旦满足就强制退出循环不要等模型自己判断我觉得结束了。第二道坎是状态管理。普通接口是无状态的agent不是。它跑一个任务可能要几分钟甚至更长时间中间挂了怎么办进度存哪我们用一个独立的状态存储服务来记录每个agent实例的阶段、已完成的工具调用、已收集的数据。这样就算进程重启agent还能从断点恢复而不是从头再来。第三道坎是工具调用的可靠性。agent的能力上限取决于它手上有哪些工具但工具越多出错面越大。可能工具本身返回的数据格式变化了、接口超时了、权限过期了每一样都会打断agent的执行流程。我们的做法是给每个工具封装统一的出错返回结构agent调用工具失败时能拿到标准化的错误信息再由决策层决定是重试、换方案还是终止任务。4.2 并发控制agent怎么扛住流量AI agent怎么扛并发是我们内部群里这周讨论最多的问题之一。很多人的直觉是用线程池并发跑agent就完事了实际完全不是这么回事。一次普通的LLM调用是毫秒到秒级的一个agent任务却是几十次LLM调用的串联跑一次要几十秒甚至几分钟。这意味着单个agent任务对后端API的请求压力会被放大十到二十倍。我们做过一个粗略测算一个agent任务平均做12次LLM调用每次调用500毫秒串行执行就是6秒。如果同时启动50个这样的agent瞬时对上游API的并发请求量就是50乘以12等于600次调用挤在一个时间窗口里远超很多API服务的配额。所以并发控制不能只按请求数限流得按token消耗速率限流。我们同时在线程池、信号量、网关限流三层做了控制线程池限制同时运行的agent实例数信号量控制每个agent内部并发调用大模型的最大数网关层按每分钟token配额做整体限流。队列也很重要。当并发达到上限新任务不是直接拒绝而是进入有界队列等待。队列满了才拒绝避免雪崩。我们还给每个agent任务加了优先级简单任务优先跑复杂的、耗时长的任务往后排这样用户的即时提问不会因为后台批量任务占满了资源而卡住。4.3 可观测性给每个agent一套追踪体系排查agent问题最怕的是什么是不知道它内部发生了什么。普通接口出问题看一眼错误栈基本就知道原因agent出问题你面对的是一长串工具调用记录和模型决策历史没有合适的追踪手段就只能抓瞎。我们这周给所有agent接了链路追踪。每个agent实例分配一个trace_id从任务开始到结束每一步都埋点记录当前执行到哪个状态、调用了哪个工具、传入参数是什么、返回结果是什么、每次LLM调用的输入输出token数和耗时。排查问题的时候直接按trace_id把整条执行链拉出来一眼就能看到它是在哪一步走偏的。状态机是另一个好工具。我们把agent的执行过程抽象成有限个状态初始化、计划中、取数中、决策中、执行工具、异常处理、完成、终止。日志里每一行都带当前状态字段出了问题可以快速定位到卡在取数中还是反复在异常处理里打转。这套体系建成之后排查问题的平均时间从小时级降到了分钟级这是这周投入产出比最高的一件事。4.4 权限收敛与工具白名单agent的能力来自工具但工具权限给大了就是灾难。我们内部有一条铁律给agent开一个工具之前必须回答它真的需要这个权限吗。比如一个做售后分析的agent它只需要读订单表和售后记录那就只给它只读权限绝不给写库的权限。更不需要给它一个能执行任意SQL的工具那等于把数据库钥匙挂在门把手上。具体的做法是建立工具白名单每个agent类型都有各自的允许调用集合不在名单里的工具直接拒掉。白名单做成动态配置运营人员可以在管理后台调整不用发版。高危工具单独加一层强管控所谓高危就是一旦出错会造成实质影响的比如批量发消息、改数据、触发业务流程等。这类工具在agent调用时不是直接执行而是生成一个待审批的请求推到人工审批队列里由运营人员确认后才真正执行。4.5 人工审批与熔断兜底为什么一定要保留人工审批环节因为再强的模型也有胡说八道的时候。我们的经验是agent在低风险、高频、规则明确的场景里能替代人做得很稳但在高影响、不可逆的动作上必须保留人的判断。审批环节多花十几秒换来的是出大事概率的大幅下降这笔账非常划算。兜底机制也不能少。我们给每个agent配了熔断器连续失败N次我们设置的是连续5次就自动熔断不再接收新任务同时触发告警。事后人工检查原因确认修复后才能手动恢复。新上线的agent还会先跑一段时间的影子模式或监督模式影子模式下agent照常执行但结果不直接落地只记录它的决策质量监督模式则是关键动作都要人工过一遍。这套机制让我们能在控制和效率之间找到一个还算舒服的平衡点。5. 常见问题与排查技巧实录5.1 token用量暴涨的四种典型场景这周处理了几次token用量异常告警规律性很强整理了四种典型场景现象可能原因排查方法解决动作单请求token突增业务数据被全量塞进上下文查单请求的token分布看哪个字段最大改成检索召回截断控制最大上下文长度单任务token总量爆炸agent死循环反复调用模型看trace里的调用次数和轮数设置最大轮数和单任务token硬上限日均token缓慢爬升对话历史越积越长分析会话平均轮数和历史token占比做历史压缩超过N轮启递归摘要某模型后端token占比异常流量路由被集中到高价模型按模型维度拆分成本报表调整路由比例加经济模型的优先级重点是第一类和第二类。第一类是最常见的prompt里塞了长文本问题第二类是最危险的agent死循环问题都需要靠监控数据及时发现不能等账单出来才后悔。5.2 agent执行中断的排查SOP这周我们遇到过agent execution terminated due to error这类模糊报错跟同事梳理了一个排查SOP现在Team内基本按这个流程走第一步拿到trace_id拉出完整的执行时间线先看中断发生前最后成功的一步是什么。第二步定位是哪个工具调用出了问题是超时、是返回格式不对、还是权限校验失败。第三步看模型当时的决策上下文它是在什么信息基础上决定调用这个工具的判断是数据问题还是模型误判。第四步如果是超时看工具本身的响应是不是毛刺要不要加超时重试如果是权限问题检查token是否过期、角色是否变更如果是模型误判就要考虑在prompt里加约束或者把关键决策改成规则判断。这个SOP跑下来大部分agent中断问题都能在十分钟内定位到根因。最反直觉的一点是很多看起来像模型抽风的问题根因其实是工具返回的数据格式出现了细微变化模型只是被脏数据误导了。所以排查的时候别急着怪模型先查数据链路。5.3 鉴权token过期与续签设计这周还遇到一类问题agent在长时间任务执行中调用内部服务和外部API时出现鉴权失败。常见报错就是token交换失败、refresh_token为空之类的。原因很典型——agent任务可能跑几分钟甚至更久而访问token的有效期可能只有几十分钟任务执行过程中token悄悄过期了后续的工具调用全部失败。我们的经验是多步任务场景不能沿用普通接口的每个请求都带token模式应该在任务开始时获取一次长期凭证并在任务内部做好自动续期的逻辑。设计上一般是短token加长refresh token组合短期凭证负责具体请求refresh token负责在短期凭证过期前主动换新。续签动作放在任务的状态机里在执行工具调用之前先检查当前凭证的有效期剩余时间不足阈值就提前刷新而不是等请求报401了才补救。另外refresh token最好不要在每次请求里都带着刷新只在确定过期时刷新一次减少不必要的网络交互和出错面。5.4 模型输出不稳定与JSON解析失败结构化输出解决了token浪费的问题但引入了另一个问题模型偶尔会返回格式非法的JSON比如多了个逗号、字段名被改了、或者整个输出被一段解释性文字包裹。这类问题在我们的生产环境中占所有异常的比例不低。处理思路是三层防御。第一层是输出约束能用tool calling或schema约束的尽量用让模型在结构框架内生成。第二层是宽容解析用容错性强的JSON解析器能处理尾逗号、引号转义不严格等小毛病解析失败时可以进行一次简单的修复比如截取第一个左花括号到最后一个右花括号之间的内容再解析。第三层是业务兜底schema校验失败就重试一次重试还失败就返回默认值或转人工处理。实测下来这套组合拳能把JSON解析失败率降到可接受的范围但这块不可能完全消灭必须接受偶尔需要一个兜底的现实。结尾的几句实在话这周最深的体会是AI工程的重心正在从能不能做出来转向能不能稳住。更少token、更强模型、更难管的agent这三件事其实是同一个信号——AI应用开始进入精细化运营阶段了。省token不只是省钱省下的成本可以换成更强的模型、更多的场景覆盖管好agent不只是防故障防住的是不可控对用户信任的消耗。最后分享一个小技巧每周固定花半小时看一次token用量报表和agent失败日志这件事性价比极高。很多严重问题在报表里提前一两天就有征兆比如某个agent的token消耗连续几天缓慢上升、某个工具的错误率悄悄抬升。你不需要每次都做大的治理但保持对数据曲线的敏感能让你在问题发酵之前就动手。这比等到线上出事故再救火要省太多力气。