多模态

一句话理解：多模态让图片、PDF、屏幕截图（以及部分模型中的音频）变成模型能“看到”的 Token；它打开了单据识别、界面操作等新场景，但也带来更高的成本、更多的误读和新的隐私风险。

大量关键信息并不在数据库里，而在图片和文件里：客户拍的商品破损照片、购物小票、扫描成 PDF 的发票、用户发来的聊天截图。销售团队的周报是带图表的 PDF，SEO 团队要看的是页面在手机上的实际渲染效果。如果 Agent 只能读文本，这些信息全都进不来。

这一课讲清楚：不同模态如何进入模型、各有什么限制与成本，以及对 Agent 设计意味着什么。

不同模态如何进入模型

模型处理的始终是 Token。多模态的本质，是把非文本内容也转换成模型能处理的表示：

以 Claude 为例（2026 年 9 月查阅官方文档）：当前所有模型都支持文本和图片输入、文本输出，PDF 通过 document 内容块输入。Claude 的 Messages API 不直接接收音频，语音场景通常先用语音识别转成文字。OpenAI 等厂商另外提供实时语音与转写类模型，适合语音客服这类场景，具体能力以各自文档为准。

向 Claude 发送一张图片，只需要在消息内容里加一个 image 块（可以用 base64、URL 或 Files API 的 file_id）：

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "image",
                    "source": {"type": "url", "url": "https://example.com/receipt.jpg"},
                },
                {"type": "text", "text": "这是一张购物小票照片。请提取订单号、商品名称和下单时间；看不清的字段填“无法识别”。"},
            ],
        }
    ],
)

官方建议图片放在文字问题之前效果更好；多张图片时，用“图 1：”“图 2：”这样的文字标签分别引出，便于在问题里指代。

限制与成本：必须心里有数

图片（Claude 官方文档）：

项目	说明
支持格式	JPEG、PNG、GIF、WebP（动图只取第一帧）
单张尺寸	最大 8000×8000 像素；单次请求超过 20 张图时，限制会更严格
单张大小	直接调用 Claude API 时 base64 编码后最大 10 MB
每次请求张数	最多 600 张（200K 上下文的模型为 100 张），但往往先触到 32 MB 请求体上限
Token 计算	按 28×28 像素图块计：约 ⌈宽/28⌉ × ⌈高/28⌉ 个视觉 Token
自动缩放	Claude 4.7 及之后的模型长边上限 2576 像素、最多 4784 个视觉 Token；其他模型长边 1568 像素、最多 1568 个视觉 Token

举例：一张 1000×1000 像素的图片约 1296 个视觉 Token；一张 4K 截图在高分辨率模型上会被缩放到上限，约 4784 个视觉 Token。一个每步都截图的浏览器 Agent，图片 Token 很快就会成为成本大头。

PDF（Claude 官方文档）：

项目	说明
大小与页数	请求最大 32 MB；每次最多 600 页（上下文窗口小于 1M 时为 100 页）
处理方式	每页转换为图像，同时提取该页文字，两者一起交给模型
Token 成本	文字部分通常每页 1500–3000 Token，另加每页图像的视觉 Token
注意	加密或有密码的 PDF 不支持；密集表格和大量图形可能在达到页数上限前就占满上下文

能力边界（官方列出的局限）：不能用来识别图片中的人是谁；低质量、旋转或很小（小于 200 像素）的图片容易误读；坐标和空间定位是近似的；数大量小物体时计数不一定准确；无法判断图片是否由 AI 生成。

对 Agent 意味着什么

多模态给 Agent 带来三类新能力，每一类都有对应的设计要点。

1. 读单据：把非结构化文件变成结构化数据。

售后处理中，客户上传商品破损照片和订单截图，Agent 提取订单号、判断破损程度、生成退款工单。这类场景要把多模态和 结构化输出 结合：

关键原则：图片里读出来的 ID、金额、日期，一律要回到系统里核对。 一个模糊的数字“8”被读成“3”，就是一笔错误的退款。

2. 看界面：让 Agent 操作没有 API 的系统。

很多老旧的内部系统、第三方后台没有 API，Agent 只能通过截图“看”屏幕、再点击和输入。这就是浏览器 Agent 和 Computer Use 的基础。它的代价是：每一步都要截图（Token 成本高）、界面一变就可能出错、速度远慢于 API。能用 API 就不要用截图，详见 三种执行方式 与 Computer Use。

3. 读图表与页面：让分析覆盖“视觉信息”。

SEO 诊断 Agent 可以对页面截图判断首屏布局、移动端是否有遮挡；销售分析 Agent 可以读周报 PDF 里的图表。但要注意：图表上读出的数值是估读，精确分析应该拿到底层数据，而不是让模型从柱状图上“看”出 17.3%。

设计要点

• 先问“有没有结构化数据源”。 能拿到原始数据、API 或文本版本，就不要让模型去读图片。
• 控制分辨率。 在保证关键文字清晰的前提下缩放和裁剪图片，既降低成本和延迟，也减少被自动缩放后文字变糊的风险。
• 大文件用文件接口。 多轮对话会重复发送历史；反复用到的图片和 PDF 上传一次，用 file_id 引用，避免每轮都把 base64 塞进请求。
• 敏感信息要处理。 截图和单据里常有手机号、地址、身份证号。上传前是否需要脱敏？存储和日志如何处理？这些要在需求阶段定下来。
• 给用户留一条修正路径。 识别结果要可见、可修改，尤其是会触发后续动作的字段。

常见误区

• “模型能看懂图片，所以 OCR 类需求直接交给它就行。” 模型在理解和容错上强于传统 OCR，但对模糊、倾斜、手写内容仍会出错，而且更贵。高量、格式固定的单据，专用 OCR 加规则校验可能更合适，两者也可以组合使用。
• “截图操作可以替代所有集成。” 它是没有 API 时的兜底方案，稳定性、速度和成本都不如 API。
• “PDF 塞进去就行，页数没超就没问题。” 密集表格和图形可能在达到页数上限前就撑满上下文；长文档先按章节拆分、只送相关部分。

产品经理检查清单

• 需求里有哪些信息只存在于图片、PDF、截图或语音中？有没有结构化的替代来源？
• 每类输入的典型尺寸、页数和日均数量是多少？折算成 Token 和成本是多少？
• 识别出的关键字段如何校验？识别失败时如何转人工？
• 输入内容中有哪些敏感信息？上传、存储、日志的合规要求是什么？
• 如果依赖截图操作界面，目标界面多久改版一次？失败时的兜底是什么？

练习

为「订单售后诊断 Agent」做一个单据识别小实验（约 45 分钟）：

1. 找 5 张不同质量的购物小票或发票图片（清晰、倾斜、局部模糊、手写备注、带反光各一张，可以用自己拍的小票并遮盖隐私信息）。
2. 用同一段提示词和结构化输出，提取订单号、商品名称、金额和备注。
3. 记录每张图的识别正确率和视觉 Token 数；把最大的那张图缩小一半再试一次，对比 Token 与准确率。
4. 写出两条“必须由程序校验”的规则，以及识别失败时的人工复核流程。

延伸阅读

• Vision：图片输入方式、尺寸限制、Token 计算与已知局限。
• PDF support：PDF 的处理方式、限制与成本估算。

下一步

了解了模型的各种能力和代价之后，下一课「模型选型与路由」讲如何在能力、延迟、成本与上下文长度之间做选择，以及大小模型如何搭配。