Apple Vision框架：大多数开发者忽略的设备端CV

Apple的Vision框架（不带”OS”后缀的那个）提供两打以上的设备端计算机视觉操作。大多数iOS开发者却默认选择OpenAI Vision API、Google Cloud Vision或AWS Rekognition来完成那些Vision框架可以在设备的Neural Engine上以毫秒级速度执行的任务。这种默认选择反映的更多是一种偏见而非评估：云端API给人以”现代AI”的感觉，而Vision被视为”平台基础设施”，于是平台层就被跳过了。这种偏见误读了平台如今所包含的内容。

Vision是本地优先的CV框架。它在Neural Engine可用时运行于其上，否则运行于GPU，CPU作为最后的备选。大多数操作的推理仅需几毫秒。该框架每次调用零成本。数据从不离开设备。API密钥不存在，因为根本没有API存在。对于iOS应用所需的大多数计算机视觉工作而言，这就是正确的工具。

TL;DR

• Apple Vision提供两打以上的设备端CV操作：文本识别、人脸检测与关键点、身体与手部姿态估计、条形码读取、文档分割、图像嵌入、显著性、动物检测、轮廓、轨迹、光流，以及任意Core ML模型的运行器。
• 每个操作都在Neural Engine上以毫秒级速度运行，每次调用零成本，无需网络，不产生第三方遥测数据。
• 云端API在一种特定场景下胜出：对图像进行复杂的语义推理（多模态LLM理解图表、表情包或文档意图）。对于像素级操作（查找人脸、读取文本、检测手部），Vision在成本、延迟和隐私上都胜出。
• 智能体工作流的连接点：Vision的结果可以无网络往返地输入App Intents和Foundation Models设备端LLM调用。整条流水线都在本地运行。

Vision实际包含哪些内容

Vision将其操作归类为VNRequest类型。创建请求、配置参数、输入图像（或CVPixelBuffer、CIImage、CGImage、URL），然后运行。结果以观察值形式附加在请求上返回。下面的分类涵盖了截至iOS 26该框架的整体范围。

文本识别

VNRecognizeTextRequest执行OCR。该请求支持recognitionLevel（.fast用于实时摄像头流，.accurate用于文档扫描）、语言提示、自定义词表以及边界框置信度。iOS 18+上的.accurate路径在收据、标牌和文档上对印刷文本处理良好；手写识别在部分语言中受支持（参见Apple的识别语言列表³）。

let request = VNRecognizeTextRequest { request, error in
    guard let observations = request.results as? [VNRecognizedTextObservation] else { return }
    let lines = observations.compactMap { $0.topCandidates(1).first?.string }
    print(lines.joined(separator: "\n"))
}
request.recognitionLevel = .accurate
request.usesLanguageCorrection = true
request.recognitionLanguages = ["en-US"]

let handler = VNImageRequestHandler(cgImage: image, options: [:])
try handler.perform([request])

通过OpenAI Vision API执行同样的操作，低细节模式下每次调用约花费几分之一美分，高细节模式下显著更高，往返耗时1-3秒，并将图像发送至OpenAI的服务器。Vision在本地100-300毫秒内返回结果，免费，且无数据外泄。

人脸检测与关键点

Vision中包含三层人脸分析：

• VNDetectFaceRectanglesRequest返回画面中每张人脸的边界框。
• VNDetectFaceLandmarksRequest返回每张人脸的结构化关键点区域（下颌线、嘴部、眼睛、眉毛、鼻子、瞳孔），每个区域包含多个关键点。
• VNDetectFaceCaptureQualityRequest返回每张人脸的质量评分（0-1），反映光照、清晰度和居中情况。应用可以用它来把关自拍捕获，或从连拍中自动挑选最佳帧。

对于大多数需要查找人脸、按人脸裁剪、模糊人脸或统计人脸数量的应用而言，矩形请求就是合适的工具。对于需要将某些内容贴合到用户脸部的应用（滤镜、面具、追踪），关键点加瞳孔追踪才是合适的工具。这些都不需要模型文件或网络调用。

身体与手部姿态

