200 lines
9.6 KiB
Markdown
200 lines
9.6 KiB
Markdown
# 前言
|
||
- 搜索类
|
||
- [[#OpenClaw原生方案/Jina / TinySearch 测试结果]]
|
||
-
|
||
# OpenClaw原生方案/Jina / TinySearch 测试结果
|
||
|
||
已获取足够信息，下面是总结：
|
||
Tavily vs Jina Reader API 对比
|
||
**Jina Reader**
|
||
**优点：**
|
||
- 极简使用：只需在 URL 前加 r.jina.ai/ 即可获取干净 Markdown
|
||
- 提供搜索端点（s.jina.ai）和事实验证端点（g.jina.ai）
|
||
- 免费额度可用，上手零门槛
|
||
- 输出 LLM 友好的 Markdown，适合快速内容提取
|
||
**缺点：**
|
||
- 只能处理单页，无法爬取整站
|
||
- 输出为原始 Markdown，无结构化 JSON 提取
|
||
- 无 schema 验证 / 类型安全
|
||
- 免费层有速率限制，付费定价不够透明
|
||
- 缺少 LangChain 等 AI Agent 框架的原生集成
|
||
|
||
**Tavily**
|
||
**优点：**
|
||
- 专为 AI/RAG 场景设计的搜索 API，返回带来源引用的结果
|
||
- 与 LangChain、LlamaIndex 等框架原生集成
|
||
- 结果包含摘要和来源 URL，适合需要 citation 的场景
|
||
- 搜索质量针对 AI Agent 优化
|
||
**缺点：**
|
||
- 侧重"搜索发现"，不擅长深度网页内容提取
|
||
- 不提供将网页转为干净 Markdown 的能力（需配合其他工具）
|
||
- 免费额度有限，重度使用成本较高
|
||
|
||
| | | |
|
||
| -------- | -------------- | --------------- |
|
||
| 维度 | Jina Reader | Tavily |
|
||
| 核心能力 | 网页→Markdown 转换 | AI 搜索引擎 |
|
||
| 适用场景 | 单页内容提取、RAG 输入 | 搜索发现、带引用的问答 |
|
||
| 结构化输出 | ❌ | ✅（JSON） |
|
||
| Agent 集成 | 弱 | 强（LangChain 原生） |
|
||
| 内容提取深度 | 强 | 弱 |
|
||
选择建议： 需要提取网页内容用 Jina Reader；需要搜索互联网并获取带引用的答案用 Tavily。两者互补，常一起使用。
|
||
|
||
## 测试
|
||
测试题目（3个场景）
|
||
|
||
| | | |
|
||
|---|---|---|
|
||
|#|场景|问题|
|
||
|T1|简单事实搜索|"2026年3月最新的AI行业大事件有哪些？列出3个"|
|
||
|T2|深度内容提取|"提取 https://github.com/anthropics/claude-code 页面的主要功能介绍"|
|
||
|T3|多源聚合研究|"对比 Tavily 和 Jina Reader 这两个搜索API的优缺点"|
|
||
对比方案（每题3种）
|
||
|
||
| | |
|
||
| ------ | ------------------------------------ |
|
||
| 方案 | 工具 |
|
||
| 默认 | webfetch / websearch（内置工具） |
|
||
| Tavily | tavily-search / tavily-extract skill |
|
||
| Jina | jina-reader skill |
|
||
共 9 个子任务
|
||
|
||
### 结果
|
||
所有 9 个子任务都已完成，现在发送汇总报告：
|
||
- Tavily最省 token（总计 30,360），速度也最快
|
||
- 🥈 默认 web_fetch 居中（33,407），单页提取场景最优
|
||
- 🥉 Jina Reader token 消耗最高（46,544），因为返回完整页面内容导致 input tokens 过大。
|
||
|
||
搜索/爬虫方案 Token 消耗对比报告
|
||
- 模型: netease/claude-opus-4-6
|
||
- 方案: 默认(web_fetch) / Tavily / Jina Reader
|
||
- 测试时间: 2026-03-10 15:15~15:22
|
||
|
||
📊 **Token 消耗数据**
|
||
T1: 简单事实搜索 — "2026年3月最新AI行业大事件，列出3个"
|
||
|
||
| | | | |
|
||
| -------------- | ------------ | --- | ------- |
|
||
| 方案 | Total Tokens | 耗时 | 相对消耗 |
|
||
| 默认 (web_fetch) | 10,588 | 21s | 基准 |
|
||
| Tavily | 8,340 | 20s | ⬇️ -21% |
|
||
| Jina Reader | 17,969 | 47s | ⬆️ +70% |
|
||
T2: 深度内容提取 — "提取 claude-code GitHub 页面功能介绍"
|
||
|
||
| | | | |
|
||
| -------------- | ------------ | --- | ------- |
|
||
| 方案 | Total Tokens | 耗时 | 相对消耗 |
|
||
| 默认 (web_fetch) | 9,171 | 14s | 基准 |
|
||
| Tavily | 10,897 | 14s | ⬆️ +19% |
|
||
| Jina Reader | 16,507 | 18s | ⬆️ +80% |
|
||
T3: 多源聚合研究 — "对比 Tavily 和 Jina Reader 的优缺点"
|
||
|
||
| | | | |
|
||
|---|---|---|---|
|
||
|方案|Total Tokens|耗时|相对消耗|
|
||
|默认 (web_fetch)|13,648|37s|基准|
|
||
|Tavily|11,123|32s|⬇️ -19%|
|
||
|Jina Reader|12,068|62s|⬇️ -12%|
|
||
📈 汇总统计
|
||
|
||
| | | | | |
|
||
| -------------- | ------- | ----------- | ---- | --- |
|
||
| 方案 | 总 Token | 平均 Token/任务 | 平均耗时 | 排名 |
|
||
| Tavily | 30,360 | 10,120 | 22s | 🥇 |
|
||
| 默认 (web_fetch) | 33,407 | 11,136 | 24s | 🥈 |
|
||
| Jina Reader | 46,544 | 15,515 | 42s | 🥉 |
|
||
💡 结论与建议
|
||
1. Token 效率: Tavily 最省 token（比默认少 9%，比 Jina 少 35%）
|
||
2. 速度: Tavily ≈ 默认 > Jina（Jina 平均耗时近 2 倍）
|
||
3. Jina token 高的原因: Jina 返回完整页面 Markdown 内容，数据量大，导致 LLM 处理的 input tokens 显著增多
|
||
4. Tavily token 低的原因: 返回精炼的摘要+结构化 JSON，LLM 无需处理大量原始内容
|
||
|
||
推荐策略
|
||
1. 搜索场景 → 优先用 Tavily（token 省、速度快）
|
||
2. 单页提取 → 默认 web_fetch 已够用（最低 token）
|
||
3. JS 渲染页面 / IP 保护 → 用 Jina Reader（能力更强但 token 消耗更高）
|
||
4. 深度研究 → Tavily research API（一次调用搞定多角度分析）
|
||
|
||
根据之前 9 个子任务的实际输出，我来评估各方案的内容质量。ch 质量最高**（平均 4.7/5）— 尤其在时效性和深度研究场景表现最好
|
||
💰 Tavily 性价比最高 — token 最省且结构化提取能力最强
|
||
📄 Jina Reader 适合特殊场景 — 质量和效率都偏低，但在 JS 渲染和反爬场景有独特价值
|
||
最佳策略：Tavily 搜索发现 + web_fetch 深度提取，按需用 Jina 处理特殊页面。
|
||
|
||
```
|
||
质量高 │ ✅默认
|
||
│ ✅Tavily
|
||
│
|
||
质量低 │ ✅Jina
|
||
└──────────────────
|
||
Token少 Token多
|
||
```
|
||
|
||
|
||
# A2A协议测试
|
||
## 本机Agent讨论测试
|
||
OpenClaw 自带方案 vs A2A 方案 Token 消耗对比
|
||
三方讨论：Wendy(主持) + Wendy_PM + mozhixin
|
||
主题：「AI Agent 在游戏开发中的最佳实践」| 三轮对话
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
🔹**方案一：OpenClaw 自带方案**
|
||
**第1轮：AI Agent 在策划文档编写中的价值**
|
||
• Wendy_PM：「效率杠杆——碎片化想法→结构化文档、配表和验收标准，自动一致性检查」
|
||
→ input=30,413 | output=92 | total=30,505 | 5.1s
|
||
• mozhixin：「结构化提效——模糊想法→规范格式，省去排版和查漏补缺体力活」
|
||
→ input=27,071 | output=105 | total=27,176 | 6.0s
|
||
|
||
**第2轮：AI Agent 在 QA 测试自动化中的应用**
|
||
• Wendy_PM：「自动生成测试用例、模拟玩家行为、版本回归、日志分析、数值校验」
|
||
→ input=30,610 | output=145 | total=30,755 | 8.5s
|
||
• mozhixin：「配表校验、用例生成、回归检测、日志分析」
|
||
→ input=27,346 | output=178 | total=27,524 | 8.3s
|
||
|
||
**第3轮：落地最大挑战**
|
||
• Wendy_PM：「信任校准——建立人机协作SOP，AI负责草稿校验，人负责决策把关」
|
||
→ input=30,923 | output=124 | total=31,047 | 7.8s
|
||
• mozhixin：「信任与容错——关键是建立人机协作的安全网」
|
||
→ input=27,615 | output=160 | total=27,775 | 7.4s
|
||
✅ 方案一总计：input=174,978 | output=804 | total=175,782
|
||
PM 小计：91,946+361=92,307 | MZ 小计：82,032+443=82,475
|
||
特点：同一 session 三轮连续对话，上下文累积
|
||
|
||
🔸 **方案二：A2A 方案**
|
||
**第1轮：AI Agent 在策划文档编写中的价值**
|
||
• Wendy_PM：「结构化提效——口语化想法→配表结构、验收标准和边界条件」
|
||
→ input=29,305 | output=107 | total=29,412
|
||
• mozhixin：「结构化和一致性——人出脑子，猫出爪子🐱」
|
||
→ input=27,071 | output=115 | total=27,186
|
||
|
||
**第2轮：AI Agent 在 QA 测试自动化中的应用**
|
||
• Wendy_PM：「测试用例生成、回归自动化、视觉识别UI异常、压力测试、崩溃日志分类」
|
||
→ input=29,347 | output=132 | total=29,479
|
||
• mozhixin：「自动生成测试用例、回归脚本维护、日志异常检测、数值平衡验证」
|
||
→ input=27,108 | output=209 | total=27,317
|
||
|
||
**第3轮：落地最大挑战**
|
||
• Wendy_PM：「信任校准——明确Agent能力边界，建立人机协作质检标准」
|
||
→ input=29,334 | output=104 | total=29,438
|
||
• mozhixin：「信任与容错——出错时能秒回滚，安全网比AI能力更关键」
|
||
→ input=27,119 | output=141 | total=27,260
|
||
✅ 方案二总计：input=169,284 | output=808 | total=170,092
|
||
PM 小计：87,986+343=88,329 | MZ 小计：81,298+465=81,763
|
||
特点：每轮独立 session，无上下文累积
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
📈 最终对比
|
||
|
||
| | | | |
|
||
|---|---|---|---|
|
||
|指标|自带方案|A2A方案|差异|
|
||
|总 Token|175,782|170,092|A2A 少 5,690 (3.2%)|
|
||
|PM Input|91,946|87,986|A2A 少 3,960 (4.3%)|
|
||
|MZ Input|82,032|81,298|A2A 少 734 (0.9%)|
|
||
|总 Output|804|808|基本持平|
|
||
|会话连续性|✅ 有|❌ 无||
|
||
|跨服务器|❌|✅||
|
||
关键结论：
|
||
1. Token 消耗差异很小（约3%），底层调用同一 agent，系统提示词是大头
|
||
2. 自带方案的 input 略多是因为会话历史累积（每轮多几百 token 的上下文）
|
||
3. A2A 每轮是独立 session，没有历史累积所以 input 稳定
|
||
4. 但 A2A 也因此丢失了多轮上下文——agent 看不到之前的讨论
|
||
5. A2A 的真正价值不在省 Token，而在跨机器/跨网络的 Agent 互联
|
||
6. 如果需要多轮连续讨论，自带方案更优（有上下文）；如果是跨服务器单次请求，A2A 更合适 |