在 Rider 中使用 TeamCity CLI 与 MCP 调试 Unity 构建

在 GameDev Day 2026 上，TeamCity 解决方案工程师 Artem Rokhin 演示了如何使用 TeamCity CLI 和 MCP 集成，从 Rider 中调查一个 CI 问题。

在演示中，他使用了一个 Unity 游戏：该游戏在本地运行正常，但部署到预发布环境后缺少背景。尽管构建已经通过，Artem 还是用 CLI 检查了日志，并发现了一个错误的构建参数。

提交修复后，他让一个通过 MCP 连接的 AI 代理解释该问题，并跟踪新的构建。

下面我们逐步讲解这个示例，包括你可以用来在自己的项目中尝试的命令和设置。

预发布环境中的问题

在 Artem 的演示中，一个 Unity 游戏在本地运行正常，但在预发布环境中缺少月球景观，尽管 TeamCity 构建已成功。他沿着部署回溯到对应的构建，并检查日志和配置，以找出它们与本地设置的不同之处。

你需要什么

要将此工作流应用到自己的项目，你需要：

• 在 Rider 中打开的 Unity 项目。
• 一个会构建并部署该项目的 TeamCity 流水线，且其 YAML 设置存储在仓库中。
• 对该流水线构建详情和日志的访问权限。
• 在你的机器上安装 TeamCity CLI。
• 对于 AI 部分，需要在 Rider 中启用一个支持 MCP 的代理，并能访问 TeamCity 的 MCP 端点。Artem 使用的是 Claude Agent。

录像使用的是 TeamCity Cloud。TeamCity On-Premises 用户可以将 2026.2 作为基线，并使用正式可用的 Pipelines。有关设置和版本详情，请参阅 Pipelines 文档。

下面的命令使用示例 ID。将 MyGame_BuildWebGL 替换为你的 WebGL 作业 ID，将 12345 替换为你正在调查的构建，并在进行到该步骤时，将 12346 替换为新的部署运行。

从 Rider 连接 TeamCity CLI

打开 Rider 的终端，如果尚未安装 TeamCity CLI，请安装。在 macOS 上使用 Homebrew：

brew install jetbrains/utils/teamcity

在 Windows 上使用 WinGet：

winget install JetBrains.TeamCityCLI

其他安装方法请参阅 入门指南。

连接到你的服务器并检查连接：

teamcity auth login --server https://example.teamcity.com
teamcity auth status

将 URL 替换为你自己的 TeamCity 地址。按照登录流程操作，这可能会打开浏览器进行授权。身份验证文档介绍了可用的方法。

连接后，返回 Rider 的终端来检查构建。

找到生成该游戏的构建

列出 WebGL 作业的最近运行：

teamcity run list --job MyGame_BuildWebGL --limit 5

选择生成预发布环境中版本的运行。搜索时要包含成功的运行：在这个示例中，相关构建是通过状态。

如果最近完成了多次运行，请在调查前检查部署的源构建和修订版本。最新的 WebGL 构建可能比你在浏览器中打开的版本更新。

检查选中的运行：

teamcity run view 12345

在录像中，Artem 从流水线运行开始，找到其中的 WebGL 作业，然后打开该作业的构建详情。当你已经知道是哪个作业生成了游戏时，直接查看该 WebGL 作业的最近运行是一条更短的路径。

检查日志和配置

读取 WebGL 构建日志：

teamcity run log 12345

默认日志查看器支持搜索。按 /，输入搜索词，并使用 n 或 N 在匹配项之间移动。完整命令详情可在管理运行指南中找到。

Artem 最近一直在处理构建变体，因此他搜索了 flavor。日志显示该构建使用了 gameBuildFlavor，值为 diagnostic。

这提供了一个可调查的具体设置。在检出的项目中搜索 gameBuildFlavor，包括流水线配置和使用它的 Unity 构建代码。

日志中打印的值告诉你 CI 构建实际收到的内容；仓库可帮助你追踪它来自哪里以及它控制什么。

在这个演示项目中，预期的变体是 game。diagnostic 值与缺少背景的版本相关。这些名称是该示例项目构建设置的一部分；你的项目可能使用不同的参数，或者根本没有变体开关。

当你沿着类似线索调查时，既要检查定义，也要检查使用该值的代码。发现意外参数是有用的证据。理解它对构建的影响，可以让你判断更改它是否能消除该症状。

提交配置更改

Artem 在流水线的 YAML 配置中找到了 diagnostic 值，并将其改为 game。由于配置与游戏代码放在一起，他可以从 Rider 中审查并提交更改。

TeamCity 已配置为监视仓库，因此推送该提交会启动新的流水线运行。在此设置中，你不需要手动重启旧构建。

