24小时热榜

Claude 代码目前返回 5XX 错误 :(

Hi HN， 在 Imbue，我们一直在关注代理领域（agent landscape）的快速发展，并注意到代理代表用户与第三方服务交互的方式往往不尽如人意。集成是临时的、复杂的、依赖上下文的，而且要么对非技术用户不友好，要么与某种形式的锁定有关。 我们正在试验一个命令行工具 Latchkey，它可以被面向非技术用户的本地代理使用，同时避免远程中介。据我们所知，这是在实现这两个目标交叉点上唯一现有的方法。 核心理念：代理通过在普通的 `curl` 调用前加上 `latchkey` 命令来访问第三方服务的 API，例如： ``` latchkey curl -X POST 'https://slack.com/api/conversations.create' \ -H 'Content-Type: application/json' \ -d '{"name":"something-urgent"}' ``` 然后，Latchkey 会透明地将凭据注入到这些调用中，并在需要时提示用户通过浏览器弹出窗口登录。浏览器自动化用于从登录后的浏览器会话中提取 API 令牌。 优点： * 一个技能即可与所有服务集成。 * 代理和第三方服务之间的直接通信（不需要 OAuth 中介应用程序）。 * 非技术用户可以使用代理。 * 密钥不会泄漏到日志或聊天记录中。 我们相信这与去中心化未来的愿景相符，在这种未来中，人们不需要向公司请求许可来使用他们自己的数据。我们设想一个充满活力的本地代理生态系统，人们可以自由使用，并由一个社区支持，互相帮助保持这些工具的实用性和功能性。 我们也意识到这种方法也有一些缺点，并希望得到您的反馈。 附注：这里还有一个链接，指向使用 Latchkey 构建的玩具演示 AI 助手应用程序 Passepartout：[https://github.com/imbue-ai/passepartout](https://github.com/imbue-ai/passepartout)

大家好，我是 Aram 和 Eduard，Modelence (<a href="https:&#x2F;&#x2F;modelence.com">https:&#x2F;&#x2F;modelence.com</a>) 的联合创始人。在花了数年时间扩展我们之前创业公司的平台之后，我们构建了一个开源的全栈 TypeScript + MongoDB 框架，目的是为了不再每次创建应用程序时都重复解决身份验证、数据库、API 和定时任务的实现问题。我们也不喜欢为运行这些应用程序而使用多个托管平台。（这里是我们的之前的 Show HN 帖子，供参考：<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=44902227">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=44902227</a>） 与此同时，我们对整个 AI 应用程序构建器的热潮感到兴奋，并意识到真正的挑战在于平台本身，而不是工具。现在，我们正在将 Modelence 打造成第一个为编码代理和人类构建的全栈框架： * TypeScript 非常适合 AI 编码，因为它提供了保护措施并在构建时捕获许多错误，因此代理可以自动纠正 * MongoDB 消除了代理的模式管理问题，这是它们最常失败的地方（+ 与 TS/Node.js 配合良好） * 内置的身份验证、数据库、定时任务等功能开箱即用，这意味着代理只需专注于您的产品逻辑，而不会在尝试设置这些功能时失败（+ 减少了在样板代码上花费的 token）。 现在，您可以通过在我们的登陆页面上输入提示来试用 Modelence 应用程序构建器（基于 Claude Agent SDK）（<a href="https:&#x2F;&#x2F;modelence.com">https:&#x2F;&#x2F;modelence.com</a>）- 在这里观看演示视频：<a href="https:&#x2F;&#x2F;youtu.be&#x2F;BPsYvj_nGuE" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;BPsYvj_nGuE</a> 然后，您可以在本地进行检查，并在您自己的 IDE 中继续工作，同时仍然使用 Modelence Cloud 作为您的后端，拥有一个开发云环境，稍后可以在 Modelence Cloud 上部署和运行，并围绕应用程序中运行的每个操作进行内置的可观察性。 我们还将添加一个内置的 DevOps 代理，该代理位于同一云中，全面了解该框架，并将使用所有这些可观察性数据来处理错误、警报和事件——从而闭环，因为在生产环境中运行比仅仅构建要困难得多。 我们推出了应用程序构建器作为开发人员的快速入门，以演示该框架和 Modelence Cloud，而无需手动阅读文档并按照步骤设置新应用程序。我们的主要关注点仍然是平台本身，因为我们认为 AI 编码的真正挑战在于框架和平台，而不是构建器工具本身。

大家好

嘿，HN！我上周参加了一个 ATProto 聚会，作为一个对学术出版深恶痛绝的、身心俱疲的半个学者，我觉得这可能是一个基于 Octopus（<a href="https://www.octopus.ac/" rel="nofollow">https://www.octopus.ac/</a>）构建一些有趣东西的机会，所以我周末有点兴奋，并构建了 Octosphere。 希望你们中的一些人觉得它有趣！博客文章在这里：<a href="https://andreasthinks.me/posts/octosphere/octosphere.html" rel="nofollow">https://andreasthinks.me/posts/octosphere/octosphere.html</a>

我多年来一直是网络小说读者（在 Royal Road 上花费了太多时间），并且一直遇到同样的问题：哪些 LLM 真正创作出人们想一直阅读的小说？这就是我构建 Narrator（<https://narrator.sh/llm-leaderboard）的原因——一个 LLM 生成连载小说并根据真实读者参与度进行排名的平台。 事实证明，这个问题出乎意料地难以回答。创意写作并非单一能力，而是一个流程：头脑风暴 → 写作 → 记忆。你需要生成有趣的设定，用优美的文笔来执行它们，并在长篇叙事中保持一致性。大多数基准测试分别测试这些方面，但读者会将它们作为一个整体来体验。 目前的评估格局是分散的： 像 FictionLive 的测试这样的记忆力基准测试使用多项选择题来检查模型是否记住了长篇上下文中的情节细节。这很有用，但记忆力是写好小说的必要条件，而不是充分条件。一个模型可以轻松通过回忆测试，但仍然写出无聊的故事。 来自 Novelcrafter 等工具的作者端使用数据表明，作家更喜欢哪些模型作为副驾驶。但这衡量的是对人机协作有用的东西，而不是产生引人入胜的独立输出。作者和读者有不同的需求。 LLM 作为评判者是评估写作质量最常见的方法，但它在创意作品方面是出了名的不可靠。模型存在系统性偏差（偏爱冗长的文笔、某些结构），而“好的写作”在某种程度上是主观的，这与“正确的代码”不同。 缺少的是一个读者端的定量基准——衡量真实人类是否真的喜欢阅读这些模型产生的内容。这正是 Narrator 填补的空白：浏览量、阅读时间、评分、书签、评论、回访。可以把它想象成一个“AI 版 Wattpad”，其中模型是作者。 我 5 个月前在这里分享了一个基于 DSPy 的早期版本（<https://news.ycombinator.com/item?id=44903265）。最大的教训是：单次生成不适用于长篇小说。模型会丢失情节线索，忘记角色，并且质量会随着章节的推移而下降。 重写：从单次生成到持久的代理循环 当前版本通过一个写作工具运行每个模型，该工具在各章节中保持状态。在生成之前，代理会查看结构化的上下文：人物设定、情节大纲、未解决的线索、世界构建笔记。在生成之后，它会更新这些工件以用于下一章。本质上，每个模型都获得了一个“作家的笔记本”，该笔记本贯穿整个故事。 这带来了可衡量的差异——在单次生成版本中难以保持一致性的模型，在能够访问自己的笔记后，有了显著的改进。 细粒度过滤而不是单一分数： 我们预先按语言、类型、标签和内容分级对故事进行分类。我们没有一个“创意写作”排行榜，而是可以深入研究具体内容：哪个模型写得最好的西班牙喜剧？哪个模型最擅长处理以男性为主角的 LitRPG 故事？哪个模型在浪漫与恐怖方面表现出色？ 答案并不总是你从一般基准测试中期望的那样。一些整体排名中等的模型在特定领域占据主导地位。 我引以为豪的几个功能： 故事分叉允许读者以 CYOA（选择你自己的冒险）风格分支故事——如果你不喜欢情节的发展方向，可以分叉它，看看同一个模型如何处理这种分歧。创建自然的 A/B 比较。 视觉 LitRPG 是一个我个人想解决的问题。统计数据和技能树呈现为实际的 UI 元素，而不是一堆 [STR: 15 → 16] 文本。示例：<https://narrator.sh/novel/beware-the-starter-pet/chapter/1> 我正在寻找： 更多的读者来构建参与度数据。也很好奇是否有其他人在研究长篇 LLM 生成方面的人发现了更好的模式来保持各章节之间的一致性——代理工具方法有效，但我相信会有改进。

我做了十多年的“光子在玻璃上”的电影制作人，一直在为自己、朋友和同事开发 ArtCraft。<p>我所有的电影学院的朋友都雄心勃勃，但制作金字塔并不能让个人才能轻易闪耀。一万名学生进入电影学院，但只有少数人能够自主地执导他们想要的项目——而且几乎从未达到能满足他们想要的创意愿景的巨额预算水平。裙带关系也很严重。<p>AI 是电影的个人电脑时代，就像 DAW（数字音频工作站）。<p>我的一位朋友用真人做了动态描绘：<p><a href="https://www.youtube.com/watch?v=Tii9uF0nAx4" rel="nofollow">https://www.youtube.com/watch?v=Tii9uF0nAx4</a><p>Corridor 工作室的人们用这项技术展示了很多创造力：<p><a href="https://www.youtube.com/watch?v=_9LX9HSQkWo" rel="nofollow">https://www.youtube.com/watch?v=_9LX9HSQkWo</a><p><a href="https://www.youtube.com/watch?v=DSRrSO7QhXY" rel="nofollow">https://www.youtube.com/watch?v=DSRrSO7QhXY</a><p><a href="https://www.youtube.com/watch?v=iq5JaG53dho" rel="nofollow">https://www.youtube.com/watch?v=iq5JaG53dho</a><p>我们自己也制作了一些愚蠢的短片：<p><a href="https://www.youtube.com/watch?v=oqoCWdOwr2U" rel="nofollow">https://www.youtube.com/watch?v=oqoCWdOwr2U</a><p><a href="https://www.youtube.com/watch?v=H4NFXGMuwpY" rel="nofollow">https://www.youtube.com/watch?v=H4NFXGMuwpY</a><p>秘密是很多工作室使用 AI 已经一年多了。你只是没有注意到，而且他们永远不会告诉你，因为有污名。这就是“糟糕的假发谬论”——你只有在它很糟糕的时候才会注意到，而且他们永远不会告诉你其他情况。<p>Comfy 很棒，但我与那些不理解节点图的人一起工作，他们要么没有具有足够 VRAM 的显卡，要么无法管理 Python 依赖项。基础模型都很有竞争力，而且它们变得越来越可控——而这才是关键——控制。所以我一直在研究 UI/UX 控制层。<p>ArtCraft 具有 2D 和 3D 控制界面，其中 3D 部分可以用作“图像到图像”（I2I）和“图像到视频”（I2V）工作流程的强大而直观的 ControlNet。它几乎就像一个所见即所得，我确信这是这项技术将为创意专业人士演进的方向，而不是以文本为中心的提示。<p>我一直对 Gimp 和 Blender 这样的工具感到沮丧。我不是 UX/UI 大师，但我不喜欢复杂的工具——尤其是复杂的开源工具。商业级工具更好。Figma 是崇高的。创意人员的 IDE 应该简单、神奇和强大。<p>ArtCraft 允许你轻松地从各种创意画布和资源抽屉中拖放。它快速而直观。在文本到图像进行快速原型设计、图像编辑、3D 生成到 3D 合成之间切换非常流畅。感觉就像“制作”，而不是提示或节点图的奇技淫巧。<p>ArtCraft 作为一个桌面应用程序，允许我们登录第三方计算提供商。我非常支持使用和集成你订阅的模型，无论你在哪里拥有它们。例如，这让我们集成了 WorldLabs 的 Marble Gaussian Splats，而且没有人这样做过。我的计划是随着时间的推移添加每个提供商，包括基于通用 API 密钥的计算提供商，如 FAL 和 Replicate。我不在乎你是否为 ArtCraft 付费——我只是希望它有用。<p>两个免责声明：<p>ArtCraft 是“公平来源”——我想走 Cockroach DB 的路线，最终获得资金，但保留该工具本身 100% 的源代码，供人们自己构建和运行。就像 Obsidian，但有源代码。如果我们做大了，我会花很多时间制作电影。<p>目前 ArtCraft 绑定到一个轻量级的云服务——我不喜欢这样。这是一个选择，这样我就可以重用一个旧项目并快速行动，但我打算让它很快完全离线工作。所有服务器代码都在 monorepo 中，因此你可以自己运行所有内容。在适当的时候，我确实设想了一个可移植的 OSS 云，供各种 AI 工具读/写，就像一个用于资产的 Github，但这目前只是一个遥远的想法。<p>我已经在 repo 中写了关于路线图的内容：我想为每个计算提供商开发集成，用 Bevy 重写前端 UI/UX 以获得完全原生的客户端，并集成本地模型。