一周热榜

抓取现代网站已成为一大难题。你基本上有两个选择：要么支付 Firecrawl/Browserbase 等昂贵的 API 费用，要么运行大量无头 Chrome 实例，每个页面消耗 1GB 内存，而且仍然会被 Cloudflare 阻止。 我构建 Draco 来解决这个问题。它是一个用 Rust 编写的快速、单二进制的网络爬虫。你将其指向一个 URL，它就会输出完美的 Markdown 或结构化的 JSON，供 LLM 使用。 其秘诀在于，它不会为每个请求都启动一个浏览器。它使用一个分层升级引擎： 第一层（隐形抓取）：Draco 使用自定义的 TLS/JA4 指纹，在数据包级别完美模仿真实浏览器的网络签名。事实证明，许多反机器人墙如果你的握手看起来正确，就会让你畅通无阻。在我针对 Cloudflare 和 Target 等网站的基准测试中，Playwright 消耗了约 500MB 内存并超时。Draco 在不到一秒的时间内就绕过了它们，仅消耗了 20MB 内存。 第二层（V8 隔离）：如果遇到需要渲染的 React/Next.js SPA，Draco 会在几毫秒内启动一个进程内的 V8 引擎。它会水合 DOM 并拦截页面正在调用的隐藏 JSON API——让你获得原始数据，而无需图形浏览器的开销。 第三层（真实浏览器）：如果遇到绝对的障碍，它会无缝回退到检测并驱动你机器上的真实浏览器。 我还构建了所有工具，使其成为托管服务的完整即插即用替代品： 守护进程模式：运行 `draco serve`，你将获得一个具有 Firecrawl 兼容 REST API 的持久 HTTP 服务器。你可以立即替换你的 API 密钥并进行自托管。 内置 MCP 服务器：它原生暴露一个模型上下文协议服务器，因此你可以将其直接插入 Claude Desktop 或你的 AI 代理。 网络搜索：内置并行多引擎网络搜索（无需 Google Search API 密钥）。 交互模式：像开发者工具控制台一样有状态地驱动页面，在导航之间持久化 cookie（主要用于 LLM）。 它完全开源（MIT/Apache-2.0）。我只是想把它提供给任何厌倦了与无头 Chromium 斗争或支付按页抓取费用的人。下载二进制文件，然后给它一个困难的 URL。 请注意，它仍处于开发阶段，因此可能会有一些不常见网站的意外中断，但总的来说它非常强大，可以处理 cf 保护的网站和重度 SPA，而其他所有工具都部分或完全失败，耗时更长或资源更多。（已在 example.com、hackernews、cloudflare、glassdoor、bluff.com、target.com、stake.com 和 thrill.com 上进行测试） | 排名 | 工具 | 分数 | 通过率 | 平均时间 | 平均内存 | | ---- | ------------ | ----- | ------ | -------- | -------- | | #1 | Draco | 769.7 | 8/8 | 3.45 | 216.50 | | #2 | Obscura | 384.5 | 4/8 | 2.68 | 87.59 | | #3 | BrowserOxide | 373.4 | 4/8 | 6.42 | 105.95 | | #4 | Playwright | 342.2 | 4/8 | 1.71 | 535.07 | | #5 | Bouncy | 196.6 | 2/8 | 0.59 | 19.38 | 仓库：https://github.com/0xchasercat/draco/

我是一名即将升入大二的学生，非常希望能在这个秋季加入一家由 YC 支持的初创公司（我更倾向于消费产品领域）。 我认为我拥有扎实的经验（今年夏天在 AWS 担任软件工程师实习生，并且我曾独立开发并推广过一款下载量超过 2 万次的移动消费应用）。 到目前为止，我的主要方法是通过 LinkedIn 向我感兴趣的初创公司的创始人发送私信，但一直没有成功。有什么建议吗？

