先看证据
从“看图”转向给软件一个答案
TypeSafe AI于2026年10月14日发布Jev 1.14.0，并先通过`jev-preview`提供。Jev是该公司称为System One的决策模型：调用方提交`state`和一组带类型的问题，模型返回Choice、Score或Noul等结构化答案，而不是把生成一段文本作为主要接口。这次更新加入实验性图片输入、Box边界框问题类型，以及可选的262k上下文。
这次变化值得读的地方，不是模型终于能“看图”——TypeSafe说明Jev 1.13也已经支持图片输入——而是视觉定位开始接入原有的类型化决策接口。对于要把模型接入软件流程的团队，坐标和判断值比一段开放式描述更容易交给下游程序处理；但接口变得结构化，并不自动意味着结果可靠。TypeSafe把图片、Box和长上下文都标为实验功能，并明确表示尚未达到生产就绪标准。
Box把位置变成坐标，但不能说“没有”
图片通过请求顶层`assets`里的引用加入，再把引用放进`state`、`instructions`或`criteria`中；API会在模型读取前替换成图像。图片请求需要显式加入`TypeSafe-Danger-Zone-Images: true`。Box则要求调用方描述要找的目标，返回`top`、`bottom`、`left`和`right`四条边，坐标按图像宽、高归一化到0至1，并附带置信度。
这里有一个重要的接口缺口：Box每次都会返回一个框，即使目标实际上不存在，也没有“not found”这一答案。TypeSafe建议把定位与存在性判断拆开，用Noul问题先或同时检查目标是否存在，再决定是否采用坐标。这不是小小的调用细节，而是应用必须自己承担的逻辑：如果只消费Box输出，错误坐标可能会被当作有效定位传给后续步骤。
36张裁切图说明了什么，又说明不了什么
TypeSafe给出的Box测试包含36张目标被部分裁切的画作。用4个逐边Noul问题检查边缘，测试检出了30处裁切；用一个“目标是否完整在图内”的问题检出26处；先画出边框再询问则检出20处。这个结果支持一个有限判断：在这组样本和任务设定中，把完整性拆成多项边缘检查，比单一整体问题或对已画出的框提问更有效。
它不能证明Box在工业质检、零售货架或其他真实场景中有相同表现。测试是TypeSafe发布的内部小样本结果，不是独立复测，也没有给出可用于比较的公开基准分数。公司称Jev 1.14整体只有小幅改进、多语言提升可能最大，但公告没有提供具体分数表；其发布材料也提醒，图片任务表现弱于纯文本，并建议尽量提出简单问题。因此，30/36应当被当成设计测试用例的线索，而不是部署时可依赖的准确率承诺。
262k是输入上限，不是可靠性承诺
Jev默认每个请求最多64k tokens、每个问题最多32k；加入`TypeSafe-Danger-Zone-Long-Context: true`后，两项上限都可升到262k。这个开关也适用于Jev 1.13。换句话说，版本号容易掩盖真正的变化：图片输入并非1.14独有，长上下文也不是，而Box才是这次更新中特别需要1.14的能力。
更大的窗口解决的是“能否放进更多输入”，不是“能否在长输入里稳定判断”。TypeSafe称Jev等模型在长输入上可靠性会下降，仍建议使用较短上下文；这与Box需要额外存在性门控的限制相同，都是把可靠性责任留给调用方。图片仅支持静态PNG/JPEG，单图上限16 MiB，请求体上限32 MiB，图像边长需在256至1568像素之间。输入价格为每百万token 0.042美元，输出免费，但价格和容量都不能替代任务级评测。
适合先接入评测，不适合直接托付生产
对技术负责人来说，Jev 1.14最合理的试用方式，是把Box当作一种新输出类型接进现有决策流水线，而不是直接把它当成完整视觉系统。先拆清任务中的“目标是否存在”和“目标在哪里”，为两类判断分别设定可接受的误检与漏检，再用自己的数据测坐标误差、边界裁切和不同图像条件下的表现。TypeSafe的36张画作测试可以启发测试设计，却不能替代这些评测。
部署边界也很明确：三个新能力都要通过danger-zone请求头显式开启，官方称仍未达到生产就绪；模型目前仅通过TypeSafe托管API提供，参数量、开放权重及硬件变体没有披露。若团队无法接受托管依赖，或需要对视觉失败模式作充分审计，这些限制本身就足以影响选型。当前可执行的判断是：用预览版验证接口是否适合自己的工作流，把Noul存在性检查纳入设计，并在拿到自有评测证据之前，不把坐标或262k上下文当作生产保证。