是什么
为什么
把模糊的自然语言需求转换为应用能够校验、授权、记录和执行的结构化动作。
怎么做
先定义一个窄而清晰的工具 Schema,再由后端验证模型返回的参数,确认权限后执行,并把结果送回模型或用户。
什么时候
需求需要模型在多个动作中做语义选择,参数来自自然语言,而且执行前能够通过明确 Schema 与权限规则约束。不宜时:动作固定、步骤确定或风险很高时,普通表单、按钮、规则引擎或显式工作流通常更简单、更稳定。
FOCUS
先记住这些
模型只负责提议
工具选择和参数都是概率性输出,应用必须允许拒绝、修复或要求用户确认。
Schema 约束形状,不保证业务正确
类型正确的日期、金额或 ID 仍可能不符合当前用户权限和真实业务状态。
连接语义与确定性系统
用户可以自然表达意图,真实动作仍由可测试、可审计的程序完成。
副作用比解析更难
写操作需要审批、幂等、补偿、审计和失败恢复,不能照搬只读查询的处理方式。
ROUTE
学习路径
一个工具只承担一个清晰动作。
用户数据是输入,Schema、权限和策略是控制。
结构、业务规则和授权逐层通过。
工具结果返回模型,同时保留日志与失败信息。
PROBLEM / POSITION / INTERFACE
先弄清它为什么存在,以及谁在使用
-
01 解决的问题
当用户不只想得到一段回答,而是希望查询实时数据、写入业务系统、调用 API 或完成某个动作时。
模型生成的自然语言无法被程序稳定解析,更不能直接获得数据库、支付、文件或外部服务的执行权限。
- 成功标准
- 模型能提出符合 Schema 的调用请求;应用能验证参数与权限、执行或拒绝,并把可追踪的结果返回给后续流程。
-
02 AI 生态位
位于模型推理与应用执行之间,是把语义判断交给确定性程序的接口层;它连接 LLM、工具注册表、权限系统和业务服务。
- 上游
- 用户意图、对话上下文、模型能力、工具说明、参数 Schema、身份与当前业务状态。
- 下游
- 搜索、数据库、内部 API、工作流、浏览器、消息系统,以及需要消费工具结果的模型或页面。
-
03 人的生态位
开发者定义可用工具与安全边界,业务人员决定哪些动作允许自动化,最终用户用自然语言提出目标并在高风险动作前确认。
- 适合使用
- 需求需要模型在多个动作中做语义选择,参数来自自然语言,而且执行前能够通过明确 Schema 与权限规则约束。
- 不必使用
- 动作固定、步骤确定或风险很高时,普通表单、按钮、规则引擎或显式工作流通常更简单、更稳定。
-
04 独特价值
它把模型擅长的语义理解与程序擅长的确定性执行分开:既保留自然语言入口,又让每个动作经过可验证的接口边界。
难点不在“让模型返回 JSON”,而在工具描述、参数歧义、权限、并发、幂等、失败恢复、结果注入和副作用治理。
- 复杂度判断
- 复杂度不是功能数量,而是控制与验证成本。
INTERFACE FLOW
谁在操作,信息怎样流动
-
WHO OPERATES
HUMAN提出目标,配置业务规则,并确认高风险动作
MODEL判断是否需要工具,选择工具并生成候选参数
BACKEND校验参数、检查权限、执行调用、记录审计与处理失败
TOOL读取或改变外部系统,并返回事实结果
-
INPUT
用户请求、当前对话与业务状态,以及应用提供给模型的可用工具定义。
-
CONTROL
工具白名单、JSON Schema、系统指令、身份权限、审批规则、超时、重试、幂等键和调用预算。
-
OUTPUT
模型先输出工具名与结构化参数;后端执行后产生工具结果,可能只读取数据,也可能写库、发消息或改变外部状态。
FLOW
一次可靠工具调用如何完成
MODULES
真正决定好不好用的六个模块
工具说明
让模型知道何时用、何时不用;说明含糊会导致选错工具。
参数 Schema
约束字段结构和基础取值,减少自由文本解析的不确定性。
业务校验
检查日期关系、资源状态、金额范围等 Schema 无法表达的规则。
权限与确认
按身份和风险决定只读、写入、拒绝或人工确认。
执行控制
处理超时、重试、幂等、限流、并发和补偿。
结果适配
把工具事实转换为模型可理解、可追踪且不过度暴露的数据。
COMPARE
什么时候选择 Function Calling
| 方式 | 适合的问题 | 主要优势 | 主要限制 |
|---|---|---|---|
| 普通文本回答 | 只需解释、改写或总结 | 最简单,没有执行副作用 | 不能稳定驱动程序动作 |
| 固定按钮或表单 | 步骤和字段完全确定 | 可预测、易测试、权限清晰 | 难以处理开放式自然语言意图 |
| Function Calling | 意图开放,但动作集合可枚举 | 语义选择与确定性执行兼得 | 需要完整校验、权限和失败治理 |
| 自由代码生成 | 沙箱中的探索性编程 | 表达能力强 | 执行风险高,不适合直接操作核心业务 |
{
"tool_definition": {
"name": "get_order_status",
"description": "读取当前用户有权查看的订单状态;不能修改订单。",
"parameters": {
"type": "object",
"properties": {
"order_id": {
"type": "string",
"description": "订单公开编号"
}
},
"required": [
"order_id"
],
"additionalProperties": false
}
},
"business_input": {
"user_request": "帮我查一下订单 A-2048 到哪了"
},
"control_context": {
"authenticated_user": "current-user",
"allowed_tools": [
"get_order_status"
],
"write_access": false
},
"model_proposal": {
"name": "get_order_status",
"arguments": {
"order_id": "A-2048"
}
}
}ALLOWED_TOOLS = {
"get_order_status": get_order_status,
}
def execute_tool_call(call, user):
# 1. 模型输出永远是不可信输入
name = call.get("name")
arguments = call.get("arguments", {})
if name not in ALLOWED_TOOLS:
return {"ok": False, "error": "tool_not_allowed"}
# 2. Schema 合法不等于业务上有权访问
order_id = arguments.get("order_id")
if not isinstance(order_id, str) or not order_id:
return {"ok": False, "error": "invalid_arguments"}
if not user.can_read_order(order_id):
return {"ok": False, "error": "permission_denied"}
# 3. 真正的工具调用发生在受控代码中
try:
result = ALLOWED_TOOLS[name](
order_id=order_id,
timeout_seconds=3,
)
return {"ok": True, "data": result}
except TimeoutError:
return {"ok": False, "error": "tool_timeout"}
示例强调责任边界;生产环境还需 JSON Schema 校验器、持久化审计、分布式幂等和机密管理。
{
"type": "tool_call",
"id": "call_demo_01",
"name": "get_order_status",
"arguments": {
"order_id": "A-2048"
}
}这是脱敏示例。应用仍需检查当前用户是否有权读取该订单,模型返回 completed 不代表工具已经执行。
PRACTICE
从演示走向生产前的检查清单
FAQ
常见问题
01到底是谁在调用工具:模型还是后端?+
模型生成调用提案;后端读取提案、完成校验并调用真实函数或服务。
如果把模型误认为执行者,就容易跳过权限、审计和失败处理。02Function Calling 和结构化输出有什么区别?+
结构化输出解决“回答长什么样”,Function Calling 进一步表达“希望应用执行哪个动作”;动作是否执行仍由应用决定。
不是每个 JSON 都是工具调用,也不是每个结构化结果都应该产生副作用。03工具参数已经通过 JSON Schema,为什么还要业务校验?+
Schema 检查类型和形状;权限、资源状态、跨字段关系和风险条件属于业务规则。
格式正确的参数仍然可能越权、过期、冲突或造成错误写入。04工具应该设计得大而全,还是小而明确?+
优先使用职责窄、边界清楚的工具,再由应用或 Agent 组合;不要把几十种行为塞进一个万能工具。
工具越宽泛,描述越难写,权限越难切分,模型也越难稳定选对。05模型参数不完整或含糊时应该怎么办?+
不要猜高风险字段;应用可以拒绝候选调用,让模型向用户追问,或提供受控默认值。
自动补全日期、金额、收件人等字段可能把语言歧义变成真实副作用。NEXT