资源感知优化：让 Agent 不只会干活，还会算账

资源感知优化，简单说就是：让 AI Agent 在完成任务时，知道每一步都要花钱、花时间、占资源，所以会主动选择更合适、更便宜、更稳定的做法。

以前我们评价一个 Agent，常问：

它能不能完成任务？
回答准不准？
会不会调用工具？
能不能多轮推理？

但到了真正上线时，还必须再问几个更现实的问题：

这次调用花了多少 token？
有没有重复算？
有没有必要继续推理？
这个任务值不值得用最贵的模型？
输出是不是太长？

一个不懂资源感知的 Agent，就像一个拿着公司信用卡、不会看价格的实习生：它可能很努力，但每一步都在烧钱。

资源感知优化的核心不是简单“省钱”，而是让 Agent 在质量、成本、速度之间做更聪明的选择。

一、Agent 也需要“钱包意识”

可以把 Agent 系统想象成一家餐厅。

餐厅里有厨师、食材、厨房、电费、服务员和顾客等待时间。对应到 Agent 系统里就是：

如果餐厅完全不算账，就会出现很多问题：

让顶级大厨做最简单的炒饭；
每道菜都重新备料；
同样的汤底每次都重新熬；
客人点个小菜，厨房却上了一桌满汉全席；
厨师一直研究菜谱，迟迟不上菜。

Agent 也一样。

它可能用最贵的模型回答简单问题；每轮对话都把完整历史重新发给模型；为了一个低价值任务反复思考十几轮；或者输出一大段并不需要的解释。

所以资源感知优化要解决的不是一个点，而是一整套问题：

该不该调用模型？
该用哪个模型？
该不该复用历史结果？
提示词能不能压缩？
推理要不要设上限？
输出能不能更短、更结构化？
成本和延迟能不能实时观测？

这就是资源感知优化的真正含义：让 Agent 像一个会经营的人一样做事，而不是像一个没有预算上限的自动化脚本。

二、为什么 Agent 比普通聊天机器人更容易烧钱

普通聊天机器人通常是：

用户提问 → 模型回答

一次请求，大概就是一次模型调用。

但 Agent 往往会经历一整套流程：

理解任务 → 制定计划 → 选择工具 → 调用工具 → 读取结果 → 反思检查 → 继续执行 → 生成最终答案

比如用户说：

帮我分析一下最近 30 天客服工单，找出主要投诉原因，并生成一份改进建议。

一个 Agent 可能要判断任务类型、查询工单数据库、抽样阅读工单、聚类投诉原因、生成初稿、自我检查，再补充分析。问题是：每一步都可能花 token、花时间、花钱。

更麻烦的是，多轮对话和反思机制会带来“滚雪球式成本”。如果每一轮都把完整历史上下文发给模型，输入成本会随着对话变长不断膨胀；如果再叠加工具调用、多 Agent 协作、Critic 检查，账单增长会非常快。

所以，资源感知优化不是上线后的“运维小修小补”，而是 Agent 架构设计时就必须考虑的核心能力。

三、资源感知优化到底在做什么

资源感知优化可以拆成四个关键动作：

1. 少算：能不调用模型就不调用；
2. 少传：能少传 token 就少传；
3. 用对模型：简单任务别用最贵模型；
4. 设上限：别让 Agent 无限思考、无限输出。

整体流程可以这样理解：

背后的原则很简单：

重复的问题，不要重复算；
简单的问题，不要用复杂模型；
长上下文，不要原样塞给模型；
长推理，不要无限循环；
长输出，不要任由模型发挥；
所有成本，都要可观测、可归因、可控制。

四、六层成本节流栈

资源感知优化不是一个技巧，而是一套分层体系。最实用的方式，是把它理解成“六层成本节流栈”。

1. 语义缓存：问过的不再问

普通缓存要求用户输入完全一样才命中。语义缓存会判断“今天上海天气怎么样”和“上海现在天气如何”意思接近，从而复用结果。

它一般会这样做：

1. 把用户问题转成向量；
2. 到向量库里找相似问题；
3. 相似度超过阈值，直接返回历史答案；
4. 没命中，再调用模型；
5. 新结果写入缓存。

适合缓存 FAQ、政策解释、产品说明、常见故障排查。不适合随便缓存实时价格、天气、股票、库存、用户个人订单和高风险决策结果。

两个参数最关键：相似度阈值和 TTL。阈值太高命中率低，太低容易误命中；静态知识 TTL 可以长，动态信息必须短。

2. 前缀缓存：把不变的提示词放前面

很多 Agent 的提示词都由系统身份、安全规则、工具说明、输出格式、历史摘要和本轮问题组成。前面几部分经常不变，真正变化的只有“本轮用户问题”。

错误结构是：

用户问题：{每次都变}
 
你是一个企业客服助手。
你需要遵守以下规则……
你可以使用以下工具……
你的输出格式是……

