编码智能体做 CV 任务，实际能力到哪一步了？——五项视觉任务实测解读

导读

编码智能体（Coding Agent）能自动写代码、跑脚本、调 bug、迭代优化，但如果交给它一个视觉任务——比如数一张图里有多少只鸟、从视频里跟踪计数车辆、识别车牌——它能做到什么程度？

最近，一个计算机视觉团队做了一组系统测试：用 5 个典型的 CV 任务，分别测试了 Claude Code、Gemini-CLI 和 OpenAI Codex 三个主流编码智能体的实际表现。测试覆盖了图像目标计数、视频多目标跟踪、实时流处理和车牌识别（OCR）等场景，评分维度包括速度和准确度。

这组测试的价值不在于"哪个 Agent 最强"，而在于它提供了一组具体的观察窗口：编码智能体在 CV 任务上的能力边界在哪里？它们的策略差异体现了什么？哪些类型的视觉任务已经可以交给 Agent，哪些还差得远？

本文基于完整的测试数据，逐项还原评测过程，并在最后给出我们的分析。

图片

来源于 Roboflow Blog 原文

一、评测设置

评分规则

得分由速度分（1 分钟以内最高 0.3 分）和准确度分（最高 0.7 分，按任务具体评估）相加得出。准确度权重远高于速度，体现了 CV 任务"做对比做快更重要"的特点。

调用方式

所有智能体均通过命令行调用：

claude --dangerously-skip-permissions --verbose --output-format stream-json [prompt]
codex -a never exec --sandbox workspace-write -c features.search=true [prompt]
gemini --yolo --output-format stream-json [prompt]

二、五项任务逐项还原

任务 1 — 使用 SAM3 计数图片中的鸟

提示词：使用 SAM3 对提供的图片 'birds_sam3.jpg'（已在工作区中）中的鸟进行标注。统计检测数量并打印计数结果。将计数结果以数字形式写入 'output.txt' 文件。

图片

来源于 Roboflow Blog 原文

结果：

• Gemini / Claude：都使用了 sam3 的 Python 包，并且都对 PositionEmbeddingSine 层进行了补丁修改以使用 CPU（评估在 macOS 上运行）
• Codex：忽略了使用 SAM3 的指令，尝试使用标准的 COCO 预训练检测器，鸟的计数结果有误

获胜者：Claude / Gemini

关键观察：当 prompt 明确指定使用某个工具时，Claude 和 Gemini 都能遵循指令并解决环境兼容性问题（自动打补丁适配 CPU）。Codex 则直接忽略了工具指定，这不是能力问题，而是指令遵循问题。

任务 2 — 计数视频文件中的汽车

视频片段长 10 秒，实际约有 150-200 辆车。计数在 50-100 和 200-300 之间可获得部分得分。

来源于 Roboflow Blog 原文

提示词：使用 Python 脚本统计视频 'cars-aerial-view.mp4'（已在工作区中）中不重复的汽车总数。将最终数字输出到名为 'output.txt' 的文件中。

结果：

• Claude：编写并运行了脚本，使用 BoTSORT 跟踪器计数 270 辆车
• Gemini：使用基于 COCO 的检测器计数 37 辆车
• Codex：使用基于 COCO 的检测器计数 48 辆车

获胜者：Claude

关键观察：视频中的"不重复计数"需要检测+跟踪两步配合。Claude 主动选择了 BoTSORT（一种多目标跟踪算法），具备跨帧关联同一目标的能力，因此能给出一个量级合理的数字（尽管 270 相比真实值 150-200 仍高估了 35%-80%）。Gemini 和 Codex 使用的 COCO 检测器是针对单帧的目标检测模型，缺少跨帧跟踪能力，在航拍小目标场景下检出率也有限，导致严重漏计（37 和 48）。这个任务说明：即使是"获胜"的 Agent，绝对精度也远未达到可直接用于生产的水平，但它在技术选型上的判断（知道需要跟踪器）明显优于其他两个。

