Claude 文本水印与欧盟 AI 法案：API 构建者需要核验什么

Vercel AI SDK 7 不只是版本升级。WorkflowAgent、Skills、MCP Apps、持久化运行和可观测性会改变 Agent 的状态归属与故障复盘方式。我的迁移原则是先明确工作流状态，再把供应商密钥放在网关后面，并在切换生产流量前验证恢复能力。

先说结论

• WorkflowAgent 负责编排，不等于模型路由。
• Skills 与 MCP Apps 提升复用，权限仍由应用控制。
• 持久化步骤必须幂等，并通过回放测试。
• 固定 SDK 版本，记录所有实验性能力。

图 1：发布页是 SDK 能力边界的主要证据。

迁移时真正改变的地方

普通聊天循环可以把状态藏在内存里，持久化工作流不行。每个工具步骤都要有稳定输入、有限重试，以及“副作用是否已经发生”的记录。先为旧循环保存夹具，再比较工具调用，而不是只比较最终文本。

图 2：把模型/API 访问与工作流编排分开。

SandBase 放在哪里

SandBase 可以为语言、图像、视频、Embedding 和第三方 API 提供统一网关，SDK 负责工作流状态。密钥只放服务端，每次运行都记录 request ID、供应商、模型、延迟与成本，迁移才有可核验依据。

图 3：网关集中处理凭证、路由与预算。

迁移清单

固定 SDK，保证持久化步骤幂等，测试暂停/恢复/重试，把审批和工具发现分开，并按成功工作流比较成本。代价是运维复杂度上升：恢复能力更强，但需要存储、回放和 schema 迁移。

来源：Vercel AI SDK 7、SandBase Docs。

我会先做的决定

第一步不是挑框架，而是划清副作用边界。模型响应可以重试，但付款、仓库写入、通知或数据导出不能按普通请求重试。给每个副作用分配幂等键，持久化审批结果，并让重试结果对操作者可见。

一次运行至少要记录 run ID、操作者、目标、模型与供应商、工具名、校验后的参数、审批状态、起止时间、用量字段和最终状态。原始载荷与可搜索索引分开，才有可能执行脱敏和保留策略。SandBase 网关的价值也在这里：语言、图像、视频、Embedding 和外部 API 可以共享请求身份，密钥不会进入浏览器代码。

值得主动模拟的失败

不要只测成功路径。模拟供应商在工具接受请求后超时、重复 webhook、错误参数、权限被撤销、流式响应中断，以及预算在运行中耗尽。每种情况都写清用户提示、告警、持久化状态和安全重试方式。如果这四个问题答不出来，就不适合扩大流量。

建议把同一个夹具回放两次。第二次要么得到相同的只读结果，要么明确拒绝重复副作用。比较 trace 和台账，而不只是最终文字。具体行为取决于供应商、SDK 版本、端点和部署配置；本文是设计清单，不是基准测试，也不宣称所有环境都支持同样能力。

什么时候应该选别的方案

需要恢复、调度和共享观测时，托管工作流很合适。没有副作用的一次性短请求，用小型自定义循环反而更简单。新功能刚发布而网关尚未暴露参数时，供应商原生 API 可能更合适。原则是选择能把失败模式说清楚的最小表面。

发布说明模板

记录来源日期、包版本、启用开关、支持端点、已知限制、回滚提交和一条示例 trace，再请第二位工程师按说明重建。这样可以避免把公告中存在、但实际路由未开启的能力写成确定事实。

最终清单

• 记录来源和检索日期。
• 第一节回答读者任务。
• 解释至少一个失败路径和一个取舍。
• 在截图附近说明它证明了什么。
• API key 只在服务端。
• 中文是原生改写，不是复制英文段落。