VNDetectHumanBodyPoseRequest返回VNHumanBodyPoseObservation.JointName⁴中19个命名关节（鼻、颈、肩、肘、腕、髋、膝、踝、耳、眼、根部）的2D坐标和每个关节的置信度。VNDetectHumanBodyPose3DRequest将拓扑扩展到3D空间，返回VNHumanBodyPose3DObservation结果；该请求在设备暴露深度数据（AVDepthData）时会利用它来提升精度，但并不要求设备配备LiDAR扫描仪。⁴ VNDetectHumanHandPoseRequest返回手指关节级精度的21个手部关键点。

身体姿态正是健身应用用来在没有可穿戴设备的情况下计数动作的依据，也是AR应用用来将虚拟内容附加到用户手部的依据，更是体态应用用来评估姿势的依据。手部姿态驱动手势识别（用户竖起两根手指，应用识别出两根手指）。两者都能在近期的iPhone上以视频帧率运行，足以支撑实时AR和手势输入。云端等价物是Google MediaPipe或专有健身科技API，该框架可将其取代。

条形码与QR码

VNDetectBarcodesRequest读取大多数零售和库存工作流所需的码制（QR、PDF417、Aztec、Code 128、Code 39、EAN-13、ITF14、Data Matrix、GS1 DataBar等），并返回原始负载和边界矩形。检测在毫秒级完成，并且能在Apple自家相机应用已经验证过的低光条件下工作。

文档分割

VNDetectDocumentSegmentationRequest在画面中查找矩形文档并返回其角点，同时考虑透视。文档扫描应用正是用这一请求将文档裁剪并校正为平整图像。Apple自家的VisionKit框架封装了该请求并附带UI，但当应用需要自定义UI时，底层操作可以直接调用。

显著性与美学评分

VNGenerateAttentionBasedSaliencyImageRequest返回观看者视线最可能聚焦位置的热图。VNGenerateObjectnessBasedSaliencyImageRequest返回物体所在位置的热图。VNCalculateImageAestheticsScoresRequest作为公开API在iOS 18¹中加入，返回美学质量评分，包括功能性分类（备忘、截图）和美学价值。这些评分正是Photos用来推送”回忆”候选项以及自动裁剪决策所依据的内容。

图像分类与嵌入

VNClassifyImageRequest使用内置分类器返回图像的Top-N类别标签，覆盖数百个常见物体类别。⁵ VNGenerateImageFeaturePrintRequest返回特征向量（模型的嵌入），适用于图像相似度搜索。

嵌入正是Photos应用、菜谱应用的”查找相似菜品”或情绪板应用通过相似度去重的实际工作原理。云端等价物是OpenAI CLIP嵌入或Google的Vertex AI；Vision在本地免费返回这些嵌入。

物体追踪与轨迹

VNDetectTrajectoriesRequest跨帧追踪移动物体并返回抛物线轨迹拟合（投出的球、射出的箭）。VNTrackObjectRequest在视频序列中追踪手动指定边界的物体。

轨迹是体育应用的底层原语（追踪棒球、篮球、网球）。该检测可在实时AVFoundation流上工作并实时返回结果。

通过VNCoreMLRequest运行自定义模型

VNCoreMLRequest可通过Vision流水线运行任意Core ML模型。该请求会根据模型的输入描述自动处理预处理（图像缩放、色彩空间转换、归一化）。应用可以在Create ML中训练自定义分类器（少数几个类别，每类别一百张样本图像，十分钟训练时间），或下载已发布的模型，将.mlpackage放入应用包中，再用三行代码通过Vision运行。

let model = try VNCoreMLModel(for: MyClassifier(configuration: .init()).model)
let request = VNCoreMLRequest(model: model) { request, error in
    let results = request.results as? [VNClassificationObservation]
    print(results?.first?.identifier, results?.first?.confidence)
}
let handler = VNImageRequestHandler(cgImage: image, options: [:])
try handler.perform([request])

自定义分类器的云端等价物是把模型托管到服务器、为推理算力付费、管理API、并接受网络延迟。Vision把它变成了应用包中的一个.mlpackage文件加一个请求处理器。

云端API真正胜出的场景

Vision的领地是像素级操作：找到这个东西、给这张图分类、识别这段文本。该框架不提供对图像意义的复杂语义推理。云端API是正确选择的三种场景：

