2天实战：用阿里云函数计算AgentRun打造端云协同的智能眼镜车牌识别原型

从一段刷到的短视频到一个可以运行的Demo，我只用了两天。本文将分享如何利用开源项目、阿里云函数计算和AgentRun，将Meta Ray-Ban智能眼镜快速改造成一个能进行车牌识别与规则判断的“交警副驾”原型。

背景与灵感

一年前，我购入了Meta Ray-Ban眼镜。虽然Meta对眼镜本体和App的更新很快，但由于缺乏中文支持和开放的SDK，对国内开发者并不友好。直到2025年11月，Meta终于放出了Device Access Toolkit，才让社区看到了更多可能性。

前两天逛GitHub，我刷到了一个名为 turbometa-rayban-ai 的开源项目。作者开发了能直连眼镜的中文App，并接入了大模型API，实现了一些有趣的功能，比如中文多模态对话和卡路里检测。

技术路已经铺好：能截取视频流、能传输图片、能进行AI交互。看着仓库里的调用代码，我心想：在此基础上增加一个服务端功能，似乎并不难？

恰巧，前段时间我刷短视频看到某地交警配备了“黑科技智能眼镜”，看一眼车牌就能识别是否违章，让高科技瞬间接上了“地气”。当时我就在琢磨：这东西看似高大上，但核心逻辑不就是 OCR + 查库 + 规则判断 吗？

吃灰的AI眼镜 -> 交警Copilot？

既然 turbometa-rayban-ai 项目解决了客户端的“样板间”问题，而我又对智能体(Agent)架构略知一二，一个想法冒了出来：能不能用阿里云函数计算的AgentRun功能，把这个原型给快速“Hack”出来呢？

整体架构：“端-管-云”协同设计

眼镜本身的算力有限，因此我们的核心策略是：端侧只负责“看”，云端负责“想”和“处理”。我设计了一个经典的“端-管-云”三层架构：

1. 端 (Client)：AI眼镜 + iOS App。只负责“抽帧”和“传图”，做一个高效无情的传输机器。
2. 脑 (Brain)：阿里云函数计算 AgentRun。作为决策中枢，负责思考业务逻辑，例如“今天是单号还是双号？”、“这辆车是不是在白名单里？”。
3. 手 (Tools)：阿里云FC函数工具。负责执行具体的“脏活累活”，比如查询数据库、写入日志。

整个系统的数据流向非常清晰：

• 看 (See)：眼镜摄像头看到车牌 -> 通过蓝牙传输 -> iOS App。
• 传 (Upload)：iOS App抽帧 -> HTTP POST -> 阿里云函数计算(FC)网关。
• 想 (Think)：FC网关注入当前日期等上下文 -> AgentRun进行推理 -> 决定调用哪个工具。
• 查 (Action)：AgentRun调度FC工具函数 -> 读写数据库 -> 返回查询结果。
• 说 (Speak)：AgentRun生成人性化回复 -> FC返回给客户端 -> iOS转语音 -> 眼镜播放（此功能在原型中规划，暂未完全实现）。

动手实现：从构想到代码

1. 客户端开发（iOS App）

在我们的架构中，iOS客户端被设计为一个“克制的中继”。我们不希望手机成为计算瓶颈，因此端侧只负责I/O，不进行任何AI推理，确保极致轻量化。

由于客户端开发不是本文重点，我直接基于 turbometa-rayban-ai 开源项目，使用Vibe Coding配合Xcode快速“缝合”出了一个转发功能。

核心流程如下：

• 链路建立：App通过特定协议与眼镜建立蓝牙/Wi-Fi连接，实时获取摄像头画面数据流。
• 智能抽帧：我们不上传连续视频流，而是每隔1~2秒，或在监测到头部静止时截取一帧关键画面。这样能极大节省流量并降低云端压力。
• 云端交互：将筛选出的清晰图片进行Base64编码，连同当前时间戳（用于Agent判断单双号）等信息，通过HTTP POST请求发送至阿里云FC网关。
• 语音反馈：当收到云端Agent返回的JSON指令（如 {"voice_feedback": "双号限行，拦截"}），App会调用iOS原生TTS引擎合成语音，并通过眼镜的扬声器播放。

