最新

嗨，Hacker News！我构建了Oxyde，因为我厌倦了重复定义我的模型。<p>如果你使用FastAPI，你肯定知道这种痛苦。你为你的API定义Pydantic模型，然后为你的数据库定义单独的ORM模型，然后编写它们之间的转换器。SQLModel试图解决这个问题，但它仍然是基于SQLAlchemy。Tortoise给你一个很棒的Django风格的API，但它有自己的模型系统。Django ORM很棒，但与框架紧密结合。<p>我想要一些简单的东西：你的Pydantic模型就是你的数据库模型。一个类，完全验证输入和输出，原生类型提示，零重复。查询API是Django风格的（.objects.filter()、.exclude()、Q/F表达式），因为我认为这是最好的设计之一。<p><i>显式优于隐式。</i> 我试图移除所有魔法。查询在调用像.all()、.get()或.first()这样的终端方法之前，不会触及数据库。如果你没有显式地调用.join()或.prefetch()，相关的的数据将不会被加载。没有懒加载，没有在你背后出现的意外的N+1查询。你通过阅读代码就能确切地看到哪些操作会影响数据库。<p><i>类型安全</i> 是一个重要的驱动力。Python的弱点在于运行时出现意外，因此Oxyde从三个层面解决这个问题：（1）当你运行makemigrations时，它还会生成带有完全类型化查询的.pyi存根文件，这样你的IDE就知道filter(age__gte=...)接受一个int，create()接受你的模型拥有的确切字段，并且.all()返回list[User]而不是list[Any]；（2）Pydantic验证进入数据库的数据；（3）Pydantic通过model_validate()验证返回的数据。你获得自动补全、拼写错误的红色波浪线以及运行时保证，所有这些都来自同一个模型定义。<p><i>为什么选择Rust？</i> 目的不是为了速度。我不参与“语言X更好”的争论。每种语言都有其擅长的领域。Python在表达业务逻辑方面很难被超越。但是像SQL生成、连接池和行序列化这样的基础设施方面，系统语言更有意义。所以我把它分开了：Python处理你的模型和业务逻辑，Rust处理数据库管道。查询在Python中构建为IR，通过MessagePack序列化，发送到Rust，Rust生成特定于方言的SQL，执行它，并将结果流回。速度是这种分离的副作用，而不是目标。但由于你没有为便利性付出性能代价，如果你感兴趣，这里有基准测试：<a href="https:&#x2F;&#x2F;oxyde.fatalyst.dev&#x2F;latest&#x2F;advanced&#x2F;benchmarks&#x2F;" rel="nofollow">https:&#x2F;&#x2F;oxyde.fatalyst.dev&#x2F;latest&#x2F;advanced&#x2F;benchmarks&#x2F;</a><p>目前的功能：Django风格的迁移（makemigrations / migrate），带有保存点的事务，连接和预取，PostgreSQL + SQLite + MySQL，FastAPI集成，以及一个与FastAPI、Litestar、Sanic、Quart和Falcon配合使用的自动生成的管理面板（<a href="https:&#x2F;&#x2F;github.com&#x2F;mr-fatalyst&#x2F;oxyde-admin" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mr-fatalyst&#x2F;oxyde-admin</a>）。<p>目前是v0.5，beta版，正在积极开发中，API可能仍会更改。这是我尝试构建我个人想使用的ORM。欢迎反馈、批评和想法。<p>文档：<a href="https:&#x2F;&#x2F;oxyde.fatalyst.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;oxyde.fatalyst.dev&#x2F;</a><p>逐步的FastAPI教程（从头开始构建博客API）：<a href="https:&#x2F;&#x2F;github.com&#x2F;mr-fatalyst&#x2F;fastapi-oxyde-example" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mr-fatalyst&#x2F;fastapi-oxyde-example</a>

