最新

嗨，HN！我是来自 Superglue 的 Stefan，今天我想分享一个我们刚刚开源的新基准测试：代理-API 基准测试，在这个测试中，我们评估大型语言模型（LLMs）处理 API 的能力。 我们给 LLMs 提供了 API 文档，并要求它们编写能够实际进行 API 调用的代码，比如“创建一个 Stripe 客户”或“发送一条 Slack 消息”。我们并不是在测试它们是否能够使用 SDK，而是在测试它们是否能够编写原始的 HTTP 请求（包含适当的认证、头信息和主体格式），并且这些请求在实际的 API 端点上执行时能够正常工作，并从响应中提取相关信息。 简而言之：LLMs 在编写使用 API 的代码方面表现不佳。 我们对 21 个常见 API（如 Stripe、Slack、GitHub 等）进行了 630 次集成测试，使用了 6 种不同的 LLM。以下是我们的主要发现： - 最佳通用 LLM：成功率为 68%。这意味着每 3 次 API 调用中就有 1 次失败，大多数人会认为这在生产环境中不可行。 - 我们的集成层成功率为 91%，这表明仅仅使用更大或更好的 LLM 并不能解决问题。 - 只有 6 个 API 在所有测试中始终成功，其他所有 API 都出现了失败。 - Anthropic 的模型在构建 API 集成方面显著优于其他提供商。 以下是结果图表： [https://superglue.ai/files/performance.png](https://superglue.ai/files/performance.png) 导致 LLMs 失败的原因： - 缺乏上下文（LLMs 在理解 API 端点的存在及其功能方面并不出色，即使我们提供了文档）。 - 多步骤工作流（链式 API 调用）。 - 复杂的 API 设计：像 Square、PostHog、Asana 这样的 API（在项目选择等方面的强制要求让 LLMs 感到困惑）。 我们已经开源了这个基准测试，您可以测试任何 API 并查看其排名：[https://github.com/superglue-ai/superglue/tree/main/packages/core/eval/api-ranking](https://github.com/superglue-ai/superglue/tree/main/packages/core/eval/api-ranking) 请查看这个代码库，考虑给它一个星标，或者查看完整排名：[https://superglue.ai/api-ranking/](https://superglue.ai/api-ranking/)。 如果您正在构建需要可靠 API 访问的代理，我们非常希望听到您的方法，或者您可以在 superglue.ai 尝试我们的集成层。 接下来：基准测试 MCP。

我与人工智能助手合作了一段时间，虽然我对此感到非常兴奋，但有时也会感到非常沮丧。大型语言模型（LLM）常常陷入无尽的循环中。 这时我开始尝试创建工作计划。最初是一个简单的待办事项列表，但感觉像是在“产品共鸣”，所以后来变得稍微复杂一些。我开始看到其中的价值。 有一天我突然想到，为什么不使用相同的GitOps原则来管理产品票据呢？我开始尝试这个方法，并非常喜欢它的运作方式。 与我的一个朋友聊天后，我意识到制定一个标准或规范会非常有用。这样就可以围绕这个标准创建各种工具。 我从Kubernetes的YAML使用方式中获得了灵感，因为我觉得它非常简洁。 你可以在这里查看示例： [https://spec.productascode.org/draft/#sec-Epic-Example-YAML-](https://spec.productascode.org/draft/#sec-Epic-Example-YAML-) 到目前为止的关键设计决策： 1. 使用YAML而非JSON：可读性强，适合git差异比较，工具生态系统优秀 2. 层级结构：史诗 → 票据 → 任务（与开发工作流程相匹配） 3. 原子票据：每个票据 = 一个分支 = 一个PR（防止范围蔓延） 4. ISO 8601时间戳/持续时间：机器可解析的时间数据 如果我能创建一个包含一堆待办票据的史诗，那么我工作中最喜欢的部分就是告诉Claude Code：“关闭当前票据，开始另一个”。 这里是包含草案规范和GitHub仓库链接的帖子链接。 目前正在开发v0.1.0，期待听到你的想法。 [https://mantcz.com/blog/introducing-product-as-code/](https://mantcz.com/blog/introducing-product-as-code/)

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

嗨，HN，我们最近出售了之前的产品，目前正在构建新的想法。这个可能是我们发现的最令人兴奋且被忽视的AI产品增长机会： 简而言之：我们开发了一款分析和探索用户提示的工具——这样您就可以真正理解用户如何与您的AI产品互动，并比较不同细分群体（语言、付费与免费等）的行为。 如果您习惯使用Mixpanel / Amplitude / PostHog来分析用户行为，您可能会注意到，当您的产品仅仅是一个聊天框（或语音界面）时，它们变得多么无关紧要。这是因为在AI时代，您不再需要按钮事件——您需要分析大量文本数据。 为了解决这个问题，我们开发了一个我们称之为GenAI应用的Mixpanel——一个用于大规模分析和探索用户聊天的自然语言处理工具。 我们已经可以做到： 1⃣ 多层语义聚类（查看所有主题的大局并深入分析） 2⃣ 过滤和分组（比较不同语言、人口统计、免费/付费等的使用情况） 3⃣ 潜在空间探索 4⃣ 提示的语义搜索 5⃣ 主题和标记使用情况分析 6⃣ （即将推出）随时间变化的趋势和受众漂移 这样您就可以回答以下问题： - 我应用的主要用例是什么？ - 支付最多的用户在做什么？ - 花费最多时间的用户在做什么？ - 我错过了哪些安静的受众和用例？ - 不同语言之间的用户模式有何不同？ - 我们可以吸引哪些新受众？ 请查看链接以获取截图和如何开始的说明！任何反馈都非常感谢（我不会说如果是负面的我不会哭）。

市面上有很多商业的YouTube摘要工具，但我找不到一个真正符合我需求的开源工具。因此，我开发了YouTubeTLDR：一个简单的、自托管的解决方案，使用Gemini API，且没有过多的冗余。 我采用了同步方法加上线程，这让我在使用Tokio时感到很轻松。 该工具是“自带密钥”，但每次请求时密钥会发送到服务器，这一点我可能在未来会进行修改。 可以在<a href="https://youtubetldr.onrender.com/" rel="nofollow">https://youtubetldr.onrender.com/</a>上查看演示。