别什么都上最贵模型。真正能上线的 Agent，必须知道什么时候省、什么时候花、什么时候降级。

1. 为什么需要资源感知优化

Agent 做得越复杂，越容易遇到三个现实问题：慢、贵、不稳定。

一次简单问答，如果也调用最强模型、塞满长上下文、再调一堆工具，效果未必更好，但成本和延迟一定更高。

资源感知优化解决的不是“省钱”一个问题。它解决的是：在预算、延迟、质量和稳定性之间，做一个可控选择。

2. 它到底是什么

资源感知优化，就是让 Agent 在运行时动态决定：用哪个模型、给多少上下文、调用哪些工具、最多跑几轮、失败后怎么回退。

它不是简单的模型降级。它是一套执行策略。

• 简单问题：走小模型、缓存、模板，快速返回。

• 复杂问题：走强模型、RAG、工具、反思，保证质量。

• 高频问题：优先复用缓存，减少重复模型调用。

• 服务拥堵：降级到备用模型，或返回简版答案。

• 高风险任务：不盲目执行，进入审批或人工确认。

3. 核心流程

资源感知优化一般分 6 步：先识别任务，再分配资源，再观察结果。

关键点是：路由器不能只看用户问题，还要看预算、延迟、上下文长度、工具成本和风险等级。

4. 6 个工程抓手

最常见的错误，是只做“模型切换”。这远远不够。

真正有效的做法，是把资源控制放进完整链路。

4.1 动态模型路由

先判断任务复杂度。简单问题用便宜模型，复杂推理再上强模型。

4.2 上下文压缩

上下文不是越多越好。无关历史、重复文档、低质量检索结果，都会消耗 token。

4.3 工具成本控制

工具调用也有成本。搜索、数据库、第三方 API、代码执行，都要设置次数、超时和预算。

4.4 缓存复用

高频问题、检索结果、中间摘要，都可以缓存。能不调用模型，就不调用模型。

4.5 限额与熔断

限制最大轮次、最大 token、最大工具次数。否则 Agent 一旦进入循环，成本会快速失控。

4.6 降级与回退

主模型不可用、工具超时、预算用完时，要能切换备用路径。用户拿到简版答案，也比直接报错好。

5. 案例：内部知识库问答 Agent

假设公司内部有一个知识库问答 Agent，员工会问制度、流程、权限、故障排查。

如果所有问题都用强模型 + 长上下文 + 多轮 RAG，成本很快上去。更合理的做法是分流。

这个案例里，Agent 不再是“看到问题就回答”。它先判断问题类型，再选择资源路径。

• 报销入口、系统地址这类固定问题，优先走缓存或小模型。

• 制度解释类问题，走 RAG 检索，再用中等模型总结。

• 跨制度对比、冲突判断，才使用强模型和反思。

• 涉及薪资、权限、法务等高风险问题，不直接给结论，转人工或提示边界。

6. 运行逻辑怎么落地

资源感知优化必须工程化，不能靠人工拍脑袋。

至少要有一个资源路由器，一个预算管理器，一个模型池，一个缓存层，一套 Trace 指标。

这里的关键不是代码多复杂，而是把规则写清楚。

• 每次请求都记录模型、token、耗时、工具调用次数。

• 每类任务都设置默认模型和备用模型。

• 每个工具都设置超时、重试、预算上限。

• 每条链路都能看到成本和质量指标。

• 路由策略要根据线上数据持续调整。

7. 常见坑

坑一：只按问题长度路由

短问题也可能很难。比如“这次故障谁负责？”字少，但风险很高。路由要看复杂度、风险、时效和工具需求。

坑二：一味压成本

成本低不代表系统好。客服错答、代码误改、审批误判，后续损失可能更大。资源感知优化追求的是性价比，不是最低价。

坑三：没有监控

没有 token、延迟、失败率、满意度指标，就无法知道路由是否有效。

坑四：没有降级方案

模型限流、工具超时、预算用完，都很常见。没有回退路径，系统就会直接不可用。

8. 上线检查清单

9. 总结

资源感知优化，是 Agent 从 Demo 走向生产的关键能力。

Demo 可以只追求效果。生产系统必须同时看质量、成本、延迟和稳定性。

一句话：小问题别烧大模型，大问题别省关键资源，高风险问题别让 Agent 独自决定。