企业官网建设流程全解析

Remarc 这个项目最值得关注的不是“能截图”，而是它把“你在屏幕上看到的问题”直接变成了“Agent 能接住的指令”。很多人在用 AI Agent 处理界面类任务时都会卡在同一个地方：页面明明摆在那里，按钮错位、配色不对、报错弹窗弹出来、表格某一列数据对不上，自己想改或想反馈，但用文字给 Agent 解释清楚，反而要写一大段，写完了 Agent 还不一定定位得到。Remarc 的思路是让你直接在屏幕上做注释，然后把这个带注释的画面发给 Agent，让 Agent 直接基于画面执行。

这个方向解决的实际问题可以概括成一句话：把用户看到的界面上下文，低成本地转移给 Agent。它对三类人最有用：一是让 Agent 改前端页面的开发者，二是做界面测试、功能验收的测试人员，三是日常想用 Agent 帮忙处理截图、报表、网页问题的效率工具用户。下面按实际落地顺序拆一遍，先讲它到底解决什么问题，再说运行条件、第一次跑通、关键参数、效果判断、批量用法和排错思路。

1. 先搞清 Remarc 这类工具解决的是什么问题

1.1 给 Agent 说清一个界面问题，为什么这么费劲

假设你想让 Agent 改一个网页：页面上有个按钮在窄屏下溢出容器，需要让它换行。用文字描述就是“按钮在窄屏下溢出容器，请让它换行”。听起来简单，但 Agent 要理解“溢出”到什么程度、“窄屏”是哪种宽度、“按钮”是哪个按钮，都需要你补充。你在文字里说得越细，输入成本越高，而且 Agent 一旦理解偏了，回给你的代码就是错的。

如果用屏幕注释，这个问题就变成：截下这个页面，在按钮位置画一个框，在旁边写一句“窄屏下溢出，改换行”。Agent 看到的是精确的空间位置加上你的意图，不需要你专门描述坐标和尺寸。这里的关键不是“截屏”这个动作本身，而是截图之后附加的那一层注释信息。

1.2 屏幕注释的本质：把“位置信息”和“意图信息”打包

纯文本对话里缺少一个非常关键的东西：空间信息。你说的“右上角”“下面一点”“第二个 tab”，在 Agent 眼里都是模糊词。而屏幕注释天然带有坐标感——你框在哪、指着哪、高亮哪块，Agent 通过图片本身就能获得位置上下文。这就是 Remarc 这类工具的核心价值：它不是在“截图”这个动作上做创新，而是把位置信息、视觉信息和指令信息打包成一个整体消息。

再往深一层说，注释还能减少歧义。比如你截图后只在问题区域画了一个椭圆，旁边写一行字“为什么这里会有空白”，这个沟通效率比纯文字高很多，因为 Agent 不需要猜你说的“这里”到底是哪里。尤其在处理复杂页面时，一个页面可能有几十个区域，纯文字描述很容易漏掉关键上下文。

1.3 适合谁用，不适合谁用

适合用的场景：

• 让 Agent 修改界面代码，需要它先定位问题区域。
• 测试阶段发现 UI 显示异常，直接截图标注给 Agent 让它分析原因。
• 处理带图表的报表，想指出某一列、某一块数据不对。
• 想用 Agent 帮忙读截图里的报错，又不想手动把报错文字敲下来。

不适合的场景也要说清楚：如果需求是纯文字逻辑分析，比如“帮我写一个排序算法”，屏幕注释没有意义；如果 Agent 本身不支持图片输入，那发送带注释的截图只会增加无用信息。使用前先确认你的 Agent 通道能不能接收图片。

2. 运行之前，先把环境、权限和 Agent 通道准备好

2.1 设备和操作系统条件

这类屏幕注释工具通常以桌面应用或浏览器扩展的形式存在。常见情况下，Windows、macOS、Linux 桌面环境都可能支持，但不同系统的屏幕捕获 API 不一样，表现也可能有差异。启动前先确认三件事：