大家好，我是 Spine AI 的 Ashwin 和 Akshay（网址：https://www.getspine.ai）。 Spine Swarm 是一个多智能体系统，它在一个无限的视觉画布上运行，用于完成复杂的非编码项目：竞争分析、财务建模、SEO 审核、推介演示文稿、交互式原型等等。 这里有一个 Spine Swarm 运行的视频：https://youtu.be/R_2-ggpZz0Q 我们是相识超过 13 年的朋友。我们一起在 NTU 参加了我们的第一门机器学习课程，课程所在的校园区域被称为 North Spine，我们的名字也由此而来。我们在 S23 年通过了 YC，并花了大约 3 年的时间，在多次产品迭代中构建了 Spine。 核心理念是：聊天界面不适合复杂的 AI 工作。它是一个线性线程，而实际项目并非线性。当然，你可以要求聊天机器人参考线程早些时候的财务模型，或者一起进行研究和市场规模分析，但你得相信模型能够隐式地处理这些上下文。你无法看到它是如何连接各个部分的，无法在不重新运行所有内容的情况下纠正某一步骤，也无法并行地探索两种策略。ChatGPT 只是一个爆火的演示，聊天界面之所以能保留下来并成为默认界面，并不是因为它是一个正确的抽象。我们认为人类和智能体需要一个真正的工作区，在那里工作的结构是明确的、用户可控的，而不是隐藏在上下文窗口中。 因此，我们构建了一个无限的视觉画布，你可以在其中使用区块而不是线程进行思考。每个区块都是我们在 AI 模型之上的抽象。有专门的区块类型用于 LLM 调用、图像生成、网页浏览、应用程序、幻灯片、电子表格等等。可以把它们想象成 AI 工作流程的乐高积木：每个积木都有特定的功能，但它们可以以多种不同的方式组合在一起。你可以将任何区块连接到任何其他区块，这种连接保证了上下文的传递，而不管区块类型如何。整个系统与模型无关，因此在一个工作流程中，你可以从 OpenAI LLM 调用开始，到 Nano Banana Pro 等图像生成模式，再到 Claude 生成交互式应用程序，每个区块都使用最适合的模型。多个区块可以从同一个输入中扇出，用不同的模型以不同的方式进行分析，然后将它们的输出输入到下游区块中，合成结果。 画布的第一个版本是完全手动操作的。用户输入提示、选择模型、运行区块并自行建立连接。它与创始人以及产品经理们一拍即合，因为他们可以从同一个起点向不同的方向分支：从一个产品创意开始，在一个分支中生成原型，在另一个分支中生成 PRD，在第三个分支中生成竞争分析，在第四个分支中生成推介演示文稿，所有这些都共享相同的上游上下文。但新用户不想学习这个界面。他们一直要求我们构建一个聊天层，可以代表他们生成和连接区块，以复制我们使用该工具的方式。因此，我们构建了这个聊天层，并且在构建过程中，我们发现了一些意想不到的事情：智能体能够自主运行数小时，生成完整的可交付成果。事实证明，智能体可以通过将工作委托给区块并将中间上下文存储在画布上，而不是将所有内容保存在单个上下文窗口中，从而运行更长时间并保持其上下文窗口的清洁。 现在它的工作原理如下。当你提交一个任务时，一个中央协调器会将其分解为子任务，并将每个子任务委托给专门的角色智能体。这些智能体在画布区块上运行，并且可以覆盖默认设置，主要是模型和提示，以适应每个子任务。智能体为每个区块选择最佳模型，有时会使用多个模型运行同一个区块，以进行比较和合成输出。当子任务之间没有依赖关系时，多个智能体并行工作，下游智能体自动接收来自上游工作的上下文。用户无需配置任何这些。你也可以同时调度多个任务，系统将对相关的任务进行排队，或者立即启动独立的任务。 默认情况下，智能体并非完全自主。任何智能体都可以在继续之前暂停执行并向用户寻求澄清或反馈，这使得人类可以参与到重要的环节中。一旦智能体生成了输出，你就可以在画布上选择一部分区块，并通过聊天进行迭代，而无需重新运行整个工作流程。 画布为智能体提供了文件系统和消息传递所不具备的东西：一个持久的、结构化的整个项目表示，任何智能体都可以在任何时候读取和贡献。在典型的多智能体系统中，上下文会随着其在智能体之间传递而退化。画布解决了这个问题，因为智能体将中间结果存储在区块中，而不是试图将所有内容保存在内存中，并且它们会留下明确的结构化交接，旨在被链中的下一个智能体高效地使用。每一步也都是完全可审计的，因此你可以准确地追踪每个智能体是如何得出结论的。 我们进行了基准测试以验证我们所看到的结果。在 Google DeepMind 的 DeepSearchQA 上，该测试包含 900 个问题，涵盖 17 个领域，每个问题都结构化为一个因果链，其中每一步都取决于前一步的完成情况，Spine Swarm 在整个数据集上的得分为 87.6%，且无需人工干预。对于基准测试，我们使用了与问题相关的区块类型的子集（LLM 调用、网页浏览、表格），并删除了不相关的区块类型，如文档、电子表格和幻灯片生成。我们还禁用了人工澄清，因此智能体完全独立运行。这些智能体不仅可审计，而且是最先进的。可审计性也暴露了旧基准测试（GAIA Level 3）中的实际错误，即预期答案错误或模棱两可的情况，而这些情况你永远无法通过黑盒管道捕捉到。我们在完整的文章中详细介绍了方法、架构和基准测试错误：https://blog.getspine.ai/spine-swarm-hits-1-on-gaia-level-3-and-google-deepmind-deepsearchqa 基准测试衡量的是封闭式问题的准确性。事实证明，同样的架构也能在最少的监督下产生更好的开放式输出，如演示文稿、报告和原型。我们看到早期用户分成了两类：一些人会观察智能体的工作并介入以在中途重定向，另一些人则会排队一个任务并回来获取已完成的可交付成果。这两种方式都有效，因为画布保留了完整的工作链，因此你可以随时进行审计或干预。 一个好的第一个尝试任务是：提供你的网站 URL，并要求进行全面的 SEO 分析、竞争格局分析以及带有幻灯片的优先增长路线图。你将看到多个智能体同时在画布上启动。人们还用它来制作带有财务模型的融资推介演示文稿、从屏幕截图和 PRD 中制作原型功能、竞争分析报告以及从多个角度研究一个主题并生成你可以进一步探索的结构化材料的深度学习计划。 定价是基于使用情况的积分，与区块使用情况和使用的底层模型相关。智能体往往比手动工作流程使用更多的积分，因为它们经过调整，可以为你提供最佳结果，这意味着它们会选择最佳区块并做更多的工作。详情请见：https://www.getspine.ai/pricing。有一个免费套餐，还有一个诚实的警告：我们调整了套餐的大小，让你能够尝试一个真实的任务，但任务的复杂性各不相同。如果你在有足够机会探索之前就用完了积分，请发送电子邮件至 founders@getspine.ai，我们会与你合作。 我们很乐意收到你对体验的反馈：哪些有效，哪些无效，以及哪些方面有所不足。我们也很想知道这里其他人如何处理编码之外的复杂、多步骤的 AI 工作。你正在使用什么工具，以及首先会出什么问题？我们将在评论区停留一整天。

