最新

大家好，我是 superglue 的 Stefan。今天我想分享我们刚刚开源的一个新基准测试：Agent-API 基准测试，我们用它来测试 LLM 处理 API 的能力。<p>我们向 LLM 提供了 API 文档，并要求它们编写代码来实际调用 API。例如“创建 Stripe 客户”或“发送 Slack 消息”。我们不是在测试它们是否可以使用 SDK；我们测试的是它们是否可以编写原始 HTTP 请求（具有适当的身份验证、标头、正文格式），这些请求在针对真实的 API 端点执行时确实有效，并且可以从响应中提取相关信息。<p>总结：LLM 在编写使用 API 的代码方面很糟糕。<p>我们使用 6 种不同的 LLM 运行了 630 个集成测试，涵盖了 21 个常用 API（Stripe、Slack、GitHub 等）。以下是我们的主要发现：<p>- 最佳通用 LLM：成功率为 68%。这意味着每 3 次 API 调用中就有 1 次失败，大多数人认为这在生产环境中是不可行的<p>- 我们的集成层获得了 91% 的成功率，这表明仅仅依靠更大/更好的 LLM 无法解决这个问题。<p>- 只有 21 个 API 中的 6 个 API 始终有效，其他每个 API 都有失败的情况。<p>- Anthropic 的模型在构建 API 集成方面明显优于其他提供商。<p>以下是结果图表：<a href="https:&#x2F;&#x2F;superglue.ai&#x2F;files&#x2F;performance.png">https:&#x2F;&#x2F;superglue.ai&#x2F;files&#x2F;performance.png</a><p>导致 LLM 失败的原因：<p>- 缺乏上下文（LLM 并不擅长理解存在哪些 API 端点以及它们的作用，即使你向它们提供了文档，我们也这样做了）<p>- 多步骤工作流程（链接 API 调用）<p>- 复杂的 API 设计：像 Square、PostHog、Asana 这样的 API（强制选择项目等会使 LLM 崩溃）<p>我们已经开源了该基准测试，因此你可以测试任何 API 并查看其排名：<a href="https:&#x2F;&#x2F;github.com&#x2F;superglue-ai&#x2F;superglue&#x2F;tree&#x2F;main&#x2F;packages&#x2F;core&#x2F;eval&#x2F;api-ranking">https:&#x2F;&#x2F;github.com&#x2F;superglue-ai&#x2F;superglue&#x2F;tree&#x2F;main&#x2F;packages...</a><p>查看该存储库，考虑点个星，或在 <a href="https:&#x2F;&#x2F;superglue.ai&#x2F;api-ranking&#x2F;">https:&#x2F;&#x2F;superglue.ai&#x2F;api-ranking&#x2F;</a> 处查看完整排名。<p>如果你正在构建需要可靠 API 访问的 Agent，我们很乐意听取你的方法，或者你可以在 superglue.ai 尝试我们的集成层。<p>接下来：基准测试 MCP。

我使用 AI 助手已经有一段时间了，虽然我对它感到非常兴奋，但有时我也会感到非常沮丧。大型语言模型（LLM）会陷入无休止的循环。<p>这就是我开始尝试创建工作计划的时候。最初只是简单的待办事项列表，但感觉像是“产品调性”，所以后来变得更复杂了。我开始从中看到价值。<p>有一天我突然意识到。为什么不用同样的 GitOps 原则来管理产品工单呢？我开始尝试，并且非常喜欢它的工作方式。<p>在和朋友聊过后，我意识到一个标准或规范会非常有用。然后你就可以围绕它创建各种工具。<p>我从 Kubernetes 的 YAML 使用方式中获得灵感，因为我觉得它非常简洁。<p>你可以在这里查看示例：<a href="https:&#x2F;&#x2F;spec.productascode.org&#x2F;draft&#x2F;#sec-Epic-Example-YAML-" rel="nofollow">https:&#x2F;&#x2F;spec.productascode.org&#x2F;draft&#x2F;#sec-Epic-Example-YAML-</a><p>目前为止的关键设计决策：<p>1. YAML 优于 JSON：人类可读，对 git-diff 友好，拥有出色的工具生态系统 2. 层次结构：史诗 → 工单 → 任务（与开发工作流程匹配） 3. 原子工单：每个工单 = 一个分支 = 一个 PR（防止范围蔓延） 4. ISO 8601 时间戳/持续时间：机器可解析的时间数据<p>如果我设法创建了一个包含一堆待办工单的史诗，那么我最喜欢的工作就是告诉 Claude Code：“关闭当前工单，然后开始另一个。”<p>这是包含草案规范和 GitHub 存储库链接的帖子的链接。<p>目前正在开发 v0.1.0，我很想听听你的想法。<p><a href="https:&#x2F;&#x2F;mantcz.com&#x2F;blog&#x2F;introducing-product-as-code&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mantcz.com&#x2F;blog&#x2F;introducing-product-as-code&#x2F;</a>

