[Python] 函数计算AgentRun实操：基于AI眼镜与端管云架构的交通违章识别原型

一年前，我购入了 Meta Ray-ban 眼镜。Meta 对于眼镜本体的开发及 App 更新很快，但由于没有中文支持和开放的 SDK，导致对国内用户非常不友好。2025 年 11 月，Meta 终于放出了 Device Access Toolkit，让社区看到了点意思。

前两天逛 GitHub，刷到了名为 turbometa-rayban-ai 的开源项目。项目作者开发了直连中文 App + 百炼 API，实现了几个有趣功能，例如中文多模态对话、卡路里检测等。

基础能力都已具备：能截取视频流、能传输图像、能进行 AI 交互。看着 Repo 里的调用代码，似乎在此基础上增加一个服务端功能并不是什么难事？

正好前段时间刷短视频，看到某地交警配备了那种“黑科技眼镜”，看一眼车牌就能识别是不是违章车，科技瞬间变成人间烟火。当时我就在想：这玩意儿虽然看起来高大上，但核心逻辑不就是 OCR + 查库 + 规则判断 吗？

既然 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 个核心组件，全部通过阿里云函数计算构建，它们构成了一个完整的人工智能决策与执行闭环：

• 接入点 (Gateway)：负责鉴权并处理客户端调用。进行 Context 注入：计算“今天是单号还是双号”，将这个环境信息塞入 Prompt，再传给 Agent。
• AgentRun (Brain)：核心决策者。它不直接操作数据库，只负责“想”。例如判断：“车牌是双号，今天是单号，违规了 -> 应该调用查白名单工具。”
  • FunModel：AgentRun 背后的大脑，通过阿里云百炼 API 调用 Qwen 等大模型。
• 工具集 (FC Tools)：连接 RDS (MySQL) 查白名单，连接 SLS 写违章日志，是 Agent 的“手和脚”。
  • log_traffic_all：把车牌、时间等信息记录下来。
  • query_history：通过车牌查询历史库，过去 7 天、30 天是否有出现。
  • check_whitelist：查询车牌是否在报备白名单中。
  • log_illegal：记录违章日志，供后台处理。
• 存储层：
  • 阿里云日志服务 (SLS)：用于存储记录数据，开箱即用，几乎无使用成本。
  • 阿里云 RDS (MySQL)：用来存储报备白名单。

2.1 函数计算 AgentRun：定义“大脑”的逻辑

我们没有写复杂的 Python 逻辑判断单双号，而是写了一段 Prompt。在 AgentRun 里，自然语言就是代码。

System Prompt 核心片段：

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

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

逻辑看起来很简单。如果交规明天改成“周三尾号 3 限行”，我只需要修改 Prompt 文本，而无需重新部署任何一行后端代码。

2.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 的工具列表里。至此，Agent 便拥有了操作真实世界数据的能力。

2.3 连接客户端：网关入口

最后，我们需要一个 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架构 + 函数计算 重新造一遍轮子吗？想了想，两者在设计哲学和扩展性上还真有本质区别。

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

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

这就到了本项目的精髓所在。用 AgentRun 取代传统后端逻辑，不仅仅是为了运用 AI 技术，更是为了解决现实世界中 “需求总在变” 和 “数据总是不完美” 这两个核心痛点。相比于传统硬编码，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？

在设计这套系统时，我选择了 阿里云函数计算 作为后端运行时。这不仅仅是为了省去服务器运维的麻烦，更因为在 Agent + IoT 这种场景下，Serverless 简直是“天选之子”。

极致的“抠门”艺术
交通场景的流量是极其不均匀的。早晚高峰车水马龙，半夜三更则几乎没有车辆。

• 传统服务器：你得按最高峰的配置购买并维持服务器运行。半夜没车时，CPU 在空转，成本在持续消耗。
• FaaS 模式：有请求（有车经过）才执行函数，没请求时资源释放，按实际使用量计费。当眼镜没传照片时，实例可缩容到 0，几乎不产生费用。当早高峰突然涌入大量请求，FC 能瞬间拉起多个实例并行处理。这种“弹性伸缩、用完即走”的特性，对资源敏感的开发者或项目初期非常友好。

Tools as Functions：天然契合
在 Agent 架构中，大模型需要调用各种 Tools（工具）。一个 Tool 的定义，其输入-处理-输出的模式，天生就与一个 FaaS 函数（Event -> Handler -> Response）完美契合。

• Tool 定义：输入车牌 -> 查库 -> 输出结果。
• FaaS 定义：Event Trigger -> Python Handler -> Return JSON。
  我不需要在一个庞大的单体应用里写一堆接口，只需要编写一个个独立、原子化的小函数：check_whitelist、log_to_sls。Agent 想用哪个，就通过 HTTP 调用哪个。这种类似微服务化的架构，让为 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 函数工具完成查库、记录等实际操作。利用零碎时间，将一副消费级眼镜初步改造成了“交警副驾”的原型。

当然，目前 Demo 只是在 Mock 数据上跑通逻辑，离生产级应用还有很大距离，还有很多可以优化的方向，例如：

• 端侧减负：在 iOS 端引入视觉算法（如拉普拉斯算子）检测画面清晰度，模糊帧直接丢弃，大幅节省上行流量。
• 降本提速：在 FC 端部署轻量级 GPU OCR 模型做预处理，只将提取后的“车牌文本”传给 Agent，将大模型 Token 消耗降低 90% 以上，同时提升响应速度。可以借助 Redis 缓存，对短时间（例如 1 分钟内）出现的重复车牌进行去重，减少无效的数据处理和调用。
• 完善体验：引入全链路流式交互，实现 Streaming TTS，让 AI 边推理边语音反馈，将端到端的响应延迟感知降至最低。

在开发过程中，我也发现作为微服务化的 Agent 应用，其工具注册、调试和观测流程仍有提升空间，相关建议也正在整理反馈。等各方体验更完善后，我计划把项目整理成一个完整的 Demo，分享到像 云栈社区 这样的技术论坛，让更多开发者能体验和复现这种“科技照进现实”的乐趣。