什么是 Function Calling？Agent 如何调用工具，又怎样避免“乱调用”？

大模型本身最擅长的是理解和生成语言，但它不能天然查询数据库、读取订单、发送邮件或运行代码。

Function Calling（函数调用）就是给模型提供一种标准接口，让它知道：

当需要外部能力时，不要自己编结果，而是输出“应该调用哪个工具、传什么参数”。

它是 Agent 能“做事”的关键能力之一。

一、Function Calling 不等于模型真的执行了函数

假设用户问：

帮我查一下订单 20260912 的物流状态。

系统可能给模型提供一个工具：

{
  "name": "get_order_logistics",
  "description": "查询订单物流状态",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "订单编号"
      }
    },
    "required": ["order_id"]
  }
}

模型不会直接去查物流，而是输出结构化请求：

{
  "name": "get_order_logistics",
  "arguments": {
    "order_id": "20260912"
  }
}

真正执行调用的是应用程序或 Agent 框架。它调用订单系统 API，把结果返回给模型；模型再把结果整理成用户能看懂的回答。

所以：

模型负责决定“要不要调用、调用什么”；系统负责决定“允不允许调用、如何安全执行”。

二、Function Calling 在 Agent 中如何工作？

一个典型 Agent 的执行流程如下：

用户提出任务
→ 模型判断需要哪些信息或工具
→ 模型发起 Function Call
→ 系统校验参数、权限和风险
→ 系统执行工具/API
→ 工具结果返回模型
→ 模型判断任务是否完成
→ 继续调用工具或生成最终答案

例如用户说：

分析本月销售下降原因，并生成报告。

Agent 可能依次调用：

1. 查询本月销售数据
2. 查询上月销售数据
3. 查询库存与缺货记录
4. 查询促销活动与客户反馈
5. 进行数据分析
6. 生成报告文件

这就是 Agent 和普通聊天机器人的差别：普通模型只会回答“应该怎么做”，Agent 可以在授权范围内真正推进任务。

三、Function Calling 最容易出现什么问题？

Function Calling 的风险通常不在“函数能不能被调用”，而在“模型是否在正确时间，用正确参数，调用正确工具”。

常见问题包括：

用户只想查询，模型却调用了修改或删除接口；
参数缺失、格式错误，导致调用失败；
模型把猜测的订单号、用户 ID 当作真实值；
连续重复调用同一个工具；
工具返回异常，模型却假装已经成功；
外部文档中的恶意文字诱导模型调用危险工具；
用户权限不足，却通过 Agent 间接访问了敏感数据。

因此，不能把工具权限完全交给模型。

四、如何确保调用正确？

1. 工具定义要清晰且“窄”

不要给模型一个万能工具：

database_query(sql)

而应提供更明确的业务工具：

get_order_logistics(order_id)
get_customer_profile(customer_id)
create_refund_request(order_id, amount, reason)

工具越具体，模型越不容易误用，也越容易做权限控制和审计。

2. 用严格的参数 Schema 校验

工具参数应定义类型、必填项、枚举值和格式。例如：

{
  "amount": {
    "type": "number",
    "minimum": 0,
    "maximum": 10000
  }
}

系统收到模型请求后，必须先验证：

参数是否齐全；
类型是否正确；
格式是否合理；
数值是否越界；
目标资源是否存在。

校验失败时，不执行工具，而是把错误返回模型，让它补充信息或向用户确认。

3. 模型不能猜关键参数

对于订单号、收款账户、员工编号、合同编号等关键信息，Agent 不应“猜一个差不多的”。

正确策略是：

信息明确 → 调用工具
信息不明确 → 追问用户
存在多个候选 → 列出候选让用户确认

例如用户说“帮我给张总发报告”，但系统中有多个“张总”，Agent 必须要求确认收件人，而不是自行选择。

4. 高风险操作必须二次确认

可以把工具分为不同风险等级：

风险等级	示例	策略
低风险	查询资料、读取状态	自动执行
中风险	创建草稿、生成报表	记录日志后执行
高风险	发邮件、退款、删除数据	用户确认后执行
极高风险	转账、修改权限、发布生产环境	人工审批

例如，Agent 可以先生成退款方案，但在真正调用退款接口前，应明确询问：

将为订单 20260912 发起 299 元退款，是否确认？

五、工具返回结果也不能盲信

工具调用成功，不代表任务真的成功。

例如，发邮件接口返回“已提交”，不代表对方已经收到；数据分析接口返回空结果，也可能是筛选条件错误。

因此，Agent 应检查：

返回状态是否成功；
返回数据是否为空或异常；
结果是否符合预期；
是否需要重试、换工具或向用户说明限制。

同时，工具返回的文本也应被视为“数据”，不能让其中的内容改变系统规则或诱导后续危险调用。

六、上线前如何验证 Agent 会不会乱调用？

需要建立专门的测试集，而不只是测“回答写得好不好”。

至少覆盖：

正常查询；
参数缺失；
模糊指令；
重复调用；
权限不足；
工具超时或报错；
恶意提示词注入；
高风险操作；
用户中途取消；
多工具串联任务。

评估指标可以包括：

工具选择正确率
参数正确率
无效调用率
越权调用率
高风险操作确认率
调用成功率
任务最终完成率

结语

Function Calling 让模型从“会说”变成“能连接外部系统”。但它不是让模型拥有无限权限，而是让模型在严格规则下提出行动建议。

一个可靠的 Agent 应当做到：

模型负责思考和决策；系统负责校验、授权、执行和审计；高风险动作始终保留人为控制。