MCP Schema 变了，产品回归不能只看工具覆盖率

Apple Research 发布了 Agent Seer：只要提供一份模型上下文协议（MCP）工具规格，它就能在没有示例、无法调用真实工具、也没有领域微调的情况下生成评测场景。它会先补充理解工具 schema，再提出工作流、合成模拟结果，并把合适的案例扩展成多轮对话。

这正面解决了每个 AI app builder 迟早都会遇到的问题：连接器更新的速度，往往比人工维护回归测试更快。

但真正值得注意的结论，并不是“schema 已经可以替你认证 Agent”。它做不到，Agent Seer 自己的实验结果也说明了原因。作者在 7 份 MCP 规格上生成了 337 个场景、391 条评测记录，其中只有 54 个场景成功扩展为多轮案例。

由于原始规格没有提供示例输出，实验中的 871 次模拟调用全部被标为低 grounding。剩余的工具调用错误，最突出的也不是工具名选错，而是参数值不准确。

这给非技术创始人带来一个很现实的产品判断：schema 变更可以低成本地产生候选测试，但仍然需要有人确认这些测试是否代表真实的用户承诺、参数值是否获得授权、模拟行为是否符合真实服务，以及最终外部状态是否正确。

本文补上这层发布控制。你将得到一份六阶段的 schema 变更回归合同、变更到测试的映射矩阵、一个完整的日程 Agent 场景、可复用的 YAML manifest、失败演练，以及 ship / limit / hold 的决策规则。无论工具来自 MCP、其他函数调用格式，还是私有连接器目录，这套方法都能使用。

这不是数据库/API 迁移指南，也不是通用的 prompt 回归清单。迁移指南关心新旧生产者、消费者能否兼容；prompt 测试关心技术栈任意部分更新后行为是否变化。

本文只回答一个更窄的问题：当 Agent 实际看到的工具规格发生变化时，怎样把 diff 转成符合产品真值的案例，又不把“生成得像真的”误当成客户真相？ 如果同一次工具变更还破坏了线上协议或数据兼容性，两道门槛都要跑。

Agent Seer 真正增加了什么能力

下游评测器可以把任务交给 Agent，在它调用工具时返回模拟输出，再将最终轨迹与预期工作流比较。创建第一批案例时，不必真的连接日历、数据库、浏览器或代码仓库。

这会明显改变测试生产的成本。团队新增连接器时，不必再从空白表格起步。服务端增加、删除或修改工具后，可以先生成一批新的候选工作流，再让产品经理做审核。它还有机会发现工具之间不那么显眼的组合，而不是只把每个函数孤立地测一遍。

这项实验足够大，值得认真对待；边界也足够清楚，不能过度外推。7 份公开 MCP 规格覆盖 Illustrator、Selenium、Redis、Git、Elasticsearch、Slack 和文件系统领域。

作者报告平均工具调用质量为 0.911，中小规模规格实现了完整工具覆盖；复杂场景相较简单场景平均下降 7.3 个百分点。同时，作者明确说明这些只是 7 份规格和单一生成模型上的观察，不是普遍性能结论。

因此，真正可长期复用的想法是从规格启动测试生产，而不是让规格自动批准产品上线。

先区分四种经常都被叫作“测试”的东西

把 schema 变更接进发布流程前，先分清四种交付物：

• 生成场景：从规格推断出的用户目标、工具序列、参数和模拟响应路径。它是候选测试，不是已经成立的 ground truth。
• 产品案例：经过产品负责人确认，确实代表某项客户承诺、业务政策和后果的场景。它可以来自生成，也可以由人编写。
• 试次（trial）：在模型、prompt、工具目录、权限和环境全部固定的情况下，让候选版本执行某个产品案例一次。
• 结果收据（outcome receipt）：由独立证据证明，权威外部系统已经达到承诺状态，同时没有出现禁止的副作用。

