更新：

在其他的答案矿后〜8月加入。当时我没有意识到 位置
标头在响应中。在某些情况下，这确实是一个不错的选择。就是说，根据答案和评论中的警告（尤其是关于 _参数化_构建），该答案似乎在某些情况下仍具有一定的实用性。

原始答案：

不幸的是，他们并没有使事情变得如此简单。也就是说，例如，返回带有 ID之 类的信息的 JSON 响应。 __

但是，我相信一个可靠的解决方法（虽然肯定是不平凡的）是利用您用于触发构建的URL中的 cause 参数，并在该原因内添加 唯一的文本
，您稍后可以解析该 文本 以确定您是否从您的自动化触发了它。

为了进一步使特定作业具有 唯一性 ，即使是在自动化的情况下，多个作业同时运行，也要在cause参数内包括某种类型的 唯一ID （可能只是
RDBMS 或类似的序列ID ）。

然后，您可以使用 JSON API 获取有关您正在远程触发的 作业的 信息。同样，它有点间接，但是可行：

点击以下形式的网址：

http://<server>:<port>/job/<jobname>/lastBuild/api/json

您可以?pretty=true在浏览器中添加漂亮的打印效果，以提高人类可读性。

这将为您提供上一版本的 JSON 。它会在 actions 属性中包含 causes 属性，并且在其中（在另一个名为
shortDescription的 嵌套属性中），您将找到添加的 cause 参数（如果这是您触发的构建之一）。 __

您可以同时解析特殊的静态文本和生成的ID，以查看它们是否匹配。如果他们这样做，那么您也可以从 JSON中 获取 Jenkins id （搜索嵌套的
buildNumber ）。

如果该构建不是完全由自动化触发的，或者根本不是由您的自动化触发的，但是ID不匹配，则可以重复进行 N-1构建 的过程，直到找到所需的内容。

JSON将采用以下形式：

http://<server>:<port>/job/<jobname>/<buildNumber>/api/json