最新

大家好，我是Gary。 今天我想介绍k7d，这是一个Apache 2.0许可的紧凑型Rust虚拟机监控器（VMM）和shim，能够实现之前无法做到的事情：快速分叉正在运行的虚拟化多节点K8s集群，同时保持在途连接的存活。 在一台64GB内存的机器上，一个包含3个虚拟机节点的K8s集群可以在105毫秒内完成分叉，而一个3个虚拟机集群的50倍分叉则需要4.1秒。 我有两个目标： 1) 在Kubernetes基础设施上实现大规模的GRPO/RL（强化学习）训练AI，这在我看来是一个很好的推理训练平台，除了训练一些实际有用的能力外。这不仅需要快速的回合重置（因为在RL后训练中需要进行数万次多轮运行），还大大受益于快速分叉，以便在RL训练期间进行并行分支探索、回滚和修剪。忠实的分叉还为GRPO的G提供了字节相同的起始状态，从而降低组内的方差。 2) 实现小于3秒的虚拟机快照暂停/恢复/分叉，适用于带有Docker-in-VM的沙箱，这与我的另一个项目K7有关，该项目提供了可扩展的自托管虚拟机沙箱基础设施，配备用户友好的CLI/API/Python SDK，并且是Kubernetes原生的。 此外，k7d还配备了： - 一个树形API用于资源管理：如你所猜测的，当你进行分叉时，即使使用了优化的写时复制（CoW）页面共享，你也需要妥善管理资源（内存+磁盘），因此你需要知道如何在运行时驱逐资源。我设计了树形逻辑来跟踪子节点如何与父节点共享页面，并让你的AI代理保护一个有前景的树分支，驱逐一个没有前景的分支，或者在资源紧张时让LRU逻辑自动驱逐。这种基于树的逻辑适用于单个虚拟机沙箱，也适用于它们自己的Linux桥接上的多虚拟机集群。 - 形式验证：当然并不是所有部分，但k7d的某些关键子部分经过了形式验证：我使用Kani对不安全路径中的内存运算进行验证，并使用Aeneas（基于Lean的后端）形式证明上述的树形逻辑，以确保驱逐操作不会释放被活动后代引用的页面。 - 延迟作为持续集成：我严格跟踪大多数重要操作的延迟，并通过一系列集成测试进行检查和强制执行。 我真的很努力地没有构建自己的VMM，最初我为K7构建了一个不同于我最初的“kfd”（Kata + Firecracker + Devmapper-snapshotter over LVM thin-pool）的后端，我称之为“kql”，即Kata + Qemu + Longhorn。如果你了解这个技术栈，你会立刻明白：Longhorn非常适合跨节点复制，因此我使用它来在节点之间复制我的快照，这样“快照恢复”总是有效/高可用。Qemu的使用是因为Longhorn的块存储要求与Firecracker不兼容，后者需要Devmapper-snapshotter，而我不想自己构建跨节点复制逻辑的后端。 但这个“kql”后端由于Longhorn的构建方式导致分叉需要45秒，这对要求我为K7启用快速分叉的用户来说太慢了。 所以，这促使我开发了k7d，命名为“k7的守护进程”，它是自己的本地VMM和shim，同时替代了Firecracker/Qemu和Kata。 这使得K7中的虚拟机沙箱可以在2-3秒内完成分叉，而大部分延迟是kubelet的开销，因为在VMM层面，热分叉实际上只需5毫秒。 一个安全的权衡是：守护进程必须在同一树的分支间共享：这是设计使然。因此，你失去了每个虚拟机的Firecracker监狱（Jailer）。但我可以为每棵树重建一个类似的监狱，这在树不跨租户共享时是足够的，比如在使用分支进行RL训练时。这只是针对与Firecracker不同的优化。 代码库故意保持足够紧凑以便进行审计（VMM + shim少于3万行代码），我在README的顶部链接了一系列深入的博客文章。 我希望大家会喜欢这个项目，并期待有贡献者和批评者。 谢谢！

现在可以在Mac、Linux和Windows上使用。我添加了一个简单的图形用户界面，可以用来查找新模型并进行构建和设置。对于我来说，它在几个模型上运行得相当不错。GitHub上的README和DESIGN.md文件详细说明了其工作原理和原因，到目前为止效果非常好。<a href="https://github.com/notactuallytreyanastasio/shoehorn" rel="nofollow">https://github.com/notactuallytreyanastasio/shoehorn</a>

我正在尝试开发一款应用程序，以帮助我的本地社区，但我希望在某个时候能够扩展，服务更广泛的社区。这是一个复杂的应用程序，涉及很多动态部分，作为一名经验较少的初级开发者，我将会非常依赖Claude。然而，我知道一般来说，Claude的能力取决于使用它的开发者，而我还是一名初级开发者。那么，关于架构我该怎么办呢？我不能把架构完全交给Claude，但我目前的职业阶段还无法独立设计出没有缺陷的架构。 你们对我可以通过帖子/YouTube视频自学的内容，以及我可能需要聘请一位高级开发者来帮助我完成的内容有什么看法？ 我已经有这个想法一段时间了，原本打算等我成为更有经验的软件工程师时再实现，但现在就是最好的时机，我想咬紧牙关开始，即使这意味着我会犯更多错误并在工作中学习。 作为参考，我倾向于使用的技术栈是PostgreSQL（我没有这方面的经验）、Java Spring Boot（我对此相当熟悉）、Typescript与Angular（相当熟悉），还有一些Python（有一些经验）。还有其他一些技术，比如Redis（没有经验）。 总之……任何关于如何正确进行这个项目的帮助或建议都将非常有用。这个项目的部分想法就是为了学习，即使这意味着我可能会在几个月后发现需要从头开始，哈哈。