我使用中继架构，在上下文进入“哑区”之前级联一个新的编码代理，理论上，一个 AI 可以无限期地以最佳状态进行编码。没有上下文腐烂。

在 Opus 4.6 之后，大型语言模型 (LLM) 在使用 bash、代码、本地文件和工具方面表现得更好。<p>因此，我一直在思考一个简单的问题：如果一个模型能够相当好地使用计算机，为什么我不能直接给它我的券商账户、一个策略，然后让它进行交易呢？<p>我的结论是，阻碍因素并非抽象意义上的模型能力，而是模型周围的系统。<p>一个原始的 LLM 几乎立刻会在几个实际问题上崩溃：<p>• 跨会话没有持久的操作系统内存<br>• 没有对它做了什么以及为什么这样做的可靠记录<br>• 在资金转移之前没有严格的批准界限<br>• 如果每次检查都需要调用 LLM，则没有廉价的、始终在线的监控<br>• 除非限制、权限或工作流程规则存在于模型之外，否则无法可靠地执行<p>所以问题实际上并不是“模型能否调用券商 API？” 问题在于交易需要一个“束缚”。<p>我和我的朋友为此构建了一个名为 Vibe Trade 的工具。它是开源的，采用 MIT 许可证，目前在您的机器上本地运行，并连接到 Dhan。<p>基本设计是：<p>1. 不可变的交易日志<br>每个操作都会在决策时记录时间戳、推理和观察到的信号。代理无法在事后重写其自身的历史记录。<p>2. 严格的审批门<br>在下任何订单之前，系统会生成一个结构化的审批请求。在用户批准之前，执行将被阻止。这在代码中强制执行，而不是留给模型自行决定。<p>3. LLM 之外的事件循环<br>市场观察由纯 JS 在计时器上处理。价格检查、时间规则和指标阈值每 30 秒运行一次，无需调用模型。LLM 仅在需要推理时才会唤醒。<p>4. 剧本 / 技能文件<br>策略存在于 markdown 文档中，这些文档在每次决策时都会被加载为操作上下文。例如：“复制 Nifty Defense 指数并每周重新平衡。” 这为代理提供了一个稳定的工作流程定义，而不是依赖于聊天记录。<p>第一个让我觉得这很真实的使用案例非常不起眼：投资组合再平衡。<p>我过去常常创建 Smallcase 风格的指数复制投资组合，然后忘记按时重新平衡它们。通过这种设置，我可以定义一次策略，让非 LLM 层监控条件，并让代理准备好操作以供批准。这是它不再像演示，而是开始感觉有用的第一个时刻。<p>一些注意事项：<br>• 用户界面仍然很弱；目前主要是一个聊天界面<br>• 仅限 Dhan<br>• 仅限本地安装<br>• 需要 Node.js 和 Anthropic API 密钥<p>仓库：github.com&#x2F;vibetrade-ai&#x2F;vibe-trade<p>我发布这篇文章的主要原因是我认为现在工具使用变得更好，并且金融领域使失败模式非常明显，因此会有更多人尝试构建“LLM 作为操作员”的系统。<p>我感兴趣的问题是：<p>• 像这样的系统还缺少哪些其他“束缚”组件？<p>• 您会更信任像这样的本地系统还是托管系统，或者更不信任？<p>• 您首先会自动化哪些可重复的金融工作流程？

