吃灰 AI 眼镜爆改“交警 Copilot”，函数计算AgentRun 实操记录

显示全部楼层

背景

一年前，我购入了 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”出来？

“端管云”协同框架

首先我们来梳理一个整体架构图，眼镜本身算力有限，所以我们的策略是：端侧只负责看，云端负责想与处理。我设计了经典的“端-管-云”三层架构：

1.端 (Client)：AI 眼镜 + iOS App。负责“抽帧”和“传图”，做一个无情的传输机器。

2.脑 (Brain)：阿里云函数计算 AgentRun。负责思考“今天是单号还是双号？”、“这车是不是VIP？”。

3.手 (Tools)：阿里云 FC - 函数工具。负责脏活累活，比如查数据库、写日志。

整体的数据流向如下：

看 (See): 眼镜看到车牌 -> 蓝牙传输 -> iOS App。
传 (Upload): iOS App 抽帧 -> HTTP POST -> 阿里云函数计算FC。
想 (Think): FC 注入日期规则 -> AgentRun 思考 -> 决定查库。
查 (Action): AgentRun 调度 FC 工具 -> 读写数据库 -> 返回结果。
说 (Speak): AgentRun 生成人性化回复-> FC 返回 -> iOS 转语音 -> 眼镜播放（规划中，暂未实现）。

动手，让想法照进现实

1. 客户端开发

在我们的架构设计中，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 引擎合成语音，音频流会自动路由回眼镜的开放式扬声器播放。

2. 服务端开发

服务端有 4 个组件，全部通过阿里云函数计算（FC 构建），分别是：

接入点：负责鉴权并处理客户端调用。Context 注入：计算“今天是单号还是双号”，将这个环境信息（Context）塞入 Prompt，再传给 Agent；
AgentRun：核心决策者。它不碰数据库，只负责“想”。判断：“车牌是双号，今天是单号，违规了 -> 应该调用查白名单工具。”；

FunModel（AgentRun 背后模型）：通过阿里云百炼API、调用 Qwen 模型；

工具（FC Tools）：连接 RDS (MySQL) 查白名单，连接 SLS 写违章日志；

log_traffic_all：把车牌、时间等信息记录下来；
query_history：通过车牌查询历史库，过去 7 天、30 天是否有出现；
check_whitelist：查询车牌是否在报备白名单中；
log_illegal：记录日志，后台处理；

存储层：

阿里云日志服务（SLS）：用于存储记录数据，开箱即用，几乎无使用成本；
阿里云 RDS（Mysql）：用来存储报备白名单。

2.1 函数计算 AgentRun

定义“大脑”的逻辑 (Prompt Engineering)我们没有写复杂的 Python 逻辑判断单双号，而是写了一段Prompt。在 AgentRun 里，自然语言就是代码。

System Prompt 核心片段：

你是一个智能交通管控 Agent。当前日期信息：{{current_date_info}} (由网关注入，例如：今天是1号，单号)
处理流程：1.必须执行：先调用`log_traffic_all`记录流水。2.规则判断： - 单号日仅允许尾号单数通行；双号日仅允许尾号双数。 - 如果满足，直接“放行”。3.违规处理： - 违反单双号规则时，别急着开罚单！ - 先调用`check_whitelist`查白名单。 - 如果没报备，再调用`query_plate_history`查查是不是惯犯。 - 最后生成简短回复。

逻辑看起来很简单，如果老板明天说“周三改为尾号 3 限行”，我只需要改 Prompt，不用重新部署代码。

2.2FC Tool：打造“手脚”

Agent 再聪明也无法直接连数据库。我们用FC (Python Runtime)封装了几个原子能力工具。

这里的代码核心是 “只做执行，不带脑子”。

#tools.py(部署在FC上)defhandler(event,context):#AgentRun会把要调用的函数名传过来tool_name=json.loads(event).get('function')iftool_name=='check_whitelist':#纯粹的SQL查询returndb.query("SELECTcount(*)FROMwhitelistWHEREplate=%s",plate)eliftool_name=='log_illegal_notice':#写入SLS日志服务，甚至把违章照片存进去returnsls.put_log(plate,image_base64,"violation")#...其他工具

我们把这个 FC 函数绑定到 AgentRun 的工具列表里，并在 AgentRun 中选上，Agent 拥有了操作真实世界的能力。

2.3连接客户端 (The Gateway)

最后，我们需要一个 HTTP 入口来接收 iOS 传来的照片，并把“当前日期”告诉 Agent。

#main.py(入口网关)defhandler(event,context):#1.算一下今天是单号还是双号is_odd=(datetime.now().day%2!=0)date_context=f"今天是{'单号'ifis_oddelse'双号'}"#2.组装Prompt，把图片和日期一起丢给Agentprompt=f"{date_context}，请处理这张图片里的车：{image_url}"#3.调用AgentRun接口reply=call_agent_run(prompt)#4.返回结果return{"voice_feedback":reply}

灵魂拷问：小题大做，还是降维打击？

可能很多人在问，这么小一个应用，半年前都已经在全国铺开了，有必要再用 Agent架构 + 函数计算（FaaS）造一遍轮子吗？想了想还真有点区别：

拷问一：几行 if-else搞定的事，为什么用 Agent 架构？

你可能会问：“不就是查个车牌吗？我在 Python 里写几行if-else不也一样跑？”

这就到了本项目的精髓所在。用 AgentRun（Agent 架构）取代传统后端逻辑，不仅仅是为了蹭 AI 的热度，而是为了解决现实世界中“需求总在变”和“数据总是不完美”这两个死穴。相比于传统硬编码（Hard-coding），Agent 方案展现了降维打击般的优势：

逻辑解耦：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 的定义，是不是天生就长得像一个 Function？

Tool 定义：输入车牌 -> 查库 -> 输出结果。
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 项目上架，让更多人来体验“科技的人间烟火”。