Claude Code Artifacts 现在以查看者凭据调用 MCP Connector：operator 必须了解的认证模型变化

Claude Code 的 Artifacts 功能在 Week 25（六月）上线时，发布模型相当简单：Claude 从会话上下文构建页面，发布到私有 URL。实用，但分享后是静态快照。

Week 29（7 月 13–17 日，v2.1.207）用一个架构倒置改变了这一切：已发布的 artifact 现在可以在查看者打开页面时调用 MCP connector，使用的是查看者自己的连接，而不是创建者的。

这不仅仅是功能迭代。它将凭据归属模型转移到一个新方向，每个通过 AI 网关运行 Claude Code 或在规模化场景部署 Claude Code 的团队，都需要明确地对此进行推理。

发生了什么

Week 29 发布为 Claude Code Artifacts 添加了 MCP connector 支持。当创建者构建一个引用 connector 的 artifact——例如"构建一个通过我的 GitHub connector 拉取当前 open pull request 的仪表盘"——生成的页面会在每次查看者打开时调用 MCP server。使用的是查看者自己的凭据，而非创建者的。查看者在第一次 connector 调用前会看到访问确认提示。

同一版本还新增了公开分享链接（此前仅限组织范围内）、Team 和 Enterprise 上的编辑协作角色，以及从 Claude Tag 会话创建 artifact 的能力。

对 AI 工程团队的影响

凭据作用域发生改变。 此前，artifact 中的任何实时数据都需要创建者嵌入快照。现在，artifact 的数据新鲜度取决于查看者的 connector 授权状态，而不是创建者的。这是一个重要的 governance 差异：失去 GitHub 组织访问权限的团队成员会看到空仪表盘；而拥有更广泛访问权限的成员可能看到创建者本无意暴露的数据。

MCP connector 的权限管理变成了 artifact 关注点。 当 Artifacts 还是静态快照时，MCP connector 配置是每个开发者作用域的问题，限定于他们的 Claude Code 会话。一旦 Artifacts 支持查看者作用域的 connector 调用，问题就变成了：哪些 connector 在什么作用域下对哪些查看者开放，遵循什么认证策略？使用 SSO 强制 MCP connector 配置的团队需要审计其 connector 授权模型是否能妥善处理这个新的访问面。

共享内部工具从"链接文档"转变为"链接实时工具"。 构建 PR 仪表盘、事件时间线或部署状态页面的 Claude Code 会话，现在可以将其发布为一个 URL，对任何打开它的人都保持实时更新——不需要任何后端基础设施。对于通过 AI 网关运行 Claude Code 的团队而言，这意味着 agent 输出不再只是对话记录：它可以成为一个持久的、具备操作能力的内部工具页面。

"查看者批准访问"是按 connector 按查看者触发的。 确认提示在查看者首次加载时触发。如果你的组织有零信任网络策略或严格的 connector 范围限制，请验证审批流程是否与你的 IdP 无缝集成，以及通过审批获得的 connector token 是否可审计。

Router/operator 视角分析

对于通过 AI 网关或自定义 base URL 路由 Claude Code 的团队，artifact MCP connector 功能带来了两个新的运维问题：

1. 你的网关需要支持哪种连接拓扑？ Artifact 从查看者的浏览器上下文调用 connector，而不是从 Claude Code CLI 会话。如果你的 AI 网关位于 Claude Code 和模型提供商之间，它不在 artifact 到 MCP server 的调用路径中。从 Artifact 发起的 MCP connector 调用，直接从查看者的浏览器连接到 connector server（或者，根据 connector 的配置方式，通过 claude.ai 的 connector 代理）。确认你现有的 MCP server 基础设施是否支持来自 Artifacts 的 connector 调用，而不只是 CLI 会话的调用。

2. 在外部分享 Artifacts 之前，审计 connector 作用域。 公开分享链接（Week 29 新增）意味着带有 connector 支持仪表盘的 artifact 可以被任何拥有链接的人打开——不仅限于组织成员。如果为公开链接 artifact 提供支持的 connector 具有较宽的读写权限，查看者确认提示是公共网络与你的连接数据源之间唯一的访问门控。检查 connector 权限范围，考虑将公开链接 Artifacts 限制为只读或不含 connector 的使用场景。

本周的行动清单：

• 审计现有 MCP connector 配置的权限范围：哪些 scope 已启用，谁可以通过查看者批准流程获得访问权限，这些 scope 是否适合 artifact 分享场景。
• 确认你的 connector server（GitHub、Linear、Notion 等）是否配置为接受通过 claude.ai connector 代理颁发的 OAuth token 授权。
• 如果在受监管环境中使用 Claude Code，检查查看者作用域的 connector 调用是否会记录在你的审计日志中。来自 Artifact 的 MCP connector 调用可能以不同于 CLI 发起的调用的会话元数据出现。
• 对于运行 AI 网关的团队：注意网关不在 artifact 到 MCP 的调用路径中。你的网关使用日志不会捕获 artifact connector 活动——你需要 connector server 侧的日志来获得这种可见性。

TheRouter 用户可以关注和尝试什么

Claude Code Artifacts 适用于 Pro、Max、Team 和 Enterprise 计划。MCP connector 功能需要通过 /login 进行身份验证的会话。如果你的团队通过 TheRouter 网关路由 Claude Code，你的会话配置（base URL、API key 作用域）继续管理会话的模型调用——artifact MCP connector 调用是独立的，且以查看者作用域运行。

实际可以尝试的操作：构建一个引用团队已配置 connector（GitHub、Linear 或自定义 MCP server）的 artifact，在组织范围内发布，并验证团队成员能否打开它、批准 connector 访问、看到实时数据。如果批准失败或出现 connector 认证错误，问题在于 connector 的 OAuth 配置，而不是 Claude Code 会话或你的 AI 网关。

后续关注：查看 Claude Code 发布说明 中 connector 权限控制和审计日志集成的进展，这两者是这一功能的自然延伸。