更好的结构是：

你是一个企业客服助手。
 
固定规则：
1. 不编造政策；
2. 不泄露用户隐私；
3. 无法确认时转人工。
 
可用工具：
1. query_order：查询订单；
2. query_refund：查询退款；
3. search_policy：查询政策。
 
输出格式：
{
  "answer": "...",
  "need_human": true 或 false,
  "reason": "..."
}
 
用户问题：
{本轮用户输入}

简单原则：稳定内容放前面，变化内容放后面；越稳定，越靠前。

3. 提示压缩：把长上下文里的“水分”挤掉

Agent 经常要处理长文档、多轮历史、RAG 检索结果、工具返回数据和多个 Agent 的中间结果。如果全部原样塞进模型，成本高，效果也未必更好。

提示压缩要做的是：保留关键信息，删除低价值内容。

比如一段客服历史原文很长：

用户先问订单多久发货，又补充说自己下周出差，希望尽快收到。
客服查询后发现订单已付款但还没出库，仓库预计明天发货。
用户又问如果来不及能不能改地址到公司。

可以压缩成：

{
  "user_goal": "希望尽快收到订单，必要时改地址",
  "order_status": "已付款，未出库",
  "warehouse_eta": "预计明天发货",
  "open_question": "是否支持改地址到公司"
}

这比原始文本更短，也更利于模型处理。

4. 模型路由：别让顶级大厨做煎蛋

不是所有任务都需要最强模型。简单任务可以用小模型、规则或分类器；复杂任务再交给强模型。

常见做法有两种：一次性路由，先判断复杂度再直接选模型；级联路由，先让便宜模型尝试，置信度不足再升级。级联路由更稳，因为它保留了升级通道。

适合路由的判断信号包括：用户问题长度、是否需要计算、是否需要多步推理、是否需要查工具、是否涉及高风险业务、小模型输出置信度、输出是否通过校验。

5. 思考预算：别让 Agent 思考到天荒地老

Agent 最容易失控的地方，是它可以不断循环：

想一想 → 调工具 → 看结果 → 反思 → 再调工具 → 再反思 → 再生成

思考预算就是给 Agent 设定边界：

{
  "max_iterations": 5,
  "max_tool_calls": 10,
  "token_budget": 50000,
  "deadline_seconds": 30,
  "cost_budget_usd": 0.1
}

预算最好按任务类型设置。FAQ 问答尽量一次完成；数据分析允许多步处理；代码生成可以给高预算，但必须限制迭代次数；高风险操作不只设预算，还要人工审批。

预算耗尽时，不要让 Agent 硬编结果。更好的退出方式是返回当前已完成的中间结果，说明哪些部分未完成，请用户确认是否继续，必要时转人工，并记录预算耗尽原因。

6. 输出控制：别让模型变成“话痨”

很多人只关心输入 token，却忽略输出 token。但在不少模型服务里，输出 token 往往更贵，长篇输出还会显著增加延迟。

输出控制要解决的是：让模型只输出需要的信息，不要自由发挥。

自由文本：

经过分析，这个客户属于高价值客户。原因是他的购买频率较高，近 30 天内购买了 5 次，平均客单价达到 680 元，并且没有退款记录。因此建议进入重点维护名单。

结构化输出：

{
  "customer_type": "high_value",
  "purchase_count_30d": 5,
  "avg_order_value": 680,
  "refund_risk": "low",
  "action": "重点维护"
}

再配合明确长度限制：

请用不超过 150 字回答。
只输出结论和 3 条原因。
不要输出推理过程。

原则很简单：能用 JSON，就不要长篇解释；能输出结论，就不要展示完整思考过程；能限制长度，就不要让模型自由发挥。

五、完整案例：客服 Agent 如何做资源感知优化

下面用一个客服 Agent 的完整流程，串起资源感知优化的核心方法。

场景是：一家电商平台每天有大量用户咨询。

用户输入：

我的订单怎么还没发货？

如果没有资源优化，系统可能直接把完整用户信息、订单信息、客服规则、历史对话都塞给强模型，然后生成一大段回答。这当然能用，但成本很高。

更好的做法是分层处理。

第一步，先查语义缓存。系统会发现“我的订单怎么还没发货？”和“为什么我的订单还没有发货？”很接近。如果只是通用咨询，可以返回缓存答案；但这个问题涉及用户自己的订单，所以不能只返回通用答案，还要查询订单状态。

第二步，用小模型或规则判断任务类型：

{
  "intent": "order_shipping_status",
  "need_tool": true,
  "risk_level": "low",
  "recommended_model": "small"
}

第三步，调用工具查询订单，只保留关键字段：

{
  "order_id": "A1024",
  "payment_status": "paid",
  "shipping_status": "not_shipped",
  "warehouse_status": "processing",
  "estimated_ship_time": "2026-06-24 18:00"
}

