让 Devin 自行验证微服务端到端改动

Devin 能在云端 VM 里改代码、跑单元测试，但微服务改完以后，和其他服务还能不能配合，通常要等部署到 staging 才知道。Signadot 这篇教程尝试把这一步提前：让 Devin 在自己的 VM 中运行修改后的服务，接入共享 Kubernetes 集群，再执行集群内的端到端测试。

作者用 HotROD 打车演示应用跑通了这条链路，Devin 会话约花 8 分钟。值得看的是它如何连接环境、处理失败、提供验证证据，以及这套流程对现有项目有哪些要求。

不部署整套环境，怎样验证一个服务的改动

教程的任务很小：修改 HotROD 的 route 服务，把计算出的 ETA 固定为 2 分钟，同时保留 FAST_ROUTE 覆盖行为和取整逻辑。

难点在验证。route 需要访问真实依赖，用户请求又会经过其他服务。只在 VM 里调用一个函数，证明不了完整请求链路能工作。

Signadot 的做法是保留集群中的基线服务，把修改后的 route 跑在 Devin 的 VM 中，再创建一个 sandbox。这个 sandbox 可以理解为一套按请求标记选择服务的路由规则：携带指定 routing key 的请求进入修改版 route，其他请求继续访问基线。

连接依靠 ControlPlaneProxy，流量经由 Signadot 控制平面传输。Devin 只需要 Signadot API key，无须持有 kubeconfig，也无须直连 Kubernetes API server。因此，集群可以运行在开发者电脑上的 minikube、kind、k3d 或 Docker Desktop 中。

另一个条件是 Devin 提供完整 VM，并有免密 sudo。signadot local connect 因而可以使用默认特权模式，让 VM 解析 redis.hotrod.svc 这样的集群域名，并调用集群中的依赖。

这套方案把待测服务放在 VM 中，把其余依赖留在共享集群里。

但它有一个关键前提：应用必须把 routing key 从入站请求继续传给下游请求，例如通过 OpenTelemetry baggage。HotROD 已经实现了这件事；自己的系统如果没有传播上下文，仅创建 sandbox 并不能保证请求全程进入正确版本。

真正需要配置的，是环境和执行知识

作者给出的完整教程约需 30 分钟，其中 Devin 执行任务约 8 分钟。前面的工作包括安装 Signadot Operator、部署 HotROD，以及创建运行 Playwright 的 job runner group。

准备机器需要通过 signadot auth login 登录，kubectl 也要指向目标集群。Devin 组织则需要允许编辑 blueprint，并具备 Manage MCP Servers 权限。

blueprint 决定每次会话 VM 的初始环境，分为三部分：

• initialize 安装 Go 1.27.1 和 Signadot CLI v1.9.0，将组织、集群及 ControlPlaneProxy 连接写入 ~/.signadot/config.yaml。
• maintenance 把 HotROD 准备到 ~/repos/hotrod，并下载 Go modules。
• knowledge 不执行脚本，而是告诉 Devin 怎样连接、启动服务、创建 sandbox 和运行测试。

固定 CLI 版本有具体原因：不指定 SIGNADOT_CLI_VERSION 时，安装器会向 GitHub API 查询最新 release，Devin 共享构建 IP 可能触发限流，随后出现 signadot: command not found。保存 blueprint 后，新快照构建约需两分钟。

凭据也有两处配置。作者创建独立服务账号 devin-tutorial，将 key 保存为 Devin Raw secret SIGNADOT_API_KEY；MCP server 还要单独填入同一个 key，因为它不共享 Devin 的 Settings → Secrets。只填前者，MCP 状态仍会显示 Needs connection。

MCP server 是 CLI 的子命令，在 VM 中通过 STDIO 运行。不过，原文添加 MCP 的步骤没有展示完整启动命令和参数，照着文字操作时还缺这项信息。

并发会话还有一个容易忽略的问题：每台 Devin VM 的 /etc/machine-id 相同，而 Signadot 用它识别 devbox。教程要求为会话生成独立 ID，并设置 MACHINE_ID_FILE，否则可能报 409 Conflict: devbox ... is already claimed。

要让 Agent 自己完成验证，仓库里需要留下可执行的运行知识，包括端口、环境变量、依赖地址和排错入口。

测试通过之外，还要证明请求经过了新代码

