这是 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 架构广泛采用的原因之一。