AI代理如何配置TeamCity构建链

TL;DR： 某个时刻，我们跨越了一个有趣的临界点。AI 代理现在可以设置 TeamCity 构建配置乃至完整的构建链、添加构建功能并配置参数。

这之所以成为可能，是因为 TeamCity 文档结构清晰，可通过 Context7 借助 MCP 访问，同时代理可以依赖 TeamCity CLI 和 teamcity-cli 技能等工具。

我最近进行了一些实验，看看这在实践中能走多远。

[LOADING...]

#1 寻找解决方案

首先，我要求 ChatGPT 针对客户需求提出一个解决方案。

ChatGPT 通过 Context7 阅读了 TeamCity 文档，并提出了一个包含以下内容的方案：

到目前为止，这是你能从一个有能力的 LLM 那里期望得到的：一个相当合理的设计。

然后，我将这个解决方案传递给 Codex，并让它实际在 TeamCity Nightly 中、在我个人的沙箱项目中设置一切。

五分钟后，我有了一个可用的演示。

过程中出现了一些错误，但几分钟内就被修正了。Codex 使用了 TeamCity REST API，并通过 teamcity api 命令逐步执行设置，实际上根据原始描述重现了整个配置。

有趣的地方不在于配置第一次就正确——事实并非如此。

有趣的是代理能够多快地：

关键之处在于，描述一个流水线和实际让它运行之间的差距现在非常小。代理不会止步于生成一个计划——它会执行计划，并迭代直到结果可用。

此时，代理不再仅仅描述解决方案，而是在实现并完善它。

在第二个实验中，我从 GitHub 克隆了一个小的个人 Go 项目，并要求 Codex 在 TeamCity 中为其设置 CI。

它创建了一个包含“测试”和“构建”配置的简单流水线。

有一个有趣的细节：它设法从 gh 工具中重用了我的 GitHub PAT 来创建 VCS 根目录。用“偷”这个词并不准确，但确实感觉很有趣。

成功的条件很简单：构建应为绿色。

然而并非如此。

经过几次尝试，代理发现构建代理环境中缺少 Go。于是它修改了构建步骤以绕过此问题，并重试直到构建通过。

换句话说，代理不仅仅是在配置 TeamCity——它是在朝着一个目标努力，并根据构建过程中发生的情况调整行动。

在检查结果后，我注意到 Go 测试在 TeamCity 中没有正确报告。

我指出了这一点。

代理更新了配置，添加了所需的构建功能，在下一次运行时测试结果被正确报告了。

在这两个案例中，代理遵循了类似的模式：

这个循环是它与早期 LLM 实验的主要区别。

代理不再停留在“这里是你如何配置的方法”，而是继续操作直到系统真正工作。这将 CI 配置变成了一个可以自行收敛的迭代过程，而不是止步于预先编写的静态定义。

TeamCity 可以与 AI 代理协同工作，而 AI 代理也能够有意义地帮助配置它。但更有趣的发现是它们如何做到这一点。

在两个实验中，相同的模式出现了：代理并没有止步于生成一个配置——它应用了配置，观察发生了什么，并不断调整直到流水线运行起来。这个反馈循环（通常需要开发人员运行流水线、读取输出、修复问题、再次运行）现在在系统内部自动进行。

话虽如此，这些仍是早期成果。代理需要明确的目标、完善的文档和可控的操作环境。过去需要多次手动迭代的设置任务现在可以更快地收敛，代理处理了大部分的循环工作。