DeepSeek 给 Code Agent 装上「眼睛」后，谁来验收它点过的每一个按钮？

Sun, 23 Aug 2026 10:00:00 +0800

8 月 21 日，DeepSeek 在 API 更新日志里加了一个实验性模型：deepseek-v4-flash-vision-exp。

它能理解图片和视觉输入。公告列出了 Terminal Bench 2.1、NL2Repo、DeepSWE、AutomationBench 等 Agent 基准测试（benchmark）的分数，也说它在需要视觉理解的 Agent 测试中接近 Opus-4.8。后半句先放在这里：这是 DeepSeek 自己的测试口径，不是第三方把它和所有竞品放进同一套真实任务后得出的结论。

模型更新的新闻很容易被压缩成一句话：国产 Code Agent 也开始「看得见」页面了。

可屏幕看得懂，离任务真的做完，中间还隔着一段不短的路。

一个 Agent 看见支付页面上的按钮，能认出它叫「确认支付」，不等于它应该点；即使允许点，也不等于它点的是测试订单；就算请求返回了 200，也不等于钱、权限或订单状态都落在了正确的地方。过去做 AI 编程，我们主要盯着代码和测试。视觉输入进来后，屏幕本身也成了需要验收的对象。

会看页面，不等于拿到了操作权限

这几个概念很容易被混在一起，先拆开说。

视觉理解（vision understanding）处理的是输入。给模型一张截图、一个设计稿，或者一段录屏中的几帧画面，它可以识别文字、控件、图表关系和页面状态。它能告诉你：弹窗里是不是报错了，按钮为什么置灰，表格少了哪一列，预览页和设计稿差在哪儿。

工具调用（tool use）处理的是动作。模型能不能点击、输入、执行命令、上传文件，不看它有没有视觉能力，要看宿主程序给了什么工具。没有浏览器工具、网络权限或文件系统权限时，它最多是一个会描述页面的观察者。

真正容易出事的是第三层：运行环境。

测试容器、隔离浏览器 Profile、staging 环境和生产账户，页面往往长得差不多。区别不在屏幕上，而在一次点击之后。预览页上点错，通常重跑就行；带着真实登录态进后台点错，可能会发邮件、改角色、删数据，或者提交一笔本不该提交的付款。

DeepSeek 的发布页其实也给了一个提醒。官方将 V4-Flash-Vision-Exp 定义为实验性 API 模型，调用名是 deepseek-v4-flash-vision-exp。在公开 Code Agent 文本任务的测试里，DeepSeek 使用了 Harness 的 minimal mode，固定 max effort、topp=0.95、temperature=1.0 等条件。很多人会先看分数，我更在意这个脚注：模型不是脱离环境跑出来的，harness（运行时框架）、工具配置和参数，都会影响它最后能完成什么。

图源：DeepSeek V4-Flash-Vision-Exp 发布说明。图中分数为 DeepSeek 官方公布口径。

把视觉模型接入工作流，也一样。模型多了读页面的能力，不代表账户权限、浏览器隔离、业务规则和人工确认已经跟上。

测试全绿，可能只说明代码没问题

传统代码任务的验收路径相对明确。看 diff，跑单元测试，等 CI，必要时开预览环境。它们回答的是「这次代码改得对不对」。

界面任务会多问几句。

假设 Agent 收到一个很普通的需求：修复结算页在窄屏下被遮住的优惠券输入框。它看了截图，改了 CSS，构建通过，单测也绿了。这当然是好消息，却还不足以交付。

输入框在常见的手机宽度下真的可见吗？错误提示出来后，焦点是否还停在合理的位置？键盘用户能不能继续填？这个页面用的是假订单，还是带着真实支付 Provider 配置？如果 Agent 为了验证真点了「确认支付」，请求又发到了哪里？

这些问题并不要求模型再聪明一点。它们要求团队把「完成」说得更具体。

我会把多模态 Agent 的验收拆成五层：

