603 lines
19 KiB
Markdown
603 lines
19 KiB
Markdown
# MCP 服务器评估指南
|
||
|
||
## 概述
|
||
|
||
本文档提供了为 MCP 服务器创建全面评估的指导。评估用于测试大语言模型能否仅通过所提供的工具,有效使用你的 MCP 服务器来回答真实、复杂的问题。
|
||
|
||
---
|
||
|
||
## 快速参考
|
||
|
||
### 评估要求
|
||
- 创建 10 个人类可读的问题
|
||
- 问题必须是只读、独立、非破坏性的
|
||
- 每个问题需要多次工具调用(可能多达数十次)
|
||
- 答案必须是单个可验证的值
|
||
- 答案必须稳定(不会随时间变化)
|
||
|
||
### 输出格式
|
||
```xml
|
||
<evaluation>
|
||
<qa_pair>
|
||
<question>你的问题在此</question>
|
||
<answer>单个可验证的答案</answer>
|
||
</qa_pair>
|
||
</evaluation>
|
||
```
|
||
|
||
---
|
||
|
||
## 评估的目的
|
||
|
||
衡量 MCP 服务器质量的关键不在于服务器实现工具的好坏或全面程度,而在于这些实现(输入/输出模式、文档字符串/描述、功能)能否让大语言模型——在没有其他上下文、仅能访问 MCP 服务器的情况下——回答真实且困难的问题。
|
||
|
||
## 评估概述
|
||
|
||
创建 10 个人类可读的问题,仅需通过只读、独立、非破坏性且幂等的操作即可回答。每个问题应具备以下特点:
|
||
- 真实
|
||
- 清晰简洁
|
||
- 无歧义
|
||
- 复杂,可能需要数十次工具调用或步骤
|
||
- 可用一个你事先确定的、可验证的单一值来回答
|
||
|
||
## 问题编写指南
|
||
|
||
### 核心要求
|
||
|
||
1. **问题必须是独立的**
|
||
- 每个问题不应依赖于任何其他问题的答案
|
||
- 不应假设在处理另一个问题之前已执行过写入操作
|
||
|
||
2. **问题必须仅涉及非破坏性和幂等的工具使用**
|
||
- 不应指示或要求通过修改状态来得出正确答案
|
||
|
||
3. **问题必须真实、清晰、简洁且复杂**
|
||
- 必须要求另一个大语言模型使用多个(可能数十个)工具或步骤才能回答
|
||
|
||
### 复杂度与深度
|
||
|
||
4. **问题必须要求深入探索**
|
||
- 考虑多跳问题,需要多个子问题和连续的工具调用
|
||
- 每一步应能从之前问题中发现的信息中获益
|
||
|
||
5. **问题可能需要大量翻页**
|
||
- 可能需要翻阅多页结果
|
||
- 可能需要查询旧数据(已过时 1-2 年)以找到小众信息
|
||
- 问题必须困难
|
||
|
||
6. **问题必须要求深入理解**
|
||
- 而非表层知识
|
||
- 可将复杂观点设为是非题,要求提供证据
|
||
- 可采用选择题形式,让大语言模型搜索不同的假设
|
||
|
||
7. **问题不能通过简单的关键词搜索解决**
|
||
- 不要包含目标内容中的特定关键词
|
||
- 使用同义词、相关概念或意译
|
||
- 需要多次搜索、分析多个相关项目、提取上下文,然后推导出答案
|
||
|
||
### 工具测试
|
||
|
||
8. **问题应对工具返回值进行压力测试**
|
||
- 可能使工具返回大型 JSON 对象或列表,压倒大语言模型
|
||
- 应要求理解多种数据形式:
|
||
- ID 和名称
|
||
- 时间戳和日期时间(月、日、年、秒)
|
||
- 文件 ID、名称、扩展名和 MIME 类型
|
||
- URL、GID 等
|
||
- 应探查工具返回所有有用数据形式的能力
|
||
|
||
9. **问题应主要反映真实的人类使用场景**
|
||
- 人类在 LLM 辅助下会关心的信息检索任务类型
|
||
|
||
10. **问题可能需要数十次工具调用**
|
||
- 这对上下文有限的大语言模型构成挑战
|
||
- 鼓励 MCP 服务器工具减少返回的信息量
|
||
|
||
11. **包含有歧义的问题**
|
||
- 可能有歧义,或者需要就调用哪些工具做出困难决策
|
||
- 迫使大语言模型可能犯错或误读
|
||
- 确保尽管存在歧义,仍然有一个可验证的单一答案
|
||
|
||
### 稳定性
|
||
|
||
12. **问题必须设计为答案不会变化**
|
||
- 不要问依赖动态"当前状态"的问题
|
||
- 例如,不要统计:
|
||
- 帖子的回复数
|
||
- 话题的回复数
|
||
- 频道的成员数
|
||
|
||
13. **不要让 MCP 服务器限制你创建问题的类型**
|
||
- 创建有挑战性的复杂问题
|
||
- 有些问题可能无法用现有的 MCP 服务器工具解决
|
||
- 问题可能需要特定的输出格式(日期时间 vs 纪元时间、JSON vs MARKDOWN)
|
||
- 问题可能需要数十次工具调用才能完成
|
||
|
||
## 答案编写指南
|
||
|
||
### 可验证性
|
||
|
||
1. **答案必须可通过直接字符串比较来验证**
|
||
- 如果答案可以用多种格式重写,需在问题中明确指定输出格式
|
||
- 例如:"使用 YYYY/MM/DD 格式。"、"回答 True 或 False。"、"回答 A、B、C 或 D,不要包含其他内容。"
|
||
- 答案应为单个可验证的值,例如:
|
||
- 用户 ID、用户名、显示名称、名、姓
|
||
- 频道 ID、频道名称
|
||
- 消息 ID、消息字符串
|
||
- URL、标题
|
||
- 数值数量
|
||
- 时间戳、日期时间
|
||
- 布尔值(用于是非题)
|
||
- 电子邮件地址、电话号码
|
||
- 文件 ID、文件名、文件扩展名
|
||
- 选择题答案
|
||
- 答案不得要求特殊格式化或复杂的结构化输出
|
||
- 答案将通过直接字符串比较来验证
|
||
|
||
### 可读性
|
||
|
||
2. **答案通常应优先采用人类可读的格式**
|
||
- 例如:名称、名、姓、日期时间、文件名、消息字符串、URL、是/否、真/假、a/b/c/d
|
||
- 而非不透明的 ID(虽然 ID 也是可接受的)
|
||
- 绝大多数答案应是人类可读的
|
||
|
||
### 稳定性
|
||
|
||
3. **答案必须稳定/不变**
|
||
- 查看旧内容(例如已结束的对话、已启动的项目、已回答的问题)
|
||
- 基于"已闭合"的概念创建问题,这些概念将始终返回相同的答案
|
||
- 问题可要求考虑一个固定的时间窗口,以规避非平稳答案
|
||
- 依赖不太可能变化的上下文
|
||
- 例如:如果要查找论文名称,应足够具体,以免与后来发表的论文混淆
|
||
|
||
4. **答案必须清晰且无歧义**
|
||
- 问题必须设计为存在单个明确的答案
|
||
- 答案应可通过使用 MCP 服务器工具推导得出
|
||
|
||
### 多样性
|
||
|
||
5. **答案必须多样化**
|
||
- 答案应为不同形式和格式的单个可验证值
|
||
- 用户相关概念:用户 ID、用户名、显示名称、名、姓、电子邮件地址、电话号码
|
||
- 频道相关概念:频道 ID、频道名称、频道主题
|
||
- 消息相关概念:消息 ID、消息字符串、时间戳、月、日、年
|
||
|
||
6. **答案不能是复杂结构**
|
||
- 不能是一个值列表
|
||
- 不能是一个复杂对象
|
||
- 不能是 ID 或字符串列表
|
||
- 不能是自然语言文本
|
||
- 除非答案可以通过直接字符串比较进行直接验证
|
||
- 并且可以被实际复现
|
||
- 大语言模型不太可能以其他任何顺序或格式返回相同的列表
|
||
|
||
## 评估流程
|
||
|
||
### 第 1 步:文档审查
|
||
|
||
阅读目标 API 的文档以了解:
|
||
- 可用的端点及功能
|
||
- 如果存在歧义,从网络获取更多信息
|
||
- 尽可能并行执行此步骤
|
||
- 确保每个子代理仅从文件系统或网络上查阅文档
|
||
|
||
### 第 2 步:工具审查
|
||
|
||
列出 MCP 服务器中可用的工具:
|
||
- 直接检查 MCP 服务器
|
||
- 了解输入/输出模式、文档字符串和描述
|
||
- 在此阶段不要调用工具本身
|
||
|
||
### 第 3 步:建立理解
|
||
|
||
重复第 1 步和第 2 步,直到你有了良好的理解:
|
||
- 多次迭代
|
||
- 思考你想要创建的任务类型
|
||
- 完善你的理解
|
||
- 在任何阶段都不应阅读 MCP 服务器实现的代码
|
||
- 运用你的直觉和理解来创建合理、真实但极具挑战性的任务
|
||
|
||
### 第 4 步:只读内容审查
|
||
|
||
在理解 API 和工具之后,使用 MCP 服务器的工具:
|
||
- 仅通过只读和非破坏性操作来检查内容
|
||
- 目标:确定特定内容(例如用户、频道、消息、项目、任务)以创建真实的问题
|
||
- 不应调用任何会修改状态的工具
|
||
- 不得阅读 MCP 服务器实现的代码
|
||
- 使用各个子代理进行独立的探索,并行执行此步骤
|
||
- 确保每个子代理仅执行只读、非破坏性和幂等的操作
|
||
- 注意:某些工具可能返回大量数据,导致上下文溢出
|
||
- 进行增量式、小规模且有目标的工具调用来探索
|
||
- 在所有工具调用请求中,使用 `limit` 参数限制结果数量(<10)
|
||
- 使用分页
|
||
|
||
### 第 5 步:任务生成
|
||
|
||
在检查内容后,创建 10 个人类可读的问题:
|
||
- 大语言模型应能使用 MCP 服务器回答这些问题
|
||
- 遵循上述所有问题和答案的编写指南
|
||
|
||
## 输出格式
|
||
|
||
每个问答对包含一个问题和一个答案。输出应为具有以下结构的 XML 文件:
|
||
|
||
```xml
|
||
<evaluation>
|
||
<qa_pair>
|
||
<question>找到在 2024 年第二季度创建、完成任务数量最多的项目。项目名称是什么?</question>
|
||
<answer>网站改版</answer>
|
||
</qa_pair>
|
||
<qa_pair>
|
||
<question>搜索在 2024 年 3 月关闭的、标记为"bug"的问题。哪个用户关闭的问题最多?请提供其用户名。</question>
|
||
<answer>sarah_dev</answer>
|
||
</qa_pair>
|
||
<qa_pair>
|
||
<question>查找修改了 /api 目录下文件、并在 2024 年 1 月 1 日至 1 月 31 日期间合并的拉取请求。有多少个不同的贡献者参与了这些 PR?</question>
|
||
<answer>7</answer>
|
||
</qa_pair>
|
||
<qa_pair>
|
||
<question>找到在 2023 年之前创建、获得星标数最多的仓库。仓库名称是什么?</question>
|
||
<answer>data-pipeline</answer>
|
||
</qa_pair>
|
||
</evaluation>
|
||
```
|
||
|
||
## 评估示例
|
||
|
||
### 好的问题
|
||
|
||
**示例 1:需要深入探索的多跳问题(GitHub MCP)**
|
||
```xml
|
||
<qa_pair>
|
||
<question>找到在 2023 年第三季度归档、且此前是该组织中被 fork 最多的项目仓库。该仓库使用的主要编程语言是什么?</question>
|
||
<answer>Python</answer>
|
||
</qa_pair>
|
||
```
|
||
|
||
这个问题好的原因在于:
|
||
- 需要多次搜索才能找到已归档的仓库
|
||
- 需要确定在归档前哪个仓库的 fork 数最多
|
||
- 需要查看仓库详情以获取语言信息
|
||
- 答案是一个简单、可验证的值
|
||
- 基于历史(已闭合)数据,不会变化
|
||
|
||
**示例 2:需要理解上下文而无关键词匹配(项目管理 MCP)**
|
||
```xml
|
||
<qa_pair>
|
||
<question>找到在 2023 年底完成、专注于改善客户引导的倡议项目。项目负责人在完成后创建了一份回顾文档。当时该负责人的职位是什么?</question>
|
||
<answer>产品经理</answer>
|
||
</qa_pair>
|
||
```
|
||
|
||
这个问题好的原因在于:
|
||
- 没有使用具体项目名称("专注于改善客户引导的倡议项目")
|
||
- 需要从特定时间范围内找到已完成的项目
|
||
- 需要确定项目负责人及其职位
|
||
- 需要从回顾文档中理解上下文
|
||
- 答案是人类可读且稳定的
|
||
- 基于已完成的工作(不会变化)
|
||
|
||
**示例 3:需要多步聚合的复杂问题(问题追踪器 MCP)**
|
||
```xml
|
||
<qa_pair>
|
||
<question>在 2024 年 1 月报告的所有标记为"严重"优先级的 Bug 中,哪个受理人在 48 小时内解决了其被分配 Bug 的最高百分比?请提供该受理人的用户名。</question>
|
||
<answer>alex_eng</answer>
|
||
</qa_pair>
|
||
```
|
||
|
||
这个问题好的原因在于:
|
||
- 需要按日期、优先级和状态过滤 Bug
|
||
- 需要按受理人分组并计算解决率
|
||
- 需要理解时间戳以确定 48 小时窗口
|
||
- 测试分页功能(可能需要处理大量 Bug)
|
||
- 答案是单一用户名
|
||
- 基于特定时间段的历史数据
|
||
|
||
**示例 4:需要跨多种数据类型综合(CRM MCP)**
|
||
```xml
|
||
<qa_pair>
|
||
<question>找到在 2023 年第四季度从 Starter 方案升级到 Enterprise 方案、且年合同价值最高的客户账户。该账户属于哪个行业?</question>
|
||
<answer>医疗健康</answer>
|
||
</qa_pair>
|
||
```
|
||
|
||
这个问题好的原因在于:
|
||
- 需要理解订阅套餐变更
|
||
- 需要在特定时间范围内识别升级事件
|
||
- 需要比较合同价值
|
||
- 必须获取账户行业信息
|
||
- 答案简单且可验证
|
||
- 基于已完成的过往交易
|
||
|
||
### 不好的问题
|
||
|
||
**示例 1:答案随时间变化**
|
||
```xml
|
||
<qa_pair>
|
||
<question>当前分配给工程团队的未解决问题有多少?</question>
|
||
<answer>47</answer>
|
||
</qa_pair>
|
||
```
|
||
|
||
这个问题不好的原因在于:
|
||
- 答案会随着问题的创建、关闭或重新分配而变化
|
||
- 不是基于稳定/不变的数据
|
||
- 依赖动态的"当前状态"
|
||
|
||
**示例 2:关键词搜索过于简单**
|
||
```xml
|
||
<qa_pair>
|
||
<question>找到标题为"Add authentication feature"的拉取请求,并告诉我谁创建的。</question>
|
||
<answer>developer123</answer>
|
||
</qa_pair>
|
||
```
|
||
|
||
这个问题不好的原因在于:
|
||
- 可以通过精确标题的关键词搜索直接解决
|
||
- 不需要深入探索或理解
|
||
- 无需综合或分析
|
||
|
||
**示例 3:答案格式有歧义**
|
||
```xml
|
||
<qa_pair>
|
||
<question>列出所有以 Python 为主要编程语言的仓库。</question>
|
||
<answer>repo1, repo2, repo3, data-pipeline, ml-tools</answer>
|
||
</qa_pair>
|
||
```
|
||
|
||
这个问题不好的原因在于:
|
||
- 答案是一个列表,可能以任意顺序返回
|
||
- 难以通过直接字符串比较来验证
|
||
- 大语言模型可能以不同格式输出(JSON 数组、逗号分隔、换行分隔)
|
||
- 更好的做法是询问具体的聚合值(计数)或最高值(最多星标)
|
||
|
||
## 验证流程
|
||
|
||
创建评估后:
|
||
|
||
1. **检查 XML 文件** 以了解模式
|
||
2. **加载每个任务指令**,并使用 MCP 服务器和工具并行找出正确答案——亲自尝试解决问题
|
||
3. **标记所有需要写入或破坏性操作的操作**
|
||
4. **汇总所有正确答案**,替换文档中的任何错误答案
|
||
5. **移除所有需要写入或破坏性操作的 `<qa_pair>`**
|
||
|
||
请记住并行求解任务以避免上下文溢出,然后在最后汇总所有答案并对文件进行修改。
|
||
|
||
## 创建高质量评估的提示
|
||
|
||
1. **在生成任务之前深入思考并提前规划**
|
||
2. **在有机会时进行并行处理** 以加快速度并管理上下文
|
||
3. **聚焦于真实的使用场景**——人类真正想要完成的任务
|
||
4. **创建有挑战性的问题** 以测试 MCP 服务器能力的极限
|
||
5. **确保稳定性**——使用历史数据和已闭合的概念
|
||
6. **验证答案**——亲自使用 MCP 服务器工具解决问题
|
||
7. **根据过程中的发现迭代并优化**
|
||
|
||
---
|
||
|
||
# 运行评估
|
||
|
||
创建评估文件后,你可以使用提供的评估框架来测试你的 MCP 服务器。
|
||
|
||
## 环境设置
|
||
|
||
1. **安装依赖**
|
||
|
||
```bash
|
||
pip install -r scripts/requirements.txt
|
||
```
|
||
|
||
或手动安装:
|
||
```bash
|
||
pip install anthropic mcp
|
||
```
|
||
|
||
2. **设置 API 密钥**
|
||
|
||
```bash
|
||
export ANTHROPIC_API_KEY=your_api_key_here
|
||
```
|
||
|
||
## 评估文件格式
|
||
|
||
评估文件使用 XML 格式,包含 `<qa_pair>` 元素:
|
||
|
||
```xml
|
||
<evaluation>
|
||
<qa_pair>
|
||
<question>找到在 2024 年第二季度创建、完成任务数量最多的项目。项目名称是什么?</question>
|
||
<answer>网站改版</answer>
|
||
</qa_pair>
|
||
<qa_pair>
|
||
<question>搜索在 2024 年 3 月关闭的、标记为"bug"的问题。哪个用户关闭的问题最多?请提供其用户名。</question>
|
||
<answer>sarah_dev</answer>
|
||
</qa_pair>
|
||
</evaluation>
|
||
```
|
||
|
||
## 运行评估
|
||
|
||
评估脚本(`scripts/evaluation.py`)支持三种传输类型:
|
||
|
||
**重要说明:**
|
||
- **stdio 传输**:评估脚本会自动为你启动并管理 MCP 服务器进程。请勿手动运行服务器。
|
||
- **SSE/HTTP 传输**:你必须在运行评估之前单独启动 MCP 服务器。脚本会连接到指定 URL 上已运行的服务器。
|
||
|
||
### 1. 本地 STDIO 服务器
|
||
|
||
适用于本地运行的 MCP 服务器(脚本自动启动服务器):
|
||
|
||
```bash
|
||
python scripts/evaluation.py \
|
||
-t stdio \
|
||
-c python \
|
||
-a my_mcp_server.py \
|
||
evaluation.xml
|
||
```
|
||
|
||
使用环境变量:
|
||
|
||
```bash
|
||
python scripts/evaluation.py \
|
||
-t stdio \
|
||
-c python \
|
||
-a my_mcp_server.py \
|
||
-e API_KEY=abc123 \
|
||
-e DEBUG=true \
|
||
evaluation.xml
|
||
```
|
||
|
||
### 2. Server-Sent Events(SSE)
|
||
|
||
适用于基于 SSE 的 MCP 服务器(需先启动服务器):
|
||
|
||
```bash
|
||
python scripts/evaluation.py \
|
||
-t sse \
|
||
-u https://example.com/mcp \
|
||
-H "Authorization: Bearer token123" \
|
||
-H "X-Custom-Header: value" \
|
||
evaluation.xml
|
||
```
|
||
|
||
### 3. HTTP(Streamable HTTP)
|
||
|
||
适用于基于 HTTP 的 MCP 服务器(需先启动服务器):
|
||
|
||
```bash
|
||
python scripts/evaluation.py \
|
||
-t http \
|
||
-u https://example.com/mcp \
|
||
-H "Authorization: Bearer token123" \
|
||
evaluation.xml
|
||
```
|
||
|
||
## 命令行选项
|
||
|
||
```
|
||
usage: evaluation.py [-h] [-t {stdio,sse,http}] [-m MODEL] [-c COMMAND]
|
||
[-a ARGS [ARGS ...]] [-e ENV [ENV ...]] [-u URL]
|
||
[-H HEADERS [HEADERS ...]] [-o OUTPUT]
|
||
eval_file
|
||
|
||
positional arguments:
|
||
eval_file 评估 XML 文件的路径
|
||
|
||
optional arguments:
|
||
-h, --help 显示帮助信息
|
||
-t, --transport 传输类型:stdio、sse 或 http(默认:stdio)
|
||
-m, --model 要使用的 Claude 模型(默认:claude-3-7-sonnet-20250219)
|
||
-o, --output 报告输出文件(默认:输出到 stdout)
|
||
|
||
stdio options:
|
||
-c, --command 运行 MCP 服务器的命令(例如:python、node)
|
||
-a, --args 命令的参数(例如:server.py)
|
||
-e, --env 环境变量,格式为 KEY=VALUE
|
||
|
||
sse/http options:
|
||
-u, --url MCP 服务器 URL
|
||
-H, --header HTTP 头,格式为 'Key: Value'
|
||
|
||
## 输出
|
||
|
||
评估脚本会生成一份详细报告,包括:
|
||
|
||
- **汇总统计**:
|
||
- 准确率(正确数/总数)
|
||
- 平均任务耗时
|
||
- 每任务平均工具调用次数
|
||
- 工具调用总数
|
||
|
||
- **每项任务的结果**:
|
||
- 提示语及预期响应
|
||
- 智能体的实际响应
|
||
- 答案是否正确(✅/❌)
|
||
- 耗时及工具调用详情
|
||
- 智能体对其方法的总结
|
||
- 智能体对工具的反馈
|
||
|
||
### 将报告保存到文件
|
||
|
||
```bash
|
||
python scripts/evaluation.py \
|
||
-t stdio \
|
||
-c python \
|
||
-a my_server.py \
|
||
-o evaluation_report.md \
|
||
evaluation.xml
|
||
```
|
||
|
||
## 完整工作流程示例
|
||
|
||
以下是创建和运行评估的完整示例:
|
||
|
||
1. **创建评估文件**(`my_evaluation.xml`):
|
||
|
||
```xml
|
||
<evaluation>
|
||
<qa_pair>
|
||
<question>找到在 2024 年 1 月创建问题最多的用户。该用户的用户名是什么?</question>
|
||
<answer>alice_developer</answer>
|
||
</qa_pair>
|
||
<qa_pair>
|
||
<question>在 2024 年第一季度合并的所有拉取请求中,哪个仓库的数量最多?请提供仓库名称。</question>
|
||
<answer>backend-api</answer>
|
||
</qa_pair>
|
||
<qa_pair>
|
||
<question>找到在 2023 年 12 月完成、且从开始到结束持续时间最长的项目。它花了多少天?</question>
|
||
<answer>127</answer>
|
||
</qa_pair>
|
||
</evaluation>
|
||
```
|
||
|
||
2. **安装依赖**:
|
||
|
||
```bash
|
||
pip install -r scripts/requirements.txt
|
||
export ANTHROPIC_API_KEY=your_api_key
|
||
```
|
||
|
||
3. **运行评估**:
|
||
|
||
```bash
|
||
python scripts/evaluation.py \
|
||
-t stdio \
|
||
-c python \
|
||
-a github_mcp_server.py \
|
||
-e GITHUB_TOKEN=ghp_xxx \
|
||
-o github_eval_report.md \
|
||
my_evaluation.xml
|
||
```
|
||
|
||
4. **查看报告**(位于 `github_eval_report.md`),以:
|
||
- 查看哪些问题通过/未通过
|
||
- 阅读智能体对你工具的反馈
|
||
- 确定需要改进的方面
|
||
- 迭代优化你的 MCP 服务器设计
|
||
|
||
## 故障排除
|
||
|
||
### 连接错误
|
||
|
||
如果遇到连接错误:
|
||
- **STDIO**:确认命令和参数是否正确
|
||
- **SSE/HTTP**:检查 URL 是否可以访问,请求头是否正确
|
||
- 确保所有必需的 API 密钥已在环境变量或请求头中设置
|
||
|
||
### 准确率低
|
||
|
||
如果许多评估未通过:
|
||
- 查看每项任务中智能体的反馈
|
||
- 检查工具描述是否清晰全面
|
||
- 确认输入参数是否有完善的文档说明
|
||
- 考虑工具返回的数据是否过多或过少
|
||
- 确保错误消息具有可操作性
|
||
|
||
### 超时问题
|
||
|
||
如果任务超时:
|
||
- 使用能力更强的模型(例如 `claude-3-7-sonnet-20250219`)
|
||
- 检查工具是否返回了过多数据
|
||
- 确认分页功能是否正常工作
|
||
- 考虑简化复杂问题
|