多模态LLM理解。 “这张图里这个人在做什么？”“这张图表是否有误导性？”“翻译这份菜单并告诉我哪些菜是素食。”这些都不是像素级问题。它们需要大型多模态模型将视觉感知与世界知识和语言相结合。Apple的Foundation Models（设备端LLM，详见Foundation Models设备端LLM）开始在设备上处理其中一部分，但对于复杂推理而言，GPT-4o、Claude Sonnet或Gemini仍然胜出。

没有训练数据的一次性自定义任务。 Vision的分类模型是固定的；自定义Core ML模型需要训练数据。多模态LLM无需任何带标注的训练样本即可回答”这是不是一只系着蝴蝶结的猫的照片？”。对于原型开发或一次性任务，当收集训练数据成本过高时，云端LLM才是合适的工具。

超越OCR的文档智能。 Vision的OCR返回文本。文档智能API（AWS Textract、Google Document AI、Azure Form Recognizer）则返回结构化字段：发票号、日期、明细项、合计金额。结构化才是其增值所在，而非OCR本身。对于高价值的文档工作流，云端API通常是正确选择；对于”读取这张收据并输出文本”，Vision才是。

规律是：云端在推理和高度专业化的垂直API上胜出；Vision在感知原语上胜出。

诚实的延迟与成本对比

在iPhone 16 Pro（A18 Pro芯片）上运行的代表性推理流水线：

上述数字源自Apple公开的基准数据和开发者报告的测量值；要传达的是数量级，而非确切数字。Vision的优势在于成本（每次调用为零）、尾部延迟（无网络抖动）和隐私（数据从不离开设备）。

当应用频繁调用视觉操作时，成本会累积。一个每会话处理100张图像的图片编辑应用，通过云端API每会话需花费数美元数量级的费用，而通过Vision则为零。

智能体工作流的连接点

Vision与已发布的两个集群想法搭配良好：

面向Apple Intelligence的App Intents工具。 当应用通过AppIntent暴露”在我的照片中查找人脸”或”从截图读取文本”的能力时，意图的执行方法在本地运行Vision并返回结构化结果。Apple Intelligence的编排器可以调用该意图，而无需将用户的照片发送到服务器。App Intents一文详细介绍了这一接口契约。

Foundation Models设备端LLM。 一条同时需要感知与推理的流水线先运行Vision（提取文本、查找人脸、定位物体），再运行Foundation Models（对所发现的内容进行推理、生成摘要）。两个阶段都在设备端运行。网络调用总数：零。Foundation Models一文解释了如何调用LLM；本文则论证Vision正是无云端往返地为其提供输入的那一环。

let textRequest = VNRecognizeTextRequest()
textRequest.recognitionLevel = .accurate

let handler = VNImageRequestHandler(cgImage: receiptImage, options: [:])
try handler.perform([textRequest])

let extractedText = (textRequest.results ?? [])
    .compactMap { ($0 as? VNRecognizedTextObservation)?.topCandidates(1).first?.string }
    .joined(separator: "\n")

let llmResponse = await foundationModel.generate(
    "Summarize this receipt as JSON with merchant, total, and date fields:\n\(extractedText)"
)

整条流水线都在设备上运行。无API密钥。无网络调用。无第三方数据暴露。

过去两个版本中成熟起来的能力

值得一提的三项新增，按Apple发布说明保守注明日期²：

美学评分作为公开API（iOS 18）。 VNCalculateImageAestheticsScoresRequest返回包含功能性分类和美学价值在内的评分，取代了照片整理类应用过去不得不通过自定义Core ML模型来近似实现的能力。

改进的多语言OCR。 VNRecognizeTextRequest在近期版本中扩展了对非拉丁脚本的支持，缩小了与历史上多语言覆盖更强的云端OCR服务之间的差距。Apple的文本识别文档列出了当前支持的语言³。

与VisionKit集成的文档分割。 VNDetectDocumentSegmentationRequest查找矩形文档并返回角点；VisionKit的VNDocumentCameraViewController在设计好的UI中为用户封装了文档拍摄，而DataScannerViewController（iOS 16+）则覆盖实时文本和机读码扫描。⁶

该框架的核心能力（人脸、文本、姿态、条形码、嵌入）在多个iOS版本中已趋成熟。规律是：扩展，而非重新发明。

为什么大多数开发者跳过Vision

尽管理由很清楚，但该框架仍被跳过，原因有三：

