本文记录我参加 GPASS AI 眼镜智能体开发者大赛的完整开发过程，包括方案选型、技术实现中的坑和解决方案。希望对想在百宝箱平台开发AI眼镜应用的开发者有参考价值。

前言：为什么做"社交记忆助手"

参加这个比赛之前，我一直在想一个问题：AI眼镜能做什么手机做不了的事？

答案不是"更大的屏幕"或"更酷的交互"，而是隐蔽性和即时性。

想象一个商务场景：你在交流会上遇到一个人，对方热情地跟你打招呼，但你完全想不起他是谁。这时候：

• 掏手机查通讯录？太刻意了
• 问对方"你是？"？太尴尬了
• 戴着AI眼镜拍一张？对方毫无察觉，AI在耳边告诉你"这是李明，智联科技CTO，上次聊了合作"

这就是"知面"的由来——一个让你再也不忘任何人的社交记忆外脑。

---

技术选型：为什么选百宝箱

百宝箱是蚂蚁集团的智能体低代码平台，最大的优势是：它直接对接了GPASS智能眼镜的硬件能力。

不需要自己处理语音识别、TTS、摄像头调用这些底层问题，只需要关注业务逻辑：

• 语音输入？开始节点自动注入
• 拍照？拖一个"眼镜设备拍照采集"节点
• 语音回复？"直接回复"节点自动走TTS

开发模式就是：拖节点 → 写 prompt → 连线 → 测试。

---

架构设计：五条链路搞定所有场景

经过反复推敲，我把所有交互归纳为5个意图：

记录(RECORD) → 从对话中提取人物信息
建档(REGISTER) → 拍照注册人脸
识人(RECOGNIZE) → 拍照搜索人脸 + 召回档案
回忆(RECALL) → 语音查询某人信息
更新(UPDATE) → 修改已有档案

整个工作流就是一个入口（意图识别）+ 分支路由 + 5条独立链路。逻辑清晰，互不干扰。

---

踩坑记录

坑1：眼镜是持续监听的

一开始我按照传统App的思路设计——用户按镜腿触发动作。后来发现GPASS眼镜是持续监听模式，用户每说一句话就触发一轮工作流。

这意味着：

• 你跟别人聊天的每一句话都会进入工作流
• 意图识别必须能区分"对AI的指令"和"跟别人聊天"
• 大部分时候应该保持静默

解决方案：意图识别prompt里加了严格的排除规则，普通陈述句/寒暄一律归为OTHER，OTHER链路只输出一个句号（不会被TTS播报）。

坑2：阿里云人脸API不接受非OSS图片

阿里云视觉智能的人脸搜索API，常规方法要求图片必须是上海地域OSS链接。但GPASS拍照返回的URL显然不是OSS地址。

解决方案：改用Advance方法。先用urllib下载图片为二进制数据，再通过io.BytesIO流式上传：

from urllib.request import urlopen, Request
import io

req = Request(url, headers={'User-Agent': 'Mozilla/5.0'})
img_data = urlopen(req, timeout=10).read()

request = SearchFaceAdvanceRequest(
    db_name='socialmemory',
    image_url_object=io.BytesIO(img_data),
    limit=1
)
response = client.search_face_advance(request, runtime)

坑3：知识库语义检索会误召回

用户说"刘翔跳槽到阿里巴巴了，更新一下"，结果知识库语义检索匹配到了一条包含"阿里巴巴"的张明档案——因为语义相似度高。

解决方案：在RECALL和UPDATE链路中，先用大模型提取人名关键词，再用人名去检索。这样搜索的query是"刘翔"而不是整句话，精度大幅提升。

坑4：意图识别太慢

最初用DeepSeek-V4-flash做意图识别，每次1-2秒。对于持续监听模式，这个延迟会导致用户说完话后要等一会儿才有反应。

解决方案：换成Ling-2.6-Flash（蚂蚁百灵系列），速度快了很多。意图分类本身是简单任务，不需要大模型的全部理解力，轻量级模型完全够用。

坑5：链路A和链路B的跨轮次传参

链路A记录了一个人（生成了entityId），链路B拍照建档需要用这个entityId。但两者是不同轮次的对话，没有全局变量可以传递。

最初的方案是在链路A的回复里带上entityId，让链路B从历史对话中提取。但这导致回复很不自然：“已记录。张伟，XX科技CTO。档案ID: zhangwei_20260708”——用户听了一脸懵。

解决方案：entityId的生成规则是确定的（姓名拼音_日期），两条链路各自按规则独立生成，结果天然一致。链路B只需要从历史中提取人名，大模型自己按规则拼出entityId。

坑6：普通对话误触发RECALL

用户跟别人聊天时说"好嘞张明总，智联科技对吧"，被意图识别判为RECALL——因为里面有人名。

解决方案：RECALL和UPDATE必须同时满足两个条件：①包含具体人名 ②包含明确的指令词（“是谁”/“准备见”/“更新”/“修改”）。纯陈述句即使提到人名也不触发。

---

开发时间线

天数	完成内容
Day 1	方案设计、赛道选择、核心流程梳理
Day 2	阿里云人脸服务开通、Python插件本地验证
Day 3	百宝箱工作流搭建（意图识别 + 链路C识人）
Day 4	链路A记录 + 链路B建档联调
Day 5	链路D回忆 + 链路E更新 + 空结果兜底
Day 6	全流程优化（模型换Ling-Flash、意图prompt调优）
Day 7	Demo录制 + 文档整理

---

给后来者的建议

1. 先确认交互模型：百宝箱+GPASS是持续监听还是按键触发，这决定了整个架构设计
2. 意图识别是核心：花足够时间调优prompt，它决定了所有链路的入口准确性
3. 用轻量模型做分类：意图识别不需要大模型，换Flash级别的模型能显著提升响应速度
4. 流式上传解决图片问题：阿里云API的Advance方法是万金油，兼容任何图片来源
5. 结构化知识库优于非结构化：CSV + UPSERT模式天然支持更新，不会产生重复文档
6. 先跑通最简链路：我的顺序是 链路C(识人) → 链路D(回忆) → 链路A(记录) → 链路B(建档) → 链路E(更新)，从简单到复杂

---

最终效果

五大功能完整闭环，全程语音交互，平均响应时间2-3秒：

• 记录：从对话中自动提取人物信息
• 建档：拍照注册人脸与档案关联
• 识人：拍照即知对方身份和历史
• 回忆：语音询问获得破冰建议
• 更新：一句话更新已有档案

---

写在最后

这是我第一次给AI眼镜开发应用。最大的感受是：眼镜的形态本身就是产品力。

同样的功能做在手机上，用户需要解锁→打开App→点按钮→等结果。而在眼镜上，只需要说一句话，AI就在耳边回答你。这种"零摩擦"的体验，是手机永远给不了的。

如果你也对AI眼镜开发感兴趣，百宝箱的低代码方式确实降低了很多门槛。核心精力可以放在场景设计和prompt调优上，而不是底层的硬件适配。

---

本文为 GPASS AI 眼镜智能体开发者大赛参赛记录。项目名：知面。