环境虚拟化赋能自主智能体

5 阅读7分钟

AI智能体生成代码效率高,但代码验证是瓶颈。环境虚拟化能提供快速、经济、真实的运行时环境,赋能智能体自主迭代,加速工程效率。

译自:Enabling autonomous agents with environment virtualization

作者:Arjun Iyer

我过去一年一直在观察AI对话从智能自动补全转向自主贡献。当我测试像Claude Code或GitHub Copilot Workspace这样的工具时,我不再仅仅看到代码建议。我看到它们在解决工单和重构整个模块。

这个前景很有吸引力。我想象着分配一个复杂的任务,然后就能收到合并后的工作。但尽管这些智能体能在几秒钟内生成代码,我发现代码验证成为了新的瓶颈。

为了让智能体成为倍增器,它们不能依赖人类验证每一步。如果我必须调试每一个中间状态,我的生产力提升就会消失。要实现10倍的影响力,我们必须过渡到智能体驱动的循环,其中人类提供意图,而智能体处理实现和集成。

代码生成反馈循环危机

考虑这样一个场景:一个智能体被任务更新用户服务中一个已弃用的API端点。智能体解析代码库,识别相关文件,并生成语法正确的代码。它甚至可能生成一个在该特定仓库有限上下文中通过的单元测试。

然而,当代码与更广泛的系统交互时,问题就会出现。一个更改可能会破坏与下游支付网关或上游认证服务的契约。如果智能体看不到这个失败,它就会认为任务已完成并打开一个拉取请求。

然后,负担就落在了人类开发者身上。他们必须拉取智能体的分支,启动本地环境,或者等待缓慢的 staging 构建完成,结果却发现集成错误。开发者将错误日志粘贴回聊天窗口,并要求智能体再次尝试。这种“乒乓效应”会破坏开发速度。

Claude Code的创建者Boris Cherny指出,闭环系统对于智能体有效运行的必要性。一个智能体的能力仅限于其观察行动后果的能力。如果没有包含真实运行时数据的反馈循环,智能体就会在黑暗中构建。

云原生开发中,单元测试和模拟对于这种反馈是不够的。在微服务架构中,正确性是更广泛生态系统的一个函数。

通过单元测试的代码仅仅是一个它可能有效的建议。真正的验证要求代码针对真实的依赖项、真实的网络延迟和真实的数据模式运行。为了让智能体自主迭代,它需要访问运行时现实。

代码测试失败图

来源: Signadot.

要求:规模化提供真实运行时环境

在最近的博客文章“长寿命智能体的有效测试环境”中,Anthropic的工程团队认为智能体的性能严格受限于其测试环境的质量。如果测试环境提供缓慢或不准确的反馈,智能体就无法学习或纠正自身。

这对工程领导层构成了巨大的基础设施挑战。在一个大型组织中,你可能部署100个自主智能体同时处理积压任务。为了支持这一点,你实际上需要100个不同的 staging 环境。

解决这个问题的传统方法在规模上会失败。为每个任务启动完整的Kubernetes命名空间或临时集群既成本高昂又缓慢。配置一个包含50个或更多微服务、数据库和消息队列的完整集群可能需要15分钟或更长时间。这种延迟对于AI工作流是致命的。大型语言模型(LLM)的操作时间尺度是秒级的。

我们面临一个根本性的冲突。我们需要生产级保真度来确保可靠性,但我们无法为每个智能体任务承担生产级别的开销。我们需要一种快速、经济、准确的代码验证方法。

解决方案:环境虚拟化

答案在于将环境与底层基础设施解耦。这个概念被称为环境虚拟化。

环境虚拟化允许在共享的Kubernetes集群中创建轻量级、短暂的沙盒。在这种模型下,一个基线环境运行所有服务的稳定版本。当智能体对特定服务(例如前面提到的用户服务)提出更改时,它不会克隆整个集群。相反,它只将包含智能体新代码的修改工作负载作为一个影子部署启动。

然后,环境利用动态流量路由来创建专用环境的错觉。它采用上下文传播头来将特定请求路由到智能体的沙盒。如果请求携带着与智能体任务相关的特定路由键,服务网格或入口控制器会将该请求导向影子部署。所有其他下游调用都会回退到稳定的基线服务。

这种架构通过三种特定方式解决了智能体与环境的匹配问题:

  1. 速度: 因为只启动一个容器或pod,而不是一个完整的集群,沙盒可以在几秒钟内启动。
  2. 成本: 基础设施占用空间极小。你无需为闲置数据库或稳定服务的重复副本付费。
  3. 保真度: 智能体针对真实的依赖项和有效数据进行测试,而不是模拟。修改后的服务与基线中实际的支付网关和数据库进行交互。

AI智能体的无缝验证工作流

这种验证循环的机制依赖于精确的上下文传播,通常通过像OpenTelemetry baggage这样的标准追踪头来处理。

当智能体处理一个任务时,它的环境被虚拟地映射到远程Kubernetes集群。这种设置支持无冲突的并行性。多个智能体可以在不同的沙盒中同时处理同一个微服务而不会发生冲突,因为路由是由附加到测试流量的唯一头部决定的。

以下是智能体重构微服务的自主工作流程:

  1. 生成: 智能体分析工单并利用本地静态分析生成代码修复。在此阶段,代码是理论性的。
  2. 实例化: 智能体通过模型上下文协议(MCP)服务器触发沙盒。这会在几秒钟内部署修改后的工作负载以及正在运行的基线。
  3. 验证: 智能体使用特定的路由头对集群运行集成测试。请求路由到修改后的服务,而依赖项回退到基线。
  4. 反馈: 如果更改破坏了下游契约,基线服务会返回一个真实的运行时错误(例如,400 Bad Request)。智能体捕获的是实际异常,而不是依赖于模拟。
  5. 迭代: 智能体分析错误,完善代码以修复集成失败,并立即更新沙盒。它再次运行测试以确认修复在真实环境中有效。
  6. 提交: 一旦测试通过,智能体就会提交一个已验证的拉取请求(PR)。人类审阅者会收到一个沙盒链接,可以立即与正在运行的代码交互,无需本地设置。

智能体重构微服务的自主工作流程图

来源: Signadot.

为什么工程的未来是自主的

随着我们规模化使用AI智能体,瓶颈从键盘转移到基础设施。如果我们把智能体视为更快的打字员,但却强迫它们等待缓慢的传统CI/CD流水线,我们什么也得不到。我们只是建立了一个更长的未验证拉取请求队列。

为了走向真正的自主工程团队,我们必须赋予智能体“看”的能力。它们需要看到自己的代码在真实世界中的表现,而不仅仅是在文本编辑器中。它们需要体验部署的摩擦和网络调用的现实。这就是Signadot的方法。

环境虚拟化正在从开发者体验工具转向基础架构。通过闭环,智能体可以完成繁琐而迭代的集成工作。这使得架构师和工程师可以专注于系统设计、高层意图以及构建软件的创造性方面。