基于langchain,Function Call的成功率怎么解决?

这是 AI Agent 面试中最喜欢问的问题之一

很多人回答:

"换个模型。"

实际上,这只是影响因素之一。

在生产环境(LangChain/LangGraph),Function Calling 成功率是一个系统工程,一般需要从 模型、Tool、Prompt、Workflow、Retry、Monitoring 六个方面优化。

我建议整理成下面这篇博客。


LangChain Function Calling 成功率优化——生产级实践总结

在 AI Agent 中,Function Calling(Tool Calling)是整个 Agent 的核心能力。

例如:

用户:
查询订单123456的物流信息

↓

LLM

↓

调用 query_logistics()

↓

返回物流信息

↓

LLM 总结回答

如果 Tool 没有被正确调用,整个 Agent 基本就失去了价值。

因此,一个生产级 Agent,不仅要让模型"会调用 Tool",更要保证 调用成功率(Tool Success Rate)


一、什么是 Function Calling 成功率?

通常包括四个阶段:

User
    │
    ▼
LLM 是否选择正确 Tool
    │
    ▼
Tool 参数是否正确
    │
    ▼
Tool 是否执行成功
    │
    ▼
LLM 是否正确理解 Tool 返回结果

因此:

Function Calling Success Rate

=

Tool Selection

×

Argument Accuracy

×

Tool Execution

×

Result Understanding

任何一个阶段失败,都属于 Function Calling 失败。


二、影响成功率的六大因素

Prompt

↓

Tool Design

↓

Model

↓

Workflow

↓

Retry

↓

Monitoring

生产环境通常从这六个方面优化。


三、Tool 设计(影响最大)

很多项目 Tool 是这样写的:

query()

模型根本不知道它干什么。

正确做法:

@tool
def query_order(order_id: str):
    """
    查询订单信息。

    仅用于查询订单。

    参数:

        order_id:订单号
    """

描述越明确。

成功率越高。


Tool 不要万能

错误:

CustomerTool

什么都查

正确:

QueryOrder

QueryRefund

QueryLogistics

QueryCoupon

每个 Tool 只负责一件事情。

模型更容易选择。


Tool 名字必须语义化

例如:

错误:

tool1

tool2

正确:

query_order

refund_status

query_logistics

Tool Name 本身就是 Prompt。


四、参数设计

例如:

错误:

query(id)

模型不知道:

id:

到底:

订单?

用户?

商品?

正确:

query_order(order_id)

参数越明确。

调用越准确。


使用 Schema 校验

例如:

class OrderRequest(BaseModel):

    order_id: str

模型输出:

{
    "order_id":"123456"
}

如果:

{
    "id":"123456"
}

Schema 会直接报错。

避免错误继续传播。


五、Prompt 优化

Prompt 决定:

什么时候调用 Tool。

例如:

如果涉及:

订单

物流

退款

必须调用对应 Tool。

禁止自行猜测。

不要:

尽量调用 Tool。

而要:

必须调用。

Prompt 越明确。

调用率越高。


Few-shot 示例

例如:

用户:

退款多久到账?

↓

Tool

query_refund_policy()

↓

回答

模型看到多个案例。

调用率会明显提高。


六、模型选择

不同模型 Function Calling 能力差异很大。

一般来说:

GPT-4.x / GPT-5

★★★★★

Claude

★★★★★

Gemini

★★★★☆

Qwen

★★★★☆

DeepSeek

★★★★☆

小模型

★★★☆☆

如果 Tool 很复杂。

模型能力影响非常明显。


七、Workflow 控制(推荐)

不要把所有 Tool 都交给一个 Agent。

例如:

20 个 Tool

↓

Agent

模型容易选错。

推荐:

Intent Router

↓

订单Agent

↓

订单 Tool

--------------

售后Agent

↓

售后 Tool

每个 Agent:

只看到:

自己的 Tool。