任务 3 — 计数 RTSP 实时流中的汽车

与任务 2 类似，但在实时流上评估，推理速度至关重要。使用 mediamtx 通过 RTSP 循环播放视频，要求推理帧率大于 10 fps。

提示词：我有一个 RTSP 流，地址为 rtsp://localhost:8554/stream。我想使用 Python 脚本统计 15 秒视频中的汽车总数。同时测量推理 FPS，如果低于 10fps 则使用更小/更快的模型。在最后将结果打印到控制台。将不重复的汽车最终数量输出到名为 'output.txt' 的文件中！视频是车辆停车场的航拍/俯视视角。

结果：

• Claude：使用了 COCO 检测器并制作了一个简单的基于 IoU 的跟踪器，计数 86 辆车
• Gemini：尝试了不同大小的模型配合现成的跟踪器，但只计数了 29 辆车。可能是置信度阈值设置过高
• Codex：仅生成了 Python 脚本，但没有按照指令实际运行它

获胜者：Claude

关键观察：实时流增加了"速度约束"这一维度。Claude 选择了轻量方案（IoU 跟踪替代 BoTSORT），体现了对性能约束的理解。Codex 在这个任务上暴露了一个反复出现的模式：只写代码不执行。

任务 4 — 计数图片中的牛油果

与任务 1 类似，但没有指定使用哪个工具。实际数量约 55 个，越接近 55 得分越高。

图片

来源于 Roboflow Blog 原文

结果：

• Claude：使用 YOLO World 尝试了不同的置信度阈值，标注了牛油果（绘制了边界框），然后使用 LLM 验证标注后的图片。消耗了大量 token，计数结果为 54 个
• Gemini：使用了类似的方法，但在 10 分钟后超时
• Codex：使用了类似的方法，计数 43 个（没有进行验证）。因为没有做验证所以速度更快，总分更高

获胜者：Claude / Codex

关键观察：这个任务有两个技术点值得展开。第一，Claude 选用了 YOLO World——这是一种开放词汇检测器（Open-Vocabulary Detector），能检测训练集类别之外的目标。"牛油果"不在标准 COCO 的 80 个类别中，选用 YOLO World 说明 Agent 具备根据目标类别选择合适模型的能力。第二，Claude 在检测之后主动调用 LLM 对标注图进行二次验证，最终计数 54（真实值 55），几乎命中。这种"检测→验证→修正"的闭环行为不是 prompt 要求的，而是 Agent 自发的策略，代价是消耗更多 token 和时间，但换来了显著更高的准确度。

任务 5 — 车牌识别（LPR）

这是一个多步骤的复合任务：检测车辆 → 定位车牌 → 裁剪保存 → OCR 识别 → 输出结果。

图片

来源于 Roboflow Blog 原文

提示词：编写一个 Python 脚本，从工作区中提供的图片 'cars-highway.png' 中检测并识别车牌。脚本应：

1. 检测车辆和车牌
2. 裁剪每个检测到的车牌，并将裁剪结果保存为图片文件到 'results/' 文件夹
3. 对每个车牌运行 OCR/LPR 以提取文本（不含空格或特殊字符）
4. 将所有车牌号码保存到 'result.txt' 文件中，以逗号分隔，不加引号。

结果：

• Claude：使用在 COCO 上训练的检测器进行车辆检测，尝试使用经典 CV 方法（阈值分割/轮廓检测）进行车牌检测，并使用 easyocr/pytesseract 进行识别。最终超时
• Gemini：使用基于 COCO 的检测器进行车辆检测，使用 HuggingFace Hub 上的 yasirfaizahmed/license-plate-object-detection 模型进行车牌检测，并使用 easyocr 进行识别。正确识别了 3 个车牌中的 2 个
• Codex：仅编写了脚本但没有运行（忽略了指令）

获胜者：Gemini