现代科技拥有庞大的开源生态系统和巨额的投资者支持，但在合作社方面的活动却微乎其微。合作社是指个人或小型公司联合资金和其他资源，以利用规模经济并与大公司竞争，而不是彼此竞争。 随着人们越来越依赖少数几家大型公司，而这些公司又日益试图利用其规模来提高价格、利润和盈利能力，合作社似乎是这个领域越来越需要的。

我十年前开始用 JavaScript 写这本书，写了几个章节（渐近符号、基本技巧、排序的开端），然后就放弃了。 最近我重新拾起这本书，把所有内容都转换成了 TypeScript，并使用 AI (Zenflow [1] + Claude Opus 4.6) 完成了剩余的章节。我提供了结构、方向和最初的章节；AI 在规范驱动的工作流程下生成了剩余内容的大部分。 这本书大致涵盖了计算机科学 1-2 年级的课程：排序、动态规划、图算法、树、堆、哈希表等等。所有代码都是可执行的，使用泛型/接口进行类型化，并附有测试。 我彻底审查了几个章节（排序、DP、图），并对其他章节进行了高层次的浏览。目前处于 Beta 测试阶段——欢迎提供更正和贡献。 采用 MIT 许可证。灵感来源于 Wirth 的《算法与数据结构》、SICP 和 CLRS。 代码和测试：[https://github.com/amoilanen/Algorithms-with-Typescript](https://github.com/amoilanen/Algorithms-with-Typescript) [1] [https://zencoder.ai/zenflow](https://zencoder.ai/zenflow)