TeamCity 2026.2 的官方发布说明确认新增了 3 类 Pipeline MCP 工具，并记录了 130 个安全问题修复项。这说明 MCP 已经值得进入企业试点，但不代表可以直接接管生产发布线。你的本周动作应是：先开安全模式、项目级身份和只读排障；暂不开 Brave Mode，也不让通用 AI Agent 直接修改生产 Pipeline 或控制签名 Mac。(TeamCity 2026.2 发布说明)

01

本周上线建议

能力阶段 推荐结论 上线边界
只读诊断 ✅ 可进入第一阶段 查看日志、项目、构建状态；只授予必要读取权限
受控触发 ✅ 可小范围试点 仅触发个人构建或测试构建，限制参数和项目
配置写入 ⚠️ 暂缓默认放量 只开放测试项目，必须有差异、审批和回滚记录
项目删除 ❌ 不进入常规 Agent 权限 由人工管理员执行，禁止通用 Agent 获得删除能力

这篇文章适合三类人：计划把 Claude Code、Codex、Cursor 等外部 Agent 接入 TeamCity 的研发效能负责人；需要审查 MCP 身份、权限继承和审计证据的企业安全负责人；管理 Xcode 构建池、签名节点及远程 Mac 容量的平台工程团队。

02

TeamCity 2026.2 MCP 的能力边界

TeamCity 2026.2 的 MCP 服务提供构建日志读取、REST GET、受控 REST POST，以及 Pipeline 读取、创建、更新和删除等工具。官方文档明确说明，teamcity_pipeline_post、teamcity_pipeline_delete 和部分 teamcity_rest_post 能力会受到 Brave Mode 限制。(TeamCity MCP 集成文档)

因此，企业验收不能只验证“Agent 能否连接”。你至少要区分下面四层权限：

  • MCP 控制面权限：Agent 能看到哪些工具，是否能调用写入工具。
  • TeamCity 项目权限：令牌能查看、触发、修改或删除哪些项目。
  • Build Agent 运行权限：构建任务能否使用某个 Agent Pool，是否能访问节点日志和机器操作。
  • macOS 本地账号权限：构建进程能否读取文件、访问证书、使用 Keychain 或登录远程桌面。

最容易出现的误判，是把第一层和第四层混在一起。MCP 有权限调用 TeamCity，不等于它应该拥有生产 Mac 的 SSH、VNC 或本地管理员权限。

TeamCity 的项目权限可以按项目授予，并会从父项目传播到子项目。如果父项目权限配置过宽，Agent 的可见范围可能随继承扩大。(TeamCity 角色与权限说明)

⚠️ 经验提醒：先导出角色权限，再创建 MCP 身份。不要先接入 Agent，出问题后才反查它到底继承了哪些权限。

03

平台工程负责连接与工具验收

平台工程团队的责任，不是证明 MCP 能运行，而是证明它只能运行在预期范围内。

版本与复核窗口

TeamCity 2026.2 的正式构建日期为 2026 年 9 月 2 日。发布后仍应关注 2026.2.x 修复版本和安全公告；主要版本之后的修复版本可能继续改变兼容性或安全边界。

建议在验收单中记录：

  1. TeamCity Server 的完整版本和构建号。
  2. MCP endpoint 是否为预期的 /app/mcp。
  3. 外部 Agent 客户端的版本、配置位置和网络出口。
  4. 试点项目、测试分支和负责人。
  5. 安全模式与 Brave Mode 的当前值。
  6. 发生异常时由谁撤销令牌、关闭会话和停止构建。

不要把第三方客户端“能显示工具列表”当成兼容性结论。官方文档列出的连接方式不代表你的企业代理、单点登录、出口策略和客户端实现一定没有差异，必须在隔离环境逐项实测。

工具范围

第一阶段建议只保留：

  • teamcity_build_log：用于失败构建排障。
  • teamcity_rest_get：用于项目、构建配置和状态查询。
  • 安全模式下的受控触发能力：只针对测试构建，并确认参数范围。

Pipeline 创建、更新和删除工具不要在第一阶段注册给通用 Agent。特别是删除工具，官方说明显示它可以永久移除 Pipeline 及其父项目，风险远高于普通日志读取。(TeamCity MCP 工具说明)

04

安全团队负责身份与最小授权

OAuth PKCE 适合需要交互式授权的外部客户端。连接时，Agent 客户端会打开授权页面，由用户确认权限后取得访问令牌。该令牌继承发起授权用户的 TeamCity 权限，所以授权人如果是管理员，Agent 也可能获得过大的可见范围。

企业环境建议将几种接入方式分开管理：

  • OAuth PKCE：适合个人排障、短时试点和需要人工确认的桌面客户端。
  • 项目级受限令牌：适合自动化服务、固定 Agent 和长期运行的 CI 集成。
  • 管理员全局令牌：不应作为通用 AI Agent 的默认凭证。

TeamCity 的访问令牌可以选择与当前用户相同的权限，也可以限制到指定项目和权限范围。(TeamCity 访问令牌文档)

