vault backup: 2026-03-20 18:20:17

07-Other/AI/AI Agent/MCP & Skill.md

@@ -388,6 +388,8 @@ app.use("/mcp", async (c, next) => {
 - 编程类
 	- [x] ***using-superpowers***：强制Agent真正发挥高级能力。 #优化器
 	- [x] acpx：外部工具桥接器，可以用来控制ClaudeCode等编程工具，还需要额外配置。  #编程
+- 沟通类
+	- [x] [openclaw-a2a-gateway](https://github.com/win4r/openclaw-a2a-gateway):多物理实例Agent沟通工具，**缺点：无有上一次对话的上下文**。
 - 进阶工具
 	- [ ] brainstorming：一个关键词生成几十个独特角度和多种假设场景。 #创意生成器
 	- [ ] copywriting：优化表达、打磨语调，不依赖老掉牙的一键生成模板。 #文字工匠

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

@@ -0,0 +1,200 @@
+# 前言
+- 搜索类
+	- [[#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 更合适