文章目录
- [资源感知优化（Resource-Aware Optimization）](#资源感知优化（Resource-Aware Optimization）)
-
- 一、打个比方：什么是资源感知优化？
- 二、核心概念解析
-
- [2.1 什么是资源感知优化？](#2.1 什么是资源感知优化？)
- [2.2 关键设计原则](#2.2 关键设计原则)
- [2.3 三类问题分类体系](#2.3 三类问题分类体系)
- 三、源码解构：路由智能体（QueryRouterAgent）
- [四、源码解构：OpenAI 实战------完整的资源感知问答系统](#四、源码解构：OpenAI 实战——完整的资源感知问答系统)
-
- [4.1 问题分类器（classify_prompt）](#4.1 问题分类器（classify_prompt）)
- [4.2 响应生成器（generate_response）](#4.2 响应生成器（generate_response）)
- [4.3 综合路由函数（handle_prompt）](#4.3 综合路由函数（handle_prompt）)
- [五、源码解构：OpenRouter 的自动路由与回退](#五、源码解构：OpenRouter 的自动路由与回退)
-
- [5.1 自动模型选择](#5.1 自动模型选择)
- [5.2 顺序模型回退](#5.2 顺序模型回退)
- [六、批判智能体（Critic Agent）](#六、批判智能体（Critic Agent）)
-
- [6.1 角色定位](#6.1 角色定位)
- [6.2 System Prompt 解读](#6.2 System Prompt 解读)
- [6.3 批判智能体的双重价值](#6.3 批判智能体的双重价值)
- 七、资源优化技术谱系
- 八、与前几章的联系
- 九、关键要点总结
- 十、实践建议
资源感知优化（Resource-Aware Optimization）
一、打个比方：什么是资源感知优化？
想象你去了一家餐厅。
- 如果你只是想喝杯可乐，服务员直接给你倒一杯------快速、便宜、立刻满足。
- 如果你要办一桌婚宴，服务员会找主厨来定制菜单------慢一些、贵一些，但品质极高。
- 如果主厨今天请假了，副厨也能顶上------虽然味道稍有差异，但婚宴不会泡汤。
这就是资源感知优化 的核心思想：根据任务的复杂度和可用资源，动态选择最合适的处理方式，在质量和成本之间找到最优平衡点。
放到 AI Agent 的语境里：
- 简单问题（如"澳大利亚首都是什么？"）→ 用快速经济的模型（如 GPT-4o-mini）
- 复杂推理（如"解释量子计算对密码学的影响"）→ 用高阶模型（如 o4-mini）
- 实时信息（如"澳网2026什么时候开始？"）→ 触发搜索引擎获取最新数据
- 主模型挂了 → 自动切换到备选模型，保证服务不中断
二、核心概念解析
2.1 什么是资源感知优化？
资源感知优化（Resource-Aware Optimization）是指智能体在运行过程中动态监控和管理计算、时间和财务资源的能力。它与传统的"一刀切"式处理不同，要求智能体：
- 感知当前可用的资源（算力、预算、时间）
- 评估任务的实际复杂度
- 决策最优的处理路径（选哪个模型、用什么工具）
- 执行并持续优化
2.2 关键设计原则
| 原则 | 说明 | 类比 |
|---|---|---|
| 动态模型切换 | 根据任务复杂度选择不同等级的模型 | 简单任务派实习生，复杂任务派专家 |
| 回退机制 | 主模型不可用时自动切换备选模型 | 主厨请假，副厨顶上 |
| 成本敏感 | 在预算约束内最大化输出质量 | 100块钱预算内做出最好的一桌菜 |
| 自适应路由 | 根据查询特征智能分流 | 前台根据客户需求分配不同部门 |
2.3 三类问题分类体系
本章给出了一个非常实用的三分法：
| 分类 | 定义 | 处理路径 | 模型选择 | 成本 |
|---|---|---|---|---|
| simple | 直接可答的事实性问题，无需推理或外部数据 | 直接生成回答 | GPT-4o-mini | 💰 |
| reasoning | 需要逻辑推理、数学计算或多步思考 | 高阶模型推理 | o4-mini | 💰💰 |
| internet_search | 涉及时事、最新数据或训练数据外的内容 | 先搜索再生成 | GPT-4o + Google Search | 💰💰💰 |
三、源码解构：路由智能体（QueryRouterAgent）
这是本章最核心的代码------Google ADK 实现的路由智能体。我们逐行拆解：
python
# 概念性 Python 结构，非可运行代码
from google.adk.agents import Agent, BaseAgent
from google.adk.events import Event
from google.adk.agents.invocation_context import InvocationContext
import asyncio
class QueryRouterAgent(BaseAgent):
name: str = "QueryRouter"
description: str = "根据复杂度将用户查询路由到合适的 LLM Agent。"
async def _run_async_impl(self, context: InvocationContext) -> AsyncGenerator[Event, None]:
user_query = context.current_message.text # ← 第13行：从上下文中获取用户原始查询
query_length = len(user_query.split()) # ← 第14行：用词数作为复杂度的简单指标
if query_length < 20: # ← 第16行：阈值判断（简单 vs 复杂）
print(f"短问题（长度：{query_length}）路由到 Gemini Flash Agent")
response = await gemini_flash_agent.run_async(context.current_message)
yield Event(author=self.name, content=f"Flash Agent 处理结果：{response}")
else:
print(f"长问题（长度：{query_length}）路由到 Gemini Pro Agent")
response = await gemini_pro_agent.run_async(context.current_message)
yield Event(author=self.name, content=f"Pro Agent 处理结果：{response}")逐行解读：
| 行号 | 代码 | 解读 |
|---|---|---|
| 3-5 | from google.adk.agents import ... |
导入 ADK 核心组件：BaseAgent 是自定义智能体的基类，Event 是智能体间通信的事件对象，InvocationContext 封装了当前调用的上下文信息 |
| 8 | class QueryRouterAgent(BaseAgent) |
路由智能体继承自 BaseAgent，这是 ADK 中创建自定义智能体的标准方式 |
| 9 | name: str = "QueryRouter" |
智能体名称，用于日志追踪和系统标识 |
| 10 | description: str = "..." |
智能体描述，在多智能体系统中帮助其他智能体理解它的职责 |
| 12 | async def _run_async_impl(...) |
这是 ADK 智能体的核心执行方法，使用异步生成器模式，可以逐步产出事件 |
| 13 | context.current_message.text |
从调用上下文中提取用户的原始文本查询，context 对象封装了当前请求的所有信息 |
| 14 | len(user_query.split()) |
关键设计：用词数作为复杂度的代理指标。虽然简单，但在实践中是有效的快速启发式方法 |
| 16 | if query_length < 20 |
阈值设定为20个词。短问题通常意味着简单查询，长问题则暗示复杂需求 |
| 18 | await gemini_flash_agent.run_async(...) |
调用经济型 Flash Agent 异步处理，使用 await 避免阻塞 |
| 19 | yield Event(...) |
通过 yield 将处理结果作为事件返回给调用方，这是 ADK 的事件驱动架构的核心 |
| 22 | await gemini_pro_agent.run_async(...) |
对复杂问题调用高阶 Pro Agent，同样的异步调用模式 |
路由智能体的设计要点
- 继承 BaseAgent ：ADK 提供的标准扩展点，比直接用
Agent更灵活 - 异步生成器模式 ：
AsyncGenerator[Event, None]允许逐步产出事件，支持流式响应 - 简单启发式：用词数作为路由指标，虽然不够精确，但执行速度极快，不会增加额外的模型调用成本
- 可扩展性 ：可以轻松替换为 LLM 驱动的复杂度分类器（如后文的
classify_prompt函数）
四、源码解构：OpenAI 实战------完整的资源感知问答系统
这是本章的第二个核心代码，展示了一个完整的、可运行的资源感知问答系统。我们重点分析问题分类 和响应生成两个关键步骤：
4.1 问题分类器（classify_prompt）
python
def classify_prompt(prompt: str) -> dict:
system_message = {
"role": "system",
"content": (
"你是一个分类器，分析用户问题并只返回以下三类之一：\n\n"
"- simple\n"
"- reasoning\n"
"- internet_search\n\n"
"规则：\n"
"- 直接事实问题且无需推理或时事，用 'simple'。\n"
"- 逻辑、数学或多步推理问题，用 'reasoning'。\n"
"- 涉及时事、最新数据或训练数据外内容，用 'internet_search'。\n\n"
"仅用如下 JSON 回复：\n"
'{ "classification": "simple" }'
),
}
user_message = {"role": "user", "content": prompt}
response = client.chat.completions.create(
model="gpt-4o", messages=[system_message, user_message], temperature=1
)
reply = response.choices[0].message.content
return json.loads(reply)解读：
| 要素 | 分析 |
|---|---|
| 分类模型 | 用 GPT-4o 做分类器，而非专门训练的分类模型。这是一个 trade-off：GPT-4o 理解能力强但成本更高，适合原型验证 |
| System Prompt 设计 | 精心设计的三分法规则，每条规则边界清晰，避免歧义。还强制 JSON 输出格式，方便程序解析 |
| temperature=1 | 设置为1（较高），让模型有更多"创造性"来判断分类，避免过于保守 |
| JSON 输出 | 强制结构化输出，便于下游代码解析，这是一个好实践 |
4.2 响应生成器（generate_response）
python
def generate_response(prompt: str, classification: str, search_results=None) -> str:
if classification == "simple":
model = "gpt-4o-mini" # ← 简单问题：最便宜的模型
full_prompt = prompt
elif classification == "reasoning":
model = "o4-mini" # ← 推理问题：推理专用的轻量模型
full_prompt = prompt
elif classification == "internet_search":
model = "gpt-4o" # ← 搜索问题：需要整合搜索结果的通用模型
if search_results:
search_context = "\n".join(
[f"Title: {item.get('title')}\nSnippet: {item.get('snippet')}\nLink: {item.get('link')}"
for item in search_results]
)
else:
search_context = "未找到搜索结果。"
full_prompt = f"""请用以下网页结果回答用户问题：
{search_context}
问题：{prompt}"""
response = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": full_prompt}],
temperature=1,
)
return response.choices[0].message.content, model模型选择策略解读：
| 分类 | 模型 | 单次调用成本（相对） | 选择理由 |
|---|---|---|---|
| simple | gpt-4o-mini | ×1（基准） | 事实性问题不需要强推理能力，mini 足够 |
| reasoning | o4-mini | ×5-10 | 推理专用模型，虽然比 mini 贵，但比 o1 便宜得多 |
| internet_search | gpt-4o | ×10-15 | 需要整合搜索结果并进行综合分析，需要通用强模型 |
4.3 综合路由函数（handle_prompt）
python
def handle_prompt(prompt: str) -> dict:
classification_result = classify_prompt(prompt) # 步骤1：分类
classification = classification_result["classification"]
search_results = None
if classification == "internet_search":
search_results = google_search(prompt) # 步骤2：按需搜索
answer, model = generate_response(prompt, classification, search_results) # 步骤3：生成
return {"classification": classification, "response": answer, "model": model}这个函数是整个系统的编排层 ，清晰地展示了三步流水线：分类 → 搜索（按需） → 生成。
五、源码解构：OpenRouter 的自动路由与回退
OpenRouter 提供了两种非常实用的路由方式：
5.1 自动模型选择
json
{
"model": "openrouter/auto"
}一个 API 调用，OpenRouter 自动帮你选最合适的模型。 这就像你跟出租车司机说"去机场"，不需要你告诉他走哪条路，他自己会根据实时路况选择最优路线。
5.2 顺序模型回退
json
{
"models": ["anthropic/claude-3.5-sonnet", "gryphe/mythomax-l2-13b"]
}指定优先级列表，系统自动按顺序尝试。 这就像你手机设置了 Wi-Fi 和移动数据的优先级：Wi-Fi 连不上自动切换到流量，用户完全无感知。
六、批判智能体（Critic Agent）
6.1 角色定位
批判智能体是资源感知优化系统的"质检员"。它的职责不是直接回答问题，而是评估答题智能体的输出质量。
6.2 System Prompt 解读
你是 **批判智能体**，负责我们协作研究助手系统的质量保障。
你的主要职责是**细致审查和挑战**研究智能体的信息，
确保**准确、完整和无偏见**。
你的任务包括：
* 评估研究结果的事实正确性、全面性和潜在倾向。
* 识别缺失数据或推理不一致之处。
* 提出关键问题以完善或扩展当前理解。
* 提供建设性建议以优化或探索不同角度。
* 验证最终输出的全面性和均衡性。6.3 批判智能体的双重价值
| 维度 | 直接价值 | 间接价值 |
|---|---|---|
| 质量保障 | 识别错误、不一致和偏见 | 提升最终输出的可信度 |
| 路由优化 | 发现不合理的分流（如简单问题用 Pro） | 间接优化资源分配和成本 |
| 持续改进 | 为强化学习和微调提供反馈数据 | 让系统越用越聪明 |
七、资源优化技术谱系
本章最后总结了一个完整的技术谱系，从简单到复杂：
| 技术等级 | 技术 | 核心思想 | 适用场景 |
|---|---|---|---|
| ⭐ | 动态模型切换 | 简单问题用小模型，复杂问题用大模型 | 通用 Agent 系统 |
| ⭐ | 自适应工具选择 | 根据成本、延迟选择最适合的工具 | 需要调用外部 API 的 Agent |
| ⭐⭐ | 上下文剪枝与摘要 | 减少 token 数量，降低推理成本 | 长对话、多轮交互 |
| ⭐⭐ | 优雅降级与回退 | 主模型不可用时自动切换 | 生产环境的高可用部署 |
| ⭐⭐⭐ | 主动资源预测 | 预测工作负载，提前分配资源 | 大规模分布式 Agent 系统 |
| ⭐⭐⭐ | 学习型资源分配 | 用强化学习优化资源分配策略 | 长期运行的复杂系统 |
八、与前几章的联系
| 前置章节 | 与本章的关系 |
|---|---|
| 多智能体协作 | 资源感知优化本身就是多智能体架构的一种应用------路由智能体、答题智能体、批判智能体各司其职 |
| 工具使用 | 自适应工具选择是工具使用模式在资源约束下的升级版 |
| 评估与监控 | 批判智能体依赖评估能力来提供反馈，评估是资源优化的"眼睛" |
| 规划 | 资源感知规划是传统规划的增强版------不仅要规划动作序列，还要考虑每个动作的资源消耗 |
| 记忆 | 上下文剪枝与摘要本质上是一种资源感知的记忆管理策略 |
九、关键要点总结
-
核心思想 ：不是所有任务都需要最强模型，用合适的模型做合适的事才是资源感知优化的精髓。
-
路由智能体是关键：它就像交通指挥员，负责将不同复杂度的请求分流到最合适的处理单元。
-
回退机制保障可靠性 ：生产环境中，模型可能限流、宕机、不可用，优雅降级比直接报错好一万倍。
-
批判智能体是闭环的关键：没有反馈的优化是盲目的。批判智能体提供质量反馈，让系统不断自我改进。
-
OpenRouter 是实用的工具：自动模型选择和顺序回退功能，让开发者不需要自己实现复杂的路由逻辑。
-
三分法分类很实用：simple / reasoning / internet_search 三类分类，覆盖了大部分问答场景，是一个值得借鉴的设计模式。
-
成本与质量的权衡是永恒话题：资源感知优化没有"最优解"，只有"最适合当前场景的解"。关键是建立可量化的评估体系，让权衡有据可依。
十、实践建议
- 从简单启发式开始：先用词数、关键词匹配等简单方法做路由，验证业务价值后再升级到 LLM 分类器
- 记录每次路由决策：日志中记录分类结果、使用的模型、响应时间、成本，为后续优化提供数据支撑
- 设置成本上限：为每个请求设置最大 token 预算，防止复杂查询消耗过多资源
- 定期评估路由准确性：人工抽样检查分类是否正确，根据结果调整阈值或提示词
- 监控模型可用性：实时监控各模型的响应时间和错误率，动态调整回退策略