在过去的十年里,云基础设施已经具备了高度的可编程性。

几乎所有的平台都提供了API,使开发人员能够创建应用程序、配置数据库、设置网络连接以及获取各种指标数据。

这种变化使得通过“代码即基础设施”以及CI/CD流程实现自动化成为可能,从而使团队能够通过脚本而非仪表板来管理系统。

现在,又有一种新的自动化方式正在出现。人工智能代理开始直接参与开发工作流程。这些代理可以阅读代码库、生成实现方案、运行终端命令,甚至帮助调试系统。下一步的发展方向是让它们能够与基础设施本身进行交互。

开发者不再需要手动查看仪表板或记忆复杂的命令行语法,而是可以让人工智能代理来检查系统状态、部署服务或获取指标数据。这些代理会代表用户与云API进行交互,从而完成这些任务。

这种能力为一种全新的工作流程打开了大门——在这种工作流程中,基础设施具备了对话式交互的能力,能够被编程控制,并且能与开发环境深度集成。

在本文中,我们将探讨人工智能代理如何通过API与云基础设施进行交互,分析将大型API提供给人工智能系统所面临的挑战,以及诸如MCP这样的架构是如何帮助代理安全地发现并执行基础设施操作的。我们还将通过一个实际例子,来了解如何使用“搜索与执行”模式将人工智能代理连接到像Sevalla这样的云平台上。

为了能够有效地理解本文的内容,建议读者事先掌握一些关于云基础设施的概念,比如API、“代码即基础设施”以及CI/CD工作流程。同时,你也应该对人工智能代理或开发辅助工具如何与代码和系统进行交互有一个基本的了解,这样才能完全领会本文中讨论的各种架构。

我们将涵盖的内容

人工智能代理正成为开发环境的一部分

现代的开发工具越来越多地将人工智能助手直接集成到编码环境中。诸如Cursor、Windsurf和Claude Code这样的编辑器允许开发者在不离开编辑器的情况下,就他们的项目提出问题、生成新代码或执行命令。

开发者无需手动查阅文档或编写重复性的代码,只需描述他们的需求,人工智能就会理解这些请求并完成相应的操作。

这种方法在编写函数、重构代码或调试错误等任务中已经非常普遍。然而,基础设施的管理仍然主要通过控制面板、终端命令或外部工具来处理。

如果要让人工智能助手真正有效地帮助开发者,它们就必须能够访问开发者每天都会使用的那些系统。也就是说,它们需要能够调用用于管理应用程序、数据库、部署以及其他基础设施资源的API。

挑战在于如何以结构化且可扩展的方式实现这种访问功能。

将人工智能助手连接到外部系统

人工智能助手本身并不懂得如何与外部服务进行交互,因此它们需要一个框架来帮助它们安全地调用各种工具并获取数据。

模型上下文协议正是这样一个框架。该协议的设计目的是让人工智能助手能够以标准化的方式与外部工具进行连接。

MCP服务器会提供一些工具,当人工智能助手需要信息或想要执行某些操作时,就可以通过这些工具来获取所需的数据。这些工具可能包括从数据库中检索数据、查询日志、与API交互,或在远程系统上执行命令等功能。

当人工智能助手收到用户的请求后,它会确定应该调用哪个工具,并通过MCP服务器来执行该工具。执行结果会返回给助手,然后助手就可以继续处理相关问题了。

这种架构使得人工智能助手能够在与复杂系统交互的同时,保持自身与外部环境之间的清晰界限。

大型云API带来的挑战

虽然MCP使人工智能助手能够连接到基础设施系统,但云平台又带来了新的挑战。

大多数云平台都会提供包含大量端点的API。一个典型的云平台可能会提供用于管理应用程序、数据库、存储资源、网络配置、域名设置、指标监控、日志记录以及部署流程等的各种接口。

如果MCP服务器将每个接口都作为单独的一个工具来提供,那么所需的工具数量很快就会达到数百个。

这会带来几个问题:首先,人工智能助手在决定使用哪个工具之前,必须了解每一个工具的用途和参数,这样才会提高其高效运行的效率;其次,对于负责构建和维护MCP服务器的开发人员来说,管理如此众多的工具也会变得非常困难。

第三,这种系统会变得过于僵化。每当添加一个新的API接口时,就必须创建新的工具并进行相应的文档记录。

对于规模较大的API来说,这种做法很快就会变得不切实际。

一种更简单的API访问方式

另一种架构通过大幅减少AI系统需要使用的工具数量来解决这个问题。

它并不为每个API接口提供单独的工具,而是让MCP服务器仅提供两项功能。

第一项功能允许智能体搜索API规范。这样,智能体就能发现可用的接口、了解参数信息,并检查请求或响应的数据结构。

第二项功能则允许智能体执行调用API的代码。

在这种模式下,AI智能体会动态生成调用API所需的代码。由于智能体可以自行查询规范并编写API调用代码,因此MCP服务器无需为每个接口单独开发工具。