我去年构建了上下文引擎，主要是出于沮丧。智能体让我又惊讶又生气：它们不断调用不存在的 API，重新实现代码库中已定义的 API，并陷入编写-编译-重写的循环。有时它们看起来非常聪明，有时却极其愚蠢。但它们并不愚蠢：想象一下，给任何一位优秀的工程师一块白板，让他们在一个从未见过的大型代码库中实现一个新功能。对于智能体来说，每一次会话都是一个它们从未见过的项目。 问题在于智能体缺乏合适的工具。它们像1995年的工程师一样，仅使用纯文本，在没有集成开发环境（IDE）的时代，面临着30年前工程师所遇到的相同问题。当人类工程师只需将鼠标悬停在符号上或按下 F12 时，智能体却要花费成千上万的标记才能获得相同的结果。因此，我构建了它们所缺失的 IDE 部分，而没有它们不需要的编辑器部分——一个无头的 IDE，类似于无头浏览器。 最初，我的目标是通过为智能体提供廉价工具来消除 API 幻觉，以便它们能够解析 API，而不是对其进行猜测。为了进一步降低成本，我添加了内联提示：在调用位置解析类型和参数名称，这样智能体就可以将推理预算用于任务，而不是用于重建类型。 但随后我意识到还有一个更根本的问题：代码库并不是一组文件，而是一个符号图（依赖符号是其中的一部分）。如果我为智能体提供跟随图的工具，我就能让它们挑选出认为对当前任务有意义的符号。语言服务器协议（LSP）提供了这种能力。而 Tree-sitter 使得智能体能够仅挑选出这些符号中必要的部分。 自一月份以来，我每天在当前项目（数学到硅的合成引擎）中将其作为内部工具使用。经过七个月的广泛使用，我有一些想法（不是基准测试）： 1. 我原本期待通过消除 API 猜测来减少错误，但结果却更好。智能体的表现像是更优秀的工程师：它们倾向于重用代码库中已定义的抽象，而不是随意重复它们，类型和生命周期的编译错误几乎消失——它们也犯更少的逻辑错误。我的假设是，这源于减少了上下文污染：当智能体仅挑选与任务相关的信息时，它们的推理能力下降得更慢。 2. 降低标记使用并不是目标，但每个任务的节省却相当可观。 3. 最不寻常的体验是为机器设计用户体验。仅仅给智能体更好的工具是不够的：你必须说服它们使用这些工具，而不是它们内置的以文本为导向的工具。有效的解决方案是将工作流程（代码库探索、调试、依赖 API 发现、重构、阅读和编辑文档）描述为新工具的链，而不是单独描述每个工具。 上下文引擎完全在本地运行，您的代码永远不会离开您的机器。所有智能体及其子智能体共享一个守护进程：Claude Code、Codex、Cursor 或任何支持 MCP 的智能体都与同一个实例对话，而在同一工作区工作的智能体也共享为其服务的 LSP 服务器。 上下文引擎 MCP 需要一个 API 密钥，您可以在 <a href="https://context-engine.app" rel="nofollow">https://context-engine.app</a> 免费获取。我目前没有将其收费的计划，但希望保留未来这样做的权利。无论如何，现在是免费的，并且在可预见的未来将保持免费。它是与语言无关的，可以与任何语言一起工作，尽管到目前为止，它仅针对 Python、TypeScript/JavaScript、Rust、Go 和 Markdown 进行了端到端验证。已知的问题是 Java：jdtls 仍在与我作斗争。 我非常希望得到反馈，特别是在工具输出设计方面。

我花了很多时间研究ARKitScenes数据集，并建立了一个处理流程，输入原始数据（ARKit姿态/低分辨率深度图/视频），输出高分辨率深度和表面法线的多视图和表面精确的高斯点云！

嗨，HN，我是一名非技术背景的独立创始人，正在开发W，一个基于优质单字母域名（https://w.xyz）的人工智能驱动的网络邮件服务。 我已经获得了这个域名，并利用人工智能代理构建了一个功能性概念验证原型。为了处理基础设施，我通过Mailgun路由应用逻辑。内部原型已经完全运行——邮件可以成功发送和接收来自@w.xyz的账户。W结合了高度优化的界面和内置的人工智能功能，如垃圾邮件扫描、智能回复和文本摘要。 目前，我有超过30个有机的候补名单，因为我正在完成最后的调整，并准备脱离原型技术栈。 我想向社区提出几个问题： 1. 概念验证：考虑到电子邮件市场竞争激烈，您认为AI原生的高端网络邮件服务有可行的市场吗？还是您认为用户从Gmail/Outlook切换的成本太高？ 2. 扩展路线图：作为一名非技术创始人，正在逐步脱离AI生成的原型技术栈，我现在必须优先考虑哪些关键架构基准，以确保系统能够顺利扩展？ P.S. 如果您有兴趣从零开始构建一种新型邮件平台，请在下面留言。

我很好奇HN社区是否有关于如何实际应用最先进的人工智能来改善专业服务（例如外包财务等）的好资源（博客、播客、其他内容）。我已经阅读了很多人对应该如何做的看法（理论），但还没有找到很多实际操作过的人分享的内容（实践）。