• 系统版本是否在工具要求的范围内。
• 是否有独立显卡或高分辨率屏幕需求。如果你在 4K 屏上使用，截图分辨率会比较大，处理时可能会更慢。
• 磁盘空间是否足够。带注释的截图文件一般不大，但如果长时间积累，占用的空间也不可忽视。

这里没有拿到官方的完整硬件要求，建议先按“普通办公电脑 + 当前主流系统版本”来验证，跑通了再考虑高负载场景。低配置机器也能试，但要把分辨率、批量数或并发数降下来，不要一上来就开太多任务。

2.2 屏幕捕获权限：最常见的卡点

屏幕注释工具几乎一定会用到截屏或录屏权限。在 macOS 上，系统会明确询问是否允许“屏幕录制”权限；在 Windows 上，某些场景需要确认窗口捕获权限；Linux 桌面则和桌面环境有关。第一次启动后如果没有弹出权限请求，或者提示无法捕获屏幕，不要急着怀疑工具坏了。

排查顺序是：

1. 打开系统设置，找到隐私与安全里的屏幕录制或屏幕捕获选项。
2. 确认工具进程在授权列表里，并且开关是打开状态。
3. 重启工具再试一次。
4. 如果还不行，检查是否有远程桌面、虚拟机或多显示器环境干扰。

远程桌面场景最容易出问题，因为系统级屏幕捕获只支持捕获本机显示器，远程桌面视图不一定在捕获范围内。多显示器用户还要注意，注释位置在副屏上可能出现偏移，这和缩放比例、坐标系都有关系。

2.3 Agent 侧准备什么东西

Remarc 的“接受端”是 Agent。运行前你需要确认：

• Agent 的入口是什么。是本地运行的 Agent 框架，还是一个远端服务，或者是一个 API 接口。
• 是否支持图片或截图输入。很多纯文本 Agent 无法读图，如果你的 Agent 不支持图片，就要先转换成图片描述文字，那就不能完全发挥注释的价值。
• 调用凭证是否配好。API Key、访问令牌、服务地址这类信息，提前填写好。
• 回调方式是什么。有的工具把注释截图直接粘贴进 Agent 对话，有的是通过接口发送，有的是写入本地目录再由 Agent 监听。不同的回调方式，决定了你验证结果时看哪里。

如果正在做 Agent 开发，这里要特别注意消息格式。屏幕注释工具发出来的东西不是一张普通图片，而可能是“图片 + 坐标区域 + 注释文本”的组合结构。你的 Agent 侧如果只按纯文本解析，就会丢掉位置信息。这个问题在自建 Agent 时特别容易出现，不是工具没发出来，而是你的程序没有解析完整。

3. 第一次跑通：从启动到把带注释的截图发给 Agent

3.1 先做最小验证：单条屏幕注释

我建议第一次测试不要一上来就开各种高级功能，也不要直接对接复杂业务。先跑一条最基础的链路：截屏、加注释、发送、看 Agent 能不能收到并回复。

操作顺序：

1. 启动 Remarc，先随便打开一个普通网页或文档窗口。
2. 调用屏幕捕获功能，选中一个明确的小区域，比如一个标题或一个按钮。
3. 在这个区域上加一条注释，写清楚“请说明这里显示的是什么”。
4. 把这条注释发送给 Agent。
5. 等待 Agent 回复，检查回复内容是否提到了截图区域里的实际内容。

这里为什么要从小区域开始？因为小区域信息量少，容易判断 Agent 是真的看到了图片，还是只是在猜测。如果 Agent 能准确说出你框选区域里的文字或颜色，说明图片链路是通的；如果回复内容泛泛而谈，说明它可能没拿到图，或者图片质量有问题。

3.2 注释时做什么、不做什么

第一次使用时，注释不要写太多。屏幕上只画一个框、写一句话，效果往往比同时标注五六个区域更好。原因很简单：Agent 处理视觉信息的能力有限，注释越多，它越难判断哪个是重点。注释应该是对界面上已有内容的“定点强调”，而不是重新画一张设计稿。

