工具调用

这项能力主要服务于 Function Calling / Tool Calling 测试。

它主要和 多消息工作区 配合使用，而不是一个独立工作区。

这项功能的真实定位

当前公开实现的重点是：

• 定义工具 schema
• 把工具定义随上下文一起发给模型
• 观察模型是否发起 tool call，以及参数长什么样

它当前不是一个通用外部工具执行平台。

也就是说，这里重点不是：

• 代你真正调用天气 API
• 自动执行数据库查询
• 自动把工具结果串成完整业务流程

这项功能当前能做什么

在 /#/pro/multi 工作区中，你可以：

1. 打开工具管理
2. 定义工具名称、描述和参数 JSON Schema
3. 用支持 tool calling 的模型执行测试
4. 在结果区查看模型返回的 tool call

工具定义长什么样

典型结构如下：

{
  "name": "get_weather",
  "description": "获取指定城市天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "城市名称"
      }
    },
    "required": ["city"]
  }
}

最适合用来测什么

1. 模型会不会发起正确的 tool call

例如你想测试：

• 模型是否会选择 get_weather
• 参数里会不会正确填入城市名

2. 不同模型的工具理解能力差异

例如在同样的 system prompt 和工具定义下：

• 模型 A 能正确组装参数
• 模型 B 容易漏字段或误用字段

这类差异就很适合放到右侧做测试和评估。

工具应该在哪里管理

当前主要入口有两个：

• 工作区中的 工具管理
• 上下文编辑器 -> tools

工具定义也会跟上下文一起导出到标准格式 JSON 的 tools[] 字段。

怎么写更稳

一个工具只做一件事

工具越单一，模型越容易正确调用。

参数描述要写清楚

字段名、说明、枚举值越明确，越有利于模型稳定生成正确参数。

不要把工具定义写成业务文档

工具描述的重点是“让模型知道何时调用、怎么填参数”，不是把所有背景知识都塞进去。

和右侧评估怎么配合

如果你在多消息工作区测试 tool calling，右侧更适合关注这些问题：

• 模型有没有选择正确工具
• 参数字段是否完整
• 字段值是否跑偏
• 不同模型在同一套 schema 下差异大不大

如果你已经知道自己最关心的问题，例如“经常漏字段”或“参数值经常乱填”，评估时可以加聚焦说明。

相关页面

• 多消息工作区
• 变量工作区
• 测试与评估