我正在使用 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，并将构建代理升级到最新版本，这个问题不再出现，我认为这是旧构建代理中的错误。我仍然没有针对原始版本的构建代理的解决方案......