另外要注意注释的层级。如果你先框住整个页面，再框住一个按钮，再在按钮上写文字，Agent 可能分不清主次。我会建议：一个截图只解决一个问题，最多两个；超过两个，就拆成多条消息分别发送。这样每张图的信息密度低，Agent 理解得会更准确，后续验证结果也更容易。

3.3 确认 Agent 真的收到了

发送完成后，验证方式取决于 Agent 的接入形式。如果是对话框式的 Agent，就看回复内容；如果是 API 通道，就看请求日志和返回结构；如果工具是把截图写入某个目录再由 Agent 监听，就看目录里有没有生成新文件、文件内容是否完整。

最直接的验证办法是让 Agent 复述图片内容：“请描述截图里被我框选的部分。”它能答对，链路才算通。答不对，先回到第 2 节的权限和格式排查。不要急着换模型，很多第一次失败都是发送链路的问题，而不是模型能力的问题。

4. 关键参数和配置项：先理解再调整

4.1 截图区域、图片格式与分辨率

屏幕注释工具一般会有几个参数影响最终发送给 Agent 的图片质量：

• 截图区域：当前窗口、全屏、自定义矩形。自定义区域适合只想让 Agent 看局部内容的情况。
• 图片格式：常见的是 PNG 和 JPEG。PNG 保留细节，适合界面、文字、表格；JPEG 文件更小，适合色彩丰富的图形，但文字边缘容易模糊。
• 分辨率：是否需要按原始尺寸发送，还是压缩到某个宽度。分辨率太高，发送慢、占用上下文多；太低，Agent 看不清小字。一般先按工具默认值跑，如果 Agent 回复里出现“看不清文字”，再调高分辨率。

这里没有具体版本数据，所以建议落地时先看默认值，再根据自己的 Agent 模型图片输入上限调整。很多 Agent 模型对单张图片的大小和分辨率是有上限的，超了会被拒绝或自动压缩。

4.2 注释参数：框选、高亮、文字标签

注释功能通常包括框选区域、高亮、箭头、文字标签等。每个注释都建议加上一个简短文字，纯图形标注对 Agent 来说不够明确。比如“这个区域颜色不对”比只画一个红框更容易被理解，因为 Agent 能看到颜色，但不知道你的判断标准是什么。

文字标签要写在注释区域附近，不要离得太远。如果工具支持给每条注释编号，建议编号后再在文字里引用编号，这样 Agent 能建立“编号 ↔ 位置”的对应关系。比如“1 号区域背景色偏灰，请改成白色”就比“这个地方中间那个块颜色有问题”清楚得多。

4.3 Agent 交互参数：超时、上下文、回调地址

如果你是通过接口把注释消息发给 Agent，需要关注几个参数：

• 超时时间。截图发送和 Agent 推理都比较耗时，超时设置太短，任务会频繁失败。
• 上下文长度。带图消息占用 token 比纯文本高很多，如果上下文窗口小，多张截图可能超出限制。
• 重试次数。网络抖动或 Agent 服务瞬时繁忙时，重试机制能避免手动重发。
• 回调地址。如果工具支持 webhook 或回调，确保地址可达，否则 Agent 处理结果无法返回。

如果遇到 Agent 执行端一直没有响应，运行日志里出现类似 provider did not respond in time 的提示，先别想着改注释内容，优先检查超时设置、服务状态和网络连通性。这个问题通常不是图片内容造成的，而是执行通道本身出了问题。

4.4 参数速查表

参数不要一次性全改。每次只改一个变量，跑一次验证，再改下一个。这样出了问题，你才能知道是哪一步造成的。

5. 注释发给 Agent 之后，怎么判断它有没有理解

5.1 低质量回复的三个常见表现

判断 Agent 有没有真正理解注释，不要只看“它回复了”。如果出现下面三种情况，说明理解出了问题：

