最新

在树莓派 Pico 2 W 上运行 10BASE-T 以太网（使用 PIO 进行 TX 和 RX 的位操作）和无线路由器。在 RP2350 的 RISC-V 核心上运行 Rust 的 cyw43 + 异步执行器。使用廉价且极简的外部硬件（仅需一个磁性连接器和 ISL3177E RS-485 收发器）。我想看看基于 MCU 的廉价 Wi-Fi 路由器想法能实现到什么程度，并进一步学习如何在 RP2350 和 RISC-V 上使用 Rust。这绝对不是家用路由器的理想选择，但对于低速率的物联网流量可能很有用。

关于其工作原理以及我如何构建批量嵌入引擎 IgniteMS 的简要说明。 整个系统使用 Rust 作为单个进程运行，负责读取输入、分词、打包批次以及保持队列的充足。TensorRT 负责推理。Python 仅作为包装器使用。 我之所以这样构建，是因为当使用多个 GPU 时，GPU 本身不再是瓶颈。CPU 的处理速度跟不上，无法足够快地为 GPU 提供数据。一个 A100 GPU 处理批次的速度比 Python 进行分词和喂数据的速度还要快，导致 GPU 只能空闲等待工作。我大部分时间都花在了优化这一点上。在 8 个 GPU 的情况下，这基本上是全部的挑战。 关于成本。我使用了一个 p4d spot 实例（8 个 A100 40GB GPU）来运行大规模的 20 亿消息处理任务。经过过滤和去重后，我得到了 6.85 亿条原始文本。使用我的新引擎，整个生产运行大约只需要半小时。以前我为这些任务使用按需实例，现在改用了 spot 实例。如果 AWS 重新分配了实例，我只需重新运行即可。每次运行大约花费 7 美元，持续半小时。而且至少目前 spot 实例比按需实例更容易获得。 公开声明：它仅支持批量处理且仅限于 NVIDIA 硬件。你可以将其作为 Docker 镜像使用，也可以本地安装。 我在生产运行中进行了一些优化。使用默认设置，如果你在 p4d 实例上运行基准测试脚本，预计可以达到约 250,000 条消息/秒的处理速度。 [https://github.com/Artain-AI/ignite-ms/blob/main/BENCHMARKING.md](https://github.com/Artain-AI/ignite-ms/blob/main/BENCHMARKING.md) v1.1.0 版本增加了对 TensorRT 11 和 60 个模型（其中 23 个在 1x 和 4x A100 上进行了测试）的支持。 我很乐意分享更多细节。

大型语言模型（LLM）擅长处理 SQL。SQL 精确、表达力强且没有歧义。如果您将 MCP 服务器连接到 Postgres，那么代理可以直接查询它。但对于 NoSQL，情况并非如此，考虑到有很多人使用 NoSQL 数据库，我感到惊讶的是关于这个问题并没有更多的讨论。 问题的一部分在于多样性。MongoDB、DynamoDB、Cassandra、Redis 和 Neo4j 都拥有不同的查询模型。没有一个通用的接口供 LLM 进行推理。因此，代理需要编写代码而不是查询：SDK 调用、手动聚合、分页逻辑。这变得更加复杂，更难审查，并且在处理任何非简单任务时都会迅速出错。 我们遇到了与 DynamoDB 特别相关的问题，并最终构建了自己的解决方案。如果您有兴趣，我在这里写过相关内容：https://dynamosql.hashnode.dev/why-llm-agents-still-can-t-query-nosql-databases。但我更感兴趣的是其他人是如何处理这个问题的。为什么这仍然是一个悬而未决的问题？

在输掉了数百场 <a href="https://pokelike.xyz/" rel="nofollow">https://pokelike.xyz/</a> 游戏后，我意识到其状态空间足够小，或许一个用 PPO 训练的小型神经网络可以比较稳定地战胜它。经过一些奖励工程的调整，它奏效了！这个经过 PPO 训练的神经网络可以在 9% 的所有游戏中一路过关斩将，直到精英四强！

Headroom 是一款菜单栏应用程序，它通过精简提示的冗余信息、去除样板代码和压缩文档，在不改变您工作方式的前提下，默默地优化 Claude Code 的输入。 这使得您在已付费的 Claude 套餐中，能够获得约两倍的 Claude Code 使用量。与竞争对手不同的是，Headroom App 完全开源，并且可以免费开始使用。 非常适合希望最大化其 AI 编码助手投资的开发人员和团队。 链接： https://extraheadroom.com/ https://github.com/gglucass/headroom-desktop https://x.com/garmdotcom https://www.instagram.com/extraheadroom/ https://youtu.be/2NPBaqRGcOs

大家好，我是 Nick 和 Drew，我们正在开发 boxes.dev——首个云端智能代理开发环境（ADE），为每个 Codex 和 Claude Code 代理提供独立的云计算机。 我们是两位工程师，之前曾共同创建 Gem（联合创始人/CTO 和首位员工），过去一年我们几乎完全使用 Codex 和 Claude Code 进行编码。这极大地改变了我们的编码方式，看到模型不断进步令人兴奋——但我们最终意识到，在本地开发正在阻碍我们： * Git 工作树的设置和使用对于并行化工作来说非常笨拙。 * 现在是 2026 年了，但不知何故，人们仍然带着打开的笔记本电脑四处走动，或者 SSH 到车库里的 Mac Mini，以免他们的代理停止工作。 * 移动端被视为事后诸葛亮，尽管现在编码就像发短信一样简单。 当多个并行代理通过在本地运行整个应用程序来测试自己的工作时，我们遇到了资源限制。 * 我们尝试了不同的产品，但找不到任何能解决我们所有痛点的产品——所以我们调整方向，决定自己构建我们想要的 ADE。 Boxes.dev 是一款桌面和移动应用程序，可让您在远程计算上运行 Claude Code、Codex（使用您的订阅！）以及您正在构建的任何内容的完整开发环境。它类似于 Conductor 或 Codex 桌面应用程序，但一切都在云端。 我们使用编码代理扫描您的本地开发设置并将其迁移到云端。然后，每个 Claude Code/Codex 线程都从完整的设置快照开始，拥有自己的文件系统和计算能力。 告别 Git 工作树，告别打开的笔记本电脑，您的编码代理可以真正地端到端测试它们的工作，因为它们可以在隔离的环境中运行您的完整应用程序。 我们镜像了 Claude Code 和 Codex 的用户体验，以便为高级用户提供自然的使用感受，同时还提供功能齐全的移动应用程序（无需切换或远程控制），以及计划的自动化和 Slack 集成。 我们当然有偏见，但我们已经使用 boxes.dev 开发 boxes.dev 数月了，这确实改变了游戏规则。一旦您意识到本地开发限制了您多少，就很难回到过去了；根据早期 beta 测试用户的反馈，我们越来越确信云是智能编码的未来。 我们很乐意让您亲身体验！非常感谢您的任何反馈——并乐意在本帖中回答任何问题。