你好 HN， 这是一个我为了解决工作中遇到的问题而临时编写的简单命令行工具。 我们遇到的问题是，一台 Linux 服务器连接了多个 USBIP 设备，而我们很难分辨出是谁连接了哪个设备。 这时 `usbatlas` 就派上用场了。它是一个基础应用，运行在 Linux 设备文件系统之上，并且依赖于 `usbip` [0][1]。它可以让你查看连接到你的 Linux 服务器上的 USB 设备以及它们的来源。目前，设备源 IP 地址解析功能还有一些问题，我正在努力解决这些细节。 下面是一个示例输出： ``` $ usbatlas --usbip xHCI Host Controller [serial: xxxx:xx:xx.x] +- USB2744 +- Lenovo New Calliope USB Keyboard +- /dev/hidraw0 +- /dev/hidraw1 +- /dev/input/event3 +- /dev/input/event4 +- /dev/input/js0 +- Lenovo USB Optical Mouse +- /dev/hidraw2 +- /dev/input/event5 +- /dev/input/mouse0 +- Bluetooth 9460/9560 Jefferson Peak (JfP) +- USB2.1 Hub +- USB2.1 Hub +- Saleae Logic +- FT4232H MiniModule [serial: xxxxxxxx] +- /dev/ttyUSB4 +- /dev/ttyUSB6 +- /dev/ttyUSB7 +- /dev/ttyUSB8 +- USB2.1 Hub +- USB2.1 Hub +- FT4232H MiniModule [serial: xxxxxxxx] +- /dev/ttyUSB0 +- /dev/ttyUSB1 +- /dev/ttyUSB2 +- /dev/ttyUSB3 xHCI Host Controller [serial: xxxx:xx:xx.x] +- USB3.1 Hub +- USB3.1 Hub +- USB3.1 Hub +- USB3.1 Hub +- J-Trace PRO [serial: xxxxxxxx] USB/IP Virtual Host Controller [serial: xxxxxxxx] +- FT4232H MiniModule [serial: xxxxxxxx] [usbip] +- /dev/ttyUSB9 +- /dev/ttyUSB10 +- /dev/ttyUSB11 +- /dev/ttyUSB12 +- FT232R USB UART [serial: xxxxxxxx] [usbip] +- /dev/ttyUSB13 +- FT4232H MiniModule [serial: xxxxxxxx] [usbip] +- /dev/ttyUSB14 +- /dev/ttyUSB15 +- /dev/ttyUSB16 +- /dev/ttyUSB17 USB/IP Virtual Host Controller [serial: xxxxxxxx] ``` [0] https://github.com/dorssel/usbipd-win [1] https://wiki.archlinux.org/title/USB/IP

有一个在线网站和一个Windows应用程序，无需GPU！云端AI处理换脸。

前几天我查看了我的 Framework 笔记本上的 iio 设备，结果发现 Framework 12 的铰链角度传感器相当准确！所以我制作了一个 LidAngleSensor (<a href="https://github.com/samhenrigold/LidAngleSensor" rel="nofollow">https://github.com/samhenrigold/LidAngleSensor</a>) 的版本，适用于 Linux 上的 Framework 12，这样你就可以让你的铰链发出嘎吱嘎吱的声音了。

我研究了如何以 a) 结构化的方式存储代理状态，b) 在没有专用 MCP 内存/状态服务器的情况下运行，并且我能够获得 c) 一条清晰的、可差异化的审计日志，记录所有随时间变化的状态。我没有找到任何符合要求的方法。 在 [https://github.com/commitspark/demo-agentic-mcp](https://github.com/commitspark/demo-agentic-mcp) 中，我演示了一个实现，该实现通过将 Claude 代理与我之前发布的 Commitspark 库及其完全由 Git 支持的 GraphQL API 相结合，满足了这些要求。 在此演示中，模拟了两个独立的 Claude 代理，它们共同完成一个任务跟踪器。第三个代理会审查任何任务更改，并回滚明显不正确的更改。完整的演示记录包含在 README 文件中，包括代理的原始工具调用。 任务代理通过一个小型 MCP 服务器访问数据，该服务器公开了两个 Commitspark API（GraphQL API、Schema API）。然后，这些代理可以获取 schema 并自行编写 GraphQL 调用，GraphQL 会自动强制执行写入的数据符合 schema。验证器代理还可以访问基本的 Git 功能，以查看 diff 和撤销提交。 我正在寻求关于以下方面的反馈：共享代理状态的 schema 验证是否是人们实际遇到的问题，或者在实践中，松散类型的 JSON + 重试是否足够。