你需要为每个 MCP 身份建立一份责任记录：

  • 专用用户名称及所属团队。
  • 令牌创建人和业务用途。
  • 可访问的顶层项目与子项目。
  • 允许的权限 ID。
  • 过期时间或定期轮换日期。
  • 密钥存放位置。
  • 撤销责任人和替补责任人。
  • 最近一次实际访问测试结果。

权限验收不能停留在角色导出。至少要用实际令牌执行以下访问测试：

  1. 读取允许项目的构建列表。
  2. 读取未授权项目的构建列表。
  3. 获取允许范围内的构建日志。
  4. 尝试读取未授权项目的日志。
  5. 触发一个测试构建。
  6. 尝试修改 Pipeline。
  7. 尝试删除测试 Pipeline，并确认该能力被阻断。

TeamCity 的 REST 权限模型支持判断权限是否为全局权限，或是否能限制到项目范围。你可以用权限导出结果和实际请求返回值，检查“配置上看似受限、实际仍可访问”的差异。(TeamCity REST 权限文档)

05

项目负责人负责写入与回滚

项目负责人要单独验收“读取”和“改变状态”这两类行为。一个 Agent 能读取 Pipeline，并不意味着它适合修改 Pipeline；一个 Agent 能触发测试构建，也不意味着它可以改变生产分支的构建参数。

流水线写入验收

建议按下面的动作顺序执行：

  1. 创建一个没有生产凭证的沙盒项目。
  2. 将测试 Pipeline 配置保存在版本库。
  3. 让 Agent 读取当前 YAML 或 Kotlin DSL。
  4. 提交一个可预期的小改动。
  5. 对比变更前后的配置差异。
  6. 要求人工审批后才允许写入。
  7. 触发测试构建，确认新配置实际生效。
  8. 回滚版本库配置，再核对 TeamCity 中的最终状态。

TeamCity 官方文档指出，Pipeline MCP 能够读取属性、参数、VCS 根和仓库等内容，也能创建、更新及验证 YAML 或 Kotlin DSL。对企业来说，这些能力的价值在于减少人工排障，但风险在于配置写入可能改变后续构建行为。

优点：

  • ✅ 可以让 Agent 自动整理失败原因并提出配置差异。
  • ✅ 可以在沙盒项目快速验证 Pipeline 语法。
  • ✅ 可以把配置变更和版本历史绑定。

缺点：

  • ❌ Agent 可能把“修复建议”直接变成配置写入。
  • ❌ 父项目继承可能扩大变更影响面。
  • ❌ 只看 UI 成功提示，无法证明生产分支没有被改变。

生产项目至少要保留变更前后差异、审批人、调用身份、触发构建和回滚结果。若配置存放在版本库，还要把提交记录与 TeamCity 审计记录关联起来。

06

Mac 平台团队负责签名节点隔离

AI Agent 触发 iOS 构建时，真正需要保护的不是 MCP endpoint，而是下游 Mac 上的源代码、证书、描述文件、构建产物和 Keychain。

TeamCity Agent 与服务器之间可能传输构建设置、仓库访问凭证、源代码、构建产物、进度消息和构建日志。官方 Agent 文档明确列出了这些数据类型，因此生产签名节点不应与不可信验证任务混用。(TeamCity Agent 通信说明)

推荐将 Agent Pool 至少拆成三类：

  • 诊断池：运行日志分析、失败复现和不含签名的检查。
  • 验证池：运行测试分支和非可信代码，禁止读取生产签名凭证。
  • 签名池：只接受审核后的固定流水线，绑定生产证书和发布权限。

TeamCity 的 Agent Pool 可以把特定 Agent 绑定到指定项目，项目只能使用已分配的池。一个 Agent 只能属于一个池，而一个项目可以使用多个池。(TeamCity Agent Pool 配置文档)

在 Mac 节点上，你还要分别检查：

  1. TeamCity Agent 使用的 macOS 本地账号。
  2. 该账号能读写哪些工作目录。
  3. Xcode、证书和描述文件的存放路径。
  4. Keychain 是否允许无人工确认访问。
  5. SSH、VNC 和网页控制台是否对该账号开放。
  6. 构建脚本是否能改变 Agent 服务配置。
  7. 节点重启后是否会自动恢复到正确的 Agent Pool。

普通诊断任务不应路由到签名池。非可信分支也不应共享生产 Keychain。平台团队可以先阅读 远程 Mac 的基础设施说明，再用一台隔离主机验证 TeamCity Agent 注册、任务路由和 Xcode 项目构建。

07

审计团队负责观察与止损

TeamCity 的审计日志可以记录项目或构建配置修改、角色分配、用户组变化以及删除动作。配置发生变化时，还可以查看对应差异；默认情况下，非必要审计记录的清理周期为 365 天，具体行为取决于服务器清理配置。(TeamCity 用户操作追踪文档)