验收层	要确认的事	常见证据
代码变更	修改是否在允许范围内，逻辑是否符合预期	diff、代码审查、静态检查
程序行为	改动有没有破坏已有功能	单元测试、集成测试、构建结果
界面状态	用户实际看到的页面是否正确	截图、DOM 快照、视觉回归结果
账户与权限	Agent 以谁的身份、在什么环境里做事	Profile、环境标识、授权记录、请求目标
外部后果	操作是否真的改变了外部世界	审批记录、API 回执、业务审计日志

前两层，工程团队已经很熟。难点常在后三层。

视觉回归测试能告诉你按钮有没有跑偏，却回答不了 Agent 是否继承了管理员登录态。API 返回 200，说明请求成功了，却无法保证它发给了正确的客户、正确的工作区，或者正确的环境。页面看着安静，后面可能连着一整套权限和业务状态。

因此，「截图看起来没问题」只能算一条证据，不能当验收结论。

不必搭大平台，先把证据留住

多模态 Agent 不需要等到有一整套新平台才能落地。很多团队从现有的浏览器测试、日志和审批流里，就能开始补证据。关键不是记录一切，而是别让改变状态的步骤变成黑箱。

任务范围要落到环境和账户

「帮我检查后台支付流程」这种任务，对人来说都太宽，更别说交给 Agent。换成「只读访问 staging 的结算预览页，不登录生产账户，不提交表单」，边界才真正出现。

视觉任务里的范围不只是文件路径。允许访问的 URL、账户、租户、浏览器 Profile、能不能上传文件、能不能发网络请求，都应写在任务里。它们还可以变成运行时规则：访问的域名不在 allowlist（允许列表）里，或者页面带着生产环境标识，就暂停，不要顺着上下文继续尝试。

让它展示前后状态

Agent 写「已修复」或「已检查」时，最好带着可回看的东西。

界面检查可以留下前后截图，或者保存 DOM 快照和关键元素的可访问性信息。目的不是攒图，而是让 review 时能对照：它一开始看到了什么，改完后哪些东西变了，页面是否处于预期状态。

动态页面尤其不能只看一帧。加载完成、错误提示、提交后的跳转、慢网下的骨架屏，都是不同状态。任务一开始就该说明哪些状态必须覆盖。否则，Agent 很容易在第一张「看起来正常」的截图上结束。

状态变更要能追溯

点击、输入、上传、调用 API，不必全都变成冗长录像。但提交、删除、授权、发布、对外发送、写入共享数据这些动作，应该能回到一项任务。

至少要知道：它在什么时间，以什么身份，对哪个对象，用了什么参数，得到什么结果。操作日志里保留目标 URL 或资源 ID、身份、请求结果和任务 ID，排查时才不至于只对着截图猜。

有了这条线索，才分得清问题是 Agent 点错了页面，还是页面本身读了旧缓存。两种情况看上去可能一样，修复方法却完全不同。

真正有后果的动作，别省掉确认

Anthropic 的 Computer Use 文档把边界说得很明确：财务交易、同意条款等需要肯定性同意的事项，应交给人确认；敏感数据访问和互联网暴露范围也应收紧，以降低提示词注入（prompt injection）的风险。

这不是某一家产品才适用的规矩。支付、授予权限、发消息、生产发布、删除云资源，无论是哪一个模型发起，出了问题都很难靠一张截图复盘。视觉能力让 Agent 接触到更多界面，反倒更需要把确认点放稳。

一个有用的确认框，展示的也不应只有「是否继续」。人需要看到它将在哪个账户执行什么动作，影响哪些对象，能否撤回，预期拿到什么回执。确认的是后果，不是替模型逐字审阅一段计划。

从「看」到「动」，中间留一段缓冲

一上来就把视觉 Agent 放进真实后台，通常没有必要。

先做只读观察就够有价值。它可以对照设计稿和 staging 截图，筛出视觉回归失败的页面，帮你找出仪表盘里异常的数字，或者从图表中提取需要人工确认的变化。它不需要生产登录态，也不需要写入权限。

图源：DeepSeek V4-Flash-Vision-Exp 发布说明。该图用于展示官方所述的多模态 Agent 使用场景，不代表本文对实际安全性或效果的独立测试。