大家好，我是 Arlan，我开发了 Nia (<a href="https:&#x2F;&#x2F;www.trynia.ai" rel="nofollow">https:&#x2F;&#x2F;www.trynia.ai</a>)，一个开放的 MCP，它与 Cursor、Continue 和 Cline 等编码助手集成，使它们能够比现有方法更好地检索外部知识。 编码助手可以很好地生成代码，但在答案超出它们面前的存储库时会失去准确性。开发人员最终需要手动粘贴 GitHub 链接、文档和博客文章，并希望助手滚动足够远。长上下文窗口有所帮助，但最近的“上下文腐败”测量结果表明，质量仍然会随着提示的增长而下降。例如，在 LongMemEval 中，所有模型在聚焦（短而相关）提示（约 300 个 token）上的得分都远高于完整（不相关，113k 个 token）提示，即使在最新模型中，性能差距依然存在 (<a href="https:&#x2F;&#x2F;research.trychroma.com&#x2F;context-rot" rel="nofollow">https:&#x2F;&#x2F;research.trychroma.com&#x2F;context-rot</a>)。 Nia 是一个 MCP，它为任何编码助手或 IDE 提供更多上下文。它索引多个存储库和文档站点，并通过 MCP 将其提供给您的编码助手，以便它有更多上下文可以使用，从而为您提供更具体和准确的答案。 Nia 使用混合代码搜索架构，将基于图的结构推理与基于向量的理解相结合。当摄取存储库或文档时，Tree-sitter 会将其解析为 50 多种语言和自然语言的 AST，并且代码会按函数/类的边界分块成稳定、内容可寻址的单元。这些块存储在图数据库中以模拟函数调用和类继承等关系，以及向量存储中。在查询时，一个带有 give_weight 工具的轻量级助手会根据意图动态分配图搜索和向量搜索之间的权重（例如，“谁调用 X”与“身份验证如何工作”），并且两条路径并行搜索。结果被融合，并用完整的代码上下文进行丰富，并通过多阶段重新排序器：语义重新排序器、交叉编码器、基于 LLM 的验证器。 早期信号：在内部评估中，一旦 Nia 索引了外部文档，Cursor 的性能提高了 27%，而这些文档是模型无法从其训练数据或网络搜索中获取的。 快速入门：&lt;<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=5019k3Bi8Wo" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=5019k3Bi8Wo</a>&gt; 演示：&lt;<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=Y-cLJ4N-GDQ" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=Y-cLJ4N-GDQ</a>&gt; 要试用它：在 <a href="https:&#x2F;&#x2F;app.trynia.ai&#x2F;" rel="nofollow">https:&#x2F;&#x2F;app.trynia.ai&#x2F;</a> 上获取 API 密钥，并按照 <a href="https:&#x2F;&#x2F;docs.trynia.ai&#x2F;integrations&#x2F;nia-mcp" rel="nofollow">https:&#x2F;&#x2F;docs.trynia.ai&#x2F;integrations&#x2F;nia-mcp</a> 上的说明进行操作。 试用并破坏它！我很想知道您的助手仍然错过了哪些上下文。边缘情况、延迟问题、扩展错误。我 24/7 在线。 谢谢！

大家好，HN，我们最近卖掉了之前的产品，目前正在开发新的想法。这次可能是我们发现的 AI 产品中最令人兴奋和被忽视的增长机会： TLDR：我们构建了一个用于分析和探索用户提示的工具——这样您就可以真正了解用户如何与您的 AI 产品交互，并比较不同细分市场（语言、付费与免费等）的行为。 如果您习惯使用 Mixpanel / Amplitude / PostHog 来分析用户行为，您可能会注意到当您的产品只是一个聊天框（或语音界面）时，它们变得多么不相关。那是因为在 AI 时代，您不需要按钮事件——您需要分析大量的文本语料库。 为了解决这个问题，我们构建了我们称之为 GenAI 应用的 Mixpanel——一个 NLP 工具，用于大规模分析和探索您的用户聊天记录。 我们已经可以做到： 1⃣ 多层语义聚类（查看所有主题的全貌并深入研究） 2⃣ 过滤器和分组（比较不同语言、人口统计、免费/付费等之间的使用情况） 3⃣ 潜在空间探索 4⃣ 提示的语义搜索 5⃣ 主题和代币使用情况细分 6⃣ （即将推出）随时间的趋势和受众漂移 因此，您可以回答以下问题： - 我的应用程序的主要用例是什么？ - 付费最多的用户做什么？ - 花费时间最多的用户做什么？ - 我错过了哪些安静的受众和用例？ - 不同语言的用户模式有何不同？ - 我们可以吸引哪些新受众？ 请查看链接以获取屏幕截图和开始使用的说明！ 欢迎任何反馈（如果负面，我不会说我不会哭）

市面上有很多商业的 YouTube 视频总结工具，但我找不到一个真正符合我需求的开源版本。因此，我构建了 YouTubeTLDR：一个简单、可自托管的解决方案，它使用 Gemini API，而且没有太多冗余功能。<p>我采用了同步方法 + 线程，这与 Tokio 形成了很好的对比。<p>它需要你自带 API 密钥，但每次请求都会将密钥发送到服务器，这可能是我未来需要修改的地方。<p>可以在 <a href="https://youtubetldr.onrender.com/" rel="nofollow">https://youtubetldr.onrender.com/</a> 上找到演示。