mirror of
https://github.com/linshenkx/prompt-optimizer.git
synced 2026-06-06 14:39:56 +08:00
110 lines
2.7 KiB
Markdown
110 lines
2.7 KiB
Markdown
# 工具调用
|
||
|
||
这项能力主要服务于 **Function Calling / Tool Calling 测试**。
|
||
|
||
它主要和 [多消息工作区](context.md) 配合使用，而不是一个独立工作区。
|
||
|
||
## 这项功能的真实定位
|
||
|
||
当前公开实现的重点是：
|
||
|
||
- 定义工具 schema
|
||
- 把工具定义随上下文一起发给模型
|
||
- 观察模型是否发起 tool call，以及参数长什么样
|
||
|
||
它当前**不是**一个通用外部工具执行平台。
|
||
|
||
也就是说，这里重点不是：
|
||
|
||
- 代你真正调用天气 API
|
||
- 自动执行数据库查询
|
||
- 自动把工具结果串成完整业务流程
|
||
|
||
## 这项功能当前能做什么
|
||
|
||
在 `/#/pro/multi` 工作区中，你可以：
|
||
|
||
1. 打开工具管理
|
||
2. 定义工具名称、描述和参数 JSON Schema
|
||
3. 用支持 tool calling 的模型执行测试
|
||
4. 在结果区查看模型返回的 tool call
|
||
|
||
## 工具定义长什么样
|
||
|
||
典型结构如下：
|
||
|
||
```json
|
||
{
|
||
"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 下差异大不大
|
||
|
||
如果你已经知道自己最关心的问题，例如“经常漏字段”或“参数值经常乱填”，评估时可以加聚焦说明。
|
||
|
||
## 相关页面
|
||
|
||
- [多消息工作区](context.md)
|
||
- [变量工作区](variables.md)
|
||
- [测试与评估](../user/testing-evaluation.md)
|