更新于

OpenAI 内置工具的选型与组合：web_search、file_search、code_interpreter 怎么搭

OpenAIResponses API内置工具技术深度

Responses API 上线后，OpenAI 把过去分散在 Assistants API、ChatGPT 网页版里的能力，统一收进了一组”内置工具”（hosted tools）：web_search、file_search、code_interpreter、computer_use，加上图像生成工具。它们的共同特点是不需要你自己实现执行逻辑——声明一下就能用，跟自定义 function calling 的开发体感完全不同。

问题也随之而来：一个真实项目往往同时需要检索网页、查内部文档、跑一段计算，这几个工具该怎么分工？全塞进一次请求会不会互相打架？本文不重复讲每个工具的 API 参数（官方文档已经很全），而是聚焦”选哪个、怎么组合”这个决策问题。

一、内置工具一览：各自解决什么问题

工具解决的问题典型触发场景
web_search模型知识过时/缺失实时信息”今天的汇率”、“最新版本号”、时效性问答
file_search需要在私有文档里做语义检索产品手册问答、内部知识库
code_interpreter需要精确计算、数据处理、画图统计分析、单位换算、生成 CSV/图表
computer_use需要操作真实 GUI 环境网页表单填写、跨系统的界面自动化
图像生成工具需要按文本描述产出图片配图、原型草图、素材生成

这五类工具解决的是完全不同维度的问题——检索 vs 计算 vs 操作 vs 生成，几乎没有互相替代的关系，这也是为什么”选型”往往不是单选题，而是组合题。

关于 file_search 和自建 RAG 的详细对比，见 OpenAI File Search vs 自建 RAG：怎么选更合适，本文不再展开。

二、web_search：什么时候必须开，什么时候不该开

web_search 的收益很直观：把模型从”训练截止日期”的限制里解放出来。但它不是免费的默认项，盲目打开会带来两个副作用：

  • 延迟上升：一次搜索通常意味着额外的网络往返 + 结果摘要，实测比纯文本生成慢 1.5–3 倍
  • 不可控的引用内容：搜索结果的质量参差不齐，模型可能引用低质站点的信息作为事实依据

该开的场景：问题里包含”最新”、“今天”、“当前版本”、“最近发生”这类时效性词，或者领域是新闻、行情、版本号等高频变化的信息。

不该开的场景：

  • 数学计算、代码生成、纯逻辑推理——这些任务联网搜索反而可能引入噪音
  • 已经有 file_search 覆盖的私有知识——不要指望公网搜索能查到你的内部文档
  • 对延迟敏感的实时对话场景，除非用户明确要求”查一下”

一个实用的工程模式是条件触发而非全局开启：在请求前用一个轻量分类（可以是关键词规则，也可以是一次小模型调用）判断问题是否需要实时信息，只有命中才在 tools 里加入 web_search。这比每次请求都带上全部工具、让模型自己决定是否调用，成本更低、延迟也更稳定。

三、code_interpreter：别用它做检索,也别用它做创意生成

code_interpreter 本质是一个沙箱化的 Python 执行环境，模型会写代码、跑代码、把结果拿回来继续推理。它的强项非常明确：任何需要精确性的任务——数值计算、日期处理、数据聚合、生成图表、格式转换。

常见的误用有两种：

  1. 拿它做知识检索：比如让模型”用 code_interpreter 查一下某个概念的定义”——这是滥用，应该用 file_search 或 web_search
  2. 拿它做开放式创意生成：比如”写一段有意思的文案”——这类任务不需要执行代码，直接生成即可，走 code_interpreter 只会增加一次不必要的沙箱调用

判断标准很简单：这个任务的答案是否需要”算出来”而不是”想出来”。如果答案对错有客观标准（比如”这两个日期相差多少天”），交给 code_interpreter；如果答案是主观表达（比如”帮我起个标题”），不需要它。

from openai import OpenAI

client = OpenAI(
    base_url="https://api.yotradeapi.com/v1",  # 国内中转地址
    api_key="your_api_key"
)

response = client.responses.create(
    model="gpt-4.1",
    tools=[{"type": "code_interpreter", "container": {"type": "auto"}}],
    input="这是一份包含 200 行销售数据的 CSV，帮我算出每个季度的环比增长率，并画出趋势图。"
)

print(response.output_text)

四、file_search 与 web_search 的边界：内部知识 vs 公开信息

这两个工具最容易被混着开，因为都属于”检索类”工具，表面上看起来可以互相补位。实际上它们的数据源完全不重叠：

  • file_search 只能检索你上传到 Vector Store 的文件，公网上的信息它一无所知
  • web_search 只能查公开网页，你的内部文档、数据库记录它接触不到

