登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  人工智能

OpenAI 工具选择策略怎么限制模型只调用指定工具

来源:17golang原创

时间:2026-09-10 09:43:08 463浏览 收藏

当一次 Responses API 请求同时带上天气查询、文档检索和发邮件三个函数时,模型“能看见”它们,不等于当前业务就允许它们全部被调用。要限制本轮只使用其中一部分,保留完整的 tools 定义,再用 tool_choiceallowed_tools 指定子集;需要强制调用时把 mode 设为 required

官方地址:https://developers.openai.com/api/docs/guides/function-calling

最稳妥的分工是:tools 描述能力全集,allowed_tools 收窄当前轮次,mode 表达“可不可以调用”,真正的权限、参数和副作用审批仍由你的服务端负责。
要点速览
  • allowed_tools 只能从已声明的工具中选子集,不能凭空创建未声明的函数。
  • auto 允许模型不调用或调用一个以上允许工具,required 要求至少调用一个,none 禁止工具调用。
  • 工具白名单不是业务鉴权;执行函数前仍要校验用户、函数名、参数和可产生的副作用。

只声明 tools,为什么仍然可能选错工具

tools 是模型在这次请求中可以考虑的能力全集。例如你把三个函数都放进去,模型就可能在上下文允许时考虑 send_email。如果只是把“不要发邮件”写进提示词,约束依赖自然语言,无法形成清晰的参数边界。

allowed_tools 解决的是“完整工具集不变,但本轮只开放哪几个”的问题。这样既可以复用稳定的工具定义,也能按会话、租户或工作阶段收窄选择范围。

Responses 请求中 tools 完整工具集与 allowed_tools 当前子集的静态关系
图1:完整 tools 仍保留在请求定义中,allowed_tools 只收窄当前轮次可选择的函数集合。

allowed_tools 的结构怎么写

下面示例把三个函数都声明为工具,但当前轮次只让模型在 get_weathersearch_docs 中选择。JSON 本身不加注释,字段含义紧跟示例说明。

{
  "tools": [
    {"type": "function", "name": "get_weather", "description": "查询城市天气"},
    {"type": "function", "name": "search_docs", "description": "搜索内部文档"},
    {"type": "function", "name": "send_email", "description": "发送邮件"}
  ],
  "tool_choice": {
    "type": "allowed_tools",
    "mode": "auto",
    "tools": [
      {"type": "function", "name": "get_weather"},
      {"type": "function", "name": "search_docs"}
    ]
  }
}

外层 tools 是完整定义,内层 tool_choice.tools 是允许集合。两处的类型和函数名要对应;send_email 仍可留在完整定义里,但不在本轮允许子集中。若调用方每轮只改变白名单而不改变完整工具定义,还能保持请求结构更稳定。

auto、required 和 none 怎么选

配置模型侧含义适用场景
allowed_tools + auto只可从子集中选择,也可以不调用问答优先,必要时查资料
allowed_tools + required必须调用一个或多个子集工具每轮都要查库存或读取文档
none不调用工具,直接生成消息纯文本阶段或暂停外部能力
指定 function强制一个确定函数单一动作入口

如果业务还不希望一次产生多个函数调用,可另外设置 parallel_tool_calls: false;它控制并行调用数量,不负责选择白名单。不要把 required 理解成“必定执行成功”,它只表达模型必须提出工具调用,服务端仍可能拒绝。

allowed_tools 的 auto required none 与服务端权限校验参数校验副作用执行器的静态关系
图2:mode 表达模型侧的调用策略,函数名、参数和副作用仍需经过服务端边界检查。

mode 只决定选择范围,权限仍由服务端兜底

工具调用返回后,不要直接把模型给出的函数名和参数交给高权限代码。服务端至少应按当前用户和业务状态重新核验函数名、必填字段、资源归属、幂等键与副作用等级。尤其是发邮件、改订单、写数据库这类函数,模型侧白名单只能减少误选,不能替代授权。

ALLOWED = {"get_weather", "search_docs"}

def dispatch_tool(call, user):
    # 先限制函数名,再校验参数和当前用户的业务权限。
    if call.name not in ALLOWED:
        raise PermissionError("tool is not allowed in this turn")
    args = parse_json(call.arguments)
    # 解析失败、字段越界或资源不属于当前用户时,不能继续执行。
    validate_arguments(call.name, args)
    authorize(user, call.name, args)
    return TOOL_HANDLERS[call.name](**args)

这里的 ALLOWED 只是应用层最后一道显式检查,实际项目还应将允许集合绑定到租户和会话状态,而不是写成所有用户共用的常量。模型返回的参数也要按服务端 schema 重解析,不能因为请求里使用了 strict 就省略业务授权。

相关问题

allowed_tools 能否放一个 tools 中没有的函数?

不能。它是已声明工具的子集;未在外层 tools 中定义的函数名没有可执行定义。

required 会不会保证函数一定执行成功?

不会。它只要求模型产生一个或多个工具调用请求,网络错误、参数校验、权限拒绝和业务失败仍由应用处理。

只把危险工具从 allowed_tools 删除够安全吗?

不够。还要在服务端按用户、资源和参数做授权,必要时增加人工确认、幂等和审计;模型侧限制是选择控制,不是完整安全边界。

什么时候应该使用 none?

当当前阶段只需要生成解释、整理结果或等待用户确认时,用 none 明确关闭工具调用,避免模型继续触碰外部能力。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>