Anthropic 当前的 Agent 评测指南也区分 task、trial、grader、transcript 和 outcome。文中的例子很直白：Agent 可以说“机票已经订好”，但真正的结果是数据库里是否存在那条预订。对产品团队来说，schema 生成测试降低的是编写成本；证明产品真值的仍然是结果核验。

Schema 描述数据形状，却不知道完整的客户承诺

当前 MCP tools specification中，一个工具可以包含名称、描述、inputSchema、可选 outputSchema、annotations 和执行元数据。输入与输出 schema 使用 JSON Schema。

服务端必须校验输入并实施访问控制；客户端则应在敏感操作前请求确认、向用户展示参数、验证工具结果、设置超时并记录调用日志。

这些规则都很重要，但合法的 schema 只能回答产品问题的一部分。它可以规定 start_time 是字符串、attendees 是数组、amount 是非负数，却不能天然证明：

• 时间采用了用户真正想要的时区；
• 每位参会者都适合、也允许收到邀请；
• 选中的账户属于当前租户；
• 退款金额等于订单当前可退余额；
• 已有批准仍覆盖变更后的参数；
• 上游服务只接受并执行了一次；
• 重试或延迟失败后，用户看到的结果仍然成立。

这正是 Agent Seer 最关键的失败信号。即便参数名与类型通常更准确，参数值仍是主要错误来源。在真实产品中，一个“看起来合理但实际错误”的值，往往比明显的解析失败更危险。customer_id: "cust_204" 完全是合法 JSON，也可能满足 schema；如果当前客户其实是 cust_240，它仍然不能接受。

所以，应把 schema 当作候选案例的生成面。产品政策、授权、真实服务语义和外部真值必须来自其他证据。

让每一个 schema diff 都产生测试义务

不要等到对方打上 major version 标签才行动。保存新旧工具目录，规范化内容，再按产品影响对每项差异分类。MCP Registry 的版本指南要求每次发布使用唯一版本字符串，并建议让 server、package 与远端 API 版本保持一致。

这有助于识别发布，但 semantic versioning 无法替你判断，YBuild 产品中的哪一项用户承诺被改变了。

可以用下面这张表，把变更编译成最低测试义务：

MCP 可以通知客户端工具列表已经变化，近期 roadmap 也记录了 discovery、Tasks、授权与结果类型的快速演进。但 notifications/tools/list_changed 只是缓存失效信号，不是产品质量判决。它应触发 refresh、diff、候选生成与审核，绝不能让新目录悄悄获得批准。

为每个 diff 分配稳定 ID，并保留旧规格。否则回归出现时，团队只知道“服务端变了”，却无法判断究竟是哪段描述、哪条约束或哪个结果字段改变了 Agent 的行为。

建立六阶段回归合同

发布合同应从便宜、覆盖面广的证据，逐步走向昂贵、贴近现实的证据。每一层都不能替代下一层要测的东西。

1. 固定并比较实际生效的目录

记录 server version、package 或 image digest、远端 API 版本、MCP protocol revision、tool-list hash、模型版本、Agent prompt、客户端政策和 evaluator 版本。比较 Agent 实际收到的目录，而不只是仓库里的源文件。缓存、feature flag、权限和租户配置都可能让“实际目录”与名义发布不同。

2. 生成候选场景

根据变化后的 schema 提出正常、边界、误用、恢复和多工具工作流。优先覆盖新增必填字段、含糊参数值、相邻工具和输出形状变化。Agent Seer 证明这个阶段可以在没有真实访问权限时启动，但每个案例都应标注 grounding level 和 generator version。

3. 执行产品真值否决

产品负责人或领域专家必须对每个案例作出接受、修改或拒绝决定。每个保留案例都要写明用户承诺、允许的 actor、权威数据源、禁止副作用、批准规则和预期最终状态。仅仅“看起来合理”的案例要拒绝。schema 推断不出的内容也要补齐：合同限制、租户边界、本地业务规则、无障碍要求、人工升级和延迟结果。

4. 运行确定性模拟