Tool Selection 成功率会大幅提高。


八、Retry(生产必备)

Tool 调用失败。

不要立即失败。

建议:

Tool

↓

失败

↓

Retry

↓

重新生成参数

↓

再次调用

例如:

第一次:

{
"id":"123"
}

Schema:

失败。

LLM:

重新生成:

{
"order_id":"123"
}

第二次成功。


九、Tool Result 标准化

很多 Tool:

返回:

{
"code":0
}

模型根本不知道什么意思。

建议:

统一:

{
    "success":true,

    "status":"运输中",

    "company":"顺丰",

    "tracking_no":"SF123"
}

字段语义越明确。

LLM 越容易理解。


十、Observability(可观测性)

生产环境必须统计:

Tool Call Count

Tool Success Rate

Retry Count

Argument Error

Timeout

Latency

例如:

query_order

成功率

99%

--------------

query_coupon

成功率

62%

说明:

Coupon Tool:

需要优化。

而不是模型不好。


十一、推荐整体架构

User
      │
      ▼
Prompt
      │
      ▼
Intent Router
      │
      ▼
Agent
      │
      ▼
Tool Selection
      │
      ▼
Argument Validation
      │
      ▼
Execute Tool
      │
      ▼
Retry(可选)
      │
      ▼
Result Normalize
      │
      ▼
LLM Summary
      │
      ▼
Answer

这是目前生产级 AI Agent 比较常见的 Function Calling 执行流程。


十二、提升 Function Calling 成功率的实践建议

优化方向 推荐做法
Tool 拆分 一个 Tool 只负责一个业务能力,避免"万能 Tool"
Tool 描述 提供清晰的名称、用途、参数说明和调用场景
参数设计 使用具有业务语义的参数名,结合 Pydantic Schema 校验
Prompt 明确规定什么时候必须调用 Tool,避免模型猜测
Few-shot 提供典型 Tool 调用示例,强化模型决策能力
Intent Router 先分类,再进入对应 Agent,减少 Tool 数量
Retry 参数错误或调用失败时自动重试
Result Normalize Tool 返回统一 JSON 结构,方便模型理解
Monitoring 统计调用率、成功率、错误率、重试次数等指标

总结

Function Calling 成功率并不是某一个模型决定的,而是整个 Agent 架构共同作用的结果。

可以将成功率理解为:

Function Calling Success Rate
        =
Tool Selection
×
Argument Accuracy
×
Tool Execution
×
Result Understanding

因此,生产级 AI Agent 的优化重点通常不是"换一个更强的模型",而是:

  • 让模型更容易选择正确的 Tool(Tool 设计 + Prompt)

  • 让 Tool 更容易被正确调用(Schema + 参数校验)

  • 让失败可以恢复(Retry + Workflow)

  • 让整个过程可观测(Monitoring + Trace)

一句话总结:Function Calling 的成功率,本质上不是 LLM 的问题,而是 Agent 工程化能力的问题。模型负责"决策",工程负责"保证决策能够稳定落地"。

面试时再补充一个加分点

很多高级面试官还会继续追问:

如果 Tool 从 10 个增加到 500 个,Function Calling 成功率为什么会下降?怎么解决?

这是因为 Tool 数量越多,模型选择空间越大,Tool Selection 的准确率会下降。生产上通常不会把几百个 Tool 全部暴露给一个 Agent,而是采用:

User
   │
   ▼
Intent Classifier / Router
   │
   ├── Order Agent(10 个订单 Tool)
   ├── CRM Agent(8 个 CRM Tool)
   ├── Payment Agent(6 个支付 Tool)
   └── Knowledge Agent(RAG)

也就是先路由,再调用 Tool,而不是让一个 Agent 面对所有 Tool。这也是 LangGraph 中 Multi-Agent 架构广泛采用的原因之一。

posted @ 2026-07-13 18:20  若-飞  阅读(12)  评论(0)    收藏  举报