• 复述内容与截图不符。Agent 描述的界面元素你压根没截到，说明它可能在猜。
• 忽略了你框选的位置。回复内容像在回答一个泛泛的问题，对你的注释区域没有任何回应。
• 只复述文字，没有处理位置。你说“右侧图表里第二根柱子颜色不对”，它回复“好的，颜色不对”，但没有针对第二根柱子做具体操作，说明位置信息没有发挥作用。

出现这些情况，不用立刻怀疑工具，先确认 Agent 的模型是否真的支持图片识别，以及截图是否真的被发送到了 Agent 可见的输入位置。很多时候问题出在消息结构上，比如图片附加了但注释文字没有一起发过去。

5.2 好的屏幕注释应该像“贴了便利贴的界面”

你可以这样检查自己的注释是否合格：把注释后的截图发给一个不认识这个界面的人，看对方能不能仅凭截图说出“你想让 Agent 干什么”。如果对方能说清楚，那 Agent 大概率也能理解。换句话说，注释截图本身应该自带指令性，而不是只有标注没有说明。

这个判断标准对新手特别有用。你不需要懂图像识别原理，也不需要看模型参数，就用“别人能不能看懂”来衡量注释质量，简单直接。

5.3 提高理解率的三个技巧

第一，在注释文本里写“动作词”。比如“把这段文字改成加粗”“把这张图的高度调整为与左侧一致”“检查这个表单为什么提交失败”，比“这里有问题”有效得多。

第二，把修改后的期望也写进去。Agent 看到当前状态之后，如果知道目标状态，就能减少猜测。例如“当前按钮是红色，希望它变成主题蓝色”。

第三，一张图只围绕一个对象。如果你要处理页面上的三个问题，就截三张图，分别注释，分三条发送。这样可以避免 Agent 把多个问题混在一起，也方便你后续按条验证结果。

6. 批量使用和固定工作流：从一次反馈到每天用

6.1 最能跑出价值的几个场景

屏幕注释 + Agent 的组合，在下面几类场景里最容易产生实际价值：

• UI 修改反馈：页面截图、标注问题区域、发给 Agent 让它生成修改建议或提交代码。
• 界面测试验收：每个测试用例对应一张带注释截图，Agent 负责汇总问题并生成报告。
• 数据报表核对：截图里某一列数据异常，框选后让 Agent 检查数据来源和计算逻辑。
• 报错信息定位：程序运行时报错弹窗，框选报错文字，让 Agent 帮忙分析原因。

这些场景有一个共同点：问题本身发生在视觉界面上，而且带有明确的位置属性。纯文字要描述清楚，成本很高，注释截图正好补上了这个缺口。

6.2 批量任务前先想好的事情

批量使用和单条使用完全不是一回事。单条跑通只代表链路本身可用，批量任务要额外考虑：

• 输出命名。如果连续发送 20 张注释截图，Agent 的回复如何和截图对应？建议用时间戳或编号作为任务标识。
• 失败重试。单条失败可以手动重发，批量失败必须靠日志定位是哪一条、为什么失败。
• 顺序依赖。如果后一张截图的内容依赖前一张的处理结果，就要设计成队列式任务，而不是同时并发发送。
• 资源占用。连续发送大图会占用较多内存和网络带宽，先小批量跑 5 条，观察正常了再逐渐增加。

这里不要急着调并发。很多批量任务跑挂，不是因为工具不支持，而是因为同时发送太多，Agent 服务端处理不过来，或者本地内存被大量图片占满。稳妥的做法是：5 条一测，10 条一测，稳定后再往上加。

6.3 固定模板和输出命名

建议提前约定几套固定模板。比如：

• 修改类模板：“截图 + 问题区域标注 + 期望效果 + 约束条件（如兼容的最低浏览器版本）”
• 排查类模板：“截图 + 异常现象描述 + 触发步骤 + 最近改动”
• 核对类模板：“截图 + 核对对象 + 判断标准 + 需要输出的结论”

固定模板的意义不是限制发挥，而是让 Agent 每次收到的信息结构一致。结构一致的输入，输出质量会更稳定，也方便对比不同批次的处理结果。输出文件命名也要统一，例如“20250526_001_ui-fix.png”“20250526_001_ui-fix_reply.md”，这样即使任务数量多了，也能快速对应上。