2. 服务端开发（阿里云函数计算）

服务端全部由阿里云函数计算（FC）构建，包含四个核心组件：

• HTTP网关 (接入点)：负责鉴权并处理客户端请求。其关键作用是进行上下文注入，例如计算“今天是单号还是双号”，并将此环境信息嵌入Prompt，再传递给Agent。
• AgentRun (决策大脑)：核心的决策者。它自身不直接操作数据库，只负责“思考”。例如，判断出“车牌尾号是双数，但今天是单号限行日，可能违规了 -> 应该调用check_whitelist工具查询白名单”。
  • 背后的模型：通过阿里云百炼API调用通义千问等大模型。
• 工具函数 (FC Tools)：Agent的“手脚”。负责连接RDS(MySQL)查询白名单，连接SLS写入违章日志等具体操作。我们封装了多个原子能力：
  • log_traffic_all：记录所有经过车辆的车牌、时间等流水信息。
  • query_history：根据车牌查询其近期（如7天、30天）出现历史。
  • check_whitelist：查询该车牌是否已在系统报备的白名单中。
  • log_illegal：确认违章后，记录详细的违章日志。
• 存储层：
  • 阿里云日志服务（SLS）：存储所有操作日志和流水记录，开箱即用，成本极低。
  • 阿里云RDS（MySQL）：存储需要快速查询的报备白名单数据。

2.1 函数计算 AgentRun：用Prompt定义“大脑”

我们没有编写复杂的Python逻辑来判断单双号，而是精心设计了一段 System Prompt。在AgentRun的世界里，自然语言就是业务逻辑代码。

System Prompt 核心片段：

你是一个智能交通管控Agent。
当前日期信息：{{current_date_info}} (由网关注入，例如：今天是1号，单号)

处理流程：
1. 必须执行：先调用 `log_traffic_all` 记录流水。
2. 规则判断：
   - 单号日仅允许尾号单数通行；双号日仅允许尾号双数。
   - 如果满足，直接“放行”。
3. 违规处理：
   - 违反单双号规则时，别急着开罚单！
   - 先调用 `check_whitelist` 查白名单。
   - 如果没报备，再调用 `query_plate_history` 查查是不是惯犯。
   - 最后生成简短回复。

这种做法的优势显而易见：如果交规明天变成“周三尾号3和8限行”，我只需要修改后台的Prompt，无需重新部署一行代码，业务逻辑的变更成本几乎为零。

2.2 FC Tool：打造听话的“手脚”

再聪明的Agent也无法直接连接数据库。我们用FC的Python运行环境封装了几个原子工具函数。这些函数的核心设计哲学是：只做执行，不带“脑子”。

# 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的工具列表中，Agent便瞬间拥有了操作真实世界数据的能力。

2.3 HTTP网关：连接一切的入口

最后，我们需要一个HTTP入口来接收iOS客户端上传的图片，并将“当前日期”这一关键上下文告知Agent。

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

深入思考：为何选择Agent架构与FaaS？

你可能会质疑：一个车牌识别应用，用几行if-else不也能搞定吗？为何要大费周章使用Agent架构和Serverless？这正是本项目的价值所在。

拷问一：为何用Agent取代传统硬编码？

用AgentRun架构取代传统后端逻辑，并非为了追赶AI潮流，而是为了从根本上解决“需求频繁变更”和“输入数据不完美”这两个经典难题。

