核心内容摘要
�程�开店平��么选？主��务商测评对比
背景一年前我购入了 Meta Ray-ban 眼镜Meta 对于眼镜本体的开发及 App 更新很快但由于没有中文支持和开放的SDK 导致对国内用户非常不友好。
2025 年 11 月Meta 终于放出了 Device Access Toolkit 让社区看到了点意思前两天逛 GitHub 刷到了名为turbometa-rayban-ai 开源项目项目作者开发了直连中文 App 百炼 API实现了几个支持有趣功能例如中文多模态对话、卡路里检测等。
路都铺好了能截流、能传图、能搞 AI 交互。
看着 Repo 里的调用代码似乎加一个服务端的功能不是什么难事正好前段时间刷短视频看到某地交警配备了那种“黑科技眼镜”看一眼车牌就能识别是不是违章车科技瞬间变成人间烟火。
当时我就在想这玩意儿虽然看起来高大上但核心逻辑不就是OCR 查库 规则判断吗吃灰的 AI 眼镜 - - 交警 Copilot既然有了 turbometa-rayban-ai 解决了样板间问题我又略懂一些 Agent 架构能不能用阿里云函数计算 AgentRun功能把这个原型给“Hack”出来“端管云”协同框架首先我们来梳理一个整体架构图眼镜本身算力有限所以我们的策略是端侧只负责看云端负责想与处理。
我设计了经典的“端-管-云”三层架构
端 (Client)AI 眼镜 iOS App。
负责“抽帧”和“传图”做一个无情的传输机器。
脑 (Brain)阿里云函数计算 AgentRun。
负责思考“今天是单号还是双号”、“这车是不是VIP”。
手 (Tools)阿里云 FC - 函数工具。
负责脏活累活比如查数据库、写日志。
整体的数据流向如下看 (See): 眼镜看到车牌 - 蓝牙传输 - iOS App。
(Upload): iOS App 抽帧 - HTTP POST - 阿里云函数计算FC。
想 (Think): FC 注入日期规则 - AgentRun 思考 - 决定查库。
查 (Action): AgentRun 调度 FC 工具 - 读写数据库 - 返回结果。
说 (Speak): AgentRun 生成人性化回复话- FC 返回 - iOS 转语音 - 眼镜播放规划中暂未实现。
动手让想法照进现实客户端开发在我们的架构设计中iOS 客户端的角色被设计为一个 “克制的中继”。
我们不希望手机成为计算瓶颈因此端侧只负责 I/O不负责 AI 推理这套逻辑确保了端侧的极致轻量化。
由于客户端开发不是重点所以我直接基于 turbometa 项目用 Vibe Coding XCode 编译缝合了一个转发功能。
架构图核心架构与流程逻辑●链路建立App 通过 turbometa 协议或 SDK 与眼镜建立蓝牙/Wi-Fi 高速通道实时获取摄像头的画面数据。
●抽帧我们不上传连续视频流而是每隔 1~2 秒截取一帧画面。
直接调VL模型估计吃不消。
●云端交互将筛选出的高清图片进行 Base64 编码打包当前时间戳用于 Agent 判断单双号和 GPS位置 信息发送 HTTP POST 请求直连阿里云 FC 网关。
●眼镜播放一旦收到云端 Agent 返回的 JSON 指令例如 {“text”: “双号限行拦截”}App 立即调用 iOS 原生的 TTS 引擎合成语音音频流会自动路由回眼镜的开放式扬声器播放。
服务端开发服务端有 4 个组件全部通过阿里云函数计算FC 构建分别是接入点负责鉴权并处理客户端调用。
Context 注入计算“今天是单号还是双号”将这个环境信息Context塞入 Prompt再传给 Agent。
AgentRun核心决策者。
它不碰数据库只负责“想”。
判断“车牌是双号今天是单号违规了 - 应该调用查白名单工具。
”FunModelAgentRun 背后模型通过阿里云百炼API、调用 Qwen 模型。
工具FC Tools连接 RDS (MySQL) 查白名单连接 SLS 写违章日志。
log_traffic_all把车牌、时间等信息记录下来query_history通过车牌查询历史库过去 7 天、30 天是否有出现check_whitelist查询车牌是否在报备白名单中log_illegal记录日志后台处理存储层阿里云日志服务SLS用于存储记录数据开箱即用几乎无使用成本阿里云 RDSMysql用来存储报备白名单
1 函数计算 AgentRun定义“大脑”的逻辑 (Prompt Engineering)我们没有写复杂的 Python 逻辑判断单双号而是写了一段Prompt。
在 AgentRun 里自然语言就是代码。
System Prompt 核心片段你是一个智能交通管控 Agent。
当前日期信息 (由网关注入例如今天是1号单号) 处理流程
必须执行先调用 log_traffic_all 记录流水。
规则判断 - 单号日仅允许尾号单数通行双号日仅允许尾号双数。
- 如果满足直接“放行”。
违规处理 - 违反单双号规则时别急着开罚单 - 先调用 check_whitelist 查白名单。
- 如果没报备再调用 query_plate_history 查查是不是惯犯。
- 最后生成简短回复。
逻辑看起来很简单如果老板明天说“周三改为尾号 3 限行”我只需要改 Prompt不用重新部署代码。
2 FC Tool打造“手脚”Agent 再聪明也无法直接连数据库。
我们用FC (Python Runtime)封装了几个原子能力工具。
这里的代码核心是 “只做执行不带脑子”。
# tools.py (部署在 FC 上) def handler(event, context): # AgentRun 会把要调用的函数名传过来 tool_name json.loads(event).get(function) if tool_name check_whitelist: # 纯粹的 SQL 查询 return db.query(SELECT count(*) FROM whitelist WHERE plate%s, plate) elif tool_name log_illegal_notice: # 写入 SLS 日志服务甚至把违章照片存进去 return sls.put_log(plate, image_base64, violation) # ... 其他工具我们把这个 FC 函数绑定到 AgentRun 的工具列表里并在 AgentRun 中选上Agent 拥有了操作真实世界的能力。
3连接客户端 (The Gateway)最后我们需要一个 HTTP 入口来接收 iOS 传来的照片并把“当前日期”告诉 Agent。
# main.py (入口网关) def handler(event, context): #
算一下今天是单号还是双号 is_odd (datetime.now().day % 2 !
date_context f今天是{单号 if is_odd else 双号} #
组装 Prompt把图片和日期一起丢给 Agent prompt f{date_context}请处理这张图片里的车{image_url} #
调用 AgentRun 接口 reply call_agent_run(prompt) #
返回结果 return {voice_feedback: reply}灵魂拷问小题大做还是降维打击可能很多人在问这么小一个应用半年前都已经在全国铺开了有必要再用 Agent架构 函数计算FaaS 造一遍轮子吗想了想还真有点区别拷问一几行 if-else搞定的事为什么用 Agent 架构你可能会问“不就是查个车牌吗我在 Python 里写几行if-else不也一样跑”这就到了本项目的精髓所在。
用 AgentRunAgent 架构取代传统后端逻辑不仅仅是为了蹭 AI 的热度而是为了解决现实世界中“需求总在变”和“数据总是不完美”这两个死穴。
相比于传统硬编码Hard-codingAgent 方案展现了降维打击般的优势逻辑解耦Prompt 即业务在传统开发中业务逻辑是“焊死”在代码里的。
一旦交规从“单双号限行”变成“周五尾号 4 和 9 限行”你得修改代码、重新测试、重新部署上线。
而在 Agent 架构中代码只负责“能力”查库、写日志Prompt 负责“逻辑”。
举个例子规则突变明天突然要严查“皮卡车”禁止皮卡进入。
传统做法改代码加一个if vehicle_type pickup重新发版。
Agent 做法只需在后台 System Prompt 里加一句话——“注意从现在起所有皮卡车一律拦截。
”Agent 会自动调用 OCR 识别车型如果 VLM 支持并执行拦截逻辑代码一行不用动。
动态编排省钱又高效传统代码通常是“流水线”式的先 OCR - 再查库 - 再记日志。
不管需不需要流程都要走一遍。
Agent 拥有 “自主决策权”它知道什么时候该省事什么时候该深究。
例如来了一辆车但 OCR 识别结果是一串乱码可能是树叶遮挡。
传统做法拿着乱码去数据库SELECT * FROM ...浪费一次数据库查询最后报错。
Agent 做法Agent 看到乱码会思考“这显然不是一个有效的车牌格式查库也是浪费时间。
”它会跳过查库工具直接反馈“车牌模糊请重拍。
” ——它懂得“止损”。
语义级扩展Agent 可以理解复杂的、非结构化的指令。
比如你想找一辆特定的车但忘了车牌只记得是“红色的宝马”。
Agent 做法你可以直接对眼镜说“帮我留意一下红色的宝马。
” Agent 会将“红色宝马”这个特征加入到它的短期记忆中。
当后续图片流中出现红色车身宝马标时哪怕你没写专门的“颜色识别代码”Agent (如果是多模态) 也能理解并触发警报。
总结一下传统程序是 “你让它干啥它干啥”就算前面是坑也往下跳抛出异常人工处理Agent 架构是“你告诉它目标它自己找路”遇到坑它知道绕过去甚至还能帮你填上。
对于像交警执法这样充满变数和非标准情况的场景Agent 才是那个最聪明的“副驾”。
拷问二为什么选 FaaS在设计这套系统时我毫不犹豫地选择了阿里云函数计算 (FC)作为后端运行时。
这不仅仅是因为我懒得维护服务器更是因为在Agent IoT这种场景下Serverless 简直是“天选之子”。
极致的“抠门”艺术交通场景的流量是极其不均匀的。
早晚高峰车水马龙半夜三更鬼影都没一个。
传统服务器你得按最高峰的配置买机器。
半夜没车时CPU 在空转你的钱在燃烧。
FaaS 模式有车来才干活没车来就睡觉。
当眼镜没传照片时实例缩容到 0一分钱不扣。
当早高峰突然来了 100 辆车FC 瞬间拉起 100 个实例并行处理。
这种“用完即走”的特性对于我这种钱包不鼓的开发者来说简直是救命稻草。
Tools as Functions在 Agent 架构中大模型需要调用各种 Tools工具。
你仔细想一下一个 Tool 的定义是不是天生就长得像一个 FunctionTool 定义输入车牌 - 查库 - 输出结果。
FaaS 定义Event Trigger - Python Handler - Return JSON。
这两者是1:1 完美映射的。
我不需要在一个庞大的 Spring Boot 或 Django 项目里写一堆接口我只需要写一个个独立、原子化的小函数check_whitelist、log_to_sls。
Agent 想用哪个就唤醒哪个。
这种类微服务化的架构让给 AI 增加新技能变得异常简单——写个新函数一挂载搞定。
“胶水” 的力量AgentRun 只是大脑数据都在云产品里RDS, SLS, OSS。
FaaS 就像是强力胶水它原生集成了阿里云的各种 SDK。
你想存照片FC 几行代码转存 OSS。
你想记日志FC 原生对接 SLS。
你想发通知FC 触发短信网关。
FaaS 屏蔽了底层基础设施的复杂性让我能专注于写那几行核心的“胶水代码”而不是去折腾数据库连接池或者网络配置。
如果说 AgentRun 是我请来的 “天才指挥官”那 FaaS 就是一支“特种部队”——平时隐身不花钱一声令下千军万马使命必达。
写在最后借助 Vibe Coding、云计算产品、及 GitHub 开源项目一个从未写过 IOS 小白解锁了 Meta Ray-Ban 眼镜的开发构建了一个 “端-管-云” 协同的智能原型眼镜负责第一视角采集iOS App 负责抽帧中继云端 AgentRun 充当“大脑”进行意图理解与决策指挥 FC 函数 完成查库、违章记录等实操。
2天零碎时间把一副消费级眼镜勉强魔改成“交警副驾”当然 Demo 只是在 Mock 数据上勉强跑通离 Production 还是有很大距离还有很多优化的地方比如端侧减负在 iOS 端引入视觉算法检测画面清晰度模糊帧直接丢弃大幅节省 5G 上传流量。
降本提速在 FC 部署 GPU 版 OCR小模型 做预处理只将提取后的“车牌文本”传给 Agent将 Token 消耗降低 90%速度提升一倍。
可以借助 Redis 缓存把邻近例如 1 分钟内车牌去重减少重复数据和调用。
完善体验引入 全链路流式交互 (Streaming TTS)让 AI 边想边说将语音反馈的等待感压至毫秒级。
在开发的过程中也发现作为微服务、Agent 应用调试工具、注册工具和 Debug 也是挺折腾的相关建议也正在整理反馈给产品方。
等各方体验完善后我也计划把项目打包成一个 Demo 项目上架让更多人来体验“科技的人间烟火”。
文中提及产品及项目阿里云函数计算 FChttps://www.aliyun.com/product/fc函数计算 AgentRun https://www.aliyun.com/product/fc/agentrun阿里云百炼大模型服务 (Bailian) https://www.aliyun.com/product/bailian阿里云日志服务 (SLS) https://www.aliyun.com/product/sls阿里云关系型数据库 (RDS for MySQL) https://www.aliyun.com/product/rds/mysql阿里云对象存储 (OSS) https://www.aliyun.com/product/oss阿里云云数据库 Redis https://www.aliyun.com/product/kvstoreturbometa-rayban-ai Github项目https://github.com/Turbo1123/turbometa-rayban-ai/blob/main/README_EN.md