返回首页
最新
我的iPhone上显示“天气不可用”，已经持续了大约一个小时。
大家好，我是 Matt Mahowald，今天我和我的联合创始人 John 一起推出 Ragnerock 的公开测试版。
作为一名数据科学家，你大部分时间都在处理数据。尽管你可能有一套喜欢使用的技术和技巧，但对于特定数据源的处理方式往往是非常定制化的，因此每次都需要编写自定义逻辑。
Ragnerock 的诞生源于这样一个观察：现代大型语言模型（LLM）可以自动化这一过程中的大量繁琐工作，同时仍然允许完全可定制的管道。此外，通过利用约束解码等技术，可以提供统一的查询接口，无论数据源是什么——将原始数据源（如文本和图像）与你现有的结构化数据（存储在数据库中）连接起来。
Ragnerock 主要有四个组件：
- 一个工作流设计器，让你构建基于 LLM 的数据处理和分析管道
- 一个作业编排层，负责运行这些工作流
- 一个查询接口，让你可以使用简单的 SQL 检查这些工作流的结果
- 一个笔记本系统，与 Jupyter 100% API 兼容，并在你现有的内核上运行，因此你可以轻松地将数据引入到现有环境和分析中
Ragnerock 还支持自带 AI（OpenAI、Anthropic 和 Google API）、数据库和 Blob 存储，因此你可以与现有数据集进行连接，并将所有输出流向你的数据湖。我们特别兴奋于我们的网页爬虫功能，它允许你抓取网站并在更新时触发工作流：例如，你可以将 Ragnerock 指向你最喜欢的博客，并运行一个工作流来评估帖子的话题和情感。
你可以在 <a href="https://www.ragnerock.com" rel="nofollow">https://www.ragnerock.com</a> 尝试，注册不需要信用卡，前 20 小时的计算是免费的。这是一个早期产品，我们特别希望收到反馈。
如果有任何问题，请随时问我——今天 John 和我会在评论区回答。
是我一个人这样觉得，还是Claude Code越来越糟糕了？自从在4.6版本中引入了100万的上下文后，情况开始变得非常糟糕，我是唯一有这种感觉的人吗？附言：我仍然每月支付200欧元的最高费用。
嗨，HN，我是来自Cua的Francesco。
上个周末我拼凑了这个项目，灵感来自Codex Computer-Use的发布以及我们为客户部署GUI操作代理时的经验教训。
主要问题是：当UI自动化过程控制桌面应用程序时，它通常会接管人类的会话。你的光标会移动，键盘焦点被抢走，窗口会跳到最前面，你必须停止工作，直到代理完成。这就是为什么我们历史上一直避免鼓励用户直接在他们的主机上运行这些过程，而是依赖虚拟机或GUI容器来实现并发和后台执行。
但是，计算机使用——我们给代理操作计算机的工具——并不能以这种方式干净地扩展。随着模型变得更智能，代理需要安全地共享主机，在后台运行，并避免与使用同一台机器的人类或其他代理发生冲突。
我们意识到macOS没有“在不触碰光标的情况下驱动这个应用”的一流API。CGEventPost通过硬件输入流进行路由，因此会移动你的光标。CGEvent.postToPid避免了光标的扭曲，但Chromium将这些事件视为不可信，并在渲染器边界静默丢弃点击。首先激活目标应用会使窗口升起并抢占焦点，这违背了后台执行的目的。
Cua Driver是我们对真正解决方案的尝试：一个用于macOS的后台计算机使用驱动程序，允许代理在你的光标、最前面的应用和空间保持不变的情况下点击、输入、滚动和读取本地应用。默认接口是命令行界面，因此很容易从任何编码代理的shell中进行脚本编写或调用。
在macOS 14+上试试：
```bash
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/trycua/cua/main/libs/cua-driver/scripts/install.sh)"
```
第一个内部用例是委派演示录制。我们让Claude Code驱动一个应用，而“cua-driver recording start”则捕捉轨迹、截图、动作和点击标记。结果是一个由代理生成的产品演示，灵感来自Screen Studio。
我们还用它做了其他事情：
- 替代Vercel的代理浏览器和其他浏览器使用的命令行工具。使用Claude Code和Cua Driver，你根本不需要Chrome DevTools协议。
- 一个开发循环的QA代理，重现视觉错误，编辑代码，重建并验证UI，同时我的编辑器保持在最前面。
- 使用Claude Code、Hermes或其他通用代理命令行工具的个人助手流程。
- 从我不在看的Chrome、Figma、预览或YouTube窗口中提取视觉上下文，而不依赖它们的API。
让这件事比预期更困难的原因：
- CGEventPost会扭曲光标，因为它通过HID流。
- CGEvent.postToPid不会扭曲光标，但Chromium在渲染器IPC边界丢弃它。
- 首先激活目标会使窗口升起，并可能将你拖到不同的空间。
- 当窗口被遮挡时，Electron应用会停止保持有用的AX树，除非有私有的远程感知SPI。
解决方案是SkyLight。SLEventPostToPid是公共每个PID调用的兄弟，但它通过WindowServer通道传输，Chromium将其视为可信。将其与yabai的无抬升聚焦模式配对，再加上在(-1, -1)处的屏幕外初始点击，点击就会落下，而窗口从未升起。
我们学到的一件事是：正确的寻址模式取决于应用。原生macOS应用通常具有丰富的AX树，Chromium系列应用通常需要AX和截图的混合，而像Blender或CAD工具这样的应用几乎不暴露有用的AX表面。错误在于到处默认使用像素——或者到处默认使用AX。
长篇技术文档：[链接](https://github.com/trycua/cua/blob/main/blog/inside-macos-window-internals.md)
我希望能得到那些构建Mac自动化、代理工具或无障碍工具的人的反馈。如果它在你关心的macOS应用上出现问题，那对我们来说是有用的数据。