背景
一年前，我购入了 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 编译缝合了一个转发功能。
|
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 项目上架，让更多人来体验“科技的人间烟火”。