修改本身只有一行，作用是把原来的随机 ETA 换成固定值：

   -    // Generate a random number between 3 and 45 with decimals
   -    eta := time.Duration((rand.Float64()*(45-3) + 3) * float64(time.Minute))
   +    eta := 2 * time.Minute

要看的是新增的 eta := 2 * time.Minute。基线 ETA 在 3 到 45 分钟之间，因此 2m0s 可以用来区分修改版行为。

随后，Devin 通过 signadot local connect 连接集群，在 VM 的 8083 端口启动 route，再调用 list_clusters、resolve_workload、resolve_workload_port 和 list_devboxes，最后用 create_sandbox 创建 devin-route-eta。

sandbox 将 hotrod namespace 中 Deployment route 的 8083 映射到当前 VM 的 localhost:8083，并以 http://frontend.hotrod.svc:8080 作为入口。

任务提示词提前明确批准了这份 sandbox spec。作者解释，create_sandbox 会要求 Agent 先确认规格，没有这句授权，流程会停下来询问用户。

Playwright 则作为 Signadot Job 在集群内执行。下面这段命令负责提交测试，并等待结果：

           signadot job submit -f .signadot/testing/demo-playwright-job.yaml \
             --set branch=main --set namespace=hotrod \
             --set sandbox=<sandbox-name> --wait --timeout 15m

这里要核对 --set sandbox=<sandbox-name>：测试必须指向本次 sandbox。MCP server 当时还没有 Job 工具，因此这一步使用 CLI。

作者的实测并非首次就成功。第一个 Job 卡在「Resolving routes」：route 默认使用 REDIS_ADDR=redis:6379，这个短域名只在集群内能解析。Devin 查看日志、下载 Playwright 报告后，将服务改用 REDIS_ADDR=redis.hotrod.svc:6379 重启，第二次测试通过，无须再改业务代码。

最终报告中的 Job 是 hotrod-playwright-e2e-zihjipq，结果为 2 of 2 tests passed。Devin 还分别发起带 routing key 和不带 key 的打车请求，得到：

• sandbox：Driver T792260C arriving in 2m0s。
• 基线：Driver T775730C arriving in 8m36s。

测试结果与行为对照一起，才构成这次修改的验证证据。

我的判断

这套流程最有价值的地方，是把「改代码以后如何验证」也写进 Agent 的任务。作者展示的失败处理尤其有参考价值：问题出在跨环境域名解析，单元测试未必能暴露，真实依赖链路却能直接发现。

但这仍是一个演示案例。修改只有一行，测试只有 2 条，约 8 分钟是这次会话的耗时。原文没有给出与传统 staging、每个 PR 部署独立环境等方案的耗时、成本或成功率对照，不能据此推断一般团队也会更快。

路由隔离也有边界。未携带 key 的请求继续走基线，证明的是请求分流；它不等于数据库、Redis 或其他共享状态都获得了隔离。原文没有交代复杂写入、异步任务等场景如何处理。

控制平面转发还会增加链路延迟。教程提到 driver 每次调用 route 只有 1 秒期限，发生 DeadlineExceeded 时，可设置 ROUTE_CALC_DELAY=1ms，去掉模拟的 50 ms 工作。这样有助于功能验证，但不能拿来证明真实环境的延迟表现。

我的取舍是：已有共享 Kubernetes 测试环境、上下文传播和 E2E 套件的团队，适合评估这种接法。独立 PR 环境对部署配置和环境差异的验证仍有价值；原文没有证明 sandbox 可以覆盖这些检查。

能拿来做什么

• 给 AI 编程任务加上验收证据要求：报告 diff、sandbox routing key、Job 名称和结果，并提供一组能区分新旧行为的请求结果，避免只收到一句「测试通过」。
• 在仓库中维护服务的集群外运行说明。前端或 Node 服务若要接入同类流程，应写清启动命令、端口、依赖地址和 routing key 传播方式，再判断是否具备接入条件。
• 将稳定流程沉淀为 .devin/blueprint.yaml，或采用原文提到的 signadot-validate skill，放入 .agents/skills/。需要提交 PR 时，可要求 Devin 附上通过的 Signadot Job。
• 保留测试日志和 Playwright 报告，并在验证结束后删除 sandbox、停止本地服务。教程的清理命令是 signadot sandbox delete devin-route-eta；VM 关闭后，devbox 占用约一分钟内失效。