multimodal/前几篇介绍怎样传图片、识别文字、读取图表和处理多页文档。单独看都像 API 教程直到crop_tool.ipynb才把共同的问题说清图片已经传给模型不代表图中的信息已经进入模型可判断的尺度。视觉调用会把图片压进有限的视觉 token。图越大、内容越密每条线、每个字占到的表示空间越少。此时继续强调“仔细看”没有用因为缺少的不是注意力指令而是分辨率。这个目录后半段所做的事情都是由程序重新安排模型看图的尺度和顺序。全图和细节不能同时保住模型需要全图理解结构也需要局部高分辨率辨认细节。把整张图缩小后发送结构还在细节可能已经不可恢复直接切成许多局部图细节保住了模型又不知道每块在全图的什么位置。crop_tool保留两份图一份是高分辨率原图只供裁剪另一份提前缩放到模型实际接收的尺寸用作首次观察和坐标系。模型先看缩放后的全图判断哪里需要细看再调用zoom(x1, y1, x2, y2, image_index)程序把模型给出的坐标映射回原图截取那个区域将裁剪结果放大到视觉 token 预算允许的最大尺寸然后作为工具结果送回模型。模型可以继续缩小范围直到读清标签或线条关系。模型返回的是它所见缩放图上的像素位置不是原图坐标。notebook 在上传前主动使用resized_size()生成与服务端一致的缩放结果使模型坐标与本地缩放图一一对应工具随后再按两张图的尺寸比例映射回原图。如果直接拿模型坐标裁原图图片越大裁剪位置偏得越远。所以“放大镜”不只是一段图片裁剪代码。它建立了一个闭环全图定位 → 请求局部 → 原图裁剪并放大 → 重新观察 → 回答或继续裁剪模型决定下一步看哪里程序保证坐标、像素和预算正确。视觉能力从一次识别变成了主动取证。提示词修不好已经丢掉的像素notebook 构造了一张多折线图问第 48 个月 Widget-A 与 Widget-E 哪条更高。两条线在完整渲染图上只差约 8 个像素小于一个 28×28 视觉 patch附近还有一次真实交叉。单次看全图时模型在 40 次测试中答错 36 次允许反复裁剪后40 次全部答对。公开的 Chartography 测试也显示相同趋势。在 100 个密集图表问题上一个模型从 29% 提升到 73%另一个从 13% 提升到 44%。但每题平均成本也分别从 0.08 美元升到 0.95 美元、从 0.02 美元升到 0.64 美元。每次放大都会把已有对话和新的裁剪图再次送入模型准确率来自更多观察不是免费增加的能力。放大也有上限。同一条近距离交叉线较小模型即使有工具十次只答对一次。裁剪能恢复被缩放压掉的像素却不能替模型完成几何判断。这个区别很重要如果问题来自信息没进入输入应改造观察方式如果清晰局部已经给到模型仍判断错误继续裁剪不会解决推理能力不足。视觉 prompt 的作用因此有明确边界。要求逐项检查、规定输出格式、提供少量示例可以改变模型处理已经看见的信息的方式它们不能恢复缩放时消失的文字和线条。前几篇 notebook 主要在改“怎么看”crop_tool开始改“实际给它看什么”。多页文档的分工改变了信息边界using_sub_agents.ipynb用另一个办法处理视觉容量把 Apple 四个季度的财报 PDF 分给四次 Haiku 调用并行读取再把四份抽取结果交给 Opus 汇总。每个 worker 只看一份文档输入更短总处理时间也更低。保存下来的输出暴露了这种切分的代价。问题要求比较 2023 财年各季度的环比变化但单个 worker 只拥有一个季度报告。报告中的比较列可能是上年同期也可能是累计六个月数据而不是上一个季度。结果里出现了这些判断Q3 把 2023 年 7 月与 2022 年 6 月的数据称为 quarter-over-quarterQ2 将三个月的 94,836 与六个月的 97,278 相减Q1、Q4 同样把同比数据写成季度环比。最终 Opus 没有回到原表核对而是把四份局部结论整理成一段流畅的年度趋势。并行调用提高了吞吐量却让跨文档关系断在了 worker 边界上。问题并非“子模型不够强”而是任务切法与问题结构冲突。抽取“每份报告中的净销售额”可以按文档并行判断“季度之间如何变化”需要把四个季度放进同一个可比较结构后再计算。更稳妥的接口应该让 worker 只返回quarter period_start period_end period_type net_sales source_page汇总阶段再检查四行是否都是单季度口径按日期排序后计算环比。跨文档结论不能由各自只见一份文档的 worker 提前生成。这个例子说明图片切块、PDF 分页和多 Agent 分工本质上在做同一件事决定哪些信息能在一次判断中同时出现。边界切错以后每个局部答案都可能成立组合起来却回答了另一个问题。视觉系统要管理观察过程multimodal/真正值得留下的不是“模型可以读图片”而是视觉输入同样需要调度。系统必须决定先给全貌还是细节什么时候增加分辨率长文档按页、按文档还是按问题拆哪些关系必须在同一个上下文里比较。crop_tool的亮点在于把不可见的细节变成一次可执行动作模型指出区域程序从原图取证再让模型判断。using_sub_agents则留下了相反的提醒把材料分开读取很容易把分开的事实重新组成同一口径的问题要难得多。因此评测视觉系统时不能只问最终答案对不对还要检查观察轨迹模型最初收到的图被缩到多大裁剪坐标是否落在正确区域关键细节是否真的进入后续上下文跨页和跨文档比较是否拥有共同口径。模型看到的世界不是上传文件本身而是这条处理链最终让它看见的部分。