

首页  思维导图  详情



Agent 工具面试实战

2026-04-13 11:10:46   0  举报





AI智能生成

Agent 工具面试实战

Agent

Agent 工具

Agent 工具准备率

模版推荐

作者其他创作

大纲/内容

动态函数路由问题

工具迷失（Tool Confusion）问题

工具越加越多，模型开始越来越“不听话”

明明查询天气，它偏要调用查机票

明明需要订酒店，它却返回纯文本

明明有正确工具，却自己编一个不存在的工具名

明明参数明确，却把两个工具的字段混着用

案例

“查一下明天北京的天气。”

LLM 的“判断能力”在工具数量上升后呈指数下降

工具越多，出错率也就越大

企业级 Agent，通常是几十甚至上百个工具，因此，如果工具不分流，模型一定会乱选

为什么要做动态路由

模型不是人，它并不“理解工具之间的逻辑关系”

模型不擅长做选择题

工具过多会出现的问题

工具语义相似（search_flights vs get_flight_info）

参数高度重叠（city / location / place）

功能边界模糊

多个工具看起来都能处理当前问题

工具数量越多，工具选择错误率越高

解决的问题

工具选择混乱

Schema 冲突导致误调用

token 压力大导致上下文丢失

模型注意力分散导致随机性增加

多工具之间语义重叠导致混淆

关键逻辑

工具不是模型来选的，而是系统来过滤的

模型只做“在正确工具中挑一个”

如何实现

规则路由 → 意图识别 → 上下文理解 → 工具过滤 → 再交给 LLM 决定最终调用

轻量规则路由（Rule-based Routing）

适用于那些强语义、强关键词的工具

案例

包含“天气”“气温”“下雨”

get_weather

包含“机票”“航班”“几点起飞”

search_flights

包含“退房”“酒店”

search_hotels

特点

规则简单粗暴，但极其有效

越简单的逻辑，越稳定。

意图分类（Intent Classification）

需要一个轻量 LLM 或者一个意图分类器来判断用户要干什么

案例

我想从上海去北京的那两天住机场附近，有推荐吗？

有“住”

酒店工具

有“机场附近”

航班工具

有“上海到北京”

地理工具

有“推荐”

混合意图

需要分类器来判定“主任务”是什么

组合策略（Hybrid Routing）

将规则 + 分类 + 记忆信息 组合使用

例如： 用户上一轮刚说“我确定要去北京” 记忆里保存目的地=北京 规则 + intent 结合后 → 可能最终确定为调用 search_hotels

总结：没有路由的 Agent，只是一个“工具堆”，有路由的 Agent 才是真正“能工作的系统

工具调用影响准备率的核心因素

Schema 定义不严谨

典型表现

参数名含糊（如 city / location / place 混着用）

工具名不唯一（如 search_flights 和 get_flight_info）

多个工具功能重叠

描述里有歧义

案例

search_hotels(location, check_in_date, check_out_date)

如果 location 写成：“ 城市名称 或区域名称”“ 目的地”“区域（可选）”

模型会困惑，因为它不知道优先级。

Agent 的 Schema 必须做到

参数唯一

功能无重叠

语义明确

格式严格

例子清晰

Prompt 上下文没有约束好

模型不知道该怎么做决定，也不知道自己的决策怎么被评价。

案例

“你是一个智能旅行助手，你可以使用以下工具……请正确调用工具。”

致命问题

没告诉模型什么时候必须调用工具

没告诉模型什么时候不能调用工具

没要求模型必须先思考再调用

没明确参数必须 JSON 格式且严格遵守 Schema

没告诉它错误时要反思和修正

正确方式

1. 先思考用户意图  

2. 决定是否需要工具  

3. 若需要工具，必须输出规范格式  

4. 若工具结果报错，必须基于错误信息调整下一步计划

采样策略（temperature / top-p）设置太“放飞”

模型关键参数

temperature

创造力

如果 temperature > 0.5

工具名变体（特别危险）

参数名拼写错误

日期格式乱写

明明应该调用工具却直接输出文本答案

top-p

稳定性

Function Calling 是典型的“工程任务”，不是“写诗”。

缺乏运行时防御机制（runtime guardrail）

企业系统必须有兜底机制

典型必备机制

JSON Schema 校验

参数不全

拒绝

类型错误

拒绝

拼写错误

拒绝

Retry / Reflection（反思重试）

RATE_LIMIT

自动重试

参数格式错误

自动重试

401 未授权

自动重试

工具不存在

自动重试

Result Validation（输出检查）

航班价格不是数字

日期格式不对

酒店列表为空

错误记录

记录参数

user_query

tool_chosen,

params

error_type

聚类分析，找到最常见错误类型，然后反向优化 Schema 或 Prompt

思想纠正

错误理念

模型应该懂

模型应该能判断

模型应该能自动修正

现实

模型只擅长生成，不擅长遵守规则。

稳定性不是模型给的，是工程体系给的。

掌握

Schema 设计

Prompt 策略

工具路由

CoT + Plan-Execute

校验层

错误恢复机制

日志闭环

总结

Agent 的 Function Calling 不稳定，最可能的原因不在模型，而在系统

越工程化，越稳定；越随便写，越随机。

企业级 Agent 的核心能力，是把模型变成“可控的执行体”，而不是“随机的语言模型”

 Collect

Get Started

研发范式转移与 AI Agent 架构演进

 Collect

Get Started

Upgrade Agent

 Collect

Get Started

为什么现在主流 Agent 都采用 ReAct？

 Collect

Get Started

Agent链路





0 条评论

下一页