接下来才是隔离环境里的可逆操作。让 Agent 在临时 worktree（独立工作树）里改布局，在一次性测试账户中填模拟表单，或在可重置的 preview 环境里跑浏览器测试。此时最重要的不是让它跑得越快越好，而是判断错了也可以把环境丢掉、把数据还原、把改动撤回。

再往前一步，进入带审查的预览。Agent 把变更、截图和测试结果交给开发者或业务人员。设计问题看视觉差异，流程问题看状态转换和文案，权限敏感的操作则确认目标账户和影响范围。

外部动作放到最后。Agent 可以先生成发布草稿、填好待提交表单、写出迁移计划和 dry run（试运行）结果。真正发出、提交、授权或删除之前，停下来等人。

这和《给 AI 编程 Agent 加一张可逆性验收表》里谈的范围、快照、回滚是一条线上的事。只是多模态任务多了一个以前没那么显眼的验收面：屏幕状态。代码 diff 告诉你改了什么，快照和回滚告诉你错了怎么回来，界面证据则让你知道用户或操作员最后看见了什么。

先拿哪些任务试水

低风险试点不等于做玩具演示，很多日常工作本来就适合放在受控环境里。

视觉回归排查是一个好起点。Agent 对比一批截图和基线，标出导航错位、文字溢出、按钮缺失，再由开发者确认哪些是真问题。它节省的是人工筛图的时间，并不直接碰用户数据。

表单和页面状态检查也适合。比如在 staging 里走必填项提示、禁用状态、空数据页和错误页。完成条件可以写得很实在：覆盖哪些页面状态，保留哪些截图，失败时返回怎样的结构化结果。

还有一种经常被忽略的用法是只读巡检。让 Agent 用受限 Profile 查看监控面板、发布后台或文档站，发现不一致就创建内部工单，但不能修改配置、点击发布或读取机密。这样既能利用视觉理解处理难结构化的界面，也把高后果动作隔在外面。

以下几类事情，别因为模型「看得懂」就直接交出去：

使用真实账户完成支付、退款、采购或签署条款；
给用户、服务或 Agent 增加权限；
处理包含登录凭据、身份证明或隐私数据的页面；
在生产环境发布、删除、迁移或批量修改；
把页面、截图或表格上传到模型和工具链之外。

它们的麻烦通常不在图像识别，而在授权、数据边界和恢复成本。模型可以参与准备和解释，真正的动作应该放在更严格的环境、审计和人工确认里。

看见只是开始

DeepSeek 这次更新，让 Agent 可以理解更多原本藏在屏幕里的信息。读网页、看设计稿、处理图表、检查桌面状态，这些工作确实会因此少绕几步。

但模型看懂什么，和它能做什么，仍然是两回事。

模型负责理解屏幕、提出下一步；工具权限决定它能不能点击、输入、上传或调用外部系统；验收系统把「它说做完了」变成可检查的 diff、测试结果、界面状态和审计记录。至于不可逆、影响他人权益、会改变真实世界状态的动作，最后仍然要有人承担判断。

视觉能力没有替代这些环节，反而把它们推到了更前面。真正成熟的多模态 Agent 工作流，不是模型看到按钮就自己按下去，而是团队能回答四个问题：它看见了什么，准备做什么，做完怎样证明结果正确，出了错能不能回来。

扩展阅读

DeepSeek V4-Flash 正式版之后，AI 编程该按任务分层，而不是按模型站队：讨论不同风险和验证条件下的模型任务路由。
给 AI 编程 Agent 加一张可逆性验收表：讨论高后果操作的范围、快照、回滚和恢复证据。

参考来源

以上来源用于核对 DeepSeek 的发布口径、API 能力边界和计算机操作的通用安全建议。DeepSeek 公布的 benchmark 与「接近 Opus-4.8」均为厂商自述，不等同于独立第三方测试；文中关于验收流程的建议属于工程实践分析，并不构成对任何模型或产品安全性的保证。

多模态AI on 奇诺分享 | 重在分享