最近看到一个叫 Remarc 的项目它的定位一句话就能说清对屏幕上任意内容做注释然后发送给你的 agent。乍一听好像只是截图标注加了个发送按钮但如果你真的调试过界面问题或者正在做 agent 开发就会明白这背后解决的是一个真实存在的痛点。大概半年前我帮朋友调一个数据看板的前端问题。页面上的图表在特定屏幕宽度下会错位截图发过去之后我在文字里反复描述“图例盖住了坐标轴”对方还是很难定位。最后是我在截图里画了两条红线标出“这个区域叠到那个区域上面了”问题才被一眼看清。后来我一直在想这类“指给 agent 看”的交互是不是被严重低估了。这篇文章想拆清楚三件事Remarc 这类工具到底解决了什么老问题、它的完整链路依赖哪些环节、以及如果你自己也在做 agent 开发或屏幕交互类产品有哪些设计取舍和坑值得提前知道。1. 为什么“把屏幕上的问题交给 agent”这件事一直在绕路1.1 你看到的是像素agent 收到的是文字先回到一个最基本的现实人类理解屏幕是整体性的。一个按钮颜色不对、一个弹窗遮挡了关键内容、一张报表里某个数字明显异常你的眼睛能在几毫秒内锁定目标。但要把这个发现完整地告诉 agent你需要把它翻译成一段文字。这个翻译过程会丢失很多东西。比如我见过最常见的描述方式“你帮我看一下这个页面好像有点问题。”这句话对 agent 来说信息量几乎为零。稍微好一点的描述是“页面右侧的导航栏在小屏模式下把内容挡住了。”但还是不够因为 agent 需要知道是哪个页面、什么尺寸、右侧导航栏具体叠到了什么位置。而如果直接把整张截图发给 agent新问题又出现了截图里什么都有agent 需要自己猜测到底哪里才是你真正关注的重点。注意力一分散输出质量就会下降。Remarc 的解法是让用户在视觉本身上面做标记。这个交互方式并不新——人类在纸面审阅、设计走查、代码评审里已经用了很多年。真正新的是它把“注释”和“agent 执行”直接连了起来。1.2 上下文转换的损耗才是真正的瓶颈如果只把 Remarc 理解成“一个更好用的截图标注工具”那就低估了它。更准确地说它是在解决上下文转换的损耗问题。在 agent 工作流里信息要经过多次转换从屏幕像素到人类的观察到文字描述到 agent 的输入上下文再到执行动作。每一次转换都可能丢信息、加噪音、引入歧义。Remarc 想做的事发生在“人类观察”和“agent 输入”这两层之间尽量把描述性损耗压到最低。从工程经验看这类工具能不能用得好往往不取决于标注功能本身而取决于后面那个转换环节做得够不够扎实截图里的标注坐标能否被准确映射到原图、注释文本能否和视觉区域绑定、发送给 agent 时上下文结构是否清晰。所以单看“在屏幕上画个圈”是很轻的功能但“画完圈之后能变成一个可执行任务”才是重活。2. Remarc 这类工具真正改变的不是“截图”而是输入方式2.1 一条从屏幕到 agent 的完整链路按这类工具的常见设计一次典型使用会经历四个环节捕获屏幕截取当前屏幕或选定区域生成图像输入。叠加注释用户在截图上划线、画框、贴文字或做高亮形成一层注释标记。组装上下文系统把截图、注释的坐标与文本、以及用户补充的指令一起打包。发送给 agentagent 收到后结合视觉信息与文本指令生成回复或执行后续操作。这四步听起来简单但每一步都可能出问题。捕获环节要处理多显示器、系统权限、缩放比例注释环节要确定坐标基准组装上下文时要注意 token 大小和描述顺序最后一步还要决定 agent 是只返回建议还是能主动操作其他工具。如果你准备搭一个类似的工具链建议先把这四步链路在纸上画出来再决定哪些自己做、哪些用现成服务。很多人一上来就纠结“用哪个截图库”“要不要做实时画面监听”反而忽略了核心链路是否完整。2.2 先跑通一轮最小闭环再谈自动化我更建议先从一次手动任务开始验证而不是急着做自动化。一个最小可用的流程是这样的手动截一张图保存为本地文件。用一个简单的图像标注工具在图上加注释导出为新的图片或注释 JSON。把图片和注释一起交给支持视觉输入的 agent 模型让它识别注释指向的区域并回答问题。检查输出它有没有理解你圈出来的对象回答是否基于截图内容而不是泛泛而谈这个最小流程不需要安装复杂的系统核心目的只有一个验证“带注释的视觉输入能不能被 agent 正确理解”。如果这条链路能跑通再考虑桌面级屏幕捕获、实时标注、一键发送这类工程化能力。2.3 为什么“先跑通一次”能省下大量排查成本原因有两个。第一视觉注释能不能被正确理解本质上是个模型能力问题不是工程问题。先跑一次能尽早验证最不可控的环节。如果模型连“圈出来的那个红色报错框”都看不懂后面做得再顺滑都没有意义。第二很多工具在“单流程演示”里没问题但一旦真实使用就会暴露出截屏权限没给、缩放后坐标偏移、注释和图像没有正确叠加、发送给 agent 时把关键信息截断等问题。先跑通一次可以把这些“看起来小但决定性”的坑提前暴露出来。注意不要一开始就追求“全自动监听屏幕 自动发送”。先手动完成一次完整闭环再逐步自动化排查成本会低很多。3. 给 agent 开发者的启发输入侧是 agent 架构里最被低估的一环3.1 多数 agent 项目的输入边界还停留在文本框这几年做 agent 开发的人越来越多但大家讨论的焦点大多集中在模型选型、工具调用、记忆机制、多智能体协作这些环节上。输入侧反而很少被认真设计。很多 agent 项目本质上还是一个“文本框 系统提示词”的壳子用户输入文字agent 调用工具返回文字。这带来一个很有意思的现象agent 的工具越来越强但它在“理解用户到底想要什么”这件事上却经常卡在最前面。Remarc 这类工具给 agent 开发者提了一个醒输入不只有文字这一种形态。屏幕、图像、注释、语音、操作轨迹都可以成为 agent 的上下文来源。如果你正在做一个面向真实用户的 agent可以问自己一个很具体的问题你的用户在使用中是更容易“说清楚”问题还是更容易“指出来”问题如果是后者那么屏幕级输入就值得排进你的路线图。3.2 一个可复用框架从屏幕到 agent 的四层设计把 Remarc 这类产品拆开可以提炼出一个通用框架适合任何需要把视觉观察转成 agent 任务的产品第一层信号层。决定捕捉什么是全屏、窗口、某个区域还是多屏拼接。第二层表达层。决定用户怎么标记重点是画框、画线、高亮还是只发截图。第三层结构化层。把图像、坐标、文字指令组装成 agent 可消费的上下文并控制体积和顺序。第四层执行层。决定 agent 收到之后是分析、修改代码、回复文本还是继续调用其他工具。这四层之间是解耦的。你的产品可以只在某一层上做创新其他层用现成组件。也就是说你不需要从零做一个完整系统也可以尝试这个方向。3.3 三种典型接入方式与一条选型建议从实现难度由低到高有三种常见的接入思路接入思路实现成本可控性适合场景离线一轮式低低快速验证、内部小工具结构化注释式中中产品化、多轮交互、日志分析Agent 工作流式高高自主任务助手、复杂工作流建议根据你的目标场景选择如果只是快速验证选第一种如果要做产品至少做到第二种如果目标是打造一个能自主完成任务的助手再考虑第三种。不要一开始就做最重的那套容易陷入工程细节而迟迟出不了结果。4. 落地屏幕注释类功能时会踩的坑4.1 权限、隐私和敏感信息是前置条件屏幕捕获最大的麻烦不是技术而是权限和隐私。在桌面端截图会带走用户当前屏幕上的一切内容包括那些用户根本没打算交给 agent 的信息。如果产品要上线至少要处理三件事明示捕获范围让用户知道自己截的是整个屏幕、某个窗口还是选定区域。提供敏感信息遮蔽在发送前允许用户框选、模糊或裁掉不想分享的区域。明确数据传输策略截图是否上传服务器、是否保留、是否用于模型训练都要有清晰说明。隐私处理不是附加功能而是用户决定是否使用这类工具的前置条件。这一条如果没想清楚功能做得越好风险反而越大。4.2 注释坐标与视觉对齐最容易出错的一环很多人第一次做截图标注时会低估坐标对齐的坑。常见的坑包括截图时的 DPI 缩放和实际显示尺寸不一致导致标注坐标偏移。注释层和截图没有使用同一个坐标基准画圈的位置和图像里的实际区域对不上。多显示器时副屏的坐标可能是负数处理不当会让 agent 收到错误的位置信息。用户截完图后窗口移动了但坐标仍然是旧的位置导致后续操作错位。从工程经验看最简单可靠的方式是把注释直接烘焙进图像里而不是单独传坐标。也就是说用户画的圈、写的字最后都画在图片本身之上再把这张“已经标好的图”交给模型。这样能规避一大部分坐标问题代价是会损失一部分灵活性。如果你确实需要传结构化坐标那就一定要在同一个坐标系里处理截图、标注和显示缩放。4.3 上下文体积和 token 消耗要做减法一张高分辨率截图的 token 消耗通常比一段文字指令高得多。如果把截图、注释、历史记录全部塞给 agent很快会遇到两个问题响应变慢、费用上升。常用的处理思路是压缩截图前先按目标模型支持的分辨率缩放。对不是关键区域的部分做裁剪。注释文本尽量精简避免和背景信息重复。如果需要多轮交互只保留与当前任务相关的截图而不是累积全部历史图像。这条可以理解为“给 agent 的上下文做减法”不是把所有信息都传过去而是把最相关的视觉线索和文字指令传过去。很多“agent 理解不准”的问题其实不是模型不行而是输入里噪音太多。4.4 排查链路先定位是哪一层出问题用这类工具时如果结果不对不要急着换模型或调 prompt。更高效的排查顺序是这样的先看现象agent 是完全没理解截图还是理解错了区域还是理解对了但执行错了再看输入图片是否清晰、注释是否完整、文字指令是否和视觉内容一致。再看环境屏幕捕获权限是否开启、缩放比例是否异常、依赖版本是否兼容。再看参数分辨率是否过低、token 上限是否被截断、发送给 agent 的上下文结构是否被破坏。最后看工具边界当前模型是否支持视觉输入、对中文注释支持如何、截图里是否含有模型难以识别的元素。这套顺序每次都有效的原因在于它默认大部分问题出在离模型更远的那一端。如果你直接去调试模型输出往往要花更多时间最后才发现是截图根本没传对。遇到“agent 没看懂”的时候先自己看一眼发给 agent 的原始输入长什么样。很多时候问题不是模型笨而是你发给它的东西本身就是错的。5. 这个方向的价值边界适合谁不适合谁5.1 适合的场景从 Remarc 的定位出发这类屏幕注释工具最适合以下几种场景设计师和前端开发者之间做视觉走查直接标出“这里间距不对”“这个颜色和设计稿不一致”减少文字沟通成本。使用 agent 辅助开发时的任务交接看到某个报错、某个界面问题直接圈出来附带上下文发给 agent。数据看板和报表审查发现异常数据、异常布局把关注点精确传递给分析型 agent。需要把“所见”转化为“任务”的内部工具例如客服看到用户截图后把问题区域标出来交给自动化脚本处理。这些场景有一个共同点用户不一定能精确描述问题但能快速指出问题。视觉注释在这里的价值是降低表达门槛而不是替代 agent 的思考能力。5.2 不合适的场景同样这个方向也有明确边界纯文本任务不需要截图注释直接把文件内容或错误日志交给 agent 效率更高。只靠一次注释就能说清楚的问题也不值得引入完整链路。对隐私极其敏感的场景比如涉及客户个人信息、财务数据、内部机密系统的屏幕内容直接捕获屏幕会带来额外风险。需要 agent 自主长时间操作的场景单独的屏幕注释不足以支撑整个任务还需要配合记忆、计划和工具调用。如果你发现自己主要在做上述几类事那屏幕注释工具可能不是最优解甚至可能引入比它解决的问题更多的麻烦。5.3 长期来看它真正改变的是人机协作方式从更大的视角看Remarc 这类项目代表的是一种协作模式的变化人和 agent 之间不再只有“文字指令”这一条通道而开始出现“视觉指向 文字补充 上下文打包”的复合指令方式。这件事的意义不在于某个工具能画圈而在于它把人类的直觉判断和 agent 的执行能力接上了。你不需要先把屏幕变成一个精确的文字世界再让 agent 去理解。你可以在它原本的视觉形态上直接和它协作。当然这个方向还很早期。屏幕捕获权限、隐私边界、上下文压缩、坐标一致性、模型对视觉注释的理解力每一个环节都还有不少工程问题要解决。但只要把“输入侧”当成一个值得认真设计的层这个方向就值得持续关注。如果你也想尝试我的建议是不用等一个完美的工具。先截一张带注释的图发给一个带视觉能力的模型看看它能不能理解你的意思。能理解后面的事都好说不能理解问题大概率不在工具链而在更底层的人机交互范式上。