用受控模拟数据，让确切的候选版本执行案例。把“是否需要工具、选择、顺序、参数名、参数值、类型、格式和关联性”分开评分。验证禁止调用和状态变化，而不只测 happy path。

随机性试次要重复，完整 trace 要保存。跨调用的合成输出必须内部一致：第一次调用返回 evt_41，后续就必须继续操作 evt_41，不能又虚构一个对象。

5. 运行受限的真实影子测试

使用真实认证、延迟、错误形状、分页、服务限制和返回语义，但不允许产生面向客户的效果。读取可以使用预置数据的测试租户；写入应进入可丢弃 sandbox、使用非生产凭据，或在真正执行前被拦截。把真实响应与模拟假设比较，并记录规格遗漏了哪些行为。

6. 核验外部结果并决定开放范围

只要工作流包含写操作，执行后就应由独立组件查询权威系统。确认必需状态、禁止状态、重复次数、身份、时间戳和恢复状态。最后决定全面发布、限制试点、hold 或 rollback。发出命令的 Agent 不能同时成为唯一的成功证明。

这条证据链有意不对称：生成案例可以低成本进入；生产权限只有经过真值审核和外部核验后才能离开。

具体场景：日历工具新增 time_zone

假设 CedarMeet 是一个由三人团队构建的 AI 日程产品。它的 MCP server 最初暴露如下工具：

{
  "name": "create_meeting",
  "inputSchema": {
    "type": "object",
    "properties": {
      "start": {"type": "string"},
      "duration_minutes": {"type": "integer"},
      "attendee_emails": {"type": "array", "items": {"type": "string"}}
    },
    "required": ["start", "duration_minutes", "attendee_emails"]
  }
}

新版本增加必填项 time_zone、可选项 send_invites，并返回含 event_id、status 和 invite_delivery 的结构化结果。看起来只是一次干净的增强，实际上却引入了多种破坏客户承诺的方式。

场景生成器提出：“明天 9 点和 Mei 安排 30 分钟通话。”它选择 create_meeting，填写 time_zone: "Asia/Tokyo"，并设定 send_invites: true。轨迹逻辑顺畅，参数也完全满足 schema。

产品真值审核却必须否决原案。虽然用户时区已知，但通讯录中有两位 Mei；CedarMeet 的产品政策要求，在向外部人员发邀请前必须先澄清身份。“明天 9 点”还依赖用户 locale 和当前日期。schema 可以提出貌似合理的值，却无法推断 CedarMeet 的授权政策。

经过审核的测试集应至少包括 6 个案例：

1. 联系人唯一且时区明确：创建一个事件，只发送一次邀请。
2. 联系人有歧义：先提问，不调用任何写工具。
3. 用户没说时区，但 profile 数据可靠：批准前展示产品采用的时区解释。
4. 用户没说时区，且没有可靠数据：先问，不静默使用默认值。
5. server 已接受请求后发生 timeout：重试前用 idempotency key 查询结果。
6. status: "created" 但 invite_delivery: "failed"：如实显示部分成功，并提供受限恢复路径。

团队需要更新 parser，并把 unknown 加入产品状态。最后，结果核验要确认权威系统中恰好只有一个事件，UTC 时间与批准预览一致，参会者身份也正确。

创始人不需要亲自实现 benchmark framework 才能应用这个案例。创始人的职责，是把客户承诺、歧义政策、批准边界和最终证据说清楚；工程团队再把合同自动化。

使用这份可复用的回归 manifest

下面的 manifest 是 YBuild 提出的产品交付物，不是 Agent Seer 或 MCP 标准。它应该足够短，让产品、运营和工程可以一起审核。