云端优先的习惯。 大多数现代AI开发首先针对云端API展开。开发者知道如何调用OpenAI；VNRecognizeTextRequest加上VNImageRequestHandler再加上VNRecognizedTextObservation这一表面区域感觉要学的API更多，而事实上按代码行数计算，比调用OpenAI Vision反而更少（无认证、无HTTP、无重试、无JSON解析）。

对能力的误判。 没有近期了解过该框架的开发者会认为它仅覆盖OCR和条形码。但上述类别清单包含两打以上的能力，其中数项没有云原生等价物，另有数项可在不付出成本的情况下匹敌商业API。

原型与生产的分歧。 云端API在早期原型阶段胜出（一条curl命令即可拿到结果），然后原型未经重新评估就被转化为生产流水线。正确的做法是用最快的方式做原型，工作流落地后对感知层重新评估。

修正之道不是拒绝云端API；修正之道是了解平台所包含的内容，从而让选择真正成立。

这一规律对iOS 26+应用意味着什么

三点要点。

1. 感知原语首选Vision。 查找人脸、读取文本、检测条形码、运行姿态估计、获取图像嵌入。该框架在Neural Engine上以毫秒级运行，零成本，不留下第三方数据痕迹。对于像素级CV操作，该框架是正确的起点。

2. 将云端API用于推理，而非感知。 多模态LLM理解图像意义、垂直文档智能API提取结构化字段、没有训练数据的一次性自定义任务。这些是云端的领地；将其交给云端是正确的。

3. 将Vision与Foundation Models配对，构建完整的设备端流水线。 感知（Vision）输入推理（设备端LLM）。流水线端到端在本地运行，无API密钥，无网络抖动，无遥测离开设备。集群中的Foundation Models一文涵盖了LLM那一半；Vision是输入那一半。

完整的Apple Ecosystem集群：类型化的App Intents；MCP服务器；路由问题；Foundation Models；运行时与工具LLM的区别；三个表面；单一事实来源模式；两个MCP服务器；Apple开发的钩子；Live Activities；watchOS运行时；SwiftUI内部构成；RealityKit的空间心智模型；SwiftData模式纪律；Liquid Glass模式；多平台发布；平台矩阵；我拒绝写的内容。中心枢纽位于Apple Ecosystem系列。关于更广泛的iOS与AI智能体上下文，参见iOS Agent开发指南。

FAQ

Apple Vision与visionOS有什么区别？

Vision框架是面向iOS、macOS和visionOS的设备端计算机视觉API。visionOS则是Apple Vision Pro的操作系统。命名上的重叠很不幸。Vision（框架）运行于每一台现代Apple设备；visionOS（操作系统）则专门运行于Vision Pro硬件。

我应该在什么情况下使用Vision而不是OpenAI Vision API或Google Cloud Vision？

对于像素级感知任务（查找人脸、读取文本、检测物体、统计数量、估计姿态、生成图像嵌入），Vision几乎总是正确的选择。它以毫秒级运行，每次推理零成本，并将用户数据保留在设备上。当任务需要对图像意义进行复杂的语义推理，或者垂直文档智能API能提供超越文本提取的结构化字段时，云端API才是正确选择。

我可以通过Vision运行自己的Core ML模型吗？

可以。VNCoreMLRequest可封装任意Core ML模型并自动处理预处理。将.mlpackage文件放入应用包中、实例化模型、用VNCoreMLModel封装、再通过请求处理器运行。同一个处理器可以并行运行多个请求，包括内置的Vision请求和自定义Core ML模型。

Vision在Apple Silicon上的调度机制是怎样的？

Vision（及其运行的Core ML模型）会自动调度：在Neural Engine可用时使用它，否则回退到GPU，CPU作为最后的备选。框架会为设备和操作选择最快的路径。对于大多数现代iPhone（A12 Bionic及之后），Neural Engine承担了推理的主体；开发者无需手动配置调度。

iOS 18和iOS 26有哪些新内容？

按Apple发布说明保守归纳：VNCalculateImageAestheticsScoresRequest作为公开API在iOS 18加入；VNRecognizeTextRequest在近期版本中扩展了多语言支持；VisionKit的DataScannerViewController（iOS 16+）覆盖实时文本和机读码，而VNDocumentCameraViewController覆盖文档拍摄。核心能力（文本、人脸、姿态、条形码、嵌入）在多个iOS版本中已趋成熟。

参考资料