这种设计大大降低了系统集成的复杂性,同时仍能让智能体完全访问底层平台的功能。

为什么沙箱化代码执行如此重要

允许AI智能体生成并执行代码会带来重要的安全问题。

如果生成的代码可以无限制地运行,它就有可能访问系统的敏感部分或执行不必要的操作。因此,必须对执行环境进行严格的控制。

一种常见的解决方案是将生成的代码放在沙箱环境中运行。在这种设置下,代码会在权限受限的隔离环境中运行,且该环境只提供允许与平台API交互的特定功能。

由于代码无法直接访问主机系统,因此出现异常行为的风险会大大降低。同时,AI智能体仍然可以根据需要灵活地生成自定义的API调用代码。

动态代码生成与沙箱化执行相结合的方式,使得AI智能体能够安全地与复杂的API进行交互。

以Sevalla为例的实际应用

这种架构的实际应用可以在Sevalla MCP服务器中看到。该服务器通过“搜索-执行”模式,让AI智能体能够访问云平台的API。

Sevalla是一家专为开发者设计的PaaS平台,它为开发人员提供了应用托管、数据库服务、对象存储以及静态网站托管等功能。当然,还有AWS和Azure等其他选项,它们也各自配备了相应的MCP工具。

该服务器并没有为每个API接口注册数百个工具,而是只提供了两项功能,让AI智能体能够探索并使用整个平台的功能。有关Sevalla MCP服务器的完整文档,请点击这里查看。

search这一工具使智能体能够查询平台的OpenAPI规范。通过这一接口,智能体可以发现可用的接口端点、了解参数信息,并检查响应数据的结构。

MCP客户端

由于API规范是可以被搜索的,因此智能体无需事先了解平台API的具体结构。它可以根据自身需要执行的任务动态地探索这些API。

例如,如果用户要求智能体列出自己账户中运行的所有应用程序,智能体就可以通过查询API规范来开始执行这一操作。

const endpoints = await sevalla.search("list all applications")

查询结果会返回相关的API定义信息,包括请求所需的正确路径和参数。一旦智能体确定了应该使用哪个接口端点,它就可以生成相应的API调用语句。

execute这一工具会在一个隔离的V8环境中运行JavaScript代码。在这个环境中,智能体可以使用平台提供的辅助函数来调用API。

const apps = await sevalla.request({
  method: "GET",
  path: "/applications"
})

因为代码是在隔离的V8沙箱环境中运行的,所以生成的脚本无法访问主机系统。智能体只能通过API辅助函数与外部进行交互。这种设计确保了AI智能体能够在安全的前提下执行基础设施操作,同时仍具备生成动态API调用的灵活性。

这种机制使得智能体无需为平台的各项功能预先准备专门的工具,就能发现并使用这些功能。在通过API规范找到相应的接口端点后,智能体就可以利用生成的API调用语句来检索应用程序数据、检查部署情况、查询指标信息或管理基础设施资源。

这种设计还大大减少了所需工具的数量。传统的MCP集成方案可能需要数百种工具才能覆盖大型API的所有接口端点,而采用搜索与执行相结合的模式后,只需两个工具就能访问整个API接口体系。

对于那些需要将AI助手与基础设施平台进行集成的开发者来说,这种架构为暴露大型API提供了实用的方法,同时使集成过程变得简单高效。

这对开发者意味着什么

允许AI智能体与基础设施API进行交互,改变了开发人员管理系统的方式。

开发者不再需要手动浏览控制面板或编写冗长的命令序列,而是可以用自然语言来描述自己的需求。AI智能体会解读这些请求,找到相应的API接口端点,并执行所需的操作。

这种方法还能提升系统的可观测性及调试效率。当出现问题时,智能代理可以查询日志、检查各项指标,并获取系统状态信息,而无需开发人员手动收集这些数据。

随着时间的推移,这种集成方式将显著降低管理复杂云系统所带来的种种麻烦。

基础设施自动化的下一阶段发展

基础设施自动化已经经历了多个发展阶段。早期的云系统主要依赖网页界面进行手动配置;而“代码即基础设施”的理念使开发团队能够通过脚本和配置文件来定义基础设施结构。

随后,CI/CD流程自动化了系统的部署与更新过程。

人工智能代理代表了这一技术发展的下一个阶段。通过结合API、MCP集成机制以及沙箱执行环境,开发人员可以让智能系统对基础设施进行逻辑分析,并安全地与之交互。

与传统静态集成方式不同,智能代理可以根据实际需求动态发现并调用相关API,这使得基础设施管理变得更加灵活且易于使用,同时依然保证了可编程系统的可靠性。

随着人工智能工具在开发环境中的应用越来越广泛,智能代理理解并控制基础设施的能力很可能会成为现代平台的一项基本功能。

希望您喜欢这篇文章。 欢迎访问我的博客,那里有更多实用教程等着您。

Comments are closed.