1. 为什么智能体需要资源感知一次真实的生产事故先从一个让我印象深刻的线上事故说起。去年年中我给一个知识库问答智能体做了升级给它接入了网页检索、代码执行、数据库查询三路工具。Demo演示阶段一切正常模型回答流畅、工具调用准确当时只觉得这智能体真聪明。结果上线一周后用户开始抱怨回答越来越慢经常转圈再往后直接出现抱歉服务不可用。查了监控才发现问题根本不在模型本身而在资源层面每天的token消耗量是预估的三倍多轮对话上下文越滚越大单次请求平均要处理两万多个token响应延迟从800毫秒飙升到6秒以上。更麻烦的是三方工具接口的配额被频繁打满数据库连接池被智能体拿来回重试差点拖垮了核心业务库。那段时间我很狼狈后来痛定思痛把所有跟智能体相关的代码重新做了资源治理才慢慢稳定下来。这让我形成了一个判断智能体设计和传统API服务设计有一个本质区别——智能体的执行路径是动态的token消耗、上下文长度、工具调用次数、外部接口延迟都是运行期变量。没有资源感知能力你根本不知道它下一步会撞上哪堵墙。所谓资源感知不只是监控一下CPU和内存它的核心是让智能体本身知道自己有多少资源、消耗在哪里、什么时候该收敛。具体拆开至少包括三层执行资源时间预算、重试次数、最大步数、上下文窗口上限外部资源API配额、第三方接口限流、数据源连接数、知识库检索条数隐性成本token费用、用户等待耐心、错误恢复的连锁代价这篇文章我会把资源感知优化、推理技术选择、评估与监控体系这三块放在一起讲因为它们本来就是一套东西资源感知让智能体学会省着用推理技术决定它想得对不对评估监控则是整条链路的质检员。没有后两块光省资源没有意义省下来的成本可能都花在错误回答的弥补上。2. 资源感知的策略设计从能跑到知道花多少钱在跑2.1 Token预算管理不要等爆了才想起限额传统服务做限流是在网关层配一个QPS阈值超过就拒绝。智能体的逻辑不太一样它有多步决策特性——一次用户请求可能要经过理解意图-调用工具-观察结果-再推理多个循环每一步都在消耗token而且每步的消耗量完全不同。我做token预算时踩过一次坑。最初给单次对话设了一个5000 token的硬上限超过直接截断。结果智能体在第三轮工具调用后突然回答到一半断掉了用户拿到的是一段残废文本。后来我把硬截断改成了分级预算效果立刻不一样了阶段预算比例说明首次响应30%保证用户能在合理时间内看到初步回应工具调用循环50%多步推理的核心消耗区预留弹性空间最终汇总回答20%收尾阶段避免前面用完了最后没字写执行时每轮迭代都检查剩余预算低于20%就触发收敛模式不再扩展搜索范围不再重试工具直接用已有信息组织回答。这个机制上线后超时率直接降了六成而且我发现一个反直觉的现象——用户对你还有80%的预算没用完毫无感知但对回答了一半被切断的抱怨极其强烈。所以预算管理的目标不是省到极致而是保证每个请求都有体面的闭环。实现层面我建议在每个循环的开始检查一个通用上下文对象里面记录累计token消耗、剩余预算、已执行步数。不管是基于大模型API的stream方式还是一次性返回方式都要在进入下一步决策之前做判断。只要预算不足立即把智能体状态切换成节省模式这个模式下的prompt模板和工具选择策略都不一样。2.2 上下文窗口的取舍什么该留什么该扔第二个大坑是闲聊式上下文累积。很多智能体框架默认把整个对话历史全部塞进prompt一开始还好聊了二十轮之后每一轮请求都带着两万字的历史记录。token消耗翻倍是小事关键是模型注意力被大量无关历史稀释反而忘了当前问题的焦点。我的做法是给上下文分三级管理必须保留系统设定、当前用户请求、最近两轮对话压缩保留早期对话按主题做摘要用五十字概括原本一千字的讨论过程直接丢弃工具调用明细、检索返回的原始文本块这些对后续回答没有增量价值具体实操时我写了一个上下文管理模块每轮结束时自动执行压缩评估。如果对话轮次超过四轮就把前三轮的历史交给模型生成一段摘要然后替换掉原文。实测下来长会话的token消耗能省35%到45%而且回答质量没有明显下降。有一个注意点摘要生成本身要花一次模型调用如果单轮对话很短摘要成本可能反倒不划算所以阈值判断很关键。另外工具调用结果的原始文本不能直接塞回上下文。比如一次网页检索返回了五段长文本真正有用的可能就两句话。我在工具层做了一个精炼回填机制让模型只提取关键信息片段结构化后再返回给主循环。这一步相当于给上下文做了前置净化大大缓解了信息冗余。2.3 外部接口的资源保护限流、熔断与降级智能体的工具调用天然比传统API多一层不确定性你以为只调一次搜索实际它可能因为不满意结果连续调了三次你以为数据库查询只需要一条SQL实际它会先生成一条失败后换条件再生成一条。这种情况下如果不在中间加保护层外部的限流迟早会触发而限流对于智能体来说是一种最差体验——它在思考中途被切断既拿不到数据也没有替代方案。我后来给所有工具调用统一加了三道保险单步超时每个工具调用强制设置超时时间比如搜索三秒、SQL查询五秒超时立即返回一个超时结果让智能体自己决定是换工具还是换query熔断开关连续同一个工具报错三次以上该工具进入熔断状态直接告知模型暂时不可用引导它绕行到备用工具降级清单给高成本工具配一个低成本替代。比如网页全文检索不可用时降级到标题检索代码执行引擎不可用时降级到静态规则匹配这一步的收益不是量化的性能指标而是稳定性。接入降级机制之后我再也没收到过智能体把第三方服务拖死的投诉。说白了智能体再聪明也不能让它有无限开火权资源保护层的存在就是为了防止一次失控调用引发雪崩。3. 推理技术的分层设计与收敛控制3.1 从一步到位到层层递进规划器执行器架构智能体的推理方式业界主流的说法是分两种一种是端到端的单次推理模型一次性根据用户问题直接调用工具另一种是规划-执行分离模型先生成行动计划再逐步执行。实际业务里单次推理虽然快但面对复杂任务很容易一步错步步错尤其用户问题里带着模糊条件时模型经常急着调工具方向却跑偏了。我现在的设计方案是三层推理结构L1 意图解析轻量模型只做意图识别和任务拆分目的是确认用户到底想干什么L2 规划生成满血模型根据意图生成完整行动计划每一步标注依赖的工具和预期产出L3 执行与修正循环执行计划步骤遇到异常时重新调整剩余步骤之所以把意图解析拆到轻量模型是因为这类任务的推理负担不大用参数量较小的模型足够应付。而规划生成是真正烧脑的部分必须让最强的模型来完成。执行与修正则更像一个反馈闭环既执行又观察边做边调整。这套分层方案最大的好处是可控性强。单次推理就像一口气跑完马拉松中途抽筋就全毁了规划器执行器则是先看地图再跑每个补给点都能重新确认路线。实测复杂任务的成功率从61%提升到78%代价是token消耗增加了30%——这笔账我觉得非常划算毕竟成功率每提升一个点售后和重试成本都能省回来。3.2 思维压缩让模型思考更短但更深大模型有个很神奇的特点你让它一步步思考它确实会思考得更好但如果你不限制思考篇幅它能给你绕出花来。生成一堆自我纠正、反复确认的内心戏既浪费token又拖慢响应。这就是思维压缩要解决的问题。我的做法是在prompt里明确加了一条请按结论先行、理由精炼、每步推理不超过20字的方式作答。效果立竿见影。同样的逻辑正确率基本没降但推理时间缩短了40%。当然这种方法需要分场景来处理——如果任务本身是数学证明或复杂推理题该让它展开还是得展开思维压缩只适合业务型问答和工具调用场景。还有一个更高效的技巧我称之为缓存思维。同类型的问题频繁出现时把上一次的规划结果缓存下来下次遇到相似意图直接复用模板只替换关键参数。比如帮我查一下某个店铺的营业时间和帮我查一下另一个店铺的营业时间本质上规划路径完全一样没必要重新推理一遍。缓存命中率高了之后平均响应时间从4秒降到了1.8秒。3.3 模型降级策略什么时候该用省电模式不是所有请求都需要满血大模型来处理。我按任务难度给智能体设置了三条推理通道通道适用场景模型选择极速通道天气、时间、简单知识问答小参数模型单次生成标准通道多步工具调用、中等复杂度查询标准模型允许少量推理深度通道复杂分析、多源信息综合、长文档理解满血模型完整规划模型降级的核心在于预判。我通过意图解析阶段给请求打一个复杂度标签然后路由到不同通道。这个标签的生成不需要太复杂让轻量模型基于文本长度、指令动词、是否含多个约束条件做一个粗分类准确率可以做到85%以上。剩下的15%误判怎么办加一个兜底机制标准通道执行中发现任务超纲自动升级到深度通道代价只是多一次模型调用。这套策略上线后我算了一笔账70%的请求走极速或标准通道整体模型成本下降了52%而用户满意度反而小幅上升因为大部分简单问题得到了更快的响应。这里有一个关键心得降级不等于降低质量而是把合适的问题分配给合适的模型。用户问现在几点钟你花五秒等一个满血模型回复和在零点五秒内由小模型回复体验差距是巨大的智力投入也是浪费的。3.4 收敛控制别让智能体在一个问题上较劲智能体最常见的失控行为是重复尝试。工具超时了再试一次。又超时了换个参数再试。还是不行换个关键词继续搜……如果没有硬性的步数上限它可能在一个死胡同里转十几次把预算烧光。我给智能体写入了一个三次法则同一个操作最多重试三次。三次都不成功立即标记为此路不通执行计划切换。同时设置全局最大步数限制比如单次对话最多八步工具调用超过八步就结束循环直接基于已有信息回答。这两个约束看起来简单实则是防止智能体钻牛角尖的关键。另一个收敛策略是置信度跳转。当模型对某个中间结果的置信度超过95%时允许它跳过剩余规划步骤直接进入回答阶段。这个策略一开始我不敢用担心跳步会导致信息遗漏。后来做了一个折中只有目标是查询类任务时才启用跳转因为查询类任务的核心是找到答案过程花哨反而影响效率。综合分析类任务坚决不跳你得先收集足够多的事实才能做判断。4. 评估与监控给智能体装上仪表盘和体检报告4.1 离线评测集先替用户把可能踩的坑踩一遍评估智能体比评估传统算法要复杂得多因为它的输出是过程性的不仅要看答案对不对还要看决策过程合不合理。你没法用一个简单的准确率指标来衡量。我搭了一套离线评测集包含一百二十个典型场景每个场景都标注了标准动作序列和标准答案特征。评测集里的用例不是随便编的我把线上三个月的真实用户日志翻出来聚类找出了高频请求类型和最容易出错的任务类型。比如多条件筛选信息矛盾处理工具返回空结果这三类问题单独各设计了二十个变体用例。评测时我自己搭了一个简单的打分框架从三个维度评判任务完成度最终回答是否满足用户需求按0到100打分路径合理性工具调用序列是否最优有没有多余动作或无效重试资源消耗实际token数与调用步数是否在预算范围内每周固定跑一次回归评测效果变化用一张趋势图来跟踪。有一次升级了规划器的prompt评测分数掉了七个点回看数据发现是新增的指令让模型变得过度谨慎老是不敢直接调工具绕来绕去。如果没有这套离线评测这种隐性劣化可能上线几天才会被用户发现。4.2 在线监控指标延迟、成本、成功率一个都不能少离线评测管的是升级前在线监控管的是升级后和日常运行。我总结了自己一直在盯的五个指标做成一个综合看板端到端响应时间用户从发消息到收到回复的总时长P50和P95都展示。P95如果超过8秒基本意味着体验已经很差了单次请求平均token消耗这个指标失真信号很强大多数问题其实只需要四五千token就够一旦超过八千大概率是推理路径跑偏了工具调用成功率按工具维度拆分哪个工具最容易失败、失败原因是什么一目了然熔断触发次数如果某个工具频繁触发熔断说明它稳定性有问题或者是prompt让它用错了场景上下文压缩率长会话场景下压缩机制是否真的在起作用原始上下文和压缩后上下文的体积比每类指标都配上告警阈值。比如P95响应时间连续五分钟超过6秒就触发微信告警token消耗异常率超过15%就进入人工排查流程。这套监控体系的最大价值不是发现问题而是把模糊的用户说慢了转化为清晰的哪个环节慢了、慢了多少、是谁导致的。4.3 全链路日志没有日志的智能体就是一团黑箱智能体的排错难度比传统系统高很多因为同一个错误可能来自prompt设计、模型选择、工具返回、参数传递任何一个环节。没有全链路日志排查一个为什么答错了的问题可能得花半天。我给每条请求都生成一个独立的trace_id从用户输入开始把每一轮模型调用、每一次工具调用、每一步token消耗、每一次预算检查的全过程都串起来记录。日志里不仅记录入参出参还记录为什么做这个决策——也就是当前上下文的关键状态。有一次用户反馈同一个问题第一次回答对第二次回答错我靠trace日志对比两条请求发现差异居然在上下文压缩环节第一次请求还是完整历史第二次请求的历史已经被摘要替换了而摘要漏掉了一个关键限定条件。如果没有日志这种间歇性的问题几乎无法排查。所以我说监控指标只是告诉你出事了全链路日志才是告诉你为什么出事的工具。4.4 日常运行的反馈闭环最后想聊聊评估与监控如何反哺设计。我建了一条简单的反馈闭环每周把监控数据里暴露的问题汇总成一张高频错误清单然后逐一回看对应的trace日志找出共因。共因通常集中在几个方面——工具返回格式不匹配、意图识别歧义、上下文压缩丢失关键信息。拿工具返回格式不匹配来说这是一种非常典型的集成问题模型规划要调用搜索然后搜到的结果是一段HTML文本模型没法直接解析只能强行在其中找关键词。我在工具层加了一个统一格式化函数让所有外部返回的文本先经过清洗、截断、结构化再交给模型。光这一个改动就把工具调用失败率从9%降到4%。闭环的意义在于评估不光是验收监控不光是报警它们共同构成了智能体的自我进化数据源。你每一次发现问题和修复问题实际上都是在给系统的行为模式做一次校准。做得越久系统的决策风格越收敛、越符合业务预期。5. 一个可以照抄的设计蓝图前面讲了资源感知、推理技术、评估监控三个层面的方法论最后我把它们合并成一份落地方案你可以直接照这个清单来搭建自己的智能体系统。资源感知层给每次请求分配token预算按首次响应30% / 工具调用50% / 汇总回答20%分级管理上下文设三级管理必须保留、压缩保留、直接丢弃长对话自动触发摘要替换工具层统一加超时、熔断、降级三道保险推理控制层意图解析用轻量模型规划生成用满血模型执行修正走循环闭环按任务难度路由到极速、标准、深度三条推理通道同一操作最多重试三次全局最大步数八步高置信度查询类任务允许跳步评估监控层维护一个覆盖高频场景的离线评测集每周跑回归看板盯五个核心指标响应时间、token消耗、工具成功率、熔断次数、压缩率每条请求全链路trace日志记录决策上下文支持事后退因分析我自己实际部署这套方案的感觉是前期搭建确实要多花一些时间特别是日志埋点和评测集建设枯燥且琐碎。但一旦跑起来后续迭代速度会越来越快。以前每次升级prompt都战战兢兢怕出错现在先跑评测集再灰度上线出问题看日志就能定位整个团队的信心完全不一样了。最后再分享一个小技巧资源感知里的预算策略别追求完美。预算定得太细管理开销会超过收益定得太粗又拦不住异常消耗。我现在的配比是在线上跑了两个月、踩了多次坑之后调出来的你完全可以先照这个版本上线再根据自己业务的真实流量特征慢慢修正。智能体的优化永远没有终点但有了资源感知、推理控制、评估监控这三块基石至少每一次改动都在往更稳的方向走。