对于你自己的流水线，请检查其触发器设置，并确认新运行包含该配置提交。保留原始运行 ID，以便之后比较设置和结果。

在新流水线运行期间，Artem 展示了从 Rider 调查 CI 结果的另一种方式：通过 MCP 连接到 TeamCity 的 AI 代理。

将 Rider 连接到 TeamCity MCP

MCP 让代理能够访问 TeamCity 工具，包括检索构建日志和查询构建信息的工具。服务器端点为：

https://example.teamcity.com/app/mcp

对于这次调查，请创建一个作用域限制在相关项目的 TeamCity 访问令牌，并使用 Read-only（只读）预设。这样就足以在你通过 Git 进行配置更改时检查 CI 结果。有关令牌权限和连接选项，请参阅 TeamCity 的 AI 集成文档。

在 Rider 中，转到 Settings | Tools | AI Assistant | Model Context Protocol (MCP)，并添加一个 HTTP 连接。有效的连接配置应如下所示：

{
  "mcpServers": {
    "TeamCity": {
      "url": "https://example.teamcity.com/app/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_TEAMCITY_TOKEN"
      }
    }
  }
}

在你私有的本地配置中替换服务器地址和令牌占位符。不要将令牌放入你提交或共享的文件中。应用配置并确认 Rider 可以连接。我们的 AI Assistant MCP 指南介绍了连接设置。

如果你使用 Claude Agent，还要打开 Settings | Tools | AI Assistant | Agents 并启用 Pass custom MCP servers。然后在 AI 聊天中选择 Claude Agent。这样会将已配置的连接提供给代理，如 Claude Agent 文档所述。

让代理调查症状

将症状告诉代理，并指明构建。对于类似的调查，你可以调整以下提示：

使用 TeamCity MCP 检查 PROJECT_ID 中的 WebGL 构建 BUILD_ID。该游戏在本地构建时有背景，但部署到预发布环境的版本缺少背景。CI 构建成功。检查构建详情和日志，然后将相关设置与项目文件进行比较。解释可能的原因，并引用支持你解释的构建 ID、日志条目和文件。暂时不要更改任何内容。

发送提示前替换 ID。如果代理需要帮助定位相关流水线 YAML 和 Unity 构建脚本，请附上它们。TeamCity MCP 提供 CI 信息；编码代理使用其 IDE 和文件工具检查本地项目。

在录像中，Claude 识别出 diagnostic 构建变体，并将其与意外的游戏行为联系起来。它还注意到修复已经提交。演示的这一部分发生在 Artem 进行 CLI 调查和手动修复之后，因此回复可以引用该已有更改。

检查答案中的证据。它是否指向你询问的那次运行？参数值是否与日志一致？解释是否符合使用该值的代码？这些检查有助于你在更改其他流水线或项目之前评估所提出的原因。

跟踪新的部署

随后，Artem 让代理检查新流水线，并在部署完成时返回预发布环境 URL。代理会在活动会话期间查询 TeamCity 并报告进度。

后续提示可以是：

检查 PROJECT_ID 中针对配置修复的流水线运行。报告 WebGL 构建和部署是否已完成。当部署成功时，从部署日志中获取预发布环境 URL。如果运行仍在进行中，请报告其当前状态。

如需持续获取终端更新，你也可以用 CLI 监视部署运行：

teamcity run watch 12346 --logs

这里，12346 表示新部署构建的 ID。请使用你自己流水线中的 ID。完成后，如果需要获取 URL，请检查其日志：

teamcity run log 12346

验证已部署的游戏

打开预发布环境 URL，并重复暴露问题的交互操作。在 Artem 的演示中，月球景观再次可见，玩家可以像预期那样在其周围驾驶。

这项检查确认配置更改解决了观察到的问题。之前的运行已经通过，因此仅凭又一次成功的流水线结果，并不能证明背景已经恢复。

对于你自己的项目，还要确认你查看的是新运行产生的部署。然后将结果与行为正确的本地版本进行比较。

让下一次调查更轻松

这个示例给出了几项有用的流水线改进建议：

• 记录所选构建变体以及其他会改变游戏输出的设置，以便轻松找到它们。
• 在项目的构建脚本中校验预发布环境构建允许的变体，并确保当值不符合预期时运行尽早失败。
• 为这里出错的行为添加检查。具体取决于项目，可以是加载相关场景的 WebGL 冒烟测试，也可以是对已部署游戏的视觉检查。

从本可以捕获这个特定问题的缺失检查开始。这会为你提供一种改进流水线的具体方式，以及一种在 Rider 中调查其结果的、可重复的方法。