我正在使用 TFS 执行夜间构建，其中包括使用TFS测试代理 https://www.visualstudio.com/en-us/docs/test/lab-management/test-machines/install-configure-test-agents。我正在运行最新版本的 TFS/Test Agent（2015 - Update 3），目前没有运行其他版本。通常（也许有一半的时间），当夜间作业运行时，“Visual Studio 测试代理部署”步骤会失败并出现以下错误：

该作业已被放弃，因为代理 Agent-XXX 未续订 锁。确保代理正在运行，没有休眠，并且没有丢失 与服务的通信。

这是由于在测试代理的日志文件（_diag 下）中发现的错误造成的：

该代理的会话已存在。睡觉30秒 在下次重试之前。

Microsoft.TeamFoundation.DistributedTask.WebApi.TaskAgentSessionConflictException： 任务代理 Agent-XXX 已拥有所有者 XXX 的活动会话。

这个问题直接参考here http://ericphan.net/blog/2016/6/10/solving-the-tfs-build-agent-error-the-session-for-this-agent-already-exists，并间接谈到here https://social.msdn.microsoft.com/Forums/vstudio/en-US/a188d2cd-3985-4d8a-84e1-723ef49ab314/vnext-build-agent-service-fails-to-start-at-reboot-vsoagentservice?forum=tfsbuild.

我发现这个问题的解决方案是重新启动测试代理正在运行的服务器，这会清除所有无效会话，并且在服务器启动备份后，测试运行得很好。我认为这实际上是正在做的事情之前提到的帖子 http://ericphan.net/blog/2016/6/10/solving-the-tfs-build-agent-error-the-session-for-this-agent-already-exists。重置配置的结果是服务重新启动。

虽然在链接的文章中作为解决方案提出，但这只是暂时的。即使服务器重新启动并且构建成功运行后，第二天问题仍将再次出现，需要手动干预才能运行构建。

我可以安排一个任务来重置服务，甚至可以在运行夜间构建之前直接重新启动服务器，但它给我的印象是绷带而不是修复。以前有人遇到过这个问题吗？如果有的话，有什么办法可以从一开始就防止它发生吗？

Update 1

我只是设置了一个在主要测试之前运行 5 分钟的构建，该测试运行蝙蝠脚本 https://stackoverflow.com/questions/162304/how-do-i-shutdown-restart-logoff-windows-via-a-bat-file重新启动托管我的测试代理的所有服务器。这是一种解决方法，但似乎可以解决问题。希望有一天有人能提出比这更好的解决方案，但目前，这就是我在 TFS 中运行自动化测试的方式。

Update 2

我现在有三台服务器，所有三台服务器都表现出相同的问题，尽管很难准确确定问题发生的时间。事实证明，在不造成停机的情况下扩大解决方案的规模是相当具有挑战性的。

Update 3

更好的一天到来了，我将 TFS 升级到 2018，并将构建代理升级到最新版本，这个问题不再出现，我认为这是旧构建代理中的错误。我仍然没有针对原始版本的构建代理的解决方案......

听起来好像有一个进程 Agent.Listener.exe 正在计算机上的某个位置运行，可能作为服务（而不是登录的用户会话）运行。

请注意，如果代理进程在有活动会话时突然终止，则该会话最终将超时（我认为是 5 分钟后）。并且在启动时，如果代理遇到会话冲突，那么我认为在放弃之前它将重试长达 5.5 分钟（足够的时间让突然终止的会话过期）。

我将继续关闭它并假设某个进程正在某处运行。我们在这方面没有遇到任何问题，也没有听到任何其他报告，所以我认为代理没有问题。如果您找到复制品，或者看起来我错了，请重新打开。