关键观察：这是唯一一个 Claude 失败的任务。Claude 选择了经典 CV 方法（阈值分割+轮廓检测）来做车牌定位——这类方法对光照变化、拍摄角度、车牌样式差异非常敏感，在非受控场景中很难鲁棒工作，最终导致超时。Gemini 则直接从 HuggingFace Hub 搜索并调用了一个专门训练过的车牌检测模型，跳过了手工特征工程，策略更高效。这说明：在需要专用模型的子任务上，Agent 能否主动搜索和调用社区预训练模型，比自己用经典方法从头搭建更可靠。

三、跳出单项结果看整体：四个值得关注的发现

1. Agent 的技术选型能力差异很大，直接决定成败

五项任务中，Agent 之间的差距往往不在于"代码写得好不好"，而在于"选了什么模型和方法"。Claude 在任务 2 中选择 BoTSORT 做跟踪、在任务 4 中选择 YOLO World 做开放词汇检测，Gemini 在任务 5 中从 HuggingFace 搜索专用车牌检测模型——这些关键选型直接决定了任务能否完成。反过来，Claude 在任务 5 中选择经典 CV 方法做车牌定位，直接导致超时失败。Agent 对 CV 工具链的掌握深度，目前是能力差距的主要来源。

2. "自验证"是有效但昂贵的策略

在任务 4 中，Claude 主动用 LLM 验证检测结果，最终精度几乎命中真实值（54 vs 55）。这种"检测→验证→修正"的闭环行为是 Agent 自发的，不是 prompt 要求的。但代价也很明显：更多 token 消耗和更长的执行时间。在对精度要求高但不赶时间的场景下，这种策略很有价值。

3. 指令遵循比模型能力更影响结果

Codex 在 5 个任务中有 2 个只写了代码不运行，直接拿了零分。这不是"做不到"，而是"没按要求做"。在实际使用中，如果一个 Agent 不能可靠地执行完整的"写代码→运行→看结果→调整"的循环，那它的模型能力再强也无法转化为有效输出。

4. 即使"获胜"，绝对精度也需要审慎看待

Claude 在任务 2 中以 270 辆车的计数"获胜"，但真实值是 150-200，误差达 35%-80%。任务 3 中计数 86 辆也明显偏低。这意味着：在这组测试的评分体系中表现最好，不等于结果可以直接用于生产。对于工业级 CV 应用，Agent 的输出仍然需要人工校验。

四、对 Agent+CV 实践的启示

这组测试给出的信号是：编码智能体已经能够在 CV 任务上走完"选模型→写代码→跑通→出结果"的全流程，但输出质量因任务复杂度和 Agent 的技术选型能力而有很大波动。

需要注意这组测试本身的局限：每个 Agent 每个任务只运行了一次，没有多次取均值；评估环境为 macOS CPU（无 GPU），不是 CV 模型的典型部署环境；5 个任务中 3 个是"计数"，任务类型覆盖偏窄。这些因素意味着测试结果不宜过度泛化。

基于现有数据，对开发者的建议：

• 单步 CV 任务（检测、计数、标注）可以让编码 Agent 快速出原型，但输出精度需要人工校验，不宜直接用于对准确率有严格要求的场景
• 多步骤流水线（如检测→定位→裁剪→OCR）建议拆成独立子任务，让 Agent 逐步完成，人工检查中间结果
• Prompt 中尽量指定要使用的模型或工具，或明确提示 Agent 去 HuggingFace 等平台搜索专用模型，减少 Agent 自行选择经典方法走弯路的概率
• 对于需要跟踪的视频任务，在 prompt 中提示"需要多目标跟踪"可以帮助 Agent 做出更合理的技术选型

参考来源

• 原文：Erik Kokalj, Which is the Best Coding Agent for Vision tasks?, Roboflow Blog
• 链接：https://blog.roboflow.com/best-coding-agent-for-vision-ai/