• 逻辑解耦，Prompt即业务：传统开发中，业务逻辑“焊死”在代码里。若规则从“单双号限行”变为“周五尾号4和9限行”，你需要改代码、测试、部署。而在Agent架构中，代码只提供“能力”（查库、写日志），Prompt定义“逻辑”。规则变动时，仅需修改Prompt即可。
• 动态编排，聪明地“省钱”：传统代码是线性流水线（OCR->查库->记录）。Agent则拥有自主决策权。例如，当OCR识别出一串乱码（可能被遮挡）时，传统流程会无谓地查询数据库然后报错；而Agent会判断“这不是有效车牌格式”，从而跳过查库工具，直接请求重拍，懂得“及时止损”。
• 语义级扩展，应对非标需求：Agent能理解复杂指令。你可以对它说“帮我留意红色的宝马”，即使没有专门的颜色识别代码，具备多模态能力的Agent也能将“红色宝马”作为特征记忆，并在后续视频流中主动识别警报。传统程序对此无能为力。

总结：传统程序是“你让它干啥它干啥”（即便前面是坑）；Agent架构则是“你告诉它目标，它自己规划路径并绕开坑”。对于交警执法这类场景多变、情况非标准化的领域，Agent是一个更聪明的“副驾驶”。

拷问二：为何选择FaaS（函数计算）？

在设计后端时，我毫不犹豫地选择了阿里云函数计算。这不仅是为了省去服务器运维的麻烦，更是因为在Agent + IoT场景下，Serverless是绝配。

• 极致的弹性与成本优化：交通流量潮汐现象明显。传统方案需按高峰配置资源，低峰期资源闲置浪费。FaaS模式有请求才执行，无请求则缩容至零，真正实现按量付费，特别适合我这种预算有限的开发者。
• Tools as Functions，天然契合：在Agent架构中，大模型调用的Tool（工具），其定义（输入->处理->输出）与FaaS函数（Event Trigger -> Handler -> Return）是1:1完美映射的。我不需要维护庞大的单体应用，只需编写一个个独立、原子化的函数（如check_whitelist, log_to_sls）。为AI增加新技能变得无比简单——写个新函数并挂载即可。
• 强大的“胶水”集成能力：AgentRun是大脑，数据存储在各类云产品（RDS, SLS, OSS）中。FaaS原生集成了这些云服务的SDK，让我能用最少的“胶水代码”快速连接一切，无需关心底层基础设施的复杂性。

如果说AgentRun是我请来的“天才指挥官”，那么FaaS就是一支“召之即来，挥之即去”的特种部队，两者结合，效能倍增。

总结与展望

借助Vibe Coding、成熟的云计算产品以及GitHub上的开源项目，我这个从未写过iOS原生应用的人，成功解锁了Meta Ray-Ban眼镜的开发，并在两天内构建出一个完整的“端-管-云”协同智能原型。

当然，这只是一个在Mock数据上跑通的Demo，距离生产级应用还有很长的路。未来可以从以下几个方向优化：

• 端侧减负：在iOS端引入简单的视觉算法（如拉普拉斯算子）检测画面清晰度，模糊帧直接在本地丢弃，大幅节省流量。
• 降本提速：在FC端部署轻量级GPU版OCR模型进行预处理，仅将提取出的“车牌文本”传给Agent，可降低90%的Token消耗并提升响应速度。结合Redis缓存对短时重复车牌进行去重，减少无效调用。
• 完善体验：引入全链路流式交互，实现Agent边思考边通过TTS播报，将语音反馈的延迟感降至最低。

整个开发过程也让我感受到，作为微服务化、智能体应用，其工具链的调试、注册和管理仍有提升空间。期待相关产品体验进一步完善后，我能将这个项目打包成一个更易用的Demo，分享到云栈社区，让更多朋友体验这场“科技照进现实”的趣味实践。

文中提及的关键产品与项目：

• 阿里云函数计算 FC：https://www.aliyun.com/product/fc
• 函数计算 AgentRun：https://www.aliyun.com/product/fc/agentrun
• 阿里云百炼大模型服务：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
• turbometa-rayban-ai Github项目：https://github.com/Turbo1123/turbometa-rayban-ai