返回首页
一周热榜
每一页大部分都是侧边栏，每次加载页面时都必须点击“隐藏”才能显示被挤压在里面的文章内容（侧边栏的状态不会被保存！！）。在“全侧边栏开启”的默认设置下，甚至需要8K屏幕或30%的缩放才能看到文章内容。
好奇大家在忙些什么！接着我之前的帖子（https://news.ycombinator.com/item?id=48760048）：
1. 你为什么要辞职？
2. 你接下来会做什么？（即使什么都不做也可以！）
嗨，HN！我们是Theodore和Louis，Armature的创始人（YC P26）。我们重建了您收到的MCP工具调用背后的整个会话，包括用户要求其代理执行的操作以及代理的想法。
您只需用三行代码将您的MCP封装起来（我们的SDK支持Typescript、Python和Go），就可以在仪表板上看到：
- 所有重建的会话：就像阅读用户在Claude或ChatGPT中进行的真实对话！
- 您的MCP最受欢迎用例的排名，基于会话聚类构建
- 您的用户代理遇到的最常见问题，以便您进行修复。
这是一个快速演示：<a href="https://youtu.be/ZFlvquhyNMQ" rel="nofollow">https://youtu.be/ZFlvquhyNMQ</a>
这个故事的背景是，我们最初将Armature作为一个独立的测试工具推出（<a href="https://www.ycombinator.com/launches/QQc-armature-making-your-app-finally-usable-by-ai-agents">https://www.ycombinator.com/launches/QQc-armature-making-you...</a>），可以通过MCP本身自然使用。我们很快意识到，我们对用户如何使用Armature MCP以及他们是否满意或感到沮丧一无所知。这也是我们在之前的公司中经历过的事情：Louis构建的MCP面向数百万用户，而Theo在加入Datadog的分支公司之前是Palantir的前线工程师。测试和产品分析在将产品暴露给代理时一直是个真正的痛点，但我们总觉得在分析方面无能为力，因为对话发生在用户的AI客户端中。
然后我们突然想到：如果我们询问代理为什么会进行某个工具调用呢？用户的意图或潜在的沮丧又是什么？于是我们开始尝试MCP的仪器化，结果用例让我们感到惊讶！我们的许多首批客户为他们的CI实施了变通方案，以触发新测试，或者让他们的编码代理高效获取结果。尽管我们定期与首批用户交谈，但他们从未与我们分享过这些反馈。于是我们构建了自动化工具，自动聚类用例，识别常见问题，并让我们的编码代理进行修复。当我们的CTO朋友们听说这件事时，他们想亲自试试，于是我们给他们提供了我们内部产品的克隆版本，他们开始分享反馈，甚至比在我们“真实”产品上更积极！
这时我们决定认真开始将MCP分析作为一项产品。起初我们担心会降低MCP的性能，因此我们不断迭代，直到达到了与未进行仪器化时完全相同的成功率（89.17% vs 89.15%，共870次运行）。然后，隐私显然是一个约束，因此我们应用了从处理银行数据或构建敏感数据日志扫描中学到的方法。如今，数据脱敏在客户端运行，才会传输到我们的服务器。我们仍然有很多事情没有完全弄清楚：并非所有模型对所有字段的填充程度相同，无状态/无服务器的MCP会话指纹识别并不完美，而用例聚类仍需优化。
但我们终于向所有人推出了我们的分析产品，您可以在<a href="https://armature.tech">https://armature.tech</a>上自助使用，设置时间不到5分钟，并提供慷慨的免费套餐。
现在，我们正在努力全面闭环，将评估功能带回我们的产品，以便我们可以：识别顶级工作流程和问题 -> 推荐修复和改进 -> 在用户运行的相同工作流程上大规模测试修复，跨所有工具和模型 -> 开放PR以直接发布修复。评估可以从会话分析中自动生成，因此您可以捕捉每一个回归，并在发布之前测试每个改进在所有模型和工具上的实际影响。
这里有一个更具体的例子：10天前，一个早期访问我们构建的营销自动化平台通过MCP分析发现用户对在创建活动后无法更改目标受众感到沮丧。因此，他们发布了该功能，并在Fable 5的Claude Code上成功进行了本地测试。几天后，在准备新的MCP公开发布时，他们在Armature上运行了一系列评估，意识到小模型可能会产生虚假观众ID，这将导致他们的MCP默认将活动发送给所有联系人（这显然可能在生产中导致灾难）。这就是让我们所构建的产品感觉如此有帮助的故事！
现在，对我们来说，最有用的反馈是了解我们产品中仍然缺少什么，以便您能感受到自己完全掌控“代理体验”。如果您在生产中运行MCP，我们也希望知道：您今天是如何判断代理是否成功，以及背后的用户是否满意的？
我开发了Spltty，这是一个用于跟踪共享开支、自定义分摊和结算的Ruby命令行工具，使用普通的Markdown文件。本文解释了它是如何从一个由Claude管理的文件夹演变为一个命令行工具的。
正如在我之前的“谁在辞职？”帖子中的评论所建议的那样（https://news.ycombinator.com/item?id=48765213），我想尝试一下“谁在裁员？”的帖子 :)
我正在发布Lunar，一个全新的Lua 5.1编译器和虚拟机，完全用Go语言编写。它包括标准库、协程，并支持Lua 5.2风格的goto。
嵌入API避免了Lua C API基于栈的接口，转而采用类型化的Go值和回调框架。库和脚本文件的访问是可选的，因此宿主可以明确控制Lua代码的访问权限。
根据我目前的基准测试和使用案例，Lunar的速度通常比GopherLua和Shopify的go-lua快约1.5到2倍。然而，它最大的改进在于内存使用：加载一个9 MB的CBOR派生对象图（数十万个表）时，分配约107 MB，而使用GopherLua时则为785 MB，垃圾回收后保留的内存大约为72 MiB，而GopherLua则为542 MiB。
公共API仍在稳定中，我特别希望能收到关于嵌入设计和Go接口的反馈。
（请注意，这个项目最初是在另一个仓库中启动的，当时我仍希望将我的一些更改移植回现有的其他库。）