7. 常见问题排查：注释丢了、发送失败、Agent 没反应

7.1 排查顺序

遇到问题不要慌，先按“现象 → 输入 → 环境 → 参数 → 工具”的顺序排查：

1. 看现象：是报错、卡住、无输出，还是输出异常。
2. 看输入：截图是否完整、注释文字是否显示、图片格式是否能被 Agent 支持。
3. 看环境：系统权限、网络连通性、服务地址是否可用。
4. 看参数：超时时间、分辨率、上下文长度、重试次数。
5. 看工具本身：版本是否过旧，是否和当前系统或 Agent 版本兼容。

不要一上来就怀疑模型不行。太多情况是权限没开、网络不通、图片没发出去，或者发出去但格式不对。

7.2 常见现象与原因对照

7.3 容易误判的几种情况

有些问题看起来是工具坏了，实际是别的环节出问题。

• 截图内容模糊，看起来像功能不支持，实际是系统缩放比例导致捕获分辨率低于预期。
• 注释位置偏移，看起来像工具 bug，实际是多显示器不同缩放比例造成的坐标换算问题。
• Agent 回复慢，看起来像 Agent 模型能力弱，实际可能是发送图片过大，占用上下文，推理时间被拉长。
• 消息被拒收，看起来像注释内容有问题，实际可能是 API Key 过期或请求频率超限。

遇到这些情况，先保留原始截图和发送日志，再做调整。日志里往往能看到是哪一步失败的，比反复猜测高效得多。

8. 我的几点实测建议

8.1 使用顺序：先单条、再批量、最后接自动化

如果你准备尝试 Remarc 或同类方案，我建议严格按照这个顺序来：先单条任务跑稳，确认 Agent 能收到图、能看到注释、能按注释反馈；再小批量跑，验证输出命名、失败重试和资源占用；最后再把它接进自动化流程，比如 CI、测试报告生成或定时巡检。

很多人跳过前两步直接上自动化，结果就是批量任务跑了一半才发现图片没发出去，或者 Agent 的回复格式根本不能解析。返工成本比慢慢验证高得多。

8.2 容易被低估的三件事：日志、隐私、成本

第一是日志。屏幕注释工具看起来操作简单，但一旦批量用，日志就是救命稻草。至少要把每次发送的时间、截图文件名、目标 Agent、返回状态记录下来。不然出了问题，你连失败的是哪一条都找不到。

第二是隐私。屏幕内容可能包含账号信息、内部系统、业务数据，发送给第三方 Agent 服务之前，先确认内容是否允许出网。这个问题不是工具能替你解决的，也不是靠事后打码能完全规避的，使用前就应该有判断。

第三是成本。带图消息消耗的 token 通常比纯文本高不少，截图越多、分辨率越高，成本增长越快。如果每天要发送几十张截图，建议先统计一次单张图片的平均 token 消耗，再估算月度成本，避免月底账单吓一跳。

8.3 最后的判断标准

这个方向真正落地时，最该盯住的不是功能列表，而是三件事：输入格式、资源占用和失败重试。输入格式决定 Agent 能不能正确解析注释，资源占用决定任务能不能批量跑起来，失败重试决定流程稳不稳定。只要这三件事处理清楚，屏幕注释 + Agent 的工作流就能稳定跑起来，而且会比纯文字描述省下大量沟通成本。

我个人的看法是，Remarc 这类工具的价值不在于“截屏”本身，而在于它让普通用户也能用视觉方式给 Agent 下指令。这个能力在 UI 修改、界面测试、报表核对这几类场景里尤其明显。如果你正在做 Agent 开发，也可以参考这个模式：给你的 Agent 加上图片输入、区域解析和注释文本提取，比单纯接一个截屏功能有用得多。还是那句话，先用小样本验证，跑通了再谈批量，这也是这类工具最稳妥的打开方式。