TeamCity 2026.2：Pipelines 全面可用，AI 助手支持 BYOK 及更多更新
内容提要
TeamCity 2026.2 正式发布，主要更新包括：Pipelines 功能全面可用，支持分支处理、失败后运行、调试及无仓库模式；AI 助手支持自带密钥（BYOK），可接入多种大模型；新增 MCP 工具和 OAuth 授权；优化依赖重试、IDE 插件及 GitHub 集成。
延伸解读
Pipelines 正式可用，但仍有演进空间
Pipelines 从 EAP 转为正式可用，意味着 JetBrains 认为其已具备生产级稳定性，适合各类项目。不过，官方也明确表示开发并未停止，并提供了路线图。对于已在使用经典构建配置的团队，迁移到 Pipelines 需要评估现有工作流的兼容性，尤其是对分支保护和复杂依赖的支持。
BYOK 模式：灵活性与责任并存
AI Assistant 支持 BYOK 后，用户可自由选择 Anthropic、OpenAI、Gemini 或本地 LLM，这增加了灵活性并可能降低长期成本。但自带密钥意味着用户需自行管理 API 密钥的安全，并关注不同模型在 CI/CD 场景下的表现差异。管理员在 Admin 区域配置时，应确保密钥仅授权给可信人员。
MCP 工具增强，但需注意安全限制
新增的 pipeline 管理 MCP 工具（get/post/delete）中，写操作仅在 Brave 模式下可用，且需手动启用，这体现了安全考量。OAuth/PKCE 授权流程的引入简化了 AI 代理的接入，无需手动生成令牌。用户应理解 Brave 模式的风险，避免在非受控环境中启用。
依赖重试与分支处理：提升 CI/CD 效率
依赖重试设置允许对失败的下游构建自动重试，避免整个链的重跑，节省时间和资源。分支处理改进支持按分支设计不同工作流，并对受保护分支提供清晰警告，防止误推送。这些功能有助于减少手动干预，但需注意重试策略可能掩盖间歇性问题，应结合告警监控。
Q&A
TeamCity 2026.2 中 Pipelines 功能有什么重要更新？
Pipelines 功能在 TeamCity 2026.2 中正式全面可用（GA），不再只是 EAP 功能。新增了改进的分支处理、失败后运行、调试单个任务、无仓库模式、以及支持从旧构建提升（promote）等功能。
TeamCity 2026.2 的 AI Assistant 如何支持 BYOK？
AI Assistant 现在支持自带密钥（BYOK），你可以在 Admin | AI Assistant 中填入自己的 AI API 密钥，然后选择使用 Anthropic、OpenAI、Google Gemini 或其他支持的模型来检查构建和调试 CI 工作流。
TeamCity 2026.2 新增了哪些 MCP 工具？
新增了三个用于管理 pipelines 的 MCP 工具：teamcity_pipeline_get、teamcity_pipeline_post 和 teamcity_pipeline_delete。其中 post 和 delete 工具仅在 Brave 模式下可用，需要手动启用。
TeamCity 2026.2 中如何实现失败后继续运行任务？
在设置任务依赖时，可以启用“即使上游失败也运行任务”选项，这样即使某些步骤出错，指定的任务（如清理或通知）仍会执行，但整个流水线仍会被标记为失败。
TeamCity 2026.2 中如何调试单个 pipeline 任务？
你可以在编辑模式下直接调试单个任务，无需触发整个流水线。这样可以更快地设计复杂工作流，因为可以即时修复问题，而不必到最后才处理失败日志。
TeamCity 2026.2 中如何创建不关联仓库的 pipeline？
创建 pipeline 时选择“Without repository”选项，即可创建一个不检出任何远程源代码的自定义工作流。
TeamCity 2026.2 中依赖重试设置有什么改进？
在构建配置设置的 Dependencies 选项卡中新增了 Retry Settings 组，可以启用自定义重试设置并输入重试次数，这样当下游构建失败时，可以自动重试失败的依赖，而无需重新运行整个链。
TeamCity 2026.2 的 IDE 插件有哪些更新？
IDEA 插件现在内置了 CLI 工具，并支持无缝的 MCP 服务器注册，可以轻松集成 Junie 或第三方 AI 代理。此外，插件核心功能改进：可以在 IDE 中查看 TeamCity 测试结果，并启动包含未提交本地更改的远程运行。Kotlin Multiplatform 开发者还可以获得免费的 TeamCity Cloud 订阅（每月 30,000 构建积分）。
TeamCity 2026.2 的 GitHub 集成有什么改进？
Pull Requests 构建功能现在可以按源分支匹配拉取请求，而不是分支引用。这样即使 GitHub 为不同仓库的拉取请求分配了不同的编号，TeamCity 也能将它们识别为相关更改，并在同一构建链中一起构建。
TeamCity 2026.2 中 Kotlin DSL 编译模式有什么新选项？
对于存储在远程仓库中的 Kotlin DSL 版本化设置，现在可以选择在服务器上还是在构建代理上执行代码。在构建代理上执行 kDSL 限制更少且更安全，但两种方式各有取舍，具体建议请参考文档。
