Bob's Personal Blog

记录想法
等待被实现的那一天

关于产品、技术、设计的一切零碎思考。不成体系,但都是真实的判断。

Started · 2026-03-20  ·  Beacon ✦

360° 耳机摄像头 — 第一视角记录设备

第一视角 · First Person POV

做一副耳机,两侧各装一个 360° 摄像头,实时合成完整画面。用户可以"回看"自己第一视角记录的一切。

为什么不做眼镜

  • 刚做完摘镜手术,戴眼镜不舒服
  • 眼镜形态拍照显得怪异,社会接受度低
  • 耳机本来就要戴,加摄像头增量成本低

产品形态

  • 轻量化耳机 + 双侧 360° 摄像头
  • 不需要屏幕,重点在"记录"而非"实时显示"
  • 配合手机 App 回放/剪辑第一视角内容
  • 具备麦克风,支持语音交互

核心差异化

GoPro 是第三方视角,这个是第一视角 戴着耳机不突兀 沉浸式第一视角,有情感价值

技术参考

  • Insta360:拼接算法消费级最强,可参考其芯片方案
  • 实时拼接:瓶颈在算力,低延迟是关键
  • 芯片方向:高通/苹果 AR 眼镜芯片路线
  • 麦克风:骨传导麦克风已成熟

待研究

  • 摄像头规格选型(消费级 360° vs 双鱼眼拼接)
  • 芯片算力需求(实时拼接 vs 本地/云端处理)
  • 续航与重量平衡
  • 数据存储方案
  • 隐私/法律问题(公共场所拍摄)

模型切换与工具敏感度差异

🤖 模型 LLM Claude / Gemini / GPT 🛠️ 工具 Tools MCP / Function Call send_message ⚠️ 调用 结果 ⚡ SDK / Runtime <internal> 标签 preset 差异 🔴 result 用户 User 重复发送 ⚠️ 工具语义 × SDK preset × 模型敏感度 = 跨模型兼容问题

Claude Code SDK 切到 Minimax M2.7 后,send_message 工具被调用两次:模型主动调用发一条,SDK 又走标准路径发一条。

根因

工具名 send_message 太模糊,语义是"发一条消息",不是"发进度通知"。不同模型/SDK 组合对 tool result 的处理策略不同:

  • Claude Code SDK + claude_code preset:知道用 <internal> 标签包裹 tool result → formatOutbound() stripping 后不发送
  • Minimax M2.7 + 无 claude_code preset:没有 <internal> 抑制逻辑 → result 直接发出

Fix

工具改名:send_messagesend_progress_update,描述加了 explicit anti-pattern:"不要发了 progress update 之后又在 final answer 里重复"。

关键洞察:不同模型对工具名称、描述措辞的敏感度不一样。换模型不只是换个 API key,工具语义和 prompt 处理逻辑都需要跟着调。这是一个需要持续维护的跨模型适配层

待验证

  • Minimax M2.7 切换后是否还有重复发送问题
  • 其他 MCP 工具(send_file、schedule_task 等)是否有类似问题
  • Skill 工具在不同模型下的触发准确率差异
📖 MSR: Tool-space interference in the MCP era

调研发现:业界 Agent 测试方法

没有银弹——没有任何一个 benchmark 能全面覆盖 agent 能力,必须组合使用。

Benchmark 测什么 关键数据
SWE-bench 真实 GitHub Issue 修复 Claude Code 80.9%
TAU2-Bench 工具调用准确性 专门测 function calling
MCP-AgentBench MCP 工具场景 33 servers, 188 tools, 600 queries(2025)
MCP-Bench 多步 MCP 任务 28 servers, 250 tools(ICLR 2026)
Sigmabench 真实代码库表现 同模型差 30-60% ⚠️

落地建议

  • 给每个 MCP 工具写"正确输入 → 期望输出"的单元测试
  • 切模型后跑同一套 prompt,看是否有行为差异
  • MCP-AgentBench 框架可复用到 Nanoclaw 的 7 个 MCP server
  • 在 Nanoclaw 自己代码库上建立 eval 数据集