最新

今天，我们开源了14个组件和示例，支持PDF、DOCX和XLSX查看器，以及边界框引用、文件上传、电子签名等功能。该项目采用MIT许可证，并且完全可定制。 演示视频：https://share.extend.ai/kRmSGKRF 我们刚开始时，尝试了所有能找到的文件查看器和文档组件库。但不幸的是，没有一个具备我们想要的所有功能（和完善度），所以我们最终为https://extend.ai/构建了自己的组件。它最初只打算内部使用，但有足够多的客户不断询问，于是我们决定将其开源。 它可用于构建文档处理代理、面向用户的实时文档接收流程，或各种内部工具。 我们曾天真地认为这是一个已解决的问题。事实证明，构建可大规模运行的PDF/XLSX/DOCX查看器并非易事……我们自己也在Extend中使用和维护它，因此我们修复了在自身系统中每天处理数百万页文档时出现的许多边缘情况。我们希望通过我们的资源和社区支持，它能随着时间的推移不断改进。

我构建 strangeClaw 是因为我想更深入地理解像 OpenClaw 这样的智能体系统，所以我从零开始构建了自己的版本。是的，我知道，这个世界上可能并不缺另一个智能体。 我的主要动机是沙箱化。智能体功能强大，但它们需要一个能够良好运行的框架（至少在我看来是这样）。对于生产环境，我认为这意味着真正的隔离，所以我尝试将智能体置于 Firecracker 微虚拟机中。我的目标是构建一个我真正愿意在我的主 PC 上运行的东西。 在 Fire 模式下，智能体无法访问主机文件系统，也没有 API 或 LLM 凭证。经过身份验证的 HTTP 调用会通过一个主机端的代理，该代理会强制执行策略、注入凭证、审查响应，并且只允许配置的端点/方法。LLM 调用也通过主机端的代理进行。 智能体本身被设计得非常小巧，现在基础已经搭建好，我将尝试开始为它添加更多的工具和技能。如果这听起来很有趣，欢迎您尝试使用它、拆解它或在此基础上进行构建。期待您的反馈 :)

访问任何帖子时都会被重定向到 https://stackoverflow.com/error

请记住，亚马逊可能会对功能进行 A/B 测试，因此 bug 可能只会在您被 A/B 测试某个特定功能时出现。 2025/09/17 5.18.5 * 据我回忆，没有严重的 bug。 2025/11/05: 5.18.6: * 移除了在书中打开完整字典的功能，只能预览。以前“打开字典”的选项在“分享到 Goodreads”的位置。 * 移除了专用的书签栏 * 德语词典 bug * “例如，我高亮了德语单词 dahertrampelten。这是一个可分离动词，前缀是 daher。在 5.18.6 之前，我的 Kindle 能识别这个单词并给出整个单词的定义。在 5.18.6 之后，它只显示前缀的定义。” * “如果有人真的需要知道 dahertrampeln 的意思，得到 daher 的定义将是[无用的]” * 日语词典 bug * “词典会尝试默认查找高亮日语文本中最短的单词，而不是最长的。” * 如果日语问题也出现在英语中，将会是：“你尝试高亮‘lighthouses’。它会高亮‘light’并显示定义。” 2025/12/10 5.19.0-5.19.1: * Kindle Scribe 2025 专属固件，但未来的固件会继承这些问题 * 由于某个域名被列入常见的默认阻止列表，使用路由器自定义 DNS 的用户会因为无限次请求重试而导致睡眠时耗电。 2026/02/17 5.19.2+: * 破坏了 AZW3/KFX 书籍中的嵌入字体，其中文本的某些部分指定了显式字体，常用于标题和副标题。现在这些内容会以通用字体渲染。[已在 5.19.4 中修复] * AZW3 书籍缺少页码 [已在 5.19.3 中修复] * AZW3 书籍 % 阅读进度跟踪器损坏 [已在 5.19.3 中修复] * AZW3 书籍翻页卡顿 [已在 5.19.3 中修复] * AZW3 漫画/图画书 % 阅读进度跟踪器损坏 [已在 5.19.4 中部分修复] * AZW3 漫画/图画书翻页卡顿 [已在 5.19.4 中部分修复] * AZW3 漫画/图画书 Aa 菜单中缺少所有布局选项 * 为 MOBI/AZW3 漫画/图画书添加了巨大的页边距 [已在 5.19.3 中修复] 2026/03/27 5.19.3 * 几天后撤回，包含 5.19.3.0.1 中的所有更改 2026/04/07 5.19.3.0.1: * 排除 Kindle Basic 第 11 代 2022 和 Paperwhite 第 11 代，因此它们没有获得任何修复 * 修复了之前提到的各种普通书籍 AZW3 问题，包括缺少页码、% 阅读进度跟踪器、翻页卡顿 * 修复了之前提到的漫画页边距问题 * AZW3 漫画/图画书在双页横屏模式下页面显示在错误的一侧 [已在 5.19.4 中修复] 2026/04/24: * Kindle Basic 第 11 代 2022 和 Paperwhite 第 11 代停留在 5.19.2 版本，如果连接到 Wi-Fi，AZW3 漫画页边距问题会得到修复，它们可能已经关闭了导致 bug 的功能的 A/B 测试（新 UI） 2026/05/07 5.19.4 * 几天后撤回，包含 5.19.4.0.1 中的所有更改 2026/05/21 5.19.4.0.1 * 仅适用于 Colorsoft、Paperwhite 第 12 代和 Scribe 2022。 * AZW3 书籍（包括普通可重排文本和漫画）的全刷新选项不再起作用。这可能在 5.19.3 中已损坏。 * 嵌入字体已修复！！！！！！！ * 修复了 AZW3 漫画横屏顺序问题 * 部分修复了 AZW3 漫画的 % 阅读进度跟踪器。之前它根本不起作用，现在可以工作了，但会在结束时卡在 100% 而不是标记为已读。但其他百分比，如 25% 和 50% 现在可以工作了。 * AZW3 漫画翻页速度大大提高，比 5.18.5 稍慢一点，但比 5.19.2 快得多 * AZW3 漫画的虚拟分镜仍然缺失 2026/05/20: * 亚马逊停止通过 Wi-Fi 进行 Kindle 商店下载，并停止注册第 1-5 代 Kindle * USB Kindle 商店下载已于去年停止 2026/06/02: * 5.19.4.0.1 发布给 Scribe 2025/2024 和 Basic 2024 * Kindle Basic 2022 第 11 代和 Paperwhite 5（第 11 代）用户停留在 5.19.2 版本 用户可以通过 Kindle 设置 > 帮助 > 联系我们 > 电子邮件选项提交正式投诉。