第四步，用结构化提示词生成短回答：

你是电商客服助手。
 
请根据订单状态回答用户。
要求：
1. 不超过 120 字；
2. 语气礼貌；
3. 不编造原因；
4. 如果订单未发货，说明预计发货时间；
5. 只输出给用户看的回复。
 
订单信息：
{
  "payment_status": "paid",
  "shipping_status": "not_shipped",
  "warehouse_status": "processing",
  "estimated_ship_time": "2026-06-24 18:00"
}
 
用户问题：
我的订单怎么还没发货？

输出：

您的订单已付款，目前仓库正在处理中，预计将在 2026-06-24 18:00 前发货。发货后系统会同步更新物流信息，请您留意订单详情页。

第五步，记录成本和链路：

{
  "trace_id": "cs-20260624-001",
  "intent": "order_shipping_status",
  "cache_hit": false,
  "model": "small-model",
  "input_tokens": 420,
  "output_tokens": 58,
  "tool_calls": ["query_order"],
  "latency_ms": 820,
  "estimated_cost": 0.002
}

这个案例的关键不是用了多少高级技术，而是每一步都在问：

这一步有没有必要？
有没有更便宜的做法？
需要传这么多信息吗？
需要用强模型吗？
输出需要这么长吗？
这次成本有没有记录？

这就是资源感知 Agent 的工作方式。

六、工程上必须守住的原则

1. 成本要前置设计，不要上线后再补

资源感知不是最后加一个“省钱模块”。架构设计时就要想清楚：请求入口在哪里统一管控，缓存在哪里做，模型路由在哪里做，token 怎么统计，成本怎么归属，预算耗尽怎么处理，哪些动作需要人工介入。

比较好的架构是通过统一的 LLM Gateway 管理调用：

业务 Agent 不直接调用模型；
业务 Agent 先请求 Gateway；
Gateway 负责缓存、路由、限流、预算、日志和观测。

这样所有 Agent 都能共享同一套成本控制能力。

2. 成本、延迟、质量要一起看

不能只追求便宜。一个系统如果成本低，但回答经常错，也不能用。也不能只追求质量。一个系统如果每次客服回复都用最贵模型生成 2000 字解释，也不可持续。

工程上要同时观察：

准确率
成本
延迟
缓存命中率
模型升级率
工具调用次数
人工接管率
用户满意度

资源感知优化的目标不是把成本压到最低，而是在业务可接受的质量下，把成本和延迟控制在合理范围。

3. 预算耗尽时要有兜底方案

Agent 预算耗尽不代表系统失败，而是需要合理退出。

错误做法是让 Agent 在预算耗尽后继续硬撑，最后输出一个看似完整但不可靠的答案。

七、和上一篇 A2A、相关模式的关系

资源感知优化不是孤立模式，它会影响前面很多 Agent 设计模式。

1. 和 A2A 的关系

上一篇 A2A 讲的是 Agent 之间如何协作。但多个 Agent 一旦互相调用，成本会放大。

用户请求 → 总控 Agent → 数据 Agent → 分析 Agent → 报告 Agent → 审核 Agent

所以 A2A 系统必须配合资源感知优化：每次跨 Agent 调用要有 trace，每个子任务要有预算，每个 Agent 要记录成本，高成本链路要能被发现，不必要的 Agent 调用要被合并或跳过。

简单说：

A2A 让 Agent 会协作；
资源感知优化让这种协作不至于烧穿预算。

2. 和 RAG、Reflection、HITL 的关系

RAG 会把检索内容放进上下文。如果检索结果太多，输入 token 会快速增长，所以要限制检索条数、压缩检索结果、缓存常见问答，并对长文档先做结构化抽取。

Reflection 能提高质量，但也会增加成本。简单任务可以不反思，普通任务最多反思 1 次，复杂任务允许多轮反思，高风险任务反思后仍需人工确认。

HITL 是人机协同。当 Agent 预算耗尽、置信度不足或风险过高时，不要继续烧 token，而是把任务交给人。这比让 Agent 无限尝试更安全，也更可控。

八、常见坑：资源感知优化不是简单换便宜模型

最容易踩的坑，可以浓缩成下面这张表。

尤其要记住最后一个坑。资源不够或信息不足时，正确输出不是“假装已经完成”，而是明确当前状态：

{
  "status": "partial",
  "message": "当前已完成订单状态查询，但物流系统暂时不可用，无法确认最新配送节点。",
  "next_step": "建议稍后重试或转人工处理",
  "need_human": true
}

九、上线前检查清单

一个资源感知 Agent 上线前，至少检查这些问题。

十、一句话记住资源感知优化

资源感知优化的本质，是让 Agent 在每次行动前都能想清楚：这一步值不值得做，能不能复用，能不能少传，能不能用更合适的模型，能不能在预算内完成。