BlueRoseNote/07-Other/AI/AI Agent/OpenClaw/实验结果/一些实验结果.md

前言

• 搜索类
  • #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 更合适