我将简短地介绍一下大型语言模型（LLM）使用方式的演变过程，我们已经看到了几个阶段： 1. 聊天 2. 自动补全 3. 使用 RAG（检索增强生成）嵌入知识 4. LLM 的工具调用（CLI 或 MCP） 5. 能够执行任务的智能体式 LLM 您认为下一步或下一个迭代会是什么？ 我的理论是，到 2026 年底，我们将拥有更量化、更高效的模型。我希望届时会出现围绕工具的迷你模型（我称之为领域智能体），它们可以直接提供答案，而不会过度增加上下文。 也就是说，领域智能体直接提供“香肠”，而无需解释“香肠是如何制作的”。 我很想听听您的理论，但我认为我们可能需要对 LLM 与工具结合的架构进行全面重新思考。

各位 HN 的朋友们，距离我们发布 HelixDB (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43975423">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43975423</a>) 已经一年多了。这是一个我和朋友在大学时启动的项目。它是一个基于对象存储的 OLTP 图数据库，支持原生向量搜索和全文搜索 (FTS)。 为什么选择图、向量和 FTS？图数据库为数据提供了自然的认知模型，向量能够语义化理解图中的实体和关系，而 FTS 则提供了更精确的过滤。许多由 AI 驱动的应用试图通过拼接多个不相关的系统来整合这些功能，但即便如此，也没有原生方法可以执行跨越所有系统的连接或查询。你仍然需要在应用层面处理这些逻辑。 Helix 最初是一个图数据库，但在尝试构建一个 AI 记忆系统后，我们转向了混合图/向量方法。这让我们深入研究了 GraphRAG 和 HybridRAG，在这种情况下，我们需要独立的图数据库和向量数据库。 我们知道可扩展性将是我们产品开发各个阶段的挑战。然而，过去一年的初步重点是证明产品的可行性，通过本地部署，并且最初只打算在单个节点上运行。图数据库的可扩展性仍然是一个我们以后必须解决的困难且昂贵的问题。 其他图数据库解决可扩展性的一些常见方法是将整个数据集复制到分布式机器上（每个节点的成本极高），或者对数据进行分片。 数据库分片是有效且经济的，然而，图数据不像关系型数据库那样有明确的分区。例如，关系型数据库的分片涉及拆分表。对于图数据库来说，边可以跨越任何分区，而在遍历节点时跨越多个机器效率低下且计算成本高昂。 为了高可用性和更好的吞吐量而复制图数据库会极大地增加数据库的运营成本，并且在垂直扩展方面仍然有限制。我们使用的场景需要存储大量的代理数据，而这些数据中只有一小部分在任何时候都需要。因此，我们不需要将所有数据都放在内存中，而是可以将所有数据存储在对象存储中，并在需要时获取所需的数据块。 代理可以从更好的上下文受益，而这可以通过更多更好的数据（更多的关系等）来实现。通过使用 S3 作为持久化/数据层，图的大小或关系的数量**没有限制**，我们可以通过水平扩展节点和在每个节点上缓存相关的图子集来扩展吞吐量和请求。这样，你可以获得对“热”数据的极低延迟，以及从冷存储（S3）写入的 p99 约 100 毫秒，读取约 50 毫秒。此外，你还可以获得极其廉价的存储的好处。 HelixDB 目前支持的工作负载： - 大量数据（TB 级别），代理需要搜索和遍历 - 为图数据成本成为瓶颈的公司提供经济实惠的图存储 - 整合多个数据库，使 AI 代理能够自主管理公司，帮助它们变得更加自主。 - AI 记忆 - 公司大脑 我们目前正在开发自己的通用 AI 记忆层，该层将使用 HelixDB 作为底层，并完全开源。此外，我们正在完成向量搜索的预过滤功能，该功能允许你根据图中的关系、元数据和子图进行预过滤。最后，GA 云将在未来几周内可用。 如果你想在本地运行 Helix（在磁盘上或内存中），可以在我们的 GitHub (<a href="https:&#x2F;&#x2F;github.com&#x2F;HelixDB&#x2F;helix-db" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;HelixDB&#x2F;helix-db</a>) 或我们的文档 (<a href="https:&#x2F;&#x2F;docs.helix-db.com&#x2F;database&#x2F;local-development">https:&#x2F;&#x2F;docs.helix-db.com&#x2F;database&#x2F;local-development</a>) 中找到更多信息。如果你有兴趣开始使用我们的分布式云，请发送邮件至 founders@helix-db.com。 非常感谢！欢迎评论和反馈！

Chirpper 是一个邀请制平台。当你担保某人加入时，他们就会加入你的信任链（TrustChain）。他们的行为会影响你的信任等级（TrustRank），并沿着血缘关系向上蔓延。没有版主。问责制是架构性的，而非基于政策的。你可以使用化名，但不能逃避责任。我很乐意在评论区详细介绍其机制。