mcp_change_regression:
  change_id: "calendar-mcp-2.4.0-to-2.5.0"
  owner: "product-reliability"
  effective_stack:
    server_version: "2.5.0"
    server_artifact_digest: "sha256:..."
    remote_api_version: "记录确切版本"
    protocol_revision: "2026-07-28"
    tool_catalog_hash_before: "sha256:..."
    tool_catalog_hash_after: "sha256:..."
    model_and_settings: "provider/model/version/settings"
    agent_prompt_version: "scheduler-17"
    client_policy_version: "writes-9"

  schema_diff:
    tools_changed: ["create_meeting"]
    required_added: ["time_zone"]
    optional_added: ["send_invites"]
    output_added: ["event_id", "status", "invite_delivery"]

  generated_candidates:
    generator: "name/version"
    generator_input_hash: "sha256:..."
    total: 24
    grounding: "spec-only"
    accepted_by_product_owner: 11
    edited: 8
    rejected: 5

  product_truth:
    user_promise: "按解释并获批的时间，只创建一次事件"
    authority_source: "用户批准，且批准绑定已预览参数"
    authoritative_system: "日历服务商的 event record"
    forbidden_effects: ["联系人错误", "静默默认时区", "重复事件"]

  gates:
    schema_validation: pass
    deterministic_simulation: pass
    repeated_trials: "每个关键案例 5 次"
    restricted_live_shadow: pass
    external_outcome_check: pass
    unresolved_argument_value_failures: 0

  decision:
    posture: "limited-pilot"
    eligible_tenants: ["internal-dogfood"]
    expires_at: "2026-09-05T00:00:00Z"
    rollback_to: "calendar-mcp-2.4.0"
    human_approver: "具名负责人"

不要拿估算值填补未知项，再让它看起来像权威事实。远端 API 版本缺失、最终状态未核验，都应该保留为 unknown，并可能阻断发布。也要记录生成案例被拒绝了多少；拒绝率可以反映 schema 完整性和生成器适配程度，不是浪费。

参数与外部效果的评分，要比工具名严格

Agent Seer 的失败分析，是不能把工具覆盖率当发布指标的最强理由。作者把工具调用拆成必要性、选择、顺序和参数，再把参数拆成 completeness、name、value、type、format 与 relevance。在主 judge 和跨模型家族 judge 下，参数值准确性都是最主要的子错误。

产品 dashboard 也应采用同样的分层思路：

OpenAI 官方的 trace grading 指南介绍了怎样对 Agent 的端到端轨迹做结构化评分，用来发现回归与定位失败。应使用这种可见性，但不能让 trace grader 代替状态查询。trace 证明走过的路径；服务商记录、数据库行、已送达消息或实际改动的文件，才证明产生的效果。

高后果参数应先使用确定性 assertion，再使用模型判断。精确的 tenant ID、currency、金额上限、时间转换、recipient、resource ID 和 approval hash，不应取决于 judge 是否觉得“看起来合理”。需要解释的质量，例如追问是否清楚、Agent 是否选择了权限过大的路径，可以交给模型 grader，但必须用人工样本做校准。

发布前运行八项失败演练

每一个发生变化、且具有写能力的工具，至少应通过以下演练：

1. 形状合法、身份错误： 换成另一个租户中 schema 合法的 resource ID，客户端或服务端必须在产生效果前拒绝。
2. 新增必填值缺失： 确认 Agent 会追问，或使用明确获授权的数据源，而不是发明默认值。
3. 只改描述却扩大权限： 把 wording 从 “draft” 改成 “send”，确认客户端政策仍要求正确批准。
4. 部分成功： 返回权威对象，同时让次要效果失败；产品必须呈现真实的部分状态。
5. 接受请求后 timeout： 隐藏首次响应，Agent 重试前必须通过幂等键或查询完成 reconciliation。
6. 输出字段缺失或为 null： 验证 parser 安全、降级可见，而且不会宣告虚假成功。
7. 会话中途工具列表漂移： 让缓存目录失效，确保旧参数不会被盲目发送给新工具。
8. mock 与 live 不一致： 让真实 sandbox 返回未记录的状态或分页路径；合同覆盖前不得发布。

哪些情况适合规格生成测试，哪些不适合

当工具 schema 描述相对完整、团队还没有初始测试集、工具目录频繁变化、真实调用昂贵或有风险，并且后续可以核验产品结果时，这套方法很合适。它特别适合扩大覆盖面：被忽略的工具、变化后的字段、多工具组合和边界候选。