同时开启两者本身没有问题，但要注意提示词里要不要引导模型区分信息来源。如果一个问题既可能命中内部文档、又可能需要公开信息（比如”我们产品支持的最新 API 版本是多少，跟竞品比怎么样”），最好在 system prompt 里明确”公司内部规格优先查 file_search，行业对比信息用 web_search”，避免模型混用来源导致答案自相矛盾。

五、computer_use：慎用的重型工具

computer_use 允许模型通过截图 + 坐标点击的方式操作真实的浏览器或桌面环境，是目前几个内置工具里执行链路最长、也最不可控的一个。适用场景非常窄：没有 API、只能靠 GUI 操作的系统（老旧的内部系统、部分 SaaS 后台）。

在决定使用它之前，先问自己一个问题：目标网站/系统有没有 API？ 如果有，哪怕要多写一层适配代码，也应该优先用普通 function calling 调用 API，而不是用 computer_use 去模拟点击——后者的稳定性和速度都明显更差，且每一步操作都有截图带来的 token 成本。

computer_use 更适合作为兜底方案：当自动化流程遇到没有 API 覆盖的步骤时，作为最后一段”人工操作替代”插入，而不是整个流程的主力工具。

六、内置工具 vs 自定义 function calling：怎么分工

很多团队一上来就想”能不能把所有能力都做成自定义 function”，其实没必要。分工原则可以简化成一句话：

通用能力用内置工具，业务专属能力用自定义 function。

维度内置工具自定义 function calling
开发成本声明即用，无需实现需要自己写执行逻辑 + 部署
适用范围通用能力（搜索/检索/计算/操作）业务专属逻辑（查订单、下单、发消息）
可控性执行细节不透明（沙箱内部逻辑不可见）完全自己掌控
维护成本由 OpenAI 维护和迭代自己负责稳定性和安全

关于自定义 function calling 与”tool use”这两个常被混用的概念的差异，见 Function Calling vs Tool Use 差异辨析；并行调用多个自定义 function 的实战细节见 LLM 并行函数调用实战。

一个具体例子：电商客服场景里，“查一下这个商品的最新评价趋势”适合 web_search（如果评价在站外）或自定义 function（如果评价数据在自己数据库），“查一下用户订单状态”必须是自定义 function（没有内置工具能连到你的订单系统），“算一下退款金额和运费差价”适合 code_interpreter。三种工具在同一个 Agent 里各司其职，不冲突。

七、组合使用的常见坑

把多个工具塞进同一次请求的 tools 数组是允许的，但实践中有几个容易踩的坑：

工具越多，模型选择错误的概率越高。当 tools 里同时有 web_search、file_search、code_interpreter 和 5 个自定义 function 时，模型偶尔会选错工具（比如该查内部文档却去搜网页）。缓解办法是在每个工具的 description 里写清楚”何时该用、何时不该用”的边界，而不只是描述功能本身。

并行调用不代表并行执行。多个工具调用在一次响应里被模型同时发起，但 code_interpreter 和 computer_use 这类有状态的工具，执行上通常还是顺序处理，实际延迟是叠加而非并行的，做延迟预算时要按最坏情况估算。

沙箱工具的结果不会自动持久化。code_interpreter 生成的文件、图表默认存在临时容器里，如果业务需要保留产出，要显式读取返回的文件引用并转存，不要假设下一轮对话还能访问。

Responses API 里多轮工具调用的完整循环写法（包括工具结果如何传回模型），见 Responses API 多轮工具调用循环实战。

八、成本视角:内置工具不是免费的

内置工具的计费方式跟普通 token 不完全一样,决策时要一起算进去:

  • web_search:除了搜索本身的调用成本,搜索结果注入上下文会显著增加 input tokens,一次搜索通常带来几百到上千 tokens 的额外消耗
  • code_interpreter:按容器运行时间计费(近似,以官方最新定价为准),空跑或反复启动容器会累积成本
  • computer_use:每一步操作都要传回一张截图,图像 token 成本远高于文本,长流程的总成本可能超出预期

一个简单的成本控制思路是限定工具的调用次数上限(通过 max_tool_calls 或业务层的重试计数),防止模型在没有拿到理想结果时反复重试同一个工具,尤其是 web_search 和 code_interpreter 这种单次成本不低的工具。

九、国内访问建议

这些内置工具都跑在 OpenAI 官方服务端(沙箱、搜索索引都是 OpenAI 托管),意味着无论走哪个工具,底层请求依然要打到 api.openai.com。国内直连不稳定时,通过中转服务(如 YoTradeApi)把 base_url 换成中转地址即可,tools 参数和工具调用逻辑不需要做任何改动,SDK 层完全兼容。

十、相关阅读

如果你的项目需要在国内稳定调用这些内置工具，YoTradeApi 提供兼容 OpenAI SDK 的 API 中转，改一行 base_url 即可接入，无需额外改造。

相关阅读