Armature 将 MCP 会话转化为分析和分阶段评估
获得 YC 支持的创始人 Theodore Otzenberger 和 Louis Scremin 正在通过分阶段评估逐步推出,将 MCP 跟踪记录转化为用例、故障排名和回归测试。
By Ryan Merket · Published
Primary source: Armature
Why it matters
As customers delegate software tasks to AI agents, vendors lose visibility into intent and outcomes. Armature is linking production traces to regression tests before incumbents absorb the category.

Theodore Otzenberger (@Totzenberger) 和 Louis Scremin 在 7 月 22 日推出了 Armature,以向软件开发者展示当客户通过 Claude、ChatGPT 和其他 AI 客户端使用他们的产品时会发生什么。Armature 从 Model Context Protocol 服务器重建会话,按用户意图对其进行分组,并对中断最多工作流的失败进行排名。
两位创始人从同一生产鸿沟的相反两端来到这个问题。Otzenberger 曾在 Palantir 工作,之后在 Tsuga 构建可观测性基础设施。Scremin 在 Joko 领导 AI 自动化,据 Y Combinator 上的 Armature 资料 称,他曾帮助将 agents 和 MCP 服务器置于拥有 600 万用户的消费产品之前。YC 将 Armature 列为一个三人团队的 2026 年春季公司。
他们的创始论点扎根于 Scremin 在 Joko 遇到的一个运维问题:在内部测试中运行正常的 MCP 服务器,仍可能在数百万次不可预测请求中失败。Otzenberger 带来了将这些交互变成产品或工程团队可以检查的追踪背景。
Otzenberger 在一次启动线程中表述了这个问题:“You get the raw tool calls, never the user intent.”
这个区别正是 Armature 所追求的切入点。
From tool calls to product behavior
传统的产品分析监测由软件厂商控制的界面。诸如页面浏览、按钮点击和完成的漏斗等事件可以被关联在一起,因为交互发生在厂商的应用内部。
由 agent 中介的会话发生在别处。客户可能会要求 Claude 或 ChatGPT 创建发票、更新订阅或对账支付。软件提供方会收到对其工具的调用,但仅凭这些调用可能无法显示最初的请求、agent 的计划或最终结果是否达成了客户的目标。
Armature 的 发布公告 描述了三层:重建会话、聚类用例和分组问题。仪表盘可以重放工具调用和结果,然后 Armature 的模型对用户试图完成的任务进行分类,并识别循环、死胡同和不受支持的请求。即便每个底层 API 请求都返回 200 状态码,一个工作流也可能被标记为不成功。
该实现通过在现有 MCP 服务器周围添加 Armature SDK 来实现。Armature 当前记录了针对 TypeScript、Python、Go 和 PHP 的 SDK。其 遥测文档 表示 SDK 在每个被监测工具的输入模式中添加了一个可选的 telemetry 对象,包含用于用户意图、agent 报告的思考过程和感知到的用户挫败感的字段。同一文档还指出,忽略这些可选字段的 agent 仍会生成包含工具调用、时间和结果的会话。
这一警示很重要。Armature 并不是独立地从每个模型中提取完整的内部推理记录。某些更丰富的会话上下文依赖于调用 agent 向 Armature 添加到模式中的可选遥测字段提供数据。
Armature 的 遥测文档 还说明,启用分析的 SDK 会注册一个可选的 capability-request 工具,用于用户需要现有工具无法完成的情况。这些调用为产品团队提供了关于未满足需求的结构化视图,将失败的请求转化为可能的路线图输入。
Production evidence becomes regression tests
7 月 22 日的公告表示随后会推出一个测试产品。到了 8 月 3 日,Armature 的 评估文档 将评估描述为逐工作区的推出,并为每个工作区分别启用访问权限。
启用后,评估产品会使用定义好的用户目标,对部署中的 MCP 服务器运行一个真实的 agent。一个独立的评审模型会根据客户编写的标准对生成的追踪进行评分,产生从 0 到 5 的分数以及通过、部分通过或失败的结果,依据 Armature 的 评分文档。评估概述 表示运行可以手动启动、按计划启动或从持续集成流水线触发。
Armature 更明确的产品决定是将分析与测试连接起来。经常出现的生产用例可以变成评估用例。在真实会话中发现的失败可以变成回归测试,用以证明后续修复是否有效。Armature 表示客户在保存测试之前会审查生成的 prompt 和标准。
这就形成了跨越观察、优先级排序和验证的反馈循环。它也使 Armature 比单纯的会话重放仪表盘拥有更广的表面。分析产品识别外部控制的 agent 如何使用 MCP 服务器,而评估层则检查这些相同任务在发布后是否继续可用。
访问仍是分阶段的。Armature 的 文档 表示评估按工作区启用,如果某个账户看不到该功能,客户可以请求访问。免费工作区每月可获得 100 次已完成的运行,而调度功能在付费计划上开始提供。
A category built around the missing interface
Armature 将自己定位于诸如 PostHog、Amplitude 和 Mixpanel 这类产品分析产品与诸如 LangSmith 和 Langfuse 这类 agent 可观测性产品之间。Armature 的主张是,第一组衡量厂商拥有的界面内部的行为,而第二组通常面向厂商自己构建的 agent。Armature 则专注于通过 MCP 操作厂商产品的外部 agent。
这一差异给了 Otzenberger 和 Scremin 一个具体的切入点,尽管成熟的分析、可观测性和 MCP 基础设施供应商可能会添加重叠功能。Armature 的防守将取决于其会话重建和从生产到评估的工作流是否足够难以复现,以及产品团队是否将 agent 行为视为拥有独立预算的单独学科。
Armature 将这一学科称为 "Agent Experience",或 AX。这个标签颇具野心,涵盖了当 agent 处于软件与客户之间时有关转化、支持和留存的未来问题。首个产品更狭窄也更易于评估:告诉开发者人们让他们的 agent 做了什么,展示工具在哪些地方失败,并将代价高昂的失败转化为测试。
Armature 的 定价页面 列出每月前 1,000 个分析会话为免费,之后每额外 1,000 个会话收费 $50,免费计划保留期为七天。Armature 表示其系统在存储前会扫描会话中是否存在个人信息和秘密。其 遥测文档 表示参与者身份由在客户服务器上派生的 SHA-256 哈希表示,捕获的输入和结果预览各自限制为 8 KiB。
对 Otzenberger 和 Scremin 来说,时机基于一个简单的押注:在大多数软件团队学会如何衡量之前,MCP 服务器正成为面向客户的接触面。Armature 正在尝试在操作习惯、工具选择和类别界限仍在被书写之时,掌握那一层测量。