所有文章 2026年11月3日 · 7分钟阅读 · Nathan Broadbent

我们的智能体可以准备服务器命令和部署。Rack Gateway 会把要审查的代码或提交交给我，然后要求我插入 YubiKey。

当编码智能体想要在 DocSpring 服务器上运行 Ruby 时，我的 Mac 上会弹出一个对话框。它会显示代码、代码将要运行的环境，以及智能体对为何需要运行它的解释。我阅读脚本，输入安全密钥的 PIN，点击 Run，然后触碰我的 YubiKey。

部署也以同样的方式工作。智能体会带来针对特定提交的审批请求。我的 PIN 和密钥触碰会批准该请求，然后 CircleCI 继续执行部署。

这就是 Rack Gateway，我们为 Convox 开发的开源访问控制服务。Convox 是我们在自己的 AWS 账户中运行 DocSpring 所使用的平台。该网关位于我们的工具与 Convox 之间，负责检查权限并记录发生的事情。

我们最初构建这些控制措施是为了 SOC 2。结果发现，它们在与编码智能体协作时非常有用：智能体可以准备命令或发布，而运行它的权限仍然是一个独立的决定。我们可以通过一个已经在使用的访问模型，给智能体分配更多工作。

DocSpring 最初运行在 Heroku 上。我喜欢那种能够部署应用然后回去继续做产品开发的感觉。后来我们获得了 AWS Activate 抵扣额度，这让迁移到自己的 AWS 账户变得有吸引力。

我不想自己编写所有的 CloudFormation 或 Terraform。我想要一个 Web 进程、一个后台 worker、日志，以及一种部署它们的方式。Convox 提供了这些：一个运行在我们账户中的、类似 Heroku 的平台即服务。

Convox 将其平台的一次安装称为一个 rack。它包含运行你的应用所需的云资源和管理服务。当前的 AWS rack 使用 Terraform，并在 Amazon EKS（AWS 的托管 Kubernetes 服务）上运行容器。你在 convox.yml 中描述应用的服务，Convox 负责处理构建、发布和部署机制。

作为一名 Rails 开发者，这感觉很熟悉。Convox 就像基础设施领域的 Ruby on Rails：约定优于配置。有一个可用的结构作为起点，当你的需求变得更具体时，你可以检查并修改实现。

这就是 DocSpring 的经历。我们现在有了自己的 Terraform 仓库，围绕 Convox 模块构建。我最终确实编写了 Terraform，但我从一个可用的平台开始。我们可以添加所需的资源和配置，而不必承担构建一个 PaaS 的工作。

安全默认值也很有帮助。例如，AWS worker 节点默认运行在 NAT 网关后面的私有子网中，Convox 负责处理应用域名的 TLS 证书。这为我们在准备合规工作时提供了一个有用的基础。

我认为 Convox 被低估了。更多初创公司应该在搭建自己的部署平台之前考虑它。你可以自己运行开源 rack，或者使用官方 Console，它增加了 Web 界面、团队访问控制、审计日志和部署工作流。我们选择为自托管设置构建自己的访问层。

我们的 SOC 2 工作让我们更仔细地审视谁可以更改我们的基础设施，以及事后我们如何对这些更改进行说明。共享底层 rack API 凭据不是我们想要的模式。我们需要个人身份、权限以及对每个操作的记录。

Rack Gateway 通过 API 代理、Web 界面和 CLI 提供这些功能。它验证发出请求的人或 API token 的身份，检查操作是否被允许，并在需要时要求 MFA。Convox 仍然在其下运行应用。

在 DocSpring，我们还让网关只能通过我们的私有 Tailscale 网络访问，并封锁了对 rack API 的直接访问。在网络上并不意味着有权运行命令；网关仍然会检查请求。

审计日志记录谁请求了操作以及发生了什么。其条目形成一个 HMAC 链接的链，定期锚点存储在 S3 Object Lock 保留策略下。这使得对被锚定历史的篡改可以被检测到。审计文档解释了数据库日志与其不可变锚点之间的区别。

一旦编码智能体开始协助运维，我们就有了强制执行其访问权限的地方。下一个问题是让审批变得值得阅读。

一个询问智能体是否可以“调查一个错误”的提示并不能告诉我太多信息。我想看到它即将运行什么。

使用 Rack Gateway 时，智能体通过 --script 传递一个本地文件，并给出理由。我们将网关配置为拒绝没有理由的命令：

rack-gateway run web rails runner
--app example-app --rack staging
--script inspect_order.rb
--justification "Inspect one test order to investigate a validation error"

以下是上面对话框中那个合成示例，使用一个虚构应用的 Order 模型：

Inspect one synthetic order while investigating a validation error.

ActiveRecord::Base.transaction do connection = ActiveRecord::Base.connection connection.execute("SET LOCAL statement_timeout = '5s'") order = Order.select(:id, :status).find(123) puts({ id: order.id, status: order.status }.to_json) end

对话框会显示带语法高亮的 Ruby 代码、目标应用和 rack，以及理由。我可以检查这个查询是否通过主键读取一条记录、只选择它需要的字段，并设置了超时。只读查询仍然可能使数据库过载。

每次交互式运行或 exec 都需要通过我的密钥触碰提供新的 MFA 证明。即使我刚刚批准了另一个命令，网关也会强制执行这一点。现有的登录或最近的批准并不覆盖下一条命令。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）