审计团队应重点观察四类异常：

  • 短时间内重复触发大量构建。
  • 高频 REST 请求或连续失败请求。
  • Pipeline 配置突然变化。
  • 删除、暂停、修改构建参数等高风险动作。

一次完整的止损演练至少包含：

  1. 撤销项目级令牌。
  2. 终止 OAuth PKCE 会话。
  3. 关闭 Brave Mode。
  4. 取消异常构建。
  5. 暂停相关 Agent。
  6. 从配置版本历史恢复 Pipeline。
  7. 检查 Mac 节点是否残留工作目录、凭证或异常进程。
  8. 重新启用节点后执行一条固定的 Xcode 测试流水线。

TeamCity 2026.2 的升级说明还显示，构建队列 REST 请求的权限检查已经收紧；没有 customize_build_parameters 权限的调用方，不能再通过相关接口触发带修改参数的构建。升级后如果出现 403，不应直接扩大令牌权限，而应先核对调用身份、项目范围和实际业务是否确实需要该权限。(TeamCity 升级说明)

08

平台容量与交接条件

当 MCP 只做日志读取时，远程 Mac 的压力主要来自排障任务和少量验证构建。进入受控触发后，排队时间、并行任务、Xcode 缓存和节点重启都会影响交付结果。

这里不要用 TeamCity 的工具说明推导 Mac 节点性能。生产容量必须用你的真实项目测试，记录：

  • 单次干净构建与缓存构建的耗时。
  • 高峰期构建排队时间。
  • 同一节点连续执行任务后的稳定性。
  • 任务取消后的工作目录清理结果。
  • 节点重启后的重新注册时间。
  • 签名任务与非签名任务是否发生错误路由。
  • 失败后能否由固定流水线完成恢复。

如果你需要先建立下游测试 Agent Pool，可以从 Mac mini M4 远程租赁方案开始做隔离验证；需要比较周期成本时，再参考 Mac mini M4 租赁价格。这里的目标不是立即替换现有基础设施，而是先验证真实 Xcode 项目、节点重启和任务路由。

三档放量判断

通过：

  • 只读排障权限已验证。
  • 受控触发只影响测试项目。
  • 写入操作有审批、差异和回滚。
  • 删除能力不对通用 Agent 开放。
  • 签名 Mac 与验证池隔离。
  • 令牌撤销和异常构建取消演练成功。

限制上线：

  • 读取和测试触发通过，但写入审计或回滚证据不完整。
  • Agent Pool 已拆分，但签名凭证流向仍需复核。
  • OAuth PKCE 可用，项目级令牌尚未完成轮换流程。

暂缓上线：

  • Agent 使用管理员全局权限。
  • 父项目继承导致未授权项目可见。
  • Brave Mode 长期开启且没有时间窗口。
  • MCP 可间接控制生产 Mac 登录或 Keychain。
  • 审计记录无法定位调用身份和配置差异。
09

常见验收问题

TeamCity 2026.2 MCP 默认能修改或删除流水线吗？

默认安全模式下，部分写入工具受到限制，不能把“已连接”理解为“可任意修改”。创建、更新和删除 Pipeline 必须结合 Brave Mode、令牌权限和项目权限判断。尤其是删除操作，可能影响 Pipeline 及父项目，应从通用 Agent 权限中移除。

怎样限制 AI Agent 只能查看指定项目？

创建专用用户，启用按项目权限，使用受限令牌，并检查父项目到子项目的继承关系。随后用该令牌实际读取允许和禁止项目，不能只依赖角色页面。TeamCity 的项目角色和权限会影响项目、构建配置及相关资源的可见范围。

Brave Mode 是否适合长期开在生产环境？

不建议作为默认生产配置。它的作用是解除部分写入工具限制，而不是提供审批、回滚或业务安全保证。更合适的方式是安全模式常开，只有隔离项目在限定时间窗口内临时开启，并由审计日志和配置版本历史提供证据。

AI Agent 触发 iOS 构建时如何隔离签名 Mac？

把诊断、验证和签名任务分配到不同 Agent Pool。签名池只绑定审核后的固定流水线，节点使用权限受限的本地账号，不向通用 Agent 提供 SSH、VNC、Keychain 或系统管理入口。TeamCity Agent Pool 只能解决构建路由问题，macOS 账号和凭证权限仍需单独验收。

10

结尾决策：先租一台隔离 Mac，再决定是否放量

如果你现在用的是一台共享 Mac mini、混合 Agent Pool 或临时云主机，常见缺点是权限边界不清、签名凭证容易与测试任务混用、节点故障后的恢复动作依赖个人经验。直接购买更多 Mac 又会带来硬件折旧、闲置容量和跨地域运维成本。

更稳妥的路径，是先用 VpsMesh 的一台隔离远程 Mac 建立测试 Agent Pool，跑通真实 Xcode 项目、节点重启、任务路由和签名隔离。验收证据完整后，再决定扩展为长期构建池或专用签名节点；如果你的团队需要的是临时试点、短期扩容或跨地域测试，这种方式通常比立刻采购整套 Mac 硬件更容易控制风险。