如果含义主要存在于规格之外，它就不适合作为唯一 evaluator。描述稀疏、远端行为未文档化、动态授权、视觉界面、物理设备、长时间延迟结果、主观质量和跨组织政策，都需要其他证据。

Agent Seer 的实验没有调用真实工具，7 份规格也都没有示例输出，更缺少系统性的人类评测锚点。论文明确把 LLM 生成 ground truth 视为最重要的限制。

对多轮能力也要保持边界感。337 个生成场景中，只有 54 个扩展成多轮案例，而且明显集中在复杂场景。这是有用的研究证据，却不能证明自动生成的测试集覆盖了真实客户中的修复、中断、协商与恢复对话。

在 ship、limit、hold 与 rollback 之间做决定

使用四种发布姿态：

身份或授权失败绝不能被平均值抹掉。98% 的场景通过率，无法补偿一次跨租户写入。对禁止效果设置 hard gate，其余测试集只能作为辅助证据。

旧的有效目录和客户端行为也必须保留。2026 年 8 月的 MCP roadmap显示，protocol feature、discovery、Tasks、授权和结果类型仍在快速演进。如果 rollback 只恢复 server package，却保留新缓存、prompt、政策或远端 API，它就不是完整 rollback。

小团队可以执行的 48 小时计划

前 4 小时，分别导出生产环境与候选发布实际生效的工具目录。固定全部技术栈版本，规范化两份文件，生成 semantic diff，并标记所有具有写能力的工具。不要一上来就让模型生成测试，却没有保留确切输入。

到第 12 小时，为每个变化面生成候选案例，并标注 normal、boundary、misuse、recovery 或 multi-tool。由产品负责人逐项接受、修改或拒绝，并为所有保留的写案例补上客户承诺、批准来源、禁止效果和权威结果。

到第 24 小时，使用预置身份与状态运行确定性模拟。重复关键案例，检查参数值失败并比较完整轨迹。每个发现的歧义，都必须转成追问规则、确定性 resolver、更窄权限或发布 blocker。

到第 36 小时，在可丢弃租户中运行受限 live shadow。覆盖真实认证、错误、timeout、分页、输出分支和服务限制。mock 与真实集成不一致时，应更新 mock；绝不能反过来篡改真实观察，让它匹配方便的模拟。

到第 48 小时，核验外部结果，完成 manifest，选择发布姿态，指定 approver，为限制开放设定到期时间，并测试 rollback。上线后还要安排复审，把真实失败和支持案例纳入长期测试集。

创始人最终要做的判断

Agent Seer 的价值，在于把“测试集为空”这个问题缩小。变化后的 MCP specification 可以持续产出结构化候选场景，而不是只留下一句模糊的“请重新测试 Agent”。这对小团队是真实的效率提升。

但产品边界仍由人拥有。schema 不知道哪项客户承诺最重要、什么歧义必须追问、哪个值真正携带授权、哪条外部记录才算最终结果，也不知道哪种失败绝对不能接受。生成覆盖率只有经过产品审核、受控试次、真实语义检查和独立结果核验后，才能成为发布证据。

当它能加快回归工作的第一稿时，就采用这套方法；但不要把候选生成、ground truth、执行与产品批准压缩成一个绿色分数。最安全、也最实用的规则很简单：让 schema 变化自动提出问题；变化后的工具要先为答案提供证据，才能接触客户。

参考资料

1. Apple Machine Learning Research — Agent Seer
2. Agent Seer 论文 — arXiv:2608.26133
3. Model Context Protocol — Tools specification, 2026-07-28
4. Model Context Protocol Registry — Versioning published servers
5. Model Context Protocol — 2026 年 8 月 roadmap
6. JSON Schema — Draft 2020-12 release notes
7. Anthropic — Demystifying evals for AI agents
8. OpenAI — Trace grading
9. NIST — Artificial Intelligence Risk Management Framework 1.0