您的代理已读取代码库中的每一行。
它从未接触过浏览器。

编码代理对你的代码库了如指掌，却完全看不到故障发生前的那二十秒。它需要的证据一直存在——在报告人的浏览器里——而这些证据进入上下文窗口的唯一通道，一直是你，一个字一个字重新打进去。

问题

无法直接观察到故障的模型必须人为地重现故障，而这种人为的重现正是错误补丁的开端。于是，人就成了记录者：粘贴堆栈跟踪、裁剪屏幕截图、凭记忆写出点击顺序、猜测哪个请求才是关键。每一步操作都会造成信息丢失，而丢失的部分恰恰是模型最难恢复的——那些静默失败的请求、控制台没有显示的错误信息、故障发生时页面的状态。最终，代理只能根据错误的概要信息而非错误本身进行工作，而审核人员不仅要检查更改的内容，还要检查被更改的部分是否曾经是问题所在。

Snag如何提供帮助

Snag 把捕获到的证据放到代理可以主动索取的地方。一次调用返回这个工作区里尚未解决的报告，最新的在前，已解决的被滤掉，所以不会有东西被重复修一遍；另一次调用把某一份报告捕获到的全部内容作为结构化字段返回，而不是一段还要去解析的文字。“以这些证据为依据、不要凭空补上缺口”这条指令随工具本身一起下发，所以它在每一次调用上都生效，而不取决于某个人的提示词是怎么写的。边界正是重点：服务器只交出证据，写回的只有你的代理已经开好的那个拉取请求的链接，所以它改不了你代码仓库里的任何东西，而你的代理继续做它本来就在那里做的那些事。接上它只需要一个令牌和一个 URL，走标准的 MCP——不用 SDK，不用 Webhook，也没有东西要托管。

你得到的回报

您的代理输入不再代表您对 bug 的描述，而是记录下来的描述；它发起的拉取请求仍然由您的代理发起，并存储在您的代码仓库中，且包含您的凭据。反向传输的信息刻意精简且短暂：指向原始工件、回放和视频的链接都经过签名，并在 15 分钟后失效，因此不会形成指向用户会话的永久 URL；每次调用都会重新检查工作区的权限，而不是信任一次性颁发的令牌。工具参考 详细列出了 bug 返回的所有信息，逐字段列出。

人们实际会问的问题

服务器能否向我们的存储库或工作区写入任何内容？

不能，因为根本不存在能让它这么做的工具。服务器只交出证据，别的什么都不做，所以建分支、提交代码、开拉取请求，都仍然发生在它们本来发生的地方：在你自己的代码仓库里、你自己的基础设施上、用你自己的凭据。Snag 永远不会碰你的代码。

对于一个 bug，代理实际拿到的是什么？

报告的标题和描述、报告所在的页面及其路由路径、带有时间戳的步骤摘要、当时捕获的控制台、网络和错误信息、回放链接，以及如果报告已路由，则包含跟踪密钥。该工具自身的描述指示代理程序基于这些材料进行修复，不要捏造其中没有的细节。

连接它需要多少工作量？

您需要从控制面板获取工作区令牌，并在客户端配置中提供服务器 URL。它基于 Streamable HTTP 的标准MCP，因此无需安装 SDK，无需接收 Webhook，也无需托管任何内容。从 Capture 套餐开始，即可获得访问权限，并且创始工作区在其生命周期内始终拥有此权限。

这些细节的来源

本页面不涉及任何其他产品——所有信息均为Snag原创。如有信息过时，请发送邮件至 admin@dvcllc.io，我们将予以更正。