返回首页
最新
上周五，我与Claude开始了一场关于操作系统的对话。这场对话演变成了一次设计会议，设计会议又转变为一个原型。从那时起，我几乎没有停下来过。
核心理念是：你的文件存在于应用程序内部。应用程序决定你如何查看内容、可以对其进行什么操作，以及你的工作保存在哪里。如果操作系统能够直接理解你的文件——渲染它们、索引它们、追踪它们的历史——而编辑器只是你在需要修改某些内容时才使用的工具呢？没有“用...打开”，也没有保存按钮。默认是查看，编辑则是有意为之。
经过一周的努力，现有的成果包括：一个用Rust从零开始开发的内核，运行在QEMU（aarch64）上，27个系统调用，具有4个对称多处理核心的EEVDF调度器，一个完整的显示管道（合成器、亚像素TrueType渲染、透明混合、PNG图像查看器），通过共享内存环形缓冲区实现的结构化进程间通信，一个编辑器进程模型，其中操作系统服务是唯一的写入者，一个文件系统原型，900多个测试，包括正式的错误审计，以及约2200行设计文档，包含13个已确定的架构决策。在上周五之前，我甚至从未见过Rust代码。
完整故事包括演示、逐日时间线、我如何与人工智能合作以及我学到了什么：<a href="https://github.com/jonathanrtuck/os/discussions/1" rel="nofollow">https://github.com/jonathanrtuck/os/discussions/1</a>
代码库：<a href="https://github.com/jonathanrtuck/os" rel="nofollow">https://github.com/jonathanrtuck/os</a>
我并不是想要构建下一个Linux。这是一次设计探索——如果从内核开始重新思考整个技术栈，OpenDoc和Xerox Star所尝试的以文档为中心的模型是否真的可行？我真心想知道这个社区的看法。
嘿，HN，我很高兴与大家分享 PNANA——一款轻量级、现代化的终端文本编辑器，使用 C++17 和 FTXUI 构建，旨在为习惯在终端中工作的开发者提供简单与强大之间的桥梁。
PNANA 有什么不同之处？
零学习曲线：摒弃 Vim/Neovim 的模式复杂性，采用与图形界面编辑器相似的 Ctrl+S/Ctrl+Z 快捷键。
美观的终端 UI：开箱即用的主题（Monokai、Dracula、Nord 等）、三列布局和智能状态栏——无需配置即可呈现出色的外观。
内置 LSP 支持：为所有主要编程语言（C/C++、Go、Rust、Python、JS/TS 等）提供原生代码补全、实时诊断、跳转到定义和符号搜索功能。
轻量且快速：终端原生，资源占用低，启动瞬间——非常适合远程服务器和本地开发。
可扩展的未来：计划中的 Lua 插件系统（受 Neovim 启发）将允许用户通过自定义脚本扩展功能。
我很想听听你的想法、反馈或功能请求！查看一下这个仓库，如果你喜欢，请给它加星，让我们一起打造更好的终端编辑器。
英文 README: [https://github.com/Cyxuan0311/PNANA/blob/master/README_EN.md](https://github.com/Cyxuan0311/PNANA/blob/master/README_EN.md)
嗨，HN！我创建Oxyde是因为我厌倦了重复我的模型。
如果你使用FastAPI，你就知道这个流程。你为API定义Pydantic模型，然后为数据库定义单独的ORM模型，再在它们之间编写转换器。SQLModel尝试解决这个问题，但底层仍然是SQLAlchemy。Tortoise提供了一个很好的Django风格的API，但有自己的模型系统。Django ORM很棒，但与框架紧密结合。
我想要一些简单的东西：你的Pydantic模型就是你的数据库模型。一个类，输入和输出的完整验证，原生类型提示，零重复。查询API采用Django风格（.objects.filter()、.exclude()、Q/F表达式），因为我认为这是最好的设计之一。
**明确优于隐含。** 我尝试去除所有的魔法。查询在你调用终端方法（如.all()、.get()或.first()）之前不会触及数据库。如果你没有明确调用.join()或.prefetch()，相关数据将不会被加载。没有延迟加载，也没有意外的N+1查询。你可以通过阅读代码准确看到哪些操作触及了数据库。
**类型安全**是一个重要的动机。Python的弱点在于运行时的意外，因此Oxyde在三个层面上解决了这个问题：（1）当你运行makemigrations时，它还会生成带有完全类型化查询的.pyi存根文件，这样你的IDE就知道filter(age__gte=...)接受一个int，create()接受你的模型所具有的确切字段，而.all()返回list[User]而不是list[Any]；（2）Pydantic验证进入数据库的数据；（3）Pydantic通过model_validate()验证返回的数据。你可以从同一个模型定义中获得自动补全、拼写错误的红色波浪线和运行时保证。
**为什么选择Rust？** 不是为了追求速度。我不参与“语言X更好”的争论。每种语言都有其擅长的领域。Python在表达业务逻辑方面难以超越。但像SQL生成、连接池和行序列化这样的基础设施工作，使用系统语言更有意义。因此我将其分开：Python处理你的模型和业务逻辑，Rust处理数据库的底层工作。查询在Python中构建为中间表示（IR），通过MessagePack序列化，发送到Rust，Rust生成特定方言的SQL，执行它，并将结果流回。速度是这种分离的副产品，而不是目标。但由于你不需要为便利性支付性能税，如果你感兴趣，这里有基准测试： [https://oxyde.fatalyst.dev/latest/advanced/benchmarks/](https://oxyde.fatalyst.dev/latest/advanced/benchmarks/)
目前的功能包括：Django风格的迁移（makemigrations / migrate）、带保存点的事务、连接和预取、PostgreSQL + SQLite + MySQL、FastAPI集成，以及一个与FastAPI、Litestar、Sanic、Quart和Falcon兼容的自动生成的管理面板（[https://github.com/mr-fatalist/oxyde-admin](https://github.com/mr-fatalist/oxyde-admin)）。
这是v0.5版本，处于测试阶段，正在积极开发中，API可能仍会变化。这是我个人想要使用的ORM的尝试。欢迎反馈、批评和想法。
文档：[https://oxyde.fatalist.dev/](https://oxyde.fatalist.dev/)
逐步FastAPI教程（从零开始构建博客API）：[https://github.com/mr-fatalist/fastapi-oxyde-example](https://github.com/mr-fatalist/fastapi-oxyde-example)
大家好！我们是来自 Spine AI 的 Ashwin 和 Akshay（<a href="https://www.getspine.ai">https://www.getspine.ai</a>）。
Spine Swarm 是一个多智能体系统，能够在无限的视觉画布上完成复杂的非编码项目：竞争分析、财务建模、SEO审计、投资提案、互动原型等等。
这是 Spine Swarm 实际操作的视频：<a href="https://youtu.be/R_2-ggpZz0Q" rel="nofollow">https://youtu.be/R_2-ggpZz0Q</a>
我们已经是朋友超过13年了。我们在 NTU 的北脊（North Spine）校区一起上了第一门机器学习课程，这也是我们名字的来源。我们在 S23 参加了 YC，并花了大约三年时间在多个产品迭代中构建 Spine。
核心理念是：聊天并不是进行复杂 AI 工作的正确界面。它是一个线性线程，而真实项目并不是线性的。确实，你可以要求聊天机器人参考线程中早期的财务模型，或者一起进行研究和市场规模分析，但你是在隐含地信任模型来处理这些上下文。你无法看到它是如何连接各个部分的，也无法在不重新运行所有内容的情况下纠正某一步，更无法并行探索两种策略。ChatGPT 是一个引起轰动的演示，而聊天作为默认界面存在，并不是因为它是正确的抽象。我们认为人类和智能体需要一个真实的工作空间，在这个空间中，工作的结构是明确且可控的，而不是隐藏在上下文窗口中。
因此，我们构建了一个无限的视觉画布，让你可以用块而不是线程进行思考。每个块都是我们在 AI 模型之上的抽象。针对 LLM 调用、图像生成、网页浏览、应用程序、幻灯片、电子表格等有专门的块类型。可以把它们想象成 AI 工作流程的乐高积木：每个块都有特定的功能，但可以以多种方式组合在一起。你可以将任何块连接到任何其他块，这种连接确保了上下文的传递，无论块的类型如何。整个系统是模型无关的，因此在单一工作流程中，你可以从 OpenAI LLM 调用，转到像 Nano Banana Pro 的图像生成模式，再到 Claude 生成的互动应用，每个块使用最合适的模型。多个块可以从同一输入分支出来，以不同的方式用不同的模型进行分析，然后将它们的输出传递给下游块进行结果综合。
画布的第一个版本是完全手动的。用户输入提示，选择模型，自己运行块并建立连接。这种方式与创始人和产品经理产生了共鸣，因为他们可以从同一个起点向不同方向分支：在一个分支中生成产品原型，在另一个分支中生成 PRD，在第三个分支中进行竞争评估，在第四个分支中制作投资提案，所有分支共享相同的上游上下文。但新用户不想学习这个界面。他们不断要求我们构建一个聊天层，代表他们生成和连接块，以复制我们使用工具的方式。因此，我们构建了这个功能，并在此过程中发现了一个意想不到的事情：智能体能够自主运行数小时，生成完整的交付物。事实证明，智能体可以通过将工作委派给块并在画布上存储中间上下文，而不是将所有内容都放在单一的上下文窗口中，从而更长时间地运行并保持上下文窗口的清晰。
现在它的工作方式是这样的。当你提交一个任务时，一个中央协调器将其分解为子任务，并将每个子任务委派给专门的角色智能体。这些智能体在画布块上操作，可以覆盖默认设置，主要是模型和提示，以适应每个子任务。智能体为每个块选择最佳模型，有时会用多个模型运行同一个块以比较和综合输出。当它们的子任务没有依赖关系时，多个智能体可以并行工作，下游智能体会自动接收来自上游工作的上下文。用户无需配置任何内容。你还可以同时派发多个任务，系统会将依赖任务排队，或立即启动独立任务。
智能体默认并不是完全自主的。任何智能体都可以暂停执行，并在继续之前向用户请求澄清或反馈，这样可以在关键时刻保持人类参与。一旦智能体生成了输出，你可以在画布上选择一部分块，并通过聊天对其进行迭代，而无需重新运行整个工作流程。
画布为智能体提供了文件系统和消息传递所没有的东西：一个持久的、结构化的整个项目表示，任何智能体都可以在任何时候读取和参与。在典型的多智能体系统中，随着上下文在智能体之间传递，信息会逐渐退化。画布解决了这个问题，因为智能体将中间结果存储在块中，而不是试图将所有内容保存在内存中，并且它们留下了明确的结构化交接，旨在高效地被链中下一个智能体消费。每一步也是完全可审计的，因此你可以准确追踪每个智能体是如何得出结论的。
我们进行了基准测试以验证我们的观察。在谷歌 DeepMind 的 DeepSearchQA 上，这是一组涵盖17个领域的900个问题，每个问题都结构化为因果链，其中每个步骤依赖于完成前一个步骤，Spine Swarm 在整个数据集上得分87.6%，且没有任何人工干预。对于基准测试，我们使用了与问题相关的块类型子集（LLM 调用、网页浏览、表格），并移除了文档、电子表格和幻灯片生成等不相关的类型。我们还禁用了人工澄清，因此智能体完全独立运行。这些智能体不仅可审计，而且处于最前沿。审计的过程还揭示了在旧基准（GAIA Level 3）中的实际错误，即期望答案错误或模糊的案例，这在黑箱流程中是无法发现的。我们在完整的报告中详细介绍了方法论、架构和基准错误：<a href="https://blog.getspine.ai/spine-swarm-hits-1-on-gaia-level-3-and-google-deepmind-deepsearchqa">https://blog.getspine.ai/spine-swarm-hits-1-on-gaia-level-3-...</a>
基准测试测量封闭式问题的准确性。事实证明，相同的架构也能在最小监督下产生更好的开放式输出，如幻灯片、报告和原型。我们看到早期用户分成了两派：一些人观察智能体工作并在流程中跳入重新引导，另一些人则排队一个任务，回来时看到完成的交付物。这两种方式都有效，因为画布保留了完整的工作链，因此你可以随时进行审计或干预。
一个不错的首个任务是：给它你的网站 URL，并请求进行完整的 SEO 分析、竞争格局和优先级增长路线图，以及幻灯片。你会看到多个智能体同时在画布上运作。人们还利用它来制作融资投资提案，包括财务模型、从截图和 PRD 中原型化功能、竞争分析报告以及从多个角度研究主题并生成结构化材料的深度学习计划，以便进一步探索。
定价是基于使用量的积分，与块的使用和所用的基础模型相关。智能体通常比手动工作流程使用更多的积分，因为它们经过调优以获得最佳结果，这意味着它们选择最佳块并做更多工作。详细信息请见：<a href="https://www.getspine.ai/pricing">https://www.getspine.ai/pricing</a>。有一个免费层，还有一个诚实的警告：我们将其设计为让你尝试一个真实的任务，但任务的复杂性各不相同。如果你在没有充分机会探索之前用完了积分，请通过 founders@getspine.ai 给我们发邮件，我们会与你合作。
我们非常希望听到你对体验的反馈：哪些有效，哪些无效，以及哪里存在不足。我们也很好奇这里的其他人如何处理复杂的多步骤 AI 工作，除了编码之外。你们使用什么工具，最先出现的问题是什么？我们会在评论区待一整天。