当 AI Agent 开始真正“动手干活”——改代码、改页面、生成图片、调配置——之后最让人不放心的环节往往不是它做不做得到而是它到底改了哪里、改成了什么样。SightDiff 这个项目的切入点很直接它不是再给你一段文字说明而是给你一张“改动前/改动后”的视觉证据让你亲眼看到 Agent 的操作结果。这句话值得展开讲。我见过太多 agent 项目能力演示得很漂亮一到真实任务就卡在验证环节Agent 说它完成了你怎么确认靠日志靠不住靠人眼盯也靠不住。SightDiff 的定位就是把你和 Agent 之间那层“信任黑盒”打开一条缝它用一个可对比的视觉结果回答“这次执行到底改变了什么”。1. AI Agent 越能干越需要证明“它到底改了什么”1.1 黑盒不是 Agent 的专利但 Agent 把它放大了传统自动化脚本——比如 CI 里的测试、定时任务里的批处理——也有黑盒问题但那个黑盒是可预测的脚本执行完你检查退出码、检查日志、检查输出文件基本就能定位。Agent 不一样它的执行路径不是预先写死的而是根据上下文和中间结果自己选择的。今天跑同一条任务它可能走 A 路径明天可能走 B 路径。这意味着你不能靠“脚本没报错”来判断结果你必须看产出物本身。SightDiff 解决的正是这个“看产出物”的环节。在 agent 开发里这一步通常叫验证但很多项目把它弱化成了“打印几行日志就完事了”。问题在于日志只能描述 Agent 认为自己做了什么不能证明它实际做了什么。1.2 为什么日志、git diff 和“跑通了”都不够这里要区分几种验证方式日志验证只能证明执行链路没有中断不能证明输出内容符合预期。git diff只能覆盖文本类变更无法覆盖渲染结果、视觉布局、图片生成、浏览器交互后的状态。“跑通了”验证没有标准定义往往是 Agent 自己说自己成功。SightDiff 补的是另一个维度最终视觉形态的差异。它关注的不只是“文件有没有变”而是“用户看到的界面、生成的图像、页面布局是否真的从状态 A 变成了状态 B”。这个维度恰恰是很多 AI Agent 工具在落地时最缺的一环。你可以在代码层面写一堆测试但 Agent 操作的是一个活生生的界面它打开页面、点击按钮、填写表单最后界面长什么样不是 await 一个函数就能确认的。在 agent 框架、MCP、agent 安全这些话题讨论得火热的当下真正面向“执行后可验证性”的工具反而显得稀缺。很多团队搭好了 Agent 的骨架却不知道跑完之后拿什么证明它跑对了。SightDiff 补位的就是这一层。2. SightDiff 的切入点给 Agent 的操作补上“视觉证据”2.1 它大概是怎么工作的虽然项目正文没有展开太多细节但从“before/after visual proof”这个定位可以推断它最常见的工作方式是这样的Agent 开始执行任务前先对目标环境做一次“快照”通常是一张截图或一组页面状态。Agent 执行任务期间可能发生多次页面变化、文件修改或资源生成。任务结束后再做一次同样的捕获。工具把前后两张快照对齐、比较把差异区域高亮出来输出一张可以给人看的对比图。这个流程听起来不复杂但真正要做好比大多数人想象得麻烦。比如两次截图的窗口尺寸、滚动位置、加载状态不一致对比就会失真又比如页面里有动态时间、随机广告、动画效果就算 Agent 什么都没做前后差异也会很大。SightDiff 如果要做得好就必须处理这些噪声而不是把两张图叠一起算个像素差完事。2.2 和 Git Diff、截图工具的区别在哪Git Diff 处理的是文本流适合代码仓库但不适合视觉结果。截图工具能帮你截图但不能自动告诉你“哪里变了”。浏览器开发者工具能检查 DOM但无法覆盖整个 Agent 工作流的前后对照。SightDiff 更像是把“截图”和“diff”组合成了一个专门针对 Agent 验证场景的产物。它服务的对象不是人肉对比而是沉淀成一种可读、可归档、可追溯的证据。放到 agent 开发、agent 安全、agent 可观测性这条技术路线上看它属于“执行之后的可验证性”这一层。这也是为什么它选择以 Show HN 的形式出现在大众视野里。因为社区里做 agent 项目的人几乎都碰到了同一个问题Agent 的执行结果是动态的、非确定的你拿什么判断它做对了有人靠 prompt 强约束有人靠测试用例有人靠人工抽查SightDiff 选择的是把“视觉差异”做成一个标准产物。3. 落地使用从一次验证到固定检查项3.1 最小接入流程如果要把 SightDiff 这一类方案接入自己的 agent 项目我建议按这个顺序来先跑单条任务。选一条最简单的 agent 任务比如“修改某个页面的标题文字”任务前截图一次任务后截图一次确认差异能正确标出。确认对比的稳定性。重复跑几次相同任务看看不改变任何东西时前后差异是不是接近零。如果噪声很大先处理窗口、滚动、动画、时间戳这些干扰项。把截图纳入 CI 或定时流程。不要每次手动点截图要让 agent 运行框架在关键节点自动触发捕获。最后才是批量。批量之前先把单条任务的误报率调到一个能接受的水平否则批量出来的对比图没人愿意看。这里有个关键点SightDiff 这类工具的价值只有在“自动化流程”里才能完全发挥。如果只是跑完任务后手动截两张图那用任何截图软件都能做到。它真正的意义是让“验证”成为 agent 执行链路上一个自动发生的步骤而不是事后想起来才补的工序。注意不要一上来就把批量数和并发数拉满先用一条样例确认输入、输出和日志都正常。3.2 怎么设置对比基线对比基线不是一个文件而是一组稳定的前置条件。常见需要固定的包括浏览器窗口尺寸和缩放比例页面进入时的初始路由登录态和用户权限本地 mock 数据或测试数据字体渲染、操作系统差异网络超时和动画时长在 agent 开发里“结果可复现”算是一个理想目标但实践中只能做到“在可控环境里可复现”。SightDiff 的对比结果也一样你必须先承认环境差异会影响视觉结果才能设计出真正有用的对比基线。3.3 输出结果怎么解读一张 before/after 对比图上一般会有三种区域无差异区域说明 Agent 没有动这一块。高亮差异区域说明这里发生了变化需要人工或模型判断是否符合预期。环境噪声区域可能是加载、动画、动态内容导致的不是 Agent 的产物。新手最容易犯的错是看到高亮就以为 Agent 改错了。不是高亮只代表“有差异”代表“需要被关注”。真正的判断还得靠人或者靠后续的规则。这也解释了为什么视觉证据工具不能完全替代测试断言它负责把注意力引导到值得看的地方但“什么算对”这件事还是要靠任务定义来回答。4. 最容易误判的几个环节4.1 环境的非确定性是最大的敌人Agent 任务天然有随机性页面渲染也有各种动态因素。同一个任务第一次跑和第二次跑可能因为字体加载顺序不同、网络请求返回时间不同就产生大量视觉差异。这些差异会直接污染 before/after 对比结果。处理思路通常是先把环境锁死。比如用无头浏览器时固定 user agent、固定视口、禁用动画和外部服务通信时优先用录制好的接口返回涉及时间的组件统一注入固定时间。锁得越死对比就越可信。但这不等于说你永远只能用固定环境。真实任务里Agent 面对的就是不可控的线上环境。这时候更多要靠“比较策略”来兜底不比较全页面只比较关键区域不比较原始像素先做结构化的 DOM diff或者用视觉相似度阈值而不是完全相等。4.2 时机问题截得太早等于没截另一个典型坑是截图时机。Agent 操作完页面后如果立刻截图可能页面还在加载中瀑布流图片还没出现弹窗动画还没结束。结果就是一个假差异或者假无差异。我一般建议在任务结束前加入一个“稳定等待”逻辑轮询页面状态等到没有网络请求、没有 pending 动画、或者等待一个固定时间之后再触发最终捕获。这个细节看起来小但往往决定了对比结果是否可靠。截图时机不是细节问题它直接决定对比结果是“证据”还是“噪声”。4.3 像素对比的局限纯像素级对比最容易出两类问题假差异一个 1 像素的抗锯齿差异被标成巨大红色区域人眼觉得没问题工具觉得大变了。漏检两个区域颜色不同但结构相同或者颜色相同但内容不同像素对比看不出来。成熟的方案一般会用“视觉特征 结构信息”结合的方式比如先做元素级定位再比较元素的位置、大小、文本和样式。但这类方案对工程能力要求更高。如果 SightDiff 只做像素级也是合理的起点——对开发者来说先把最简单的证据链建立起来再逐步优化精度比一开始追求完美更实际。4.4 出问题时怎么排查如果你发现 SightDiff 的对比结果不对可以按这个顺序查先看前后两张快照本身的成像质量。是不是模糊、黑屏、半加载状态、权限弹窗挡住了内容。再看环境参数。浏览器尺寸、设备像素比、滚动位置、截图时间点是否一致。再看任务本身。Agent 是否真的执行了预期操作还是中途失败但没报错。最后看工具的配置。阈值、忽略区域、对比策略是否覆盖了你的场景。这个顺序的核心逻辑是先排除数据采集层的问题再去怀疑 Agent 和工具。很多人一看到差异异常就改 Agent 的 prompt结果问题出在截图环境上白折腾一轮。5. 从“证明改过”到“能复盘”它真正的长期价值5.1 给 Agent 加一层“审计轨迹”一旦 before/after 对比图成为 agent 执行的固定产物你的项目就自动获得了一层审计能力。每次任务跑完不仅留下文字日志还留下可直观查看的视觉记录。这对 agent 安全和你接受度都很有价值尤其是在 agent 从“实验玩具”走向“生产工具”的过程中。很多团队不太放心让 agent 直接操作生产环境不只因为它可能出错更因为出错之后难以追踪。如果真的出了问题你可以翻开历史对比图像看监控录像一样定位是哪一次执行、在哪个环节、改了什么。这种“看得见的证据”比一万行 debug 日志更能建立信任。5.2 让“异常”变成一个可以讨论的产物没有视觉证据时Agent 执行异常往往只能靠一个人对着终端猜。有了对比图你可以把差异结果直接贴到 issue 里、发给同事、作为回归测试的附件。它不是最好的沟通方式但比“Agent 说它完成了但我觉得不对”要具体得多。实际落地时可以把对比图打包进每次任务的产物目录命名规则里带上任务 ID 和时间戳。后续复盘时按时间线翻目录就能把 Agent 的行为变化串起来。这个习惯一旦养成对 agent 项目的长期维护非常有帮助。5.3 沉淀成可复用流程这里我给出一个通用框架你可以照搬到自己项目里捕获在 agent 执行链路的关键节点自动触发前后快照。对比用稳定基线、忽略规则、相似度阈值过滤噪声。归档按任务 ID、时间、Agent 版本组织好对比产物。回顾每次模型版本或 prompt 更新后抽查对比图看行为是否符合预期。预警当差异区域数量或面积超过阈值时自动标记为待人工确认。差异区域多不一定代表 Agent 做错了只代表这里发生了变化需要被解释。这就是我理解的“SightDiff 这类工具真正带来的变化”它把一次性的“验证行为”变成一个持续运行的“验证机制”。你不再需要每次人工确认 Agent 做了什么因为每次执行都会自己留下一份可以回溯的证据。6. 适用边界和选型思路6.1 它适合谁在做 agent 开发、agent 框架、agent 平台的人。你需要一种通用方法向使用你的人证明“Agent 确实产出了预期结果”。做浏览器自动化、UI 自动化、端到端测试的团队。这类团队本来就很依赖截图对比SightDiff 可以作为 agent 场景下的新工具补充。做 AI 内容生成、AI 图像工具链的人。如果 agent 会生成图片或修改视觉资源前后对比能帮你快速判断风格、构图、内容是否偏离预期。6.2 它不适合谁纯后端 agent。如果 agent 只改配置文件、数据库记录、API 调用视觉对比几乎没有意义应该用结构化 diff 和断言。对实时性要求极高且没有稳定环境的场景。如果你的页面充满动态广告、实时推送、随机内容那视觉对比的噪声可能比信号还大需要投入大量精力做屏蔽。只想“证明成功”而不想真正验证的团队。如果只是为了演示视频好看视觉证据工具帮不了你长期建立质量体系。6.3 选型时看什么选这类工具时我建议先看四个能力快照捕获是否支持稳定的环境控制比如视口、设备比例、等待策略。对比算法是否有忽略区域、阈值设置、元素级定位能力。产物是否方便归档和分享比如是否能输出标准化图片和 JSON 元信息。是否能接入现有 agent 框架和 CI 流程而不是一个孤立的命令行工具。如果你的场景要求高还可以进一步考虑是否支持 DOM diff、OCR 文本对比、模型辅助判断差异是否合理。但前提是先把最基础的截图证据链路跑通否则一切高级功能都悬空。7. 我的几条落地建议前面这些内容其实可以浓缩成一套我自己的落地顺序。不管你是自己写一个同类工具还是打算把 SightDiff 集成到现有 agent 流程里我建议都按下面这个顺序走。7.1 第一条建议先用一条最小任务建立证据链先别急着追求全自动。选一条最简单的 agent 任务比如“把页面标题改成另一个文案”然后只做三件事任务前截图、任务后截图、人工确认差异区域是否准确。这一步的核心不是跑通工具而是建立一个你能理解的最小证据链。如果这一步看着都对再往自动化上靠。7.2 第二条建议环境稳定性优先于功能丰富度一个对比工具哪怕支持 20 种差异算法如果前后截图之间带着大量环境噪声它输出的结果还是不能看。所以我会优先处理窗口尺寸、设备像素比、滚动位置、等待时间、动画开关、动态数据注入这些基础变量。环境越稳定后面的阈值和忽略规则才有意义。7.3 第三条建议把工具当行车记录仪而不是裁判视觉对比图的职责是记录“发生了什么”而不是判定“这件事做得对不对”。判定对不对需要结合任务定义、断言规则、甚至人工审查。团队如果指望一个截图对比工具就能保证 Agent 行为全对那多半会在复杂任务上失望。更好的分工是SightDiff 负责把差异暴露出来断言和评审负责做最终裁决。7.4 第四条建议从第一天起就归档不要等到出问题再补哪怕只是测试环境跑了几次任务也建议把对比图按任务 ID、时间戳、Agent 版本归档起来。数据积累得越早后面做回归对比、模型迭代评估、异常溯源时就越省力。很多团队的问题是工具链都有了但没有历史数据可查出了事故只能悔不当初。7.5 最后一条把这个方法内化成团队习惯真正有价值的不是某一次对比图而是团队形成一种习惯任何 agent 执行任务都要有可看见的产物、可追溯的记录、可讨论的差异。工具可以换这个习惯不能丢。这也是我写这篇文章最想强调的一点SightDiff 代表的是一个方向——让 AI Agent 的执行结果变得可见、可审、可复盘。对我个人来说这类工具最打动我的点不是技术细节多么精巧而是它把一个常识带回 AI Agent 的开发里如果你想让别人信任一个能自主行动的软件你至少要能清楚地展示它做了什么。SightDiff 没有去解决“Agent 是否正确思考”这种大问题它只解决了一个更朴素的问题先把改动摆到明面上。但这个朴素的起点可能正是 agent 走向生产环境之前最值得补上的一环。