编码AI代理的K8s环境验证新技能

微服务测试公司 Signadot 今日推出了一项名为 /signadot-validate 的新技能。该技能允许编码代理（如某机构的 Claude Code、某机构的 Codex 以及 Cursor）在将代码交还给开发者之前，于类生产环境的 Kubernetes 环境中验证其自身的更改。

该技能旨在通过为编码代理提供所需的工具和环境访问权限，来弥合 Signadot 所称的云原生开发中的“代理闭环”。代理可以针对真实依赖项运行修改后的服务，读取结果并持续迭代直至测试通过。

此次发布旨在解决一个随着编码代理编写代码能力日益增强而浮现的鸿沟：代理虽然能写代码，但在复杂分布式系统中判断代码是否真正有效的能力却很弱。对单个微服务的更改可能会波及代理从未直接接触的数据库、消息队列、缓存和下游服务，而单元测试或模拟集成测试通常无法发现这些回归错误。

Signadot 认为，传统的替代方案无法扩展到代理式开发。本地的 Docker Compose 堆栈会与生产环境产生偏差，且会遗漏依赖项；而为每个代理重复创建环境则既缓慢又昂贵，并受成本限制。此外，共享的预发布环境会遭遇资源竞争和不稳定性问题，当数十个代理并行推送更改时，情况会变得更糟。

其结果是，开发者最终不得不充当验证层，手动审查代码差异、运行集成测试并调试下游故障。

/signadot-validate 技能通过两个接口将编码代理连接到 Signadot：一个用于控制平面操作的模型上下文协议（MCP）服务器，以及一个用于本地开发循环的命令行界面。

代理使用 MCP 服务器来发现集群、解析正在修改的工作负载并查找端口，而无需硬编码名称。然后，它会创建一个 Signadot 沙箱，该沙箱仅包含被修改的服务，其他所有内容均从基准集群共享，并使用一个唯一的路由键来将该更改与其他流量隔离开来。

环境运行后，代理会针对从集群中获取的真实依赖项（包括 Postgres、Kafka、Redis 和下游服务）在本地执行其更改后的服务。日志会实时流式传回，因此代理无需在每次迭代时都重建容器镜像。

该技能会预先询问代理要使用哪种验证形式，例如：语言原生的集成测试、像 Playwright 或 Cypress 这样的端到端框架，或是浏览器自动化。每个请求都携带路由键，以确保流量命中修改后的服务而非基准服务。

失败信息会被返回给代理，代理修复代码后，在同一个环境中重新运行。路由键保持不变，因此固定的测试可以继续工作。当验证通过后，环境会保持运行以供开发者审查。

/signadot-validate 技能现已面向运行 Signadot 的团队提供。FINISHED