最新

去支付我的手机费（按月套餐）。 网站上的“支付”按钮无法使用，也没有任何明显的错误提示。 网站提供了一个聊天功能。 通过聊天机器人联系客服。 转到人工客服。 被要求重复我已经向机器人报告过的信息（他看不到完整的聊天记录吗？）。 被要求提供我的电子邮件地址和电话号码（而我已登录与该电子邮件地址和电话号码关联的帐户，为什么他看不到？）。 这对我来说是典型的在线支付服务体验，但在手机支付方面尤其糟糕。 为什么公司要花钱雇佣人工客服来提问客户已经向他们的机器人回答过的问题，或者这些问题本应从他们数据库中应该拥有的客户详细信息中自动填充？ 如果一个愚蠢的机器人什么有用的事情都做不了，比如完成支付，然后还要求客户两次输入相同的信息，那要它干什么？ 我在实体店也看到了这种情况。我住在乡下。这里有一家加油站/便利店连锁店。一天中的任何时候，收银台前都排着队，柜台后面有三个店员，但只有一个收银台是开着的。这是一种令人沮丧的客户体验。另外两个店员在摆弄热狗或其他东西。这家加油站真的卖这么多热狗来雇佣第三个店员吗？同时开放两个收银台来服务顾客难道不是更好吗？ 或者你去沃尔玛。收银员不知道怎么装袋。排在前面的顾客总是试图用无效/未激活/透支的信用卡付款，收银员并没有引导他们去客户服务台，而是花了5分钟尝试解决这个问题，同时刷了他们的破卡片好几次。他们最终拿出另一张卡支付了订单，与此同时，现在已经排了六个人了。 或者你去了商店，想在关门前5-10分钟买点东西，而员工已经锁上了门。这对我来说在疫情前从来都不是问题。以前企业都想做生意！ 在我这个脑子不太灵光的客服处理我的手机支付时，我写完了这整个帖子。

大家好，我是 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>