# 前言
- 搜索类
	- [[#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 更合适